Ollie, all,
=20
I've been carrying around the idea of HTTP-based remoting with Java =
serialization myself for quite a while, but not added it to Spring yet, =
focussing on the RMI invoker and Hessian instead. Good to see that =
there's interest in such an approach, and good to see that you're =
already prototyping a solution!
=20
Today I've played a bit with a simple implementation myself: an exporter =
and a proxy factory that simply serialize RemoteInvocation and =
RemoteInvocationResult objects over HTTP. Each is just about 50 lines of =
code currently. The exporter is a Spring web controller, just like =
HessianServiceExporter, participating in Spring's web framework. The =
proxy factory uses Commons HttpClient to access a specified service URL. =
Server and client side just interact with RemoteInvocation and =
RemoteInvocationResult objects.
=20
I've reused some of the code from Spring's RMI invoker mechanism here, =
which I already designed as generic remoting support. As with the RMI =
invoker, it's straightforward to add further context information to =
RemoteInvocation, by using an appropriate subclass: for example, user =
credentials. It's even the very same mechanism for both, just going =
through the RMI subsystem in the one case and serializing over HTTP in =
the other case!
=20
My current prototype is deliberately as simple as possible: It is =
designed as drop-in replacement for HessianProxyFactoryBean and =
HessianServiceExporter, using analogous configuration style (i.e. one =
exporter per service). The only Hessian feature it doesn't support yet =
is HTTP basic authentication - which you can define in Hessian to =
authenticate against the server (not necessarily for passing along =
application-specific user credentials).
=20
I'm surprised by how simple this was: It didn't take much more than two =
hours of initial coding and testing. Of course, it lacks support for =
retries and for progress bars at this point of time. Nevertheless, we =
certainly have similar goals here: So I suggest to merge our efforts. If =
we do retries in standard Spring, I'd like to add this in a generic =
fashion for all of Spring's supported remoting protocols. Progress bars =
is harder, as we need hooks into the streaming code here.
=20
I'm inclined to add my basic version of this to Spring 1.1 final, as it =
is so straightforward and so analogous to the existing Hessian / Burlap =
/ RMI invoker support. Retry strategies etc are definitely a 1.2 =
feature, though. My biggest issue is the naming, actually: =
"SimpleHttpServiceExporter" and "SimpleHttpClientInterceptor" don't =
sound too convincing. Any better naming suggestions? We should get =
serialization into the name, or use some acronym...
=20
What approach is your current prototype using? Do you use =
org.springframework.remoting.support.RemoteInvocation or some custom =
class for representing invocations? What do you think about the above =
approach, and about adding generic support for retry strategies across =
all of Spring's supported remoting protocols?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag von =
Oliver Hutchison
Gesendet: Mi 28.07.2004 08:52
An: spr...@li...
Betreff: RE: [Springframework-user] Spring-Hibernate using by Burlap
Andy, Seth, J=FCrgen, everyone,
I'd be happy to submit my own remoting implementation. It's lacking a =
bit of polish but I'm currently in the process of making it almost =
"drop-in" compatible with the Spring Hessian support code.
It's works in a similar way to Hessian (I've borrowed quite a few ideas =
and a bit of code - though it doesn't reimplement any of the Hessian =
API) but it's based on Java serialization rather than the custom =
serialization code in Hessian. What this means is that the only =
requirement on invocations is that all arguments are Serializable. This =
also gets rid of any problems with Hibernate collections assuming you =
*do* include the Hibernate jar on the client side ;-)
A nice little extra is the ability to retry invocations that fail =
because of IOException etc. The system allows you to register a =
RetryDecisionManager which can interrogate the invocation and the =
exception that has caused the failure. The remoting system also flags =
all exceptions to indicate whether they are recoverable or not and when =
it's not sure it also uses a "Maybe" recoverable status.
It certainly wouldn't be hard to add some hooks for a progress bar. Andy =
what did you have in mind?
Anyway If you're interested please let me know and I'll clean up the =
code a bit and send it through to the list.
Ollie
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user
|
