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