Use case 3

* 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>

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

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Wednesday, 16 February 2005 04:07:26 UTC