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
> <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.
>
I could define a hashmap in XML, the problem comes with translating it
onto a specific platform. If I limited it to string to string mappings
it's easily done but most people find HashMap's of that nature too
strict - i.e. it's not mapped tightly enough to their platform to be useful.
i.e. One trades flexibility of expression away for interoperability.
> 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.
>
Not sure I agree with that. They're doing what they do with many a
framework and just expecting it to "handle" such things and when the
framework handles only a part of the problem as they see it, they get
confused. They either want it fully handled or not handled at all - a
clear boundary.
> 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.
>
I can't agree with that - IMHO, it's because you defined a narrow set of
acceptable things to pass over the wire and have a standardized protocol
for doing the passing. That's what's given you interoperability and it
can be implemented in many ways including over XML but also with a
binary protocol or whatever.
I'm also not sure where you'd fit CORBA into this? Are we saying that's
a distributed object system because it doesn't use XML or for some other
reason?
> 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.
>
And that's the rub - we're stacking up a number of different exceptional
behaviours and expecting developers to remember which apply under which
circumstances on which platforms.
Dan.
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/
