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

[Keith Harrison-Broninski]

Anne, you're right to say that starting from the XML Schema is more likely to buy you SOAP interoperability - but it won't buy you application interoperability, will it.  If anything, it reduces the chances of achieving it. After all, most SOAP messages are intended for processing by software, not humans, which means that at some point they must be unmarshalled from XML into program language objects.  Deserializing into DOM is not enough, unless the only thing you ever want to do with the data you receive is stick it untouched into an XML repository for posterity.  And in the general case, there is not enough information in an arbitrary XML schema to describe how this unmarshalling should be done - so relying on a schema will only lead to ambiguity, and consequent "misunderstanding" between sender and receiver (unless, that is, both ends are using the same code libraries, in which case the argument for SOAP over a distributed object system starts to look rather weak. as Gregg continually reminds us).  It is a disconnect similar to that between objects and relational data structures. If you are set on using SOAP in preference to a distributed object approach, one approach that will give you genuine interoperability is to adopt a specific dialect of XML, a dialect that is sufficiently limited and formal to remove the disconnect.  For example, XMI - the standard XML representation of objects defined using OMG MOF.  Otherwise, you may as well resign yourself to having the same code at each end - and may find yourself wondering about the value-add of SOAP in the first place. -- All the best Keith http://keith.harrison-broninski.info Anne Thomas Manes wrote: 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  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.