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.
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.
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>
|
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).
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.
- Be sure to check out the three previous installments of this column: Part 2, Part 3, and Part 4.
-
Read the WSFL specification.
-
Check out the Business Process Modeling resources catalogued at Google.
-
Learn about SOAP, WSDL,
and UDDI.
-
Learn about BPML, ebXML,
and the Workflow Management Coalition.
(I'll compare and contrast each of these with WSFL in a future installment.)
- See more dW Web services resources.
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.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
