- From: Tony Fletcher <tony_fletcher@btopenworld.com>
- Date: Mon, 24 Jan 2005 18:30:20 -0000
- To: <www-ws-desc@w3.org>
- Message-ID: <000f01c50242$c55bc4f0$6501a8c0@corp.choreology.com>
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 <http://www.choreology.com/> 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: <http://www.choreology.com/> www.choreology.com CohesionsT Business transaction management software for application coordination Work: tony.fletcher@choreology.com Home: amfletcher@iee.org
Attachments
- image/gif attachment: image002.gif
Received on Monday, 24 January 2005 18:31:04 UTC