[XML-SIG] WSDL library ?

Martin v. Loewis martin@v.loewis.de
15 Feb 2002 01:57:52 +0100


Paul Prescod <paul@prescod.net> writes:

> You may not be able to "get" it from that section without reading all of
> the context but think of it this way: HTTP is an "Remote Method
> Invocation" model where every single object has the same
> interface...i.e. not really an RPC at all.

Why would that not be "remote procedure call"? Frankly, I disagree
with this thesis. It seems to me that the HTTP client invokes a
procedure (namely, retrieve a resource), and it does so remotely.

I'm not even sure that all servers implement the same protocol. If you
expect some kind of "operation name" in an RPC protocol, I'd claim
that the URL is the operation name. Additional parameters are provided
by the headers, and the body of the request.

> This is a big part of what makes HTTP scale, because once you learn
> that one interface you can develop tons of caches, firewalls and
> other optimizers which you cannot do if people invent their own
> interfaces willy nilly.

I don't believe this is true either. On one hand, requesting resources
based on URL is *not* sufficient for caches and firewalls. Here is a
number of cases why caching could go wrong:
- requesting the same resource (URL) multiple times may return different
  values each time (e.g. in case of a CGI script)
- different parameters (e.g. Accept-Language) may have effect the response
  as well, even though identical requests would give identical responses.
To circumvent these problems, specific support for caching was built
into the protocol (Expires headers, caching indications, etc)

Furthermore, it is *not* true that RPC protocols could not be used in
an infrastructure that allows caching and firewalls. It is quite
possible to have a firewall act as a proxy for arbitrary CORBA clients,
without even knowing the specific signature of each operation. 

For another example, consider NFS: It is clearly an RPC application,
yet caching and firewall traversal are frequently done.

For yet another example, ILU extends the notion of operations on an
interface with a FUNCTIONAL attribute, which allows the client to
cache responses. If such a feature is put in the wire protocol (as a
bit to indicate whether caching of the response is allowed), proxies
could easily perform caching for arbitrary clients. HTTP-ng was built
on top of an RPC architecture, yet it was just as scalable as HTTP
1.1, and more efficient.

So I think it is non-sense to claim that RPC infrastructures, by
nature, cannot scale.

Regards,
Martin