[XML-SIG] WSDL library ?

[Martin v. Loewis]

Paul Prescod <paul@prescod.net> writes:

> > 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.
> 
> If the URL is the operation name then what is the HTTP method for?

For all practical purposes, the method can be only "GET" or
"POST". Those are really synonymous; it is merely a protocol variant
(i.e. POST can be taken to mean "do not cache", so it is part of the
protocol header).

> > 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)
> 
> 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.

In RPC, you can also know when you invoke the same operation on the
same object twice, and cache the result (consider the NFS case).

> > To circumvent these problems, specific support for caching was built
> > into the protocol (Expires headers, caching indications, etc)
> 
> 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.

Sure. But the RPC infrastructure could provide the same kind of
information. E.g. ILU does, with the FUNCTIONAL attribute.

> > 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.
> 
> A firewall that doesn't understand the data it is passing back and forth
> isn't much of a firewall.

So it should not let HTTP through then, either? After all, a POST
could include arbitrary information (such as a SOAP message, or a GIOP
message).

> > For another example, consider NFS: It is clearly an RPC application,
> > yet caching and firewall traversal are frequently done.
> 
> 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.

The caching is done on the NFS level. NFS is an RPC application, so it
is both: RPC and application. In this terminology, could you agree
that HTTP is an RPC application (with a fixed set of operation names:
GET, POST, and a few that aren't in use)?

> 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. 

Exactly. So what is the point? It seems what you are saying is "RPC
cannot (in general) be used without knowledge of the specific
interface"; I could not agree more. Your implication "it does not
scale" then becomes "RPC does not scale, but specific RPC applications
can".

For example, Google could collect information from CORBA Naming
Service installations right away (or better CORBA bootstrap
installations, since they even have a well-known port). So it would
seem that you can agree that the CORBA Naming Service does scale, and
so could my own CORBA application. If so, we are in violent agreement.


> 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? 

The value of using an RPC infrastructure is that it precisely safes
you the effort of defining your own wire protocol. The wire protocol
(and in case of CORBA, the programming language API) is implied by
defining the interface.

> If you want to think of HTTP as being built on top of a nameless RPC
> protocol then go ahead. 

That is indeed my view.

> 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.

Because they are applications with widespread applicability. There is
(unfortunately, IMO) a tradition to define text protocolls in the
internet. The Intelligent Net telephone infrastructure (the one that
implements number translation for the 1-800 services etc) is indeed an
application of an RPC protocol (an adaptation X.880, to be specific).
I'd claim that there are more invocations of that application on any
given day than there are FTP or SMTP interactions (HTTP invocations
might outnumberb the number of phone call to toll-free telephone
numbers).

> HTTP-NG is just the latest in the list of failures. I predict SOAP
> will be next.

Those infrastructures are only used if people use them for
applications. They will do so if they help them to do their work (such
as CORBA and COM do), instead of being in the way of solving the problem
(as is the case with HTTP-ng, SOAP, and DCOM).

They will certainly never see such widespread use as HTTP or SMTP,
just since the applications that are developed with it are not as
widely used as "retrieve remote document" and "send electronic mail".


> > So I think it is non-sense to claim that RPC infrastructures, by
> > nature, cannot scale.
> 
> 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.

It seems that out main problem is a terminology one. What means "it
cannot scale" to you? To me, it means "you cannot build an
infrastructure where many user in vastly remote locations
participate". I still think this not true, for RPC systems. To you,
it seems to mean "it is unlikely that as many users will ever use
it as they use HTTP today to get documents". If so, we agree.

I'm still a bit unclear what to make of the fire-wall compatibility:
it seems that for any specific application, you'll either have to
explain it to the firewall, or cheat it; whether the interaction
is REST-style or RPC.

> I've been through this so many times that I can't do it again. Here are
> some URLs:

Thanks for these. I agree that we probably don't need to continue this
discussion endlessly; it seems that we don't disagree that much about
facts, just in how we judge the relevance of these facts.

Regards,
Martin