Service gateway

A service gateway is a single access point and acts as a proxy for multiple services. A service gateway enables transformations, routing, and common processing across all the services.

A service gateway module is a single mediation that handles the requests for multiple service consumers and providers. There are four steps that are typical of any service gateway:

Common processing - once the message is received by the gateway, common processing occurs for all messages, such as adding protocol level headers or logging the message.
Service identification - the message that is processed by the gateway needs to be identified as a certain service type. For example, the message is queried to determine if it is for service provider A, B, or C.
Endpoint routing - when it is known that a message will be delivered to a particular service provider, it is mapped to a network-addressable endpoint so that the message can be forwarded to the service provider.
Service-specific processing - any processing that is required for the particular target service is performed.

The order of the four steps can be changed according to different scenarios.

There are three service gateway patterns provided out of the box that are supported by WebSphere® ESB:

Each of these patterns follow a general format within the tooling environment in IBM® Integration Designer, as shown in Figure 1. The service gateway is represented as an SCA module. An export exposes the endpoint and has the service gateway interface attached. The service gateway interface instructs the runtime that it is in the service gateway mode.

Figure 1. General pattern for a service gateway module Service gateway represented as an SCA module. An export exposes the endpoint and has the service gateway interface attached. The service gateway interface instructs the runtime that it is in the service gateway mode.

Service gateway represented as an SCA module. An export exposes the endpoint and has the service gateway interface attached. The service gateway interface instructs the runtime that it is in the service gateway mode.

The service gateway interface has two operations: requestOnly and requestResponse. Both operations use messages that have an anyType structure. An anyType message structure allows it to be one of five core structures that represent raw data that is sent to the mediation flow component, as shown in Figure 2. This is not to accommodate any business object. Implement one or both of the interface operations.

Figure 2. Five structures that represent raw data

TextBody, BytesBody, ObjectBody, StreamBody and MapBody are the five structures that represent the raw data that is sent to the mediation flow component.

The binding type must be taken into consideration, to determine which business object is created. The following table shows the business objects that are created for the different binding types.

Binding type	Business object created
WebSevice Binding	TextBody
HTTP Binding
HTTP Content-Type=text/*	TextBody
HTTP Content-Type=application/soap+xml	TextBody
HTTP Other	BytesBody
JMS Binding
JMS TextMessage	TextBody
JMS BytesMessage	BytesBody
JMS StreamMessage	StreamBody
JMS MapMessage	MapBody
JMS ObjectMessage	ObjectBody
MQ Binding
MQ Format = MQSTR	TextBody
Other	BytesBody

The content of the message is in a serialized form (such as XML) when it reaches the mediation flow component and is held within a TextBody structure. Header information is parsed as a business object and can be found in the header section of the Service Message Object (SMO). To change the body of the message, it can be parsed within the mediation flow component and changed using transformation mediation primitives and then serialized before it is passed to the service gateway import. To parse the message within the mediation flow component, the schema information associated with the message type should be available to the module.

There are two ways that WebSphere ESB can parse a message within the service gateway pattern:

Manual parsing of the gateway message
Automatic parsing and any message type support

Manual parsing of the gateway message

The DataHandler mediation primitive can be used to convert a message from a serialized form (such as XML) to a business object structure. This mediation primitive differs from other transformation primitives such as the Mapping or the BO Mapper, which convert one business object into another business object.

The DataHandler mediation primitive is used extensively within the static service gateway pattern, where you must parse the serialized message body into the concrete business object structure. Each DataHandler primitive can only handle a single message type, therefore branching and multiple DataHandler primitives are required, as shown in Figure 3.

Figure 3. DataHandler mediation primitive used in a service gateway Each DataHandler primitive can only handle a single message type, therefore branching and multiple DataHandler primitives are required

Each DataHandler primitive can only handle a single message type, therefore branching and multiple DataHandler primitives are required

Automatic parsing and any message type support

In IBM Integration Designer, as a default all terminals are defined with concrete message types. The terminals can be defined to have any message structure, which is set on individual terminals, allowing any business object to move through the mediation flow. WebSphere ESB parses the serialized message body into a concrete business object at the edge of the mediation flow component (input and callout). To enable this, the input nodes must be configured with the feature titled Automatically convert the service gateway message. This allows the parsing and serialization to occur automatically when the inbound message is XML encoded within a TextBody structure. The overall service gateway design is shown in Figure 4.

Figure 4. Automatic parsing used in a service gateway

WebSphere ESB parses the serialized message body into a concrete business object at the edge of the mediation flow component (input and callout). To enable this, the input nodes must be configured with the feature titled “Automatically convert the service gateway message”. This allows the parsing and serialization to occur automatically when the inbound message is XML encoded within a TextBody structure.