1 / 91

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services (BPEL4WS). 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

jace
Download Presentation

Business Process Execution Language for Web Services (BPEL4WS)

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. Business Process Execution Language for Web Services (BPEL4WS)

  2. 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).

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

  4. 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

  5. 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 …..

  6. 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>

  7. 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

  8. 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

  9. 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

  10. 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 willnot if it does not affect the course of the protocol • Only properties are visible to abstract BP

  11. 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

  12. 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

  13. Abstract BP – Non-determinism computation that assigns a value to part x non-deterministic assignment to property x (alias of x) switch(x) switch(x ) Abstract BP Executable BP

  14. 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

  15. 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

  16. Communication – Client Side clientserver invoke invoke invoke receive • • • client waits (synchronous invoke) server exports interface (asynchronous invoke) • • • client continues • • • problem: how do you associate request with response? • • • • • • • • • • • client exports (callback) operation

  17. 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

  18. Communication – Server Side clientserver invoke receive • • • (synchronous invoke) reply receive server exports interface invoke (asynchronous invoke) • • • receive invoke • • • • • • • • receive invoke client exports (callback) interface

  19. Example: Purchase Order (PO) Service receive purchase order concurrency sequencing initiate price calculation decide on shipper initiate production scheduling complete price calculation arrange logistics complete production scheduling synchronization invoice processing, reply

  20. PO Service PO Service receive synchronous invocation POMsg Body of PO Service customer operation sendPurchOr on interface purchOrIf InvMsg reply

  21. 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> <input message=“pos:POMsg/> -- arguments supplied <ouput message=“pos:InvMsg”/> -- response </operation> </interface> ….. interface exported by PO Service prefix for target namespace in this document </definitions>

  22. 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 • Can be an XML simple type • Can be an XML schema element (which might have a complex type) • Has an associated scope <variable name=“PO” messageType=“lns:POMsg”/> • lns is prefix in BPEL document for the WSDL document

  23. 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 partner to be specified dynamically) <plnk:partnerLinkType name=“purchLT”> <plnk:role name=“purchService”> <plnk:interface name=“pos:purchOrIf”/> </plnk:role> </plnk:partnerLinkType> Unit of collaboration Only one role since only POService needs to provide an interface

  24. 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 of invoice requester BP playing role of invoice service invoiceCallbackIf computePriceIf

  25. 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 PO service name of partnerLink prefix lns refers to WSDL document <partnerLinks> <partnerLink name=“purchLink” partnerLinkType=“lns:purchLT” myRole=“purchService”/> <!-- other partnerLink’s go here --> </partnerLinks> hence PO service must provide purchOrIf

  26. 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>

  27. 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>

  28. plnk – prefix in WSDL doc refers to WSDL extension pos – target ns of WSDL doc lns – prefix in PO Service refers to WSDL doc cns – prefix in customer refers to WSDL doc Linkage: Customerto PO Service <plnk:partnerLinkType name=“purchLT> <plnk:role name=“purchService”> <plnk:interface name=“pos:purchOrIf”/> </plnk:role> </plnk:partnerLinkType> <partnerLink name=“linkToPurch” partnerLinkType=“cns:purchLT” partnerRole=“purchService”/> <partnerLink name=“purchLink” partnerLinkType=“lns:purchLT” myRole=“purchService”/> WSDL inter- face exported by PO Service partner specification in customer process partner specification in PO Service

  29. 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>

  30. PO Service (BPEL) <variables> <variable name=“PO” messageType=“lns:POMsg”/> <variable name=“Invoice” messageType=“lns:InvMsg”/> </variables> <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> Both necessary since PO Service might communicate with several BPs through the same interface

  31. Interaction with Shipping Provider operation requestShipping on interface shippingIf decide on shipper (invoke) shipReqMsg shippingProvider shipInfoMsg scheduleMsg arrange logisitics (receive) role = shippingService operation sendSchedule on port shippingCallbackIf role = shippingRequester

  32. Handling Shipping (WSDL) <interface name=“shippingCallbackIf”> <operation name=“sendSchedule”> <input message=“…”/> </operation> </interface> <interface name=“shippingIf”> <operation name=“requestShipping”> <input message=“…”/> <output message=“…”/> </operation> </interface> interface exported by PO Service interface imported from shipping service

  33. Handling Shipping <plnk:partnerLinkType name=“shippingLT”> <plnk:role name=“shippingService”> <plnk:interface name=“pos:shippingIf”/> </plnk:role> <plnk:role name=“shippingRequester”> <plnk:interface name=“pos:shippingCallBackIf/> </plnk:role> </plnk:partnerLinkType> <partnerLink name=“shippingProvider” partnerLinkType=“lns:shippingLT” myRole=“shippingRequester” partnerRole=“shippingService”/> WSDL BPEL

  34. Handling Shipping (BPEL) contains input message <sequence> <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>

  35. 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 needed by complete production scheduling • data communicated through globally shared variable decide on shipper initiate production scheduling arrange logistics complete production scheduling link source target

  36. <flow> <links> <link name=“ship-sched”/> </links> <sequence> <assign> …. </assign> <invoke partnerLink= ….> </invoke> <receive partnerLink= …. variable=“shippingSched”> <source linkName=“ship-sched”/> </receive> </sequence> <sequence> <invoke partnerLink=….> </invoke> <invoke partnerLink=…. inputVariable=“shippingSched”> <target linkName=“ship-sched”/> </invoke> </sequence> …. </flow> Links decide on shipper shipping arrange logistics complete production scheduling scheduling

  37. 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’/>

  38. 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

  39. 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)

  40. 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 conversation

  41. Using Correlation Sets • A particular receive operation can be used in a BP to accept the start of a new conversation • All subsequently arriving messages with same value of PurchaseOrder will be directed to this BP asynchronous purchase requst <receive partnerLink =“Buyer” interface=“SP:PurchasingIf” operation=“asynchPurchase” variable=“PO”> <correlations> <correlation set=“PurchaseOrder” initiate=“yes”/> </correlations> </receive> create a new correlation set value for BP instance

  42. Using Correlation Sets • Response returns the correlation set value • Asynchronous (callback) response to previous invocation • A reply to a synchronous invocation would be similar <invoke partnerLink “Buyer” interface=“SP:BuyerIf” operation=“asynchPurchaseResp” variable=“PO”> <correlations> <correlation set=“PurchaseOrder” initiate=“no”/> </correlations> </invoke> use the set to address the message

  43. 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”) subsequent messages sent and received use correlation set inv messsage contains both correlation sets

  44. 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>

  45. 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: • All processes can use: • 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. bpws:getVariableData (‘variableName’, ‘partName’, ‘locationPath’?) query string bpws:getVariableProperty(‘variableName’, ‘propertyName’) property alias contains query string

  46. Assignment • Allows copying of data • One form (for executable processes): • 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) <assign> <copy> <from variable=“v1” part=“p1” query=“q1”/> <to variable=“v2” part=“p2” query=“q2”/> </copy> </assign>

  47. 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>

  48. 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>

  49. 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>

  50. 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.

More Related