Thanks for great answer!
You should not assume that document/literal means you have to do "raw XML processing". Most SOAP implementations support automatic marshaling of SOAP messages and automatic transformation of XML into Java objects when using document/literal.
Why SOAP implementations do this? I can use another tools for transformation between XML and Java objects or database (Castor or Hibernate for example - it's better choise because them specialized for this task). So SOAP can be only transport for XML created by other specific tools.
It helps to understand some history. When SOAP 1.1 was first developed (circa 1999/2000), XML Schema was not yet finalized, so the SOAP spec authors had to define their own typing scheme: SOAP encoding. Now that the XML Schema data typing system is fully specified, SOAP encodingreally isn't necessary any more. Meanwhile, the web services community has been moving steadily aware from rpc/encoded style services to document/literal style services because rpc/encoded wasn't sufficiently specified,and therefore it caused many interoperability issues.
One of the primary goals of Axis 1.2 has been to implement much better
support for document/literal and the XML Schema type system -- which
also ensures compliance with the WS-I Basic Profile.
So, main goal of Axis 1.2 is supporting XML Schema instead of encoding? It's fine.
If your goal is
to enable rpc-style interoperability between heterogeneous systems,
then you should be using document/literal with the wrapped programming
style. (it simulates rpc).
One moment, please. Can I automaticaly give same functionality to my SOAP clients in rpc style and message style? Can you give me some examples of this?
Axis 2 is building on the XML Schema work done for Axis 1.2 and will also support more complex interaction styles, which requires support of asynchronous service invocations.
But -- you should not assume that SOAP works like a remote object facility (like RMI). SOAP does not support remote references. It does not manage remote objects for you, and that is not its intention. SOAP is fundamentally a message exchange system -- not a distributed object system. If you want heterogeneous distributed objects, then I suggest you use CORBA.
I know that SOAP is not best choise instead of RMI, CORBA and EJB, but I not need full distributed objects support and biggest part of my clients (for example Mozilla-based) knows only about HTTP, XML-RPC and SOAP.
Thanks Eugene
