RE: Use case 3

>-----Original Message-----
>From: public-ws-async-tf-request@w3.org 
>[mailto:public-ws-async-tf-request@w3.org] 
>Sent: Wednesday, Feb 16, 2005 0:11 AM
>To: Roberto Chinnici
>Cc: public-ws-async-tf@w3.org
>Subject: Re: Use case 3
>
>
>Roberto Chinnici wrote:
>> 
>> * Description of the scenario
>> 
>> In this use case, a client contacts a server using transport T1. The
>> response is sent back asynchronously using a callback made over a
>> potentially different transport T2. Even if the transports 
>are the same, 
>> the request and response messages could use different connections,
>> making this case different from #6.
>> 
>> As a working example, let's use Kevin's 
>"submitExpenseReport" operation
>> (see [1]). Its request and response messages are defined as follows:
>> (I made a few edits to make the naming more consistent)
>> 
>>     <xs:schema ...>
>> 
>>        <xs:element name="submitExpenseRequest" >
>>             <xs:complexType ...> ...    </xs:complexType>
>>       </xs:element>
>> 
>>       <xs:element name = "submitExpenseResponse">
>>           <xs:complexType>
>>                 <xs:choice>
>>                         <xs:element ref = 
>"tns:ApprovalConfirmation"/>
>>                             <!-- an immediate approval message for
>>                                  amount under $100 -->
>>                         <xs:element ref = "tns:ManagerDecision"/>
>>                             <!-- manager decision is 
>required for amount
>>                                  above $100 -->
>>             <xs:choice>
>>           </xs:complexType>
>>        </xs:element>
>>             ...
>>     </xs:schema>
>> 
>> This example highlights some variations on this use case:
>> 
>>   3a. The response always uses transport T2.
>>   3b. The response uses sometimes T2a, sometimes T2b. Both are
>>       statically described.
>>   3c. The response may use any transport T2, independently from
>>       what the service description says.
>> 
>> In Kevin's description of the sample service, the response would be
>> sent over HTTP when it's immediately available 
>("ApprovalConfirmation"
>> case) and over SMTP when it's not ("ManagerDecision"), thus providing
>> an example of (3b).
>> 
>> * Can we achieve this case now with the current specs?  With how much
>> "squinting"?
>> 
>> Almost. At the price of giving up on the idea of having a single
>> sumitExpenseReport operation. One can define two interfaces, each
>> carrying half of the whole interaction modelled as an 
>in-only operation.
>> E.g.
>> 
>>   <interface  name = "expenseReportingService" >
>>     <operation name="submitExpenseReport"
>>             pattern="http://www.w3.org/2004/03/WSDL/in-only" >
>>         <input messageLabel="In"
>>               element="tns:expenseRequest" />
>>     </operation>
>>   </interface>
>> 
>>   <interface  name = "expenseReportingCallback" >
>>     <operation name="submitExpenseReportCallback"
>>             pattern="http://www.w3.org/2004/03/WSDL/in-only" >
>>         <input messageLabel="In"
>>               element="tns:expenseResponse" />
>>     </operation>
>>   </interface>
>> 
>
>I interpreted this to mean that usecase 3 (as expressed above) is 
>reduced to usecase 5 (correlated 2 one-way messages). Is that correct 
>interpretation?
>

I believe it is. I am actually surprised by this formulation. I was
hoping that we would explore how easy/how hard to retain a single
operation defn in an interface for which we may be able to define
different granularity in the binding WITHOUT sacrificing a single
operation. Since a binding applies to all the messages in an operation,
the approach requires changing WSDL substantially. Before we give up on
use case (and abondoning a single operation), personally it would be
nice to know what the consequences are going down that path... Kevin
actually illustrated the complexities quite a bit. 

Otherwise, use case 5 is the same as 3 for which I just supplied a very
similar solution. 

>> Separate bindings are then defined for each interface 
>(potentially even
>> multiple ones for the callback over different transports 
>T2a, T2b, ...).
>> On the wire, the request message would use a wsa:ReplyTo header
>> (assuming a SOAP binding, otherwise the realization of a [reply
>> endpoint] message addressing property) to indicate where to send the
>> response.
>> 
>> One missing piece at the moment is some correlation at the 
>description
>> level between the two interfaces/operations. The WS-MessageDelivery
>> specification [2] defined one such mechanism in the form of the
>> wsmd:ResponseOperation WSDL extension element:
>> 
>>     <wsmd:ResponseOperation
>>         wsmd:interface="xs:QName"
>>         wsmd:operation="xs:NCName"
>>         wsmd:binding="xs:QName"?/>
>> 
>> (Greg's presentation in [3] defined a "respLink" attribute 
>for the same
>> purpose, but it didn't provide a specification for it.)
>> 
>> There's also one additional well-known missing piece, i.e. a SOAP 1.2
>> one-way MEP.
>> 
>> Assuming instead that one insists on modeling the interaction in WSDL
>> using a single in-out operation, e.g.
>> 
>>   <interface  name = "expenseReportingService2" >
>>     <operation name="submitExpenseReport"
>>             pattern="http://www.w3.org/2004/03/WSDL/in-out" >
>>         <input messageLabel="In"
>>               element="tns:expenseRequest" />
>>         <output messageLabel="Out"
>>               element="tns:expenseResponse" />
>>     </operation>
>>   </interface>
>> 
>> then it's presently impossible to do this with standard specs only.
>> 
>> As Kevin pointed out in [1], a WSDL binding must bind all operations
>> and all messages within an operation the same way. All the predefined
>> bindings use the same transport for input, output and fault messages,
>> so it's game over.
>> 
>> * What is the minimal change that would be necessary to what 
>spec(s) in
>> order to achieve this case?
>> 
>> In this case, "minimal" is in the eye of the beholder.
>> 
>> For the first formulation 
>> (expenseReportingService/expenseReportingServiceCallback),
>> defining a WSDL extension akin to wsmd:ResponseOperation and 
>a SOAP 1.2
>> one-way MEP would be sufficient.
>> 
>> For the second formulation (expenseReportingService2), given a
>> combination of transports {T1,T2,T2a,T2b,...}, say {T1=SOAP/HTTP,
>> T2=SOAP/SMTP}, we could define a WSDL 2.0 binding for it. Obviously
>> this would result in a combinatorial explosion. Note e.g. that
>> scenarios 3a, 3b and 3c would all use different bindings.
>> 
>> There is also an additional problem mentioned by Kevin, i.e. that
>> presently in WSDL 2.0 all operations in an interface must be 
>bound the
>> same way, so all these newly defined bindings would 
>presumably have to
>> allow binding different operations in slightly different ways.
>> E.g, operation1 might be request->SOAP/HTTP, 
>response->SOAP/SMTP while
>> operation2 is request,response->SOAP/HTTP (synchronous).
>> 
>> In other words, the plain SOAP/HTTP binding would have to be a
>> sub-binding of the SOAP/(HTTP|SMTP) ueber-binding (words 
>fail me at this
>> stage...). If we don't do that, then it becomes impossible 
>to mix plain
>> in-out operations that use synchronous SOAP/HTTP operations with the
>> "enhanced" ones that take advantage of WSA.
>> 
>> For a different solution, requiring deeper changes to WSDL, see next
>> point.
>> 
>> * What would be the "ideal" solution if we could change 
>anything to get
>> this case covered?
>> 
>> Sorry to repeat myself, but in this case, "ideal" too is in 
>the eye of
>> the beholder.  ;-)
>> 
>> Something along the lines of option 4 in Kevin's email [1] (see also
>> Glen's email [4]) would do the trick. In WSDL 2.0, we'd 
>allow the choice
>> of a binding on a per-message basis (including faults, of course).
>> Furthermore, to cover 3b, we'd have to allow many alternate 
>bindings to
>> be specified for a single message.
>> 
>> Given the overall complexity, I'm not sure this solution qualifies as
>> "ideal", except that it appears to make pretty much any use case
>> describable.
>> 
>> As outlined in [4], it's also possible to keep the single binding
>> requirement and make sure that the SOAP binding supports different
>> (and multiple!) transports for each message in the MEP. Or 
>we could be
>> even less general and just allow this for a common MEP such 
>as in-out.
>> All these variants are pretty much restrictions of the 
>general solution
>> outlined above.
>> 
>> Finally, let's take the perspective embodied in the first formulation
>> (expenseReportingService/expenseReportingServiceCallback) 
>and look for
>> an ideal solution in that context. We could generalize the
>> wsmd:ResponseOperation and provide a mechanism to say "the in-only
>> operation O plays the role of the message whose label is L 
>in the WSDL
>> MEP M in a "virtual operation" identified by I". Tools, or a
>> choreography language, could make a bunch of in-only operations
>> annotated with such an extension appear for all practical purposes
>> as a single operation that uses MEP M.
>> 
>> [1] 
>> 
>http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/
>0022.html
>> [2] 
>http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/
>> [3] 
>> 
>http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jan/
>0004.html
>> [4] 
>> 
>http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/
>0028.html
>> 
>> Roberto
>> 
>
>

Received on Wednesday, 16 February 2005 08:32:43 UTC