Web Services and Flows (WSFL)
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.
Chapter 18: Web Services and Flows (WSFL)
In This Chapter
- Service Flow and Service Composition
- Flow Modeling Concepts
- Flows as Compositions of Web Services
- Exposing Flows as Web Services
- Public and Private Flows
- Global Models
The overall aim of Web services is to provide a standards-based framework to enable application-to-application interaction. Simple interactions, in particular stateless ones, can be modeled as single operation invocations or message exchanges with a service; WSDL and SOAP provide convenient support for this type of basic interaction. Richer interactions typically involve multiple invocations flowing between two or more services in a peer-to-peer settingthat is, a scenario in which all participants potentially act as both clients and servers. This is the model of interaction prevalent even in simple business transactions, both in the business-to-consumer and (especially) in the business-to-business scenarios. Even a process as simple as ordering merchandise online involves at least three partiesa customer, an e-commerce retailer, and a shipperas well as direct interactions between the three of them.
The full potential of the Web services framework will not be realized until complex interactions of this kind are properly supported. Although no single standard has yet emerged, Web services flow (or process) languages, such as the Web Services Flow Language (WSFL) and XLANG), provide the means to deal with them. This chapter reviews the basic concepts underlying these languages, drawing mainly from WSFL.
Service Flow and Service Composition
Complete representations of complex service interactions rely on two basic concepts: service flow and service composition. The service flow is a description of how the service operates. In business environments, the service flow is a representation of the business process that it implements. By revealing the internal operation of the service, the flow lets users and possible business partners know how the service should be used. In particular, the flow describes the order in which the operations the service provides should be used, and the logic the service follows to process requests. Following a long-standing tradition in the field of business process modeling, WSFL uses a flow model to represent service flows. The flow model itself is presented in the section Flow Modeling Concepts.
A flow's individual steps can be realized through a multitude of possible implementations, from manual realizations performed by people to automatic implementations performed by software. The usage of Web services as particular realizations of the individual steps of a flow is described in the section Flows as Compositions of Web Services.
Flows themselves are of course services, too, though more complex ones. It must therefore be possible to make them available as Web services. The section Exposing Flows as Web Services; shows how this can be done.
Flows can provide different levels of description of the business process followed by a Web service. The complete description allows a flow language interpreter (a flow engine) to actually implement all the service functionality with no other input than the service flow specification itself. Typically, this level of description is not published, because it may reveal details of the hosting enterprise's operation or its trade secrets. The complete flow is in this case referred to as the private flow of the service. A simplified flow is published instead, containing just the information partners need to interact with the service. This public flow differs from the private one only in the level of detail provided, not in the underlying representation model. The section Public and Private Flows; deals with public flows.
Service composition is the second fundamental concept that is required to represent complex service interactions. Composition refers to the act of putting together two or more existing services to provide new functionality not present in the original ones, either in the form of a new service or in the form of a distributed service interaction. A flow typically accesses other Web services in the course of its operation, thus becoming a composition of services itself: It defines a usage pattern for existing services and optionally offers the composed functionality as a new service. A second type of composition occurs when multiple services interact following a certain interaction pattern to achieve some business goal. The nature of this composition is intrinsically distributed: Unlike the flow-based composition, these compositions are not orchestrated from a single point of control or flow engine. Service composition in WSFL is described in some detail in Flows as Compositions of Web Services; and Global Models.
The rest of this chapter develops the themes outlined here in some detail, using the flow depicted in Figure 18.1 to introduce the basic concepts of service process and service composition. You will notice a significant difference between this and other chapters in the book: There is no Java code provided here. The reason, obviously, is that there is no support available yet for any of the proposed Web services flow languages. The goal of this chapter is thus limited to introducing the fundamental concepts of service flows and compositions.
Cell phone ordering service sample flow.
Flow Modeling Concepts
In WSFL, flow models are used for the specification of complex interactions of services. A flow model describes a usage pattern of a collection of available services, so that the composition of those services provides the functionality needed to achieve a certain business goalthat is, the composition describes a business process. The flow model specifies precisely how those services (steps in the flow) are combined, specifying in which order they have to be performed (including the possibility of concurrent execution), the conditional logic deciding whether an individual step or a group of steps have to be performed at all or should be looped, and the passing of data between the involved steps.Figure 18.1 shows an example of a flow model describing a simplified ordering process for a cell phone that continues and evolves throughout this chapter. It consists of a set of business tasks that are executed in a certain order, although some tasks may be skipped. The example flow starts with the receipt of an order for a new cell phone. If the requestor is not known as a customer, the credit history is checked first, and then a customer account is created. Neither of these tasks need to be done for an existing customer. Depending on retrieved knowledge about the requestor, the order might be rejected. Otherwise, the order is processed. The credit card is charged, a bill is sent, a new phone number is assigned, the phone is sent, and so is a note informing of its delivery.
Data produced by a certain task in the flow may be used by a subsequent task; for example, the customer account data is used to send the bill.
From the example, you can already see that the key ingredients for the description of a flow model are the individual business tasks that have to be executed, the specification of the control flow describing the order of their execution and the conditional logic, and the specification of the associated data flow describing the passing of data between them. In WSFL, those three concepts are described by activities, control links, and data links.
An activity is a single step in a flow. It represents a business task that potentially has to be performed as part of the business process the flow model describes. Whether it is actually performed during the execution of a specific flow depends on the conditional logic of the control flow into which it is embedded.
WSFL distinguishes between an activity and its implementation. The implementation describes an actual operation that is invoked when the activity is reached during execution of the flow. The activity, on the other hand, describes how this operation is embedded into the flow. An operation in this context can be anything needed to realize the particular business task. The most obvious realization is the invocation of a piece of code. Another very common realization in existing workflow products is the involvement of human beings performing a task manually.
In the example, the CheckCreditHistory activity is described by the following WSFL fragment:
<activity name="CheckCreditHistory"> <input name="CustomerData" message="tns:Customer"/> <output name="Result" message="tns:CreditWorthiness"/> <implement> <internal> <!-- Implementation is provided by check method of an EJB -- outside WSFL scope --> <ns1:ejbMethod xmlns:ns1="..." ejbNameJndiName="/finance/creditHistory" operation="check" /> </internal> </implement> <!-- Other properties describing embedding into (control and data) flow --> </activity>
The fragment specifies that the CheckCreditHistory task expects a message of type Customer and produces a message of type CreditWorthiness. Both messages are WSDL messages as described Chapter 11.
The tns (this name space) prefix is needed because messages are actually XML-qualified names that are qualified by associated name spaces.
For the example, we assume that the activity is implemented by a certain EJB's check method. Note that the specification of the actual implementation is from a different name space, because WSFL addresses this as an extensibility element outside the WSFL scope.
Additional properties of the activity relate to its embedding into the control and data flow, which is covered in the following section.
The control flow of a flow model specifies the execution order of the individual business tasks to be performed, and the conditional logic specifying whether they should be performed at all, or possibly looped. The need for executing two business tasks in a certain order follows from logical dependencies between them; if no such dependency exists, they can be performed concurrently, thus speeding up the execution of the flow.
In WSFL, a control link is a relationship between two activities, A1 and A2,that prescribes an execution order: A1 has to be completed before A2 can be started. In WSFL, the set of all activities and the set of all control links together describe a directed, acyclic graph.Figure 18.2 has more control flow detail for the first part of the example flow model. Here, the control link between the ReceiveOrder activity and CheckCreditHistory activity indicates that the latter cannot be started until the former has completed. Whether it is actually started depends on the control link's optional transition condition attribute, which is evaluated at the flow's run-time. Depending on that evaluation, control is either passed along the control link, or the control link marks the start of a dead path, which is eliminated from the flow during its run-time.
WSFL doesn't distinguish between alternate branches where one is taken depending on a certain condition (switch) and parallel branches that are all taken concurrently (fork). In the WSFL model, multiple control links originating from the same activity always denote a fork, possibly followed by a dead-path elimination of some of the parallel branches.
Flow model: control links, transition conditions, and join conditions.
In the example, the following lines specify that this path is to be taken only if the activity ReceiveOrder returned no customer ID, that is, when nothing is known about the customer:
<controlLink source="ReceiveOrder" target="CheckCreditHistory" transitionCondition="customer/id=null" />
The two control links leading to the ChargeCreditCard activity specify a control join, stating that this activity can be started only after both the ReceiveOrder and CreateCustomerAccount activities are complete. Completion is achieved either by successful execution or by dead path elimination. When an activity is the target of more than one control link, a WSFL join element associated with the activity describes how the activity is dealt with.
In the example, the following lines state that the ChargeCreditCard activity is executed only after all its incoming control links have been evaluated, synchronizing the parallel paths (deferred evaluation of the join element, the only option currently offered by WSFL), and only if at least one of those control links evaluated to true:
<activity name="ChargeCreditCard"> <input name="CreditCardData" message="tns:CreditCard"/> <output name="Result" message="tns:CreditCardChargeRecord"/> <implement>...</implement> <join condition="link1 OR link2" when="deferred" /> </activity> <controlLink name="link1" source="ReceiveOrder" target="ChargeCreditCard" transitionCondition="customer/id != null && customer/credit=ok " /> <controlLink name="link2" source="CreateCustomerAccount" target="ChargeCreditCard" />
Page 1 of 4