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/
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
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.
