RE: Use case 3

Hi Reberto,

Thanks for the nice write up of this use case.

Overall, I think we should focusing on the first formulation- using
multiple interface to support this use case. I agree with you that for
this case to work, we need a SOAP one-way MEP (or HTTP one way binding).


As for the correlation piece, I don't think we need to go there in the
WSDL level. 

First of all, I don't see how such mechanism really add value. If we
want to address the *descriptive* conversational aspect, you need to
employee UML or some process language to model your whole application
logic. Just model a single interaction doesn't really help application
development. Takes the WS-I Sample application as an example, I don't
see they need such extensions in their wsdl for their callback
situation.  Note they are using sequence diagrams to model the
processes (or you can call it composition of services). *IF* they decide
to describe the process in some xml language, the callback extension
doesn't help them much, they have to go for something like BPEL. 

Secondly, such extension may limit the use of an operation to one
particular application scenario. As defined in the wsdl for
expenseReportingService, to me the submitExpenseReport operation only
have to say it takes in an expense report, period. Further conversation
depends on applications. For example, One application may require that
it calls back with a approval/denial decision, another application may
requires that it calls back with bank depositing info, yet another
application may requires a call back with approval, then another call
back with banking info, so on and so on. I agree that adding some call
back extension describes one use of the operation, but don't you think
it actually limited its potential use for other cases?  The point is
that if you add callback descriptions, it's not a simple wsdl anymore,
it's a process definition, though a simple and common process. They are
two different things, and the later should not be in the scope of the
WSDL group. 


Now the second formulation, I think we have seen its complexity by now.
It requires too deep changes to WSDL and I hesitate to go there in such
a late stage. Anyway, the use case itself falls in the 20 side of a
80/20 cases. WSDL should be fine if it has one way to support that.
Spending tremendous resource to tackle the binding to support such use
case is not a right thing for a working group that is already way behind
its charted schedule. 


Best Regards,
Kevin
 

>-----Original Message-----
>From: public-ws-async-tf-request@w3.org 
>[mailto:public-ws-async-tf-request@w3.org] 
>Sent: Tuesday, Feb 15, 2005 01:53 PM
>To: public-ws-async-tf@w3.org
>Subject: 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 17:38:07 UTC