OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 110 - Rough draft for proposal to vote


-1

this ties our semantics too closely to HTTP-like semantics and makes 
thinking about JMS-topic-like transports too difficult.

Yaron Y. Goland wrote:

> This is a rough draft of a proposal for new text in section 11.3. The 
> only normative change I made to the text was changing the name of 
> inputVariable to requestVariable and outputVariable to 
> responseVariable. I also changed in|out|out-in to 
> request|response|request-response. In editing the language I took into 
> account issue 122:
>
> Section 11.3:
>
> BPEL processes can call Web Services to perform work on their behalf 
> (see Partner Link Types, Partner Links and Endpoint References). A 
> BPEL process invokes a web service using the invoke activity.
>
> <invoke partnerLink="ncname" portType="qname"? operation="ncname"
>     requestVariable="ncname"? responseVariable="ncname"?
>     standard-attributes>
>     standard-elements
>     <correlations>?
>          <correlation set="ncname" initiate="yes|no"?
>         pattern="request|response|request-response"/>+
>         </correlations>
>     <catch faultName="qname" faultVariable="ncname"?
>                          faultMessageType="qname"?>*
>             activity
>     </catch>
>     <catchAll>?
>             activity
>     </catchAll>
>     <compensationHandler>?
>           activity
>     </compensationHandler>
> </invoke>
>
> The invoke activity is used anytime a BPEL process wishes to send a 
> message to another web service. In the case of a one-way message 
> exchange pattern (MEP) the invoke activity will return as soon as the 
> message is sent. In the case of a request/response MEP the invoke 
> activity will not return until the response is received, this behavior 
> applies even if the underlying request/response MEP is asynchronous.
>
> On a one-way MEP the requestVariable attribute is used to specify the 
> message to be sent. The responseVariable attribute is not used as no 
> response is sent to a one-way MEP. On a request/response MEP the 
> requestVariable attribute is used to specify the message to be sent 
> and the responseVariable attribute is used to record the response that 
> is returned.
>
> The partnerLink, portType and operation attributes play their usual 
> roles of identifying exactly what message is to be sent and to whom.
>
> Correlation sets MAY be used on invoke activities to coordinate with 
> stateful partner processes. See Correlation for more information.
>
> The invoke activity has an in-line fault handler. The in-line fault 
> handler allows the invoke activity to handle any WSDL fault messages 
> that may be received in response to a request/response MEP directly 
> within the invoke activity itself. If the invoke activity's fault 
> handler does not catch a WSDL or other fault then the fault will be 
> thrown to the scope that encloses the activity (see Scopes and Fault 
> Handlers).
>
> Note that a WSDL fault is identified in BPEL by a qualified name 
> formed by the target namespace of the corresponding portType and the 
> fault name. This uniform naming mechanism must be followed even though 
> it does not accurately match WSDL’s fault naming model. Because WSDL 
> does not require that fault names be unique within the namespace where 
> the service operation is defined, all faults sharing a common name and 
> defined in the same namespace are indistinguishable in BPEL. In WSDL 
> 1.1 it is necessary to specify a portType name, an operation name, and 
> the fault name to uniquely identify a fault. This limits the ability 
> to use fault-handling mechanisms to deal with invocation faults.
>
> Finally, the invoke activity has an in-line compensation handler. This 
> compensation handler can be invoked either explicitly or by the 
> default compensation handler of the enclosing scope (see Scopes and 
> Compensation Handlers).
>
> Semantically, the specification of local fault and/or compensation 
> handlers is equivalent to the presence of an implicit scope 
> immediately enclosing the activity and providing those handlers. The 
> name of such an implicit scope is always the same as the name of the 
> activity it encloses.
>
> The following example shows an invocation with a nested compensation 
> handler. Other examples are shown throughout the specification.
>
> <invoke partnerLink="Seller" portType="SP:Purchasing"
>     operation="SyncPurchase"
>     requestVariable="sendPO"
>     responseVariable="getResponse">
>      <compensationHandler>
>     <invoke partnerLink="Seller" portType="SP:Purchasing"
>          operation="CancelPurchase"
>         requestVariable="getResponse"
>         responseVariable="getConfirmation">
>      </compensationHandler>
> </invoke>
>
>
> Section 10.2
>
> From: Finally, in the case of invoke, when the operation invoked is 
> synchronous request/response, a pattern attribute is used to indicate 
> whether the correlation applies to the outbound (request) message, the 
> inbound (response) message, or both.
>
> To: Finally, in the case of invoke, when the operation invoked is a 
> request/response message exchange pattern, a pattern attribute is used 
> to indicate whether the correlation applies to the request message, 
> the response message, or both.
>
> Entire Spec:
>
> A global replace of inputVariable with requestVariable and 
> outputVariable with responseVariable as well as a global replace of 
> all values of pattern from in|out|out-in to 
> request|response|response-request.
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]