Re: The Protocol [was: Syntax] is API Fallacy
Jonathan Borden wrote: > > First, let me preface this by commenting that I am a proponent of > layering, and there is much useful insight gained by layer analysis in > system design. That being said, the RPC model, now the distributed object > model defines a specific mapping between a syntax layer above the network > layer (e.g. DCE-RPC/NDR over TCP/IP) which defines a direct correlation > between the "API" generated by an IDL compiler and network PDUs. So the 7 > layer OSI model can be applied to systems design. And if done in that way, you run right into the "Protocol is API" fallacy. I've been doing distributed systems since the mid 1980s and have come to understand that there exist major limitations in the RPC model. > Via this mapping, one can *compile* IDL e.g. CORBA or DCOM into an > HTTP/XML binding. HTTP/XML replaces the IIOP or DCE-RPC. This is what is > known as XML-RPC. The fact that one "can" do it doesn't make it a good idea for all, or even very many, cases. The fallacy is that one focusses on the API rather than the protocol; and APIs have an unfortunate pattern of not addressing protocol problems. Moreover, there's major resistance to getting them to be addressed; the problems strike at the heart of RPC, which is to enable an API mapping by removing message patterns and system structures that are essential for working in real systems. - To design a protocol, design a protocol. - To design an API, design an API. - Understand the severe limitations of mapping APIs to protocols. You need both protocols and APIs. But there is no one-to-one mapping that works in all cases. Good protocols support many APIs, and vice versa. RPC systems remove that flexibility; they force API changes when protocols change, and vice versa. > API, Syntax Protocol etc describe different layers in a system. When > well known/standard interfaces are developed to link different layers in a > system, system developers can concentrate on the important tasks of system > design and object analysis and allow the plumbing to do its job. There's a signifcant issue with the quality of the linking. RPC systems hide significant parts of the network, which need to be surfaced. They don't expose faults well, or recovery mechanisms; they complicate callback style messaging patterns unduly; they bury encoding issues, and impose specific protocol-to-API mappings even in environments where they're not at all appropriate. Consider that no RPC system in the world (CORBA, ONC, DCE, etc) has had the reach of some rather basic non-RPC systems like E-Mail (SMTP, POP, IMAP) or the web (HTTP, HTML, XML, etc). For folk who have spent a lot of time working on architectural issues, this is telling: it says that there's quite likely a problem with the RPC approach. I think that is fundamental to the approach at this point; the very thing that makes RPCs seem easy to understand is the thing that makes it a weak paradigm in the big picture. It's just not a rich enough model. > In the distributed object world, the interface (which here is called > the 'API') is primary and the network plumbing and serialization format is a > detail to be taken care of by the system. Which is the fallacy: it doesn't work as well as defining protocols first. Because that plumbing isn't a mere detail, it's extremely significant to the overall evolution of the system and it needs to be designed with that in mind. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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