Granville Miller

Subscribe to Granville Miller: eMailAlertsEmail Alerts
Get Granville Miller: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

Automating Business Processes with WSFL and BPEL4WS

Automating Business Processes with WSFL and BPEL4WS

As we strive to add more value to the business as computing professionals, the marriage of business processes and Web services provides opportunities to get closer to our business colleagues.

The business process scripting languages, Web Services Flow Language (WSFL) and Business Process Execution Language (BPEL), provide a mechanism for integrating Web services to form cohesive business processes. The first step is to create models of your business. This is followed by a combination of development and business process engineering activities. Simulation of the business process can be used to "try out" the new process. Finally, J2EE technology can be used to roll out scalable, enterprise-level applications.

The real value behind any new technology comes from its ability to help us solve real problems. Technology provides its greatest value when it can be used to solve whole classes of problems across many diverse areas. One of the recent additions to our technology repertoire is Web services. The technology behind Web services is a set of XML-based access and description languages. However, the idea behind Web services is much more than description and access technologies. The intent is that they are coarse-grained services that provide tangible business value.

Originally, Web services were desired as a method to make business services available externally. Certainly Web services could be made available via a universal directory where people could discover and utilize these services over the Internet. However, Web services are more likely to be found internally as initial applications of this technology tend to focus on automating business processes.

Much of the automation of today's business processes can be found in a combination of systems. Some may be legacy systems, written using outdated software technology. Packaged solutions that provide interfaces to generic business services may automate another part of a business process. Finally, there may be areas of a business process for which existing systems cannot provide automation. These areas must be written as part of new business initiatives.

Web service technology can provide a ubiquitous interface to all of these systems. As a result, Web service technology provides the ultimate "glue" for integrating legacy systems, packaged solutions, and new technologies into solutions that automate or partially automate business processes. The concept of assembling a set of Web services to provide a solution that meets a business process need is called Web service orchestration.

Web service orchestration knits together a series of Web services to provide support for a business process. Each Web service provides support for an activity within the workflow. As each activity is completed, the flow provided moves the user to the next activity. A path through a set of activities is followed until the business process is completed. Multiple paths may reflect exceptions that can occur and the remedies for those exceptions if an activity is not completed successfully.

This sequence of activities can be depicted using a UML activity diagram (see Figure 1). In the activity diagram, the boxes represent the activities, while the links between the activities represent the flow between them. Activity diagrams are commonly used to represent flow between activities in business processes. Activity diagrams are a visual representation of a business process that is easy to understand and communicate.

Flow Languages
To make Web service orchestration easier, IBM created WSFL, which connects Web services to provide Web service orchestration. It is an XML-based language that provides the ability to describe workflows and to call Web services to orchestrate the workflow. The idea behind WSFL is that it is easier to build flows in a language specifically meant for this (especially when it is driven pictorially), rather than a high-level multipurpose language such as Java.

Of course, WSFL becomes Java when it is deployed to WebSphere, but the implementation details are unimportant to those seeking to rapidly deliver business solutions in this fashion. Instead, WSFL can be used to quickly prototype the business process changes necessary to continually engineer business processes. New Web services can be written to fill out these new processes in high-level languages such as Java, supporting the newly engineered activities.

A succeeding language to WSFL is Business Process Execution Language for Web Services (BPEL4WS). This new flow language is a joint collaboration between IBM, BEA, and Microsoft. The basic ideas behind BPEL4WS are similar to those behind WSFL and the Microsoft flow language, XLANG. Though both WSFL and BPEL4WS are XML-based, their syntax is slightly different.

Flow Language Concepts
Let's look at a simple business process to understand workflow and flow languages. Let's consider a simple loan processing process. We can divide loan processing into the following activities:

  • Submit loan request
  • Validate credit references
  • Evaluate loan request
  • Book loan
There are many types of people or roles involved in this high-level business process. The applicant performs the first activity, submit loan request. The loan clerk validates the credit references and books the loan. The loan officer evaluates the loan request. Each of these activities would normally be divided into small subactivities. However, for the purposes of this example, let's assume that these are each atomic (nondecomposable) activities with simple succeed or fail results.

In WSFL, the roles are called service providers (partners in BPEL4WS). Service providers are the class of people responsible for performing the given activity. The activities in the business process are called activities in WSFL, and we always associate a role with each activity to show who performs it. The initial WSFL for the simple loan processing process is shown in Listing 1.

In our implement section, we would specify the name of the Web service that implements the activity.

This flow definition defines the service providers and the activities, but it does not define the flow of activities within the process. Control flow is determined by WSFL structures called control links and data flow is determined by data links. A control link specifies a source and a target activity and links the two activities together. The control flows from the source to the target, setting up a sequential flow of control across the activities.

<controlLink source="submitLoanRequest"
target="validateCreditReferences" />

Data links show how data moves from activity to another. For example, the loan application is clearly used in all of the activities. The application is created in the first activity and is propagated to the next. The WSFL would look like:

<dataLink source="submitLoanRequest"
target="validateCreditReferences">
<map sourceMessage="loanApplication"
targetMessage=" loanApplication" />
</dataLink>

Conditional control and data links allow multiple flows across the activities. This handles the many exception conditions that arise in normal business processes.

Implementation
There are many ways to invoke Web services using flow languages. The most straightforward is to invoke a Web service as a remote procedure call in a synchronous manner. Activities can be synchronous when they can be processed in a reasonable amount of time. However, there are often activities whose response cannot be determined in what we would consider a reasonable amount of time. They may have dependencies on other activities, such as a loan officer approval. Activities with dependencies or that require larger amounts of time to complete may require a flow language to exhibit asynchronous behavior.

In BPEL4WS, there are three ways that things can be done inside a flow. A flow can invoke a Web service, send a message (called a reply), or receive a message. Invoking a Web service corresponds to performing an activity. Sending messages and receiving replies allows activities to be performed concurrently or asynchronously.

The send and receive behavior also allows multiple roles to be coordinated. As loan requests are submitted by customers, credit references can be validated by the clerks. The process moves this way through its transitions until the final loan information is replied back to the customer. The corresponding BPEL4WS code looks like that in Listing 2.

Turning Into Java
WSFL and BPEL4WS were meant to be deployed to application servers such as WebSphere. The common complaint with scripting languages is their speed and scalability. This area is covered with these two flow languages. An interesting feature of flow languages is their recursive composition, or their ability to become Web services themselves. Each flow is itself a Web service and can be called by another flow. This allows processes to be decomposed into subprocesses that can be decomposed into activities.

A subprocess can then be rewritten in Java and exposed as a Web service for the flow language to call. The idea is that you break Web service flows into granular pieces and if performance becomes an issue, build them into the coarse-grained flows that perform best on the server side.

Finally, business process simulation is always a good idea when engineering your business process. Web services can quickly be made in Java and "stubbed" into a new business process to "try it out." In this way, we can prototype new business processes without a whole lot of investment. Rapid application development products such as WebSphere Studio Application Developer IE and Together WebSphere Edition can help you model and build business process prototypes quickly and easily.

Conclusion
The climate for business process modeling and development is rapidly converging on the set of tools necessary to deliver business value in the Web services arena. Paramount to this process are the Web service flow languages that allow rapid development of business processes using Web service components. These languages can be utilized to engineer business processes for more efficient operations.

References

  • Curbera, F.; Goland, Y.; Klein, J.; Leymann, F.; Roller, D.; Thatte, S.; Weerawarana, S. Business Process Execution Language for Web Services, Version 1.0. www-106.ibm.com/developerworks/webservices/ library/ws-bpel
  • Leymann, F. Web Services Flow Language (WSFL 1.0). www-3.ibm.com/software/solutions/webservices/ pdf/WSFL.pdf
  • More Stories By Granville Miller

    Granville Miller has over 15 years of experience in the object-oriented
    community. He is coauthor of the Advanced Use Case Modeling series and A Practical Guide to Extreme Programming. Granville currently directs strategy for the TogetherSoft line of products.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.