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 - Proposal for Vote


Excellent.  Finally this gets sorted out.

This is the perfect way for BPEL to interface to the OASIS jCAM 
for information validation and packaging, including error signalling via 
the compensation

Also - since jCAM supports context headers - this allows some limited 
use of context
handling too - to tailor specific schema structures and business rules 
based on the
use case scenario and context of the intiator.

Thanks for making this integration possible.  People wanting to try this 
download the jCAM open source implementation from


Yaron Y. Goland wrote:

> Replace Section 11.3 with:
> 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.
> Schema:
> tInvoke
> From: <attribute name="inputVariable" type="NCName" use="optional"/>
>       <attribute name="outputVariable" type="NCName" use="optional"/>
> To: <attribute name="requestVariable" type="NCName" use="optional"/>
>     <attribute name="responseVariable" type="NCName" use="optional"/>
> tCorrelationWithPattern
> From: <enumeration value="in"/>
>       <enumeration value="out"/>
>       <enumeration value="out-in"/>
> To: <enumeration value="request"/>
>     <enumeration value="response"/>
>     <enumeration value="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]