- From: David Hull <dmh@tibco.com>
- Date: Tue, 22 Feb 2005 14:46:33 -0500
- Cc: public-ws-async-tf@w3.org
Short reply inline below. Anish Karmarkar wrote: > David Hull wrote: > >> Anish Karmarkar wrote: >> >>> Hi David, >>> >>> I have not looked at the pull notification discussion in WS-N. Will >>> do so, thx for the pointer. >>> >>> But, I am a little confused by the use of the term 'callback', which >>> to me implies a 'push' style, whereas this usecase embodies a 'pull' >>> style. >>> Perhaps I misunderstood what you were trying to say (very likely >>> since I haven't read the discussion in WS-N). >> >> >> >> Sorry. S/callback/notification/. In other words, this situation >> looks a lot like pull notification, except that we expect exactly one >> "notification" message (the reply) instead of zero or more in the >> normal case of notification. >> > > Isn't that also the difference between "normal" notification and > callback? One has zero or more messages sent whereas the other > involves only one message (unless there is a failure). > > IMHO: The important thing here is that asynch req-response (callback > and poll style) are very simple and important usecases for which one > should not have to require a complete notification infrastructure > (which involves subscription mgmt) or BPEL. > > Of course if there is commonality which can be leveraged/reused > without requiring the complete infrastructure of BPEL/notification, it > would make sense to do so. I completely agree. My take is that callbacks are more fundamental than subscription. > >> Does that help? >> > > Yes it does. Thx. > >>> >>> -Anish >>> -- >>> >>> David Hull wrote: >>> >>>> It occurs to me that this is very much like the scenario for "pull" >>>> notification currently being discussed in WSN. The only >>>> differences I see are that we expect exactly one callback (as >>>> opposed to zero or more), and the callback message will be >>>> referenced to a single reply message. I'm not sure exactly what >>>> commonality is to be captured here, but I'm pretty sure there is >>>> some. At the very least, any mechanism for pull notification can >>>> handle this case. It may well be overkill, but it will work. >>>> There may also be simpler mechanisms that work for this case that >>>> aren't suitable for pull notification. >>>> >>>> Anish Karmarkar wrote: >>>> >>>>> >>>>> Usecase 4: Asynch req-res -- polling style >>>>> --------------------------------------- >>>>> >>>>> 1. Description of the scenario >>>>> >>>>> This usecase consists of two app-level/soap-level messages: m1 and >>>>> m2. >>>>> Message m1 is sent by node A to node B over transport t1. Message >>>>> m2 is sent by >>>>> node B back to node A over transport t2. Transport t1 and t2 may >>>>> be of the same >>>>> type/protocol. Both messages m1 and m2 are initiated by node A >>>>> using the >>>>> underlying transport t1 and t2. Node A polls for message m2 from >>>>> node B. If m2 >>>>> is ready then node B sends m2 to node A upon a "query" by node A. >>>>> If m2 is not >>>>> ready then node B informs node A that the message is not ready. >>>>> >>>>> ------ m1 ------ >>>>> node A -----> node B >>>>> ------ ------ >>>>> m11 >>>>> t1 -----> t1 >>>>> <----- >>>>> ------ m12 ------ >>>>> >>>>> m11: transport level request/connection initiation from node A to >>>>> node B. This >>>>> message carries m1 as the payload >>>>> m12: transport level response from node B to node A with location >>>>> of the soap >>>>> level response to poll for. There is no payload. >>>>> [note there may be more than two transport-level messages, the >>>>> figure above >>>>> uses the simplest case] >>>>> >>>>> >>>>> ------ m2 ------ >>>>> node A <----- node B >>>>> ------ ------ >>>>> m21 >>>>> t2 -----> t2 >>>>> <----- >>>>> ------ m22 ------ >>>>> >>>>> m21: transport level request/query/connection initiation from node >>>>> A to node B. >>>>> This message does not carry any payload. >>>>> m22: transport level response back to node A from node B which >>>>> either says >>>>> "try-again" with no payload or carries m2 as the payload. If >>>>> it says >>>>> "try-again" then node A may keep polling for m2. >>>>> [note there may be more than two transport-level messages, the >>>>> figure above >>>>> uses the simplest case] >>>>> >>>>> For this usecase both t1 and t2 are assumed to be synchronous >>>>> transports >>>>> (like HTTP). I suppose it would be possible to use asynch >>>>> transport to >>>>> implement this usecase, but I'm assuming that the lower water-mark >>>>> for >>>>> declaring success in this case would be if we enable this using >>>>> SOAP over HTTP. >>>>> >>>>> >>>>> 2. Can we achieve this case now with the current specs? With how >>>>> much >>>>> "squinting"? >>>>> >>>>> a) For SOAP 1.1 over HTTP >>>>> No we cannot achieve this using the current specs. >>>>> >>>>> b) For SOAP 1.2 over HTTP >>>>> Yes it is possible to do this using existing specs. >>>>> There is minimal squinting required to do this (details below). >>>>> >>>>> c) For WSDL 1.1 >>>>> No we cannot achieve this using the current specs. >>>>> >>>>> d) For WSDL 2.0 >>>>> >>>>> Yes it is possible to do this in existing spec with a minor tweak. >>>>> >>>>> 3. What is the minimal change that would be necessary to what >>>>> spec(s) in >>>>> order to achieve this case? >>>>> >>>>> a) For SOAP 1.1 over HTTP >>>>> Message m1 can be sent using SOAP1.1/HTTP binding using the >>>>> clarification made >>>>> by WS-I Basic Profile 1.0/1.1 -- but this will require additional >>>>> clarification >>>>> along the lines suggested by Marc (see thread starting at [1]). >>>>> Message m2 cannot be sent using SOAP1.1/HTTP binding currently >>>>> used as it does >>>>> not allow a SOAP message to be received in HTTP response without a >>>>> SOAP message >>>>> in the HTTP request. The SOAP 1.1/HTTP binding will have to be >>>>> modified to >>>>> achieve this. >>>>> >>>>> b) For SOAP 1.2 over HTTP >>>>> See the thread starting at [1]. >>>>> i) Specify somewhere how this is done (as outlined in [1]) >>>>> ii) Clarify ambiguity wrt to the next state of a HTTP requestor >>>>> when a 3XX >>>>> status code is received in the case of SOAP1.2/HTTP binding. This >>>>> could perhaps >>>>> be done as SOAP 1.2 errata. >>>>> >>>>> c) For WSDL 1.1 >>>>> One clarification (very little squinting) and one invention is >>>>> needed: >>>>> i) clarification - how 303 status code is handled along with >>>>> Location/Retry-After HTTP headers >>>>> ii) Invention/modification - modify the exiting binding or invent >>>>> a new >>>>> extensibility element that says that something like SOAP 1.2 >>>>> Response MEP is >>>>> used in conjunction with SOAP one-way. >>>>> >>>>> In addition if there is a requirement to allow for t1 != t2 then >>>>> this will >>>>> require an additional invention, as the transport that is >>>>> specified on >>>>> soap:binding element applies to both the input and output message. >>>>> >>>>> d) For WSDL 2.0 >>>>> This will have to be expressed as a single WSDL operation which >>>>> implements two >>>>> SOAP MEPs. Currently WSDL 2.0 does not allow this for wsoap:mep >>>>> attribute on >>>>> the wsdl20:operation element. Either the value of wsoap:mep should >>>>> be changed >>>>> to type 'list of URIs' or allow wsoap:mep per message (message) in >>>>> the binding. >>>>> I prefer the 1st solution. >>>>> >>>>> 4. What would be the "ideal" solution if we could change anything >>>>> to get >>>>> this case covered? >>>>> >>>>> a) For SOAP 1.1 over HTTP >>>>> i) Clarify/specify that SOAP 1.1/HTTP binding can be used to support >>>>> SOAP-response MEP (along the lines of SOAP 1.2) and how this is >>>>> done (backport >>>>> SOAP 1.2 SOAP-response MEP to SOAP 1.1) >>>>> ii) rules around status code 303 and Location/Retry-After HTTP >>>>> headers (work >>>>> common to SOAP 1.2 and SOAP 1.1) >>>>> >>>>> b) For SOAP 1.2 over HTTP >>>>> Ideal solution is to make the clarification(s) in 3.b as SOAP 1.2 >>>>> errata. >>>>> The next best solution is to make the clarification(s) in 3.b in the >>>>> SOAP1.2/HTTP binding in WSDL. >>>>> >>>>> c) For WSDL 1.1 >>>>> see 3.c above >>>>> >>>>> d) For WSDL 2.0 >>>>> see 3.d above >>>>> >>>>> >>>>> -Anish >>>>> -- >>>>> >>>>> [1] >>>>> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0005.html >>>>> >>>>> >>>> >>
Received on Tuesday, 22 February 2005 19:47:06 UTC