Architectural Styles and Service Oriented Architecture

The core repertoire of the IT Architect consists of a number of architectural styles. This paper will describe one or more styles that naturally belong to Service Oriented Architecture.

 

Introduction

Investigating which style or styles naturally belong to SOA, we start with the definition of Architectural Styles (styles) and Service Oriented Architecture (SOA). Combining these definitions will lead to a single style or set of styles that best support SOA.

Architectural Styles

Styles are a mechanism to categorize architectures by capturing the essence of interaction between system components and ignoring the incidental details. Each style embodies a unique pattern of interaction and therefore suitable for specific system requirements.
Since architecture embodies both functional and non-functional properties, architectural styles will help determine the most suitable architecture for specific system requirements. By defining the key quality aspects of a system and comparing these with the strength and weakness of each style will result in the best matching system architecture for that specific system.
Commonly used styles are:
Pipe-filter
Data is send through a set of filters by using pipe components, ending up in the sink that captures the final output.
Hub & Spoke
Data is send to the hub that translates the data and sends it to a spoke.
Blackboard
Data is shared on a single place, all applications read/write to that single place of data.
Master/Slave
Data is send by the master to a slave that processes the data and send the result back to the master.
Event-bus
Data is send onto the bus, which informs interested components of events coming available. The interested component picks up the data, transforms is and sends it back onto the bus.
Layers
Data is transferred trough multiple layer, where each layer has it’s own function(s).
Client-Server
The client requests data to the server after which the server send the data to the client.

Service Oriented Architecture

SOA is a software architecture that enables business agility by using loosely coupled services that support a specific business process. Services are reusable business functions that can be orchestrated to form composite applications. Each service is discovered as self-describing interface and can be invoked using open standard protocols across networks.
When characterizing SOA, the following can be distinguished:
          Services are loosely coupled; Adjustment of one service or business process is transparent to the rest of the services and the orchestrated composite applications using them.
          Services are business driven; System architecture is designed to be coherent with the organisation architecture. A change in a business process can be easily translated to a change in the supporting service.
          Services are protocol independent and location transparent; Interoperability of services is independent of the protocol used or the location the service.
          Services can use message-based communication; Asynchronous communication between services improving the loose coupling.
          Services are composable; Services are used to compose applications, each service can be used by multiple applications.


Styles for Service Oriented Architecture

Using the definitions of architectural styles and SOA we describe architectural styles, highlighting their strength and weakness when used for SOA.
Pipe-filter
Pipe-filter is a high adjustable style; filters can be changed with ease. It is however tightly coupled, due to the chain configuration of the style. Each filter is built on the specific output of the former filter, making that a change to one filter impact the next filter.
Hub & Spoke
A single hub with many spokes, the essence of the hub & spoke style, is not in line with SOA. A significant strength of SOA is the ability of services to interoperate point-to-point. Scalability is also a problem of the hub & spoke style, because the messaging hub becomes a bottleneck to the architecture.
Blackboard
The blackboard style uses the principle of a single shared dataset that is used by multiple applications. This style is too inflexible for SOA because all applications should be change when the dataset changes making is tightly coupled. 
Master/Slave
Master/slave can be determined more as an infrastructural style than a software architecture style. This style is mostly used for redundancy solutions, where a single master orchestrates all requests and answers, just the opposite of SOA where each service interoperates independently of each other.
Event-bus
The event-bus style is designed to provide a messaging layer for services, the bases of SOA. This style allows point-to-point and messaging interoperability and supports enterprise qualities of service like security and transactions The connected services can be design to be business driven, making is a naturally belong style for SOA.
Layers
Each layer provides services to the next layer, mostly communicating synchronously. Layers are dependent on the lower layer, making defining of abstract service interfaces difficult and possibly performance intensive.
Client-Server
Client-server style initially looks like it naturally belongs to SOA, each service acts as both client and server. SOA however, requires something like n-client to n-server supporting interoperability in-between services. The client-server style does not focus on protocol independence and does not make services loose coupled. Therefore this style is not ideal for SOA.
Using the characteristics of the architectural styles to compare with the required characteristics of SOA shows that there is only one true style for SOA, namely ‘Event-bus’.

 

Conclusion

The essence of SOA lies in the use of services. Services are designed to be self-containing and modular. Services should be designed for interoperability with each other using messaging or point-to-point. Services are business process driven and loosely coupled, best supporting the organisation architecture.
Although real-life systems mostly contain a combination of styles, the event-bus truly captures and strengthens the essence of SOA. The event-bus style therefore natural belongs to SOA.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s