SOA-Service Oriented Architecture
Nowadays, software could not be just defined in terms of an application, either standalone or web-enabled one, but should also be fit into on-demand business requirement, rendered as a service. Like the services that a customer avails at a restaurant or a cafeteria. Here, the customer need not know about the whole process involved while placing an order. The customer just places the order and gets back what he asked for. Behind the scene, the order is first passed from the waiter to the chef who prepares the item and then passes through the bill counter where the item pricing is done and finally goes to the customer’s desk. The customer just pays for it and consumes the item.
Where does SOA fits in?
Similar is the situation in our current IT market where a software should be rendered as a service that is built or developed once, applied to many and by many. Thus said, the software built for such causes should be customizable and scalable. This comes under the responsibility of the developers. For this, the software objects aka business objects we develop should be loosely coupled not just with each other but also with the operating system and other technologies it should be integrated with. How it can be made possible? Can a person who speaks only English understand Dutch? We certainly need interpreters in such cases. But this does not suffice if the translation should be done among different languages and that too if new languages and technologies evolve as in case with software industry.
To solve this problem, we need to develop metadata sufficient enough to describe not just what types of services are rendered but also the type of data and how it can be consumed in various ways. Thus, when a business object in a software is rendered as a service, it should contain a metadata that tells the ways of consuming it across different platforms. For this purpose, a special architectural pattern is defined as a layered pattern termed as Service-Oriented Architecture (SOA).
Is SOA similar to Web Services?
In web services, the business objects that are built in any language is wrapped inside an XML-structured language because XML is platform independent. However, since these objects need to be transmitted across a distributed network a special protocol is needed and that call as Simple Object Access Protocol (SOAP). However, these consumers need to be aware of the availability of these objects. For example, if we want to develop a weather report program that generates a chart type of interface for displaying temperatures across the world, we first need the data. Consumer or again the weather report programmer need not go and collect or do some logic to get the temperature and other information but can avail/use prebuilt utility that has been developed by another programmer in some part of the world.
In this case, the consumer/programmer need not install any specific software which can again occupy some space in his/her system. This is made possible by a special language called Web Services Description Language (WSDL) that typically defines such services. Just like we register our address information on yellow pages, these services should be registered such that it can be easily located and for this, a common registry is set up that is termed as Universal Discovery Description and Integration (UDDI). It acts much like our traditional yellow pages from which we can search for a particular service and who is offering it, etc. The salient feature of SOAP, WSDL, and UDDI is that they are XML-based.
Service-Oriented Architecture cannot be completed as said web services, but we can say that web services is an approach towards SOA.
Service-Oriented Architecture — Concept
Connecting disparate systems is the main aim of SOA. SOA should also ensure that the messages are properly and promptly delivered. For this, SOA architecture contains a special layer called Enterprise Service Bus (ESB) which takes care of guaranteed delivery of messages. ESB need not be coded by us rather can be got from Microsoft, Sun Microsystems, IBM, etc.
In concrete, SOA consists of a group of components that include,
- SOA Registry, which is a directory of information that contains where the services are located.
- Loosely coupled business component that is wrapped inside an XML-based descriptive language.
- A service broker which is a middleware technology (Enterprise Application Integration – EAI) that reads the services from the registry and ties it together with other components. These middleware need not be developed by our own. We can get this from Sun Microsystems, Microsoft, IBM, etc.
Different vendors provide different layers using their own implementation languages however layered approach is the common phenomena for all.
SOA — Building Blocks:
Once a service is built up, they must be exposed at one or more ends such that it can be available to the clients. Thus SOA’s endpoints consists of three main things namely
- Address – This is an URL that points to the location of service.
- Binding – This takes care the communication part. It tells how the services are exposed and accessed using SOAP over HTTP, binary, MTOM, TCP, etc.
- Contract – This defines the protocol of how the client communicates with the service, i.e., what method of invocation and what parameters are to be passed and value to be returned.
Thus, SOA is a concept which can be implemented using different technologies like Microsoft’s DCOM & WCF, Sun’s EJB, etc.
