Integration patterns

One-to-one relationship between the sending and receiving clients.
Integration Patterns

Integration patterns

1. Integration, Point to Point

In a point-to-point integration, the concept of a message queue is used to implement the messaging. The sending application/client establishes a named message queue in the broker and sends messages to this queue. The receiving client registers with the broker to receive messages posted to this queue. There is a one-to-one relationship between the sending and receiving clients.

Integration Pattern Point To Point

In point-to-point messaging, there is always exactly one message producer and one message consumer. Unless the sender defines a timeout for the message, there is no time dependence in this type of messaging. A message consumer can receive a message sent at any time in the past by a message producer, even if the consumer wasn't running when the message was queued. Figure shows a point-to-point messaging scenario.

A Simple Point-to-Point integration would involve the following:
  • Define Sender/Receiver Channels
  • Define Input queues which will be used by the source/target applications for sending/receiving the message
  • Development/Unit testing
The following are not in scope for Simple Point-to-Point integration:
  • Modifications to the source/target applications to put/get messages from the queue.
  • Analysis/design-To be done as part of the PreStudy/Other Prestudy phase

2. Integration, Request/Reply

A Request/Reply scenario can be used in both asynchronous and synchronous mode. When it is synchronous, the requester sends the request to the receiver or server application, waits for the reply, and then goes on with its work. The requester must wait for the reply or feedback. If no reply is received after a certain period of time, a time-out exception will be raised to handle the error.

Integration Pattern Request Or Reply

WebSphere Message Broker provides options for synchronous interaction both as a requester and a provider over a variety of transport protocols. Figure above shows a sample of a request-response implementation with WebSphere Message Broker.

A simple Request/Reply integration would involve the following:
  • Define Sender/Receiver Channels
  • Define Input queues which will be used by the source/target application for sending the message
  • Define ReplyTo queues
  • Development/Unit testing
The following are not in scope for Simple Request/Reply integration:
  • Modifications to the source/target applications to put/get messages from the queue.
  • Analysis/design-To be done as part of the pre-study/Other pre-study phase

3. Integration, Transformation

Fire-and-forget is a common scenario in asynchronous mode in which the sender sends the notification to the receiver, and that is all. The sender does not need to wait for the reply to continue his job.

Integration Pattern Transformation

Sometimes when necessary, the receiver needs to send feedback or a response to the sender. In this situation, the requester must implement an event handler to capture the response when it comes back asynchronously and to correlate each response with the corresponding request.

WebSphere Message Broker supports asynchronous service interaction using MQ or JMS transportation. It also supports one-way Web services using SOAP over HTTP 1.1 as a service requester and service provider. The requester does not need to wait for a valid SOAP reply, but a simple 200 or 202 HTTP response status code is the indicator that the request has been accepted by the HTTP layer.

A Simple Transformation would involve the following
  • Development/Unit testing
  • Define Sender/Receiver Channels
  • Define Input queue which will be used by the source application for sending the message
The following are not in scope for a Simple Transformation:
  • Modifications to the source/target applications to put/get messages from the queue.
  • Analysis/design-To be done as part of the PreStudy/Other Prestudy phase

4. Integration, Content based Routing/Distribution

Publish/subscribe involves the sending of data by one application to any number of receivers. This introduces a much more complex relationship between the sender and the receiver, where there is an abstraction between them so that they are unaware of each other. This abstraction layer is usually provided by a broker service, which manages incoming data (publications) from sending applications (publishers) and matches them to interested receivers (subscribers). The broker then forwards the data to the registered subscribers.

Integration Pattern Content Based Routing

The correlation between publishers and subscribers is defined by using topics, which are contained in a hierarchical arbitrary namespace (that is, application defined). Subscribers register interest in a topic (or topics) with the broker, and publishers publish messages using those topics. The names of topics usually relate to the information carried within them. The broker routes publications on particular topics to all those subscribers that have registered an interest in those topics.

In a WebSphere Message Broker scenario, typically a publish/subscribe system has more than one publisher and more than one subscriber, and often more than one broker. An application can be both a publisher and a subscriber. The publisher application generates a message that it wants to publish and defines the topic of the message. A message flow running in the broker retrieves the message from its input node and passes the message to a Publication node for distribution to all subscribers that have registered an interest in the topic. A user name server is provided to achieve the security control on topics.

A subscriber registers a request for a publication by specifying one of the following items:
  • The topics of the published messages that it is interested in.
  • The subscription point from which it wants to receive publications.
  • The content filter that should be applied to the published message.
  • The name of the queue (known as the subscriber queue) on which publications that match the criteria selected should be placed. This can be the name of a cluster queue so that publications can be distributed to clustered subscribers.
A Simple Content based routing would involve the following:
  • Define a message flow in the broker with an MQ input node and an publication node
  • Define Input topic which will be used by the source application for publishing the message and used by the target application for receiving the message
  • Development/Unit testing
  • Define Sender/Receiver Channels
The following are not in scope for a Simple Content based routing:
  • Modifications to the source/target applications to put/get messages from the queue.
  • Analysis/design - To be done as part of the PreStudy/Other Prestudy phase

5. Integration, Standard Change Request Point-to-Point–Moving a Server

A Simple change request to move the queues and the other integration components would involve
  • Defining the queues/channels (similar to whatever has been defined in the existing setup)in the new server based
  • Deploying the integration
  • Unit testing the integration in the new server.
  • Publish a list of details like queue names/ports/namespaces etc of the newly moved queues/servers.
The following are not in scope for Standard Change Request-Simple Point-to-Point:- Moving a Server
  • Modifications to the source/target applications to put/get messages from the new server/queue.
  • Analysis/design-To be done as part of the PreStudy/Other Prestudy phase
  • Does not include decommissioning the existing queues

6. Integration, Other Integrations

a) Integration using Message Broker

A Simple integration using message broker would involve:
  • Defining the source and destination queues/topics
  • Defining the message flow with a one Input node and one output node
  • Define a simple transformation as part of the message flow. A simple transformation would mean that there will be a 1-1 mapping of the source and target data.
  • Development/Unit testing
The following are not in scope for Simple integration using message broker:
  • Modifications to the source/target applications to put/get messages from the queue.
  • Analysis/design-To be done as part of the PreStudy/Other Prestudy phase
The effort estimated for a simple request to move the Point to point queues, configuring them and testing them is 56 hrs.

b) Integration using Adapter

WebSphere Adapters for specific applications are used to create integrated processes that include the exchange of information with the intended applications.

Using the adapter, an application component (the program or piece of code that performs a specific business function) can send requests to the application (for example, to query a customer record in a SAP table or to update an order document) or receive events from the application (for example, to be notified that a customer record has been updated). The adapter creates a standard interface to the applications and data on the application, so that the application component does not have to understand the lower-level details (the implementation of the application or the data structures) on the application.

The adapter, is generated with the Adapter Connection wizard, uses a standard interface and standard data objects. The adapter takes the standard data object sent by the application component and calls the relevant application function. The adapter then returns a standard data object to the application component.

The following is in scope for Simple integration using adapters:
  • Configuring the out-of-the box adapters provided by Websphere Message Broker,
  • Defining a simple message flow (one input node and one output node)
  • Defining a simple transformation. (1-1 mapping between source and target data)
  • Development/Unit testing
The following are not in scope for Simple integration using adapters:
  • Modifications to the source/target applications to put/get messages from the queue.
  • Analysis/design-To be done as part of the PreStudy/Other Prestudy phase

c) Integration Connections to VCC external companies

A Simple integration to connect to VCC external companies would be the integration between VCC and one or two external companies only.

  • Development/Unit testing of the following is in scope:
  • Designing and Implementing message flow as defined by the VCC architects
  • Designing the message content and transformation based on the definition provided by VCC architects.
  • Identifying & configuring source and destination queues.
The following are not in scope for Simple integration to connect to VCC external companies:
  • Any modifications required to the source/target applications (including put/get messages from the queue).
  • Analysis/design - To be done as part of the PreStudy/Other Prestudy phase
  • Interaction and Management effort with external companies.