[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] inputVariable optional on Invoke
Exactly, this is syntactic sugar, I'm glad we are all in agreement. Alas, this leaves me to file another issue. :( Yaron Prasad Yendluri wrote: > > > Yaron, > > Yaron Y. Goland wrote: > > > Prasad, what I don't understand from your mails is where you see us > > trying to make the WSDL message object itself optional? > > Given we have no control over WSDL (1.1 anyway), no I was not thinking > we are trying to make the WSDL message object itself optional. I was > taking that as a given. My remark essentially was that WSDL even with > the WS-I refinement R2202 still requires a message object (as input to > an operation) even if it has no parts and we cannot deduce from that > WS-I was suggesting that higher abstractions that use such operations > are free not to show the inputs of operations that have WSDL messages > with no parts. > > > In a world without issue 12 I believe that inputVariable is always > > mandatory and we should change the text. > > > > In a world with issue 12 it would seem natural to extend issue 12 to > > specify that if a WSDL message has no parts then one doesn't have to > > specify an inputVariable on invokes because it is possible to fully > > derive the expected WSDL message object definition directly from the > > operation's associated WSDL. > > I would prefer to distinguish between null input and no input. No > inputVariable implies to me there is no input and not null input > (payload/soap:body). This could be important especially given a SOAP > message (for soap bindings) would actually go across to the invoking > portType (port) and operation as input and might in fact carry other > parts in the soap:message (defined at the binding level for that port > and operation) including any contextual (resource properties) layered > protocol (reliability, security sorta) data. I am concerned that people > could interpret no inputVariable to mean just that "no input" where as > it is actually null input (or payload). It is perhaps ok in the case of > "invoke". So, at the heart I see this as syntactic sugar, so I am ok. > People can still show the inputVariable if they like. > > Thanks, Prasad > > > In all cases the WSDL message object is fully and correctly defined. > > > > Thanks, > > > > Yaron > > Prasad Yendluri wrote: > > >> 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 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> > <mailto:UCorda@SeeBeyond.com> > >> To: Prasad Yendluri <pyendluri@webmethods.com> > >> <mailto:pyendluri@webmethods.com>, Ron Ten-Hove > >> <Ronald.Ten-Hove@Sun.COM> <mailto:Ronald.Ten-Hove@Sun.COM> > >> CC: <ygoland@bea.com> <mailto:ygoland@bea.com>, "wsbpeltc" > >> <wsbpel@lists.oasis-open.org> <mailto: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 <mailto: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: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. > >>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]