- From: Arthur Ryman <ryman@ca.ibm.com>
- Date: Mon, 24 Jan 2005 15:28:01 -0500
- To: "Tony Fletcher" <tony_fletcher@btopenworld.com>
- Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
- Message-ID: <OFCE50E031.2B85B6B8-ON85256F93.006C712B-85256F93.00706C97@ca.ibm.com>
Tony,
The WSDL 2.0 WG discussed the message issue at length, and the conclusion
was that if we added support for constructs like "choice" then we would we
slowly but surely reproduce a lot of XSD. There were many requests for
more control over the parts of a message. The solution we adopted was to
discard the WSDL 1.1 <message> and <part> elements altogether and simply
use XSD Global Element Declarations (GEDs) directly.
The key point about this design is that the GED is viewed as an abstract
message definition. The concrete details come in at the binding level. The
binding rules are simple in the case where the concrete message is the
same as the abstract message, e.g. for SOAP, the simple case is to use the
GED as the <body> content of the SOAP <envelope>
In your case, the idea would be to define a GED, BorC, whose content model
was a choice of the two response messages:
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace=
"http://example.com/choicy" xmlns:tns="http://example.com/choicy">
<element name="B" type="string"></element>
<element name="C" type="string"></element>
<element name="BorC">
<complexType>
<choice>
<element ref="tns:B"></element>
<element ref="tns:C"></element>
</choice>
</complexType>
</element>
</schema>
The WSDL 2.0 interface (aka portType) is:
<interface name="Responder">
<operation name="abc">
<input message="tns:A"/>
<output message="tns:BorC"/>
<outfault name="fault" message="tns:F"/>
</operation>
</interface>
This introduces a top level wrapper element <BorC> that you probably don't
want in the concrete SOAP message. The solution is to modify the SOAP
binding rules, i.e. to copy the content of the GED into the <body> rather
than the entire GED including that unwanted root element.
FYI, we have had a related request to allow more flexibility in our SOAP
binding to permit muliptle children in the <body>. The binding rule: "copy
the element content into the <body>" would work for your case and the
multiple children case.
Does this binding approach satisfy your requirement?
Note that the fault issue is handled at the MEP level. We have several
predefined MEPs already that specify how and when fault elements occur.
See part 2. [1]
[1] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/
Arthur Ryman,
Rational Desktop Tools Development
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/
"Tony Fletcher" <tony_fletcher@btopenworld.com>
Sent by: www-ws-desc-request@w3.org
01/24/2005 01:30 PM
To
<www-ws-desc@w3.org>
cc
Subject
Choice of response message in WSDL
To the W3C Web Service Description Group,
[Please copy me directly on responses as while I am on the WS-Choreography
mailing lists I am not on the Web Service Description mailing lists -
Thank you.]
In the Last Call version of the WS-Choreography specification several
exchange elements are allowed in an interaction element. One is the
request going in one direction and the others must be in the reverse
direction. Only one of these is allowed to be the 'normal' response
message, all the others must be fault messages.
The case I am particularly interested in seems to be supported by neither
WS-Choreography at present nor WSDL 2.0 and I wonder if it should be. (I
understand that WSDL 2.0 could support what I propose as an extension,
though I make this comment to the WSD group with the aim of making it a
standardised feature.)
Suppose I have request - response protocol pair but there can be several
distinct response messages. So I want to say the request message is A and
the response is B or C (or possibly fault message X or Fault message Y).
I realise that of course you can write it as five (in this case) one way
interactions, but that looses the request response semantic. You could
also re-write the protocol to only use a single response message and
internally to the response message have different parameter values that
give the semantics of B or C - and likewise one can re-write the Fault
message to combine X and Y, but why should one have to change the protocol
to suit WSDL?
In WS-Choreography I would like to be able to write, for example,
something like:
<interaction name="ABCF" channelVariable="tns:aChannel" operation="a">
<participate relationshipType="SuperiorInferior"
fromRole="tns:Superior" toRole="Inferior"/>
<exchange name="A" informationType="Atype" action="request">
<send variable="tns:A"/>
<receive variable="tns:A"/>
</exchange>
<exchange name="B" informationType="BType" action="respond">
<send variable="tns:B"/>
<receive variable="tns:B"/>
</exchange>
<exchange name="C" informationType="CType" action="respond">
<send variable="tns:C"/>
<receive variable="tns:C"/>
</exchange>
<exchange name="F" informationType="FType" action="respond">
<send variable="tns:F" causeException="true"/>
<receive variable="tns:F" causeException="true"/>
</exchange>
</interaction>
and in the corresponding Web Service description I would like to be able
to write something like:
<portType name="Requester">
<operation name="abc">
<output message="tns:A"/>
<input message="tns:B"/>
<input message="tns:C"/>
<fault name="fault" message="tns:F"/>
</operation>
</portType>
<portType name="Responder">
<operation name="abc">
<input message="tns:A"/>
<output message="tns:B"/>
<output message="tns:C"/>
<fault name="fault" message="tns:F"/>
</operation>
</portType>
or with explicit choice construct:
<portType name="Requester">
<operation name="abc">
<output message="tns:A"/>
<choice>
<input message="tns:B"/>
<input message="tns:C"/>
</choice>
<fault name="fault" message="tns:F"/>
</operation>
</portType>
<portType name="Responder">
<operation name="abc">
<input message="tns:A"/>
<choice>
<output message="tns:B"/>
<output message="tns:C"/>
</choice>
<fault name="fault" message="tns:F"/>
</operation>
</portType>
I would be quite happy to have either some sort of explicit 'choice'
construct around the multiple responds that are regular permitted
responses and therefore do not have cause exception set, or an implicit
choice as we currently have for multiple exception causing responses.
Best Regards,
Tony
Tony Fletcher
Technical Advisor
Choreology Ltd.
68, Lombard Street, London EC3V 9L J UK
Phone:
+44 (0) 1473 729537
Mobile:
+44 (0) 7801 948219
Fax:
+44 (0) 870 7390077
Web:
www.choreology.com
Cohesions?
Business transaction management software for application coordination
Work: tony.fletcher@choreology.com
Home: amfletcher@iee.org
Attachments
- image/gif attachment: 01-part
Received on Monday, 24 January 2005 20:28:49 UTC