About the Post
Software Patterns generally include Architectural Styles,
Design Patterns and Language Idioms. This post is part of a 3-part introduction to Architectural Styles. Part-I will introduce the more commonly used styles, Part-II will introduce some of the hybrid styles are used today and Part-III will provide some insight into emerging styles.
Note that this post is not intended to be a comprehensive guide or tutorial on all existing architectural styles but only a brief introduction to a sub-set of more commonly used architectural styles.
Note that this post is not intended to be a comprehensive guide or tutorial on all existing architectural styles but only a brief introduction to a sub-set of more commonly used architectural styles.
Architectural Styles - Part I
Definition[1]: An architectural style expresses a
fundamental structural organization schema for software systems. It provides a
set of predefined element types, specifies their responsibilities, and includes
rules and guidelines for organizing the relationships between them.
In short it’s a template that defines how the software
components of the system are organized and how they are inter-connected.
There are some classifications done for categorizing
architectural styles. A preliminary classification of these styles is presented
in Shaw and Clements [1997] and repeated in Bass et al. [1998].Typically these
classifications are based on what kinds of components and connectors between
them are used in a particular architectural style. However the primary goal of
this post is to provide an introduction to more commonly used styles and ignite
interest in software architects to evaluate existing architectural styles based
on their applicability to their systems.
Pipes & Filters
Description:
In a pipe and filter style each component has a set of
inputs and a set of outputs. A component reads streams of data on its inputs
and produces streams of data on its outputs, delivering a complete instance of
the result in a standard order. The filters modify or transform or in some
cases examine the data as it passes through them. This computation to the input
streams is done incrementally so that output begins before input is fully consumed.
The pipes serve as conduits for the streams, transmitting outputs of one filter
to inputs of another.
Constraints:
The constraint is that a filter must be completely
independent of other filters (zero coupling): it must not share state, control
thread, or identity with the other filters on its upstream and downstream
interfaces.
Variants:
- Pipelines — linear sequences of filters
- Bounded pipes — limited amount of data on a pipe
- Typed pipes — data strongly typed
- Uniform Pipe and Filter —all filters must have the same interface.
Examples:
Traditionally compilers have been viewed as a pipeline
system (though the phases are often not incremental). The stages in the
pipeline include lexical analysis, parsing, semantic analysis, and code
generation. Other examples of pipes and filters occur in signal processing
domains, functional programming, and distributed systems.
Advantages:
- System behavior is a succession of component behaviors
- Filter addition, replacement, and reuse
- Possible to hook any two filters together
- Certain analyses such as throughput and deadlock analysis
- Concurrent execution
Limitations:
- Often lead to batch organization of processing
- Not good at handling interactive applications
- Might force lowest common denominator on data transmission leading to loss of performance and increased complexity in implementing filters.
Event-based Integration
Description:
The idea behind event-based Integration (also called implicit
invocation, selective broadcast) is that instead of explicit communication
between software components (e.g. via procedure calls, remote object calls
etc), software components simply broadcast one or more events. Other components
in the system can register an interest in an event by subscribing to it. When
the event is announced the interested components are notified and they can
invoke the required procedures accordingly. Thus an event announcement "implicitly" causes other components to invoke procedures in their modules.
Constraints:
The constraint is that software components broadcasting
events do not know which components will be affected by those events. Hence no
assumptions on the order of processing can be made by the components announcing
the events.
Variants:
·
Message Bus — events are exchanged via an intermediate
component usually called message bus or message router. Though the primary
concept is based on implicit invocation, yet most the message bus architectures
provide multiple integration patterns that qualify them to be considered as a
separate style as well.
o
Enterprise Service Bus – An ESB uses services
for communication between the bus and components attached to it. An ESB
typically provides services that transform messages from one format to another
to enable components that use incompatible messages to communicate.
o
Internet Service Bus – Is similar to an ESB but
the participating components are hosted in a cloud instead of on an enterprise
network. ISB uses URI (Uniform Resource Identifiers) to control the routing of
messages between the participating components.
·
Publish-subscribe – Subscribers
register/deregister to receive specific messages or specific content.
Publishers broadcast messages to subscribers either synchronously or
asynchronously.
Examples:
Examples of
systems with implicit invocation mechanisms abound. They are used in
programming environments to integrate tools, in database management systems to
ensure consistency constraints, in user interfaces to separate presentation of
data from applications that manage the data, and by syntax-directed editors to
support incremental semantic checking.
Advantages:
- Component reuse
- System evolution
- Loose coupling between components.
Limitations:
- No knowledge of what components will respond to event
- Lack of control on order of processing. (Message bus architectures overcome this by externalizing the routing logic and providing some control on it).
- Counter-intuitive system structure.
Layered Systems
Description:
Layered
architecture focuses on the grouping of related functionality within a system
into distinct layers that are stacked vertically on top of each other, with each
layer providing service to the layer above it and serving as a client to the
layer below. The layers of an application may reside on the same physical
computer (the same tier) or may be distributed over separate computers (n-tier),
and the components in each layer communicate with components in other layers
through well-defined interfaces.
Constraints:
Components in one layer can interact only with components in
the same layer or with components from the layer directly below it.
Variants:
· N-Tier/3-Tier Architecture — Though this
qualifies to be a style in itself, since there is good amount of resemblance from
the separation of concerns into different layers, I have taken the liberty to
include this as a variant of Layered architecture. Communication between tiers
is typically asynchronous in order to support better scalability.
Examples:
Examples of
systems with layered architecture are abound; most of the network protocol
stacks use this style like the OSI, TCP/IP stack etc. Line-of-business (LOB)
applications such as accounting and customer-management systems; enterprise
Web-based applications and Web sites, and enterprise desktop or smart clients
with centralized application servers for business logic.
Advantages:
- Increasing abstraction levels
- Easy evolution
- Changes in a layer affect at most the
adjacent two layers
- Reuse of software assets
- Different implementations of layer are
allowed as long as interface is preserved
- Standardized layer interfaces for
libraries and frameworks
Limitations:
- Can be quite difficult to find the right levels of abstraction
- Performance
Repositories
Description:
In a repository style there are two quite distinct kinds of components:
a central data structure represents the current state, and a collection of
independent components operate on the central data store. Interactions between
the repository and its external components can vary significantly between
systems. The choice of control discipline leads to major subcategories. If the
types of transactions in an input stream of transactions trigger selection of
processes to execute, the repository can be a traditional database. If the
current state of the central data structure is the main trigger of selecting
processes to execute, the repository can be a blackboard.
Constraints:
System control is entirely driven by the blackboard state.
Variants:
Replicated Repository: The repository is decentralized
(either replicated or partitioned) yet they as a whole provide an illusion of a
centralized view to the clients.
Examples: Typically
used for AI systems and in applications requiring complex interpretations of
signal processing, such as speech and pattern recognition.
Advantages:
- Suitable for complex problems
- Incrementally lead to problem resolution, enables easy troubleshooting.
Limitations:
- Control is completely driven by repository state
Data Abstraction and Object Oriented Organization
Description:
Data Abstraction architecture focuses on the division of
responsibilities for a system into individual reusable and self-sufficient objects,
each containing the data and the behavior relevant to the object. Objects are examples
of a sort of component we call a manager because it is responsible for preserving
the integrity of a resource (here the representation). Objects interact through
function and procedure invocations. The object is responsible for preserving
the integrity of its representation and the representation of that object is
hidden from other objects.
Constraints:
- Objects are
responsible for their internal representation integrity
- Internal representation is hidden from other objects
Variants:
There are many variations. For example, some systems allow
“objects” to be concurrent tasks; others allow objects to have multiple
interfaces.
Advantages:
- Object internals can be altered without affecting the clients.
- System decomposition into sets of interacting agents
Limitations:
- Objects must know identities of other objects that they intend to interact with.
- Side effects in object method invocations
Client/Server
Description:
The client-server style is the most frequently encountered
of the architectural styles for network-based applications. It segregates the
system into two applications, where the client makes requests to the server. A
server component, offering a set of services, listens for requests upon those
services. In many cases, the server is a database with application logic
represented as stored procedures. A
client component, desiring that a service be performed, sends a request to the
server via a connector. The server either rejects or performs the request and
sends a response back to the client.
Constraints:
Separation of concerns is the principle behind the
client-server constraints. User interface functionality is concentrated in
client side.
Variants:
There are many variants mainly depending on how the client
and server components interact i.e. based on the various connectors between the
two components e.g. Client-Queue-Client Systems, Peer-to-Peer applications etc.
Examples:
Most of the network based applications like FTP, DHCP etc
are all client-server style architectures.
Advantages:
- Separation of concerns allows the two types of components to evolve independently.
- Centralized and secure data access.
- Ease of maintenance as the roles of each component are well established.
Limitations:
- Application and data logic is combined on the server component.
- Extensibility and Scalability
Mobile Code
Description:
This style is mainly based on the philosophy that
transferring code (business logic) over the network is cheaper than transferring
the application data and hence the name Mobile Code. Mobile code styles use
mobility in order to dynamically change the distance between the processing and
source of data or destination of results. In all of the mobile code styles, a
data element is dynamically transformed into a component.
Variants:
Code-on-demand, remote evaluation, and mobile agent.
Examples:
Mainly used in network management applications like Intelligent
Mobile Agents.
Advantages:
Improved the proximity and quality of its interaction
Reduces interaction costs and thereby improving efficiency and
user-perceived performance
Limitations:
Suitable only for specific application areas.
Summary:
This concludes the introductory part to commonly used architectural styles, in the next part of this series of posts we will see hybrid styles that are popular today.
