Service Oriented Architecture – Introduction

SOA, which is Service Oriented Architecture, is a buzz word since recent past. It is also getting accepted in organizations having a pool of applications supporting business requirements. To understand what is service oriented architecture, let us start with the first word ‘Service’. We understand what a ‘Service’ means and then take it forward to connect with architecture.

What is a Service?
In real world, we know service is getting some help/work done from others. (And you also know that it is getting expensive day by day). This ‘others’ includes living as well as non living things. An animal can also provide us service in an hour of need, while many electronic products provide us day to day services.

If we want to identify characteristics of a service then -

A service -

• means getting something done from others
• may involve cost
• involves rules of service, can be called as a agreement or contract
• must have contract which changes less frequently
• can be provided by anybody who will be called as service provider
• can be used by any user/client
• may change the way of implementation without affecting contract or client
• can be published (advertised) by service provider
• should involve some rules of quality
• can be monitored for performance

In our case, when we connect service word with architecture, these characteristics need to be fulfilled by a service and also by the architecture which is backbone of this service. Hence a service oriented architecture is an architecture which can transform a component build on it into a service satisfying above characteristics (sometimes partially based on priorities and context).

Let us take an example. An organization has many applications, e.g. order entry, order processing, billing, complaint management, etc. These applications rely on customer information which reside in database. All these applications read customer information from database and use as required. This means the code, to read customer data from database, resides in all applications. We can think of moving this customer data read logic from all applications to a separate component. This component will be responsible for reading the customer data from database and presenting it in certain generic form suitable for all applications. It will also be accessible to all applications irrrespective of platform and location. All applications will just call the interface provided and get customer data irrespective of how the component internally reads data. Here the component can be called as customer data service. There are more technicalities involved in this, but we keep these for later discussion.

In short, SOA is a architecture pattern that can convert a component into a service.