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 Mon, 10 Jul 2006 17:39:24 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:

  4. [#Assumptions Assumptions and Dependencies][[BR]]
  5. [#Analysis High Level Design][[BR]]
  	5.1 [#Overview JMX Overview][[BR]]
- 	5.2 [#Current Component Structure][[BR]]
- 		5.2.1 [#Embedded Monitoring Service][[BR]]
- 		5.2.2 [#Embedded_Server Structure of MBeans][[BR]]
- 		5.3.3 [#Interface_UML JMX Interfaces] [[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. [#Startup Management Service Startup]  (Under developement)[[BR]]
+ 6. [#Service_Startup Management Service Startup]  (Under developement)[[BR]]
- 7. [#UseCases Use Cases] (Under developement)[[BR]]
+ 7. [#Use_Cases 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]]
@@ -130, +132 @@

  		'''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]]
+ [[Anchor(Component_Structure)]]
  === 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.
@@ -155, +158 @@

  	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.
+ [[BR]]
+ [[Anchor(Individual_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]]
@@ -168, +173 @@

  || ......... || ............. || (More MBeans to be added later ) ||
+ [[Anchor(Management_Service)]]
  	''' 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. 
+ [[Anchor(Management_MBeans)]]
  	'''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]]
- 	//Step 1: Obtain an instance of resource [[BR]]
- 	Monitor myMon= Monitor.getMonitor();[[BR]]
- 	//Step 2: Create a RequiredModeMBeanInfo object [[BR]]
- 	ModelMBean monitorMBean= new RequiredModelMBean();
- [[BR]]
- 	//Step 3: Create necessary Metadata and descriptor class[[BR]]
- 	ModelMBeanAttributeInfo[] attributeInfo = new ModelMBeanAttributeInfo[1];
- 		attributeInfo[0] = new ModelMBeanAttributeInfo(  "EngineVersion",
-   								"java.lang.String",
-   								"Version of database engine",
-   								true,
-   								false,
-   								false,
- 							);
- 	DescriptorSupport desc = attributeInfo.getDescriptor(  );[[BR]]
- 	desc.setField("getMethod", "getEngineVersion");[[BR]]
- 	.........[[BR]]
- 	.......[[BR]]
- 	//Step 4: Create metadata resource[[BR]]
- 	ModelMBeanInfo mbeanInfo = new ModelMBeanInfoSupport(Monitor.getClass().getName(  ),
-     								"Derby Monitor MBean",
-     								attributeInfo,
-     								null,
-     								null,
-     								null
-   								);[[BR]]
- 	//Step 5: Set the metadata of RequiredModelMBean to the metadata for the resource (from
Step 3) and the resource to be managed through the ModelMBean interface. [[BR]]
-   			monitorMBean.setModelMBeanInfo(mbeanInfo);[[BR]]
-   			monitorMBean.setManagedResource(monitor, "ObjectReference");[[BR]]
-   			MBeanServer mbeanServer = MBeanServerFactory.createMBeanServer(  );[[BR]]
-   			mbeanServer.registerMBean(queueModelMBean, objName);[[BR]]
- 	// . . .[[BR]]
- '''5.3.3. JDBC(Driver)/Authentication/Database/Other MBeans:'''  All other MBeans will be
implemented using the same procedure as described for the Monitor MBean above.
+       All other MBeans will be implemented using the same procedure as described for the
Monitor MBean above.
+ [[BR]]
+ [[Anchor(Class_Diagram)]]
  === 5.4 Class Diagram ===
- 	The following diagram depicts the relationships of the new JMX classes in Derby system.
+ 	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.
+ [[BR]]
+ [[Anchor(Component_Diagram)]]
  === 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.
+ [[Anchor(Service_Startup)]]
+ == 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.
+ [[Anchor(Use_Cases)]]
+ == 7. Use Cases ==
+ 	Coming up soon!
+ [[Anchor(Security)]]
+ == 8. Security Considerations ==
+ 	Please refer to the following discussion to learn more about JMX'es support for authentication,
SSL and remote monitoring.
+ [[Anchor(Geronimo)]]
+ == 9. 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:
+ [[BR]]
+ 	''' 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. 
+ [[BR]]
+ 	''' 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.
+ [[BR]]
+ 	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.
+ [[Anchor(References)]]
+ == 10. References ==

View raw message