Highly Available WebSphere Business Integration Solutions

22 Highly Available WebSphere Business Integration Solutions

3.1 IBM WebSphere Business Integration solution

architecture

The IBM WebSphere Business Integration portfolio is a suite of middleware

products that are loosely coupled to each other. The product suite delivers the

integration capabilities that are required for comprehensive, enterprise-wide

application integration (EAI). The IBM WebSphere Business Integration Adapters

provide the connectivity to and from enterprise applications. IBM WebSphere MQ

provides the underlying transport layer. IBM WebSphere Business Integration

Message Broker provides routing and mediation services, where as IBM

WebSphere Interchange Server or IBM WebSphere MQ Workflow act as

processing engines, and implement business synchronization logic. The

availability of a system is a product of the availability of all its factors. In order to

build a high availability integration solution, it is therefore important to understand

the dependencies among the products.

3.2 WebSphere Business Integration component

dependencies

The following bullet points describe the dependencies between various

WebSphere Business Integration components:

򐂰 InterChange Server and Message Broker

The brokers are loosely coupled to each other. The brokers communicate

with each other through MQ queues and the IBM WebSphere Business

Integration Adapter for WebSphere MQ. As a result, the availabilty of

InterChange Server does not directly influence the availability of Message

Broker and vice versa.

򐂰 InterChange Server and WebSphere MQ

Generally, the availability of InterChange Server itself does not influence the

availability of MQ. InterChange Server’s dependence on MQ is determined by

which transport mechanisms the adapters have been configured to use.

All of the adapters have been configured to use the same transport

mechanisms, which are:

–

IDL, InterChange Server, and adapters are not at all dependent on a

queue manager for transport of business objects between the adapter

agent and controller.

–

MQ, polling adapters will stop delivering objects to InterChange Server.

InterChange Server will continue to process events that are in process

Chapter 3. Design considerations 23

already. Objects can still be sent to target adapter agents and be

processed by them.

–

JMS, adapter controllers will be stopped if the queue manager becomes

unavailable. Before the queue manager can be restarted, InterChange

Server has to be restarted. After a restart of InterChange Server and the

associated queue manager, the controllers that use JMS as transport

have to be manually restarted. (The team has raised this issue as a

defect.) Objects that are sent to the target adapter while the controller is

stopped will fail and have to be manually resubmitted.

򐂰 WebSphere Business Integration Adapters and WebSphere MQ

– Adapters that are configured to use

JMS as their transport mechanism are

directly dependent on WebSphere MQ for transport of business objects,

and for administrative communication between the adapter agent and

adapter controller. In the event that the queue manager becomes

unavailable, the adapter agent and controller shut down. They have to be

restarted following the restart of the MQ queue manager and InterChange

Server.

– Adapters that are configured to use

MQ as their transport mechanism are

dependent on WebSphere MQ for event delivery. In the event that the

queue manager becomes unavailable with a request processing adapter

(an adapter that sends objects to a target destination), the controller is

unable to delete events after delivery. InterChange Server must be

restarted for processing to continue. But, if a polling adapter is

unsuccessful in putting a polled business object on the delivery queue, the

adapter agent shuts down and has to be restarted. In the case where the

queue manager becomes available again before a polling adapter tries to

access its delivery queue, the adapter agent does not have to be restarted

and continues polling.

– Adapters that are configured to use

IDL as their transport mechanism are

not dependent on WebSphere MQ. In the case where the queue manager

becomes unavailable, the adapter agent and controller continue event and

request processing as normal.

򐂰 WebSphere Business Integration Adapters and InterChange Server

For a process to be synchronized successfully, all source and target adapters

and InterChange Server have to be available. However, if one of the

components becomes unavailable, only that one component needs to be

restated. (In the authors' experience, agents reconnect even after hours.)

Adapter agents ping InterChange Server every 30 seconds, and will stop

processing if no response is received from the server. InterChange Server

can continue processing unless all adapter agents become unavailable.