 | Level: Introductory James Snell (jasnell@us.ibm.com), Software engineer, IBM, Emerging Technologies
01 Jul 2001 In the last installment of the Web services insider, I introduced you to the basic principles of the Web Services Flow Language (WSFL). In this installment, I follow up on my promise to walk through the steps of designing and creating a business process model implemented with WSFL.
Business process modeling is not a discipline that
comes easily to many developers, primarily because it goes
quite a bit beyond simply downloading a snippet of code and tinkering around
with it. We might as well admit the fact that we developers can be a fairly
lazy lot at times. And proper business modeling takes time, and it requires
the ability to take in the big picture of not only how the particular kibbles'n'bits
of an application are to be assembled, but also how that application fits
into an overall architecture geared towards solving some distinct business
goal.
In the previous issue (see Resources), I took
some time to introduce you to a new specification geared towards implementing
business processes within the framework of the Web services architecture.
The WSFL enables developers to easily create, execute, and
combine Web services into complex processes and workflows.
In this installment of the Web services insider, I'll explore how to create an implementation
of a WSFL business process starting with an introduction to the basic principles
of business process modeling in general. This will be a fairly high level
discussion, however, glossing over many of the more complicated issues
and in some cases completely ignoring others. What is important to keep
in mind is that this is merely an introduction designed to get you started
in the right direction. I would strongly recommend that you follow up with
the resources I have included at the end of this article.
Business processes 101
Far too often, developers tend to look at the applications they are
writing in terms of the technology or function that they are implementing;
an address book here, a shopping cart there, perhaps even instant messaging
or peer-to-peer architectures, etc. Often they fail to take into account
the overall big picture of what those applications need to be used for,
which, in many cases, involves solving some type of critical business need.
At the risk of sounding like I'm beating the company drum, too often
e-business is viewed in terms of the "e" rather than the "business". Business
process modeling attempts to put the "business" back into the picture by
building a framework into that individual applications may be plugged into
fulfill the individual requirements of each step in a process -- be it
the purchase of raw materials for a vehicle assembly line or the hiring
of a new employee or the support of an important customer account. Business
process modeling starts with a picture of what the process looks like as
a whole, broken down in terms of the specific activities that must be completed,
the order in which they must be completed, the dependencies between those
activities, and a definition of who is responsible for making sure those
activities are completed.
Figure 1: A sample business process model
Figure 1 illustrates a simple business process model
shamelessly copied from the WSFL specification. You should notice that
in the above diagram every significant step in the process is identified
and fit into a workflow that defines the specific order in which those
steps must be completed. Whether or not any of those steps can or cannot
be implemented strictly using some Java application or a Web Service or
whatever is irrelevant. In other words, a business process model is about
the chain of events that must occur rather than the specific details about
how those events will occur.
Each oval in Figure 1 represents an activity. Each
activity represents something that must be done by someone or something.
All of the activities are linked together using arrows, called directed
edges, that indicate the flow from one activity to the next. This
flow may either be conditional or unconditional; that is, there may be
rules that specify conditions that must be met in order for the next activity
in the process to be executed. There may also be rules that specify exactly
when a particular activity has been completed or what to do when an error
has occurred. The dotted lines in the graph indicate the flow of information
between activities, which is something that I will explain a bit more in
depth once I get to the part about creating a WSFL global model.
Web services in the big picture
The WSFL casts Web services into the role of
implementing activities within an overall business process, or "flow" model.
In the big picture, this means that individual types of Web services (address
books, instant messaging, credit card verification services, etc.) are of
less importance than the overall workflow that is being implemented, at
least from the point of view of the company wishing to utilize those services.
To put it a different way, the true value of Web services is in how they
better enable developers to actually conduct business or share information rather
than in the individual merits of the Web service itself.
Building the flow model
At this time, I need to point out the fact that WSFL, in and of itself,
is not a specification dealing with how to create a business process model
as much as it is a specification for how to implement a business process
model using the new emerging Web services architecture. In other words,
you don't actually use WSFL to define what your business process model
will look like; that is a job for something along the lines of UML. Rather,
you would use WSFL to create an XML representation of the business model,
then feed that XML-representation into a middleware application designed
to invoke and manage the process (for example, by using IBM's MQSeries
Workflow, or Rational Rose). What you need, then, is to understand how to
translate a business process model diagram into a WSFL flow model.
The process is actually quite simple, and once tools become available
that handle this step behind the scenes, automatically generating
the WSFL flow model based on a graphical business process model, this will
become an issue that you simply won't have to deal with. However, for now,
understanding how things come together in WSFL can help you to understand
its utility and function within the Web services architecture.
Creating a WSFL flow model from a business process model depends on
really nothing more than understanding the function of each of the XML
elements used in the WSFL grammar and understanding the differences between
each significant piece of information communicated in the process model.
In the model, you should notice that there are three distinct roles through
which activities are implemented. These roles represent who is responsible
for implementing the specific activity. For example, the Traveler plans
the trip, the Agent selects the legs of the trip and the Airline issues
the electronic ticket. WSFL requires that you explicitly specify these
roles as part of the process implementation. You would do so using the
WSFL serviceProviderType element.
<definitions name="totalTravel">
<serviceProviderType name="travelerType">
<portType name="abc:ticketBuyer" />
</serviceProviderType>
<serviceProviderType name="agentType">
<portType name="abc:tripHandler" />
<portType name="abc:ticketBuyer" />
</serviceProviderType>
<serviceProviderType name="airlineType">
<portType name="abc:ticketHandler" />
<portType name="abc:ticketDelivery" />
</serviceProviderType>
</definitions>
|
The serviceProviderType element identifies each type of role
within the context of a given business process model and the specific Web
service interfaces (in the form of WSDL-defined portTypes) that must be
implemented by a Web service provider in order to fulfill that role.
In this example, there are actually two different sub processes that
you need to be concerned with: the process of booking the trip and the process
of ordering and issuing the tickets. Each process should generally be modeled
using a different WSDL flowModel. Each flowModel consists
of several pieces of vital information that are necessary for the workflow
engine managing the implementation of the process to do its work. This
information includes:
- the identity of the service providers who are fulfilling
the necessary roles responsible for each activity
- the condition upon which to launch the process (known as a
flowSource)
- the external interface of the process through which information may be passed into or out of the process
- the definition of each activity in terms of how it is implemented
and who is expected to implement it
- and the definition of how control and information is to flow from one activity to the next as the process is executed, including the various exit and start conditions for each activity
and for the process itself.
Unfortunately, I don't have time to go into a tremendous amount of
detail for each of the elements, so what I'll do here is provide just an
example of what a flowModel for purchasing the tickets would look
like. This, again, is an example from the WSFL specification itself, so
to learn more about this particular sample, I recommend that you take the
time to read it.
<flowModel name="bookTickets" serviceProviderType="airlineFlow">
<!-- Defines the start condition for this process,
which in this case is the reception of
a TicketOrder -->
<flowSource name="ticketFlowSource">
<output name="processInstanceData" message="tio:receivedTicketOrder"/>
</flowSource>
<!-- Defines the service providers who will be
implementing this process. The serviceProvider
element offers several ways of uniquely or
dynamically identifying the specific provider
who will be implementing that role. -->
<serviceProvider name="agent" type="agentType"/>
<serviceProvider name="traveler" type="travelerType"/>
<!-- Defines an external interface that allows this
process to be launched. WSFL defines that this
interface is itself a Web Service making it
possible to "spawn" a business process using SOAP
messages, etc. Each export represents an operation
in a WSDL document that describes WSFL Web Services -->
<export lifecycleAction="spawn">
<target portType="tio:ticketHandler" operation="receiveTicketOrder">
<map sourceMessage="receiveTicketOrderInput"
targetMessage="processInstanceData" targetPart="request"/>
<map sourceMessage="processInstanceData"
sourcePart="airlineWorkId"
targetMessage="receiveTicketOrderOutput"
targetPart="airlineWorkId" />
</target>
</export>
<!-- Activities are defined in terms of the WSDL
defined messages that are either received, sent
or both, as well as in terms of who is responsible
for performing that activity. -->
<activity name="reserveSeats">
<input name="reserveSeatsInput" message="tio:receivedTicketOrder"/>
<output name="reserveSeatsOutput" message="tio:reservation"/>
<performedBy serviceProvider="local"/>
<implement>
<internal>
<!-- .. call to reservation system .. -->
<internal/>
</implement>
</activity>
<activity name="chargeCreditCard" >
<input name="dataIn" message="tio:reservation" />
<output name="dataOut" message="tio:chargedReservation"/>
<performedBy serviceProvider="local"/>
<implement>
<internal>
<!-- .. call to credit card service .. -->
</internal>
</implement>
</activity>
<activity name="confirmFlights" >
<input name="confirmFlightsInput" message="tio:chargedReservation"/>
<output name="confirmFlightsOutput" message="tio:eTicketMsg"/>
<performedBy serviceProvider="agent"/>
<implement>
<export portType="tio:ticketHandler" operation="sendConfirmation">
<map sourceMessage="confirmFlightsInput" sourcePart="confirmationInfo"
targetMessage="sendConfirmationOutput" targetPart="confirmationInfo"/>
</export>
</implement>
</activity>
<activity name="issueETicket">
<input name="issueETicketInput" message="tio:eTicketMsg"/>
<performedBy serviceProvider="traveler"/>
<implement>
<export portType="tio:deliverTickets" operation="sendETicket">
<map sourceMessage="issueETicketInput" sourcePart="authorization"
targetMessage="sendETicketOutput" targetPart="authorization"/>
</export>
</implement>
</activity>
<!-- controlLinks represent the directed edges in the process diagram. They are
the arrows that determine the next step in the business process. -->
<controlLink name="rS-cC" source="reserveSeats" target="chargeCreditCard"/>
<controlLink name="cC-cF" source="chargeCreditCard" target="confirmFlights"/>
<controlLink name="cF-sT" source="confirmFlights" target="issueETicket"/>
<!-- dataLinks define the flow of data from activity to another. They represent the
dotted lines that we see in the model diagram -->
<dataLink name="rS-cCdata" source="reserveSeats" target="chargeCreditCard"/>
<dataLink name="gT-rS-data" source= "ticketFlowSource" target="reserveSeats"/>
<dataLink name="cC-cFdata" source="chargeCreditCard" target="confirmFlights"/>
<dataLink name="cF-sTdata" source="confirmFlights" target="issueETicket"/>
</flowModel>
|
 |
Building the global model
Every activity defined in a WSFL flowModel is implemented
in the form of a Web service defined by WSDL. Each activity represents
a operation or combination of operations within a given portType.
Every party fulfilling a role within a given process must properly implement
the portTypes defined by the serviceProviderType element
in the flowModel. What is required then, is a method of mapping
the portTypes and operations implemented by one service provider
with the portTypes and operations implemented by another service
provider so that the control and data links defined within the flowModel
know which operations to invoke for each activity in order to perform the
activity or to exchange information. Now, if you're not sure if that made
much sense, think of it this way: if you're sending me a box of chocolates
-- which I would gladly accept -- you need to know my address. In WSFL,
this address is in the form of an operation on a given Web service interface
and is communicated via a globalModel.
<globalModel name="bookTripNTickets" serviceproviderType="agentType">
<!-- Defines the identity, location and implementation of the service provider
fulfilling the role of the travel agent -->
<serviceProvider name="travelAgent" serviceProviderType="tio:agentType">
<export>
<source portType="tio:tripHandler" operation="sendItinerary"/>
<target portType="tio:tripNTicketHandler"
operation="sendItinerary"/>
</export>
<export>
<source portType="tio:tripHandler" operation="receiveTripOrder"/>
<target portType="tio:tripNTicketHandler"
operation="receiveTripOrder"/>
</export>
<locator type="static" service="Traveluck.com"/>
</serviceProvider>
<!-- Defines the identity, location and implementation of the service provider
fulfilling the role of the airline -->
<serviceProvider name="airline" serviceProviderType="tio:airlineType">
<export>
<source portType="tio:ticketDelivery" operation="sendETicket"/>
<target portType="tio:tripNTicketHandler"
operation="sendETickets"/>
</export>
</serviceProvider>
<!-- A plugLink links the output of an operation of one service provider to the
input of
an operation for another service provider -->
<plugLink>
<source serviceProvider="airline" portType="tio:ticketHandler"
operation="sendConfirmation"/>
<target serviceProvider="travelAgent" portType="tio:tripHandler"
operation="waitForConfirmation"/>
</plugLink>
<plugLink>
<source serviceProvider="travelAgent" portType="tio:tripHandler"
operation="requestTicketOrder"/>
<target serviceProvider="airline" portType="tio:ticketHandler"
operation="receiveTicketOrder"/>
</plugLink>
</globalModel>
|
The separation of the flowModel and the globalModel
allows you to keep the abstract definition of the workflow process (the
flowModel)
separate from the specific details about how a given process has been implemented
(the globalModel).
What's next?
In the next installment of this column, I will discuss what a service provider must do in order to fulfill a role defined by a WSFL flowModel.
That process, along with the ability to recursively compose new business
processes from existing business processes, represents one of the most
powerful and compelling features of WSFL. In the meantime, you may want
to continue your education of business process modeling and WSFL by making
use of the resources listed below.
Resources
About the author | 
| |
James Snell is both an author and a developer and is one of the newest members of the IBM Web Services development team. He comes to IBM with an extensive background in custom enterprise application development and business-to-business integration, and a passion for the cutting edge of Web technology. You can reach him at jasnell@us.ibm.com. |
Rate this page
| |
