Hello,
I assume that ManagedObject will be an interface defining the J2EEManagedObject. That AbstractManagedObject will be an implementation of ManagedObject, in other words J2EEManagedObject, and also an implementation of StateManageable.Create an AbstractManagedObject which implements ManagedObject and StateManageable.
If my assumptions are right, then it means that the 77 models/components should extend AbstractManagedObject. I said in a previous memo, that this is an implementation via inheritance of the problem. Even if inheritance is fine for the StateManageable requirements, I still believe that a composition will be more handy:
A component, which mirrors a specific J2EEManagedObject as defined by the specifications, creates the relevant J2EEManagedObject. This J2EEManagedObject is added to the 77 model. This additional layer, focused solely on the 77 requirements, can then be used to manage the J2EE applications. Up to the component to push the relevant pieces of information to its mirroring J2EEManagedObject. Up to the J2EEManagedObject to trigger the StateManageable operations on its related component.
I must have a look to the "Deployment" sub-project, but I assume that it is easy to trigger the creation of J2EEDeployedObject when a EAR is deployed. If this EAR contains a EJB, then an EJBModule is added to the previously created J2EEDeployedObject instance. If this EAR contains a Web-app, then a WebModule is created and also added to this J2EEDeployedObject. When I say "added", it could be via the standard POJO style. However if you prefer a JMX approach, one could modelize the 77 model via roles and relation types and let the relation service deals with it.
I have surely missed something, so anyone could explain me why we are not going into this direction?
Cheers, Gianny
_________________________________________________________________
ninemsn Extra Storage is now available. Get five times more storage - 10MB in your Hotmail account. Click here http://join.msn.com/
