db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "High Level Design" by SanketSharma
Date Wed, 28 Jun 2006 20:20:56 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by SanketSharma:
http://wiki.apache.org/db-derby/High_Level_Design

------------------------------------------------------------------------------
  = Apache Derby =
  
  == Draft Proposal ==
- == High - Level Design for JMX Extensions==
+ == High - Level Design for JMX Extensions ==
  
  == Document Contents ==
  
@@ -20, +20 @@

  	5.1 [#Overview JMX Overview][[BR]]
  	5.2 [#Current Component Structure][[BR]]
  		5.2.1 [#Embedded Monitoring Service][[BR]]
- 		5.2.2 [#Embedded_Server Monitor MBean][[BR]]
+ 		5.2.2 [#Embedded_Server Structure of MBeans][[BR]]
+ 		5.3.3 [#Interface_UML JMX Interfaces] [[BR]]
+ 6. [#Startup Management Service Startup]  (Under developement)[[BR]]
+ 7. [#UseCases Use Cases] (Under developement)[[BR]]
+ 8. [#Security Security Considerations] (Under developement)[[BR]]
+ 9. [#Geronimo Apache Raiders and fishes of glass (Geronimo and GlassFish)] (Under developement)[[BR]]
+ 10. [#Refernces References][[BR]]
  
  == 1. Revision History ==
  [[Anchor(Revision_History)]]
@@ -68, +74 @@

  === 3.4. Structure of this document ===
  [[Anchor(Structure)]]
            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 communication scenario between these components. Section seven discusses
the issues that might aries following a JMX implementation. Section eight enlists the sources
of information for this document. 
+ 	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.

  [[BR]]
  === 3.5. A Note  ===
  [[Anchor(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 mail !
+            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 !
   
  [[BR]]
  == 4. Assumptions and Dependencies ==
  [[Anchor(Assumptions)]]
  [[BR]]
  	  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.
- 	    This document follows Java Coding conventions defined at http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
+ 	This document follows Java Coding conventions defined at http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
  [[BR]]
  [[Anchor(Analysis)]]
  == 5. High Level Design ==
@@ -95, +101 @@

  	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:
+ [[BR]]
  
  	''' 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 ma
 nagement interface via specific interfaces e.g. by implementing DynamicMBean interfaces and
by creating MBeanInfo objects.
- 
+ [[BR]]
- The specification identifies three key components at this level:
+ 	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.) 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.[[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.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.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]]
+ 		''' 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]]
+ 	''' 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]]
+ 	''' 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.
+ 	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.) 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]]
- 		b.) Agent Services: The JMX specification defines the following services that any compliant
agent must provide the the registered MBeans:
+ 		'''b.) Agent Services:''' The JMX specification defines the following services that any
compliant agent must provide the the registered MBeans:
- 
+ [[BR]]
- 		b.1.) Dynamic loading services allow agent to instantiate MBeans using Java classes and
native libraries dynamically loaded from the network.
+ 		'''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.
+ 		'''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
+ 		'''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.
+ 		'''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.
  
@@ -131, +138 @@

  
  
  http://wiki.apache.org/db-derby-data/attachments/High_Level_Design/attachments/resizedHLD.jpg
- 	
- 	Blue components in the diagram services that are started by the monitor. The monitor itself,along
with its utility services is represented by shade of green. MBeans, (Model MBeans) are represented
by shades of pink 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. 
+ 
+ ||<rowstyle="font-weight: bold;	font-size: 12pt;color: white; text-align: center; background-color:
#828DA6; font-family: Helvetica, Arial, Tahoma, Verdana, 'Nimbus Sans L', lucida-sans, lucidasans,
sanserif; padding: 6px; border: none;">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||
+ || Driver 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. 
+ [[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. 
  
- 	The choice of this architecture was based upon following factors:
+ [[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]]
  	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 Indivisual Components ===
+ === 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:[[BR]]
  
- 	1.) System Management Service[[BR]]
- 	2.) Monitor MBean[[BR]]
- 	3.) JDBC(Driver) MBean[[BR]]
- 	4.) Authentication MBean[[BR]]
- 	5.) Database MBean[[BR]]
- 	(More MBeans to be added)[[BR]]
+ ||<rowstyle="font-weight: bold;	font-size: 12pt;color: white; text-align: center; background-color:
#828DA6; font-family: Helvetica, Arial, Tahoma, Verdana, 'Nimbus Sans L', lucida-sans, lucidasans,
sanserif; padding: 6px; border: none;"> 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 ) ||
+ [[BR]]
  
  
- 	''' 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. The 
+ 	''' 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. 
- 
+ [[BR]]
- 	'''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>>
+ 	'''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	//[[BR]]
  
@@ -168, +185 @@

  [[BR]]
  	//Step 3: Create necessary Metadata and descriptor class[[BR]]
  
- 	ModelMBeanAttributeInfo attributeInfo = new ModelMBeanAttributeInfo()
+ 	ModelMBeanAttributeInfo[] attributeInfo = new ModelMBeanAttributeInfo[1];
- 		attributeInfo = new ModelMBeanAttributeInfo(  "EngineVersion",
+ 		attributeInfo[0] = new ModelMBeanAttributeInfo(  "EngineVersion",
    								"java.lang.String",
    								"Version of database engine",
    								true,

Mime
View raw message