Re: [service-orientated-architecture] Re: XML Tuple Spaces as Middleware

Wed, 12 Apr 2006 09:36:22 -0700

This is absolutely correct, and fundamentally one of the biggest problems we have today in the software industry - the fact that Web services specifications are misunderstood and not implemented correctly.  JAX-RPC is the kind of "poster child" for this.  I have personally told people from Sun that it was a mistake to view SOAP as an RPC like RMI, and that it was a mistake to view Web services in general as "external technologies" to J2EE, creating APIs for each spec as if it were a database, directory, or security service external to the core.  Web services should have been implemented as system level APIs not application level APIs. 
 
The tendency to want to automatically convert XML data types into language specific data types is understandable but misguided, and moreover impractical since it's basically impossible.  The mismatch between binary compiled languages with data types designed as if the language were the only language to be used and a text based document markup language is too great to ever be made transparent.
 
The answer is that you have to do some coding to parse and interpret the XML correctly.  This is extra work for developers but the benefit is standardization across programming languages, operating systems, middleware systems, database systems, messaging systems, and packaged applications.
 
Eric

----- Original Message ----
From: Anne Thomas Manes <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, April 11, 2006 9:17:16 AM
Subject: Re: [service-orientated-architecture] Re: XML Tuple Spaces as Middleware

The primary difference between RMI and SOAP is that RMI works using pass by reference, and SOAP works using pass by value. I discussed these differences lightly in my blog entry, "Web services are not distributed objects". See http://atmanes.blogspot.com/2005/03/web-services-are-not-distributed.html.

Someone from the Axis user community provided more specific information here:
http://marc.theaimsgroup.com/?l=axis-user&m=114091729003011&w=2

The point is that developers need to recognize that SOAP is not a distributed object system, and that although the JAX-RPC API provides a programming model that is very similar to RMI, the communications system acts more like JMS. In one of the earlier posts in this thread, Dan Creswell lamented that the automatic seralization systems in most SOAP frameworks handle only a limited subset of primitive types. In fact, most frameworks can easily handle all primitive types, and they can easily handle structures and arrays. They run into trouble when you start trying to automatically serialize language-specific collection classes, such as Java Hashmaps and .NET Datasets.

The fact that developers assume that a SOAP toolkit should be able to automatically handle language-specific collection classes is indicative of the fact that they view SOAP as equivalent to the native distributed object system. They are approaching the tools from the wrong perspective.

Rule #1 in SOAP interoperability -- start with the XML Schema type system, not with the language type system. If you define your interface using XML Schema and WSDL rather than trying to generate the WSDL from a Java class, interoperability works much better. And that's because SOAP is an XML messaging system, not a distributed object system.

The serialization systems can handle all primitive types, and they can handle most structures and arrays automatically. Some systems get a bit challenged when using some of the more complex schema structures, such as <choice> or <union> groups -- but worst case, it deserializes these structures into DOM.

Anne

On 4/8/06, patrickdlogan <[EMAIL PROTECTED]> wrote:
> It feels very much like RMI, although it's a document exchange
> system rather than a distributed object system. Developers should
be
> aware of that subtle distinction (although many aren't -- leading
to
> a variety of bad practices).

I would be interested in more information about why it "feels like
RMI" but acts like a "document exchange system".

Why does it feel one way, but act another?

If it feels a certain way, why should developers be aware that it is
acting some other way?

What has led to this confusion, what bad practices have resulted, and
what can be done to correct them?

This seems critical knowledge toward success with SOAP. Is it boiled
down somehwere, or why not, for better results with SOAP?

Thanks,
Patrick










Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
YAHOO! GROUPS LINKS



Reply via email to