The intent of this article is to define an Enterprise Service Bus (ESB) that can be created to support any Service Oriented Architecture (SOA) adopted by an organization. The type of ESB required could vary and as there is no "one size fit all" option available. Therefore this article defines mechanisms available that could be adopted to implement any ESB.
Enterprise Service Bus is an evolving integration architecture pattern used to integrate different incompatible business systems. This would mean that different business systems would have a uniform mechanism to communicate across environments. Thereby any new systems would have to only "plug" into the ESB and the task of transferring information is done. In comparison, systems that do not possess these capabilities and require communication to be done by creating unnecessary adapters and for every new system would mean recreating the process again and again. This increases the cost of development as well as increased turnaround time. Therefore many organizations leave some of these crucial tasks to the individual teams and these teams, based on the level of complexity, may decide not to do it or provide some temporary mechanism. Adopting ESB would change this attitude since it would become a standard framework and teams could find improved benefit for the business as well as ease of use.
So, what is ESB? This is a question quite often asked and there are several answers bandied about. But the gist of ESB is that it should provide a standard routing mechanism for a loosely coupled asynchronous service oriented architecture (SOA). It would also allow complex transformation of the messages as needed as well as provide an interface to integrate across different non standard interfaces.
IMAGE FIG 1 TO COME
Figure 1: Diagram showing an ESB with different services connected in a message flow.
Different services exist across environments but letting these services communicate is a critical task across enterprises. Each of these services would provide a message that is required by some other service. This would mean that these messages have to be transported to these services asynchronously as well as provide a high level of fault tolerance. Moreover any new service should be able to subscribe or be able to publish using the existing service bus without creating a new transport mechanism.
Today it is possible to provide a standard message with XML and SOAP. Most systems can provide a SOAP message and non standard system can be tweaked to provide a SOAP message. In this article I would refer to services that provide a SOAP message and not so much with the non standard systems. Additionally there is also new WS-* specifications which are now available for most systems to use. This article would be consuming SOAP messages containing the WS-* standards as part of the payload.
SOAP and WS-*
SOAP stands for Simple Object Access Protocol. It's a light weight protocol for exchanging structured information. This article will not delve into it since it's a W3C recommendation and there are lots of articles describing it. The basic structure of a SOAP message would be as shown figure 2.
<env:Envelope xmlns:env="https://www.w3.org/2003/05/soap-envelope"> <env:Header> <!-- Any header information --> </env:Header> <env:Body> <!-- Any information --> </env:Body> </env:Envelope>
Figure 2: Basic structure of a soap message.
Every SOAP message must be enclosed within the Envelope tags. The Header would contain any contextual, processing and or security information. The Body would contain the actual payload of the message.
WS-* are web service specifications. Theses are a set of specification that is part of the recommendations from the W3C. Some of the specifications are WS-Security, WS-Routing (WS-Addressing Microsoft Only), WS-Referral, WS-Timestamp etc.
WS-Security is specifications for security.
All the systems that wish to use the ESB must provide SOAP message. These SOAP messages are provided to a Request / Response stubs. The stubs could be a combination of MSMQ, File drop, database or web services. This would mean the service bus should be able to read/ write of the different types of stubs.
Reading from stubs can be achieved by a background process that constantly monitors the read stub to obtain the message. After the message is read and is now in the bus the message should be routed to the appropriate location. There is several routing mechanism.
- Itinerary-Based Routing.
Itinerary based routing mechanism is when a message would contain a list of addresses it would need to visit. This list is in the metadata and is carried with the message. The service bus would have several end points and this message would visit each location and is forwarded on by their invocation mechanism as shown in figure 3. This would mean there is no central routing mechanism each end point reference determines the next step. The benefit is the routing is distributed and hence a dependence on centralized routing is eliminated and single point failure is prevented. Thus each end point reference could have its own set of write stubs. Moreover each of the stubs can have lesser number of services subscribed to it. The messages would take longer to complete. This is analogous to routers in a network and hence a packet can hop from one router to another. There are added benefits of having several different endpoints at times with specialized endpoint each with different levels of orchestration. These messages can also be modified at different end points. It increases the flexibility and specialization of the service bus.
IMAGE FIGURE 3 TO COME
The example message shown in figure 4 carries list of locations that the message would pass through in its progress to the final destination.
Figure 4: Message from the sending service
After the message passes through the order service the message would change and can be as shown in the figure 5 below. As the message leaves the order location it adds an optional attribute vid which indicates the path it needs to take on its return.
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> <m:path xmlns:m="http://schemas.xmlsoap.org/"> <m:action>http://myServer/service</m:action> <m:to>soap://sale.com/endpoint</m:to> <m:fwd> <m:via>soap://order.com</m:via> <m:via>soap://pricing.com</m:via> </m:fwd> <m:rev> <m:via/> </m:rev> <m:id>uuid:A034C795-3DE7-49f0-AD03-505BD09437C1</m:id> </m:path> </S:Header> <S:Body> ... </S:Body> </S:Envelope>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> <m:path xmlns:m="http://schemas.xmlsoap.org/"> <m:action>http://myServer/service</m:action> <m:to>soap://sale.com/endpoint</m:to> <m:fwd> <m:via>soap://pricing.com</m:via> </m:fwd> <m:rev> <m:via/> <m:via m:vid="cid:[email protected]"/> </m:rev> <m:id>uuid:A034C795-3DE7-49f0-AD03-505BD09437C1</m:id> </m:path> </S:Header> <S:Body> ... </S:Body> </S:Envelope>
Figure 5: Message at intermediary location.
2. Content based routing.
IMG FIG 6 TO COME
Figure 6: Content based routing.
Content based routing mechanism is when a message is routed based on it content. The content is evaluated by XPath expression. The message is then forwarded to the appropriate end point. A misnomer in content based routing is the assumption that the actual body of the message is evaluated. This can be done but the usual mechanism in the real world is to evaluate the statement in the header that can contain the routing information based on which the message is sent to the appropriate end point. The routing mechanism is a central router that evaluates each message and takes the necessary action to emit the messages to the endpoints.
The example shown in figure is an example message for a content based routing where the message could be evaluated for the expression //saleProceeds/process and if found valid would then be routed to the appropriate destination based on services that have subscribed for this message.
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> <m:path xmlns:m="http://schemas.xmlsoap.org/"> <m:action>http://myServer/service</m:action> <m:to>soap://saleProceeds/process</m:to> <m:id>uuid:43F8BBC6-4FA9-4b87-B7EE-649FD801A8BE</m:id> </m:path> </S:Header> <S:Body> ... </S:Body> </S:Envelope>
Figure 7: Example of a typical message used in content based routing.
The benefit of a Content Based Routing is that there is a centralized mechanism for all the routing. The disadvantage is this can be a single point of failure. But aside from this disadvantage the benefits of single point of maintenance and also the messages can be totally ignorant of its end point are the added advantage. Moreover, when messages flow across, it can be sent to all the subscribers and if there is a failure at any end point references it can be quickly and easily identified.
The routing mechanism adopted depends on the system in use as well as careful evaluation of the existing systems in the organization and the resources available. If the existing systems are a conglomerate of various systems handled and maintained by various autonomous units including external units then an Itinerary based approach would be better. This is because then a central support unit need not be provided. The only problem would be the responsibility to maintain a fault tolerant environment at each end point is critical. Therefore if a message fails at one end point then effective support mechanism should be available to provide alternate routes for the messages in transition. Moreover the header would also carry other information such as to proceed or not if the message fails at an end point reference. This system will cope well in case where the message may have to be modified based on changing scenarios at each end point.
The decision to use any particular mechanism should not be based on the technology or the systems available but should be more of a domain problem. Essentially it's in the domain that all the applications are tightly coupled and hence increased dependency between the applications.
This would mean the domain could be functional or application domain. Functional domain is when different functions in the business domain are dependant on each other say sales and pricing in an e-business application. Application domain is where different applications could be within the same functional domain and are intricately dependant on each other.
In a functional domain when there is tight coupling the difficulty arises when each of the functional area is hampered from moving forward unless the other changes or is acceptable to the change. This is like a three legged race where nobody moves without the other moving. Therefore these types of systems are good candidates for SOA. After they are made SOA compatible the question is the type of ESB that needs to be adopted to fulfill the loose coupling by providing an effective service broker. In such a system a content based routing mechanism is well suited. The reason for this is that the ESB system can be built independent of the functional area. Therefore the development teams for each functional area would not have to have to develop any special mechanism other than subscribing to a service. Adding new systems is easy and hence more functional areas can collaborate on their terms.
In the application domain each of the applications have specific needs and is usually tightly integrated compared to functional domains. The level of integration results in systems which are often too tightly coupled. Hence a system A could be coupled with system B and another system C could be dependant not only on B but the resultant relationship between A and B. Such complex dependency results often in spaghetti type coupling between all the applications. Therefore any change to one system results in unknown reactions occurring in systems that were not even directly dependant. Maintaining such a system becomes unbearable and finally total abandonment of the application or patch works that fails every day.
For such a system where such a complex relationship exists in dependency where primary as well as secondary dependencies are seen the better mechanism to adopt is iteration based routing. This would give the benefit of messages being routed not only across primary but also secondary dependencies. But establishing such a system would result in heavier technology build up at each of the endpoint references since they are now more aware of their dependencies. The advantage is that each of the systems knows the system that they have to route the message. They can also change the message in transmission. Since they are not tightly coupled to each other any system can change its implementation as long as they maintain the loosely based contract between the systems.
Every system has contractual obligation to other systems since no system works totally isolated. This is even more in the case of SOA systems using the ESB. Therefore an acceptable message conforming to the correct format of the message has to be planned and designed appropriately. This contract is usually an XML schema and as long as all the systems accept this contract they could change any part of their application without fearing short term or long term implication of the change.
XML schemas are W3C recommendation. Today most applications understand the schema and hence rampantly used. A schema is a way of type identification for XML documents. Therefore it is a point of validation for the messages that are of the XML format.
The schema language contains native datatypes that match with the datatypes of the programming languages. Custom types can be defined which are denoted as complex types which can contain several native types referred as simple types. Moreover they also have the inherent capability of reuse by referencing to other schemas.
Shown in figure 8 is an example of XML Schema that contains both a simple type and complex type. Restrictions can also be added to it as needed.
<xs:element name="salesorder"> <xs:complexType> <xs:sequence> ... ... </xs:sequence> ... </xs:complexType> <xs:simpleType> ... </xs:simpleType> </xs:element>
Figure 8: Basic structure of XML Schema.
This capability of reusing as well as referencing schemas, help in creating a hierarchy of schemas that can be used at appropriate levels polymorphically. Therefore a business document can be evaluated either at the parent or at the child level depending on the business rule. The schemas can also be used in translating these messages into relational data and stored as needed.
This article will not delve into the major aspects of a schema but in terms of the ESB only messages that satisfy this contract is acceptable as shown in figure 9.
IMG FIG 8 TO COME
Figure 9: Service to service contract.
The benefit of a loosely coupled system has a disadvantage in terms of debugging the system. But this can be corrected by developing mechanism that enforces accountability into the process.
Enterprise Fault Tolerance
The percentage of Enterprise Fault Tolerance should be maximized. This is also a major concern since the fault is not easily discovered in a loosely coupled system. Though fixing the problem is easier in a loosely coupled system. The need for identifying the fault lines and taking secondary measures to resolve the issues is important.
The analysis of such a system leads to two type of faults. They are business faults and system faults. Business faults occur when the parameters or operations have changed and hence either the sending service or the receiving service has changed or the business rules changed. System faults occur due infrastructure level failures which are usually purely technology related.
Business level fault can be prevented by refining the schema. The more refined the schema lower is the level of fault as well as higher chances of discovering any unexpected changes.
System level faults occur due to various reasons related to infrastructure. It could be a network failure which would mean that alternate support mechanism should be provided for minimal downtime. Quite often it's a timeout due to increased complexity of any of the feeder system or the ESB itself. This would mean that system would need re-architecting because this could be a serious design flaw. Re-architecting would be needed only for that portion of the system that has the problem and this itself is a flexibility of ESB where new systems can be added at ease as well as older ones can be transitioned out.
Business level fault is seen more in content based routing whereas system level faults are seen more in iteration based routing. Both type of faults can exists on both the systems. Therefore it is important consider this in the risk plan when developing the routing mechanism for the ESB.
For this simple reason its necessary to have some collection mechanism for these faults that can occur as well as anticipate these faults and develop automated mechanism to handle these faults. Every fault may not be handled this way but at least majority should be handled automatically by the system in place.
Some of the failure scenarios that can be handled by the ESB are -:
- Destination cannot be reached.
This calls for the mechanism of storing the message and reattempt periodically until after a set number of tries the system notifies of its failure.
- 2. Message to large.
If the message to large it could result in buffer overflow or truncated message. Therefore mechanisms that can be adopted would be to verify the size of the message or have it as part of the contract. Thereby the sender can truncate the message send it in smaller chunks and the receiver is aware of such messages and takes appropriate action.
- 3. Message corrupted.
Sometimes the sender can send a message for some reason that is not correct. This could be verified by the schema in the ESB and then appropriate message send back to the sender to take necessary actions. Sometimes the actual data could be wrong. This cannot be identified by the ESB but this can be identified by the receiver based on business rules and notify the ESB of such a fault and hence the sender is requested to take appropriate action.
The ESB should be monitored from faults to performance of the system. There are typically two types of monitoring.
Monitoring ESB is as important as making it fault tolerant. The ESB can have another system that is an observer service that checks all the messages that flow through it. Anytime a fault occurs the observer raises an event to notify any systems subscribing to the service and it can then process the information appropriately. This pattern is called as QoS Observer as shown in figure 10.
IMG FIG 10 TO COME
Figure 10: QoS Observer
Yet another mechanism adopted is to have message header carries reference of every endpoint it visits as well as the starting destination as shown in figure 11. This would result in the history carried in the header being evaluated with the possible destination it should have traversed and if they do not match then appropriate mechanisms can be adopted to verify the problem.
IMG FIG 11 TO COME
Figure 11: Message History. The message carries end point references in its header as it passes through each service.
This mechanism is more suitable for itinerary based routing whereas the former is better suited for content based routing.
Monitoring the network is also an important task and this can be done by sending test messages that could be checked at a periodic intervals. The verification can be done on the time, load and authenticity of the test message transmitted. This is done because any messages from the services may not be accountable due to loosely coupled nature of the systems.
Building an ESB to support SOA is not a trivial task and architects must take into consideration the various possibilities as well as the risk involved in developing such a system More often the question should arise as to the nature of service that the ESB should provide and based on these factors a deterministic approach can be taken as to the mechanism to be adopted to satisfy the business need.