The Protocol [was: Syntax] is API Fallacy

[David Brownell]

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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)