Service Oriented architecture – Intro

So, a lot has been said about Service Oriented Architecture, or SOA in short. Thus, I would like to keep the introduction brief and easy here.

In order to talk about SOA, we need to first understand what services are. Services (also in the non-technical world) are the provision of specific functionality. Such functionality is unique and specific and independent of other functionality. Such functionality is also complete in itself and independent. To take a real-world analogy , we have the washing machine – its functionality is well -defined. It washes clothes – and it does that independently of any other device. So a washing machine provides a service of washing clothes. A refrigerator is also a service provider – its job is to cool and preserve the content inside. Similarly, a dish-washer provides the service of washing dishes. All these are examples of services provided. Such services are simple, well-defined and immediately create a picture in your mind in terms of what is the basic functionality/ service provided.

In the world of computing, we similarly have services – which are ideally well-encapsulated units of specific and uniquely provided functionality. It should be clear what type of functionality will be provided by a specific service. Ideally there should be no redundancy – one type of functionality is provided by one service only. This is what will lead to the benefits of reuse and minimization/ elimination  of redundancy.

What is the need for having services? In a typical IT landscape, even in a mid-sized enterprise today, there are multiple stove-piped systems, each one complete by itself and providing all the functionality it needs. Let us start with the concept of customer – each enterprise system will have its own definition of customer – and the data structure and definition for the same. There will be multiple systems like the sales, marketing, accounting, purchases, etc. which may deal with the concept of customer, each with its own definition and understanding of the term customer and also the functionality for the same. This leads to a lot of redundancy in the IT systems. Each system above will have its own functionality for creating a new customer, communicating with the customer, collecting data about the customer etc., and none of them are synchronized with each other. Suppose we want to start a new customer help desk system. Actually, all the information about the customer is available, but it is distributed across various systems, there is no single source of truth or master of customer-related information. This is the bane of the stove-piped systems. In most cases, the new system will also create its own definition of customer and add one more definition to the picture.

As you can imagine the maintenance of such systems is a nightmare! If the customer address changes, this information may be captured and modified only in one system leading to a discrepancy in the information. Unless, effort is made to explicitly find out all the places where the information about that customer is stored and modify the address information after understanding the semantic / meaning of all the address information for the different systems. If this change is not propagated to all the systems, then there may be situations where the customer delivery goes to a wrong address etc., resulting in overall dissatisfaction and increased costs on all sides. There are systems like the Customer Relationship Management systems (CRM) systems whose objective is to consolidate all customer related information in one single place. Typically, such projects are massive exercises that touch and impact many existing systems and business processes in an enterprise.

So what does all this have to do with SOA? SOA advocates creation of well-defined and specific services whose functionality is clearly defined. The functionality is also clearly available and advertised so that all the systems that may need to use this functionality know exactly how to interface with the service. If you need to wash clothes, you use a washing machine and if you need to wash dishes, you use the dish-washer. There is no confusion. Ideally this interface is provided in a platform-independent manner using some well-defined and standardized technologies that all the systems understand and are able to interface with. Ideally also the interface is independent of the actual implementation of the service.

This leads us to the second key aspect of the services concept – which is the concept of black-boxing or encapsulation. The interface or the way to access a service should ideally not change frequently. This increases the longevity of the architecture and implementation as a whole. Even if there is a change in the implementation of a service, the other systems are not impacted by it as they do not know of such changes. They only talk to the interface and as long as the interface does not change, there is no impact to other services.

The third aspect of service orientation is the communication. Ideal communication between the systems or services must be by means of passing messages. This is analogous to the postal or the “snail mail” system.  We can send post from one country in a continent to another country on another continent, albeit very slowly, using the standard conventions. You put your message inside the envelope ( which also takes care of privacy) and write the address of the recipient on the envelope and viola,  the mail reaches the intended recipient wherever they are! Similarly for communication among services, they should pass messages to each other using some standardized way of communicating like standard protocols (XML, HTTP etc.) and this makes the systems communicate and understand each other in a platform-independent manner.

Once we have a set of services, the SOA advocates creating larger processes/ functionality / services using such granular services. The services communicate with each other by message passing. This leads to creation of well-encapsulated, long-lived, well-defined systems that eliminate redundancy in terms of functionality. With these basic thoughts, I would like to take leave. See you again!

This entry was posted in SOA. Bookmark the permalink.