WebSphere Enterprise Service Bus for z/OS, Version 6.2.0 Operating Systems: z/OS


Dynamic invocation of a static endpoint

Dynamic invocation of a static endpoint occurs when a service is invoked using any supported import binding.

Introduction

The service is available from a different endpoint than originally specified when the mediation module was created and deployed.

Enabling dynamic invocation of a static endpoint

You can use WebSphere® Integration Developer to create a mediation module that selects the target service dynamically at runtime. This module includes an import associated with the reference used to make the dynamic invocation. The import has a binding configuration suitable for a set of target services which all use the same protocol and accept messages which use the same data format. The target service is selected from the alternate targets by applying appropriate qualifiers to the reference and import. For example, the target service could be selected from a number of MQ queues, each providing a related service. The choice of target to invoke is made dynamically using available metadata provided in the message.

What happens at runtime

When a message is received by the mediation module, it might have an EPR that contains the endpoint URI of a target service. If the URI matches the import binding, the import and any relevant qualifiers are used to make the actual invocation of the intended target service. If the URI does not match the import binding, a pure dynamic invocation is made for the URL type, if it is supported.

If no EPR is provided in the message, an invocation is made using the import defined when the module was created and deployed. An EPR present in a message always overrides any static endpoint configuration.

Any response from the new service target returns through the normal response flow process, back to the original caller of the export.

If the incoming message contains invalid override information, for example an invalid target address, the mediation module throws an exception and an exception response is returned to the original caller.

Storing endpoint information

Service endpoint information can be stored in any easily accessed form, such as WSRR or a database. For example, non-Web service or SCA endpoints could be stored in WSRR as standalone endpoints, not requiring WSDL. The service endpoints could be added to WSRR manually, or automatically published from SCA exports in deployed modules. Within mediation flow components, endpoints could be obtained using the Service Registry or Database Lookup mediation primitives, or set using MFC capabilities in the SMO.

For SCA endpoints, the choice of which endpoint to use is set in the EPR used to make the invocation. In this case it is not possible to specify alternate targets.

Examples

Figure 1. Dynamic invocation of a static endpoint
A message flows through a mediation module and an import binding to a Web service. Information in the message can override the endpoint dynamically.

Figure 1 shows how dynamic invocation works when the POJO in Mediation Module 1 receives a message. The message is sent to Export 2 in Mediation Module 2 through the existing wired connection created when the mediation module was developed and deployed. Optionally, the incoming message contains information that sends the message to a different destination. In Figure 1, the message could be sent to Export 3 in Mediation Module 3 by using an optional Endpoint Reference object. The POJO extracts the endpoint information from the message, and identifies Export 3 as the endpoint, rather than the Export 2 endpoint specified in the original deployment. The POJO uses the SCA Endpoint Reference API, and the reference wired to the Import, to invoke the remote service specified by the endpoint in the message.

Figure 2. Dynamic invocation of a static endpoint using SMO
Normally, a message flows through a module and an import binding to a Web service. Information in the message can be used to override the endpoint dynamically.

A similar mechanism works by using a Mediation Flow Component to modify SMO values within the message, as shown in Figure 2. Dynamic invocation begins when a message is received by the export. The message would normally be sent through the import to SvcProvider1, but contains routing information that should resolve to SvcProvider2.

A new target address is set for the message using the incoming message content and routing information. The Mediation Flow Component sets the new address by changing SMO values, using one or more of several possible mediation primitives, such as Database Lookup, Message Element Setter, Business Object Map, or XSL Transformation.


reference Reference topic

Terms of use | Feedback


Timestamp icon Last updated: 21 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.zseries.doc/ref/rwesb_dynamicoverridestatic.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).