Hi Pae!
+1, with some clarification:
What you describe is certainly a valid way to look at SOAP intermediaries,
but it isn't the whole picture. While there may be times when you want a
"transparent proxy" which performs some service or other "invisibly" on your
behalf (or that of the service provider), there are equally important times
when the sender of a message actually needs to know the message path and
what functionality is available at each hop along the way.
This is part of the reason for the "actor" attribute in the SOAP spec. It
allows a client to build a message and insert a header which is specifically
targeted at, for instance, a security intermediary which sits on a firewall
into a corporate intranet.
There may also be times when the client chooses a particular path for the
message to take, using some higher layer extension such as SOAP-RP [1]. The
SOAP spec is intentionally very loose about message path and transparency
issues, so that the community can build a variety of useful models on top of
the core protocol.
Cheers,
--Glen
[1] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
----- Original Message -----
From: "Pae Choi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 9:20 PM
Subject: Re: chaining soap servers
> Hello Hari Nam,
>
> From the initial SOAP client perspective, all other SOAP servers other
than one
> , e.g., 1st SOAP server, which receives the SOAP request should be
transparent.
> This means that next SOAP server in the chain should be determined by the
one
> that is forwarding the request. During the forwarding flow through the
intermediate
> SOAP servers, you can think about the SMTP store-and-forward mechanism if
> you want imagine even though it is a perfect example.
>
> So, however the forwarding SOAP server process and transmit the requst is
your
> choice as long as the next SOAP server understand the message defined by
the
> standards.
>
> Does it make sense to you?
>
>
> Pae
>
>
> > Hi,
> >
> > I have a more general question on SOAP. The spec suggests that possible
SOAP
> > requests may travel through multiple SOAP servers. Those SOAP servers
may or
> > may not alter the body somehow.
> >
> > So, it says that the SOAP header has an actor element that describes the
> > next SOAP server that it should go to. Is that correct?
> >
> > How do I describe a chain of SOAP servers? E.g., go to this SOAP server,
> > then this and then to the final SOAP server? According to the spec,
should I
> > just add multiple actor elements in the header? And, the order of the
> > elments describes the order of the SOAP servers? Does the SOAP client
API
> > support setting multiple SOAP actors?
> >
> > Here is, what I want to do.
> > I) Have a SOAP server accept SOAP requests from Java and non-Java
clients.
> > The SOAP request won't be processed here. Rather, it should look at the
SOAP
> > envelope to determine, to which SOAP server this should go.
> >
> > II) That's, where I want to use a proprietary JMS protocol to call on
> > another SOAP server. This SOAP server looks at the SOAP header, and
figures
> > out to which http SOAP server to make the request to.
> >
> > It seems that the SOAP spec supports and suggests this. Though, could
> > someone illustrate me with a sample SOAP header, how this would work.
Plus,
> > does Apache and general client SOAP implementations support this?
> >
> >
> > Thanks a lot,
> > Hari Nam
>
