OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Web Services - what is the alternative? (was TAG on HLink

[ 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 

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


A city is like a large, complex, rabbit
 - ARP


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS