Skip to content

Service Oriented Architecture

Service Oriented Architecture was developed to solve the problem of how to connect disparate systems in a way that they could function together in a systematic manner.

Service Oriented Architecture is less about how to modularize an application, and more about how to compose an application by integration of distributed, separately-maintained and deployed software components.

Service-Oriented Architecture (SOA)

Service Oriented Architecture is a software architecture where distinct components of the application provide services to other components via a communications protocol over a network. The communication can involve either simple data passing, or two or more services coordinating connecting services to each other.

As you can see in the preceding diagram, there are two main layers of the SOA: a service consumer layer and a service provider layer. The service consumer layer is the point at which all the consumers, such as human consumers and other service consumers, interact with the SOA. The provider layer is the point where all services are defined within the SOA.

The Enterprise Service Bus (ESB) provides communication by a common communication protocol, or communication bus, which has connections between the consumers and providers. In SOA architecture, database storage is shared between all services.

Enterprise Service Bus

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture. As it implements a distributed computing architecture, it implements a special variant of the more general client-server model, wherein, in general, any application using ESB can behave as server or client in turns. ESB promotes agility and flexibility with regard to high-level protocol communication between applications.


All customer services communicate in the same way with the ESB: the ESB translates a message to the correct message type and sends the message to the correct consumer service.

The ESB is implemented in software that operates between the business applications, and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB.

The primary duties of an ESB are

  • Route messages between services
  • Monitor and control routing of message exchange between services
  • Resolve contention between communicating service components
  • Control deployment and versioning of services
  • Marshal use of redundant services
  • Provide commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service

Key benefits

  • Scales from point-solutions to enterprise-wide deployment (distributed bus)
  • More configuration rather than integration coding
  • No central rules-engine, no central broker
  • Easy plug-in and plug-out and loosely coupling system

Key disadvantages

  • Slower communication speed, especially for those already compatible services
  • Single point of failure, can bring down all communications in the Enterprise
  • High configuration and maintenance complexity

Web services and SOA

A web service-based SOA cannot rely on a single monolithic service bus. Web services are based on slightly different principles than a traditional SOA. Each service needs to be reusable, stateless, autonomous, abstract, discoverable, and loosely coupled. Instead of a formal service bus, you have a service integration layer, which operates as a logical or virtual service bus.

Many protocols can be used and are used to communicate between the various web services over TCP/IP. The most common is SOAP. SOAP provides a standard message format that consists of an XML document capable of hosting remote procedure call (RPC) and document-centric data. SOAP can be easily leveraged by both synchronous and asynchronous data exchange models. SOAP, as a raw protocol set, does not define a preset language, allowing the application designer to create a language specific to the architecture.

An alternative to SOAP-based web services is the Representational State Transfer (REST)-based web services. REST leverages the existing vocabulary of the HTTP or other robust application layer protocols with existing vocabularies.