Modeling BPEL4WS

By: Richard Gronback

Abstract: How does Model-Driven Architecture (MDA) relate to Business Process Modeling (BPM)? This session explores how these modeling technologies and their underlying languages relate today and how they will likely be used in the future.

Modeling BPEL4WS

Richard C. Gronback - Borland Software Corporation

Introduction to BPM

BPEL4WS

Modeling BPEL4WS

BPMN

UML

BPDM

Deployment

Conclusion

Appendix A

References

Introduction to BPM

The abbreviation BPM stands for many things, depending on who you ask.  To some, it stands for Business Process Modeling, to others it’s Business Process Management, and still to others, it stands for British Postgraduate Musicology.  In this paper, we will take a look at how to model a business process, specifically in the context of the specification for Business Process Modeling for Web Services, or BPEL4WS (BPEL for short).

There are literally hundreds of tools, notations, and methodologies associated with the concept of business modeling.  In general, it means the design, execution, maintenance, and optimization of business processes.  In the context of describing a business process using BPEL4WS, we are more interested in which portions of a business process are automated using computer software.  More specifically, BPEL4WS involves only automating processes which invoke Web Services, which are defined using Web Services Definition, or WSDL.  In this paper, we are not so much interested in the particulars of BPEL4WS, as we are in modeling it using a standard notation and metamodel mapping.

When it comes to standards around business process, the Business Process Management Initiative website (http://www.bpmi.org) is a good place to start.  This non-profit organization has developed several specifications, including: Business Process Modeling Language (BPML), Business Process Modeling Notation (BPMN), and Business Process Query Language (BPQL).  The BPMI focuses on the internal, or private implementation of business processes, while ebXML and RosettaNet focus on external interfaces.

BPEL4WS

Business Process Execution Language for Web Services got its start from IBM’s Web Service Flow Language (WSFL), and Microsoft’s XLANG initiatives.  The specification is authored by IBM, Microsoft, BEA, SAP, and Seibel Systems.  The specification defines a model and grammar for describing the behavior of a business process based on interactions between the process and its parents.  The use of Web Services is essential to BPEL4WS, which allows for the modeling of executable and abstract processes, and is based upon WSDL, XML Schema, and Xpath standards.

There are several key core concepts of BPEL: partner links, variables, correlation sets, fault handlers, and activities.  The key concepts will be covered briefly here, while the complete specification can be found at [BPEL4WS].  Appendix A of this document contains a brief summary of the BPEL4WS syntax, as found in the specification.

 

Modeling BPEL4WS

The readability of XML being what it is, the prospect of hand-coding *.bpel files is clearly not attractive.  The prospect of modeling BPEL should be obvious to anyone familiar with UML Activity and other workflow-style diagrams.  Unfortunately, the BPEL4WS specification provides no visual notation, which leaves several options for an alternative.

It would be seemingly straightforward to declare WSDL defnitions with UML Class diagrams and model business process definitions using UML Activity diagrams.  In fact, there is a profile for doing this and is a viable solution.  However, there are other competing notations which are arguably easier for a business modeler to understand and work with, the Business Process Modeling Notation, in particular.  We will explore a few approaches to the modeling of BPEL in this section.

Prior to examining each notation and its mapping to BPEL4WS, a note about MDA®.   Model-Driven Architecture® in an OMG initiative and collection of standards to promote model-based development of software systems.  Its aim is to drive models toward their place as first-class development artifacts, from which code targeting potentially several platforms can be generated with some degree of completeness.  

In the terminology of MDA, general business process modeling falls in the scope of a Computation-Independent Model (CIM).  From these overarching models, portions may be extracted that can be manifested in software applications.  These are referred to as Platform-Independent Models (PIM).  In the context of business process modeling, a general-purpose language such as BPMN would be used for CIM, while a subset of BPMN used to map to BPEL4WS would comprise a PIM.  The modeling of Web Services utilized within the context of a BPEL process could be considered a Platform-Specific Model, or PSM.

BPMN

As mentioned above, a recent standard provided by BPMI.org defines a graphical notation for the modeling of business processes.  This notation is the merger of many notations and far exceeds the notational capabilities required to model BPEL4WS.  Fortunately, the specification provides a mapping of BPMN to BPEL4WS.

BPMN defines elements of Business Process Diagrams (BPDs), for which there are four categories: flow objects, connecting objects, swimlanes, and artifacts.

Flow objects consist of three core elements:

·        Events

o       Start, Intermediate, and End

·        Activities

o       Task and Sub-Process “work” elements

·        Gateways

o       Decisions, forks, joins, and merges

Connecting objects are represented in three ways:

·        Sequence flows

o       Indicates order of activities

·        Message flows

o       Indicates flow of messages between Process Participants

·        Associations

o       Associates data, text, or other Artifacts with flow objects

A simple business process is provided below to illustrate the elements described above.

Swimlanes are used in BPDs to organize activities by responsibility or functional capability.  There are two swimlane elements: pools and lanes.  A Pool represents a Participant in a process.  A Lane is a sub-partition within a Pool used to organize and categorize activities.

Artifacts are used on diagrams and come in three predefined types:

·        Data objects

o       Show how data is required or produced by activities

·        Groups

o       Used for documentation or analysis, but does not affect the sequence flow

·        Annotations

o       Allow for textual notes to be added

Another example diagram of a simple process is provided below to illustrate swimlanes and artifacts.

In order to utilize BPMN for BPEL4WS modeling, mappings are provided from BPD elements to BPEL elements.  It is a rather straightforward mapping, but not without complications and/or limitations.  The basic mappings are illustrated in the diagram below:

UML

The UML metamodel is more than adequate for business process modeling, particularly the UML2 metamodel.   A profile applied to the UML will allow for representing BPEL elements with Activity diagrams.  Additionally, WSDL files are modeled using UML Class diagrams.

One such profile is defined on the AlphaWorks website from IBM.  This is an informal profile used to illustrate the process of exporting a UML model with profile markup, to an XMI file, which is then transformed into a *.bpel and *.wsdl files.  These files are then deployed to the BPWS4J execution engine, which comes with the Emerging Technologies Toolkit (ETTK).  An example of the profile used on both Class and Activity diagrams is below, along with the process of transformation.

AlphaWorks UML Profile for BPEL4WS

AlphaWorks Process for UMLà BPEL4WS Transformation

For a more formalized approach to using the UML metamodel as the basis for modeling BPEL4WS, we will next take a look at the Business Process Definition Metamodel (BPDM).

BPDM

The striking similarity between BPMN and UML2 Activity diagrams is no surprise to the standards bodies behind each.  Work is underway to bring them closer together, and at the metamodel level.

Currently, however, there are a number of mappings defined in the present version of the BPDM specification.  Note that the BPDM provides a metamodel and notation.  The following list of profiles and mappings are defined in the specification:

·        UML 2.0 Profile for BPD

·        UML 1.5 Profile for BPEL4WS

·        Mapping from BPD metamodel to BPEL4WS

·        Mapping from EDOC to BPD metamodel

·        Mapping from BPMN to BPD metamodel

So, how many options are there for modeling BPEL4WS?  Too many?

Let’s take a look at the notation provided by the BPDM.  The basic categories of elements are: services and processes, tasks, pins and flows, and miscellaneous elements.

In the services and processes category, there are three major elements:

·        Service Specification

o       Defines one or more interfaces, that in turn, define one or more messages that flow in and out of the service

·        Service Provider

o       Represents a logical grouping of service implementations.  There is also a notion of a Service Provider application that is a grouping of service specifications.

·        Process

o       A process has Message Pins that may be wired directly to Task Pins.  Send/Receive tasks may also be used to communicate messages.

There are several Task element types and Pin notations.  Tasks themselves are represented by rounded-corner rectangles with a Name and optional Performer marking.  In general, Pins represent both data and control inputs/outputs for tasks.  Below is a listing of various Task/Pin notations:

·        Decision

·        Alternative Inputs

·        Multiple Parts

·        Alternative Sources

·        Parallel Branch

·        Timer Task

·        Send

·        Receive

·        Embedded Process

·        Foreach

Pins and Flows come in nine varieties, described below:

§         Control flow

§         Data and control flow

§         Exception flow

§         Ticket flow

§         Start of control

§         Completion of flow

§         Completion of process

§         Goto connection

§         Message flow

The diagram below provides examples of these element notations:

Two miscellaneous elements are found in the BPDM notation: Data store and Notes.  These are fairly standard notational elements, examples of which are below:

Below are some sample BPDM diagrams of simple business processes:

Basic Parts Procurement Diagram using BPDM

Basic Request Credit Diagram using BPDM

Deployment

After taking the time and effort to model a BPEL4WS process, what does one do with it?  In order to take advantage of the model, it must be transformed into a *.bpel file and deployed to an execution environment.

There is at least one open source project, ActiveBPEL, which provides an execution environment.  Other commercial products that support BPEL are available, including ones from IBM, Oracle, Microsoft, and others.  These products typically come with their own development environments, and in the case of the Oracle BPEL Designer product, utilizes a proprietary notation that is a direct mapping from the underlying BPEL source.

As BPEL becomes more mature and as the standards unify on a common metamodel, it should become more common to model and transform these diagrams and deploy to a runtime in much the same way it is done for J2EE.  In fact, BPEL deployment in conjunction with J2EE deployments may become commonplace.

Conclusion 

There are several competing notations and metamodel mappings for modeling BPEL4WS.  Tool support ranges considerably in this space, which is symptomatic of the standards issue.  It appears the BPMN will be adopted for general business process modeling needs, and as it has a mapping to BPEL4WS may be the best approach.  However, as the metamodel likely to become the standard for BPMN has its own notation, there is likely to be remaining confusion in this space.  Below are samples of the same process modeled using BPDM, BPMN, and a UML 2.0 Activity diagram.  Each of these have defined mappings to BPEL4WS to allow for generation of *.bpel files for deployment to a compliant runtime engine.

UML2 Diagram of Trouble Ticket Process

BPMN Diagram of Trouble Ticket Process

BPDM Diagram of Trouble Ticket Process

BPEL4WS Diagram of Trouble Ticket Process

Appendix A

The basic structure of the BPEL4WS language is:

<process name="ncname"

         targetNamespace ="uri"

         queryLanguage ="anyURI"?

         expressionLanguage ="anyURI"?

         suppressJoinFailure ="yes|no"?

         enableInstanceCompensation ="yes|no"?

         abstractProcess ="yes|no"?

         xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/">

   < partnerLinks >?

      <!-- Note: At least one role must be specified. -->

      <partnerLink name="ncname"

                   partnerLinkType ="qname"

                   myRole ="ncname"?

                   partnerRole ="ncname"?>+

      </partnerLink>

   </partnerLinks>

    

   < partners >?

      <partner name="ncname">+

         <partnerLink name="ncname"/>+

      </partner>

   </partners>

   < variables >?

      <variable name="ncname"

                messageType ="qname"?

                type ="qname"?

                element ="qname"?/>+

   </variables>

   < correlationSets >?

      <correlationSet name="ncname" properties="qname-list"/>+

   </correlationSets>

   < faultHandlers >?

      <!-- Note: There must be at least one fault handler or default. -->

      <catch faultName="qname"? faultVariable ="ncname"?>*

         activity

      </catch>

      < catchAll >?

         activity

      </catchAll>

   </faultHandlers>

   < compensationHandler >?

      activity

   </compensationHandler>

   < eventHandlers >?

      <!-- Note: There must be at least one onMessage or onAlarm handler. -->

      <onMessage partnerLink="ncname"

                 portType ="qname"

                 operation ="ncname"

                 variable ="ncname"?>

    

         < correlations >?

            <correlation set="ncname" initiate="yes|no"?>+

         < correlations >

         activity

      </onMessage>

      <onAlarm for="duration-expr"? until ="deadline-expr"?>*

         activity

      </onAlarm>

   </eventHandlers>

   activity

</process>

The token activity can be any of the following:

  • <receive>              <reply>                  <invoke>               <assign>               <throw>
  • <terminate>          <wait>                    <empty>                <sequence>           <switch>
  • <while>                  <pick>                   <flow>                    <scope>                 <compensate>

The syntax of each of these elements, except <terminate>, is considered in the following paragraphs.

The <receive> construct allows the business process to do a blocking wait for a matching message to arrive.

<receive partnerLink="ncname"

         portType ="qname"

         operation ="ncname"

         variable ="ncname"?

         createInstance ="yes|no"?

         standard-attributes>

    

   standard-elements

    

   < correlations >?

      <correlation set="ncname" initiate="yes|no"?>+

   </correlations>

</receive>

The <reply> construct allows the business process to send a message in reply to a message that was received through a <receive>. The combination of a <receive> and a <reply> forms a request-response operation on the WSDL portType for the process.

<reply partnerLink="ncname"

       portType ="qname"

       operation ="ncname"

       variable ="ncname"?

       faultName ="qname"?

       standard-attributes>

    

   standard-elements

    

   < correlations >?

      <correlation set="ncname" initiate="yes|no"?>+

   </correlations>

</reply>

The <invoke> construct allows the business process to invoke a one-way or requestresponse operation on a portType offered by a partner.

<invoke partnerLink="ncname"

        portType ="qname"

        operation ="ncname"

        inputVariable ="ncname"?

        outputVariable ="ncname"?

        standard-attributes>

    

   standard-elements

    

   < correlations >?

      <correlation set="ncname"

                   initiate ="yes|no"?

                   pattern ="in|out|out-in"/>+

   </correlations>

    

   <catch faultName="qname" faultVariable="ncname"?>*

      activity

   </catch>

   < catchAll >?

      activity

   </catchAll>

   < compensationHandler >?

      activity

   </compensationHandler>

</invoke>

The <assign> construct can be used to update the values of variables with new data. An <assign> construct can contain any number of elementary assignments.  The syntax of the assignment activity is:

<assign standard-attributes>

   standard-elements

   < copy >+

      from-spec

      to-spec

   </copy>

</assign>

The <throw> construct generates a fault from inside the business process.

<throw faultName="qname"

       faultVariable ="ncname"?

       standard-attributes>

   standard-elements

</throw>

The <wait> construct allows you to wait for a given time period or until a certain time has passed.  Exactly one of the expiration criteria must be specified.

<wait (for="duration-expr" | until="deadline-expr")

      standard-attributes>

   standard-elements

</wait>

The <empty> construct allows you to insert a "no-op" instruction into a business process.  This is useful for synchronization of concurrent activities, for instance.

<empty standard-attributes>

   standard-elements

</empty>

The <sequence> construct allows you to define a collection of activities to be performed sequentially in lexical order.

<sequence standard-attributes>

   standard-elements

   activity+

</sequence>

The <switch> construct allows you to select exactly one branch of activity from a set of choices.

<switch standard-attributes>

   standard-elements

   <case condition="bool-expr">+

      activity

   </case>

   < otherwise >?

      activity

   </otherwise>

</switch>

The <while> construct allows you to indicate that an activity is to be repeated until a certain success criteria has been met.

<while condition="bool-expr" standard-attributes>

   standard-elements

   activity

</while>

The <pick> construct allows you to block and wait for a suitable message to arrive or for a time-out alarm to go off.  When one of these triggers occurs, the associated activity is performed and the pick completes.

<pick createInstance="yes|no"?

   standard-attributes>

   standard-elements

   <onMessage partnerLink="ncname"

              portType ="qname"

              operation ="ncname"

              variable ="ncname"?>+

      < correlations >?

         <correlation set="ncname" initiate="yes|no"?>+

      </correlations>

   activity

   </onMessage>

   <onAlarm (for="duration-expr" | until="deadline-expr")>*

      activity

   </onAlarm>

</pick>

The <flow> construct allows you to specify one or more activities to be performed concurrently.  Links can be used within concurrent activities to define arbitrary control structures.

<flow standard-attributes>

   standard-elements

   < links >?

      <link name="ncname">+

   </links>

   activity+

</flow>

The <scope> construct allows you to define a nested activity with its own associated variables, fault handlers, and compensation handler.

<scope variableAccessSerializable="yes|no"

   standard-attributes>

   standard-elements

   < variables >?

      ... see above under <process> for syntax ...

   </variables>

   < correlationSets >?

      ... see above under <process> for syntax ...

   </correlationSets>

   < faultHandlers >?

      ... see above under <process> for syntax ...

   </faultHandlers>

   < compensationHandler >?

      ... see above under <process> for syntax ...

   </compensationHandler>

    

   < eventHandlers >?

      ...

   </eventHandlers>

   activity

</scope>

The <compensate> construct is used to invoke compensation on an inner scope that has already completed normally.  This construct can be invoked only from within a fault handler or another compensation handler.

<compensate scope="ncname"?

   standard-attributes>

   standard-elements

</compensate>

Note that the standard-attributes referred to above are:

name ="ncname"?

joinCondition ="bool-expr"?

suppressJoinFailure ="yes|no"?

where the default values are as follows:

·        name. No default value (that is, unnamed)

·        joinCondition. The logical OR of the liveness status of all links that are targeted at this activity

·        suppressJoinFailure. No

and that the standard-elements referred to above are:

<target linkName="ncname"/>*

<source linkName="ncname" transitionCondition="bool-expr"?/ >*

where the default value of the "transitionCondition" attribute is "true()", the truth-value function from the default expression language XPath 1.0.

References

[BPEL4WS] Business Process Execution Language for Web Services, Version 1.1, May 05, 2003.  http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/

[BPDM] Business Process Definition Metamodel, Version 1.0.2, August 02, 2004.  http://www.omg.org/cgi-bin/apps/doc?bei/04-08-03.pdf

[BPMN] Business Process Modeling Notation, Version 1.0, May 03, 2004.  http://www.bpmi.org/specifications.esp

[UML2BPEL] K. Mantell, “From UML to BPEL: Model Driven Architecture in a Web Services World” September 09, 2003. http://www-106.ibm.com/developerworks/webservices/library/ws-uml2bpel/


Published on: 10/11/2004 2:17:57 PM

Server Response from: ETNASC01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.