[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] inputVariable optional on Invoke
while void types in interfaces are useful, variables of void type are not. i believe that's exactly what's happening here - WSDL declares a void 'parameter'. BPEL should not declare a void variable to send to the interface so the types can match up. danny ----- Original Message ----- From: "Prasad Yendluri" <pyendluri@webmethods.com> To: "Ugo Corda" <UCorda@SeeBeyond.com> Cc: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>; <ygoland@bea.com>; "wsbpeltc" <wsbpel@lists.oasis-open.org> Sent: Friday, July 16, 2004 4:54 PM 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]