[
Lists Home |
Date Index |
Thread Index
]
On Thursday 26 September 2002 02:59, Rob Griffin wrote:
> So here's the question. What is the alternative to Web Services?
Good 'old CORBA...
> Or is the answer that no form of RPC is acceptable?
Quite possibly. There is stupidity and craziness in how we think about
networking. Models of how people think of the network that I have seen are:
1) Unreliable packet blasting, UDP style
2) Isochronous bit streams, ATM style
3) Asynchronous bit streams, TCP style
4) Blocking request/response, RPC style
5) A sea of objects implementing interfaces, CORBA/RMI/HTTP-POST style,
differing from (4) only in the concept of invoking a method on an object (of
which there are many on a server) rather than invoking a procedure on a
server (one argument of which might be the ID of an object to operate on, as
in NFS, but that's up to the application).
6) A sea of documents, HTTP GET style.
7) A load of joinable broadcast channels, multicast / JMS topics style.
8) Reliable packet blasting, JMS queue / RDP style.
Now, rather than warring between these factions, how about we consider the
idea that maybe different approaches are useful in different applications and
make a model that merges them all together? The ISO OSI model is a model of
network implementation, not of different services the Transport/Session
layers might provide to higher layers, and so people have neglected the broad
issues there. The TCP/IP people seem to have gravitated towards (3) with a
little taste of (1) as being the fundamental architecture, and people have
ended up hacking the rest together on top of TCP. The telcos like (2) since
it supports their media streaming. Application developers seem to crave a mix
of (5), (6), (7), and (8), and the intrepid developers of real-time stuff
know they need (1) because there are tradeoffs inherent in converting (1) to
(8) that they can't tolerate.
It shouldn't be so hard to merge all those approaches into one. We can have
the concept of a network address identifying a host and something within that
host, URL style, and have each addressed entity provide an interface CORBA/WS
style, but allow that interface to include more than just RPC-style methods.
Let it also include void-returning methods that are marked as reliable (8),
broadcast (7), or unreliable (1). Let it include methods marked as
'idempotent' and/or 'cacheable' whose return values for a particular set of
parameter values can be cached, (6) style. Let it have methods that open
synchronous or asynchronous byte streams; when accessed from Java those would
appear to be methods that return InputStream or OutputStream objects.
By merging all the different APIs we use for TCP, UDP, RPC, Web Services,
CORBA, JMS, HTTP, and so on into one unified architecture for addressing
(low-level; this is like TCP, not HTTP; these things are not to be treated
quite like URLs, but they will be embedded in URLs as a hostname:port number
pair no doubt...) network resources and then invoking the appropriate
protocol to handle the actual communications, we'll make it easy for
developers to use what they need... the interface exported by an instant
messaging client would have type (8) methods to send me a message, type (3)
methods to start up interactive chat, type (2) to start up a videoconference,
type (6) to obtain general information about me, and type (4/5) methods to
get real-time information about whether I'm at my machine or busy or away or
whatever.
This might then end the wars between different models of development!
How does this interact with REST? Well, the partial isomorphism is that:
GET http://foo.com/AlaricsIM/getUserDetails?section=Postal
...is the same as...
fnp://foo.com:AlaricsIM/getUserDetails(POSTAL)
fnp = Federated Network Protocol
foo.com = server
AlaricsIM = object identifer
getUserDetails = method name
(POSTAL) = arguments
So type (1), (7) and (8) methods are like a POST that returns nothing, with
the option of not caring whether it returns an error or not (and thus not
wasting resource sending that error back to the client or setting up a TCP
connection to get reliable delivery); (4) and (5) are like POST; (6) is like
GET, of course; and (2) and (3) are like ugly tricks with POSTs that have
unbounded request or response bodies.
The main thing we add in terms of *capabilities* on top of REST/HTTP is that
we can signal to the lower layers whether we want to bother with stuff like
retransmission and maintaining ordering.
The more advanced version I have designed, which I won't detail the operation
of here, replaces the methods that open byte streams with methods that
instead create a pair of interfaces - one on the client, one on the server -
that face each other on a connection. The connection then has the option of
enforcing the ordering of requests sent by one end being the same when
received by the other end, and it also provides for bidirectional
communication (which surprisingly many network applications need, yet few
protocols implement nicely). That same connection can make use of guaranteed
bit rates and so on when running over networks like ATM or frame relay.
ABS
--
A city is like a large, complex, rabbit
- ARP
|
