J Aaron Farr wrote:
On Fri, 2003-06-27 at 21:19, Stephen McConnell wrote:
I think its achievable.
In fact Aaron's appliance extension provides a good entry point for plugging in of a JMX extension without having to sub-class DefaultAppliance. This deals with the component side of things - but we will need something closer to appliance itself something like an ApplianceListener and ApplianceEvent which get registered during the appliance initialization phase. This would address the need for registration of the appliance as a managable entity before deployment of components.
ApplianceEvent and ApplianceListener, eh?
So when would events be fired? On deployment? On access? I agree that some way of registering appliances would be a nice feature.
In principal it should be possible to launch a container based on deployment model that is supplied to it. Currently Merlin builds that deployment model as part of container startup (based on all of the XML - kernel.xml, block.xml, xinfo, xservice, config, etc.). However - I'm thinking ahead towards a scenario where XML is just one of multiple sources for the declaration of a deployment scenario.
Let's assume that the entire deployment model is provided as a single serializable meta-data instance. Secondly, let's assume that the a kernel is already registered with a JMX server. Thirdly, let's assume that the kernel is provided with the meta-data (deployment scenario) by the JMX server (i.e. an administrator has finished playing with a persistent deployment scenario and is requesting scenario execution by a container).
On execution of the scenario the container would need to fire back to the server the progress relative to scenario execution.
The type of events would include:
1. scenario deployment event
signals the initiation of scenario deployment
during which appliance instances are instantiated
and associated relative to services and dependencies
imported and exported by the respective component
types 1.1. appliance creation event
1.2. appliance assembly event2. scenario runtime event
runtime events signaling the deployment of components,
suspension, redeployment, and decommissioning of
components 2.1 appliance deployment event(s)
a) component instantiation event
b) component logging event
c) component context event
d) ...
2.2 appliance suspension event(s)
2.3 appliance redeployment event(s)
2.3 appliance decommissioning event(s)
a) component stop event
b) component disposal event3. scenario decommissioning
during which appliance instance associations are
disassembled and destroyed 3.1 appliance disassembly event
3.2 appliance disposal eventIf we combine the above information with a remotely accessible appliance, we have something that starts to look *really* interesting.
Cheers, Steve.
Ummm, thinking, thinking ...
Me too. :P
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
