Choosing a Remoting Architecture

With so many options available for remoting, you may wonder which solution to use. Thankfully, the decision is often quite clear for a given set of requirements. The Spring documentation provides quite a comprehensive discussion on how to choose a remoting implementation. We expanded on this here and you should certainly read it in conjunction with this discussion.

As the documentation states, RMI is a good solution for Java-to-Java solutions that require transmission of complex object models. Because RMI uses built-in Java serialization capabilities, creating a distributed application that transmits complex models across the network requires very little effort on your part. Using RMI in conjunction with Spring allows you to hide RMI-specific implementation details from your application, making it easier to plug in a new remoting architecture, should your requirements change.

RMI is also a good solution for you to use in heterogeneous environments because it allows you to communicate using CORBA IIOP, which is widely supported in a variety of other languages. Indeed, you may find that if you are deploying a new component into an existing environment, the architecture in place is CORBA. In this case, RMI is the best solution for your needs.

The biggest drawback of RMI is that it is not easily usable across HTTP, so if you need to communicate across the Internet or you need to punch through corporate firewalls easily, one of the other available architectures will better meet your needs.

The use of JAXRPC is usually mandated if you need to communicate across HTTP with systems written in other languages; this is because SOAP is widely supported. Remember, think twice before you adopt JAXRPC for Java-to-Java communication, because many more efficient solutions exist. Even if you feel that you may need SOAP support in the future, you can easily create a SOAP service for non-Java clients and use some other framework for your Java clients with both services backed by the same implementation class.

The Spring-native HTTP Invoker architecture is a good candidate for having Java-to-Java communication with Spring available at both ends, and because it builds on Java serialization, it is more than capable of transmitting complex object models between components.

Hessian and, to a certain degree, Burlap are excellent candidates for use in both homogenous and heterogeneous environments. You should prefer Hessian over Burlap unless XML is explicitly required, because Hessian performs much better than Burlap and is more widely supported outside of Java. In Java-to-Java environments, Hessian is a valid alternative to HTTP Invokers and may be the only solution if both ends are not using Spring. The only problem is that Hessian's serialization support is not quite as comprehensive as that provided by Java serialization, so for complex object models, you may be restricted to HTTP Invoker in order to have your application function correctly.



Pro Spring
Pro Spring
ISBN: 1590594614
EAN: 2147483647
Year: 2006
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net