[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 12 - Proposal For Vote
+1 again. Your batting a 1000 today, Yaron. This is not only an improvement by making processes simpler and more more straightforward, but also supports the use of doc/lit, which I think is a responsible, forward-looking thing. -Ron Yaron Y. Goland wrote: > Issue 12 - XML types and WS Interactions > > Proposal: Allow messaging activities involving messageTypes with a > single part defined using an element (e.g. a WS-I doc/lit) to submit a > BPEL variable of the same element type as the part directly to the > message activity rather than having to submit a BPEL messageType > variable. > > Rationale: Today all message activities in BPEL require the use of a > WSDL messageType variable. But moving forward it is expected that > WS-I’s doc/lit design pattern will be a common Web Services design > pattern. This pattern requires that a message have exactly one part > and that the part be defined using an element. In other words messages > having to look something like: > > <xsd:element name="myElem"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="xsdtns:detail" ... /> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > ... > <wsdl:message name="myMsgType"> > <wsdl:part name="myPartName" element="xsdtns:myElem" /> > </wsdl:message> > > Rather than requiring users to wrap the single element of content into > a messageType variable it would be much simpler to allow, in these > cases, for the user to directly submit an element BPEL variable to the > message operation. The consequence is that a BPEL which only deals > with WS-I compliant doc/lit operations would never need to use > messageType variables at all. They could just use element variables. > > Allowing this optimization, besides making BPEL code simpler, would > also put BPEL in very good shape for the eventual transition to WSDL > 2.0. WSDL 2.0 messages do not have any parts at all and are defined > exclusively using XML elements. So by allowing for message activities > that interact with WSDL 1.1 messages with a single element-based part > to avoid using messageType variables and just use XML variables we > make it much easier for BPEL 2.0 code to make the transition to a WSDL > 2.0 world. > > Changes Required: This proposal depends on issue 93 and 145. In the > case where a messageType consists of a single part defined using an > element it will be legal to submit a BPEL element variable instead of > a messageType variable to messaging activities. The onEvent handler > will be extended to have an element attribute in addition to a > messageType attribute. The catch semantics are extended so that if > there is no messageType based catch that matches a fault whose data is > a messageType then if the messageType has one part defined using an > element then a matching element based catch can grab it. > > Section 11.3 > > Add to the end of the section: > If the WSDL operation used to send and/or receive a message in an > invoke activity is defined as a message containing exactly one part > which itself is defined using an element then a BPEL variable of the > same element type as used to define the part MAY be submitted directly > to the invoke activity. The result of submitting a BPEL variable in > the previously defined circumstance MUST be the equivalent of > declaring an anonymous temporary WSDL message variable based on the > associated WSDL message type. In the case of an inputVariable the > value of the submitted BPEL variable will be used to set the value of > the part in the anonymous temporary WSDL message variable. In the case > of an outputVariable the value of the received part in the temporary > WSDL message variable will be used to set the value of the submitted > BPEL variable. > > Section 11.4 > > Insert after the paragraph that begins “It is permissible to have the > createInstance attribute”: > If the WSDL operation used to receive or send a message in a > request/reply activity is defined as a message containing exactly one > part which itself is defined using an element then a BPEL variable of > the same element type as used to define the part MAY be submitted > directly to the request/reply activity. The result of submitting a > BPEL variable in the previously defined circumstance MUST be the > equivalent of declaring an anonymous temporary WSDL message variable > based on the associated WSDL message type. In the case of a receive > activity, the incoming part’s value will be used to set the value of > the submitted BPEL variable. In the case of a reply activity the value > of the submitted BPEL variable will be used to set the value of the > part in the anonymous temporary WSDL message variable that is sent > out. In the case of a reply that is sending a fault the same logic > applies but using a fault name rather than an operation name. > > Section 12.4 > > Change: Each pick activity MUST include at least one onMessage event. > The semantics of the onMessage event is identical to a receive > activity regarding the optional nature of the variable attribute, the > handling of race conditions, and the constraint regarding simultaneous > enablement of conflicting receive actions. > > To: Each pick activity MUST include at least one onMessage event. The > semantics of the onMessage event is identical to a receive activity > regarding the optional nature of the variable attribute, the handling > of race conditions, the single element-based part message short cut > and the constraint regarding simultaneous enablement of conflicting > receive actions. > > Section 13.4 > > Change: A fault response to an invoke activity is one source of > faults, with obvious name and data aspects based on the definition of > the fault in the WSDL operation. > > To: A fault response to an invoke activity is one source of faults, > with name and data aspects based on the definition of the fault in the > WSDL operation. > > Change: Because of the flexibility allowed in expressing the faults > that a catch activity can handle, it is possible for a fault to match > more than one fault handler. The following rules are used to select > the catch activity that will process a fault: > • If the fault has no associated fault data, a catch activity that > specifies a matching faultName value and no faultVariable attribute > will be selected if present. Otherwise, the default catchAll handler > is selected if present. > • If the fault has associated fault data, a catch activity > specifying a matching faultName value and a faultVariable whose type > (WSDL message type) matches the type of the fault’s data will be > selected if present. Otherwise, a catch activity with no specified > faultName and with a faultVariable whose type matches the type of the > fault data will be selected if present. Otherwise, the default > catchAll handler is selected if present. > If no catch or catchall is selected, the fault is not caught by the > current scope and is rethrown to the immediately enclosing scope (see > Implicit Fault and Compensation Handlers for a more complete > description of the default fault and compensation handling behavior). > If the fault occurs in (or is rethrown to) the global process scope, > and there is no matching fault handler for the fault at the global > level, the process terminates abnormally, as though an exit activity > had been performed. > > To: Because of the flexibility allowed in expressing the faults that a > catch activity can handle, it is possible for a fault to match more > than one fault handler. > > In the case of faults thrown without associated data the fault will be > caught as follows: > • If there is a catch activity with a matching faultName value that > does not specify a faultVariable attribute then the fault is passed to > the identified catch activity. > • Otherwise if there is a catchAll handler then the fault is passed > to the catchAll handler. > • Otherwise the fault is thrown to the immediately enclosing scope. > > In the case of faults thrown with associated data the fault will be > caught as follows: > • If there is a catch activity with a matching faultName value that > has a faultVariable whose type matches the type of the fault data then > the fault is passed to the identified catch activity. > • Otherwise if the fault data is a WSDL message type where the > message contains a single part defined by an element and there exists > a catch activity with a matching faultName value that has a > faultVariable whose type matches the type of the element used to > define the part then the fault is passed to the identified catch > activity with the faultVariable initialized to the value in the single > part’s element. > • Otherwise if there is a catch activity without a faultName > attribute that has a faultVariable whose type matches the type of the > fault data then the fault is passed to the identified catch activity. > • Otherwise if the fault data is a WSDL message type where the > message contains a single part defined by an element and there exists > a catch activity without a faultName attribute that has a > faultVariable whose type matches the type of the element used to > define the part then the fault is passed to the identified catch > activity with the faultVariable initialized to the value in the single > part’s element. > • Otherwise if there is a catchAll handler then the fault is passed > to the catchAll handler. > • Otherwise the fault is thrown to the immediately enclosing scope. > > If the fault occurs in (or is rethrown to) the global process scope, > and there is no matching fault handler for the fault at the global > level, the process terminates abnormally, as though an exit activity > had been performed. See Implicit Fault and Compensation Handlers for a > more complete description of the default fault and compensation > handling behavior. > > Section 13.5 > > Change the onEvent element definition to make messageType optional and > add an optional element attribute. > > <onEvent partnerLink="ncname" portType="qname"? > operation="ncname" variable="ncname"? > (messageType="qname" | element="qname" )? > > > Insert after the schema: All instances of onEvent MUST use either the > messageType or element attribute but not both. > > > Section 13.5.1 > > Change: The messageType attribute specifies the type of the variable > by referencing a message type definition using its QName. The type of > the variable (as specified by the messageType attribute) must be the > same as the type of the input message defined by operation referenced > by the operation attribute. The variable and messageType attributes > constitute the declaration of a variable of that name and type within > an implicit scope associated with the event handler. > > To: The messageType attribute specifies the type of the variable by > referencing a message type definition using its QName. The type of the > variable (as specified by the messageType attribute) must be the same > as the type of the input message defined by operation referenced by > the operation attribute. Optionally the messageType attribute may be > omitted and instead the element attribute substituted if the message > to be received has a single part and that part is defined with an > element type that matches the element type referenced by the element > attribute. The variable and messageType/element attribute constitute > the declaration of a variable of that name and type within an implicit > scope associated with the event handler. If an element attribute is > used then the binding of the incoming message to the variable declared > in the onEvent handler occurs as specified for the receive activity in > section 11.4. > > 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. > >
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]