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] inputVariable optional on Invoke


    When faced with the oddities of WSDL 1.1, I usually consult my copy 
of the WS-I Basic Profile. Even though it is SOAP-centric, it does have 
a lot to say about service declarations. The BP 1.0 doesn't recognize 
(and clarify) the contradiction you found (concerning the cardinality of 
message parts), but I find this:

 From section 5.3.1 (Bindings and Parts):

    Use of |wsdl:message| elements with zero parts is permitted in
    Document styles to permit operations that can send or receive
    messages with empty |soap:Body|s. Use of |wsdl:message| elements
    with zero parts is permitted in RPC styles to permit operations that
    have no (zero) parameters and/or a return value.

    I'd say we have the WS-I's blessing on leaving the inputVariable as 
optional. Other implementations of SOAP may have different 
interpretations, but allowing the inputVariable to be optional is the 
most general choice, and will cover such implementations as well.

-Ron

Yaron Y. Goland wrote:

> Executive Summary: Antony Miguel, in a private e-mail, pointed out 
> that the inputVariable attribute on invoke is currently optional. In 
> BPEL as it now is specified this doesn't make sense as all operations 
> MUST have a WSDL message associated with them. But if issue 12 passes 
> then the optional inputVariable makes sense in cases where the message 
> has no parts. Unfortunately the WSDL 1.1 spec seems to contradict 
> itself on the legality of partless messages.
>
> Long Winded Version:
>
> Antony Miguel, in a private e-mail with me, pointed out that the 
> inputVariable attribute is optional on invokes. Given that all invoke 
> MEPs MUST have an outgoing message does it make sense to have the 
> attribute be optional?
>
> The only scenario I can come up with where it makes sense to not have 
> an inputVariable attribute is if the outgoing message is 'empty'. This 
> is not a completely insane idea. Some protocols do have 'empty' 
> messages which have an address header but no body. This could be used 
> for things like pings.
>
> But all BPEL messages have to be sent using a WSDL message structure 
> and it isn't possible to define an operation that doesn't point at a 
> message. However it MAY be legal to define a WSDL message with no 
> parts. There is a contradiction between the text in WSDL 1.1 and the 
> schema. The text in section 2.3 says "Messages consist of one or more 
> logical parts.". But the psuedo-schema in 2.3 says:
>
> <definitions .... >
>     <message name="nmtoken"> *
>         <part name="nmtoken" element="qname"? type="qname"?/> *
>     </message>
> </definitions>
>
> Furthermore the XML Schema in the appendix says:
>
>    <complexType name="messageType">
>       <complexContent>
>          <extension base="wsdl:documented">
>             <sequence>
>                <element ref="wsdl:part" minOccurs="0"
>                         maxOccurs="unbounded"/>
>             </sequence>
>             <attribute name="name" type="NCName" use="required"/>
>          </extension>
>       </complexContent>
>    </complexType>
>
> Assuming the schema triumphs then this means that it is legal to 
> define a message with no parts. An empty message.
>
> But this still leaves the problem that BPEL requires that all messages 
> be contained in a WSDL container. This alone would require that invoke 
> MUST always have an inputVariable attribute.
>
> But, if issue 12 passes, then it would make sense to make 
> inputVariable optional to cover the case where the message for an 
> operation has no parts.
>
> 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]