[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]