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?

> 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:16:30 UTC