Connector architecture

The connector is meta-data-driven. Message routing and format conversion are initiated by an event polling technique. The connector uses an MQ implementation of the JavaTM Message Service (JMS), an API for accessing enterprise-messaging systems that also makes possible guaranteed event delivery.

The connector allows a WebSphere integration broker (InterChange Server Express) to asynchronously exchange business objects with Peer-to-Peer Agent.

The connector supports bidirectional exchanges--it publishes to the integration broker business data events that it receives from Peer-to-Peer Agent, and it processes business data requests sent from the integration broker to Peer-to-Peer Agent. This is done through queues. You must set up queues for receiving messages from Peer-to-Peer Agent, and queues for sending messages to Peer-to-Peer Agent:

The connector does not persist the state of events. When the connector delivers a message into the queue monitored by Peer-to-Peer Agent, it returns successfully, without waiting to determine whether the message that it delivered to Peer-to-Peer Agent was sent to the Peer-to-Peer Agent trading partner. And when the connector receives an event from Peer-to-Peer Agent, it publishes it asynchronously to the subscribing collaborations. If the enterprise requires that delivery of the business data messages be tracked and verified, the collaboration (or WebSphere MQ Integrator broker work flow) that defines the business process must be designed to do that by incorporating the monitoring of MDN and notification queues into its process flow.

The connector uses data handlers to convert between the serialized data contained in the WebSphere MQ message and the business object that is handled by the integration broker. Because different data formats require different data handlers, the connector allows you to specify (in the connector's standard configuration properties) the data handler to be used for your implementation of the connector. However, you can adjust this specification at the business object level, specifying that a specific data handler (such as the XML data handler) will be used for a specific business object (such as the Customer_Create business object) and that other data handlers will be used for other business objects. You can do this for both request processing (converting a business object into a message to send to Peer-to-Peer Agent) and for event notification (converting a message from Peer-to-Peer Agent into a business object that is delivered to the integration broker).

For more information about data handlers generally, see the Data Handler Guide.

The type of business object and verb used in processing a message received by the connector is based on the queue from which a message is retrieved. The connector uses meta-object entries to specify which business objects can be expected from which queues.

You can optionally construct a dynamic meta-object that is added as a child to the business object passed to the connector. The child meta-object allows the user to set and get much of the same information as that defined by the static meta-object, but dynamically at run-time.

The connector can poll multiple input queues, polling each in a round-robin manner and retrieving a specified number of messages from each queue. For each message retrieved during polling, the connector adds a dynamic child meta-object (if specified in the business object). The child meta-object values can direct the connector to populate attributes with the format of the message as well as with the name of the input queue from which the message was retrieved.

When a message is retrieved from the input queue, the connector looks up the business object name associated with the queue and the FORMAT field contained in the message header. The message body, along with a new instance of the appropriate business object, is then passed to the data handler. If the connector cannot determine the business object based on the input queue and format, the message body alone is passed to the data handler. If a business object is successfully populated with message content, the connector checks to see if it is subscribed, and then delivers it to the integration broker using the gotApplEvents() method.

Copyright IBM Corp. 1997, 2003