Boston meeting notes: START HERE - Executive overview

[adrian.brock]

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

[starksm64]

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.

[starksm64]

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.

[adrian.brock]

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.

[adrian.brock]

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.