Web Services Business Process Execution Language Version 0 Public Review Draft 02, 20 November, 2006

səhifə	16/23
tarix	27.06.2016
ölçüsü	2.65 Mb.

1 ... 12 13 14 15 16 17 18 19 ... 23

14. Extension Declarations

WS-BPEL is designed to be extensible. Extensions to WS-BPEL could include anything ranging from new attributes to new elements, to extended assign operations and activities, to enable restrictions or extensions of run time behavior and so on.
...

?

+

...
The child element under element of the element is used to declare namespaces of WS-BPEL extension attributes/elements and indicate whether they carry semantics that must be understood by a WS-BPEL processor.

If a WS-BPEL processor does not support one or more of the extensions with mustUnderstand="yes", then the process definition MUST be rejected.

Optional extensions are extensions which the WS-BPEL process MAY ignore. There is no requirement to declare any optional extensions. Optional extension can be declared using the extensions element with mustUnderstand="no". The purpose of allowing optional extensions to be declared using the extensions element is to provide a well defined location where additional information about the optional extension can be found.

The declaration element under is itself extensible.

The same extension URI MAY be declared multiple times in the element. If an extension URI is identified as mandatory in one element and optional in another, then the mandatory semantics have precedence and MUST be enforced. The extension declarations in an element MUST be treated as an unordered set. That is, WS-BPEL does not provide any way to establish precedence between extension declarations based on ordering.

An extension declared through the element MUST NOT, in and of itself, cause any change to the semantics of a WS-BPEL process. Rather, the extension declaration defines whether the extensions identified by the denoted namespace must be supported or can safely be ignored.

In order to apply extension semantics to a WS-BPEL process, an extension syntax token, in the form of an element or attribute qualified by the URI value of a namespace attribute in an element that is used outside of an element, MUST appear in the WS-BPEL process definition or its directly referenced WSDL

definitions, definitions or definitions. It is this extension syntax token, rather than the extension declaration, that indicates the new semantics apply.

An extension syntax token can only affect WS-BPEL constructs within the syntax sub-tree of the parent element of the token. In other words, extension syntax token MUST NOT affect the semantics outside the subtree. Here are two examples to illustrate this concept further:

...

foo:invokeProperty="someNature" ... />

foo:invokeProperty="someNature2" ... />

...
The "foo:invokeProperty" extension attribute are applied to activities for "operation1" and "operation3". The activity for "operation2" must not be affected.

...

SomeNature

...
The "foo:invokeProperty" extension element can be applied to all activities within the activity where the extension element are attached to.

15. Examples

The examples in this section are not completely specified. For instance, the shipping service example imports XML Schema elements from the namespace “http://example.com/shipping/ship.xsd”, which is not fully specified in this document.

15.1. Shipping Service

This example presents a WS-BPEL Abstract Process for a rudimentary shipping service. This service handles the shipment of orders, and orders are composed of a number of items. The shipping service offers two options, one for shipments where the items are shipped all together, and one for partial shipments where the items are shipped in groups until the order is fulfilled.

15.1.1. Service Description

The context for the shipping service is an interaction between a customer and the service. This is modeled with a partnerLinkType definition (shippingLT.wsdl):

targetNamespace="http://example.com/shipping/partnerLinkTypes/"

xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"

xmlns:sif="http://example.com/shipping/interfaces/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

namespace="http://example.com/shipping/interfaces/" />

portType="sif:shippingServicePT" />

portType="sif:shippingServiceCustomerPT" />

The corresponding message and portType definitions are as follows (shippingPT.wsdl):

targetNamespace="http://example.com/shipping/interfaces/"

xmlns:ship="http://example.com/shipping/ship.xsd"

xmlns:tns="http://example.com/shipping/interfaces/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

15.1.2. Properties

The properties relevant to the service are:

The shipping order ID (shipOrderID) is used to correlate the shipping notice(s) with the shipping order.
Whether the order is to be shipped complete or not (shipComplete).
The total number of items in the order (itemsTotal).
The number of items in a ship notice (itemsCount). When partial shipments are acceptable, itemsCount and itemsTotal are used to track the fulfillment of the order.

The definitions for the properties and their aliases are (shippingProperties.wsdl):

targetNamespace="http://example.com/shipping/properties/"

xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop"

xmlns:ship="http://example.com/shipping/ship.xsd"

xmlns:sif="http://example.com/shipping/interfaces/"

xmlns:tns="http://example.com/shipping/properties/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

namespace="http://example.com/shipping/interfaces/" />

domains. The itemCountType is restricted by range -->

targetNamespace="http://example.com/shipping/ship.xsd">

messageType="sif:shippingRequestMsg" part="shipOrder">

ship:ShipOrderRequestHeader/ship:shipOrderID

messageType="sif:shippingNoticeMsg" part="shipNotice">

ship:ShipNoticeHeader/ship:shipOrderID

messageType="sif:shippingRequestMsg" part="shipOrder">

ship:ShipOrderRequestHeader/ship:shipComplete

messageType="sif:shippingRequestMsg" part="shipOrder">

ship:ShipOrderRequestHeader/ship:itemsTotal

messageType="sif:shippingRequestMsg" part="shipOrder">

ship:ShipOrderRequestHeader/ship:itemsCount

messageType="sif:shippingNoticeMsg" part="shipNotice">

ship:ShipNoticeHeader/ship:itemsCount

15.1.3. Process

For brevity, the Abstract Process definition does not include details such as the handling of error conditions that a complete process description would likely provide. The outline of the process is as follows:

receive shipOrder

if
condition shipComplete

send shipNotice

else

itemsShipped := 0

while itemsShipped < itemsTotal

itemsCount := opaque // non-deterministic assignment

// corresponding e.g. to

// internal interaction with

// back-end system

send shipNotice

itemsShipped = itemsShipped + itemsCount
The WS-BPEL process is as follows:

targetNamespace="http://example.com/shipping/"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/abstract"

xmlns:plt="http://example.com/shipping/partnerLinkTypes/"

xmlns:props="http://example.com/shipping/properties/"

xmlns:ship="http://example.com/shipping/ship.xsd"

xmlns:sif="http://example.com/shipping/interfaces/"

abstractProcessProfile="http://docs.oasis-open.org/wsbpel/2.0/process/abstract/ap11/2006/08">

location="shippingLT.wsdl"

namespace="http://example.com/shipping/partnerLinkTypes/" />

location="shippingPT.wsdl"

namespace="http://example.com/shipping/interfaces/" />

location="shippingProperties.wsdl"

namespace="http://example.com/shipping/properties/" />

partnerRole="shippingServiceCustomer"

myRole="shippingService" />

messageType="sif:shippingRequestMsg" />

messageType="sif:shippingNoticeMsg" />

type="ship:itemCountType" />

properties="props:shipOrderID" />

operation="shippingRequest"

variable="shipRequest">

bpel:getVariableProperty('shipRequest',

'props:shipComplete')

property="props:shipOrderID" />

property="props:itemsCount" />

operation="shippingNotice"

inputVariable="shipNotice">

0

$itemsShipped

$itemsShipped

bpel:getVariableProperty('shipRequest',

'props:itemsTotal')

property="props:shipOrderID" />

property="props:itemsCount" />

operation="shippingNotice"

inputVariable="shipNotice">

pattern="request" />

$itemsShipped

bpel:getVariableProperty('shipNotice',

'props:itemsCount')

$itemsShipped

15.2. Ordering Service

This example expands on the shipping service to illustrate the use of an Abstract Process using the template profile. This Abstract Process describes a set of services to request, track, and confirm orders and their shipments, invoicing, and payment. The ordering service receives orders from an order processor, sends a shipping request to the shipping service, and acknowledges shipment, pickup, invoicing, and payment as each is performed.

15.2.1. Service Description

The context for the ordering service is an interaction between a consumer and the service. This is modeled in the following partnerLinkType definition (orderingLT.wsdl):

targetNamespace="http://example.com/ordering/partnerLinkTypes/"

xmlns:oif="http://example.com/ordering/interfaces/"

xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

namespace="http://example.com/ordering/interfaces/" />

portType="oif:orderingPT" />

portType="oif:orderingResponsePT" />

portType="oif:shippingServicePT" />

portType="oif:shippingServiceResponsePT" />

portType="oif:orderingConfirmationPT" />

The corresponding message and portType definitions are as follows (orderingPT.wsdl):

targetNamespace="http://example.com/ordering/interfaces/"

xmlns:order="http://example.com/ordering/order.xsd"

xmlns:tns="http://example.com/ordering/interfaces/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

element="order:OrderAckMessage" />

element="order:ShipRequestMessage" />

element="order:ShipNoticeMessage" />

element="order:ShipHistoryMessage" />

element="order: InvoiceAckMessage" />

Although there are more interactions between consumer and service, not all have been modeled in this example. Un-modeled interactions are opaque.

15.2.2. Properties

The properties relevant to the service are:

The order ID (orderID) is used to correlate the order placement with the shipping request, shipping notice, invoice confirmation, pickup confirmation and final order confirmation. For this example, only the shipping request, shipping notice and final confirmation are defined

The order ID and aliases are defined as follows (orderingProperties.wsdl):

targetNamespace="http://example.com/ordering/properties/"

xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop"

xmlns:oif="http://example.com/ordering/interfaces/"

xmlns:order="http://example.com/ordering/order.xsd"

xmlns:tns="http://example.com/ordering/properties/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

namespace="http://example.com/ordering/interfaces/" />

messageType="oif:OrderMessageType" part="OrderMessagePart">

order:OrderMessageHeader/order:orderID

messageType="oif:ShipNoticeMessageType"

part="ShipNoticeMessagePart">

order:ShipNoticeMessageHeader/order:orderID

Although there are more messages between the consumer and the service, not all have been modeled. Un-modeled messages are opaque.

15.2.3. Process

This Abstract Process uses the template profile. The outline is as follows:

receive placeOrder

send shipOrder

condition shipCompleted

send orderNotice (indicating shipCompleted)

else

send orderNotice (indicating !shipCompleted)
receive pickupNotification

update shipHistory

receive invoice

send invoiceResponse

receive paymentConfirmation

send orderConfirmation

The WS-BPEL process is as follows:

targetNamespace="http://example.com/ordering/"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/abstract"

xmlns:ext="http://example.com/bpel/some/extension"

xmlns:oif="http://example.com/ordering/interfaces/"

xmlns:order="http://example.com/ordering/order.xsd"

xmlns:plt="http://example.com/ordering/partnerLinkTypes/"

xmlns:props="http://example.com/ordering/properties/"

xmlns:tns="http://example.com/ordering/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

abstractProcessProfile="http://docs.oasis-open.org/wsbpel/2.0/process/abstract/simple-template/2006/08"

suppressJoinFailure="yes">

location="orderingLT.wsdl"

namespace="http://example.com/ordering/partnerLinkTypes/" />

location="orderingPT.wsdl"

namespace=" http://example.com/ordering/interfaces/" />

location="orderingProperties.wsdl"

namespace="http://example.com/ordering/properties/" />

mustUnderstand="no" />

partnerLinkType="plt:orderingServiceLT"

myRole="orderingService"

partnerRole="orderingServiceResponse" />

partnerLinkType="plt:shipperLT"

myRole="shippingServiceResponse"

partnerRole="shippingService" />

partnerLinkType="##opaque"

myRole="##opaque" />

partnerLinkType="##opaque"

myRole="##opaque"

partnerRole="##opaque" />

partnerLinkType="plt:completionConfirmationLT"

partnerRole="orderingServiceConfirmation" />

initiation -->

messageType="oif:OrderAckMessageType" />

element="order:OrderAckMessage" />

element="order:ShipRequestMessage" />

element="order:ShipNoticeMessage" />

messageType="oif:ShippingHistoryMessageType" />

messageType="oif:InvoiceAckMessageType" />

variable="order" createInstance="yes">

$order.OrderMessagePart/order:OrderMessageHeader/

order:orderID

$shippingRequestMsg/order:ShipRequestMessageHeader/

order:orderID

$order.OrderMessagePart/order:ShippingInfo

$shippingRequestMsg/order:ShippingInfo

inputVariable="shippingRequestMsg"

ext:uniqueUserFriendlyName="send shipping request to

shipper"/>

portType="oif:shippingServiceCustomerPT"

operation="shippingNotice"

variable="shippingNoticeMsg"

ext:uniqueUserFriendlyName="receive response from shipper">

$order.OrderMessagePart/order:OrderMessageHeader/

order:orderID

$orderAckMsg.OrderAckMessagePart/

order:OrderAckMessageHeader/order:orderID

the first case would package the order

acknowledgement for a completed shipment

-->

$orderAckMsg.OrderAckMessagePart/order:Ack

the second case would package the order

acknowledgement for an uncompleted shipment

-->

$orderAckMsg.OrderAckMessagePart/order:Ack

operation="getOrderAck"

inputVariable="orderAckMsg" />

operation="##opaque"

variable="##opaque"

ext:uniqueUserFriendlyName="receive the pickup notification">

$shipHistoryMsg.ShipHistoryMessagePart/order:Event

If we receive notice that the ship has completed, update

our ship history accordingly

variable="##opaque"

ext:uniqueUserFriendlyName="receive invoice for processing">

$invoiceAckMsg.InvoiceAckMessagePart

inputVariable="##opaque"

ext:uniqueUserFriendlyName="send response for the invoice" />

variable="##opaque"

ext:uniqueUserFriendlyName="receive payment confirmation">

$orderShippedMsg/order:Ack

$order.OrderMessagePart/order:OrderMessageHeader/

order:orderID

$orderShippedMsg/order:OrderAckMessageHeader/

order:orderID

operation="getOrderConfirmation"

inputVariable="orderShippedMsg" />

15.3. Loan Approval Service

This example consists of a simple loan approval service. Customers of the service send loan requests, including personal information and amount being requested. Using this information, the loan service executes a simple process resulting in either a "loan approved" message or a "loan rejected" message. The decision is based on the amount requested and the risk associated with the customer. For low amounts of less than $10,000 a streamlined process is used. In the streamlined process low-risk customers are approved automatically. For higher amounts, or medium and high-risk customers, the credit request requires further processing. For each request, the loan service uses the functionality provided by two other services. In the streamlined process, used for low amount loans, a risk assessment service is used to obtain a quick evaluation of the risk associated with the customer. A full loan approval service (possibly requiring direct involvement of a loan expert) is used to obtain assessments when the streamlined approval process is not applicable.

15.3.1. Service Description

The WSDL portType (loanServicePT) used by this service is shown below. This example assumes that an independent "loan.org" consortium has provided definitions of the loan service portType as well as the risk assessment and full loan approval service, so all the required WSDL definitions appear in the same WSDL document. In particular, the portTypes for the Web Services providing the risk assessment and approval functions, and all the required partnerLinkTypes that relate to the use of these portTypes, are defined in the WSDL (loanServicePT.wsdl).

targetNamespace="http://example.com/loan-approval/wsdl/"

xmlns:ens="http://example.com/loan-approval/xsd/error-messages/"

xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"

xmlns:tns="http://example.com/loan-approval/wsdl/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema/">

message="tns:errorMessage" />

15.3.2. Process

In the process, the interaction with the customer is represented by the initial and the matching activities. The use of risk assessment and loan approval services is represented by elements. All these activities are contained within a , and their (potentially concurrent) behavior is executed according to the dependencies expressed by the elements. Note that the transition conditions attached to the elements of the links determine which links get activated. Dead path elimination is enabled by setting the suppressJoinFailure attribute to yes on the
element (See section 11.6.3. Dead-Path Elimination).

The operations invoked can return a fault of type loanProcessFault, therefore a fault handler is provided. When a fault occurs, control is transferred to the fault handler where a element is used to return a fault response of type unableToHandleRequest to the loan requester.

targetNamespace="http://example.com/loan-approval/"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:lns="http://example.com/loan-approval/wsdl/"

suppressJoinFailure="yes">

location="loanServicePT.wsdl"

namespace="http://example.com/loan-approval/wsdl/" />

partnerLinkType="lns:loanPartnerLT"

myRole="loanService" />

partnerLinkType="lns:loanApprovalLT"

partnerRole="approver" />

partnerLinkType="lns:riskAssessmentLT"

partnerRole="assessor" />

messageType="lns:creditInformationMessage" />

messageType="lns:riskAssessmentMessage" />

messageType="lns:approvalMessage" />

faultVariable="error"

faultMessageType="lns:errorMessage">

portType="lns:loanServicePT"

operation="request" variable="error"

faultName="unableToHandleRequest" />

portType="lns:loanServicePT"

operation="request"

variable="request"

createInstance="yes">

$request.amount < 10000

$request.amount >= 10000

portType="lns:riskAssessmentPT"

operation="check"

inputVariable="request"

outputVariable="risk">

$risk.level='low'

$risk.level!='low'

yes

portType="lns:loanApprovalPT"

operation="approve"

inputVariable="request"

outputVariable="approval">

portType="lns:loanServicePT"

operation="request"

variable="approval">

15.4. Auction Service

A process may have multiple activities capable of creating an instance of the process. An example can be a simplified auction house process. The process collects information from the buyer and the seller of a particular auction, report the appropriate auction results to an auction registration service, and then send the registration result back to the seller and the buyer. The process may start either by receiving the seller information, or by receiving the buyer information. Because a particular auction is uniquely identified by an auction ID, the seller and the buyer need to provide this information when sending their data. The sequence in which the seller and buyer requests arrive at the auction house is random. When a request comes in, it needs to check whether a process instance exists already or not. If no process instance already exists then one is created. When both requests have been received, the auction registration service is invoked. Because the invocation is done one-way, the auction house passes the auction ID to the auction registration service. The auction registration service returns this auction ID in its answer for the auction house to locate the proper process instance. Each buyer or seller provides an endpoint reference for the auction service to respond properly. In addition, the auction house provides its own endpoint reference to the auction registration service for the auction registration service to send the response back to the auction house.

15.4.1. Service Description

The auction service offers two portTypes, called sellerPT and buyerPT, with appropriate operations for accepting the data provided by the seller and the buyer. The auction service responds to the seller and buyer through appropriate portTypes, sellerAnswerPT and buyerAnswerPT. These portTypes are properly combined into two partnerLinkTypes, one for the seller called sellerAuctionHouseLT and one for the buyer called buyerAuctionHouseLT.

The auction service needs two portTypes, called auctionRegistrationPT and auctionRegistrationAnswerPT, for the invocation of the auction registration service. The portTypes are part of the partnerLinkType auctionHouseAuctionRegistrationServiceLT (auctionServiceInterface.wsdl).

targetNamespace="http://example.com/auction/wsdl/auctionService/"

xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop"

xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"

xmlns:sref="http://docs.oasis-open.org/wsbpel/2.0/serviceref"

xmlns:tns="http://example.com/auction/wsdl/auctionService/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

auction registration service -->

type="sref:ServiceRefType" />

auction registration service -->

via auction Id -->

messageType="tns:sellerData" part="auctionId" />

messageType="tns:buyerData" part="ID" />

messageType="tns:auctionData" part="auctionId" />

messageType="tns:auctionAnswerData" part="auctionId" />

registration service -->

name="auctionHouseAuctionRegistrationServiceLT">

portType="tns:auctionRegistrationPT" />

portType="tns:auctionRegistrationAnswerPT" />

15.4.2. Process

The WS-BPEL process for the auction house is as follows:

targetNamespace="http://example.com/auction"

xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"

xmlns:sref=" http://docs.oasis-open.org/wsbpel/2.0/serviceref"

xmlns:addr="http://example.com/addressing"

xmlns:as="http://example.com/auction/wsdl/auctionService/">

location="auctionServiceInterface.wsdl"

namespace="http://example.com/auction/wsdl/auctionService/" />

partnerLinkType="as:sellerAuctionHouseLT"

myRole="auctionHouse"

partnerRole="seller" />

partnerLinkType="as:buyerAuctionHouseLT"

myRole="auctionHouse"

partnerRole="buyer" />

partnerLinkType="as:auctionHouseAuctionRegistrationServiceLT"

myRole="auctionHouse"

partnerRole="auctionRegistrationService" />

messageType="as:sellerData" />

messageType="as:sellerAnswerData" />

messageType="as:buyerData" />

messageType="as:buyerAnswerData" />

messageType="as:auctionData" />

messageType="as:auctionAnswerData" />

properties="as:auctionId" />

Either one can create a process instance -->

partnerLink="seller"

portType="as:sellerPT"

operation="submit"

variable="sellerData"

createInstance="yes">

initiate="join" />

partnerLink="buyer"

portType="as:buyerPT"

operation="submit"

variable="buyerData"

createInstance="yes">

initiate="join" />

endpoint reference and setting my own endpoint reference

for call back and receiving the answer Correlation of

request and answer is via auction Id -->

http://example.com/auction/

RegistrationService/

as:RegistrationService

endpointReference="myRole" />

$auctionData.auctionHouseEndpointReference

$sellerData.auctionId

$auctionData.auctionId

1

$auctionData.amount

partnerLink="auctionRegistrationService"

portType="as:auctionRegistrationPT"

operation="process"

inputVariable="auctionData" />

partnerLink="auctionRegistrationService"

portType="as:auctionRegistrationAnswerPT"

operation="answer"

variable="auctionAnswerData">

the endpoint reference provided by the seller

and invoking the response -->

$sellerData.endpointReference

Thank you!

$sellerAnswerData.thankYouText

partnerLink="seller"

portType="as:sellerAnswerPT"

operation="answer"

inputVariable="sellerAnswerData" />

the endpoint reference provided by the buyer

and invoking the response -->

$buyerData.endpointReference

Thank you!

$buyerAnswerData.thankYouText

partnerLink="buyer"

portType="as:buyerAnswerPT"

operation="answer"

inputVariable="buyerAnswerData" />

1 ... 12 13 14 15 16 17 18 19 ... 23