IBM Service Oriented Architecture (SOA)

 Service-oriented architecture is a style of software design. Where the Business service is provided to other components in the SOA environment as an independent unit, through communication protocols. And the core service functionality is separated from other software components like (mediation, connectivity and extra logic).

Implementing an SOA mainly is for developing applications that use services. Furthermore SOA service is a set of an independent reusable unit of functionality. The service is provided by a service provider and consumed by a service requester remotely, such as get account balance online.


In addition SOA service represent a business activity, which can contain multiple underlying activities. But as a consumer it looks at the service as a black box. Because of the known outcome of it. SOA enables software developers to combine services (Functionality) in a big software application, in order to provide what consumers need.

As proved by the history of software and system development in the last fifty years, software architecture plays an important role in software system. An architectural model is a representation that contains basic building blocks common to all similar applications, along with a certain aspects unique to each specific application.

So Figure.1 below, shows how SOA works to convert software application from a set of business functions grouped together, to an independent reusable service which can be used by other programs.

SOA architecture
Figure .1: SOA separates connectivity, mediation and the extra logic from the Business services.

Enterprise Service Bus (ESB)

In order to start with ESB concepts, we should first begin with Middle-ware concepts and definitions. Middle-ware often sits between the operating system and applications on servers. And it simplifies the development of applications that use services from other applications. Allowing programmers to create business applications without having to custom integrations for each new application.

Typically, middle-ware programs provide messaging services. So that different applications can communicate using messaging protocols, like Simple Object Access Protocol (SOAP). Collecting services together from different applications, often through the use of middle-ware, is known as EAI (enterprise application integration).

At a basic level, middle-ware provides services required to connect applications together such as concurrency, transaction management, threading and messaging. More sophisticated implementations of middle-ware principles are baked into modern integration infrastructure such as ESB (enterprise service bus) and API management. Software to provide greater governance, risk management and accountability.

Figure.2 below, shows the SOA Reference Architecture logical model view. The logical model view decomposes the functional underpinnings of an SOA solution. This functional or IT-focused view portrays the ESB as an integration part, that supplies inter-connectivity among other IT parts of a solution.

IBM SOA figure.2
Figure .2

Figure.3 below, shows the SOA foundation reference architecture solution view. This is a business-focused view of a service-oriented solution. Note the portrayal of the ESB as an integration layer underpinning the inter-connectivity among the business parts of the solution.

Figure .3


ESB core principles

Service requester and providers interact by exchanging messages. The ESB, acting as a logical intermediary in the interactions, provides loosely coupled inter-connectivity between the requester of a function and the provider. Its role as a logical intermediary is to allow the ESB to intercept messages and process them as they flow between a service requester and provider. This processing is called mediation. See figure.4 below.

Figure .4

The ESB appears as a centralized hub in Figure.2. And the physical realization of the architectural pattern in many solutions is in fact a physical hub. Figure.4 attempts to suggest the architectural pattern can have different realizations. For example, the ESB can be distributed so that mediation can physically take place in the service requester environment. Since the service provider environment, in a centralized hub environment, or in any combination of those realizations.


IBM ESB products

Figure .5


IBM Integration Bus 

For environments that must integrate multiple different heterogeneous applications. Including those environments that require an SOA-enabled infrastructure without substantial rework.


WebSphere Data-power

Excellent solution for companies that have a high level of XML data structures and a need for speed. Must deploy an ESB (Enterprise Service Bus) in a DMZ (Demilitarized Zone).


WebSphere Enterprise Service Bus

Well-suited to integrating environments with a preponderance of standards-based applications and web services assets.




In conclusion, you learned how the enterprise service bus is a key architectural pattern. The article described,  how the ESB supports service virtualization and aspect-oriented connectivity between interacting participants. How the architectural pattern is implemented using a variety of logical typologies and a variety of middle-ware technologies and products.




7 thoughts on “IBM Service Oriented Architecture (SOA)

Leave a Reply

Your email address will not be published. Required fields are marked *