JavaWeb-based JavaWeb Services and Flows (WSFL)

Web Services and Flows (WSFL) content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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)

Chapter 18: Web Services and
Flows (WSFL)

By Francisco Curbera and Matthias Kloppmann

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
  • References

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
setting—that 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 parties—a customer, an
e-commerce retailer, and a shipper—as 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.

Figure 18.1
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 goal—that 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"/>
   <!-- Implementation is provided by check method of
      an EJB -- outside WSFL scope -->
   <ns1:ejbMethod xmlns_ns1="..."
           operation="check" />
 <!-- Other properties describing embedding into
    (control and data) flow -->

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

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories