RE: Use case 3

Kevin,
I would hate giving up on the second formulation. If we do that, it will
be impossible to postpone to deployment time or run time the decision of
whether the interaction is synchronous or asynchronous.

Ugo

> -----Original Message-----
> From: public-ws-async-tf-request@w3.org 
> [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Liu, Kevin
> Sent: Wednesday, February 16, 2005 9:37 AM
> To: Roberto Chinnici; public-ws-async-tf@w3.org
> Subject: 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 18:44:24 UTC