RE: concatenating web services

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