- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 16 Feb 2005 11:38:52 -0800
- To: David Hull <dmh@tibco.com>
- CC: public-ws-async-tf@w3.org
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). -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 Wednesday, 16 February 2005 19:48:00 UTC