[
Lists Home |
Date Index |
Thread Index
]
> > > 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.
There is nothing in the definition at:
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214272,0
0.html
that would imply that an RPC would have to support routing middleware to
be called RPC.
> 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"?
> 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.
|
