rdilipk wrote:

> then how about this?
> http://www.sellsbrothers.com/spout/#httpIsDead

Let's not mince words: Don views HTTP as "the cockroach of the Internet" ---
his own words. Don's perfect world is one where the Internet is a universal
bus on which type-specific objects communicate. That's a nice vision, but
one that is technically flawed in a very obvious way: all attempts to build
such universal buses for type-specific objects or components has failed.

Agreement and problems with Don's POV:

(1) Asymmetry of HTTP is a problem. No doubt, I am in total agreement. But
the problem can be solved in numerous HTTP-friendly ways, many of which have
been discussed on this list, more elsewhere. That asymmetry doesn't mean we
have to chuck HTTP, though; there's exponential value in putting an HTTP
listener everywhere there are resources of interest, exposing those resources
through HTTP. Dealing with the firewall is simply a matter of standardizing
generic rendezvous intermediaries and how they interact with domain naming.

(2) His concern over long-running transactions is a red herring. Think
about it this way: existting client-server DB connection protocols support
transactions --- even long-running ones --- and transaction management at a
semantic level. However, these things are modeled on top of RPCs, which are
1-shot, synchronous, and provide no transactional semantics. HTTP doesn't
directly model transactions, but that doesn't mean you can't build
transactional systems on top of it. It's simply a matter of modeling your
"application" (i.e., resources or domain objects and their interactions)
appropriately.

(3) He fails to factor out the need for long-running "transactions" and
asynchronous messaging. They are related but different. Again, HTTP's
fundamentally synchronous nature doesn not prevent asynchronous
communications patterns from being used. Paul's HttpEvents spec, Mark
Nottingham's WARM / RUP work, and so on are nascent attempts to define how to
do asynchronous communications in a manner that fits with the current Web
architecture.

(4) Fundamentally, Don's got a very deep vested interest in seeing RPC-style
SOAP interfaces deployed universally; this interest is rooted in Microsoft's
own deeply vested interest in maintaining balkanization of data and systems
and integration friction. To the extent that the Web architecture succeeds,
it strategically devalues Microsoft.

(5) Don and the rest of the SOAP-RPC camp are suffering from yet another
iteration of a fundamental failure of software engineering and design. Our
industry was sold a bill of goods about "reuse," productivity gains, etc.
-wrt- OO 10-15 years ago. In the process of buying into the OO religion, we
failed to learn an important lesson: OO rarely works as a large-scale
integration methodology. Generic interfaces and generic composition
frameworks have always demonstrated better scalability, reusablility,
simplicity, economics, etc. than OO. Cases in point: UNIX, Plan 9, the Web,
Linda. Until we as an industry learn the lessons these examples pose, we're
doomed to fail over and over again, developing technologies that cannot
withstand the test of time and ubiquity: ONC and DCE RPC, CORBA, DCOM, etc.

jb