WebSphere Integration Developer and WebSphere ESB advanced topics, Part 1: Content-based service invocation and routing

This series of articles will evaluate the different approaches and design issues that you need to consider when you design an ESB solution. Part 1 describes 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.

Share:

Dorian Birsan (birsan@ca.ibm.com), Advisory Software Developer, IBM

Dorian Birsan is a Manager and Technical Lead at the IBM Toronto Lab, responsible for designing and developing Websphere ESB and Message Broker tools. His current technical interests are SOA technologies and finding simpler solutions to complex problems. You can contact Dorian at birsan@ca.ibm.com.



Allen Chan (avchan@ca.ibm.com), Software Architect and Senior Development Manager, IBM

Allen Chan is a Software Architect and Senior Development Manager on the WebSphere Integration Developer and WebSphere Message Broker Toolkit teams at the IBM Toronto Lab. You can contact Allen at avchan@ca.ibm.com.



Anita Dave (anita@ca.ibm.com), Advisory Information Developer, IBM

Anita Dave is an Advisory Information Developer on the WebSphere Integration Developer team at the IBM Toronto Lab. You can contact Anita at anita@ca.ibm.com.



David Van (davidvan@ca.ibm.com), Staff Software Engineer, IBM

David Van is a Usability Specialist on the WebSphere Integration Developer and WebSphere Message Broker Toolkit usability team at the IBM Toronto Lab. You can contact David at davidvan@ca.ibm.com.



27 June 2007

Introduction

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
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
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
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:

Static
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.
Dynamic
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
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
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
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
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
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.

Conclusion

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.

Glossary

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Business process management
ArticleID=236651
ArticleTitle=WebSphere Integration Developer and WebSphere ESB advanced topics, Part 1: Content-based service invocation and routing
publish-date=06272007