Re: Asynchronous Web Services

"Newcomer, Eric" wrote:
> 
> Paul,
> 
>...
> 
> -- 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 problem is that after you read in the WSDL file, the
interoperability issues I am talking about *begin*. Not the
interoperability issues that you as a middleware vendor are expected to
solve, but the interoperability issues that the customer must deal with
to build their systems. Incompatible addressing schemes, MEPs, data
dictionaries, schemas, etc.

> The same can't be said of integrating CORBA 
> with .NET through IIS.

Integrating CORBA through .NET is actually not that interesting to me.
Integrating your CORBA purchasing application with your partner's .NET
inventory app is where I thought the benefits of Web Services come in.

i.e. integrating business objects.

In order to integrate business objects, we need to agree on much more
than SOAP specifies. 

There are two ways to reduce this cost. The first is to raise the level
of standardization. That's what REST proposes. We can (e.g.) standardize
on addressing models and data transfer primitives. The second way to
reduce the cost is to have ways to declare the things that were not
standardized (descriptive). That's what WSDL and XML Schema do. The
strategies are not mutually exclusive: you can do a little bit of
prescriptive and a little bit of descriptive. (for instance xml:lang is
prescriptive but it doesn't remove the need for XML Schemas)

The "agree in advance globally" strategy is massively cheaper than
"describe locally what decisions we've taken". It's exactly like the
difference between using a language we both already understand and
handing a
new language but then explaining it to you. Obviously the former
strategy is
faster, cheaper and less error prone. The latter strategy is only
appropriate for situations where the former *cannot* succeed. That is
not the case with the standardization of addressing models and
operations on the Web. We can standardize them and should.

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

and 

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

That is not the proposal. Method names should not go in URIs. Methods
names go in the HTTP request line as described by:

http://www.w3.org/TR/soap12-part2/#WebMethodFeature

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

No, but neither does the Corba Object Transaction Service *embed* any
special features for Oracle or SQL Server. They are components. You can
map them into the CORBA world if you want or not, if you don't want.
Similarly, I see no reason that a web services architecture needs to put
existing middleware or databases at the heart of the architecture. It
needs to be able to gateway to them. That is all.

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

First, CORBA is *much* more detailed and prescriptive than is SOAP/WSDL,
so I would expect CORBA-based integration to be much easier than
SOAP/WSDL integration. But even so, if CORBA solved web service's
problems then why would we need SOAP/WSDL? We are aiming for a *higher*
level of interoperability than you get from CORBA.

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

I agree you do not need app servers. A variety of tools are capable of
supporting the Web data model.

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

*This* is the O(N^2) solution that you denied above. I do not see how
this can be good enough.

I have to be careful here, however, REST does not make integration of
third and fourth parties completely free. Nevertheless, I can state
clearly what it does and doesn't standardize. It does standardize an
addressing model, which SOAP alone demonstrably does not. It does
standardize a list of primitive operations, which SOAP alone
demonstrably does not. It does standarize a data model, which SOAP alone
demonstrably does not. This is very analogous to the way that SQL
standardizes on the relational data model, the table-name addressing
model and the SELECT/INSERT/UPDATE/DELETE methods.

REST, like SQL, does not (and cannot) standardize the structure of your
particular data (XML or RDF schema in the case of REST, relational
schema in the case of SQL). Nevertheless, REST reduces the
"negotiation" of data model, addressing model and operation names from
O(N^2) to O(N) which will slash the price of integrations -- and in many
cases make explicit integration unnecessary.

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

It is not operations (verbs) that you represent as resources. It is
resources (nouns ) that you represent as resources. A travel itinerary
is
a resource. The current temperature in Arkansas is a resource. The stock
price for IONA is a resource. Roughly speaking, whatever would be an
object in CORBA is a resource in Web architecture. 

Whether you agree with all of REST or not, it seems to me that CORBA has
a fundamental advantage over the traditional web services architecture
in that (as far as I understand) in CORBA, any object can refer to any
other object, anywhere in the universe, through a single abstraction of
a reference which has first-class syntax in the protocol. SOAP (without
HTTP) lacks such a notion. This means that integrating two applications
must necessarily start "top down" with the entire service interface
rather than with an integration only of the (perhaps deeply embedded)
objects of actual interest.

For instance, in CORBA, you could define a purchase order interface:

interface po{
  do_something_with(arg1, arg2);
  ...
}

And then presumably if two services adopt this interface then a client
could hand a reference to a PO from one service to another with little
or no regard to the context of the PO (as long as authentication etc.
are correct). Conversely, in standard SOAP 1.1/WSDL 1.1 practice,
purchase orders would be handled through a "service" interface. The
service would be specified like this:

interface purchasing{
  do_something_with_po(po_number_as_UUID, arg1, arg2);
  ...
}

You can see this pattern in the UDDI SOAP interface (it uses UUIDs),
Hailstorm (it uses XPaths) and most examples on XMethods (which use
whatever they feel like). Can we at least agree that we lost some
standardization between CORBA with its universal object references and
SOAP 1.1 where every application invented its own? If so, then you can
understand the *nature* of the interoperability problems I am trying to
reduce. Not the low-level syntactic issues that prevent COM from talking
to CORBA, but the higher-level semantic issues. Integrating COM and
CORBA is relatively easy. IONA probably sells a product that just "does"
it. 

Integrating application data models, address models, operation names and
semantics is much harder, cannot be done "automatically" by a tool and
is more along the lines of where I think web services can go beyond what
we have today..

> 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 do not know what you mean by "...data ... can be represented
abstractly". The relational database has a relational data model. The
ORB and OODB have an object oriented model. I cannot imagine how SOAP or
WSDL can help you to bridge that gap. 

REST is not much help either, but it doesn't claim to solve that 
problem. REST is strong at bridging the gap between business-level 
applications, not the tools you use to implement those applications.

At the risk of repeating myself, REST is great for integrating the
Oracle-backed accounting application with the CORBA-backed sales
application, and less interesting for integrating Oracle with a CORBA
ORB.
-- 
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:50:23 UTC