[XML-SIG] WSDL library ?
"Martin v. Loewis" wrote:
>>
>>...
>>
>> 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. (01)
One of the defining characteristics of procedure calls is you get to
choose your own procedure names, per component. In HTTP the names are
generic across all components. (02)
> 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. (03)
If the URL is the operation name then what is the HTTP method for? (04)
> > 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) (05)
That's why there are cache control headers. But unlike RPC you *know*
when you are requesting a representation of the same resource multiple
times. (06)
> - different parameters (e.g. Accept-Language) may have effect the response
>> as well, even though identical requests would give identical responses. (07)
Caches know about this stuff. (08)
> To circumvent these problems, specific support for caching was built
>> into the protocol (Expires headers, caching indications, etc) (09)
Exactly. And caches combine these *generic* headers with the *generic*
method name to figure out what is going on. Whereas in RPC the method
names and headers (if any) are specific to the service. (010)
> 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. (011)
A firewall that doesn't understand the data it is passing back and forth
isn't much of a firewall. (012)
> For another example, consider NFS: It is clearly an RPC application,
>> yet caching and firewall traversal are frequently done. (013)
But is the caching and firewalling done at the RPC level or the NFS
level? NFS itself is more like HTTP, an application protocol, than like
RPC. It has a fixed set of methods etc. (014)
> For yet another example, ILU extends the notion of operations on an
>> interface with a FUNCTIONAL attribute, which allows the client to
>> cache responses. (015)
Caches are just one example. Filters, loggers, spiders, proxies, these
all depend on knowledge of HTTP (or NFS, or SMTP) semantics. Google is
an example of a web service that only works because it knows that the
services it talks to all speak HTTP (or FTP, or some other protocol with
known semantics). Google will likely never do anything useful with an
XML-RPC site. It could only ever make progress if something ON TOP of
XML-RPC defined some semantics it understood. And that thing on top
would be the important bit. XML-RPC would just be annoying syntax that
got in the way. Babelfish is the same. Meerkat is another. (016)
> .... 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. (017)
Yes, you can build efficient protocols *on top* of an RPC. That is very
different than saying that RPC scales. You can also build an efficient
protocol *without* RPC and what value is the RPC layer providing you? (018)
If you want to think of HTTP as being built on top of a nameless RPC
protocol then go ahead. That doesn't change the fact that HTTP is not
itself RPC, nor that non-RPC protocols like HTTP, FTP and SMTP have
achieved much more widespread usage in "internet-scale" applications
than RPC protocols have. HTTP-NG is just the latest in the list of
failures. I predict SOAP will be next. (019)
> So I think it is non-sense to claim that RPC infrastructures, by
>> nature, cannot scale. (020)
If you use RPC as RPC, i.e. defining your own methods whenever it is
convenient to, then you will not achieve internet-wide scalablility,
popularity nor fire-wall compatibility. (021)
I've been through this so many times that I can't do it again. Here are
some URLs: (022)
* http://www.xent.com/pipermail/fork/2001-August/002801.html
* http://mail.python.org/pipermail/xml-sig/2002-February/007160.html
* http://www.xml.com/pub/a/2002/02/06/rest.html
* http://www.xent.com/jan00/0907.html
* http://conveyor.com/RESTwiki/moin.cgi/HowToConvertRpcToRest
*
http://www.distributedcoalition.org/mailing_lists/dist-obj/msg03077.html
*
http://www.distributedcoalition.org/mailing_lists/dist-obj/msg03084.html
*
http://www.distributedcoalition.org/mailing_lists/dist-obj/msg03091.html (023)
If you still disagree when you've read them (and Fielding's thesis) then
that's okay with me. There is always room in the computing industry for
another attempt to deploy RPC on the Internet. We can have this debate
again in a couple of years. ;) (024)
Paul Prescod (025)