Version 22

    BPEL process context



    This diagram shows the overall process deployment of a bpel process.

    The picture shows the context for one process.  Of course the bpel

    engine should support multiple processes.  The wsdls (PortType's) are

    referenced from the bpel process definition.


    At runtime the container is responsible for publishing the web-service

    endpoints for sending messages to process instances.  These endpoints are

    bound to a process definition.  So when a message arrives at such an endpoint,

    the first thing that needs to be done is figure out to which process

    instance this message needs to be routed.  This covered by message correlation.


    A property specifies a data-item in an message with e.g. an XPath expression.

    A correlation set is a set of properties that indicate how incoming messages

    are related to process instances.


    BPEL process



    Apart from some decorations such as variables, correlation sets, fault handlers,

    compensation handlers and event handlers, the essence of a BPEL process is its

    activity.  The activity is a program with instructions and control structures like

    a very basic programming language.


    BPEL partner



    A BPEL process definition refers to external actors as partners.  The interactions

    between partners and the process are expressed in WSDL (PortType).   So the target

    environment for this specification is an environment where the complete architecture

    is standardized on web services.  Note that it is possible to bind WSDL to in-JVM

    method calls.  But regrettably this is waaaay inefficient.  For a method call like

    e.g. partnerIf.send( invoice ); you would have to specify the WSDL and

    perform binding it at runtime.


    BPEL activities



    Activities are modeled as a composite patterns which means that

    the top level activity most likely is a structured activity.  Structured activities

    contain other activities.  Basic activities are just operations.  The activities

    of BPEL form the analogue of a programming language.  The structured activities

    are used for control flow, the basic acitivies are operations.


    Translating BPEL processes


    During this analysis it has become clear that it is possible to implement

    a bpel workflow engine on the basis of the nwsp architecture.


    A bpel process definition will be translated into a nwsp process definition.

    The bpel activities will be translated into a mix of nwsp states and observers.

    Since bpel is a block-structured process language and the proposed model has a

    free-flow graph structure, translation is rather straightforward.


    See also From UML to BPEL - Model Driven Architecture in a Web services world


    Basic bpel activities

    • receive --> state

    • wait --> state or milestone

    • reply --> observer that invokes a webservice

    • invoke --> observer that invokes a webservice

    • throw --> observer that manipulates the state of the process instance

    • empty --> no translation necessary

    • assign --> observer that stores signal-data into a variable

    • terminate --> observer that cancels the process instance


    Structured bpel activities

    • flow --> fork & join

    • sequence --> sequence of states or observers

    • switch --> decision

    • pick --> state with multiple leaving transitions

    • while --> decision at end of block with a loopback transition


    BPEL Links


    BPEL Cookbook Sample Chapter

    • [ Building Rich Internet Applications for Workflow and Process Monitoring



    BPEL Tutorial


    BPEL intellectual property and licensing


    Referenced by: