4 Replies Latest reply on Oct 23, 2002 9:32 PM by Adrian Brock

    Remote Aspects

    Bill Burke Master

      I think maybe we need to not think of the client stack and the server stack as one aspect but rather as 2 different aspects.

      The Client aspect is an aspect with no target object. Just an interceptor on the end that makes an invocation on a remote Invoker.

      The Invoker takes the invocation and invokes on an MBean. The MBean itself is an Aspect and this is where the server interceptors live.

      Now, when the server needs to change the interceptor chain on the client, the Invoker throws an exception with the new interceptor stack embedded in the exception. (Much like a LocationForward in CORBA.). The Client aspect catches this exception, recreates the interceptor stack and re-invokes the method call.

      All in all I think it is very important to have an InvocationResponse object as Adrian talked about. I've been meaning to put this in for a long time.

      Bill

        • 1. Re: Remote Aspects
          Hiram Chirino Expert

          > I think maybe we need to not think of the client
          > stack and the server stack as one aspect but rather
          > as 2 different aspects.

          Yes.. They are 2 different aspects. And the types of interceptors you place on those aspects are different (you can allow serverside interceptors to have access to the JMX bus).

          >
          > The Client aspect is an aspect with no target object.
          > Just an interceptor on the end that makes an
          > invocation on a remote Invoker.
          >

          I can agree on that.. Then I think we need to add another create method to the AspectFactory which accepts the following args: (String aspectName, Class []targetInterfaces).
          This is so that the proxy object also exposes the targetInterfaces even though it has a null targetObject.

          Or Perhaps we can use the targetObject as our key to lookup the right serverside aspect???

          > The Invoker takes the invocation and invokes on an
          > MBean. The MBean itself is an Aspect and this is
          > where the server interceptors live.
          >

          We should also try to decouple the server-side aspects from JMX as much as possible. The Factory or Deployer that creates the server-side aspect should be the one that registers the aspect in JMX. Use some reflection technique to implement the MBean for the aspect (perhaps even implement it via another aspect).

          If we we can do this, then we have a chance at allowing applications to creating a WHOLE container stack via an aspect definition. (They would just need another set of Factories that did not use JMX). Some applications don't NEED JMX managment.

          > Now, when the server needs to change the interceptor
          > chain on the client, the Invoker throws an exception
          > with the new interceptor stack embedded in the
          > exception. (Much like a LocationForward in CORBA.).
          > The Client aspect catches this exception, recreates
          > the interceptor stack and re-invokes the method
          > call.
          >

          Ok.. I can buy this but I don't think this applies at the generic aspect level. This needs to just be at the invoker level. The last interceptor in the client aspect will be the invoker client. That interceptor will need the abililty to chanage the aspect definition for the proxy.

          > All in all I think it is very important to have an
          > InvocationResponse object as Adrian talked about.
          > I've been meaning to put this in for a long time.
          >
          > Bill

          • 2. Re: Remote Aspects
            Adrian Brock Master

            > > Now, when the server needs to change the
            > interceptor
            > > chain on the client, the Invoker throws an
            > exception
            > > with the new interceptor stack embedded in the
            > > exception. (Much like a LocationForward in
            > CORBA.).
            > > The Client aspect catches this exception,
            > recreates
            > > the interceptor stack and re-invokes the method
            > > call.
            > >
            >
            > Ok.. I can buy this but I don't think this applies
            > at the generic aspect level. This needs to just be
            > at the invoker level. The last interceptor in the
            > client aspect will be the invoker client. That
            > interceptor will need the abililty to chanage the
            > aspect definition for the proxy.
            >

            I agree with that. An InvocationResponse should not be
            used in the base invocation chain as the return value.

            But the invocation handler needs some way of knowing
            to retry the invocation with the new chain.
            And other client/server interceptors need some way of
            using it as well.

            My preferred solution is to allow an
            optional InvocationResponse object in the invocation.
            The invokers would be responsible for returning it
            to the client and updating the client's copy of the
            invocation with any response object.
            For local invocation, no work is required.

            This would allow things like Marc's invocation level
            logging where the client can retrieve all the server
            logging for an invocation.

            Regards,
            Adrian

            • 3. Re: Remote Aspects
              Hiram Chirino Expert

              > > Ok.. I can buy this but I don't think this
              > applies
              > > at the generic aspect level. This needs to just
              > be
              > > at the invoker level. The last interceptor in the
              > > client aspect will be the invoker client. That
              > > interceptor will need the abililty to chanage the
              > > aspect definition for the proxy.
              > >
              >
              > I agree with that. An InvocationResponse should not
              > be
              > used in the base invocation chain as the return
              > value.
              >

              cool.

              > But the invocation handler needs some way of knowing
              > to retry the invocation with the new chain.

              Perhaps the invoker needs to throw a special "retry exception" which the IH catches and does a retry???

              > And other client/server interceptors need some way
              > of
              > using it as well.
              >
              > My preferred solution is to allow an
              > optional InvocationResponse object in the
              > invocation.
              > The invokers would be responsible for returning it
              > to the client and updating the client's copy of the
              > invocation with any response object.
              > For local invocation, no work is required.
              >
              > This would allow things like Marc's invocation level
              > logging where the client can retrieve all the server
              > logging for an invocation.

              I like this. Make it more generic. Have a Map that holds response objects. client side interceptors could communicate server side interceptors with every method call by placing objects in request and response maps.

              How expensive is it to create a new Map for each method call??

              Regards,
              Hiram

              >
              > Regards,
              > Adrian

              • 4. Re: Remote Aspects
                Adrian Brock Master

                Maps are expensive.

                It isn't the actual Map, more all the Map.Entry objects
                that have to be constructed.

                Regards,
                Adrian