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.