[Springframework-developer] Initial remoting support

[<jue...@we...>]

Hi everybody,

I've just introduced an initial version of remoting support for Spring, =
featuring 3 protocols:
- Caucho's Hessian (a slim HTTP-based binary protocol, =
http://www.caucho.com/hessian)
- Caucho's Burlap (a slim HTTP-based XML protocol, =
http://www.caucho.com/burlap)
- transparent RMI (using a RemoteInvocationHandler to allow for non-RMI =
service interfaces).

The goal is to achieve transparent remoting via service interfaces =
without obvious remote dependencies (like extending java.rmi.Remote or =
throwing RemoteException):
- To access a remote service, a client bean can simply get a bean =
reference implementing the service interface from a proxy factory bean.
- To export a service, there are service exporter implementations, =
exporting a plain remote-unaware service implementation that it gets as =
bean reference implementing the service interface.

For Hessian and Burlap, the exporters are web MVC controllers, allowing =
for exporting any bean as remote service to HTTP URLs just like a normal =
MVC controller - even within the same ControllerServlet. For transparent =
RMI, the exporter is a non-web bean that can export any bean via RMI on =
the same machine, taking the RMI name of the object and the port of the =
registry as parameters (and implictly starting a registry if there isn't =
one yet).

This means that remote services can be integrated into Spring =
applications just like normal beans or any other resource (compare =
JndiDataSourceBean and JndiSessionFactoryBean), getting treated as =
standard Java interfaces, given to beans as bean references. Exporting =
is as easy as possible too, taking an existing interface-implementing =
bean and making it available via the respective protocol. Changing the =
protocol, or exporting a service via multiple protocols, doesn't affect =
the service implementations at all!

BTW, I've already used Hessian successfully in a production system. For =
Java-to-Java service calls without sessions, all 3 protocols should work =
nicely. RMI has the advantage that it can transport any serializable =
Java object without hassle - Hessian had some quirks in this respect =
formerly. But Hessian and Burlap are significantly simpler to setup, and =
work on a web server with any firewall. They even support HTTP basic =
authentication (see username and password properties of the respective =
proxy factory beans).

Of course, an obvious remoting solution is missing: SOAP-based web =
services. This shouldn't be too hard to add, but such toolkits are far =
more complex to setup and integrate, especially Axis. I wouldn't use =
SOAP for Java-to-Java communication anyway, as it's fairly bloated. I =
prefer Hessian: slim, and extremely simple to setup. But the nice thing =
about our support is that protocol choices aren't mutually exclusive: =
Export a bean both via Hessian and transparent RMI, if you like, or with =
SOAP when there will be support for it.

Regards,
Juergen

P.S:
Hessian and Burlap are open source under the Apache license. Their =
releases are aligned with and included in Resin releases, but they're =
also available standalone - for example they work nicely with Tomcat. =
And just in case you're wondering, hessian-3.0.1.jar contains both =
Hessian and Burlap.


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG