IT Articles : What’s really SOA Services?
IT Articles : What’s really SOA Services?
SOA as in Service Oriented Architecture is an architecture of building systems based on loosely coupled interoperable services. SOA has a broad meaning that goes beyond software architecture. SOA is an architecturual guideline to building a system based on services.
What really are services? In SOA, Software and Hardware and the system built around it is called a Service. While SOA is mostly viewed from the context of a Software, but nothing stops it from being a Hardware. Services may be both hosted as software or hardware. These services are offered in a common communication link (like Internet) so that the consumers (the clients) can see what services are being offered.
The term loosely coupled in SOA is very important. Loose coupling predominantly means that the Service is self contained with minimal or no dependencies. That means, the consumer is guaranteed to get the expected result from calling the service, if the parameters to the service meets the specification. A service expects to receive data upon which it will operate. This data is fed to the service in various ways.
Among many proprietary ways in which data may be fed, some standard way of sending and receiving data is REST (Represental State Transfer) and SOAP (Simple Object Access Protocol). These formats have no relationship to the service itself (hence the loose coupling), rather it represents data and the structure of the data. Therefore, both REST and SOAP messages may be interpreted by any service and the client.
The reason for SOA to be interoperable is in fact derived from loose coupling. Adopting a data dependent message format like REST or SOAP makes the service interoperate across any platforms. SOA is not associated with HTTP protocol or JMS service.
A SOA service therefore may be based on REST, SOAP or some proprietary format as long as the services are loosel coupled and interoperable. If the protocol is SOAP, it is also called Web Service. If the format is REST, it is called RESTful service. A single service may support both SOAP and REST. Both SOAP and REST are data representation format, not a transport. Because the service and the client have to be somehow linked, the transports may be HTTP/HTTPS, JMS, FTP, Files, etc. SOA does not limit the kind of transport. The most popular are, however, HTTP(S) and JMS. HTTP(S) is the most popular due to its support by web browsers making it firewall safe as well as web browser ready.
SOA services may be consumed by web applications as well as any other platform specific applications. JMS (Java Messaging Service) is usually used in cases for asynchronous communication between the client and the service. An ideal SOA service should be able to handle both synchronous and asynchronous transports. Typically, synchronous transport uses RPC based protocol and asynchronous transports use message based protocol.
Let us consider that we have an AddressBook service as a SOA service, which may be consumed by both a mobile phone application written in J2ME as well as a PC application written in C# .NET. AddressBook service must be interoperable due to the fact that it is consumed by two different applications written in two different programming languages.
The mobile phone sends REST based data format through HTTP to the AddressBook service, while the PC application sends SOAP format through JMS. The AddressBook service is designed to support both REST and SOAP, so as soon as the data in either format is received by AddressBook, it can process the data and return the result in the same format in which it received.
?Notice that the transport layer was not a concern for the AddressBook service. Sits between a SOA Service and the client is a routing middleware called an ESB (Enterprise Service Bus). It is practically a router which converts data or transports in one form to the other. While modern ESBs are much more than just a router, but it is the router portion that is responsible for all routing activity for the AddressBook service. In general, ESB is not a necessity, but if not present, would require the service itself to support multiple protocols and message formats. This makes each services difficult to maintain. Therefore, having an ESB in between a service and a client makes services easy to develop and maintain.
SOA achieves loose coupling by eliminating the transport layer and adhering to the structure of data and by keeping the data represented in a standard format, it becomes interoperable. SOA services are also described in a standard way. Web Services uses standard XML template called WSDL (Web Services Description Language) to describe the messaging format to communicate with the service. WSDL may also be discovered by having them advertised in registries. A registry is conceptually similar to the domain name registrar, except now that it is for a SOA service.
