[
Lists Home |
Date Index |
Thread Index
]
Joshua Allen wrote:
>
> > > > In my mind, the defining characteristics of RPC are a) a single
> > > > endpoint supports an arbitrary number of methods b) the endpoint
> is
> > > > allowed to invent its own methods and c) the endpoint returns
> values
> > > > based on the method name and method inputs.
> > >
> > > In my mind, the defining characteristic of RPC is that it is Remote
> > > Procedure Calls, passing parameters to named methods and expecting a
> > > result. Your (a) and (b) strike me as nifty extra features, not
> > > something fundamental.
> >
> > Can you name a protocol that bills itself as RPC that lacks features
> a)
> > and b)?
> >
>
> Well, it all depends on what you are calling the "endpoint". Most
> people think of RPC as being "remote procedure call", not "remote
> procedures call". If you are defining the endpoint to be the middleware
> layer that routes RPCs to the appropriate end-endpoint, then maybe you
> have a point.
I don't understand what middleware has to do with it. I'll ask the
question again: do you know of a protocol that bills itself as RPC where
the core method names are predefined in advance by the protocol? Is FTP
an RPC protocol? If not, why not?
>...
> > the case that everything that RPC touches immediately falls apart.
> It's
> > rather the case that the RPC layer is not a very important or helpful
> > layer which is why you can get away without defining it formally. The
>
> You mean, "not very important or useful ... when passing hypertext
> around"?
No, in general. FTP works fine without being defined on top of an RPC
protocol and its used for non-hypertext data. DNS works fine without
being defined on top of an RPC protocol. I don't see how either protocol
would be more useful if it were defined on top of an RPC protocol.
> > RPC layer only takes on mythic proportions when people start to revel
> in
> > the ability to invent their own protocols on top of it...and that's
> > where interoperability starts to degrade.
>
> We may be talking about different things, but defining a common format
> for people to slap RPCs on top of HTTP rather than having everyone roll
> their own formats (including various things that look like XML-RPC,
> hidden form fields, URL-munging, etc.) seems to *help* interoperability.
Hidden form fields are payloads. The vast majority of XML-RPC is payload
definition. Yes, payloads need to be standardized. But most often they
will be vertical, not using any SOAP-defined payload. The payloads will
most often be XML vocabularies defined by vertical industries like
these:
http://www.xml.org/xml/registry.jsp
URL-munging is in a different category. That's endpoint addressing and
SOAP doesn't standardize it because SOAP endpoints are just URLs also.
IMO, there are three issues that need to be standardized before you can
talk to another system:
* who can I talk to?
* what can I ask them to do?
* what data formats can I give them to work with?
HTTP standardizes the first: "anything with an HTTP URI".
HTTP standardizes the second: "PUT, POST, GET, DELETE".
HTTP leaves the third entirely up to the application, as SOAP does
(ignoring the SOAP encoding).
It is the standardization of those first two things that makes HTTP an
application protocol, in my mind. When you put an RPC protocol on top of
it you lose the second standardization point and if you start passing
parameters to GET-like methods in the XML body then you lose the
standardization of the first also. After all, if the method is GET-like
then clearly it is "addressing" so the standardized way is to put the
addressing information in the URI.
Paul Prescod
|
