Anand Natrajan wrote:
SOAP is always going to be slower than RMI, no question. But by adoptingSOAP is not necessarily that much slower than RMI - see my performance results at http://www.sosnoski.com/presents/cleansoap/results.html, for example.
SOAP as a facade for my application, do I not gain language-independence,
flexibility, loose coupling and document-orientation?
You do gain a certain level of language-independence just from using SOAP, and much more from using doc/lit as opposed to rpc/enc. You don't really gain loose coupling with most of the current SOAP frameworks in Java, though. The problem is that with current SOAP frameworks for Java the wire format (and the schema that goes into the WSDL) is tightly coupled to the structure of your Java classes. If you change your classes, the XML also changes. Beyond that, many types of application data structures just can't be handled in any reasonably way by the existing frameworks.
The next generation of SOAP frameworks for Java are going to be addressing these issues. In the case of JAX-RPC 2.0 they'll be addressed by using JAXB 2.0 for converting between XML and Java. Axis 2 is also likely to support a variety of data binding implementations, and I'll probably be taking my own JibxSoap further in the next couple of months.
What's wrong in thinking "code-centric" (don't like that term, but I'llThe problem with this approach is that you're exporting your object model. This works fine for simple applications where you've got clients that only talk to one web service and services that only work with one client. Beyond that level it starts to get really messy, since the same data may be used with multiple services. If each one exports its own object model you then have to write code to shuffle the data from one model to another. This approach becomes completely unmanageable when you get to complex data structures (like many forms of enterprise data) that may involve dozens of components.
continue usage for now) when designing my application and my API, but then
generating a SOAP version of the API to gain all of those advantages? The
only significant risk I see is that when designing my "code-centric" API, I
may use language-specific artifacts, e.g., hashes in Perl, or Sets in Java.
These structures may not translate well into other languages. But as long as
I keep _that_ best practice in mind, I don't see an issue.
If you're going to be making web services a serious part of your future development you're better off developing standard data representations (in the form of XML schemas) that can be shared across services. That way applications which are working with the same type of data will be using compatible formats for the XML exchanges, even though their internal data structures may be different. Of course, you won't gain the most benefit from this approach until you can use a SOAP framework that lets you to decouple the XML format from your data structures. Even if you can't do it with the current production frameworks, though, you can still plan for this flexibility in the future.
- Dennis
-- Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Consulting http://www.sosnoski.com Redmond, WA 425.885.7197
