Service Oriented Architecture (SOA) - Concepts, Components, and Standards

Service Oriented Architecture (SOA) - Concepts, Components, and Standards BY DR. PETER EICHHORST

The Necessity of an Architecture Framework

The first section of this series discussed the problems of today’s IT landscape. The sectioned described how the tight coupling between IT applications was responsible for inflexible IT processes and inefficient application integration. With Service Oriented Computing (SOC), the applications are assembled as Services that communicate with one another using accepted communication standards. Services are autonomous and implement only the business logic but do not concern themselves with process flow or data transformation logic. In order for the loosely couple services to communication with one another, and architectural framework is required. A Service Oriented Architecture SOA is an infrastructure framework that enables autonomous, loosely coupled services (with defined interfaces) to communicate with one another without point-to-point calls between any of the services. It enables internal and external system integrations and the reuse of application logic by enabling the composition and orchestration of services. SOA Service Oriented Architecture offers a complete paradigm change away from the object-oriented client/server paradigm in which very fine grained objects communicate with one another. On the basis of a Service Oriented Architecture SOA, loosely coupled services communicate with one another only indirectly, on a high level and through standardized documents. SOA Service Oriented Architecture facilitates the flexible design of business processes and the agile IT implementation of these processes and “composite” services.

Components of an SOA Service Oriented Architecture

In order for loosely coupled services to communicate with one another (by exchanging standardized documents) and in order to execute the services in the appropriate flow, an Service Oriented Architecture SOA consists of two base components: The Enterprise Service Bus (ESB) is responsible for the message distribution and the Service Orchestration Engine (SOE) is concerned with the flow of the business process. Both components work in together in tandem to accomplish the communication between loosely coupled services in a defined process flow.

Web Services (WS) communicate with one another (as shown in the diagram above) in a loosely coupled manner with each WS not “knowing” to which other WS it sends messages or from which WE it receives messages from. To accomplish this, the ESB utilizes an Publish/Subscribe principle in which service clients never directly call the service providers – they don’t even “know” that the providers exist! Generally, the service client sends a message document with all of the data it deems as “relevant” (so that the Service Provider can do its business function) to the ESB. The Service Client registered with the ESB as a Document Publisher and provided the ESB with its document schemas. In order for a service provider to receive documents from a client (via the ESB), it must register with the ESB and subscribe to all of the client documents (schemas) that it is intended to receive. This means that the service provider requests from the ESB to send it all documents published by the clients to which the provider subscribes. Due to existing document standards (XML and schema standards), the service provider can programmatically parse this document and exe-cute its business functions using the extracted data. The Service Provider (publisher) also registered its output schema with the ESB and the Service Client registered as a Subscriber to this same document (in order to receive the response from the provider). The service publisher produces a resulting XML document (with a published schema) and sends it to the ESB, which then sends the document to all services that subscribe to the document. The publish/subscribe principle enables services to communicate with one another in an indirect manner through an ESB. Therefore, the services are loosely coupled because the service client does not “know” which service it is calling and the service provider does not “know” which service it is being called by and to whom the service results are being sent to. But, the services are still not totally loosely coupled because the service publisher must “know” the document schema of the service client and vice versa! This problem is solved by a SOA infrastructure in the following manner: Services register as clients or publishers and provide their document schemas. For every schema published to the ESB, there is a standard schema (also called a Canonical Schema) defined in the ESB. The ESB contains an XML Document Translator that translates all published documents into the appropriate canonical document. The is accomplished using a translation document (XSLT in the XML standard) that contains data translation information. Using this mechanism, a service publishes its output document to the ESB which translates it to a canonical document (using an XSLT document). The ESB then uses additional translators to translate the canonical document to the input documents of all services that subscribe to the document. Up to this point in the article, it is still unknown how the flow of the service communication is accomplished. Using only an ESB, when several services subscribe to the same schema, all of the subscribers will now always receive the document (which is not the desired outcome).

In the example Order Process introduced in the first section of this series, both the “Approval” and “Order” services subscribe to the “Purchase Request” document.

In the ESB scenario described above, both of the subscribing services would always receive the Purchase Request document each time it is published. This is why the ESB must work together with a Service Orchestration component that informs the ESB when to send the appropriate documents based upon business conditions. The diagram below illustrates how the flexible Order Process is implemented within a Service Oriented Architecture SOA Environment in which the ESB and Service Orchestration Engine (SOE) work in tandem:

The SOE receives a canonical document from the ESB which contains specific variables (x and y) that are used to determine the flow of the process. The SOE determines which services are to be call next based on the evaluation of the business rules in the process model. Once the appropriate services are determined but the SOE, it sends a message to the ESB informing it which services are to be called next. In the example “Order Process” the SOE informs the ESB to call the “Order” service if the variable x <= 1000 or it informs the ESB to call the “Approval “ service if the variable x > 1000. Although both of the services subscribe to the same schema (document), only one of the services actually receives the document upon completion of the Purchase Request service. The diagram also illustrates how the document flow and document translation works. It is important to remember that the Service Orchestration Engine never communicates directly with the physical web services, rather through logical service endpoints that receive the canonical documents. In order to quickly develop easily changeable applications and processes on the basis of a Service Oriented Architecture, a SOA development environment is required consisting of many tools that the concepts described above can be achieved without heavy coding, but instead with simple configurations! This includes a tool that makes it possible to create process models that can be interpreted by the SOE as well as a tool to create business rules used within the processes. The example “Order Process” contains two business rules that must be defined: Rule 1 – Approval Required: when x>1000 and Rule 2 – Approved: when y=ok.