11 Replies Latest reply on Oct 22, 2002 4:52 PM by bill.burke

    Stateful Aspects needed (use cases)

    bill.burke

      Sorry for coming in late to this discussion. Didn't know this forum existed. (I hate forums anyways.)

      Examples of Stateful Aspects:

      - "Nuke" pattern. The state of a SFSB is replicated at the client in the event of a total cluster failure.

      - Idempotent methods. I.E. hashCode, etc...already in EJB client interceptors. I also want to be able to define this for any MBean or EJB method as well in the future.

      - Clustering. As Marc already said. The client proxy maintains list of nodes to loadbalance or failover on.


      The way I see it is you have Singleton interceptors. One instance for all aspects. And interceptor per proxy.

      Idempotent and "Nuke" are examples of instance per proxy.

        • 1. Re: Stateful Aspects needed (use cases)

          > Hi Hiram,
          >
          > The point I was trying to make was that JMX isn't
          > based on interfaces or methods.
          > Interfaces aren't dynamic because the client holds a
          > copy.
          >

          yes. what does that mean then?? Are you saying JMX cannot be used to implement an aspect??

          > StandardMBean is a convenience to generate
          > MBeanInfo from an interface.
          >
          > > This sounds like he sets up a interceptor list per
          > > method, is this right?
          >
          > Mostly the interceptors and lists can be shared
          > although I don't think it is implemented at the
          > moment.
          > Generally the config is done once and the objects
          > aren't big.
          >
          > It kind of makes sense for JMX because things are
          > configured at operation/attribute level.
          >

          yes. this could be done for aspects also.

          > You don't need a fully featured interceptor stack
          > covering all possibilites on every invocation.
          >
          > The slow part is determining the invocation flow
          > for an operation/attribute. But this is probably
          > faster than filtering at every interceptor? I've
          > not measured it.
          >

          Right.. the trade off is increased memory useage vs. increased CPU usage. Not sure which will win. In an aspect case, multiple proxys would share the same interceptor stack config. The question is how many interceptor stack configs do you think would be running in a typical app?? Perhaps the approach to the problem should be a configuration option??

          Regards,
          Hiram

          > Regards,
          > Adrian

          • 2. 3853952
            bill.burke

            Another question:

            Are you using the precompiler? Or load time? or both?

            Bill

            • 3. Re: Stateful Aspects needed (use cases)
              marc.fleury

              Where the state lives is a good topic

              There are cases where we need the state to be given by the client and cases where we need the state in the interceptor.

              Ex: the READ-AHEAD interceptor for CMP
              the scenario is simple the read-ahead value is dictated by use cases. Meaning that a given client may want to display 20 lines, another one 50 etc. This is clearly in many framework how the "bucket" is done. Right now this data is only given through the static configuration of the interceptor in the container.

              We need to have the information passed in the Invocation. Bill, I believe there are two ways programmatic ways for the client to do that.
              1- the client casts his proxy to the generic (ClientProxy) interface. This interface needs to be added to the dynamic proxy at construction time. Then that interface supports

              clientProxy.setValue("READ-AHEAD", 20);

              the implementation of the ClientProxy is in the first client interceptor or maybe its own client interceptor and it calls

              invocation.setValue("READ-AHEAD", 20);

              this value is sent to the server or just passed on trhough the invocation down the chain. The server side CMP implementation recieves the "Invocation", he can then do

              invocation.getValue("READ-AHEAD")

              and do stuff with it. So really it means that while we would maintain the configuration as is, meaning that we would support the basic read-ahead setting as it is today, it allows for overridding of that property BY THE CLIENT.

              2- The interceptor gives an interface. That interface is the (ReadAhead) interface that has setReadAhead(int value) in its signature. I believe that Hiram already has support for that interface declaration. The difference here is that we do need 2 interceptors when we go for client-server distributed. The client side interceptor would do the invocation.setValue() call and the server side one is the same as above in point 1 meaning it retrieves the value from the Invocation itself.

              The state I am talking about here is almost "configuration" state. The state you mention in the clustering Bill, is clearly state that comes from the system. That we keep the state in interceptor or a central hashmap is irrelevant in this case. It is a matter of coding style and I believe that both coding styles (field variable vs invocation retrieval) are needed.

              When the client passes the value (not applicable to the clustering stuff) then the invocation needs to be it. When we are talking about the clustering values then I am ok with both coding practices.

              That being said, I like the idea of having the configuration centrally visible on a running system. We assemble the container and we keep a central hashmap of all the values. We can put that hashmap on the JMX bus for that logical container and modify/monitor it centrally which would be nice even for programmatic reasons. You can then modify the configuration without have to hold a direct reference to it, think administration purposes.

              Let me give you an example. Option A/B/C/D let's say that we want to modify the option and maybe even modify the period of refresh for D. Today this is very static. We have that variable in an interceptor today, it is the commit-option field in the cache interceptor but the point is HOW DO WE GET AT THAT INTERCEPTOR in a standardized way.

              Here is a thought. I believe that we can separate the 2 issues so that they become orthogonal. Let's assume we store that configuration for the whole stack of interceptors in a central hashmap. It will mean that we can change the commit option of the container through the administration interface. If you look at that configuration it will say
              DISTRIBUTED=true;
              commit-option=D;
              refresh-rate=20;
              etc etc

              then that map has an adapter that retrieves the setters from the interceptors. So that cache interceptor has setCommitOption(). The adapter knows that the interceptors wants the "commitOption" call so when the value changes the adapter that holds the pointer to the interceptor (that adapater is built at deployment time) will call the interceptor with
              interceptor.setCommitOption(map.get("commit-option");

              the mapping of names to method needs to be something dumb like "remove - lowercase everyone and set the values".

              This way we solve the problem of coding style while retaining the centralized approach to configuration. This is uber powerful. One of the applications of this is if we have a cluster running we can call the configuration on the whole cluster easily.

              it is good infrastructure.

              Do we see eye to eye on this one?

              • 4. Re: Stateful Aspects needed (use cases)
                bill.burke


                > and do stuff with it. So really it means that while
                > we would maintain the configuration as is, meaning
                > that we would support the basic read-ahead setting as
                > it is today, it allows for overridding of that
                > property BY THE CLIENT.
                >

                Yes that is cool. So that is a reason to keep state at the proxy level for configuration.

                > today, it is the commit-option field in the cache
                > interceptor but the point is HOW DO WE GET AT THAT
                > INTERCEPTOR in a standardized way.
                >

                How do we get at an interceptor in a standard way? Redeploy it! Modify the .aspect xml file and redeploy it. For JMX we would need an XML editor MBean that wrapped the .aspect xml file. You understanding what i'm saying? The JMX XML Editor MBean would be attached to the .aspect xml file and would have a save button.

                I'm sick of MBean config being non-persistent. Its our last hurdle before becoming a real light-weight component model.

                >
                > then that map has an adapter that retrieves the
                > setters from the interceptors. So that cache
                > interceptor has setCommitOption(). The adapter knows
                > that the interceptors wants the "commitOption" call
                > so when the value changes the adapter that holds the
                > pointer to the interceptor (that adapater is built at
                > deployment time) will call the interceptor with
                > interceptor.setCommitOption(map.get("commit-option");
                >
                I like this adapter idea too. We just need to make sure that everything is layered here. We want the Aspect framework to be lightweight and usable as a library, a JAR file.

                > the mapping of names to method needs to be something
                > dumb like "remove - lowercase everyone and set the
                > values".
                >
                > This way we solve the problem of coding style while
                > retaining the centralized approach to configuration.
                > This is uber powerful. One of the applications of
                > this is if we have a cluster running we can call the
                > configuration on the whole cluster easily.
                >
                > it is good infrastructure.
                >
                > Do we see eye to eye on this one?
                >

                Yes centralized configuration is good. But you should be able to override.

                At Iona we had the idea of configuration scopes. Scopes could inherit off of one another. So if your current scope didn't have a config value defined it looked to the parent for the value.

                We could have configuration scopes for our Aspects.

                Invocation-Config-Scope extends Proxy's-config-scope extends Global-config-Scope.

                So whenever an aspect needs config info it asks the InvocationScope->Proxy's Scope->GlobalScope.

                So a user can modify configuration on different levels. For the duration of the method call, for a specific reference to a object, or globally for all.

                You get what I'm saying?

                Bill

                • 5. Re: Stateful Aspects needed (use cases)
                  hchirino

                  do you need them statefull per proxy object or per target object??

                  Per proxy will be easy to implement support for.. per tartget object would be harder.

                  Regards,
                  Hiram

                  • 6. Re: Stateful Aspects needed (use cases)

                    I don't think an interceptor per target makes sense.

                    If the interceptor needs to get configuration based
                    on the object id it will delegate to some
                    configuarion object.

                    e.g. Do I have access to a Bank Account? or
                    Can I use Management's expensive laser printer?
                    Will be in some central security repository. The state
                    for the interceptor is just the link to the repository.

                    Regards,
                    Adrian

                    • 7. Re: Stateful Aspects needed (use cases)

                      Bill,

                      One point on JMX.

                      Until the generic invocation stuff is done,
                      the jmx interceptors cannot use the aspect processing.

                      The aspect processing is based on methods in an
                      interface.

                      Only for a Standard MBean do you have an interface.

                      JMX is operations and attributes defined in MBeanInfo.
                      The starting point is an already detyped invocation.

                      Because JMX is already detyped, it doesn't have any
                      problem with adding new operations/attributes on the fly.

                      Also, Juha's new implementation allows for separate
                      invocation flows for each operation/attribute,
                      rather than filtering the interceptors.

                      Regards,
                      Adrian

                      • 8. Re: Stateful Aspects needed (use cases)
                        hchirino

                        So bill, are you ok ith just per proxy interceptors??

                        • 9. Re: Stateful Aspects needed (use cases)
                          hchirino

                          > Until the generic invocation stuff is done,
                          > the jmx interceptors cannot use the aspect
                          > processing.

                          Right.. But aspect can use a jmx interceptor. I have allready commited an aspect interceptor that acts like a JBoss Invoker (delegates all method calls to the "invoke" method on a MBean.

                          We could also develop a DynamicMBean which delegates to the InvocationHandler of an aspect. So, I see alot of ways aspects can interop with JMX.

                          > The aspect processing is based on methods in an
                          > interface.
                          >

                          Kinda true.. the aspect interceptors support adding interfaces to the DP. But the aspect interceptors can process all method method calls regardless of the interface the method is defined on.

                          > Only for a Standard MBean do you have an interface.
                          >
                          > JMX is operations and attributes defined in
                          > MBeanInfo.
                          > The starting point is an already detyped invocation.
                          >
                          > Because JMX is already detyped, it doesn't have any
                          > problem with adding new operations/attributes on the
                          > fly.
                          >

                          You can change the interceptor chain on aspect also. The only problem is if this chain exposes different interfaces, a new DP needs to be created for the aspect object.

                          > Also, Juha's new implementation allows for separate
                          > invocation flows for each operation/attribute,
                          > rather than filtering the interceptors.
                          >

                          This sounds like he sets up a interceptor list per method, is this right?

                          Regards,
                          Hiram

                          > Regards,
                          > Adrian

                          • 10. Re: Stateful Aspects needed (use cases)
                            hchirino

                            > Hi Hiram,
                            >
                            > The point I was trying to make was that JMX isn't
                            > based on interfaces or methods.
                            > Interfaces aren't dynamic because the client holds a
                            > copy.
                            >

                            yes. what does that mean then?? Are you saying JMX cannot be used to implement an aspect??

                            > StandardMBean is a convenience to generate
                            > MBeanInfo from an interface.
                            >
                            > > This sounds like he sets up a interceptor list per
                            > > method, is this right?
                            >
                            > Mostly the interceptors and lists can be shared
                            > although I don't think it is implemented at the
                            > moment.
                            > Generally the config is done once and the objects
                            > aren't big.
                            >
                            > It kind of makes sense for JMX because things are
                            > configured at operation/attribute level.
                            >

                            yes. this could be done for aspects also.

                            > You don't need a fully featured interceptor stack
                            > covering all possibilites on every invocation.
                            >
                            > The slow part is determining the invocation flow
                            > for an operation/attribute. But this is probably
                            > faster than filtering at every interceptor? I've
                            > not measured it.
                            >

                            Right.. the trade off is increased memory useage vs. increased CPU usage. Not sure which will win. In an aspect case, multiple proxys would share the same interceptor stack config. The question is how many interceptor stack configs do you think would be running in a typical app?? Perhaps the approach to the problem should be a configuration option??

                            Regards,
                            Hiram

                            > Regards,
                            > Adrian

                            • 11. Re: Stateful Aspects needed (use cases)

                              > Are you saying JMX cannot be used to implement an
                              > aspect??

                              I was actually talking about the opposite.

                              Using the aspect layer to implement the MBean wrapper.
                              The interface exposed at the proxy would be DynamicMBean
                              or ModelMBean.

                              But as I said before, the interceptors would have to work
                              with operation/attribute Strings rather than Method
                              objects.

                              > Perhaps the approach to the problem should be a
                              > configuration option??

                              It's best to keep it simple :-)

                              off-topic - interface flows
                              The multiple flows are more interesting when
                              we use aspects to do multiple inheritance.
                              If we have aspects A, B, C the flows can
                              be different for each, rather than the concatenation.
                              We don't need to go through A and B to get to C.

                              Regards,
                              Adrian