RE: Asynchronous Web Services

Paul,

Ok, I think we are sort of getting somewhere here.  

-- The Expedia example is not a Web service since it still involves human interaction.  What we want is Expedia to automatically book flights based on calendar choices in a PDA.  Expedia needs to become a "service" to which one can send messages across the Web, not a site that simply serves pages.  Would you argue that the Web services APIs that Google and Amazon.com have recently developed and published are not useful since they expose a different paradigm than interacting with those sites via URI based method names and parameters?

-- Joining applications by joining their web server mappings is inefficient compared to joining them directly, although I agree the 0(N) problem is the same one we are trying to solve with SOAP and WSDL.  Also there is no way to represent middleware semantics.

-- Middleware systems share fundamental information requirements that allow an abstract messaging system to be defined that spans them -- the service name, data (whether in arguments or text blobs), security context, transaction context, and session/user context. We at IONA have successfully bridged COM and CORBA, J2EE and CORBA, and CORBA with CICS and IMS.  We have implemented an abstract runtime kernel that is capable of plugging multiple transports.  This problem is solvable.

-- With regard to the packaged application/middleware debate, people have been saying for about 30 years now that they're going to replace their CICS and IMS middleware systems.  There is no practical difference between homegrown applications based on middleware and packaged applications that someone else developed -- the issues are the same.

-- The idea that adding SOAP and WSDL to CORBA and .NET (for example) improves interoperability is easily proven.  Our Web services product accomplishes just that, using a very simple point and click development environment.  The same kit integrates J2EE application servers.  There are design issues, and mapping issues, but basically we can point our toolkit at a WSDL file exported by a .NET application and instantly interoperate. The same can't be said of integrating CORBA with .NET through IIS.

-- One fundamental area of disagreement here seems to be whether or not it's appropriate to encapsulate the method name within the data, or within the message (and perhaps that also brings up another fundamental area of disagreement, whether we are dealing with messages or documents).  I am not sure it makes sense to require everyone to expose every method they want to integrate using a URI.

Of course behind all this is still the fact that the term "Web service" still means different things to different people, and that the term can be very, very broadly used.

More below.

Eric

-----Original Message-----
From: Paul Prescod [mailto:paulp@ActiveState.com]
Sent: Sunday, July 21, 2002 2:15 PM
To: Newcomer, Eric; www-ws-arch@w3.org
Subject: 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).

** But this seems to be exactly what is suggested by using a URI for each method exposed as a Web service...

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

** Then what is wrong with the mapping phase including the method name?  Other than violation of REST, that is?  I have heard the argument that it doesn't scale, and I understand that it doesn't, but I am also unsure it needs to, since Web services are not the same thing as Web page interactions (and perhaps you are saying that they are, and this is also part of the disagreement).  

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

** Rather than place an orders with Expedia via the Web page, I want to send a message to Expdia from my calendar program when I decide the dates and times I want to plan a trip.  I also want the calendar program to reserve a car, reserve a restaurant table, reserve a hotel, etc. 

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.

** It still assumes human interaction.

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

** Ok, what I meant was Web servers as they exist today.  The implications of whether or not Web services specifications require a re-write of Apache are almost as significant as whether or not they require a re-write of HTTP.  We are not proposing the one, let's be sure we don't propose (even implicltly) the other.

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

** Preserving existing investments cannot be secondary or the technology will not succeed.  The Corba Object Transaction Service could not re-invent Oracle or SQL Server, neither can Web services re-invent existing applications.

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

** Yes, but application servers are fundamentally 3-tier structured architectures designed for fanning in or multiplexing a large number of clients sharing a single resource such as a database.  They are not well suited architecturally to loosely-coupled message oriented interactions (despite the support in J2EE 1.3 for Mbeans, JMS, and the like), and this gets us back to the orignal point of the thread.  Web services, like the Web itself, are better suited to asynchronous message oriented interactions than to RPCs, and the asynchronous messaging paradigm grew to prominence precisely because of its benefits to integration -- the level of abstraction is better suited to bridging multiple technology domains than RPCs are.

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

** Sorry but I have to correc this statement ;-).  The integrator would just use CORBA for the integration as 65% of our customers already do.  No need for another middleware system. The motivation and fundamental use case for CORBA, as for Web services, is application integration.

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.

** Again, CORBA already solves this problem using IDL.  There is no 0(N^2) problem in this scenario.  You may not like the solution, and that's your perogative, but we can show you literally thousands of successful implementations of this solution.  

** Aside from that, however, this scenario is remarkably similar to what we're trying to achieve with Web services, which to me provides a more broadly adopted, more abstract, and more powerful integration solution.  Because of this I think that the two camps are not far apart.  I agree that we need code that maps each side into the Web data model, but I don't agree you need app servers to do it.  What we are fundamentally discussing is the "resource" issue.  Currently the way this works is that both sides develop a WSDL file that they can agree on (yes, I know this requires previous knowledge, but perhaps that is consistent with the Web services use case and motivation) and exchange SOAP messages conforming to the WSDL.  Each side is responsible for mapping the message into and out of the respective software system "domain" whether middleware or packaged application.

** I am really not sure what the compelling benefit is of defining Web service operations as resources instead of defining them within WSDL files.  I actually think if we can solve this one we can resolve almost the entire discussion.   

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)

** It is significant if those vendors have tested and certify interoperability with each other, as SOAP Builders have done, and WS-I is doing more broadly.

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.

** No, they have to write glue code to map the WSDL representation of the message into and out of the middleware systems, which has actually already been done, and works. 

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

** Sorry, I meant "non Web services" applications.  But it is more significant to bridge existing than new applications.  Web services will not succeed if they only work with new applications.

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

** See above -- the service, data, security, transaction, and user context can all be represented abstractly.

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

** Yes.

-- 
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 15:46:11 UTC