RE: Asynchronous Web Services

Paul,

I'm interested in clarifying some things in this message.  Are you suggesting that a database be exposed to the Web as a resource?  Or a CICS transaction?  In other words, is the suggestion that a URI point to these type of legacy systems directly?  Or is it assumed that some sort of indirection or "mapping" occurs between the Web and these systems?

You mention how Web sites work today by mapping into legacy systems.  There are well established mechanisms for calling from Web severs to back end systems via application servers, CGI scripts, etc.  But interacting with these systems requires human interaction with an HTML form of some kind.  I'm really not clear on how you propose to accomplish this automatically, machine to machine, without a browser, if there isn't some definition of the mapping between the legacy applications and the Web.  

A very important question lies within this area of debate.  Is it the responsibility of the "web server" to map to any and all middleware systems, database systems, and packaged applications?  That's pretty much the case today.  Or can the responsibility be moved to the middleware systems, database systems, and packaged applications to do the mapping?  That's the idea of SOAP and WSDL.

I don't think anyone is suggesting that we propose re-implementing existing database management systems, transaction processing monitors, application servers, object request brokers, messaging oriented middleware systems, etc. to adapt to REST, or am I wrong about that?  

If we are not suggesting that, we have to be defining an abstraction that allows messages to be exchanged across these types of systems.  If Web services are not useful for interoperability across existing software systems, I do not think they have another compelling reason for existing.  I also believe it is possible to abstract the interactions across existing software systems, as they are similar enough in what they do, and how they can be told what to do with the data they receive.

However, I am not sure we can teach existing web servers to map HTTP semantics onto each of these systems successfully.  As a practical matter, wouldn't this mean re-implementing existing web servers to add all the functionality to map HTTP method names onto any type of existing software system?  And what about the flexibility fo map the same method names to multiple software systems?  

I think there's a real fundamental issue here with respect to the implementation of whatever architecture gets defined.  I believe the model of having the system software vendors implement Web services has proven successful enough so that we seriously risk the adoption of Web services if we propose to have web servers implement them, instead.

Regards,

Eric

-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Saturday, July 20, 2002 8:12 PM
To: Edwin Khodabakchian; www-ws-arch@w3.org
Subject: Re: Asynchronous Web Services



Edwin Khodabakchian wrote:
> 
> Paul,
> 
> This is a very good explanation.
> 
> How would you address the case where the client initiates the long-lived
> transaction through a one-way protocol like SMTP or JMS. It seems to me
> that it that case, the client needs to specify the correlationId.

Edwin: I think that this is a core disagreement between the REST and
SOAP communities. When you have to start dumbing down your archicture to
preserve compatibility with hundreds of different protocols, the cost of
compatibility with those protocols is way too high. I will be speaking
on this theme at a few conferences and in some upcoming papers.

If you want wire-level interoeperability then the participants in
communication must choose a particular wire protocol. The software
vendors and enterprises who dominate the Web Services world naturally
have a tendency to want to preserve their investment in non-Web
protocols (including SMTP). What I believe that they do not understand
is that the money saved in the short-term in that preservation is vastly
overwhelmed in the money they will spend again three years from now
solving the interoperability problems they solve today by continuing to
use non-Web protocols.

Of course, saying "non-Web protocols" is just a politically correct way
of saying non-HTTP protocols because HTTP is the only protocol so far
developed (if we exclude the HTTP variants WebDAV and SOAP+HTTP)
specifically to integrate with the Web architecture and with a deep
understanding of the central concepts of that architcture (in particular
URIs). Even SOAP 1.2 does not require messages to always be addressed to
a URI (though the HTTP binding requires that of course).

So anyhow, you will never see me compromise a design "in case" it needs
to run over JMS or SMTP. Note that I am not deprecating the importance
of either reliability or asynchrony. Reliable systems are important.
Reliable messages are not. They are only a means to an end in some
architectures. Similarly, asynchronous systems are important.
Asyncronous messages are not. Note that SMTP is not an asynchronous
protocol in the same sense that UDP is. SMTP is a synchronous protocol
weaved into an asycnchronous system. I propose that this widely adopted,
successful model is also appropriate for web services.

If and when someone invents a reliable or asynchronous protocol that is
truly a web protocol in its understanding of the role of URIs as
addresses and URIs embedded in documents ("hypermedia") as an
abstraction, I would adopt that alongside HTTP happily. Until that
happens, it is easy enough to build reliable and asynchronous systems in
HTTP as it is today that I do not feel that I am asking anyone to
sacrifice anything.

> As to whether the correlationId should be a URI, some clients (like a VB
> app) cannot host URIs: those clients interact with the long-lived
> transaction through polling (passing in the correlationId as part of
> each request).

I presumed that typically the server would host the conversation
resource. That's why I said that the server should invent the name
(URI), not the client.

> It seems to me that a correlationId is not a resource but rather a key
> used as part of an asynchronous interactions.

Why shouldn't a key be a resource? I've outlined the benefits of doing
it. The only complaint yet proferred about the model is: "it doesn't
work with non-Web protocols." But this is the W3C and we are building
the Web, not building life support for non-Web systems. Once again let
me say that I am not deprecating legacy systems especially legacy
business logic. The Web deals with legacy systems through gateways. When
I order a ticket from Expedia I do so through HTTP even though I presume
that my message at some point travels over the proprietary Sabre
information network. The Web is precisely the *standardized glue*
between these legacy systems. 

If those legacy systems start to migrate from the edge of the network
into the very architecture then we are just rebuilding the mess that
already exists. I'd rather build a new system that is clean and clear
and can be the common conversation point for those legacy systems.

An attempt to build a union of existing systems will collapse under its
own weight. Let me make the necessarily inflamatory suggestion that if
vendors had tried to build the Web they would exactly have attempted to
grandfather in every hypertext language and transport protocol and
messaging protocol: Lotus Notes+Microsoft Help+CICS+.... This would have
made the migration from existing systems to the Web cheap for their
customers but interoperability would have been terrible. Instead, the
Web was invented by idealists who said: "map all of your old crap into
our model. It will be very expensive but interoperability will be
great." It was very expensive: expensive enough to build entirely new
companies like BEA, Allaire and Vignette. But it was cheaper than
limping along with half-way compatible systems.

Sorry for the long note but I wanted to explain why I do not see
arguments about protocol independence to be persuasive.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Sunday, 21 July 2002 12:44:15 UTC