Enterprise Service Bus (ESB) technology can play the role of mediation in any Business Integration solution by performing a number of functions: content-based routing, transformation, validation, enrichment, and service invocation. However, as with any programming model, you can often implement the same function in different ways, with advantages and disadvantages for each approach. How then do you decide which approach to implement? This series of articles will evaluate the different approaches and design issues that you need to consider when you design an ESB solution using IBM® WebSphere® ESB.
This first article examines the different ways to perform content-based routing and service invocation.
Designing your mediation flow
Performing routing and service invocation is a major function of an ESB. Content-based service routing via the ESB frees a service requestor from knowing where a service is located, or which service receives the request. The service destination is determined in the ESB by inspecting the request message, and performing appropriate mediation logic. What is the best way to invoke a service? Before you choose, consider the requirements that may impact the mediation flow design:
- Routing based on application content or context
- Sometimes it is sufficient to make the routing decision based on the request body, but in some ESB scenarios, the routing decision must be made from context information in the transport headers, or from information received from other services. The mediation programming model gives the flow developer the logical structure of the invocation message. Primitives enable the user to manipulate the message (both payload and headers) and route it to the appropriate service. See below, Usage pattern 1. Using the result of one service to invoke another service.
- Dynamic or static binding
- Do you always want to invoke the same service? For example, if you are looking at trace logs for problem determination, you don't want the trace to be different with every invocation. Do you require the ESB to determine the service at every invocation? See below, Usage pattern 3. Static and dynamic selection of service endpoints.
- Other services that need to be invoked to route the request message to a final destination
- See below, Usage pattern 1. Using the result of one service to invoke another service.
- Accessing non-Web Services applications dynamically, such as back-end ERP systems or databases
- See below, Usage pattern 7. Dynamically invoking non-Web services endpoints.
Examples of content-based service invocation and routing
Content-based service invocation is a key function of WebSphere ESB, and can be used in almost any integration solution. Here are some situations in which you might route a message by inspecting its contents:
You can select the service to invoke based on everyday business requirements, such as:
- Sending a booking request from a travel Web site to a booking agent selected by the customer.
- Selecting an appropriate financial service based on customer information. For example, selecting a basic or premium stock quote service depending on the customer subscription level.
- Selecting different order processing systems based on information received from the order.
You can use content-based routing to solve IT requirements, such as:
- Selecting the server destination based on information contained in the message. For example, the message body may contain access information for a specific server (hostname).
- Using the error handling situation defined in the message body to select the correct behavior.
Usage patterns for content-based service invocation and routing
Besides invoking a service via a callout node, you can also invoke a service inline in a mediation flow. The usage patterns below describe how to invoke an intermediary service, and different ways that you can process the result returned by the service.
Usage pattern 1. Using the result of one service to invoke another service
Typically, WebSphere ESB mediation flows intercept and modify messages that are passed between existing services (providers) and clients (requesters) that want to use those services. In a mediation flow, the request message travels through a chain of mediation primitives that processes it in various ways until the message reaches a callout node associated with a service provider. Message processing at each primitive is not limited to built-in processing logic; primitives can also use services that are external to the mediation flow.
WebSphere ESB V6.0.2 provides a Custom Mediation primitive that you can configure to invoke an external service. Unlike a callout node that is always the last node in a request flow, a Custom Mediation can invoke a service at any point in the flow, and the result of invoking the service is returned to the same flow. You can use the result of invoking a service in the middle of a mediation flow for further processing, either to augment the original request message, or to make routing decisions.
These usage patterns are illustrated below:
Service as message enhancer
The result of invoking an intermediary service is combined with the original request message to invoke the ultimate service provider being mediated. Consider an example in which the ultimate service provider requires certain security headers, as shown below:
Figure 1. Service as message enhancer
First, using an XSLT primitive, the current request message is saved in the transient context and a request for the security service is prepared. This new message is then passed to a Custom Mediation that is configured to invoke the security service and obtain security credentials. Using another XSLT primitive, the security information returned from this invocation is combined with the original request message from the transient context to produce a new message for the mediated service provider. For example, the security information could be set into the SOAPHeader structure available in the Service Message Object (SMO).
This pattern is similar to using a Database Lookup primitive. The main difference is that here, the message is augmented with data obtained by invoking a service instead of by looking it up in a database table.
Service as routing data
The result of invoking an intermediary service is used to route the message to one of many service providers. A typical example is when an incoming message request is first sent to a service that provides quality of service data, and then, based on this data, the message is routed to the appropriate service providers. Consider the following flow:
Figure 2. Service as routing data
The QoS service returns quality of service data, which is part of the input message to the Message Filter primitive (labeled Router). This primitive inspects this data and routes the message to one of the two services based on the quality of service.
Usage pattern 2. Using the result of a service to implement another service
The invocation patterns described above invoke an ultimate service provider at the end of the flow, even though an intermediary service was invoked in the middle of the flow. You can also use mediation flows to implement a service provider pattern. Basically, you can bypass the ESB callouts and invoke other service providers directly, using Custom Mediations. Unlike the above scenarios with service invocation in the middle of the flow, as an intermediary, in this pattern, service invocation is done at the end of the flow, and the result is sent to the client via the Input Response node:
Figure 3. Using the result of a service to implement another service
In this example, the input message is routed to one of the two providers. The result from each service provider, implemented as Custom Mediation service invocations, is then wired to the response node, so that the result is returned directly to the client that invoked this mediation service.
Sometimes the service result is not important for the flow, but the act of invoking the service is important. A message is sent to a service in the middle of a mediation flow, but no response is received, and no further processing is done as a result of this invocation. This pattern is called "Fire and forget," and can be used when something needs to be logged outside the mediation flow. Basically, the flow acts as a notifier or a service trigger.
Usage pattern 3. Static and dynamic selection of service endpoints
Unlike in the previous section, where service invocation patterns are intermediary (custom mediation) nodes in the flow, this section describes service invocation using callout nodes -- routing to the ultimate service provider being mediated.
WebSphere ESB provides two mechanisms for invoking such a service: static and dynamic:
- The message is routed to a pre-defined endpoint address that is hard-wired in the module. At development time, you need to know the address of the service you are invoking. You can change the endpoint at runtime from the admin console.
- The message is routed to an endpoint address that is determined by the mediation logic at runtime, based on a condition or property in your flow. At development time, you need to know the port type or interface of the service you are invoking. The service can be changed at runtime without affecting the application. In WebSphere ESB, you can do dynamic routing in two ways:
- A service endpoint is retrieved from WebSphere Service Registry and Repository by using an Endpoint Lookup primitive.
- A service endpoint is retrieved from a database by using the Database Lookup primitive.
Let’s look at how we might use the different ways to invoke a service. Consider the example of a financial services company that offers tiered levels of a stock quote service, depending on customer subscription level. If the subscription level is premium, the request for a stock quote is routed to a real-time service; otherwise the request is routed to a service that responds within 20 minutes.
Stock Quote: Static service invocation
Two service providers, RealtimeService and DelayedService, are defined in the mediation flow. The customer subscription level is retrieved from a database and used to determine which service to invoke. The chosen service is invoked statically, using the address specified in the import binding. This is a simple integration of the services, and does not require any infrastructure. The static stock quote is hard-coded for two service levels only, and accommodating a new service level or a change in service address would require you to change the flow.
Figure 4. Stock Quote: Static service invocation
In this example, a Database Lookup primitive (Lookup), queries a customer database for the customer subscription level, and updates the message correlation context with this information. The updated message is passed to a Message Filter primitive (Filter), which routes the message to one of two services depending on the subscription level. The XSLT primitives transform the message to the format required by the invoked service. The service is invoked statically from the callout node, using the address specified in the import binding.
Usage pattern 4. Dynamic service invocation using a database
In this usage pattern, the customer subscription level is retrieved from a customer database, and used to retrieve the service address from a service endpoint database. The service address is placed in the message, and the service is invoked using the retrieved address. With the Endpoint Lookup primitive, all you need to do is specify the query, whereas with the Database Lookup primitive, you need to specify the service address.
You can change or replace the service address in the database at any time without affecting the flow. You can also add subscription levels and their associated endpoints without changing the mediation flow. If you don't have the WebSphere Service Registry and Repository product, this procedure is a good alternative, as you can use CloudScape or another relational database to store your endpoints. This solution provides flexibility, but you can retrieve only one service endpoint, and it also introduces the overhead of managing the databases.
Figure 5. Stock Quote: Dynamic service invocation using a database
In this example, a Database Lookup primitive (CustLookup) is used to retrieve the customer subscription level and place the subscription level in the message. Another Database Lookup primitive, URL_Lookup, then retrieves the service address from a database based on the subscription level, and places the retrieved address in the message’s target element. An XSLT primitive transforms the message, and the service is then invoked using the address retrieved from the database.
Usage pattern 5. Dynamic service invocation using WebSphere Service Registry and Repository
The customer subscription level is retrieved from a customer database, and the subscription level is used to query WebSphere Service Registry and Repository. The retrieved service address is placed in the message, and the service is invoked using the retrieved address. With the Endpoint Lookup primitive, all you need to do is specify the query, whereas with the Database Lookup primitive, you need to specify the service address.
As with the database lookup, you can change or replace the service address at any time without changing the flow. However, the endpoint lookup query to WebSphere Service Registry and Repository provides more flexibility, as you can retrieve one service endpoint or a number of endpoints, and can then perform further processing to select one of the retrieved endpoints. In addition, WebSphere Service Registry and Repository provides a full life-cycle management of service registration and discovery.
Figure 6. Stock Quote: Dynamic service invocation using WebSphere Service Registry and Repository
In this example, a Database Lookup primitive (CustLookup) is used to retrieve the custom subscription level and place it in the message. An Endpoint Lookup primitive (EPL_Lookup) then uses the subscription level to query WebSphere Service Registry and Repository for the service address, which is automatically placed in the message's target element. An XSLT primitive transforms the message, and the service is then invoked using the address retrieved from WebSphere Service Registry and Repository. In this example, a single endpoint that matches the query is retrieved. You can also retrieve all endpoints that match the query, and then perform further processing to determine which service to invoke.
Usage pattern 6. Invoking services in a different module
Another useful WebSphere Integration Developer/WebSphere ESB pattern is to have a mediation flow invoke services exposed by other modules, including mediation modules. For example, an adapter can first be wrapped as a service using an SCA module, and you can then easily access messaging endpoints through the SCA endpoints. In Figure 7 below, an SCA module is created for an SAP adapter, and the exported service of the SCA module (Invoke_SAP_Endpoint) is mediated by a mediation flow. You can use this pattern to invoke another mediation service from a mediation flow and it is especially useful if your scenario requires dynamic invocation of modules in the future (See below, "Usage pattern 7.")
Figure 7. Invoking SAP adapter module
Usage pattern 7. Dynamically invoking non-Web services endpoints
In a heterogeneous business infrastructure, you often need to dynamically connect to different back-end systems using various protocols. The current version of mediation flows cannot directly consume adapters from WebSphere Service Registry and Repository. Using the pattern discussed above, you can wrap the adapter as a service, register the SCA module in WebSphere Service Registry and Repository, and then invoke the module dynamically.
The Endpoint Lookup primitive in a mediation flow is designed to dynamically query different types of documents from WebSphere Service Registry and Repository. Figure 8 shows the use of WebSphere Service Registry and Repository and the endpoint lookup primitive in WebSphere Integration Developer V6.0.2:
Figure 8. Dynamically invoking non-Web services endpoints
WebSphere Service Registry and Repository does not currently support directly registering adapters, JMS, or MQ endpoints. One way to enable this requirement is by using SCA modules as endpoints, and dynamically selecting the modules from WebSphere Service Registry and Repository. In Figure 8, module 1 and module 2 represent SCA modules that contain definitions for various adapters and messaging endpoints. The goal is to upload these SCA modules into WebSphere Service Registry and Repository and let it dynamically pick the SCA endpoint of one of these modules, based on the query criteria passed from the client. In WebSphere Integration Developer, the query that will determine which module is selected is configured in an Endpoint lookup primitive. In Figure 6, the red dotted line represents the endpoint lookup primitive in WebSphere Integration Developer.
This article described usage patterns and design considerations for invoking services based on message content, in order to help designing ESB solutions using WebSphere Integration Developer and WebSphere ESB. The authors had lengthy discussions on how much detail to include for each of the concepts, and decided to focus more on the general approach and design, as opposed to detailed step-by-step instructions. For detailed information on how to implement the patterns described above, see Resources below.
In the next article, we will discuss some advanced concepts around two important aspects of any ESB solution: content transformation and enrichment.
- Callout node
- The callout receives the message and invokes the requested service and operation. There is a callout node for each connected target operation in the mediation flow. If you invoke a service statically, you must have a corresponding import in the mediation module for each callout. When the callout is fired, the message is routed to the service address specified in the import’s binding. If you invoke a service dynamically, you must enable the Use dynamic endpoint property. This property is enabled by default. For more information, see selecting endpoints dynamically.
- Content-based routing and service invocation
- The mediation flow processes the content of a section of the message, and based on the content, determines the subsequent flow path of the message, or the service invoked. The section processed can be the request body, headers, or context information of the message.
- Correlation context
- The section of the SMO that contains the business object that is persisted through the duration of the request and response flows. It is used for passing values from the request flow to the response flow. For more information, see Storing and using properties in the message context.
- Database Lookup
- The Database Lookup primitive enriches the message using data retrieved from a database.
- Endpoint Lookup
- The Endpoint Lookup mediation primitive queries the WebSphere® Service Registry and Repository and retrieves service endpoints, which it places in the message context. The retrieved endpoints can then be used to dynamically invoke a service.
- Mediation flow
- A sequence of processing steps that are executed when an input message is received. A mediation flow is created in the mediation flow editor by including a number of mediation primitives that define a processing step. The connections between the mediation primitives determine which processing steps are carried out and the order in which they are carried out.
- Mediation primitives
- A basic interface or programming element that can be used to build mediation flow components. Mediation primitives accept messages and process them by performing actions such as routing or transforming. Mediation primitives are connected together to execute the logic of a mediation flow.
- Message Logger
- The Message Logger primitive logs messages to a database.
- Message Filter
- The Message Filter primitive conditionally routes messages based on the results of pattern evaluation. A pattern is evaluated against the message, and if the result is true, the message is propagated to a terminal associated with the pattern. The Custom Mediation primitive allows you to implement your own mediation logic using Java™ code, or to call an import in the same mediation module.
- Service message object
- A message is a communication sent from one application or service to another application or service. Messages in mediation flows are represented as service message objects (SMOs). Service message objects are enhanced business objects that include the application data and header information related to the transport protocol used to invoke a service such as SOAP or JMS. A service message object is composed of a body that contains the application data (also known as the payload or operation message) in a business object, and headers containing additional context information. For a detailed description of the SMO structure, see SMO structure.
- Transient context
- The section of the SMO that contains the business object that is available for the duration of the current flow (either the request flow or the response flow). It is used to pass values between mediation primitives in the same flow. For more information, see Storing and using properties in the message context.
- XSL Transformation (XSLT)
- The XSL Transformation primitive transforms message formats between source and target operations, or changes the content of a message. The primitive uses an XSL style sheet to map between the source and target message types.
WebSphere Service Registry and Repository information center
A single Eclipse-based Web portal to all WebSphere Service Registry and Repository documentation, with conceptual, task, and reference information on installing, configuring, and using the product.
IBM Redbook: WebSphere Service Registry and Repository Handbook
This Redbook describes the architecture and functions of WebSphere Service Registry and Repository along with sample integration scenarios for implementing the product in an SOA environment.
Introducing WebSphere Service Registry and Repository
This two-part article series describes the main concepts and capabilities of WebSphere Service Registry and Repository and explains its role throughout the SOA lifecycle.
WebSphere ESB developer resources page
Technical resources to help you use WebSphere ESB as a flexible connectivity infrastructure for integrating applications and services to support an SOA.
WebSphere ESB product page
Product descriptions, product news, training information, support information, and more.
WebSphere ESB information center
A single Eclipse-based Web portal to all WebSphere ESB documentation, with conceptual, task, and reference information on installing, configuring, and using WebSphere ESB.
WebSphere ESB documentation library
WebSphere ESB product manuals.
WebSphere ESB FAQs
Basic questions and answers about the new WebSphere ESB product and its relationship to other WebSphere products.
WebSphere ESB support
A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
Dynamic routing improvements in WebSphere Enterprise Service Bus V6.0.2
Learn how the dramatic improvements in dynamic routing at runtime in WebSphere ESB V6.0.2 can enhance your SOA solutions.
Getting started with WebSphere Enterprise Service Bus and WebSphere Integration Developer
A technical introduction to WebSphere ESB and its accompanying tooling, WebSphere Integration Developer. This article describes how to: 1) develop a mediation flow providing a basic Web service; 2) develop an intermediate flow, to connect to this service, with more complex routing logic provided by pre-built mediation functions; 3) deploy and test these flows using both the tooling test facilities and a standalone JSP-based front-end.
Developing custom mediations for WebSphere Enterprise Service Bus
Learn how to create custom mediations using the WebSphere Integration Developer environment for WebSphere ESB. The article will walk you through the development of three types of custom mediations in a simple scenario.
Dynamic routing at runtime in WebSphere Enterprise Service Bus
Learn how to implement dynamic routing at run time for Web services (SOAP/HTTP and SOAP/JMS) in WebSphere ESB.
WebSphere Integration Developer developer resources page
Technical resources to help you use the WebSphere Integration Developer IDE to render your existing IT assets as service components, encouraging reuse and efficiency as you build SOA-based integration solutions across WebSphere Process Server, WebSphere ESB, and WebSphere Adapters.
WebSphere Integration Developer product page
Product descriptions, product news, training information, support information, and more.
WebSphere Integration Developer information center
A single Eclipse-based Web portal to all WebSphere Integration Developer documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Integration Developer environment.
WebSphere Integration Developer information roadmap
Roadmap of articles and resources to help you with installation, migration, administration, development, troubleshooting, and understanding the underlying technology.
WebSphere Integration Developer documentation library
WebSphere Integration Developer product manuals.
WebSphere Integration Developer support
A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
developerWorks WebSphere Business Integration zone
For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
WebSphere Business Integration products page
For both business and technical users, a handy overview of all WebSphere Business Integration products
Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products.
Trial downloads for IBM software products
No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
Technical books from IBM Press
Convenient online ordering through Barnes & Noble.
developerWorks technical events and Webcasts
Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.