Software Architectural Styles

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.

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.