Connector architecture

Connectors consist of an application-specific component and the connector framework. The application-specific component contains code tailored to a particular application. The connector framework, whose code is common to all connectors, acts as an intermediary between the integration broker and the application-specific component. The connector framework provides the following services between the integration broker and the application-specific component:

The connector is metadata-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 assured event delivery.

The connector allows a WebSphere integration broker (which can be either the InterChange Server or the WebSphere MQ implementation) to asynchronously exchange business objects with iSoft Commerce Suite server.

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

The connector does not persist the state of events. When the connector delivers a message into the queue monitored Commerce Server, it returns successfully, without waiting to determine whether the message that it delivered to Commerce Server was sent to the Commerce Server trading partner. And when the connector receives an event from Commerce Server, 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 Commerce Server) and for event notification (converting a message from Commerce Server 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 an input queue, the connector looks up the business object name associated with that input queue and with 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 a business object is successfully populated with message content, the connector checks to see if it is subscribed, and then delivers it to the InterChange Server using the gotApplEvents() method.

Copyright IBM Corp. 1997, 2004