Chapter 12. ESB as SOA Infrastructure
12.1 Basic Traditional Messaging Frameworks
12.2 Basic Service Messaging Frameworks
12.3 Common ESB Features Relevant to SOA
A standard service development platform, such as a Web services stack or an API design and runtime stack, may no longer be enough to support the complex infrastructure requirements in a larger contemporary services ecosystem. In a heterogeneous environment, connecting applications together that use different communication protocols, message formats, or implementation technologies creates loosely coupled composite systems, requires building services out of existing assets, and warrants the delegation of system-level concerns to an infrastructure component.
System-level concerns include, but are not limited to:
• Messaging – to send and receive synchronous or asynchronous messages
• Mediation – to inspect, transform, or apply specific routing as part of message handling
• Application Integration – to connect disparate and heterogeneous applications
• Service Composition – to compose services from existing applications or a set of services, which include both REST and SOAP-based services
Although ESBs are not required for building SOA-based applications, they can be used to address a number of SOA infrastructural concerns. This chapter provides a basic overview of typical service infrastructure issues faced by IT organizations to illustrate how an ESB implements a combination of messaging, mediation, service hosting, and application integration techniques in support of service-orientation design principles.
Note
If you are already familiar with ESBs and their role within fundamental service infrastructures, you can skip this supplemental chapter.
12.1 Basic Traditional Messaging Frameworks
Service consumers communicate with services via remote procedure calls, messaging, file exchange, or shared data in databases. For online applications, as opposed to batch applications that process data in bulk at pre-determined time intervals like in a monthly statement generation process, RPC and messaging are often the only viable options.
For example, messaging can be implemented using a message queuing technology, such as WebSphere MQ or ActiveMQ, but can also be realized using REST-style HTTP services. Therefore, messaging in this context means that the service consumer and service send each other self-describing messages.
Messaging can help applications achieve loose coupling. Basic messaging engines can be unsuccessful in meeting sophisticated message routing and transformation requirements. ESBs resolve this gap by acting as sophisticated messaging frameworks offering extensive support for configuration-driven message traffic management and transformation. For real-world applications, ESBs can be used as a messaging backbone.
RPC vs. Messaging
Created in the 1980s, remote procedure calls are the foundation for more heavily used technologies, such as RMI/EJBs in Java. Application integration traditionally relied on RPC and messaging techniques. However, a large IT environment containing numerous applications reliant on an RPC model of integration can result in a spaghetti architecture where each application must know about the methods, method parameters, and return values of other applications. As the number of applications grows, the introduction of a new system means many of the other applications must change to interface with the new applications by calling another set of APIs.
In Figure 12.1, applications communicate with one another by calling APIs offered by other applications.
The RPC method of integration exposes a fine-grained API. Each application must know the API details of each of the service operations offered by other applications to ensure the right function calls are made, which results in various types of tight coupling between the applications.
Technology Coupling
Applications communicating with one another via direct API calls are tightly bound at the technology level because of dependence on a common programming language, such as Java, or a specific application protocol, such as RMI or RMI/IIOP. In Figure 12.2, an EJB client calls an EJB service. Both are implemented on the Java platform with a tight degree of technology coupling. While a C++ application can use IIOP to communicate with a Java application, the scope of interoperability is limited by the widely varying nature of implementations.
Spatial Coupling
Each application must be aware of the intimate details of other applications’ API input parameters and return values. If any of these APIs change, the client applications must also change. In the absence of any infrastructure, service consumers are responsible for knowing at which network node services are available, without location transparency.
If services move to a different network node, the client applications must also change. In Figure 12.3, an application calls another application to retrieve customer information.
Temporal Coupling
In a blocking communication, the service consumer makes a service call and is blocked until a response is received from the service. If the service is unavailable due to a system outage, the service consumer is responsible for periodically retrying the service invocation until the service is back online. In some situations, temporal coupling can be unavoidable due to the synchronous nature of the interaction. However, the service consumer can at times proceed and perform useful computation without waiting for the response while the original request is still being processed by the service. In Figure 12.4, the service consumer fails when the service is unavailable.
Applications can communicate with one another by sending and receiving messages rather than by calling APIs. A protocol is agreed upon by the service and the service consumer facilitating the transport for sending and receiving messages. Additionally, a message infrastructure or messaging engine can provide the backbone necessary for applications to communicate with each other.
Messaging styles include the point-to-point and publish/subscribe methods illustrated in Figure 12.5.
Figure 12.5 Messaging-style integration follows common models of messaging, such as point-to-point (top) and publish/subscribe (bottom).
Most message queuing infrastructures provide facilities for the message sender and message receiver to function regardless of one being offline, in a method known as guaranteed delivery.
The message sender can send a message to a destination that is accepted by the queue, and carry on with other actions regardless of whether the receiver is online. The queue will reliably deliver the message to the receiver irrespective of possible failures at the network or application level.
Message delivery is guaranteed only after the message has been delivered to the messaging queue and it has acknowledged the receipt of the message. The Asynchronous Queuing pattern captures this feature-set within the context of SOA.
The use of messaging queues minimizes many of the coupling-related problems associated with the RPC-centric integration model. When applied to the different types of coupling, the use of messaging produces the following results:
• Technology coupling is minimized since the message sender and message receiver rely on the messaging infrastructure, not each other. The dependency is transferred to the particular messaging queue(s) used to send and receive the messages.
• Temporal coupling is removed in truly asynchronous interactions, as messaging queues do not require the message sender and message receiver application to be running simultaneously.
• Spatial coupling is reduced, as applications can communicate with each other by sending documents as messages that no longer require intimate knowledge of the methods used by other applications.
The document must still contain the correct data of the correct type, but how the document is interpreted by the receiving application is irrelevant to the message sender.
Figure 12.6 shows how applications implemented in different technologies can communicate with one another using messaging queues. Applications implemented in different technologies can communicate through messaging queues by exchanging documents as opposed to making method calls. The message sender application does not depend on the receiver application being operational at the time the message is sent. The message will be reliably delivered to the receiver when the receiving application comes back online.
Figure 12.6 Messaging queues reduce technology coupling, temporal coupling, and spatial coupling between applications.
Message Producers and Message Consumers
As messaging communication is unidirectional by nature, it is helpful to label applications with the message producer and message consumer roles when mapping message travel, irrespective of larger service composition activities.
In this section we’ll use the term message producer to refer to an application that produces a message and directs it to an outgoing destination. Similarly, we’ll use the term message consumer to refer to an application when it receives and processes the message at runtime. In a request/response MEP, the message producer issues a request message to the message consumer. The message consumer application then switches to the role of message producer to send back a response message.
Figure 12.7 illustrates these roles with both request/response and one-way MEPs.
Figure 12.7 Applications assuming message producer and message consumer roles in request/response and one-way MEP scenarios.
Note
The terms message producer and message consumer can be mapped to the terms service consumer and service. However, using both sets of terms within the same scenario description can be confusing. Note also that when tracing message transmissions across multiple point-to-point branches, the terms initial sender and ultimate receiver are further helpful in identifying the service consumer that initiates the transmission of a message and the service that ultimately receives it at the end of the message path.
Case Study Example
12.2 Basic Service Messaging Frameworks
We will now take a look at simple ESB messaging functionality within the context of service interactions by comparing how common message processing and transformation functions can be carried out with and without an ESB middle tier.
Basic Service Message Processing without ESBs
Designing messaging-based architectures is essential to establishing contemporary service-oriented architectures. This section addresses message routing and transformation processing for service-enabled, point-to-point messaging architectures that do not utilize a middle processing tier, as provided by an ESB. The subsequent Basic Service Message Processing with ESBs section provides the counterparts to the scenarios described in this section to highlight potential benefits of logic abstraction provided by an ESB. Figure 12.10 begins by showing a simple messaging architecture with a service consumer sending one-way messages to multiple services.
Figure 12.10 A basic messaging architecture involving one-way messaging between a single service consumer and three services. In order for the service consumer to successfully send each message, it must have logic that is coupled to each of the three service contracts.
Message Routing without an ESB
Each message producer is responsible for ensuring that the messages produced are directed at the appropriate recipient. Within a given message path, there may be service agents that automatically intercept and route messages or messages may be directed to services that themselves act as intermediaries and forward the message on further. To support the need for programs outside of the message producer to perform routing functions, messages can contain routing information within the message content. The routing of messages based on the contents of a message payload or message header is known as content-based routing.
Content-based routing, without the use of an ESB, requires that the routing logic be built into the message producer that generates the message with routing content (Figure 12.11). The result is an inflexible solution, as routing logic can often be subject to change, such as when it is based on business rules or other volatile conditions.
Figure 12.11 Content-based routing based on a business rule that determines the path of the message in relation to the value of the invoice document it contains. Because the messages are sent directly from the service consumer to the services, the routing logic needs to be embedded within the service consumer logic.
The routing of messages based on contextual information, such as the current workload on a particular system, is known as context-based routing. Similar to content-based routing, context-based routing logic is driven by rules and conditions that need to be embedded within the message producer if it is sending the messages directly to destination message consumers. As shown in Figure 12.12, this results in a comparably inflexible messaging architecture.
Figure 12.12 Context-based routing based on a runtime condition that determines the path of the message in relation to the value of the current load factor of a service. Because the messages are sent directly from the service consumer to the services, the routing logic needs to be embedded within the service consumer logic.
Message Transformation without an ESB
As already discussed during previous chapters, the need to carry out runtime transformation in order to overcome application or service disparity at the data model, protocol, or message format levels is sometimes unavoidable. When designing larger service inventories or when designing transformation points between disparate service inventories, the question as to where the actual transformation logic will reside needs to be carefully considered.
Figure 12.12 illustrates a seemingly simple approach whereby the transformation logic is embedded within the service consumer. The downside to this approach is that changes to the data, protocol, or format mapping that comprises the transformation logic will require direct programming updates to the service consumer logic. As with the aforementioned message routing approach, this results in a fragile messaging architecture.
Basic Service Message Processing with ESBs
The next two sections provide corresponding architectures that demonstrate runtime message routing and transformation functionality with the use of ESBs.
Message Routing with an ESB
The introduction of an ESB allows for message routing logic to be abstracted away from the service consumer into a middle tier in which routing functionality is established equivalent to the features resulting from the application of the Intermediate Routing pattern. This intermediary processing layer offers the following potential benefits:
• Flexibility – Service consumers do not require the details of the message destinations. The routing logic is moved the ESB’s routing agent from where it is also maintained through the use of front-end tools.
• Loose Coupling – New services and message destinations can be incorporated into an existing architecture by configuring the routing agent to include additional targets and routing conditions without affecting any of the existing interactions.
The middle tier established by the introduction of an ESB provides intermediary routing logic that supports both content-based routing (Figure 12.14) and context-based routing (Figure 12.15).
Figure 12.13 Exchanging message content based on different data models requires runtime transformation. In this case, the transformation logic is expressed in an XSLT stylesheet executed within the service consumer architecture on an XML document received from another source. The document contents are transformed and wrapped in a message format, prior to transmission to the service.
ESBs provide a configuration framework where routing policies can often be specified either in a declarative manner, such as with XPath statements or XQuery expressions, or via pluggable custom components.
Although the figures depict the ESB in a separate box between the service consumer and service provider, the ESB is only logically separate. Depending on the implementation style, the ESB can also be co-located at the service consumer or service. This distinction is the delineating factor in viewing ESBs as either a technology or product or as a design pattern (as per the Enterprise Service Bus compound pattern).
Message Transformation with an ESB
ESB messaging infrastructure provides intermediary transformation logic that can carry out the functionality established by the Service Broker compound pattern, which is comprised of the Data Model Transformation, Data Format Transformation, and Protocol Bridging patterns. Collectively, the feature-sets resulting from the application of these patterns provide the ability to carry out sophisticated runtime transformations that are centralized in the middle tier, from where they can also be centrally maintained via front-end tools.
Figure 12.16 shows how intermediary data format transformation logic provided by the ESB converts the format of one message into two others.
Figure 12.16 An ESB carrying out intermediary data format transformation logic is shown. A JMS message is converted into a SOAP message for Service A, which is a Web service. The same JMS message is converted into an HTTP message for Service B, which is a REST service.
Figure 12.17 illustrates an ESB providing centralized transformation logic for the runtime conversion of message content structures from one data model to one of two other data models, as required to comply with the respective destination service contracts.
Figure 12.17 Message transformation with a canonical data model within an ESB minimizes the number of transformations required.
12.3 Common ESB Features Relevant to SOA
This next section highlights functions relevant to service processing and service-oriented architectures that are provided by various contemporary ESB products.
Service Lookup and Invocation
A service consumer can select an appropriate service based on the information it retrieves from a service registry, such as functionality and quality of service. The service endpoint selection can be handled by an ESB mediation component which facilitates dynamic service selection.
The service endpoint selection can be handled by an ESB mediation component which facilitates dynamic service selection. If business rules change, the mediation component can change to select a different service endpoint rather than changing the service consumer. For example, an ESB mediation component can look up either a premium or regular subscription service based on the customer information obtained from the service consumer, as seen in Figure 12.18.
Figure 12.18 The ESB serves as a mediation component between a service and service consumer to help select an appropriate service endpoint.
Service endpoint selection can at times be an even more dynamic process with intermediate steps, such as database lookups, performed to locate an appropriate service endpoint. Many ESB implementations offer a mechanism where a custom mediation component can be plugged to perform the necessary computation before a service endpoint is selected.
Figure 12.19 Appropriate Loans and Mortgage service endpoints can be selected by an ESB mediation component from a service registry.
Service Processing
Generally, certain pre- and post-processing steps must occur before and after a business service is invoked. These steps are often unrelated to the core functionality offered by the service to handle non-functional aspects, such as auditing, security, and monitoring. The non-functional aspects are infrastructural in nature, and can be abstracted away from the core business logic of the service functions. For example, the service invocation pre-processing step of logging all service invocations for a premium service can be efficiently handled within a mediation component.
Sophisticated ESBs allow for a more general-purpose declarative composition of service pre-processors and post-processors, where they can be built to enhance a message processing cycle. The ESB can compose processors in a declarative fashion that allows for variation in the invocation sequence of the pre- and post-processing components by changing the configuration of the processors rather than the implementation code.
Examples of pre-processors include message enrichment, message encryption/decryption, and message de-duplication. Beyond providing the processors that developers must build. ESB mediation components facilitate an arbitrary composition of the processors in a declarative fashion.
Case Study Example
Figure 12.20 Business rule pre-processing or post-processing can be implemented or plugged in from mediator components in an ESB.
Service Composition Support
ESB frameworks support service composition by offering out-of-the-box support for integrating technology artifacts from different platforms programming languages, such as Java, C#, and Ruby. An ESB integrates a pre-existing session EJB component to send a message to a messaging destination, which is similar for calling a POJO or scripting language-based component. ESBs can further provide features that help string together a variety of service composition resources through declarative configurations, such as a specialized a domain-specific language.
Commercial ESB vendors often offer a GUI tool to help developers create a service flow. In keeping with a contract-first development philosophy, it is still recommended to leverage these components as implementation artifacts with their own service contracts that are used in a declarative language.
The runtime may choose to use an optimized platform native communication protocol, such as an in-memory call to a POJO, rather than calling a SOAP-based or REST service. To realize the service flow at runtime, the service composition framework brings together all the infrastructure capabilities, such as messaging, mediation, and application integration features.
REST API Management Support
Modern, lightweight ESBs can often act as a REST API management platform that functions as an enabler for connecting mobile Web applications to enterprise REST APIs. Often, these enterprise REST APIs are also wrappers over existing system interfaces. An ESB acting as an API management platform offers bridging capabilities between REST APIs and the back-end services.
An API management platform can mediate REST service interactions with interception capabilities for logging, auditing, and security checks, expose existing or third-party SOAP-based Web services as REST APIs for consumption from mobile devices (by bridging REST resources to existing services), and define API policies, such as security and SLAs. WSO2 is an example of a modern ESB product with API management features.