SOA: Service Oriented Architechture

The hottest developments of the software services market have been revolving around Service Oriented Architecture and Cloud Computing off late. Which of these was the predecessor might be debatable and contextual but both have been creating buzz and traction in the market. History of these might be traced as back as in 1950's but the real growth/development of these principles started post dot com burst in the past decade. Every leading vendor in this space is trying to come up with new offerings and even there are people who are trying to re-brand there services as Cloud or SOA based as it makes it lot easier to sell. So it is very important to understand the real SOA and Cloud offerings, advantages, and differences with other competing technologies and principles.

Service Oriented Architecture

 A simple one line definition of Service Oriented Architecture is follows: SOA represents a collection of services that communicate with each other to perform defined and self contained tasks as a whole or as individual input/output units. It is necessary for the services contributing to the SOA be independent of each other’s state and context. Potentially these create mutually fulfilling production/consumption units that are contributors to a larger business flow.

The success (technical) of a SOA based application largely depends on the connection/communication between the underlying collection of services. Currently the most effective and common communication mechanism used is WebServices that use XML to talk to each other. A typical communication example of service oriented architecture would typically be as follows:

Two essential entities in a SOA based application are the service provider and the service consumer. The service provider creates a description of its services using a language, such as the Web Services Description Language (WSDL). This description/definition is then published to the directory of services. The directory of services can be UDDI based or ebXML registry based. The service consumer queries the directory of services to determine the details required for invoking the services. These details are extracted from the WSDL and passed to the service consumer. With these details the consumer understands what is should be the request format for the required service and also the format of the response from the service provider. After getting the details of the service request and response the consumer sends the service requests to the provider using the WSDL. The provider performs valid actions on the requests and sends appropriate responses as declared in the definition of the service.


The primary advantages of using the services oriented architecture are:

---> Loose coupling of business components

---> Helps increase agility in the development phase

---> Helps in decreasing the time to market

---> Helps increase the usage of external services for business growth

---> Helps manage business workflows

---> Easy customizations for diverse audience

---> Enhanced adaptation capability in the overall workflow

---> Reduction of production and maintenance cost

Even though SOA has so many advantages but it not necessary to be the best solution for all business/application development scenarios. It is important to understand and know the scenarios where SOA may not be desirable solution design. Few examples where SOA may not be used are:

---> Stand alone applications which are not distributed in nature

---> Applications that do not require request/response based design

---> Applications with short lifespan as the ROI may not be fully recovered

---> Applications where re-usability is not in the scope

---> Applications where loose coupling is not required