Differences between revisions 10 and 11
Revision 10 as of 2006-07-13 17:56:52
Size: 24425
Editor: SanketSharma
Comment:
Revision 11 as of 2009-09-20 22:12:44
Size: 24483
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
1. [#Revision_History Revision History][[BR]]
2. [#Disclaimer Disclaimer and Legal Information][[BR]]
3. [#About About this document][[BR]]
 3.1 [#Purpose Purpose][[BR]]
 3.2 [#Audience Intended Audience][[BR]]
 3.3 [#Notations Notations and Conventions][[BR]]
 3.4 [#Structure Structure of this document][[BR]]
4. [#Assumptions Assumptions and Dependencies][[BR]]
5. [#Analysis High Level Design][[BR]]
 5.1 [#Overview JMX Overview][[BR]]
 5.2 [#Component_Strcuture Derby JMX Component Structure][[BR]]
 5.3 [#Individual_Components Individual Components] [[BR]]
  5.3.1 [#Management_Service Management Service][[BR]]
  5.3.2 [#Management_MBeans Management MBeans][[BR]]
 5.4 [#Class_Diagram Class Diagram][[BR]]
 5.5 [#Component_Diagram Component Diagram][[BR]]
6. [#Service_Startup Management Service Startup] (Under developement)[[BR]]
7. [#Use_Cases Use Cases] (Under developement)[[BR]]
8. [#Security Security Considerations] [[BR]]
9. [#Issues Issues] [[BR]]
10. [#Geronimo Apache Raiders and fishes of glass (Geronimo and GlassFish)] (Under developement)[[BR]]
11. [#Refernces References][[BR]]
1. [[#Revision_History|Revision History]]<<BR>>
2. [[#Disclaimer|Disclaimer and Legal Information]]<<BR>>
3. [[#About|About this document]]<<BR>>
 3.1 [[#Purpose|Purpose]]<<BR>>
 3.2 [[#Audience|Intended Audience]]<<BR>>
 3.3 [[#Notations|Notations and Conventions]]<<BR>>
 3.4 [[#Structure|Structure of this document]]<<BR>>
4. [[#Assumptions|Assumptions and Dependencies]]<<BR>>
5. [[#Analysis|High Level Design]]<<BR>>
 5.1 [[#Overview|JMX Overview]]<<BR>>
 5.2 [[#Component_Strcuture|Derby JMX Component Structure]]<<BR>>
 5.3 [[#Individual_Components|Individual Components]] <<BR>>
  5.3.1 [[#Management_Service|Management Service]]<<BR>>
  5.3.2 [[#Management_MBeans|Management MBeans]]<<BR>>
 5.4 [[#Class_Diagram|Class Diagram]]<<BR>>
 5.5 [[#Component_Diagram|Component Diagram]]<<BR>>
6. [[#Service_Startup|Management Service Startup]] (Under developement)<<BR>>
7. [[#Use_Cases|Use Cases]] (Under developement)<<BR>>
8. [[#Security|Security Considerations]] <<BR>>
9. [[#Issues|Issues]] <<BR>>
10. [[#Geronimo|Apache Raiders and fishes of glass (Geronimo and GlassFish)]] (Under developement)<<BR>>
11. [[#Refernces|References]]<<BR>>
Line 33: Line 33:
[[Anchor(Revision_History)]] <<Anchor(Revision_History)>>
Line 39: Line 39:
[[Anchor(Disclaimer)]] <<Anchor(Disclaimer)>>
Line 47: Line 47:
[[Anchor(About)]] <<Anchor(About)>>
Line 49: Line 49:
[[Anchor(Purpose)]] <<Anchor(Purpose)>>
Line 52: Line 52:
[[BR]] <<BR>>
Line 54: Line 54:
[[Anchor(Audience)]] <<Anchor(Audience)>>
Line 56: Line 56:
[[BR]] <<BR>>
Line 58: Line 58:
[[Anchor(Notations)]] <<Anchor(Notations)>>
Line 60: Line 60:
[[BR]] <<BR>>
Line 74: Line 74:
[[BR]] <<BR>>
Line 76: Line 76:
[[Anchor(Structure)]] <<Anchor(Structure)>>
Line 79: Line 79:
[[BR]] <<BR>>
Line 81: Line 81:
[[Anchor(Note)]] <<Anchor(Note)>>
Line 84: Line 84:
[[BR]] <<BR>>
Line 86: Line 86:
[[Anchor(Assumptions)]]
[[BR]]
<<Anchor(Assumptions)>>
<<BR>>
Line 90: Line 90:
[[BR]]
[[Anchor(Analysis)]]
<<BR>>
<<Anchor(Analysis)>>
Line 95: Line 95:
   As the project is about adding JMX features to Derby, I thought it would greatly benifit the reader if the High Level Design is accompanied by a brief overview of JMX architecture. So this section gives the reader a bird's eye view of the JMX world without getting into any deatails. For a detailed reading of JMX, please refer to the resources and links mentioned in [#References References]

[[Anchor(Overview)]]
   As the project is about adding JMX features to Derby, I thought it would greatly benifit the reader if the High Level Design is accompanied by a brief overview of JMX architecture. So this section gives the reader a bird's eye view of the JMX world without getting into any deatails. For a detailed reading of JMX, please refer to the resources and links mentioned in [[#References|References]]

<<Anchor(Overview)>>
Line 105: Line 105:
[[BR]] <<BR>>
Line 108: Line 108:
[[BR]] <<BR>>
Line 112: Line 112:
  ''' a.1) Standard MBeans: ''' Define and implement their own management interface. Simplest to design and implement.[[BR]]
  ''' a.2) Dynamic MBeans: ''' Implement a predefined interface but expose their management interface at run time. These are the most flexible.[[BR]]
  ''' a.3) Model MBeans: ''' Are the most powerful, configurable and flexible. They only provide a generic dynamic MBean which can be customized to expose any management interface and instrument any resource at runtime.[[BR]]
  ''' a.4) Open MBeans: ''' Are dynamic MBeans that use basic data types and are self described.[[BR]]

 ''' b.) Notification Model: ''' The specification provides a notification model based on the Java event model that lets applications register and recieve notifications of all events that occur in a MBean of its interest.[[BR]]

 ''' c.) Metadata classes: ''' The specification define classes that are used for both introspection of standard MBeans and self description of all dynamic MBeans. Together, these classes describe the management interface of a MBean in terms of Attributes, Constructors, Operations and their Parameters. [[BR]]

 For a detailed discussion of these topics, please refer to the resources mentioned at the end of this section.[[BR]]
[[BR]]
 '''2. Agent Level: ''' The agent level provides specifications for implementing Agents. Agents are JMX components that expose the functionality of MBeans to outside applications. This level builds upon instrumentation level to define a standardized agent to manage JMX managable resources. Agents are usally located on the same machines as the MBeans they control, although, this is not a requirement. The JMX agent consists of following to components:[[BR]]
  ''' a.1) Standard MBeans: ''' Define and implement their own management interface. Simplest to design and implement.<<BR>>
  ''' a.2) Dynamic MBeans: ''' Implement a predefined interface but expose their management interface at run time. These are the most flexible.<<BR>>
  ''' a.3) Model MBeans: ''' Are the most powerful, configurable and flexible. They only provide a generic dynamic MBean which can be customized to expose any management interface and instrument any resource at runtime.<<BR>>
  ''' a.4) Open MBeans: ''' Are dynamic MBeans that use basic data types and are self described.<<BR>>

 ''' b.) Notification Model: ''' The specification provides a notification model based on the Java event model that lets applications register and recieve notifications of all events that occur in a MBean of its interest.<<BR>>

 ''' c.) Metadata classes: ''' The specification define classes that are used for both introspection of standard MBeans and self description of all dynamic MBeans. Together, these classes describe the management interface of a MBean in terms of Attributes, Constructors, Operations and their Parameters. <<BR>>

 For a detailed discussion of these topics, please refer to the resources mentioned at the end of this section.<<BR>>
<<BR>>
 '''2. Agent Level: ''' The agent level provides specifications for implementing Agents. Agents are JMX components that expose the functionality of MBeans to outside applications. This level builds upon instrumentation level to define a standardized agent to manage JMX managable resources. Agents are usally located on the same machines as the MBeans they control, although, this is not a requirement. The JMX agent consists of following to components:<<BR>>
Line 125: Line 125:
  ''' a.) MBean Server: '''Acts a registry for all MBeans. All management operations applied to resource have to go through the MBean server. The MBean server provides a standardized interface for querying, instantiating and accessing MBeans. Any resource that needs to be managed from outside the JVM, needs to be registered with the a MBean Server.[[BR]]   ''' a.) MBean Server: '''Acts a registry for all MBeans. All management operations applied to resource have to go through the MBean server. The MBean server provides a standardized interface for querying, instantiating and accessing MBeans. Any resource that needs to be managed from outside the JVM, needs to be registered with the a MBean Server.<<BR>>
Line 127: Line 127:
[[BR]]
  '''b.1.) Dynamic loading''' services allow agent to instantiate MBeans using Java classes and native libraries dynamically loaded from the network.[[BR]]
  '''b.2.) Monitoring capabilities''' for attribute values in MBeans notifies the listeners upon detecting certain conditions.[[BR]]
  '''b.3.)''' A Timer service that can send notifications at predetermined intervals. [[BR]]
  '''b.4)''' A relation service that defines relations between MBeans and maintains the relations. [[BR]]

 '''3. Distributed Level: ''' The Distributed services level provides interfaces for implementing JMX managers. As defined by the specification, this level defines management interfaces and components that can operate on agents. Typicall, these services can expose the management view of a JMX agent and its MBeans by mapping their semantic meaning into constructs of data rich protocol e.g. HTML or SNMP. [[BR]]
<<BR>>
  '''b.1.) Dynamic loading''' services allow agent to instantiate MBeans using Java classes and native libraries dynamically loaded from the network.<<BR>>
  '''b.2.) Monitoring capabilities''' for attribute values in MBeans notifies the listeners upon detecting certain conditions.<<BR>>
  '''b.3.)''' A Timer service that can send notifications at predetermined intervals. <<BR>>
  '''b.4)''' A relation service that defines relations between MBeans and maintains the relations. <<BR>>

 '''3. Distributed Level: ''' The Distributed services level provides interfaces for implementing JMX managers. As defined by the specification, this level defines management interfaces and components that can operate on agents. Typicall, these services can expose the management view of a JMX agent and its MBeans by mapping their semantic meaning into constructs of data rich protocol e.g. HTML or SNMP. <<BR>>
Line 136: Line 136:
[[BR]]
[[Anchor(Component_Structure)]]
<<BR>>
<<Anchor(Component_Structure)>>
Line 144: Line 144:
http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/resizedHLD.jpg {{http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/resizedHLD.jpg}}
Line 154: Line 154:
[[BR]] As I said earlier, the basic design idea for adding extensions to Derby is to have an Model MBean per service that is loaded in Derby. Each MBean will manage a logical aspect of the system. Please note that the diagram is only intended to give the user a overview of the architecture. Several details, including modules and services have been intentionally left out to highlight the architecture.

[[BR]] The choice of this architecture was based upon following factors:

 1.) Miniumum changes to exisiting code base are required due to the use of ModelMBeans. Model MBeans keep a reference of the object they are managing and implement all operations as callbacks. While reviewing the code, I felt that quite a lot existing functionality can very easily be exposed through Model MBeans.[[BR]]
 [[BR]]
<<BR>> As I said earlier, the basic design idea for adding extensions to Derby is to have an Model MBean per service that is loaded in Derby. Each MBean will manage a logical aspect of the system. Please note that the diagram is only intended to give the user a overview of the architecture. Several details, including modules and services have been intentionally left out to highlight the architecture.

<<BR>> The choice of this architecture was based upon following factors:

 1.) Miniumum changes to exisiting code base are required due to the use of ModelMBeans. Model MBeans keep a reference of the object they are managing and implement all operations as callbacks. While reviewing the code, I felt that quite a lot existing functionality can very easily be exposed through Model MBeans.<<BR>>
 <<BR>>
Line 162: Line 162:
[[BR]]
[[Anchor(Individual_Components)]]
<<BR>>
<<Anchor(Individual_Components)>>
Line 166: Line 166:
 The following components are identified for the JMX extensions:[[BR]]  The following components are identified for the JMX extensions:<<BR>>
Line 175: Line 175:
[[BR]]

[[Anchor(Management_Service)]]
<<BR>>

<<Anchor(Management_Service)>>
Line 179: Line 179:
[[BR]]
[[Anchor(Management_MBeans)]]
<<BR>>
<<Anchor(Management_MBeans)>>
Line 183: Line 183:
   // Code after the Agent has been started //[[BR]]

 [[BR]]
   // Code after the Agent has been started //<<BR>>

 <<BR>>
Line 188: Line 188:
[[BR]]
[[Anchor(Class_Diagram)]]
<<BR>>
<<Anchor(Class_Diagram)>>
Line 193: Line 193:
http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/ClassDiagram.jpg


[[BR]]
[[Anchor(Component_Diagram)]]
{{http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/ClassDiagram.jpg}}


<<BR>>
<<Anchor(Component_Diagram)>>
Line 203: Line 203:
http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/ComponentDiagram.jpg

[[Anchor(Service_Startup)]]
{{http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/ComponentDiagram.jpg}}

<<Anchor(Service_Startup)>>
Line 216: Line 216:
[[Anchor(Use_Cases)]] <<Anchor(Use_Cases)>>
Line 221: Line 221:
[[Anchor(Security)]] <<Anchor(Security)>>
Line 225: Line 225:
[[BR]]
[[Anchor(Issues)]]
<<BR>>
<<Anchor(Issues)>>
Line 228: Line 228:
 * ''' Version Incompatibilities: ''' Currently, most of Derby's source is built against Java version 1.3, only code that is inherantly dependant on 1.4 is compiled against javac version 1.4. However, JMX support is available only on Java versions 5 (1.5) and above. Reference implementations of JMX are available for JMV version 1.3 and 1.4 as seperate download (Please see the discussion below for JMX implementations). Ant scripts will have to be modified in this case to support the building of JMX modules. [[BR]]
 * ''' Modules.properties: ''' The modules.properties file uses derby.env.jdk.<tag>={1|2|4} to identify which modules are supported under which JVM environments. Since JMX requires 5 and above, we need to extend support for 5 and maybe 6 as well. (Not very sure about this) [[BR]]
 * ''' JMX Implementations: ''' Anothe design issue it the choice of JMX implementations. Besides the one available as part of Sun JDK 1.5 and above there are several other open source implementations available. Each has its own advantages and disadvantages. The following is a list of the most apparant ones:[[BR]][[BR]]
 '''1. Sun JDK 1.5 and above: ''' Requires no additional Jars to depolyed with the client. Leads to smaller footprint. One the negetive side, it will always require Derby to run on JRE 1.5 and above. My not be a good choice as some implementations might be using earlier versions.[[BR]][[BR]]
 '''2. Sun JDK prior to version 1.5: ''' Sun's references implemenation (available as a seperate jar download) for JDK versions 1.3 and above. Applications running on JVM 1.3 and 1.4 will need to download install this jar.[[BR]][[BR]]
 ''' 2. XMOJO Project: ''' This JMX supports JDK version 1.2 and above, which means it imposes no additional JDK requirements. Hoewever, additional JARs will to be deployed on the client for them to use JMX. They can either be bundled with Derby or can be seperately installed on client. Another point to note is that XMojo itself requires two more jars to be present (xalan.jar, crimson.jar, and jaxp.jar and org.mortbay.jetty.jar)[[BR]][[BR]]
 ''' 3. Apache Commons Modeller framework: ''' The commons modelling framework is another Apache project developed under the Jarkarta project. Although, it is not an implementation in itself, it facilitates writing of MBeans in a big way and future updates are easily managed. The Metadata for MBeans is specified in an XML file which is parsed to gernerate MBeans.It is know to work with all major JMX implementations.[[BR]][[BR]]
 ''' 4. MX4J:''' Another very popular JMX framework know to work with JDK 1.3 and above. It also supports automatic generation of ModelMBeans using XDoclets. Needs additional jars to be deployed. Supports HTTP adapters for access via HTTP. [[BR]][[BR]]

 My recommendation is to use Sun's reference implementation with the commons modelling framework.[[BR]]

[[Anchor(Geronimo)]]
 * ''' Version Incompatibilities: ''' Currently, most of Derby's source is built against Java version 1.3, only code that is inherantly dependant on 1.4 is compiled against javac version 1.4. However, JMX support is available only on Java versions 5 (1.5) and above. Reference implementations of JMX are available for JMV version 1.3 and 1.4 as seperate download (Please see the discussion below for JMX implementations). Ant scripts will have to be modified in this case to support the building of JMX modules. <<BR>>
 * ''' Modules.properties: ''' The modules.properties file uses derby.env.jdk.<tag>={1|2|4} to identify which modules are supported under which JVM environments. Since JMX requires 5 and above, we need to extend support for 5 and maybe 6 as well. (Not very sure about this) <<BR>>
 * ''' JMX Implementations: ''' Anothe design issue it the choice of JMX implementations. Besides the one available as part of Sun JDK 1.5 and above there are several other open source implementations available. Each has its own advantages and disadvantages. The following is a list of the most apparant ones:<<BR>><<BR>>
 '''1. Sun JDK 1.5 and above: ''' Requires no additional Jars to depolyed with the client. Leads to smaller footprint. One the negetive side, it will always require Derby to run on JRE 1.5 and above. My not be a good choice as some implementations might be using earlier versions.<<BR>><<BR>>
 '''2. Sun JDK prior to version 1.5: ''' Sun's references implemenation (available as a seperate jar download) for JDK versions 1.3 and above. Applications running on JVM 1.3 and 1.4 will need to download install this jar.<<BR>><<BR>>
 ''' 2. XMOJO Project: ''' This JMX supports JDK version 1.2 and above, which means it imposes no additional JDK requirements. Hoewever, additional JARs will to be deployed on the client for them to use JMX. They can either be bundled with Derby or can be seperately installed on client. Another point to note is that XMojo itself requires two more jars to be present (xalan.jar, crimson.jar, and jaxp.jar and org.mortbay.jetty.jar)<<BR>><<BR>>
 ''' 3. Apache Commons Modeller framework: ''' The commons modelling framework is another Apache project developed under the Jarkarta project. Although, it is not an implementation in itself, it facilitates writing of MBeans in a big way and future updates are easily managed. The Metadata for MBeans is specified in an XML file which is parsed to gernerate MBeans.It is know to work with all major JMX implementations.<<BR>><<BR>>
 ''' 4. MX4J:''' Another very popular JMX framework know to work with JDK 1.3 and above. It also supports automatic generation of ModelMBeans using XDoclets. Needs additional jars to be deployed. Supports HTTP adapters for access via HTTP. <<BR>><<BR>>

 My recommendation is to use Sun's reference implementation with the commons modelling framework.<<BR>>

<<Anchor(Geronimo)>>
Line 243: Line 243:
[[BR]] <<BR>>
Line 245: Line 245:
[[BR]] <<BR>>
Line 247: Line 247:
[[BR]] <<BR>>
Line 251: Line 251:
[[Anchor(References)]] <<Anchor(References)>>
Line 254: Line 254:
JMX tutorial sesssion as presented at the 2001 O'Reilly Enterprise Java Conference http://www.oreillynet.com/pub/d/858 [[BR]]
JMX tutorial at Sun: http://java.sun.com/j2se/1.5.0/docs/guide/jmx/tutorial/tutorialTOC.html [[BR]]
JMX tutorial sesssion as presented at the 2001 O'Reilly Enterprise Java Conference http://www.oreillynet.com/pub/d/858 <<BR>>
JMX tutorial at Sun: http://java.sun.com/j2se/1.5.0/docs/guide/jmx/tutorial/tutorialTOC.html <<BR>>

THIS PAGE IS BEING UPDATED

Apache Derby

Draft Proposal

High - Level Design for JMX Extensions

Document Contents

1. Revision History
2. Disclaimer and Legal Information
3. About this document

4. Assumptions and Dependencies
5. High Level Design

6. Management Service Startup (Under developement)
7. Use Cases (Under developement)
8. Security Considerations
9. Issues
10. Apache Raiders and fishes of glass (Geronimo and GlassFish) (Under developement)
11. References

1. Revision History

Version

Version Information

Date

Modified by

Comments

1.0

Document Created

Tuesday, June 27, 2006

Sanket Sharma

Comments are welcome!

Copyright 2005 The Apache Software Foundation or its licensors, as applicable.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

3. About this Document

3.1. Purpose

  • This document identifies the components and the interfaces required for implementing management extensions to Apache Derby in a modular fashion. The document is not intended to describe detailed implementation associated with a specific module.


3.2. Intended Audience

  • The intended audience includes a wide community of those interested in developing monitoring and management modules for the Apache Derby.


3.3. Notation Conventions

  • The documentation set uses the following conventions.


  • Convention

    Explanation

    Example

     Monospace 

    Filename

     MyFile.java 

    Directory Names and Path Names

     \MyDir\MyDir2 

    Commands and Command line options

     ecl-02 

    Method names, Classes, Interfaces in running text

    Use the  createService()  method to...

    Parameters or other placeholders

     doSomething(int val1, int val2) 

     Monospace bold 

    User input

     [C:] dir 

    Italics

    Emphasis; Introducing or defining terms

    The term access takes as its subject

    [ ]

    Optional Items

     -Fa[c]  Indicates these command-line options:  -Fa  and  -Fac 

    {|}

    Choice of one item from a selection of two or more items.

    -aX{K | W | P} Indicates these command-line options:

     -aXK 

     -aXW 

     -aXP 


3.4. Structure of this document

  • This section is divided into seven sections. Section one to four provide basic information about legal stuff and notational conventions used in this document and can be skipped over without loss of any details. Section five begins with a very high level architectural overview of JMX and JMX enabled applications followed by architectural overview of Derby. This section also identified how JMX components will be plugged into existing architecture and describes indivisual JMX components in greater detail.
  • Section 6 describes the startup of management servicees. Section seven describe possible use cases and section eight discusses the issues that might aries following a JMX implementation. Section nine talks about behaviour of Derby JMX when embedded inside JMX enabled frameworks like GlassFish or Geronimo. Section ten enlists the sources of information for this document.


3.5. A Note

  • This document is still evolving! If you feel this document lacks some detail which ought to have been here, please feel free to drop me a mail !


4. Assumptions and Dependencies


  • It is assumed that the reader is fairly experienced with Java and know what classes, interfaces, attributes, events, constructors are. A basic understanding of how introspection works will be helpful in understanding of JMX MBeans. It is assumed that the reader is familiar with JMX although, for those who are not, a brief introduction has been included with this document.


5. High Level Design

  • As the project is about adding JMX features to Derby, I thought it would greatly benifit the reader if the High Level Design is accompanied by a brief overview of JMX architecture. So this section gives the reader a bird's eye view of the JMX world without getting into any deatails. For a detailed reading of JMX, please refer to the resources and links mentioned in References

5.1. JMX Overview

  • The Java Management extensions (also called the JMX specification) define an architecture, design patterns, APIs, and the services for applications and network management & monitoring in the Java programming language. Java Management Extensions, also known as JMX, were developed as Java Community Process Java Specification Request (JSR) 3 to address management needs of applications written in Java while being compatible with existing management technologies like SNMP etc. JMX specification provides Java developers across all industries means to instrument Java code, create smart Java agents, implement distributed management middleware and managers, and smoothly integrate these solutions into existing management and monitoring systems. The JMX specification describes the JMX architecture in three distinct layers, each with well defined functions and interfaces to communicate with other layers. A JMX application can be viewed as the following stack: Each of these three layers are described below:


  • 1) The Instrumentation Layer: This is the layer that is closest to the resource being managed. A resource is managable if it is writtent in Java or provides Java wrappers and has been instrumented using one or more MBeans. A MBean is a normal Java Bean except for the fact that it exposes the management interface of a resource according in accordance with the JMX specification. Each MBean exposes a piece of management configuration or functionality of an underlying resource. A MBean can be classified as standard or dynamic. To a management application, they appear all the same but to a developer, they are quite different both in terms of the way they are developed and the flexibility they offer. Standard MBeans are developed using design patterns as specified in JMX specification e.g. the management interfaces must have same name as the classname with MBean appended to it, get() and set() methods for attributes etc. Dynamic MBeans on the other hand, expose their management interface via specific interfaces e.g. by implementing DynamicMBean interfaces and by creating MBeanInfo objects.


  • The specification identifies three key components at this level:

    a.) MBeans: The specification defines a MBean as a concrete class that is instrumented by either implementing its own management interface or by implementing DynamicMBean interface. It may also include an implementation of NotificationBroadcaster interface. There are four types of MBeans:

    • a.1) Standard MBeans: Define and implement their own management interface. Simplest to design and implement.
      a.2) Dynamic MBeans: Implement a predefined interface but expose their management interface at run time. These are the most flexible.
      a.3) Model MBeans: Are the most powerful, configurable and flexible. They only provide a generic dynamic MBean which can be customized to expose any management interface and instrument any resource at runtime.
      a.4) Open MBeans: Are dynamic MBeans that use basic data types and are self described.

    b.) Notification Model: The specification provides a notification model based on the Java event model that lets applications register and recieve notifications of all events that occur in a MBean of its interest.

    c.) Metadata classes: The specification define classes that are used for both introspection of standard MBeans and self description of all dynamic MBeans. Together, these classes describe the management interface of a MBean in terms of Attributes, Constructors, Operations and their Parameters.

    For a detailed discussion of these topics, please refer to the resources mentioned at the end of this section.


  • 2. Agent Level: The agent level provides specifications for implementing Agents. Agents are JMX components that expose the functionality of MBeans to outside applications. This level builds upon instrumentation level to define a standardized agent to manage JMX managable resources. Agents are usally located on the same machines as the MBeans they control, although, this is not a requirement. The JMX agent consists of following to components:

    • a.) MBean Server: Acts a registry for all MBeans. All management operations applied to resource have to go through the MBean server. The MBean server provides a standardized interface for querying, instantiating and accessing MBeans. Any resource that needs to be managed from outside the JVM, needs to be registered with the a MBean Server.
      b.) Agent Services: The JMX specification defines the following services that any compliant agent must provide the the registered MBeans:


  • b.1.) Dynamic loading services allow agent to instantiate MBeans using Java classes and native libraries dynamically loaded from the network.
    b.2.) Monitoring capabilities for attribute values in MBeans notifies the listeners upon detecting certain conditions.
    b.3.) A Timer service that can send notifications at predetermined intervals.
    b.4) A relation service that defines relations between MBeans and maintains the relations.

  • 3. Distributed Level: The Distributed services level provides interfaces for implementing JMX managers. As defined by the specification, this level defines management interfaces and components that can operate on agents. Typicall, these services can expose the management view of a JMX agent and its MBeans by mapping their semantic meaning into constructs of data rich protocol e.g. HTML or SNMP.

  • Please refer to the links mentioned in the references section for a detailed discussion of JMX and ModelMBeans.


5.2 Derby JMX Component Structure

  • The basic design principle followed while designing this architecture was to have a MBean, a Model MBean per service instance that is loaded into the monitor. The monitor being a service itself, is managed via System manager MBean. The diagram below gives a high level component structure of Derby along with JMX components loaded.

http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/resizedHLD.jpg

Component Name

Component Function

Starts As

Started By

Management Service

Derby Management Service

JMX Agent

Monitor

Authentication MBean

Management for Authenticaion Service

Model MBean

Management Service

System Manager MBean

Management for entire system (monitor)

Model MBean

Management Service

JDBC MBean

Management for Driver

ModelMBean

Management Service

Database MBean

Management for any loaded databases

ModelMBean

Management Service

  • Blue components in the diagram services that are started by the monitor. The monitor itself,along with its utility services is represented by red. MBeans, (Model MBeans) are represented by shades of purple and are labeled as "service name" MBean. The arrows represents call backs and returns from JMX Agent to MBean and from MBean to managed resource. The Management service itself is represented in cyan lies at the center of the diagram. A management application is represented in light blue at the top.


As I said earlier, the basic design idea for adding extensions to Derby is to have an Model MBean per service that is loaded in Derby. Each MBean will manage a logical aspect of the system. Please note that the diagram is only intended to give the user a overview of the architecture. Several details, including modules and services have been intentionally left out to highlight the architecture.


The choice of this architecture was based upon following factors:

  • 1.) Miniumum changes to exisiting code base are required due to the use of ModelMBeans. Model MBeans keep a reference of the object they are managing and implement all operations as callbacks. While reviewing the code, I felt that quite a lot existing functionality can very easily be exposed through Model MBeans.

    2.) Extensible: The design is inherantly extensible. If new services are added by developers, they can be simply plugged into existing architecture with minimal changes. The architecture neither restricts the development of new services or burdens the developer with writing of extra code for exposing to management client. Infact most of the code required for a Model MBean can be generated with help of tools.


5.3 Individual Components

  • The main components to be delivered as a result of this project are going to be MBeans, therefore I will focus this discussion on MBeans. JMX agent will be discussed only when needed.

    The following components are identified for the JMX extensions:

omponent

Implemented As

Functions

1.) System Management Service

JMX Agent (MBean Server)

Provides access to system management features

2.) Monitor MBean

Model MBean

Access to system level (monitor) properties & functions

3.) JDBC(Driver)

Model MBean

Access to JDBC driver level information

4.) Authentication

Model MBean

Access to authentication service

5.) Database MBean

Model MBean

Database level properties/management

.........

.............

(More MBeans to be added later )


  • 5.3.1. System Management Service: This service is nothing but a JMX Agent that is booted up, which in turn will register MBeans. The Agent performs two functions - Provides the MBean server which acts as central repository & factory interfaces to create our Model MBeans and provides the agent that lets us perform remote administration. The Management service will be not loaded in a normal derby startup. The management modules will be started only when Derby is supplied with an argument like derby.management=true. If you are worried about security and local vs. remote access or cases when derby is started in a server framework, please see the issues section for details.


  • 5.3.2. Monitor MBean: The Monitor MBean will be a Model MBean which will manage the Derby Monitor. This MBean will be an instance of javax.management.modelmbean.RequiredModelMBean class and will be customized at run time to provide the management functionality of the requried MBean. By calling a setManagedResource method on the RequiredModelMBean object and passing the reference of the Monitor as an argument, the MBean will be associated with the monitor. The actual task of mapping attribute and operation calls to Monitor will be done by MBeanInfoSupport object, which will also be created at runtime. <<Insert actual code with comments>> <<Code to be updated >>

    • // Code after the Agent has been started //


  • All other MBeans will be implemented using the same procedure as described for the Monitor MBean above.


5.4 Class Diagram

  • The following diagram depicts the relationships of the new JMX classes in Derby system. The attributes and methods of these classes have been intentionally left out for the sake of clarity.

http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/ClassDiagram.jpg


5.5 Component Diagram

The diagram below depicts the major componenets of the system e.g. The Agent, the MBeans and the components and interfaces used by MBeans.

http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/ComponentDiagram.jpg

6.0 Derby Management Service Startup

  • As Derby's management and monitoring moudles do incur some overhead on the host system, these services are not started with the normal startup of a Derby system. To start Derby's management service, the user will have to specify the following run time option:

    java -Dderby.management=true SimpleApp where local and remote specify if remote monitoring is to be enabled or not. Once the option has been specified, system can be monitored using JConsole.

7. Use Cases

  • Coming up soon!

8. Security Considerations

  • Please refer to the following discussion to learn more about JMX'es support for authentication, SSL and remote monitoring.


9. Issues

  • Version Incompatibilities: Currently, most of Derby's source is built against Java version 1.3, only code that is inherantly dependant on 1.4 is compiled against javac version 1.4. However, JMX support is available only on Java versions 5 (1.5) and above. Reference implementations of JMX are available for JMV version 1.3 and 1.4 as seperate download (Please see the discussion below for JMX implementations). Ant scripts will have to be modified in this case to support the building of JMX modules.

  • Modules.properties: The modules.properties file uses derby.env.jdk.<tag>={1|2|4} to identify which modules are supported under which JVM environments. Since JMX requires 5 and above, we need to extend support for 5 and maybe 6 as well. (Not very sure about this)

  • JMX Implementations: Anothe design issue it the choice of JMX implementations. Besides the one available as part of Sun JDK 1.5 and above there are several other open source implementations available. Each has its own advantages and disadvantages. The following is a list of the most apparant ones:

    1. Sun JDK 1.5 and above: Requires no additional Jars to depolyed with the client. Leads to smaller footprint. One the negetive side, it will always require Derby to run on JRE 1.5 and above. My not be a good choice as some implementations might be using earlier versions.

    2. Sun JDK prior to version 1.5: Sun's references implemenation (available as a seperate jar download) for JDK versions 1.3 and above. Applications running on JVM 1.3 and 1.4 will need to download install this jar.

    2. XMOJO Project: This JMX supports JDK version 1.2 and above, which means it imposes no additional JDK requirements. Hoewever, additional JARs will to be deployed on the client for them to use JMX. They can either be bundled with Derby or can be seperately installed on client. Another point to note is that XMojo itself requires two more jars to be present (xalan.jar, crimson.jar, and jaxp.jar and org.mortbay.jetty.jar)

    3. Apache Commons Modeller framework: The commons modelling framework is another Apache project developed under the Jarkarta project. Although, it is not an implementation in itself, it facilitates writing of MBeans in a big way and future updates are easily managed. The Metadata for MBeans is specified in an XML file which is parsed to gernerate MBeans.It is know to work with all major JMX implementations.

    4. MX4J: Another very popular JMX framework know to work with JDK 1.3 and above. It also supports automatic generation of ModelMBeans using XDoclets. Needs additional jars to be deployed. Supports HTTP adapters for access via HTTP.

    My recommendation is to use Sun's reference implementation with the commons modelling framework.

10. Geronimo and Glassfish

  • Both Glassfish and Geronimo application servers are built of top of JMX using what is know as "Inversion of Control" philisophy or the Hollywood style design, which is similar to way Derby is built. Geronimo uses GBeans to add components to the core server and Glassfish is also built around the same lines. There are two wasy in which Derby's features can be exposed from Glassfish and Geronimo:


  • Option 1: Use Derby as a part of the application and not as server framework. In this mode Derby's management extensions will be available to the user, not as a part of Server framework, but as a part of his application.


  • Option 2: Customize the extensions and make Derby available as GBean (in case of Geronimo etc): Although one implementation is already available with Geronimo, it does nothing more that starting and stopping Derby. However, to expose complete functionality as a part of server framework will require writing wrapper code around Derby's JMX modules and exposing all of them as part of GBean interface.


  • I think for the benifit of most users, option 1 seems to be the better choice. This way, Derby's developers get more flexibility while instrumentation of Derby GBean can be better left to Geronimo/Glassfish communities.

11. References

JMX tutorial sesssion as presented at the 2001 O'Reilly Enterprise Java Conference http://www.oreillynet.com/pub/d/858
JMX tutorial at Sun: http://java.sun.com/j2se/1.5.0/docs/guide/jmx/tutorial/tutorialTOC.html
JMX tutorial at XMOJO project: http://www.xmojo.org/products/xmojo/tutorials/docs/index.html[[BR]]

High_Level_Design (last edited 2009-09-20 22:12:44 by localhost)