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


Well, we disagree. I don't think it matters that WSDL 2.0 does not use 
message construct any more since WSDL 2.0 is not in scope currently 
(plus it is a moving target). Additionally WSDL 2.0 replaces messages 
with GEDs which can be empty as well. This is analogous to the use of 
void type in programming languages which is pretty useful.

Regards, Prasad

Ugo Corda wrote:

> Prasad,
> I don't think that BPEL should necessarily follow the WSDL 1.1 rule 
> and require the presence of even empty messages, particularly given 
> the fact that there are no messages to speak of in WSDL 2.0.
>  
> Ugo
>  
>  
> -----Original Message-----
> From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
> Sent: Friday, July 16, 2004 4:26 PM
> To: Ugo Corda
> Cc: Ron Ten-Hove; ygoland@bea.com; wsbpeltc
> Subject: Re: [wsbpel] inputVariable optional on Invoke
>
>     Ugo,
>
>     I was pointing out that R2202 only permits 'zero parts in the
>     wsdl:message'. It does not permit not supplying a wsdl:message as
>     input or output of an operation. When there is a void() input or
>     output on an operation, one still needs to model the operation
>     with a wsdl:message that has no parts. Hence the point is that
>     R2202 can not be used to infer that the wsdl:message and hence
>     deduce that the inputVariable to invoke (or receive or reply etc.
>     for that matter) can be optional. I think we still need to supply
>     the a wsdl:message with no parts, unless we add explicit text to
>     clarify that aspect. My preference would be to require the input
>     variable always, so that WSDL and BPEL stay consistent (while
>     being conformant with WS-I BP).
>
>     Regards, Prasad
>
>     -------- Original Message --------
>     Subject: 	RE: [wsbpel] inputVariable optional on Invoke
>     Date: 	Fri, 16 Jul 2004 13:33:48 -0700
>     From: 	Ugo Corda <UCorda@SeeBeyond.com>
>     To: 	Prasad Yendluri <pyendluri@webmethods.com>, Ron Ten-Hove
>     <Ronald.Ten-Hove@Sun.COM>
>     CC: 	<ygoland@bea.com>, "wsbpeltc" <wsbpel@lists.oasis-open.org>
>
>
>
>     Prasad,
>     An absent inputVariable does not necessarily imply that there
>     should be no envelope. It could just mean that the inputVariable,
>     if present, would not bring any useful information that would have
>     any visible effect on the message being sent out (which, I think,
>     is the case when the inputVariable points to a message with zero
>     parts).
>      
>     Ugo 
>
>         -----Original Message-----
>         From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
>         Sent: Friday, July 16, 2004 12:22 PM
>         To: Ron Ten-Hove
>         Cc: ygoland@bea.com; wsbpeltc
>         Subject: Re: [wsbpel] inputVariable optional on Invoke
>
>         Ron,
>
>         This is only permits zero parts in the wsdl:message or the
>         soap:body (binding level) being empty. This does not say the
>         wsdl:message or the soap:envelope itself can be totally
>         absent. Hence we can not interpret that to imply the
>         inputVariable can be absent. It can be empty or void of 
>         payload (body) content and with WSDL 1.1 headers can be
>         present in the soap:envelope coming from other wsdl:messages  etc.
>
>         Regards, Prasad
>
>         Ron Ten-Hove wrote:
>
>>             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:Bodys. 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. 
>>
>


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