Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Web Services - what is the alternative? (was TAG on HLink
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
