Adapter architecture

The adapter for CES Centricity Gateway is built using the WebSphere Business Integration Adapter (WBIA) framework and WBIX adapter framework extensions. WebSphere Business Integration extensions (WBIX) are a set of modular components built on top of the WBIA framework and are configured and instantiated at runtime. The adapter uses the XSLT logic module for message processing, the WBI transport receiver and sender for communicating with the broker, and either the WebSphere MQ transport or the Java(TM) Messaging Service (JMS) transport for communicating with the Centricity MQSeries(R) gateway. The WBIX XML data handler is used to convert between generic business objects and their XML representation for processing by the XSLT logic module. All event notification is handled by the WBI transport and the queue-based transports.

Figure 1. Detail view of the adapter for CES Centricity Gateway architecture

Adapter for CES Centricity Gateway architecture includes sender and receiver transport modules, one or more logic modules, an MQ or JMS sender and receiver queue. On top of those components is the adapter core, which interfaces with the connector profile and WBIX XML data handle. This component interfaces with the gateway, which connects to the Centricity product. On the other side of the adapter component, is the integration broker.

A description of the adapter components follows.

Adapter components

The adapter components, which are part of the adapter extensions framework, are as follows:

Adapter Core
The adapter core controls the data and logic flows in the adapter.
Connector Profile
The connector profile describes the connector configuration and its properties. The Connector Configurator, which is a tool with a graphical user interface, enables you to define the configuration and properties.
WBIX XML Data Handler
The WBIX XML data handler provides conversion between generic business objects and their XML representation for processing by the XSLT logic module.
Event store
The event store provides persistence throughout adapter processing. Events are persisted within the queue, by default, until written to the event store. See Event life cycle and Event store file naming for additional details on the event store component.

The event store for this adapter is com.ibm.wbix.adapter.transports.FileSystemEventStore.

Logic Modules
Logic modules process data from an inbound transport receiver enroute to the outbound transport sender. These modules provide translation functionality between the application and integration broker data formats. For example, an XSLT logic module is provided for the situation where both inbound and outbound formats are in XML format.

You can create custom logic modules to provide processing specific to your requirements. For example, you could create a specific XSL file to define a specific grammar transformation. Logic modules can also be chained if you require that capability.

The logic module for this adapter is com.ibm.wbix.adapter.logicmodules.XsltLogicModule.

Transport
A transport encapsulates inbound, outbound, and persistent communications logic for the adapter and integration broker. The outbound component of the transport is the sender. The inbound component of the transport is the receiver. The persistence component is the event store.

Because an application might have a mix of different protocols as its integration interface (for example, an SQL database interface for some data and an MQ messaging interface for other data), multiple transports can be loaded within a single adapter to enable the adapter to communicate across disparate protocols. In addition, each transport can house multiple incoming (receivers) and outgoing (senders) endpoints, such as a single receiver or sender for each of the application messaging queues. Transports are provided for some common interfaces. See Transport modules for additional details on the transport component.

Transport modules

The standard WebSphere Business Integration sender and receiver transport modules are used for communication with the integration broker. They expect the body of the message to contain an XML format recognized by the adapter or the WBI transport, which then gets converted into a WebSphere Business Integration Java object and sent to the integration broker for processing. The transport component contains modules that communicate with the integration broker and modules that communicate with the application.

Broker transport

For this adapter, the WebSphere Business Integration transport consists of the following components:

com.ibm.wbix.datahandlers.XMLDataHandler
The data handler converts WebSphere business objects to and from WBIX XML.
com.ibm.wbix.adapter.transports.wbi.WBISender
This module sends business objects to the integration broker.
com.ibm.wbix.adapter.transports.wbi.WBIReceiver
This module receives business objects from the integration broker.

Application transport

You can select either a JMS or MQ implementation as the application transport.

For a JMS transport, the following packages are provided:

com.ibm.wbix.adapter.transports.queue.jms.xml.XMLSender
Responsible for sending XML messages using JMS.
com.ibm.wbix.adapter.transports.queue.jms.xml.XMLReceiver
Responsible for receiving XML messages using JMS.

For an MQ transport, the following packages are provided:

com.ibm.wbix.adapter.transports.queue.mq.xml.XMLSender
Responsible for sending XML messages using WebSphere MQ queues.
com.ibm.wbix.adapter.transports.queue.mq.xml.XMLReceiver
Responsible for receiving XML messages using WebSphere MQ queues.

Event life cycle

Events generated are propagated to the integration broker as follows:

  1. The adapter adds the event to the local event store with status "EVENT_RECEIVED".
  2. Processing occurs on the event in the local event store which changes status:
  3. When the processing and polling completes, the local event has its status changed to the appropriate status value, for example, "ERROR_POSTING_EVENT" or "SUCCESS".
  4. The event is archived:

Event store file naming

The event store uses the local file system as the default persistent event store implementation. When the adapter is started, it creates separate directories for the event store proper and the event store archive.

For each event added to the event store, the adapter writes a new log file with the event contents. Each event record uses a naming convention consisting of a unique ID, appended with an event status separated by an underscore (_), for example, uniqueID_status value. The unique ID is obtained by computing a hash function on the event ID of the message.

If you use this event store, ensure that the event IDs generated by the receivers contain no special characters that are disallowed by your file system. For event status changes, the event store generally renames the file to reflect the updated status. However, for status changes that indicate a change in the event body, for example, IN_PROCESSING to READY_FOR_POLL, the event store rewrites the file contents.

The status constants are listed in Table 1. Error constants are listed in Table 2.

Table 1. Status constants

Status constant Value
EVENT_RECEIVED 2147483647
IN_PROCESSING 2147483646
EVENT_PROCESSED 2147483645
READY_FOR_POLL 0
IN_PROGRESS 1
SUCCESS 3

The error constants are:

Table 2. Error constants

Error Value
ERROR_IN_LOGIC_PROCESSING -2147483647
UNSUBSCRIBED 2
ERROR_PROCESSING_EVENT -1
ERROR_POSTING_EVENT -2
ERROR_OBJECT_NOT_FOUND -3

Copyright IBM Corp. 1997, 2003