Ports

A collaboration has a set of interfaces to the outside world called ports. In a collaboration template, each port is a variable that represents a business object that the collaboration object receives or produces at runtime. For example, consider a hypothetical Service Billing collaboration that is triggered by the closing of a case in a customer service management application. The collaboration retrieves the customer's contract as a business object from a customer records application, then uses the information in the contract to send an invoice business object to an accounting application.

Such a collaboration might use three ports, one for each of the connectors with which it interacts. Each port is associated with a particular type of business object, as shown in Figure 2-3:

Figure 19. Ports in the Service Billing collaboration


At configuration time, an administrator creates a collaboration object that contains the template's ports. The administrator binds the ports for that specific collaboration object, associating each port with a connector, or with another collaboration object. For some collaborations (those whose templates accept the Retrieve verb), a port can be configured instead as External, so that it can receive a triggering business object from an access request--an external call on the Server Access Interface.

The ports enable communication between bound entities, so that the collaboration object can accept the business object that triggers its business processes, and then send and receive business objects as requests and responses.

Figure 20 illustrates a fictional collaboration, with its triggering port bound to accept the Case business object as a call from external processes, and its other ports bound to connectors that use Contract and Invoice business objects.

Figure 20. Ports bound to connectors


To make an analogy, a computer has various hardware interfaces. To hook up a computer with peripherals such as speakers or a monitor, you attach cables and wires whose shapes are complementary to the shapes of the computer's interfaces. The "shape" of a collaboration port is the type of business object that can pass through it. An administrator can bind a port only to a connector that supports specific types of business objects, just as you can plug a computer cable only into the interface that matches its shape.

A collaboration can be bound to another collaboration if each has a port that supports the same type of business object. Figure 21 illustrates two collaboration objects bound at ports that support the Item business object.

Figure 21. Binding two collaboration objects


Port names often indicate the role of the port's supported business object in the collaboration. For example, if a collaboration receives customer information and generates contract information, its ports might be called InCustomer and OutContract.

Dynamic service calls

Collaborations implement service calls with explicit binding, which means that the collaboration service call needs be configured to connect to a known destination, such as a connector or another collaboration, while the collaboration is being developed from a collaboration template. The explicit binding is static, which means that if the port assignments are changed, the collaboration objects need to be redeployed into InterChange Server before they can be used. Collaborations also cannot be deployed until all ports are bound.

InterChange Server includes an API which enables dynamic service calls, so that a collaboration can make a service call to a destination that has not been pre-defined and explicitly bound during collaboration development. The dynamic service call API captures all the required details about the consumer so that a collaboration can interact with many connectors, and the number and type of connectors can change dynamically. When creating a collaboration to receive a dynamic service call, an inbound port should be bound as an external port during port binding in the System Manager tool, so that the collaboration can receive the triggering business object through the external port. The API can pass the essential information about the client, such as the client's name and type. The API can also use the source adapter information to determine where to send the service request. The dynamic service call API is synchronous.

The dynamic service call API enables dynamic service binding without the need for any tools. The API and the associated set of parameters can be used within collaboration templates with minimal changes or influences to existing collaborations. The API itself does not handle exceptions or define failure behavior, so these issues need to be addressed in the collaboration template. The API also does not provide quality of service, such as transaction support compensation. See the Collaboration Development Guide for API information.

The dynamic service call has limited or no support for the following:

Copyright IBM Corp. 1997, 2004