Docstoc

Business Process Execution Langu

Document Sample
Business Process Execution Langu Powered By Docstoc
					Business Process Execution
Language for Web Services
       (BPEL4WS)



                             1
             BPEL vs. WSDL
• WSDL supports a stateless model which describes
  operations supported by web servers
   – One or two messages needed for client/server
     communication
   – No mechanism for describing state between operations
• A business process (BP) typically characterized by
  long-running, statefull sequence of operations with
  one or more web services (business partners).

                                                            2
      Simple Example: Ordering
             Stationery
cobegin
      invoke Staples.StationeryQuote(staples-quote);
      invoke Office-Max.StationeryQuote Service(max-quote);
coend;
                                                     state
if staples-quote < max-quote
      {invoke Staples.StationeryPurchase}
else
      {invoke Office-Max.StationeryPurchase}


                                                              3
                    New Issues
• Must be able to communicate with other Web
  Services
• Must be able to access and modify data received in
  messages
   – Use XPath to extract information from messages
• Must have control constructs
   – sequence, switch (if), flow (concurrency), while, link
     (synchronize concurrent processes), invoke, etc
• Must be able to handle faults

                                                              4
                      Example (BPEL)
<sequence>
 <flow>
    <invoke partnerLink=“Staples” interface=“staplesPurchasePt”
            operation=“requestQuote” inputVariable=“stationeryReq”
            outputVariable=“staplesStationeryQuote”>
    </invoke>
    <invoke partnerLink=“OfficeMax” interface=“officeMQuotePT”
            operation=“requestQuote” inputVariable=“stationeryReq”
            outputvariable=“officeMStationeryQuote”>
    </invoke>
 </flow>

                   ….. Continued on next slide …..


                                                                     5
                          Example (BPEL)
 <switch>
   <case condition=“bpws:getVariableProperty(staplesStationeryQuote, quote)
                  < bpws:getVariableProperty(officeMStationeryQuote, quote)” />
        <invoke partnerLink=“Staples” interface=“staplesQuotePt”
                operation=“purchStationery” inputVariable=“stationeryPurch”
                outputVariable=“stationeryResp”>
        </invoke>
   </case
   <otherwise>
        <invoke partnerLink=“Office Max” interface=“officeMQuotePT”
                operation=“purchStationery” inputVariable=“stationeryPurch”
                outputVariable=“stationeryResp”>
        </invoke>
    </otherwise>
  </switch>
</sequence>                                                              6
         Business Process (BP)
• A BP consists of both internal computations and
  invocations of operations exported by web service
  partners
• The operations it exports constitute its interface to
  its partners
• The sequence of invocations it executes is referred
  to as a protocol and
   – is data dependent
   – responds to exceptional conditions

                                                      7
    Abstract Vs. Executable BPs
• Executable BP – complete description of BP (including all
  computations)
• Abstract BP – contains only externally visible
  (communication related) behavior of BP
   – Not executable
   – Internal decision making algorithm and data
     manipulation not described
• Languages for describing abstract and executable BPs
  share a common core, but differ primarily in data handling
  capabilities
• BPEL4WS is used to specify both abstract and executable
  BPs
                                                           8
               Executable BPs
• BPEL is sufficient for describing a complete
  (executable) BP that
   – Relies on web services and XML data
   – Is portable (platform independent)
• Executable BP is a complete specification of the
  Web Service
   – Actual implementation, however, might not use BPEL,
• Abstract BP specifies external interface and can be
  exported for use by business partners

                                                           9
                     Abstract BP
• Unfolding of protocol related portion of BP
   – depends on properties - a subset of the data contained in
     messages
   – Ex. Message invoking getQuoteRequest might have parts
     instrumentType (with value stock or bond) and symbol
     (which identifies a particular instrument of that type)
      • instrumentType will be a property if it affects the course of the
        protocol
      • symbol will not if it does not affect the course of the protocol
• Only properties are visible to abstract BP
                                                                        10
        Abstract Vs Executable BP
• Internal computation of executable BP not included in
  abstract BP
   – If assignment is to a variable that is not a property, it is
     eliminated from abstract process
       • Ex. Address data might not affect the protocol
   – If assignment is to a variable that is a property, it (generally)
     affects the protocol
       • Ex. Value of bidPrice might affect protocol:
           – if (bidPrice>1000) invoke webService1 else invoke webService2
           – bidPrice will be a property, but its value is computed by an
             internal algorithm
       • The computation that produces the new value is generally
         not relevant to the protocol
                                                                      11
 Abstract BP – Non-determinism
• Description of abstract BP allows assignment of
  non-deterministic values to properties to model this
• Abstract and executable BPs differ in data handling
  ability
   – Executable can explicitly manipulate all data
   – Abstract can access only properties in limited
     ways and can assign non-deterministic values to
     them
   – Executable cannot assign non-deterministic
     values to anything
                                                    12
Abstract BP – Non-determinism

                    non-deterministic
 computation that
                       assignment
  assigns a value
                      to property x
     to part x
                       (alias of x)



     switch(x)          switch(x )


  Executable BP        Abstract BP
                                        13
   Communication – Client Side
• Invoking an operation of an interface
  (specified in WSDL) exported by server
  – Client assigns message to operation‟s input
    variable
  – Client executes invoke on operation
     • Asynchronous (in-only WSDL pattern):
        – Client resumes execution immediately
     • Synchronous (in-out WSDL pattern):
        – Client waits for response and then resumes execution
        – Client can access response message in operation‟s output
          variable

                                                                     14
   Communication – Client Side
• Receiving an operation (e.g., an asynchronous
  response to a prior invocation) on a (callback)
  operation exported by client
  – Client executes receive on operation
        – Client waits for message
        – Client can access message in variable associated with
          operation and resume execution




                                                                  15
           Communication – Client Side
            client                                     server

            invoke




                                                        •••
  client
  waits                        (synchronous invoke)

            invoke                                                server exports




                                                        •••
                               (asynchronous invoke)
             •••




client                                                            interface
continues
            invoke




                                                        ••••••
             •••••




                                                                 problem: how do
                                                                 you associate
                                                                 request with
            receive                                              response?
                      client exports
                      (callback) operation                                16
  Communication – Server Side
• Accepting an operation invocation on an
  (exported) interface (specified in WSDL)
   – Server executes receive on operation and waits
• Responding to a synchronous operation invocation
   – Server executes reply on operation (rpc)
• Invoking a client‟s exported (callback) operation
   – Server executes invoke on operation



                                                      17
Communication – Server Side
 client                                server

 invoke                                receive




                                        •••
               (synchronous invoke)    reply
 invoke                                receive   server exports
               (asynchronous invoke)




                                        •••
                                                 interface


 invoke                                receive




                                        ••
  ••••




                                        ••
 receive                               invoke

           client exports
           (callback) interface                          18
Example: Purchase Order (PO) Service
                           receive
                          purchase
                            order             concurrency
      sequencing

   initiate                              initiate
                         decide on
    price                              production
                          shipper
 calculation                           scheduling


  complete                              complete
                           arrange
    price                              production
                          logistics
 calculation                           scheduling


       synchronization     invoice
                         processing,
                            reply                    19
  PO Service                             PO Service




   synchronous                           receive
    invocation
                  POMsg


                          operation
customer                  sendPurchOr    Body of PO
                          on interface
                                          Service
                          purchOrIf

                 InvMsg



                                           reply

                                                      20
           PO Service Interface (WSDL)
                <definitions targetNamespace=“….”
                             xmlns=“http://schemas.smlsoap.org/wsdl/” …>
                        <message name=“POMsg”>
                          <part name=“custInfo” type=“sns:custInfo”/>
                          <part name=“purchOr” type=“sns:purchOr”/>
                        </message>
                        <message name=“InvMsg”>
                          <part name=“IVC” type=“sns:Invoice”/>
                        </message>
                        …..
                        <interface name=“purchOrIf”>
                          <operation name=“sendPurchOr>
interface exported          <input message=“pos:POMsg/> -- arguments supplied
by PO Service               <ouput message=“pos:InvMsg”/> -- response
                          </operation>
                                                   prefix for target
                        </interface>
                                                   namespace in
                        …..
                                                   this document         21
                 </definitions>
              Variables (BPEL)
• Variables maintain the state of a BP
   – Used to store messages that have been sent or received or
     for local storage (no message involved)
   – Has an associated type:
      • Can be a message type
            <variable name=“PO” messageType=“lns:POMsg”/>
                   lns is prefix in BPEL document for the WSDL document
      • Can be an XML simple type
      • Can be an XML schema element (which might have a complex
        type)
   – Has an associated scope

                                                                 22
         Partner Link Type (WSDL)
• <partnerLinkType> describes the way two BPs interact:
   - names an interface that must be declared in each
   - associates <role> with each end of the interaction
Identifies a BPEL schema                                 Not a process
                                                         (allows actual
      <plnk:partnerLinkType name=“purchLT”>
                                                          partner to be
        <plnk:role name=“purchService”>
                                                            specified
          <plnk:interface name=“pos:purchOrIf”/>
                                                          dynamically)
        </plnk:role>
      </plnk:partnerLinkType>                Unit of
                                         collaboration
               Only one role since only
                POService needs to
                provide an interface
                                                                          23
       Partner Link Type (WSDL)
<plnk:partnerLinkType name=“invoicingLT”>
  <plnk:role name=“invoiceService”>
    <plnk:interface name=“pos:computePriceIf”/>
  </plnk:role>
  <plnk:role name=“invoiceRequester”>
    <plnk:interface name=“pos:invoiceCallbackIf”/>
</plnk:partnerLinkType>
                            description of a
                            possible relationship
                            between two BPs

       BP playing role                          BP playing role
       of invoice                               of invoice service
       requester

                 invoiceCallbackIf    computePriceIf
                                                                     24
             Partner Link (BPEL)
• Connection to another BP described by a partner link
• <partnerLink> construct in BPEL names a process
  and associates it with a role in that link.

           partner
        specification in                     name of
          PO service                       partnerLink

                                                     prefix lns refers to
<partnerLinks>
                                                     WSDL document
  <partnerLink name=“purchLink”
           partnerLinkType=“lns:purchLT”
          myRole=“purchService”/>                   hence PO service
  <!-- other partnerLink’s go here -->                must provide
</partnerLinks>                                        purchOrIf            25
                   Partner (BPEL)
• A BP might interact with another BP – called a
  partner - through several partnerLinks
  – Need a mechanism that asserts that the same BP is at
    the other end of a set of partnerLinks
  – Ex: BPs might support getFareIf and purchaseTicketIf;
    an acceptable partner is one that supports both
     <partners>
       <partner name=“ticketVendor”>
          <partnerLink name=“xxxx”/> <!-- supports getFareIf -->
          <partnerLink name=“yyyy”/> <!-- supports purchaseTicketIf -->
       </partner>
     </partners>                                                    26
               Process Name
• Each BP is assigned a name in the <process> tag
     <process name=“customer”
              … namespace declarations …
              … query language (default XPath) …
              … expression language (default XPath)… >
         … declarations and process body …
     </process>

     <process name=“purchOrProcess”
              … similarly … >
          … declarations and body of PO service …
     </process>
                                                         27
                                           plnk – prefix in WSDL doc refers
                                                  to WSDL extension
Linkage: Customer                          pos – target ns of WSDL doc
                                           lns – prefix in PO Service refers
  to PO Service                                  to WSDL doc
                                           cns – prefix in customer refers
                                                 to WSDL doc

  <plnk:partnerLinkType name=“purchLT>
    <plnk:role name=“purchService”>                 WSDL inter-
      <plnk:interface name=“pos:purchOrIf”/>        face exported
    </plnk:role>                                    by PO Service
  </plnk:partnerLinkType>
                                                    partner
  <partnerLink name=“linkToPurch”
                                                    specification
          partnerLinkType=“cns:purchLT”
                                                    in customer
          partnerRole=“purchService”/>
                                                    process
  <partnerLink name=“purchLink”                     partner
          partnerLinkType=“lns:purchLT”             specification
          myRole=“purchService”/>                   in PO Service       28
                       Partners
• In general:
    - A partnerLinktype is not specific to a particular BP;
       it is a global, bilateral (WSDL) description of the
       interaction between two BPs.
    - A partnerLink declaration (BPEL) describes how the
       local BP interacts with other BPs through a
       partnerLinktype.
        <partnerLinks>
          <partnerLink name=“invoiceProvider”
                  partnerLinkType=“lns:invoiceLT”
                  myRole=“invoiceRequester”
                  partnerRole=“invoiceServices”/>
        </partnerLinks>
                                                      29
           PO Service (BPEL)
<variables>
  <variable name=“PO” messageType=“lns:POMsg”/>
  <variable name=“Invoice” messageType=“lns:InvMsg”/>
</variables>
                    Both necessary since PO Service might communicate
                             with several BPs through the same interface
<sequence>
 <receive partnerLink=“purchLink” interface=“lns:purchOrIf”
                 operation=“sendPurchOr” variable=“PO”/>
 </receive>

 <flow> …. concurrent body…. </flow>

  <reply partnerLink=“purchLink” interface=“lns:purchOrIf”
        operation=“sendPurchOr” variable=“Invoice”/>
</sequence>
                                                                      30
 Interaction with Shipping Provider
                                                       operation requestShipping
       decide on                                       on interface shippingIf
        shipper
                                 shipReqMsg
       (invoke)
                             shipInfoMsg
                                                         shippingProvider
        arrange              scheduleMsg
       logisitics
       (receive)                                          role = shippingService
                           operation sendSchedule on
                           port shippingCallbackIf

role = shippingRequester

                                                                          31
Handling Shipping (WSDL)
 <interface name=“shippingCallbackIf”>
   <operation name=“sendSchedule”>
                                         interface exported
     <input message=“…”/>
                                         by PO Service
   </operation>
 </interface>

 <interface name=“shippingIf”>
   <operation name=“requestShipping”>    interface imported
     <input message=“…”/>                from shipping
     <output message=“…”/>               service
   </operation>
 </interface>


                                                   32
           Handling Shipping
<plnk:partnerLinkType name=“shippingLT”>
  <plnk:role name=“shippingService”>
    <plnk:interface name=“pos:shippingIf”/>
  </plnk:role>
                                                     WSDL
  <plnk:role name=“shippingRequester”>
    <plnk:interface name=“pos:shippingCallBackIf/>
  </plnk:role>
</plnk:partnerLinkType>

<partnerLink name=“shippingProvider”
        partnerLinkType=“lns:shippingLT”
        myRole=“shippingRequester”                   BPEL
        partnerRole=“shippingService”/>

                                                            33
       Handling Shipping (BPEL)
                                 contains
                                  input
<sequence>                       message
  <assign>
    <copy> <from variable=“PO” part=“custInfo” />
             <to variable=“shippingReq” part=“custInfo” />
    </copy>
  </assign>
  <invoke partnerLink=“shippingProvider” interface=“lns:shippingIf”
           operation=“requestShipping”
           inputVariable=“shippingReq” outputVariable=“shippingInfo” >
  </invoke>
  <receive partnerLink=“shippingProvider” interface=“lns:shippingCallbackPT”
         operation=“sendSchedule” variable=“shippingSchedule”/>
</sequence>


                                                                   34
 Links (BPEL)– Synchronizing
 Concurrent Activities w/I a BP
• Production scheduling cannot be completed until
  logistics have been arranged
    Concurrent sequence activities in flow
                                             • data produced by
                                             arrange logistics is
    decide on
                              initiate       needed by complete
                            production       production scheduling
     shipper
                            scheduling
                                             • data communicated
                                             through globally shared
                             complete        variable
     arrange     link
                            production
    logistics
                            scheduling
            source      target
                                                              35
             <flow>
               <links>
Links            <link name=“ship-sched”/>
               </links>
               <sequence>
                 <assign> …. </assign>
decide on        <invoke partnerLink= ….> </invoke>
shipper
                 <receive partnerLink= ….             shipping
arrange                variable=“shippingSched”>
logistics          <source linkName=“ship-sched”/>
                 </receive>
               </sequence>
               <sequence>
                 <invoke partnerLink=….> </invoke>
complete         <invoke partnerLink=….
                                                     scheduling
production            inputVariable=“shippingSched”>
scheduling         <target linkName=“ship-sched”/>
                 </invoke>
               </sequence>
               ….
             </flow>                                         36
               Properties (WSDL)
• Some message data is protocol-relevant.
   – Used in conditional behavior of BP
   – Used to relate messages sent to a particular instance of a BP
• A property declares a global name that can be assigned
  to data items that may be parts of several different
  message types and carry the same meaning
   – taxpayerID might be a part of one message type in one
     namespace (e.g., Internal Revenue), ssn might be a part of
     another in a different namespace (e.g., Social Sec. Admin)
   – Both might represent the same information of type txtyp:SSN

       <bpws:property name=“customerID” type=“txtyp:SSN‟/>

                                                               37
        Property Alias (WSDL)
• Used to associate a property name with a field in
  message part
   – A particular property can be associated with different
     fields in different messages

   <bpws:property name=“customerID” type=“txtyp:SSN‟/>
   <bpws:propertyAlias propertyName=“customerID”
                       messageType=“txmsg:taxpayerInfo”
                       part=“taxpayerID”
                       query=“/socialSecNum” />
   </bpws:propertyAlias>
                                        query string – specified in
                                       XPath - to locate the field in
                                                 the part
                                                                   38
         Correlation Sets (BPEL)
• A web service might be configured with multiple
  instances of a BP to concurrently handle (stateful)
  conversations with multiple clients.
   – All receive requests over the same port
      • With SOAP over HTTP, messages arrive on port 80
• A mechanism is needed to:
   – Route an arriving message that is part of a particular
     conversation to the correct BP instance
      • Messages of a particular conversation can be recognized by the
        fact that they will generally all carry some identifying value(s)
        (e.g., customerID and orderNum)


                                                                        39
                Correlation Sets
• A correlation set is a set of properties whose
  value is shared by all messages in a particular
  conversation.
  – Hence, an address is really:
                  (host address, port, correlation set)
  – A correlation set identifies the BP instance
   <correlationSet name=“PurchaseOrder”
                  properties=“cor:customerID cor:orderNum”/>

                                   aliased to items of
                                   information contained
                                   in the messages of a
                                                               40
                                   conversation
          Using Correlation Sets
• A particular receive operation can be used in a BP
  to accept the start of a new conversation
                                                  asynchronous
                                                  purchase requst
   <receive partnerLink =“Buyer”
             interface=“SP:PurchasingIf”
             operation=“asynchPurchase”       create a new correlation
             variable=“PO”>                   set value for BP instance
       <correlations>
            <correlation set=“PurchaseOrder” initiate=“yes”/>
       </correlations>
   </receive>

• All subsequently arriving messages with same
  value of PurchaseOrder will be directed to this BP
                                                                    41
         Using Correlation Sets
• Response returns the correlation set value
   – Asynchronous (callback) response to previous
     invocation
    <invoke partnerLink “Buyer”                        use the set to
              interface=“SP:BuyerIf”                   address the
              operation=“asynchPurchaseResp”           message
              variable=“PO”>
        <correlations>
             <correlation set=“PurchaseOrder” initiate=“no”/>
        </correlations>
    </invoke>

   – A reply to a synchronous invocation would be similar
                                                                        42
           Multiple Correlation Sets
                             messages of a
                             single conversation

   buyer                                                server
invoke(corrSet=“PO” init=“yes”)            receive(corrSet=“PO” init=“yes”)


receive(corrSet=“PO” init=“no”             invoke(corrSet=“PO” init=“no”
       corrSet=“inv” init=“yes”)                  corrSet=“inv” init=“yes”)
                                                            messsage
                                                            contains both
                                                            correlation sets
              subsequent messages sent and received use
                       correlation set inv

                                                                         43
      Multiple Correlation Sets
• With synchronous invocation two messages
  are involved; the pattern attribute associates
  a correlation set with a message.
   invoke (partnerLink=“Buyer” interface=“SP:BuyerIf”
             operation=“synchPurchaseResp”
             inputVariable=“PO” outputVariable=“invoice”>
       <correlations>
            <correlation set=“PurchaseOrder” initiate=“yes”
                         pattern=“out”/> (initiated in outbound msg)
            <correlation set=“InvoiceResp” initiate=“yes”
                         pattern=“in”/> (initiated in inbound msg,
                                           which contains both sets)
       </correlations>
   </invoke>                                                        44
                 Data Manipulation
• Data (state) stored in variables (used for messages and
  local storage)
• Expressions use expression language (XPath default) to
  access data in variables
   – Executable processes can use:
       bpws:getVariableData („variableName‟, „partName‟, „locationPath‟?)
   – All processes can use:                query string
       bpws:getVariableProperty(„variableName‟, „propertyName‟)
                       property alias contains
                            query string
   – Returns the part (or, if the locationPath is specified the
     field within the part) in the named variable.
       • If a single node is not specified, a fault is returned.
                                                                     45
                     Assignment
• Allows copying of data
• One form (for executable processes):
          <assign>
            <copy>
              <from variable=“v1” part=“p1” query=“q1”/>
              <to variable=“v2” part=“p2” query=“q2”/>
            </copy>
          </assign>
   – query is an absolute expression (if XPath is the query
     language) that identifies a single node w/i the document
     fragment specified by part
   – from child can also contain a literal value or a simple
     arithmetic expression (for data transformation)
                                                                46
 Assignment in Abstract Process
• A non-deterministic value from a property‟s
  domain can be assigned to the property by an
  abstract process using opaque assignment
   – Allows simulation of execution traces

        <assign>
          <copy>
            <from opaque=“yes”/>
            <to variable=“v2” property=“p2”/>
          </copy>
        </assign>

                                                 47
Invoking Web Service Operations
• invoke might have child elements related to faults and
  compensation (discussed subsequently), and links and
  correlation (discussed previously)
• invoke specifies a partnerLink since an interface can be
  associated with several partnerLinkTypes connected to
  different BPs
       <invoke partnerLink=“shippingProvider”
               interface=“lns:shippingIf”
               operation=“requestShipping”
               inputVariable=“shippingRequest”
               ouputVariable=“shippingInfo”>
       </invoke>
                                                    48
Invoking Web Service Operations
• invoke can be
   – Synchronous
      • input and output variables specified
      • waits for a response
   – Asynchronous
      • no output variable specified
      • no waiting

         <invoke partnerLink=“invoiceProvider”
                 interface=“lns:computePriceIf”
                 operation=“initiatePriceCalc”
                 inputVariable=“PO”>
         </invoke>

                                                  49
 Synchronous Vs. Asynchronous
          Invocation
• Web service communication characterized by:
  – Services are not always available.
  – Loads tend to be unpredictable.
     • Attempts to handle too many requests in real time can
       lead to thrashing and failure.
  – Many requests can‟t be handled instantly even
    with low loads.
• Asynchronous invocation will play an
  increasingly important role.
                                                         50
Providing Web Service Operations
• receive waits for an invocation to arrive
 <receive partnerLink=“customer” interface=“lns:purchOrIf”
            operation=“sendPurchOr” variable=“POmsg”/>
 </receive>


  – specifies a partnerLink since an interface can
    be associated with several partnerLinkTypes
    connected to different BPs

                                                             51
Providing Web Service Operations
• Initiating a new instance of a BP:
  <receive partnerLink=“customer” interface=“lns:purchOrIf”
             operation=“sendPurchOr” variable=“POmsg”
             createInstance=“yes”/>
  </receive>
   – createInstance=“yes” => a new instance of the BP is
     created and this is its initial activity.
      • The receive should be the first activity in the BP
        (since prior activities will not be executed within the
        new instance)
      • If the message is the start of a conversation then a
        correlation child element should be specified:
        <correlation set=“PurchaseOrder” initiation=“yes”/>
                                                              52
Providing Web Service Operations
• reply is used to respond to a synchronous invocation.
   – connection between receive and reply based on
     constraint that not more than one synchronous
     request from a particular (partnerLink, interface,
     operation) can be outstanding at a time
    <reply partnerLink=“customer” interface=“lns:purchOrIf”
          operation=“sendPurchOr” variable=“Invoice”/>

• Response to an asynchronous invocation is made
  using an invoke on a callback operation
   – partnerLink between requestor and requestee must have
     two roles
                                                              53
       Other Basic Activities
• <terminate>
• <wait until=“deadline”>
          or
  <wait for=“duration”>
• <empty>



                                54
            Structured Activities
• <sequence>                           Involves only
    <!-- list of activities -->         properties if
  </sequence>                        process is abstract
• <switch>
      <case condition=“bool-expr”>             at least one case
               <!-- activity -->               element; conditions
                                               evaluated in order
      </case>
      <otherwise>                              if present, executed
               <!-- activity -->               if all conditions
                                               fail, else an empty
      </otherwise>                             otherwise is assumed
  </switch>
                                                              55
            Structured Activities
• <while condition=“bool-exp”>
     <!-- iteratively executed activity -->
  </while>
• <pick>                -- waits for the occurrence of first event
    <onMessage partnerLink=“..” interface=“..”
                   operation=“..” variable=“..”>          at least one,
                                                          acts like
                <!-- activity to process message --> receive
    </onMessage>
    <onAlarm for=“durationExp” | until=“deadlineExp”> zero or
                <!-- timeout activity -->                          more
    </onAlarm>
  </pick>                                                         56
        Structured Activities
• <flow> concurrently executes nested (child)
  activities
• Terminates when all children terminate
          <sequence>
             <flow>
               <invoke partnerLink=… />
               <invoke partnerLink=… />
             </flow>
             <invoke partnerLink=../>
          </sequence>
                                            57
                  WSDL Review
• WHAT: interface describes abstract functionality
  (operations, messages)
• HOW: binding describes how elements of an
  interface (operations, messages) are mapped to a
  particular transport protocol (e.g., SOAP over HTTP,
  data encoding)
• WHERE: endpoint maps a binding to an address
  (particular server at a URL)
   – service is a collection of related endpoints



                                                    58
             Endpoint References
• A BP is statically dependent on the interfaces with
  which it communicates
• However, the endpoints associated with those
  interfaces (and hence the identity of the BP instances
  with which it communicates) can change dynamically
   – Endpoints can be sent in messages
   – A BP can dynamically select a provider
   – Example: client can send a callback interface to which server
     can send response
                                                             59
        Endpoint References
• A message part of EndpointReferenceType can
  hold addressing information
• Every role in a partnerLink has an associated
  EndpointReference (of that type) that
  identifies an endpoint (address) and an
  associated process instance
• An EndpointReference element is an
  alternative to a service element

                                           60
WS-Addressing Specification for
    Endpoint Reference
<wsa:EndpointReference …namespace declarations… >
   <wsa:Address> … a URI … </wsa:Address>                 -- required
   <wsa:ReferenceProperties>
       … properties (child elements) are inserted here ….
   </wsa:ReferenceProperties>
   <wsa:Interface> …</wsa:Interface>
   <wsa:ServiceName> … </wsa:ServiceName>
   <wsa:Policy> … </wsa:Policy>
</wsa:EndpointReference>

• wsa identifies WSDL extension namespace for
  endpoint references
• Information to identify a particular instance of a BP can
   also be supplied
                                                                        61
           Endpoint Reference
• Properties: mapped literally to SOAP headers
  – MessageId
  – Action: action to be taken by destination
  – ReplyTo: …
• Interface: identifies the associated interface
• ServiceName: identifies the associated service


                                                62
      Endpoint Reference Example
<message name=“buyerData”> ….
  <part name=“serviceReference” type=“wsa:EndpointReferenceType”/>
  <part …. />
</message>

<interface name=“buyerIf”>
   <operation name=“submit”> <input message=“tns:buyerData”/>
   </operation>
</interface>
<interface name=“buyerCallbackIf”> <operation name=“answer” …. </interface>

<plnk:partnerLinkType name=“buyerStoreLT”>
  <plnk:role name=“store”>
     <plnk:interface name=“tns:buyerIf”/>
  </plnk:role>
  <plnk:role name=“buyer”/>
     <plnk:interface name=“buyerCallbackIf”/>
  </plnk:role>
</plnk:partnerLinkType>
                                                                       63
      Endpoint Reference Example
<partnerLink name=“buyer”
         partnerLinkType=“as:buyerStoreLT”
         myRole=“store” partnerRole=“buyer”/>
<variable name=“buyerData” messageType=“as:buyerData”/>
……
<sequence>
  <receive name=“acceptFromBuyer” partnerLink=“buyer”
        interface=“as:buyerIf” operation=“submit” variable=“buyerData”/>
   …..
  <assign>
     <copy>
       <from variable=“buyerData” part=“endpointReference”/>
       <to partnerLink=“buyer”/>
     </copy>
  </assign>
  <invoke name=“respondToBuyer” partnerLink=“buyer”
            interface=“as:buyerCallbackIf” operation=“answer”
            inputVariable=“…” />
</sequence>
                                                                           64
         Assignment and Endpoint
               References
• Sending an address: from child can have the form
      <from partnerLink=“ … ”
               endpointReference=“myRole|partnerRole ”/>

   – A BP might want to send its own address (e.g., for a callback)
     or its partner‟s address
• Receiving an address: to child must be associated with
  partnerRole (can‟t change your own address)
       <to partnerLink=“ … ” />


                                                              65
         Links – Synchronizing Flow
<flow>
 <links>          Activities
     <link name=“XtoY” />
     <link name=“CtoD”/>            - any activity can have a source
  </links>                            or target child element
  <sequence name=“X”>
                                    - every link must have exactly
     <source linkName=“XtoY”/>
     <invoke name=“A”…/> …            one activity w/i the flow as
  </sequence>                         its source and one as its target
  <sequence name=“Y”>               - sequence Y can‟t start until
     <target linkName=“XtoY”/>        sequence X completes
     <receive name=“C”…>
        <source linkName=“CtoD”/>
                                    - source and target need not be
     </receive> …                     nested at same level (CtoD)
  </sequence>                       - link must not cross a while
  <invoke name=“D”…>                  boundary
     <target linkName=“CtoD”/>      - links must not create a loop
  </invoke>
</flow>                                                          66
     Link Semantics at the Source
• Each source child of an activity has an implicit or
  explicit transitionCondition whose value is:
  - Implicit: true when activity terminates
  - Explicit: the value of the transitionCondition when the activity
  terminates                       variable name
                                                        property name
   <source linkName=“AtoB”
      transitionCondition=“getVariableProperty(„eval‟, „risk‟) = „low‟ ”/>
   - The transitionCondition determines the link status (positive or
  negative) when the activity terminates

                                                                        67
        Link Semantics at the Target
• Without considering links, an activity is ready to execute in
   accordance with normal flow-of-control rules (sequence, switch,
   etc.)
• In addition, an activity might be the target of several links.
    - Every such activity has a joinCondition which can be
      evaluated when the status of all incoming links has been
      determined. Execution starts when the activity is ready and its
       joinCondition is true.
• Default joinCondition: status of at least one incoming link is true
                    <sequence name=“X” >
                      <target linkName=“AtoX”/>
                      <target linkName=“BtoX”/>
                             …….
                    </sequence>                                   68
       Link Semantics at the Target

 • joinCondition can be explicitly provided as
   an attribute using getLinkStatus() function.

<sequence name=“X”
  joinCondition=“bpws:getLinkStatus(AtoX) AND bpws:getLinkStatus(BtoX)”>
  <target linkName=“AtoX”/>
  <target linkName=“BtoX”/>
         …….                           must specify an incoming
</sequence>                            link for activity X



                                                                  69
   Link Semantics at the Target
• If the joinCondition evaluates to false a
  joinFailure fault is thrown, else the activity is
  started
• If an activity, X, will not be executed (e.g. a
  case in a switch, an activity that does not
  complete due to a fault) then the status of all
  outgoing links from X is set to negative.


                                                70
  Link           <flow>
                   <link name=“AtoC”/>
Semantics          <link name=“BtoC”/>
  <sequence>
  <switch>                               <sequence name=“C”>
    <case condition=“C1”>                    <target name=“AtoC”/>
      <sequence name=“A”>                    <target name=“BtoC”/>
         <source linkName=“AtoC”/>           ………
         ….                          - only one case is executed
      </sequence>                    - joinCondition at C cannot
    </case>                            be evaluated until status of
    <case condition=“C2”>              both links are determined
      <sequence name=“B”>            - if C1 is chosen for execution
         <source linkName=“BtoC”/>     the status of BtoC is set to
         ….                            negative (if that were not
      </sequence>                      done C would never start)
    </case>                          - default joinCondition at C is
  </switch>                            true when either C1 or C2
  …….                                  completes - since their (default)
                      </flow>          transitionCondition is “true”
                                                                 71
              Link Semantics
• Problem – in some cases a false joinCondition
  is not a fault; it is an indication that the activity
  should not be performed in at a particular point
  in the execution
   – In that case the status of all outgoing links should
     be set to false so that the joinCondition of other
     activities can be evaluated
• Solution – use activity attribute
  suppressJoinFailure
                                                      72
              Link Semantics
• If value of the suppressJoinFailure attribute of
  an activity, A, is yes, then if the joinCondition
  of A or any nested activity has value false
  when it is ready to execute
  – status of all of it‟s outgoing links is set to negative
  – it is skipped and execution continues (as if it had
    terminated without raising a fault)
  – referred to as dead-path-elimination
                                                       73
  Link
Semantics        <flow suppressJoinFailure=“yes”>
                   <link name=“AtoC”/>
  <sequence>
  <switch>                               <sequence name=“C”>
    <case condition=“C1”>                    <target name=“AtoC”/>
      <sequence name=“A”>                          ………
         <source linkName=“AtoC”/>
             ….
      </sequence>                       - C is executed if C1 is chosen
    </case>                             - if C1 is not chosen
    <case condition=“C2”>                 the status of AtoC is set to
      <sequence name=“B”>                 negative and a joinFailure
          ….                              would occur
      </sequence>                       - suppressing joinFailure allows
    </case>                               C to be silently skipped
  </switch>
  …….
                      </flow>                                    74
                  Scope
• Nested scoping is provided through the
  scope activity in the conventional way.
• Variables, fault and compensation handlers,
  and correlation sets can be declared.
• Properties are global since they are mapped
  to data in messages.


                                            75
                      Faults
• Fault has a unique name and an (optional)
  fault variable describing the event
• Sources of faults:
  – Explicit raising of a fault
     <throw faultName=“trouble” faultVariable=“descr”/>
  – Standard BPEL faults
     bpws:joinFailure - joinCondition has value false
     bpws:conflictingReceive – two receive’s for same
        partnerLink, interface and operation pending
        within a flow at the same time
                                                        76
                           Faults
• Source of faults (con‟t):
   – Fault response to an invoke. The reply:
      <reply partnerLink=“customer” interface=“lns:loanServiceIf”
            operation=“request” variable=“error”
            faultName=“unableToHandleRequest”/>
   raises the fault unableToHandleRequest in customer
   that has synchronously invoked request on interface:
    <interface name=“loanServiceIf”>
      <operation name=“request”
                  pattern=“http://www.w3.org/2003/06/wsdl/in-out”>
         <input message=“lns:creditInfoMsg”/>
         <output message=“lns:approvalMsg”/>
         <fault name=“unableToHandleRequest” message=“errorMsg”/>
      </operation>
    </interface>                                                   77
                         Faults
The reply raises the unableToHandleRequest fault in
customer which is handled by

    <faultHandlers>
      <catch faultName=“unableToHandleRequest”
             faultVariable=“error”>
         …. handle the fault ….     Re-throw the same fault
      </catch>                      and/or clean-up and/or
    </faultHandlers>                invoke a compensation
                                    handler


                                                              78
                             Handlers
    • Handler is associated with an implicit or explicit
      scope; catches faults that occur in that scope
                                       <scope>
<invoke                                 <faultHandlers>
    partnerLink=“loanApprovProc”         <catch faultName=“unable…”
    interface=“lns:loanserviceIf”          faultVariable=“error”>
    operation=“request”                      …. handle the fault …
         ….. >                    or      </catch>
  <catch                                   …other handlers …
     faultName=“unable…”                </faultHandlers>
     faultVariable=“error”>               …activities …
      …. handle the fault….             <invoke partnerLink=“loanApprovProc”
  </catch>                                 interface=“lns:loanserviceIf”
</invoke>                                  operation=“request” … >
                                         </invoke>
                                         …activities…
                                       </scope>                          79
          Fault Flow of Control
• When a fault f occurs in some scope, B
   – Execution of activities within are terminated
   – If a fault handler for f or a catchAll handler has been
     declared local to B, it is executed and execution resumes
     in the next enclosing scope at the activity following B
   – Else f is thrown in the next enclosing scope
   – In both cases B is said to have exited abnormally
• The handler might reverse changes it has made to
  variables global to B and invoke compensation
  handlers for scopes nested in B that have
  completed normally.
                                                            80
                Fault Flow of Control
                   A



                       B      catch f
                                throw g
                                  or
                                exit
abnormal exit


                           throw f




                                          81
                    Atomicity
• A BP is a long running process involving invocations
  of operations at a number of web services.
• It is unrealistic to treat a BP as a single transaction,
  since a particular service will not hold locks for the
  duration of the BP
• Instead, a single operation at a service might be treated
  as a transaction that commits when it sends reply
• BPEL does not support global atomicity (e.g., two-
  phase commit) over multiple invocations by a BP

                                                       82
          Long-Running Business
            Transactions (LRT)
• Reversing the effect of a BP relies on compensation
   – a web service might offer a compensating operation for a
     synchronous operation
   – Ex. CancelPurchase compensates for Purchase
• BPEL supports an LRT by providing compensation
  handlers
   – Allows application to specify a recovery strategy using
     compensating operations
   – No guarantee of atomicity or isolation
   – Future work in this direction is being carried out in the
     context of the WS-Transaction specification
                                                                 83
                 Compensation Handler
• Handler can be in the immediate scope of invoke or declared
  local to scope
   – Undoes the effect of the scoped activities
<invoke name=“invSeller” partnerLink=“seller” interface=“SP:Purch”
                                                                          -- invSeller is
          operation=“syncPurch” inputVariable=“sendPO”
                                                                          name of scope
          outputVariable=“getResponse”>
   <correlations>
     <correlation set=“PurchOr” initiate=“yes” pattern=“out”/>
   </correlations>                -- pattern=“out” indicates set applies to request msg
   <compensationHandler>
     <invoke partnerLink=“seller” interface=“SP:Purch” operation=“cancelPurch”
         inputVariable=“getResponse” outputVariable=“getConfirm”>
        <correlations>
           <correlation set=“PurchOr” pattern=“out”/>
        </correlations>
      </invoke>
   </compensationHandler>
</invoke>                                                                           84
          Invoking Compensation
• Compensation can only be performed for scope (e.g.,
  invoke, scope) that has completed normally
   – A compensation handler is not “installed” until the
     associated scope has completed normally.
      • Hence handler must be invoked from outside the scope
   – Compensation occurs when a failure is detected
      • Hence handler is invoked from a global fault or
        compensation handler



                                                           85
      Invoking Compensation
• At most one compensation handler can be
  explicitly declared local to a scope (in
  contrast to fault handlers)
• Scope has a name; handler is invoked using
     <compensate name=“scopeName”/>
• Handler is installed when scope is exited
  normally (at that point compensation is
  meaningful)
                                           86
                    Handler Invocation
                       A          catch f            fault handler
                                    compensate B     for f


                           B          compensate C   compensation
                                      compensate D   handler for B


                                  C                  compensation
                                                     handler for C



                                                     compensation
Although B, C and
                                  D
                                                     handler for D
D may have exited
normally, A will
exit abnormally         throw f
in this case
                                                               87
     <scope>
                          Compensation
      <faultHandlers>
       <catch faultName=“unable…” faultVariable=“error”>
          <compensate scope=“invBank”/>
        </catch>
      </faultHandlers>
      <sequence>
         <invoke name=“invBank” partnerLink=“myBank”                          fault
                  interface=“bankIf” operation=“Op” ….>
            <compensationHandler>                                compensate
               <invoke partnerLink=“myBank” interface=“bankIf”
                        operation=“cancelOP” …..>
normal         </invoke>
exit         </compensationHandler>
         </invoke>
         <invoke partnerLink=“loanApprovProc”
                  interface=“lns:loanserviceIf” operation=“request” ….. >
         </invoke>
         …………                                                abnormal exit 88
                Default Handlers
                                        A
• Problem: Suppose a fault handler
  is not declared
                           default          B
                           handler
                           for f                 C
                        compensation
                        handler for C
• Compensation handler for C
  cannot be called from within A
• Solution: default fault handlers
  automatically invoke declared                 throw f
  compensation handlers of
  immediately enclosed scopes and
  then rethrow the fault
                                                          89
                Default Handlers
                           fault handler                catch f
                                           A              compensate B
                           for f
• Problem: Suppose a
  compensation handler
  is not declared        default               B
                         compensation
                         handler                    C
                         compensation
                         handler for C


• Compensation handler for C
  cannot be called from within A
• Solution: default compensation
  handler automatically invokes
  declared compensation handlers
                                                   throw f
  of immediately enclosed scopes
                                                                     90
      Structure of a BP

<process name=“…” abstractProcess=“yes|no” … />
  <partnerLinks> … </partnerLinks>
  <variables> … </variables>
  <correlationSets> … </correlationSets>
  <faultHandlers> … </faultHandlers>
  <compensationHandlers> … </compensationHandlers>
  activity
</process>




                                                     91

				
DOCUMENT INFO