- From: Rand Anderson <randerson@macgregor.ws>
- Date: Mon, 10 Feb 2003 12:02:12 -0500
- To: "'Don Box'" <dbox@microsoft.com>
- Cc: xml-dist-app@w3.org
Excellent! I agree, the scenario in the original question was fairly simple, all this is probably overkill. I was just thinking of the original post as a 'hello world' example of a more general question, projecting my own interest (I now see) onto the discussion of approaches. Since we're there now, one more question/comment on this, following your last comment: > The interesting question (to me at least) is whether or not B is an intermediary or an ultimate receiver. > In my mind, B is an ultimate receiver, however, strictly speaking, one could model this such that B was an > intermediary between A and C (albeit an "active" intermediary). I hadn't thought about it much, now I'm interested as well - your focus on and use of the term 'ultimate receiver' has me questioning my assumptions about how to think about this. Who/what determines whether a node is an 'ultimate receiver' or some kind of 'intermediary'? Is it more the node itself, in declaring its services and role? I guess if the node doesn't support routing, then that would be equivalent to saying "I'm just an ultimate receiver". Or is it the consumer, based on context of use? I've been assuming the latter, and that by supporting routing, even if you think of yourself initially as an 'ultimate receiver', you then better support modularity, and position for emergence, serendipity, re-use, and other good and interesting things. I should go re-read and study what the spec suggests, I guess, at least to start, to see if there is any thinking on this there. Thanks, Rand -----Original Message----- From: Don Box [mailto:dbox@microsoft.com] Sent: Monday, February 10, 2003 11:23 AM To: Rand Anderson Cc: xml-dist-app@w3.org Subject: RE: concatenating web services > -----Original Message----- > From: Rand Anderson [mailto:randerson@macgregor.ws] > Sent: Monday, February 10, 2003 8:03 AM > To: Don Box > Cc: xml-dist-app@w3.org > > Hi Don, > Thanks for commenting on this. > > I do understand that the purpose of WS-Routing is for defining a routing > mechanism ;). > > My question, or I guess it was more than a question, it was a suggestion, > was that the intermediaries can do more than blindly pass the message on. > That certainly has value by itself (e.g., for mixing transports along the > way), but allowing the intermediaries to do something 'interesting' to the > message contents along the way holds the power of enabling a decentralized > form of simple orchestration, a pipelining. And it parallels many real- > world > semantics of process flow. > > Of course, I was just exploring what seemed to be some interesting ground > here...Are you saying that WS-Routing should not be used for this (i.e., > counts as 'twisted' ;)? Not at all. Let's dissect the original scenario. In that scenario, the desire was for the message exchange to look like this: 1) A sends a request message to B (ws1) looking for the average temperature 2) B sends a message to C (ws2) containing the list of temperatures 3) C sends a response message to A containing the average. This is totally kosher in SOAP, but you would do need to deviate from the traditional HTTP request/response MEP. Here's a very direct way to get there: <!-- message 1 (A->B) --> <soap:Envelope> <soap:Body> <xx:CalculateAverageTemperature> <respondTo>...address of A...</respondTo> </xx:CalculateAverageTemperature> </soap:Body> </soap:Envelope> <!-- message 2 (B->C) --> <soap:Envelope> <soap:Body> <xx:CalculateAverageOfList> <respondTo>...address of A...</respondTo> <sample>67</sample> <sample>66</sample> <sample>82</sample> </xx:CalculateAverageOfList> </soap:Body> </soap:Envelope> <!-- message 3 (C->A) --> <soap:Envelope> <soap:Body> <xx:Average>215</xx:Average> </soap:Body> </soap:Envelope> Something like WS-Routing can make this somewhat simpler by normalizing the common properties of the message (e.g., to, respondTo, msgid, ...) into a common SOAP header block. However, you don't need anything as formal to get the job done. > If so, do you have something fundamental against the concept of pipelining > services? Or is it that you believe some additional protocol is needed > (not counting authorization or mustUnderstand issues)? I'm not against it at all. The interesting question (to me at least) is whether or not B is an intermediary or an ultimate receiver. In my mind, B is an ultimate receiver, however, strictly speaking, one could model this such that B was an intermediary between A and C (albeit an "active" intermediary). DB > Thanks, > Rand > > -----Original Message----- > From: Don Box [mailto:dbox@microsoft.com] > Sent: Monday, February 10, 2003 9:51 AM > To: Anne Thomas Manes; Rand Anderson; xml-dist-app@w3.org > Subject: RE: concatenating web services > > > > -----Original Message----- > > From: Anne Thomas Manes [mailto:anne@manes.net] > > Sent: Thursday, January 16, 2003 1:36 PM > > To: Rand Anderson; xml-dist-app@w3.org > > > > I don't think that web service concatenation is an intended > application > > for > > WS-Routing. WS-Routing defines a mechanism to route a message through > a > > series of SOAP intermediaries on its way to the ultimate receiver. The > > original question involved concatenating two ultimate receivers. > > Your analysis of WS-Routing is spot on. That stated, I've seen people use > WS-Routing (or home-grown variations) to do some pretty twisted things. > SOAP > is pretty vague about what a SOAP intermediary can do to a message before > relaying it to the next SOAP node. > > One feature of WS-Routing that would be useful in this scenario is the > ability to do transport-independent async messaging. If one crafted the > message schemas correctly, getting the first service to send a message to > the second one wouldn't be terribly hard. > > > The new W3C WS Choreography Working Group proposes to define a > language > > which would allow you to create a composite web service that would > > coordinate this type of process. The announcement for the group only > came > > out yesterday, so they haven't delivered very much yet. You might look > at > > WSCI (http://www.w3.org/TR/wsci/). > > I think a simple XSLT (or equivalent) would solve this guy's problem. > > > You also might look at Collaxa > (http://www.collaxa.com/home.index.jsp). I > > think they can do something like this. But you still have to create a > new > > service that coordinates the concatenation. > > > > Anne > > > > > -----Original Message----- > > > From: xml-dist-app-request@w3.org > [mailto:xml-dist-app-request@w3.org]On > > > Behalf Of Rand Anderson > > > Sent: Thursday, January 16, 2003 2:38 PM > > > To: xml-dist-app@w3.org > > > Subject: RE: concatenating web services > > > > > > > > > > > > You may want to take a look at the WS-Routing protocol > > > (http://www.google.com/search?sourceid=navclient&q=ws%2Drouting). > > > > > > HTH, > > > Rand > > > > > > > -----Original Message----- > > > > From: Vix [mailto:vixcc@yahoo.com] > > > > Sent: Thursday, January 16, 2003 2:05 PM > > > > To: Sudhir Agarwal; xml-dist-app@w3.org > > > > Subject: Re: concatenating web services > > > > > > > > > > > > > > > > > i would like to know, whether it is possible to pipe the > > > > output of one > > > > > web services to the input of the other web service. > > > > ... > > > > > i want to avoid that the client c gets all the temperature > > > > data from > > > > > ws1 which it then sends to sw2 which calculates the average > > > > and sends > > > > > the answer to c. i would rather like to tell ws1 somehow > > > > (how? that is > > > > > actually my question) to send its output (list of > > > > temperatures) to ws2 > > > > > and not to c. ws2 must be able interpret it as its input > > > > and must know > > > > > that it should send its output > > > > > (average) to c and not to ws1. > > > > > > > > > > > > I don't know of any existing possibility. > > > > However, I would be really careful with this if it exists. This is > > > > simply because lots of security issues might be raised > there. > > > > > > > > Please let me know if any such possibility exists. > > > > > > > > Best regards, > > > > > > > > Victor > > > > > > > > > > > > > > > > ===== > > > > _,.<~=`^`=~>.,_,.<~=`^`=~>.,_,.<~=`^`=~>., > > > > ------> tAke a bReak! gEt eNtertained! http://www.sallini.com/ > > > > ^`=~>.,_,.<~=`^`=~>.,_,.<~=`^ > > > > -> http://netdesignplus.net/ > > > > -> It works... It Pays... > > > > _,.<~=`^`=~>.,_,.<~= > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > > http://mailplus.yahoo.com > > >
Received on Monday, 10 February 2003 12:02:21 UTC