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


-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]