[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] inputVariable optional on Invoke
-1 i understand the tradeoff here between consistency with WSDL and cluttering up the BPEL file with useless stuff. however, i'm on the other side of the argument from you. 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:26 PM 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]