Given the widespread adoption of simple object access protocol as a remote procedure call mechanism elsewhere in the industry, its not surprising that Sun Microsystems Inc. would bake SOAP into its upcoming Java 2 Enterprise Edition 1.4 specification.
However, the move might also be a quiet gift even to those working in all-Java environments because it provides a new, legacy-free way for J2EE application servers to interoperate.
J2EE publicity claims have long stressed the standardization and cross-vendor compatibility benefits that the J2EE testing process provides. While the process ensures that all J2EE-compatible products offer the same base level of functionality, it doesnt ensure that J2EE applications deployed on different application servers can interoperate.
In fact, even just redeploying the same application to another application server wont work in most cases because of differences in deployment descriptor files.
The troubles come when trying to do anything other than basic method invocation calls between two servers–for example, if one application server needs to call another with particular security credentials or with particular transaction semantics (if the caller and called server need to participate in the same distributed transaction).
And forget about building a cluster out of a heterogeneous mix of J2EE application servers: Clustering protocols are proprietary. Application server vendors have only recently gotten clustering interoperability working among their own application server products when running them on different hardware and operating system platforms.
These interoperability problems have a history that stretches back to the development process of Common Object Request Broker Architecture and the general lack of interoperability among different CORBA transaction services.
Now, the new SOAP standards work also has big holes—there is no way to transfer transaction semantics across a SOAP call, for example. There are also no standardized ways to pass security credentials, although there is extensive work going on in this area, and we believe it will be a solved problem by next year.
For the moment, SOAP does work for most simple interoperability problems. For more complex heterogeneous development efforts, we advise using a message queuing product at both sides of the link, as this will provide the security and transaction support necessary for more complex distributed applications.