Patterns: Broker Interactions for Intra- and Inter-enterprise

226 Broker Interactions for Intra- and Inter-enterprise

Transport support for applications

WebSphere Business Integration Message Broker provides the following

transports mechanisms to allow clients to communicate with applications through

message flows:

򐂰 WebSphere MQ Web Services Transport allows Web services clients using

XML messages and the HTTP protocol running over TCP/IP to communicate

with applications through message flows in a broker.

򐂰 WebSphere MQ Real-time Transport is a lightweight protocol optimized for

use with non-persistent messaging. JMS applications communicate with the

broker using TCP/IP ports.

򐂰 WebSphere MQ Telemetry Transport is a lightweight publish/subscribe

protocol flowing over TCP/IP. This protocol is used by specialized applications

on small footprint devices that require a low bandwidth communication,

typically for remote data acquisition and process control.

򐂰 WebSphere MQ Multicast Transport is used by dedicated multicast-enabled

JMS application clients to connect to brokers. Applications communicate with

the broker by writing data directly to TCP/IP ports. This protocol is optimized

for high volume, one-to-many publish/subscribe topologies.

򐂰 WebSphere MQ Enterprise Transport supports WebSphere MQ applications

that connect to WebSphere Business Integration Message Broker by writing

data to and reading data from message queues.

򐂰 WebSphere MQ Mobile Transport is used exclusively by WebSphere MQ

Everyplace clients. WebSphere MQ Everyplace is an application designed

primarily for messaging to, from, and between pervasive devices. These are

typically small, handheld devices, such as mobile phones and PDAs. A bridge

queue on the broker's queue manager provides an interface for the

WebSphere MQ Everyplace clients to the broker services.

9.3 Applying patterns

The Retail system needs to get delivery dates based on a part or system number

from the appropriate Wholesale supplier. Each Wholesale supplier has its own

unique implementation that returns the delivery date to requesters but has

basically the same input and output formats for incoming requests and outgoing

responses. Each Wholesale system does not necessarily support the same

protocol for transmission of the requests and responses.

The Retail system knows the part number it wants a delivery date for, but doesn’t

know which Wholesale suppliers can deliver the part. In the event that there are

multiple Wholesale suppliers for the part, the Retail system wants to know the

earliest possible delivery date.

Chapter 9. Broker solutions using WebSphere Business Integration Message Broker 227

From this, ITSO Electronics determined the following requirements:

򐂰 Each Wholesale department must expose its services as Web services.

The actual implementation on the Wholesale systems must be transparent to

the Retail system. The request for a delivery date will be done as a Web

service invocation, relieving the Retail system from having to know how the

request is fulfilled.

򐂰 The design must be able to support multiple protocols and perform protocol

transformation.

򐂰 The design must be able to decompose the incoming request into multiple

Web service requests, then must be able to recompose the responses into a

reply. For this, a broker will be used.

򐂰 The broker must be able to inspect the incoming request and determine which

Wholesale system it needs responses from in order to create a complete

reply for the Retail system. It must be able to send simultaneous requests to

the Wholesale systems, and manipulate the responses so the earliest

delivery date returned (and not all delivery dates) can be sent as a response.

9.3.1 Application patterns

ITSO Electronics will address the solution in three stages:

򐂰 In the first stage, they will integrate the internal Retail and Wholesale

systems, allowing the Retail systems to get a delivery date based on a part

number.

򐂰 In the second stage, they will implement a solution that allows the Retail

systems to publish sales information to internal Wholesale systems.

򐂰 In the third stage, they will extend the solution from stage 1 to integrate the

internal Retail systems with external wholesale partners. This will allow the

Retail systems to get delivery dates for parts supplied by external Wholesale

suppliers.

Stage 1: Internal delivery date

In stage 1, the solution will address the internal Retail and Wholesale systems.

The use of a broker provides the ability to:

򐂰 Perform any protocol transformation required between the Retail and

Wholesale systems.

򐂰 Perform intelligent routing of incoming messages, relieving the Retail systems

from knowing which Wholesale systems can supply the part.

򐂰 Route the request from the Retail system to multiple Wholesale systems

simultaneously. In the event that multiple Wholesale systems can supply the