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.
To unsubscribe from this mailing list (and
be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
|