avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <m...@leosimons.com>
Subject RE: v4 jmx kernel
Date Mon, 02 Apr 2001 18:54:24 GMT
> >> I think we need to formally define a new object to make things
> easier. The
> >> Services JSR calls this object the "Embeddor" (sp?).
> >
> >Where do I find that?
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_111_jsf.html

just read the white paper...

> >> Essentially it is
> >> responsible for
> >> * creating MBeanServer
> >> * starting MBeanServer
> >> * creating kernel
> >> * starting kernel
> >>
> >> and optionally for
> >> * creating deployer
> >> * using deployer to deploy from default location(s)
> >> * creating default logEngine
> >> * setting up default log for kernel
> >> * loading kernel services (aka facilities)

from the white paper:

The JSF is designed to be embedded within a larger context.  For example, an
implementation of the JSF could be embedded within a database, an
application server, or a router.  For this reason, an embeddor is needed to
communicate with the external environment and provide the information it
obtains to the services that it hosts.
At a functional level, the role of the embeddor within the framework is to:
1.  Create an instance of a kernel.
2.  Initialize the kernel.
3.  Start the kernel.
4.  Stop the kernel.
5.  Destroy the kernel.

An embeddor can monitor the life cycle of the kernel using functionality
that is built into the kernel.


The Role of Embeddors
Embeddors are the “shells” that create a server environment within a device.
Any embeddable device that can support a JVM can contain an embeddor.  The
embeddor interacts with both the physical device and the application that it
contains.  It extracts information from the physical environment and
communicates it to the applications on an “as needed” basis.  It is also
capable of performing the same role within diverse software environments.
At the system level, an embeddor is an object.  It maintains a peer
relationship with the process or application that is the externally visible
server.  The embeddor can be as simple as a “wrapper” that exposes the
functionality of the internal components or as complex as a database server
within which a server is embedded.
Because embeddors must interact with the device on which they reside, they
must be customized to conform to that physical environment.  In addition,
embeddors that are used with the JSF must provide the following basic
?	Provide an interface between the kernel and the external environment.
?	Provide the kernel with the configuration URL.
?	Provide the means to create instances of the kernel.


The Kernel’s Core Management Facilities
The JSF kernel provides fundamental functionality to the other framework
components.  Each type of component receives a different set of capabilities
from the kernel.  The kernel exposes several disparate interfaces to limit
the capabilities that are exposed to each component type.
The kernel is responsible for creating and maintaining the following
framework elements:
?	The JMX MBean Server
?	The JNDI Registry
?	The Service Manager
?	The Configuration Manager
?	The Log Manager
?	The Deployment Manager
?	The Security Manager


If we want to follow this model, the Embeddor should not be
responsible for MBeanServer, Deployer, etc.

After reading the white paper (which sounds pretty good
except for the requirment that the Log Manager should
handle internationalisation issues), I'm wondering what
the plans are for Avalon in the long run.
It seems to me that Avalon itself would become mostly
redundant somewhere in the future, phoenix would become
a JSF implementation, and cornerstone would provide
some default JSF Services, should we choose to adapt
to JSF.
What are the thoughts on this? Should we start preparing
for this change?

(it would, among other things, require some significant
changes to the lifecycle stages:

1	Resolution
2	Initialization
3	Start
4	Reconfiguration
5	Stop
6	Destruction

The following sections describe each of these phases.

Phase 1:  Resolution
During the service resolution phase, the following activities occur:
1	The service’s manager (ServiceManager) is instantiated.
2	The service’s class loader is created.
3	The service’s service context is created.
4	The packages that can be provided by the service are exported to the
5	All configured children are taken through their resolution phase.

Phase 2:  Initialization
During the service initialization phase, the following activities occur:
1	A check is made to ensure that the kernel can provide all required
2	The service implementation is instantiated.
3	The service is registered with the service registry.
4	The service is provided with its service context
5	The service is asked to initialize itself (if it has implemented the
Initializable interface).
6	All of the service’s children are initialized.
7	Monitoring of the service’s configuration URL is initiated.

Phase 3:  Start
During the service start phase, the following activities occur:
1	Logical references to dependent services are resolved.
2	The service is asked to start itself.  During this request a service may
acquire references to its dependent services.
3	All of the service’s children are started.

Phase 4:  Reconfiguration
During the service reconfiguration phase, the following activities occur:
1	The service’s reconfigureService() method is invoked.
2	The service uses the configuration manager provided through the service
context to retrieve a configuration object.
3	The configuration object is used to obtain the configuration information.
4	The service applies the new configuration information to itself.

Phase 5:  Stop
During the service stop phase, the following activities occur:
1	The service is asked to stop itself.
2	All of the service’s children are stopped.
3	All dependent services acquired by the service are released.

Phase 6:  Destruction
During the service destruction phase, the following activities occur:
1	If the service is running, it is stopped.
2	All of the service’s children are stopped.
3	All dependent services acquired by the service are released.")



	About LSD  = new PersonalInfo();
	LSD.name("Leo Simons");
		http://www.leosimons.com, // personal website
		http://www.atfantasy.com, // fantasy RPG portal
		http://www.the-sign.nl    // web-design company
	] );

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message