1 / 33

Defining the Behaviour of BPEL light Interaction Activities Using Message Exchange Patterns

Defining the Behaviour of BPEL light Interaction Activities Using Message Exchange Patterns. Jörg Nitzsche, Benjamin Höhensteiger, Frank Leymann, Mirko Sonntag and Markus Tost. Agenda. BPEL BPEL light Message Exchange Patterns (MEPs) MEPs to define the behaviour of Interaction Activities

holland
Download Presentation

Defining the Behaviour of BPEL light Interaction Activities Using Message Exchange Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Defining the Behaviour of BPELlight Interaction Activities Using Message Exchange Patterns Jörg Nitzsche, Benjamin Höhensteiger, Frank Leymann, Mirko Sonntag and Markus Tost

  2. Agenda BPEL BPEL light Message Exchange Patterns (MEPs) MEPs to define the behaviour of Interaction Activities In MEP definitions In executable processes Implementation Conclusion 3

  3. What is BPEL? Language to define executable processes and abstract processes Executable processes Can be performed within all compliant environments (portability) Abstract processes Are “views” on internal processes Templates Observable behaviour Combination of graph-based language (IBM WSFL) and calculus-based language (Microsoft XLANG) A language to specify behaviour of business processes Between Web services… …and as Web service 4

  4. Business Processes Compose Web Services BPEL Process uses Web services 5

  5. Business Processes as Web Services A BPEL Process is also a Web Service Provides functionality in terms of WSDL port types and operations 6

  6. Aggregating Web services BPEL provides a recursive aggregation model for Web services 7

  7. Problem statement Interaction activities in BPEL refer to a partner link and a WSDL operation, i.e. process logic and activity implementation specification are tightly coupled Only partner services that implement the right port type (hard-coded within the process logic) can be used Services that provide the same functionality but implement a different interface cannot be used Activity implementations are restricted to WSDL services  Flexibility and reusability is hampered BPEL is Web Services only 8

  8. Approach Free BPEL from WSDL • BPEL only defines the messages send to and received from activity implementations 9

  9. Two Approaches Profile for BPEL abstract process Introduce new WSDL-less interaction modelusing the <extensionActivity> mechanism BPEL light Why BPEL light: Reusability is similar to having an abstract BPEL But abstract BPEL has to be completed to BPEL, i.e. flexibility is higher in BPEL light because activity implementations can even be changed/discovered by the middleware during runtime. WSDL-less BPEL 10

  10. Remove WSDL dependencies out of BPEL <partnerLink name="" partnerLinkType="" myRole="buyer" partnerRole="seller"/> depends on WSDL <sequence ...> </sequence> <invoke inputVariable= "item" operation= "buy" partnerLink= "" portType="“/> depends on WSDL … <receive operation= "buyAck" partnerLink= "" portType= "" variable= "Ack“/> depends on WSDL 11

  11. What remains gets new names… Without the WSDL dependency this element is not a typed connector any more. It simply defines a conversation among partners from the point of view of one partner <partnerLink name=""/> <conversation name=""/> <sequence ...> </sequence> <sequence ...> </sequence> <invoke inputVariable= "item“/> <extensionActivity> <interactionActivity inputVariable= "item“ conversation="“/> <extensionActivity> … … <extensionActivity> <interactionActivity outputvariable= "Ack“ conversation=""/> <extensionActivity> <receive variable= "Ack“/> 12

  12. Achievements Decoupling of process logic from activity definition 13

  13. BPEL light 1.0 A Conversation is a container for defining a message exchange required for fulfilling a specific business goal Multiple partners can be involved into a conversation Interaction activities in BPEL light define the actual message exchange within a conversation <interactionActivity> It defines which messages are sent / received by an activity (similar to a task in BPMN) It defines to/from which partner a message is sent/received It is limited to at most 2 messages (like an <invoke> in BPEL) 14

  14. WSDL 2.0 Operations are defined using MEPs which are identified by a URI MEPs are defined using templates Multiple inputs, outputs, infaults and outfaults can be defined  Complex MEPs are possible. <operation name="xs:NCName" pattern="xs:anyURI"? style="list of xs:anyURI"? > <documentation />* [<input/>|<output/>|<infault/>|<outfault/>]* </operation> 15

  15. MEP template This pattern consists of [number] message[s, in order] as follows: [enumeration, specifying, for each message] A[n optional] message: 1. indicated by an Interface Message Reference component whose message label is "[label]" and direction is "[direction]" 2. [received from|sent to] ["some" if first mention] node [node identifier] This pattern uses the rule [fault ruleset reference]. An Interface Operation using this message exchange pattern has a message exchange pattern property with the value "[pattern IRI]". 16

  16. Example: out-optional-in (WSDL 2.0 MEP) The out-optional-in message exchange pattern consists of one or two messages, in order, as follows: A message: indicated by a Interface Message Reference component whose {message label} is “Out" and {direction} is “out" Sent to some node N An optional message: indicated by a Interface Message Reference component whose {message label} is “In" and {direction} is “in" Received from node N … An operation using this message exchange pattern has a {message exchange pattern} property with the value "http://www.w3.org/ns/wsdl/in-opt-out". 17

  17. Deficiencies of the W3C proposed template No notion of cardinality Weak definition of what a node is (node type vs. node instance) Multi-casts not supported request for bid c a Provider !c order payment+ delivery Requester Banking 18

  18. Deficiencies of the W3C proposed template (2) Weak control flow No parallelism No conditional flow etc. Imprecise Weak definition of “optional” (how can a service decide whether an optional message will arrive or not?) 19

  19. BPEL light 4 MEPs BPEL defines flow between WS operations receive, reply, invoke, pick, eventHandler BPEL and WSDL define the message exchange of (multiple) parties from the point of view of one participant A BPEL dialect that is decoupled & independent of WSDL (BPEL light) is an eligible candidate for defining the flow within WS operations 20

  20. BPELlight Abstract Profile for MEPs • Allows definition of MEPs in terms of exchanges of abstract messages • Omission of data types (variables) • Abstract definition of expressions used within the control flow • Abstract definition of timing expressions used for time outs (in picks) or in wait statements 21

  21. <bpel:process xmlns:bpel="http://.../wsbpel/ 2.0/process/abstract" suppressJoinFailure="yes" abstractProcessProfile="http:// .../BPELlight/abstract/mep/2008/" targetNamespace="http://.../mep" name="out-optional-in"> <bl:conversations> <bl:conversation name="out-optional-in"/> </bl:conversations> </bl:partners> <bl:partner name=“A“/> </bl:partners> <bpel:flow> <bpel:links> <bpel:link name="L1"/> </bpel:links> <bl:interactionActivity name="Out" inputVariable="##opaque" conversation="out-optional-in“ partner=“A“> <bpel:sources> <bpel:source linkName="L1"/> </bpel:sources> </bl:interactionActivity> Example: out-optional-in (BPELlight) <bl:pick> <bpel:targets> <bpel:target linkName="L1"/> </bpel:targets> <bl:onMessage name="In" outputVariable="##opaque" conversation="out-optional-in“ partner=“A“> <bpel:empty/> </bl:onMessage> <bl:onMessage name="InFault" faultName="##opaque" outputVariable="##opaque" conversation="out-optional-in"> <bpel:empty/> </bl:onMessage> <bpel:onAlarm> <mep:timingExpression name="timeout" type="##opaque" expression="##opaque"/> <bpel:empty/> </bpel:onAlarm> </bl:pick> </bpel:flow> </bpel:process> 22

  22. BPELlight using MEPs MEPs can be used to define BPELlight Activities Used in MEP definitions  Enables defining MEPs recursively Used in concrete processes 23

  23. Parameterisation of a MEPs via an IA <process name="main" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable "... > <variables> <variable name="someVar" type="xsd:int" /> <variable name="receive" type="dt:StringMessage" /> <variable name="send" type="dt:StringMessage" /> </variables> <partners> <partner name="myPartner" /> </partners> […] <interactionActivity name="InOut" conversation="aConversation" mep=" iaas.uni- stuttgart.de/meps#in-out"> <input variable="send" messageRef="IO-Out" /> <output variable="receive" messageRef ="IO-In" /> <partner name="myPartner" partnerRef="aPartner" /> <variable name="someVar" variableRef="aVariable" /> <timingExpression expression="2008-12-02T13:00" type="until" timingExpressionRef="TEWait" /> </interactionActivity> [...] <!-- any further process logic --> </process> • <process name="in-out" • targetNamespace="iaas.uni-stuttgart.de/meps" …> • <conversations> • <conversation name="IOCon"/> • </conversations> • <variables> • <variable name="aVariable" type="##opaque" /> • </variables> • <partners> • <partner name="aPartner" /> • </partners> • […] • <sequence> • <interactionActivity name="IO-In" conversation="IOCon" > • <output messageLabel="IO-In" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • <interactionActivity name="IO-Out" conversation="IOCon" > • <input messageLabel="IO-Out" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • </sequence> • <wait><timingExpression timingExpressionLabel =“TEWait“ /> </wait> • […] • </process> Main process MEP process References the MEP

  24. Recursive MEPs Interaction Activity enables recursive MEPs MEPs that use MEPs Eases Modelling Realized via „abstract“ Parameterisation of the Interaction Activity 25

  25. „abstract“ Parameterisation - Recursion <process name="main" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/abstract "... > <variables> <variable name="someVar" type=“##opaque" /> </variables> <partners> <partner name="myPartner" /> </partners> […] <interactionActivity name="InOut" conversation="aConversation" mep=" iaas.uni- stuttgart.de/meps#in-out"> <input messageLabel=“mIO1" messageRef="IO-Out" /> <output messageLabel=“mIO2" messageRef ="IO-In" /> <partner name="myPartner" partnerRef="aPartner" /> <variable name="someVar" variableRef="aVariable" /> <timingExpression expressionLabel=„mTEWait" timingExpressionRef="TEWait" /> </interactionActivity> [...] <!-- any further process logic --> </process> <process name="main" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable "... > <variables> <variable name="someVar" type= "##opaque" /> </variables> <partners> <partner name="myPartner" /> </partners> […] <interactionActivity name="InOut" conversation="aConversation" mep=" iaas.uni- stuttgart.de/meps#in-out"> <input messageRef="IO-Out" /> <output messageRef ="IO-In" /> <partner name="myPartner" partnerRef="aPartner" /> <variable name="someVar" variableRef="aVariable" /> <timingExpression timingExpressionRef="TEWait" /> </interactionActivity> [...] <!-- any further process logic --> </process> <process name="main" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable "... > <variables> <variable name="someVar" type="xsd:int" /> <variable name="receive" type="dt:StringMessage" /> <variable name="send" type="dt:StringMessage" /> </variables> <partners> <partner name="myPartner" /> </partners> […] <interactionActivity name="InOut" conversation="aConversation" mep=" iaas.uni- stuttgart.de/meps#in-out"> <input variable="send" messageRef="IO-Out" /> <output variable="receive" messageRef ="IO-In" /> <partner name="myPartner" partnerRef="aPartner" /> <variable name="someVar" variableRef="aVariable" /> <timingExpression expression="2008-12-02T13:00" type="until" timingExpressionRef="TEWait" /> </interactionActivity> [...] <!-- any further process logic --> </process> • <process name="in-out" • targetNamespace="iaas.uni-stuttgart.de/meps" …> • <conversations> • <conversation name="IOCon"/> • </conversations> • <variables> • <variable name="aVariable" type="##opaque" /> • </variables> • <partners> • <partner name="aPartner" /> • </partners> • […] • <sequence> • <interactionActivity name="IO-In" conversation="IOCon" > • <output messageLabel="IO-In" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • <interactionActivity name="IO-Out" conversation="IOCon" > • <input messageLabel="IO-Out" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • </sequence> • <wait><timingExpression timingExpressionLabel =“TEWait“ /> </wait> • […] • </process> • <process name="in-out" • targetNamespace="iaas.uni-stuttgart.de/meps" …> • <conversations> • <conversation name="IOCon"/> • </conversations> • <variables> • <variable name="aVariable" type="##opaque" /> • </variables> • <partners> • <partner name="aPartner" /> • </partners> • […] • <sequence> • <interactionActivity name="IO-In" conversation="IOCon" > • <output messageLabel="IO-In" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • <interactionActivity name="IO-Out" conversation="IOCon" > • <input messageLabel="IO-Out" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • </sequence> • <wait><timingExpression timingExpressionLabel =“TEWait“ /> </wait> • […] • </process> • <process name="in-out" • targetNamespace="iaas.uni-stuttgart.de/meps" …> • <conversations> • <conversation name="IOCon"/> • </conversations> • <variables> • <variable name="aVariable" type="##opaque" /> • </variables> • <partners> • <partner name="aPartner" /> • </partners> • […] • <sequence> • <interactionActivity name="IO-In" conversation="IOCon" > • <output messageLabel="IO-In" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • <interactionActivity name="IO-Out" conversation="IOCon" > • <input messageLabel="IO-Out" variable="##opaque" /> • <partner name="aPartner" /> • </interactionActivity> • </sequence> • <wait><timingExpression timingExpressionLabel =“TEWait“ /> </wait> • […] • </process> MEP process 1 MEP process 1 Main process MEP process 2 MEP process 2 MEP process Parameterized by the „main process“

  26. request-for-bid <interactionActivity ... mep=“out-optional-in” <input messageLabel=“request-for-bid!Out” messageRef=“out-optional-in!Out”/> <output messageLabel=“request-for-bid!In” messageRef=“out-optional-in!In”/> ... </interactionActivity> Request-for-bid out-optional-in <interactionActivity ... mep=“out-only” <input messageLabel=“out-optional-in!Out” messageRef=“out-only!Out”/> ... </interactionActivity> In-optional-out <onMessagemessageLabel=“out-optional-in!In”/> out-only Out-only <interactionActivity ... <input messageLabel=“out-only!Out” ... </interactionActivity> 27

  27. Implementation The good thing is…: It’s really simple based on the tools already available  Extended Eclipse BPEL designer enables: Modelling abstract MEPs Using abstract MEPs for activity definitions Extended Apache ODE engine enables: Executing BPEL light processes MEPs describing activity behaviour are parameterized and executed as discrete instances of BPEL light processes in the engine 28

  28. 29

  29. 30

  30. 31

  31. Conclusion • BPEL is tied to WSDL • BPEL light decouples process logic and activity definitions (frees BPEL from WSDL) • Abstract BPEL light processes (MEPs) can be used to define the behaviour of interaction activities • Enables defining Message Exchange Patterns recursively • Allows to model more coarse grained executable process models • There are prototypes that enable modelling and executing BPEL light processes 32

More Related