Section 17.2. Wiring

17.2. Wiring

As illustrated earlier in the book, aggregations of Web services play a central role in business interactions. Chapter 11, "Transactions," discussed aggregations of Web services based on agreement protocols, and Chapter 14, "Modeling Business Processes: BPEL," discussed aggregations of Web services based on business process models. Many more aggregation mechanisms are possible (see [KL03] for a corresponding discussion), but one particular mechanism deserves special attention because it is fundamental.

When multiple Web services are used within a business interaction, there are often mutual dependencies between these services. As shown in Figure 17-1, in order for an interaction to succeed, the invocation of operation o1 of port type A is expected to respond by using operation o2 of port type B. To be more precise, operations o1 and o2 are inbound operations (see Chapter 6, "Web Services Description Language") that consume messages, and port type A will somehow have an operation o3 defined to send out a message (an outbound operation) that is the response produced as an effect of using operation o1. This message will be provided as input of operation o2. The fact that operation o3 produces a message sent to operation o2 is graphically depicted by a link, L, in Figure 17-1. Such a link is called a plug-link in [WSFL]. Plug-links wire pairs of dual operations. That is, the operation at the start point of the plug-link begins an interaction by sending a message, and the operation at the end point of the plug-link consumes the initial messages sent.

Figure 17-1. Wiring dual operations.

Thus, there is a dependency between the two operations wired by a plug-link. At a more coarse-grained level, a partner link type in BPEL is similar to such a plug-link. A partner link type specifies that there is a mutual dependency between the two port types specified with each role of the partner link type. The provider of an implementation of the port type of one role of the partner link type requires a provider of an implementation of the port type of the other role of the partner link type for an appropriate and correct interaction (i.e. a message exchange).

A plug-link wires operations, not port types as partner link types do. This finer granularity allows annotating a plug-link to specify additional functionality. For example, a plug-link might be associated with a transformation specification that is used at runtime to map the message produced by the source operation of the plug-link into the message format expected by the target of the plug-link. This facilitates the wiring of operations in which the message formats do not even match.

Another example of information associated with a plug-link is a locator. This is a specification about how to find an implementation of a port type providing an implementation of the operation at the endpoint of the plug-link. Various kinds of locators might be defined, such as a query on a directory like UDDI. At runtime, when the source operation of a plug-link is used, the platform will evaluate the locator associated with the plug-link to determine an implementation of the target to which the message is to be sent.

Typically, the operations of more than one port type will be wired by plug-links. Not all operations of the port types used will be wired by plug-links, but nevertheless the collection of wired port types represents a useful aggregate for others. Thus, this aggregate can be rendered as another port type. This is achieved via export-links [WSFL].

In Figure 17-2, port types A, B, C are aggregated and wired via plug-links. The aggregation G (called a global model [WSFL]) is represented to the outside as another port type P with operation o and o'. An implementation of P is accomplished by delegating its operations to operations of the aggregate. For example, operation o is in fact implemented by operation o1 of port type A, and operation o' is implemented by operation o7 of port type C. This kind of delegation is specified by an export link, the source of which is the implementing operation and the target of which is the implemented operation. At runtime, when the operation o of a port with port type P is used, the platform will forward the message to operation o1 of a port with port type A. Note that the internal wiring behind P might be hidden from the outside, and port type P might be used within other wirings (that is, the aggregation model is recursive).

Figure 17-2. Recursive aggregation via a global model.

Note that it is absolutely fine that a global model does not export any of the operations of its encompassed port types. To a certain degree, the encompassed port types are sufficient. They are self-contained, properly supporting a complete interaction between a set of partners. In many situations, having no need to further wire operations in an aggregation (via plug-links or export-links) indicates a complete, self-contained business interaction between partners.