JDMK represents a framework with corresponding tools, based on the
JavaBeans specification [#!sun:97!#], for the development of
management applications and management agents. The base components of
the architecture are shown in figure .
M-Beans (Managed Beans) are Java objects implementing the intelligence and the functionality of an agent.[JDMK Architecture]JDMK Architecture [r] They act as a representative for one or more managed objects (MOs). In order to use JDMK services or communication resources M-Beans have to be registered at the so called Core Management Framework (CMF) . Only registered Beans can be accessed from outside the CMF. The CMF together with its M-Beans represents the management agent.
C-Beans (Client Beans) can be generated from M-Beans using a special compiler. C-Beans are proxy objects for remote M-Beans. Together with their adaptors and additional management functionality they form the manager. An agent is also able to register C-Beans with its CMF. By doing this, the agent becomes a manager for that agent which implements the corresponding M-Beans. The strict separation between the manager and the agent role in protocol-based management architectures is therefore abolished in JDMK. An Adaptor implements a special kind of a protocol, it is an interface for the CMF and hence for the agent. At present RMI, HTTP, HTTPS (HTTP over SSL), IIOP, SNMP and a so called HTML adaptor, which represents a web server, are available. This concept allows to communicate with the same JDMK agent by means of different protocols. It is not necessary to change the functionality or the code of the agent, the only thing to do is to register a different adaptor. Of course it is possible to use more than one adaptor at the same time.
[JDMK Management Applet (M-Let) Service]JDMK Management Applet (M-Let) Service [l] Besides the base components of JDMK several services and tools exist to simplify the development of management applications and agents. Services relevant for the project are briefly explained in the following paragraphs.
Beans may be registered with the aid of Repository
Service either as volatile or persistent within the CMF. The
Discovery Service
is used to detect
all active CMFs. To determine the properties and methods which are supported by an
M-Bean the Metadata Service,
can be used.
The Class and Library Server
serves as a local or remote repository for class
files and libraries. M-Let, Launcher and Bootstrap Service are used
for dynamic extension of agents, for update mechanisms and for
bootstrapping. The M-Let Service (Management Applet
Service)
offers the possibility to download and
configure M-Beans dynamically (cf. figure ). For this
purpose a new HTML tag (<MLET>) is defined. First M-Let
Service loads a HTML page from an URL from which it can obtain all the
necessary information about the Beans to load. Then M-Let Service is
able to download the implementation classes of the M-Beans and to
instantiate them. Afterwards, the M-Let Service must register them
with the CMF. It is also possible to put version information inside
an (<MLET>) tag and thus use the M-Let Service for versioning.
The Bootstrap Service simplifies the distribution and
instantiation of JDMK agents. This service is used to download
implementation classes. Therefore the Bootstrap Service initializes
the CMF, starts the M-Let Service, loads the necessary classes,
initializes, registers and starts all required M-Beans and services
of the agent.
Besides mogen compiler which is used to create C-Beans there is mibgen compiler for developing a JDMK based SNMP agent for a device. If SNMP-MIB files are available for a managed device, mibgen is able to use them to create M-Beans representing the MIB. The M-Beans have to be enlarged with functions e.g., implementing access to resources of the managed system.