different requirements of return 'this' in remoting
to kick off the offline discussion we've been having in private email ...
we're trying to determine the best way to handle 'this' on a return (or even parameter) in jboss remoting.
this is going to be subsystem dependent - JMX is fairly easy, and complete, since in JMX there is builtin indirection via ObjectName.
the next big subsystem is EJB.
my thought is in general that the DP (or interceptor, AOP class, etc.) would have to handle an invocation where this was referenced and replace the argument/return type with a proxy to something that could get back to the object reference. Adrian pointed out that this really is like an identifier than a memory addr - which I agree.
session bean it is a session ID
entity bean it is a primary key
jms it is a queue/topic, etc.
pojo it is a combination of equals/hashcode.
i'm wondering if we can't just use AOP to create an serialized object that basically contains an InvokerLocator (it's serializable and allows you to reach back to the remote machine regardless of transport) via JBoss Remoting invoke method. You could then on deserialization just create a clientinvoker back to yourself and pass the invocation object id (which would correlate back to "this") for every method invocation on the object - at that point it would be like normal DP semantics - except it would go across the transport back to the original object. So, this is a similar indirection like ObjectName, except you're forcing the indirection at runtime using a dynamic class that looks and feels like the real object - except that invocations are remoted. ALso, you could then use interceptors to cache method calls that don't need to travel across the wire, etc. in the usual manner.
in other words, basically make the calls look indirected like JMX does - and never really move the real object across the wire at all.
if you did something like this, when you instrumented the class you could just support casting it to Remoteable containing the locator which would construct a serializable object that could be shipped.
this does get a little tricky, since you have an object graph to worry about...
any thoughts?
