Web Services and Flows (WSFL), Page 4
Up until now you've been dealing with the problem of specifying the behavior of a single Web service, either in executable form (private flow) or as a public contract (public flow). In practice, every transaction involves at least two parties, each of which can be characterized in general as a Web service. Complex transactions can typically involve three and more participants directly interacting with each other. Using the flow model described in the previous sections, you can represent the behavior of each one of the parties involved in a transaction. This, however, is not enough to fully specify how the interaction is carried out. What is still missing is a specification of the way in which all these parties need to interact to carry out a certain transaction. Global models are used in WSFL to specify the form of multiparty interactions.
To begin, consider the simplest case: an interaction between two services. A new service must be added to the example, representing an automated cell phone requester serviceor customerof the ordering service. The customer service and its interactions with the cell phone order services are shown in Figure 18.7.
Global model involving two parties.
Observe that the customer is modeled as a service itself, with a WSDL interface and a flow representing its behavior, in just the same way as the phone ordering service. In non-trivial interactions both the provider and the requester of a service need to send and receive messages at different points in their interaction; that is, both effectively behave as clients and servers simultaneously. The Web services interaction paradigm is thus naturally a peer-to-peer interaction model.
In WSDL terms, the customer interface includes one notification operation (sendOrder) and three in-only operations (getRejection, getInvoice, and getDelivery). The customer's public flow specifies the steps that need to follow the sending of the order before the customer's ordering process can be considered terminated: receiving the bill and receiving a note informing of the phone delivery. The customer can also receive a rejection message informing it that the request was not accepted.
In addition to the public flows of two services, Figure 18.7 depicts the interactions between the two in the form of connections between the two services. WSFL refers to these connections as plug links. Plug links are directional connections that represent the invocation of an operation of the target service by the source. WSFL models invocations as an ordered pair consisting of an outbound operation at the source (that is, a WSDL notification or solicit-response operation) followed by an inbound operation (WSDL one-way or request-response) at the target.
It is important to note here that WSFL makes the assumption that outbound operations in a WSDL interface represent a service's ability to invoke the corresponding inbound operationthat is, one whose signature is obtained by exchanging the input and output elements in the operation definition. Thus, WSFL interprets outbound operations by as proxies of the corresponding inbound operation, and a plug link is basically a symbolic representation of connection that exists between the proxy and the operation that it actually invokes on a given service.
The following is an example of a plug link as specified in WSFL syntax:
<plugLink> <source serviceProvider="customer" portType="customerPortType" operation="sendOrder"/> <target serviceProvider="cellPhoneOrderService" portType="orderPortType" operation="receiveOrder"/> </plugLink>
In this example, the assumption is that sendOrder and receiveOrder have dual but matching signatures, as in the sample portTypes below:
<portType name="customerPortType"> <operation name="sendOrder"> <output message="tns:phoneOrder"/> </operation> ... </portType> <portType name="orderPortType"> <operation name="receiveOrder"> <input message="tns:phoneOrder"/> </operation> ... </portType>
Provision must be made, however, for the case in which the types of the messages sent and received by the source and the target do not match, because in practice the connected services may have not been developed from a common design. WSFL allows for simple adaptation of the messages exchanged by means of a mapping mechanism similar to the one used with data links (see the section Data Flow). Thus, if the message that sendOrder sends has a different type from the message that receiveOrder accepts, a map specification can be included in the plug link to provide for the necessary data mapping:
<plugLink> <source serviceProvider="customer" portType="customerPortType" operation="sendOrder"/> <target serviceProvider="cellPhoneOrderService" portType="orderPortType" operation="receiveOrder"/> <map sourceMessage="sendOrderOutput" sourcePart="personalInfo" targetMessage="receiveOrderInput" targetPart="customerData"/> </plugLink>
Global Models in WSFL
To describe a multiparty transaction, WSFL uses a new construct: the global model. A global model identifies the set of service instances that participate in the transaction (these are the service providers you saw in the section Flows as Compositions of Web Services) and uses plug links to define the interactions between them.
The customer-to-phone order service transaction has a very simple global model with two providers and four plug links:
<globalModel name="phoneOrder"> <serviceProvider name="customer" serviceProviderType="abc:customerType"/> <serviceProvider name="cellPhoneOrderService" serviceProviderType="cde:phoneOrderType"/> <plugLink> <source serviceProvider="customer" portType="abc:customerPortType" operation="sendOrder"/> <target serviceProvider="cellPhoneOrderService" portType="cde:orderPortType" operation="receiveOrder"/> </plugLink> <plugLink> <source serviceProvider="cellPhoneOrderService" portType="cde:orderPortType" operation="rejectOrder"/> <target serviceProvider="customer" portType="abc:customerPortType" operation="getRejection"/> <map ... /> </plugLink> <!-- Additional plug links here --> ... </globalModel>
Service providers (or service instances) identify a particular usage of a certain service, as opposed to the service itself. Service instances are typed according to a service type (a named set of WSDL interfaces, see Flows as Compositions of Web Services), and they are assigned a unique name within the global model. Plug links simply identify the source and target providers by their names, and the operations within those providers that are involved in the interaction.
Clearly, global models need not be limited to two-party interactions. Figure 18.8 shows a modification of the two-party phone order global model in which the order service has outsourced all the shipping functions to a third shipping service. The interaction between the customer and the phone ordering service is now limited to the initial ordering and billing. Both the phone ordering service and the customer have direct interactions with the shipping service: The phone ordering service transmits the phone shipment request to the shipper and lets it deal with all the shipping-related functions; the customer receives the delivery information directly from the shipper.
Global model involving three parties.
In the corresponding global model, there are three providers and three groups of plug links representing the interactions between them. You can see in the following example that the three service providers ("customer" on the left of the figure, "cellPhoneOrderService" in the middle, and "shipper" on the right) are declared at the top of the XML coding of the global model. In the rest of the global model, the customer to phone ordering service, phone ordering service to shipper, and shipper to customer interactions are defined in the form of sets of plug links connecting each pair of service providers. All possible pair-wise interactions between the providers are represented in the global model:
<globalModel name="phoneOrder"> <serviceProvider name="customer" serviceProviderType="abc:customerType"/> <serviceProvider name="cellPhoneOrderService" serviceProviderType="cde:noShipperPhoneOrderType"/> <serviceProvider name="shipper" serviceProviderType="cde:shipperType"/> <!-- customer to phone order service links --> <plugLink> <source serviceProvider="customer" portType="abc:customerPortType" operation="sendOrder"/> <target serviceProvider="cellPhoneOrderService" portType="cde:orderPortType" operation="receiveOrder"/> </plugLink> ... <!-- phone order service to shipper link --> <plugLink> <source serviceProvider="cellPhoneOrderService" portType="cde:porderPortType" operation="sendOrder"/> <target serviceProvider="shipper" portType="fgh:shipperPortType" operation="receiveShippingOrder"/> </plugLink> <!-- shipper to customer link --> <plugLink> <source serviceProvider="shipper" portType="fgh:shipperPortType" operation="deliveryNote"/> <target serviceProvider="customer" portType="abc:customerPortType" operation="getDelivery"/> </plugLink> </globalModel>
This example illustrates the distributed nature of the information that a global model is designed to capture. Note that in this case no single party has a complete view of the global interaction. The global transaction is a distributed composition in which two or more service providers are connected according to a certain interaction pattern to enable a level of functionality (a business goal) not provided by any service independently. Compare this form of composition with the type of compositions created when you use flows to define usage patterns of services, as described in Flows as Compositions of Web Services.
For more information on the topics discussed in this chapter, see these references:
Frank Leymann. Web Services Flow Language (WSFL). IBM, April 2001. Available online at http://www.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.
Satish Thatte. XLANG. Web Services for Business Process Design. Microsoft 2001. Available online at http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm.
This chapter reviewed the basic concepts of Web services flow languages, using WSFL as a model. Flow languages, and the fundamental notions of flows and compositions of Web services, are the basic pieces required to support complex, multiparty, and long- running service interactions, such as the ones involved in any realistic business-to-business transaction.
Authors of this Chapter
Francisco Curbera holds a Ph.D. in Computer Science from Columbia University, and is currently a Research Staff Member at IBM's T.J. Watson Research Center. He has worked for several years on the use of markup languages for application development and composition of software components, including the definition of the Bean Markup Language (BML), and the design of algorithms for managing XML documents. More recently, he has been involved in the definition and implementation of several Web services specifications. He is one of the authors of the Web Services Description Language (WSDL) and of the Web Services Flow Language (WSFL).
Matthias Kloppmann is a Senior Software Engineer with IBM Software Group's lab in Bvblingen, Germany. He holds an M.S. in Computer Science and Electrical Engineering from the University of Stuttgart. Matthias has many years of experience with building workflow systems, both in C++ and, more recently, in Java. He has participated in the creation of WSFL, the Web Services Flow Language, and the design of the XML and Web services extensions for MQSeries Workflow. Currently, Matthias is working as a workflow architect on WebSphere, IBM's J2EE application server.
Source of this material
|This is Chapter 18: Web Services and Flows (WSFL) from the book Java Web Services Unleashed (ISBN:0-672-32363-X) written by Robert Brunner, Frank Cohen, Francisco Curbera, Darren Govoni, Steve Haines, Matthias Kloppmann, Ben Marchal, Scott Morrison, Arthur Ryman, Joe Weber, and Mark Wutka, published by Sams Publishing. |
To access the full Table of Contents for the book