xml-dev - Re: The Protocol [was: Syntax] is API Fallacy

[David Brownell <david-b@pacbell.net>]

Jonathan Borden wrote:
> 
> David Brownell wrote:
> 
> >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.
> 
>     This isn't the problem with RPC systems at all (including CORBA, Java
> RMI, DCOM, DCE-RPC etc), 

Which of those six points are you referring to?  I assure you I've seen
at least half of those problems in each "RPC" system you mention.


>		 and certainly the current defacto web 'protocol'
> namely a form and www-form-encoding or a CGI query string is hardly a robust
> way for programs to communicate.

For three years now, I've advised folk to use HTTP "POST" with request
bodies that encode data in some useful form ... e.g. XML documents.

Query strings only appropriate for requests where parameters can safely
be logged (no credit card info!) or exposed to third party sites (watch
those "Referer:" headers) and also are idempotent (which very few are).


>	 Rather, the ubiquity of firewalls allows
> HTTP and SMTP traffic to flow where no RPC can go.

That's an issue I raise separately.  CORBA was designed to support the
notion of firewall bridging, and in fact I wrote that into the spec.
Few other RPC systems have the technical wherewithal to handle that;
you need an exposed, queriable type system.  (Preferably a lot better
than XML DTDs!)


>     You are missing the picture. Designing your own network protocol for
> each new application is as useful as writing your own XML parser for each
> new application. 

Apples and oranges.  Exactly what do you think any RPC's IDL is doing, if
not defining a new protocol?  (And causing problems by equating it to API?)

Are you perhaps confusing lower level protocols with higher level ones?


>	We have learned something from layering, interfaces and
> code reuse (despite your protests). Why should a developer need understand
> network issues etc when all they wish to do is send a message across the
> network. 

Sending messages is what defines a protocol.  Sending new messages is what
defines a new protocol.  Not all sequences of messages can work in the face
of the inevitable failures, and that's part of why developers need to have
some understanding of network issues.


> >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.
> 
>     That's exactly my point, there is no reason not to layer IDL on top of
> perfectly good protocols such as HTTP and SMTP. 

You're then missing my point in its entirety.  The problem is the model,
the notion that the system building block is an "RPC" of any kind.  Protocol
isn't the issue; after all, in an RPC system, it doesn't matter right?  Since
nobody sees it.


>	Why do you compare RPC to XML?
> They are different species. This confuses the issue.

I don't think I compared them except by context; but the reason it's
an interesting comparision is because they _are_ different species.

XML based systems can be designed without some of the flaws of RPC
based systems.  Or -- they could recreate those flaws.  I vote for
the former.


>     I'm suggesting that the abstraction afforded by IDL and RPC can be
> layered on top of HTTP and SMTP via XML? Do you have a problem with this?

Yes.  I stated it pretty succinctly above:  

> > 	they bury encoding issues, and impose
> > specific protocol-to-API mappings even in environments where they're not
> > at all appropriate.

Or as I said later in that post, you have to change API and protocol in
lockstep.

 
>     This is my suggestion (feel free to propose another): Distributed
> systems can communicate via HTTP and SMTP using XML documents as the
> contents of their MIME messages 

So far so good; people have agreed on that one for some time.  Though
I'm waiting to see details on how SMTP really fits in.  Store-and-forward
messaging is usually done through a different API model than RPC.


>	and function in the same fashion as
> distributed systems which employ IIOP or DCE-RPC.

That's where I have problems.  Those systems impose the RPC model.
And I have stopped liking that model for "real systems".  It's an
appealing way to get started; there's a seeming simplicity from the
academic point of view.  But such systems don't grow/evolve so well.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)