Binding between elements

To perform a business process, a collaboration can communicate with connectors, with other collaborations, and with external processes from which it receives access requests through the Server Access Interface. Binding is used to set up communications between the collaboration and these elements when the collaboration is configured.

This section describes the concepts for binding. The tools and procedures for creating the bindings are described later in this guide underRight-clicking to configure InterChange Server Express properties).

Binding a trigger

A collaboration begins a processing flow when it is triggered to do so by the arrival of a business object. The trigger can be any of the following:

To allow a collaboration's business processes to be triggered, you must bind the collaboration at configuration time to an element that will supply the triggering event or call.

Binding is done between the collaboration and any element that will participate in that collaboration's business process, but only one element can be bound as the trigger.

Binding for events

When you configure a collaboration at your site to be triggered by events, you bind it to a connector capable of publishing the triggering event. For example, you might specify that the collaboration's Employee.Delete event comes from the PeopleSoft connector.

To look more closely at this relationship, recall that the connector actually consists of a connector controller (which, like the collaboration, resides in the InterChange Server Express) and a connector agent (which includes the client connector framework and an application-specific component, and is separate from the InterChange Server Express). The connector controller maintains the binding information and provides its connector agent with a list of events to which collaborations have subscribed.

When relevant application operations occur, the connector agent publishes the events on that list to the connector controller. The connector agent sends an event to the connector controller without knowing anything about its ultimate destination at a collaboration.

The connector controller is therefore an intermediary between the connector agent and the collaboration, as Figure 8 illustrates.

Figure 8. A connector providing a triggering event

Multiple collaborations can subscribe to the same event. When the connector controller publishes the event, it can publish simultaneously to all subscribers.

Binding to receive access requests

Instead of binding the collaboration to a connector for triggering, you can specify that the collaboration will receive access requests from external processes as triggers.

Binding destinations

In addition to binding collaborations to triggering elements, you also bind collaborations to the destination elements with which the collaborations will engage in request/response interactions. Destination elements can be either connectors or other collaborations. A single collaboration can be bound to multiple destination elements.

Copyright IBM Corp. 2004, 2005