- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Mon, 26 Mar 2001 17:47:53 +0100
- To: "'Krishna Sankar'" <ksankar@cisco.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, "Henrik Frystyk Nielsen (E-mail)" <frystyk@microsoft.com>, "Jean-Jacques Moreau (E-mail)" <moreau@crf.canon.fr>, "John Ibbotson (E-mail)" <john_ibbotson@uk.ibm.com>, "Lynne Thompson (E-mail)" <Lynne.Thompson@unisys.com>, "Marc Hadley (E-mail)" <marc.hadley@uk.sun.com>, "Mark A. Jones (E-mail)" <jones@research.att.com>, "Martin Gudgin (E-mail)" <marting@develop.com>, "Nick Smilonich (E-mail)" <nick.smilonich@unisys.com>, "Oisin Hurley (E-mail)" <ohurley@iona.com>, "Scott Isaacson (E-mail)" <SISAACSON@novell.com>, "Yves Lafon (E-mail)" <ylafon@w3.org>
- Cc: xml-dist-app@w3.org
Hi Krishna, > -----Original Message----- > From: Krishna Sankar [mailto:ksankar@cisco.com] > Sent: 26 March 2001 17:29 > Cc: xml-dist-app@w3.org > Subject: RE: Draft Alternate Section 3. > > > Stuart, > > As always, it is a pleasure discussing XML with you ! > > Couple of points : > > 1. Message Sequence : > > Your discussion brings up a good point Chaining of XMLP messages (within > one Correlation.MessageRef). I agree that this goes beyond the SOAP/HTTP, > but we should be looking at the future and secondly we might be using > XMLP/SOAP/RMI or XMLP/SOAP/JINI or XMLP/SOAP/eSpeak or (of course) > XMLP/SOAP/COM for all we care ! Sure... no argument, just a concern that it might need more careful thought than I have given it so far. > > I was thinking of the web services space and using XMLP as the basic > protocol for web services. > > 2. I still have the question on [Faults]/ .status. If the status is > .failure, how do I know what happened ? Remember, there is no [correlation] > and so the app cannot ask for more details. May be the app would want to > make decisions on the fault code or some similar information. Ok... so this is different. From the senders point of view the lifetime of the operation is from the .send to the .status. These are implicitly correlated. I could at a non-optional Correlate to the .status just to emphasis this with a local abstract reference to the message that was sent. If the status is failure, you may not know what has happened. To be useful failure should only be reported when the message definitely wasn't delivered. It may not be possible to know how far down an intermediary chain it got before failing. However, a subsequent fault-bearing message from, say, the intermediary where failure occured *may* cast more light on the problem - or may itself be lost! > > 3. I am actually thinking of prototyping this model as an exercise and > hence the detailed questions and concerns. Sounds good... let me know how you get on. > > cheers > Regards Stuart
Received on Monday, 26 March 2001 11:49:18 UTC