Re: Asynchronous Web Services

"Newcomer, Eric" wrote:
> 
> 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?  

Generally you would not want to expose this "primitive" of a resource
externally (for all of the usual reasons of encapsulation).

> 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?

Mapping.

> 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.

I don't follow you. The HTML form does not do the mapping. The CGI
script or servlet or cold fusion page or... does the mapping. This could
continue for web services. You would of course replace the HTML with
XML. Let me give a very concrete example. Microsoft could convert
Expedia to return XML instead of HTML to XML-accepting clients. HTML
links become XLinks. "Clients" step from page to page following XLinks.
Microsoft documents the structure of the pages as XML Schemas. They
could use a language like WRDL to strongly type declare the operations.
(or not...sometimes a prose description is enough)

In what sense would this not be a "web service"? Although it is not
representative of all web services, I think it is representative of a
large class of them.

> 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?  

If these applications accept connections and those connections are made
using standard Web protocols (HTTP, SOAP over HTTP) then *they are web
servers*. The choice of whether to build on Apache or from scratch is an
engineering and topology decision.

>  ... That's the idea of SOAP and WSDL.

I think that the point of SOAP and WSDL is to enable organizations to
integrate their information systems within the organization and across
organizational boundaries. Preserving existing investments is important
but secondary. And I am much more interested in helping people preserve
their investment in domain-specific software (packaged applications,
custom applications and database schema) than in generic middleware and
database software.

> 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?

It depends on the extent to which those things want to be considered
"Web tools" or implementation infrastructure that is gatewayed to the
Web. I don't think a SQL database needs to be considered a "Web tool"
though Web supporting interfaces are sometimes convenient. Application
servers already support REST! The app server software category rose to
prominence as the tool you use to do the mapping between legacy systems
and "the Web architecture".

> If we are not suggesting that, we have to be defining an 
> abstraction that allows messages to be exchanged across these 
> types of systems.  

Let me provide an example. CTO recognizes that his sales automation
systems cannot speak to his accounting systems so he doesn't know when
sales calls translate into purchases. The sales automation system is
built around a CORBA ORB. The accounting system is built around MOM.

The CTO goes to a generic integrator and asks for a solution. The
integrator might say: "Sure, I can write some glue code to integrate
those systems. I'll insert another middleware system and a bunch of
code."

The CTO goes to a REST advocate and asks for a solution. The REST
advocate says: 'Buy two Web app servers and write code that maps each
into the Web data model. Make every logical object "sales call",
"customer", "purchase" into a resource. This might be more expensive
than the solution above but when you want to integrate a third and
fourth and fifth system, you have an O(N) integration problem, not
O(N^2)." The REST solution will not standardize everything, but it will
standardize primitive message exchange patterns, addressing model and
allowed operations. What it does not standardize is information
representation. Purchase orders will still use a different vocabulary
from sales call logs and when new systems are brought in, their
representations must also be integrated.

The CTO goes to his ORB and MOM vendors and asks for a solution. They
will say: "The next version of our products will support SOAP and WSDL.
So you just need to upgrade and you'll get interoperability." But what
does this mean? Both can support SOAP, but that does not mean that two
services will have a common addressing model. It does not mean that they
will have common operations. It does not mean that they will have a
standardized information representation. What concretely does the client
gain from the fact that the ORB and MOM vendors have both wrapped their
proprietary information model in XML angle brackets and SOAP envelopes?
(actually, SOAP does not even require angle brackets)

Or let's talk about WSDL. So the client now has a WSDL definition for
both services. They have a very concrete representation of the distance
between the two. They *still* have to write glue code to integrate the
addressing models, MEPs and operations.

> If Web services are not useful for interoperability across existing 
> software systems, I do not think they have another compelling 
> reason for existing.  

That's a surprising statement! Doesn't interoperability of new systems
count for anything? I thought that Web Services would allow new kinds of
applications to be built!

> 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.

Could you please outline what is standard across the range of software
applications you've described? Relational databases, MOMs, ORBs, OODBs,
app servers, etc.?

>...
> 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.

Does IONA's software achieve a high level of compatibility with, let's
say, BizTalk, Oracle and Sun ONE just by virtue of SOAP and WSDL
interfaces?
-- 
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 Monday, 22 July 2002 12:16:14 UTC