4 Replies Latest reply on Feb 9, 2005 10:29 AM by Adrian Brock

    Boston meeting notes: START HERE - Executive overview

    Adrian Brock Master

      AOP Container overview Assumptions and descisions
      ClassData model Descriptions of classes
      JoinPoint model How to dispatch invocations
      Two phase container construction Work out what a container requires then create it when dependencies are satisfied
      Annotations We will use annotations as our metadata model
      Advice construction Deploying and configuring aspects/interceptors
      Container module tasks The spi for common metadata
      AOP module tasks The container implementation
      MicroContainer module tasks Changes to the lifecycle/configuration to use the agreed comon metadata model
      System module tasks Integrating the jmx kernel service lifecyle
      Aspects module tasks Integration of AOP/MicroContainer
      Sundry tasks The TODO

        • 1. Re: Boston meeting notes: START HERE - Executive overview
          Scott Stark Master

          So the notion of the metadata service and its relation to the aspects such as the ClassData, and Annotation pieces does not clearly jump out at me after reading through the overview links.

          Its clear that there is a competing view between the simple development metadata model that wants to move the definitions close to the code as typified by annotations, and the admin metadata model that wants an abstracted topdown view of across deployments and even servers.

          Some natural topdown management views of this metadata service are:
          * All metatadata introduced by level: instance, class, invocation, session, deployment, server, cluster, federation.
          * The settings for a piece of metadata by level.
          * meta-metadata views that allow for filtered views like all metadata affecting endpoint settings(port/interface), transactional sematics, locking semantics, security settings, etc.

          • 2. Re: Boston meeting notes: START HERE - Executive overview
            Scott Stark Master

            Another overview I would like to see us work to is an interaction diagram type of description for an ejb3 type of deployment. The key thing is how various layers of the micro-container affect the deployment, runtime behavior, redeployment, and management of the ejb3 component and its associated application.

            The overriding concept I want to keep in the back of everyone's mind is the ability to control components from an admin perspective. We have historically been good at supporting micro-manipulation of components, but not so good at taming the resulting complexity when admin type of operations are to be imposed on the deployed components.

            • 3. Re: Boston meeting notes: START HERE - Executive overview
              Adrian Brock Master

              We only touched upon this meta-metadata service during our discussions, defining the
              requirements for integration with the MC and what is currently provided for AOP.
              i.e. at the component level

              I think it would have been presumptous of us to try to imagine all the use cases
              that such a service would provide when it is was not our immediate concern
              and requires input from others (JBoss IDE, admin console, etc.).
              The AOP IDE already has a lot of these views at the component level.

              We simply noted that such a service was required.

              One of the good things about annotations is that they can themselves be annotated,
              e.g. we are doing this to identify which annotations define dependencies.

              But in general this is a cross cutting concern easily handled by annotations.
              Annotations do more than define dependency injection or aspects.
              e.g. You want to define all objects that configure entry points into the system
              which the GateKeeper service needs to know about:

              @EntryPointConfiguration
              public class JNDIBinding
              {
              public void setTarget(Object o) {}
              public void setBinding(String binding) {}
              //etc...
              @OpenTheGates :-)
              public void bind() throws Exception
              {
               new InitialContext().bind(binding, o);
              }
              }
              


              Equally this could be retrofitted to a bean instance using MC config
              if it wasn't defined on the class.
              <bean bean="JNDIBinding">
               <annotation name="EntryPointConfiguration"/>
              // etc.
              </bean>
              


              Additionally, some of the query mechanisms already exist in the MicroContainer,
              e.g. the ability to get "DependsOnMe" for the transaction manager.

              Also on the MC roadmap is the ability to define subsystems, subservices
              that allow the grouping of components into a single "Object" for management.
              The use cases for this are:
              1) I want to stop JMS (subsystem)
              2) I want to stop that EJB (also stops any internal subservices like the jndi binding
              or state replicator)

              But as Bill keeps reminding me, we need to work in baby states and iterate.
              i.e. we need to make sure we have sure foundation before we try to build on top of it.

              • 4. Re: Boston meeting notes: START HERE - Executive overview
                Adrian Brock Master

                I would be happy to discuss what such a service will look like
                as long as we have all the interested parties contributing their use cases.
                IDE, admin-console, portal, JMX, etc.

                This is probably best done a separate thread.