1 Reply Latest reply on Feb 22, 2003 3:46 AM by Adrian Brock

    different requirements of return 'this' in remoting

    Jeff Haynie Newbie

      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?

        • 1. Re: different requirements of return 'this' in remoting
          Adrian Brock Master

          What you describe is similar to how the ejb
          proxies work at the moment.

          There needs to be a mechanism such that
          when a client invokes a method on a remote
          object that returns a remote object
          it should use the same transport automagically.
          This is currently handled by the invoker proxy
          bindings for ejbs in 3.2 which are configured
          through meta data.
          i.e. I invoke an ejb using iiop, any returned
          remote object should use iiop.

          The remote objects also need to work in a HA
          environment when required.
          I think this is a related but separate concern to
          The remote object is then a collection of
          "identical" remote objects that talk to different
          nodes. The actual node used is based on a load
          balancing policy.
          So any "this" identifier must mean the same
          thing on all nodes.