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 "Requirement Specifications" by SanketSharma
Date Sun, 11 Jun 2006 22:08:22 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/Requirement_Specifications

------------------------------------------------------------------------------
  
  == Requirement Specifications for Monitoring and Management Extensions using JMX ==
  
+ == Document Contents ==
+ 
+ 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]]
+ 	3.5 [#Note A note about ranking][[BR]]
+ 4. [#Assumptions Assumptions and Dependencies][[BR]]
+ 5. [#Analysis Requirement Analysis][[BR]]
+ 	5.1 [#Overview Overview][[BR]]
+ 	5.2 [#Current Current Scenario][[BR]]
+ 		5.2.1 [#Embedded Embedded Instance][[BR]]
+ 		5.2.2 [#Embedded_Server Embedded in Server Framework][[BR]]
+ 		5.2.3 [#Network_Server Network Server][[BR]]
+ 	5.3 [#Conclusion Conclusion][[BR]]
+ 6. [#Identified Requirements Identified][[BR]]
+ 	6.1 [#Feature_Overview Overview][[BR]]
+ 	6.2 [#Feature_Identified Features Identified][[BR]]
+ 	6.3 [#RemoteLocal Remote vs. Local][[BR]]
+ 	6.4 [#Feature_Conclusion Conclusion][[BR]]
+ 7. [#References References][[BR]]
  == 1. Revision History ==
- 
+ [[Anchor(Revision_History)]]
  
  ||<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;"> Version || Version Information || Date || Modified
by || Comments ||
  || 1.0 || Document Created || Tuesday, June 06, 2006 || Sanket Sharma || Comments are welcome!
||
  
  == 2. Disclaimer and Legal Information ==
- 
+ [[Anchor(Disclaimer)]]
  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.

@@ -19, +43 @@

  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 ==
- 
+ [[Anchor(About)]]
  === 3.1. Purpose ===
+ [[Anchor(Purpose)]]
           This document identifies the requirements and design goals for adding Management
extensions to Apache Derby as Google Summer of Code 2006 project. Consequently the document
identifies a set of requirements, categorizes them and attempts to assign priority to the
identified requirements for their implementation. However, the priorities assigned reflect
my own personal views and are left open for the community to decide. The final priorities
will be decided by the community as a whole. This document does not describe any high level
architecture or implementation details. These will be described in a subsequent documents.
  [[BR]]
  === 3.2. Intended Audience ===
+ [[Anchor(Audience)]]
            The intended audience includes a wide community of those interested in developing
monitoring and management applications for the Apache Derby. It also includes the end users
of the database who will ultimately use these features and the developers who might use these
features for fine tuning their applications. 
  [[BR]]
  === 3.3. Notations and Conventions ===
+ [[Anchor(Notations)]]
            The documentation set uses the following conventions.
  [[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;"> Convention || Explanation
|| Example ||
@@ -44, +71 @@

            || {{{ -aXP }}} ||
  [[BR]]
  === 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. Section five
describes what features currently exist in Derby to monitor and tune the performance of the
system and why we need a better monitoring and management system. Section six then tries to
identify features that might be useful to developers and administrators. While this section
enumerates a whole bunch of features, this section also tries to assign a priority to their
implementation. Section seven enlists the sources of information for this document. 
  [[BR]]
  === 3.5. A Note about Ranking ===
+ [[Anchor(Note)]]
             Developers and Derby users who read this document are requested to assign their
priorities to the features enlisted in section six. I have provided an initial version of
priorities based on my personal opinion. Developers and Users are requested add a column to
the table, add their names as coloumn heading and assign priorities to the features. This
will help us in deciding which features have to be implemented and in which order. 
  [[BR]]
  == 4. Assumptions and Dependencies ==
+ [[Anchor(Assumptions)]]
  [[BR]]
  	    This document follows Java Coding conventions defined at http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
  [[BR]]
  == 5. Requirement Analysis ==
+ [[Anchor(Analysis)]]
  
  === 5.1. Overview ===
+ [[Anchor(Overview)]]
  	   Apache Derby is a relational, light weight, embedded database developed entirely in
Java. Being an embedded database it is very flexible in its use and can be used either embedded
inside an application sharing the same JVM as the application or can be embedded inside a
server framework (such as Geronimo) or can be deployed as a standalone server (with the Network
server framework) in a traditional client server environment. However, currently derby does
not support any mature monitoring and management features which lets a developer or an administrator
view statistics about the health of a system and fine tune system parameters via a management
console or application. Such functionality is indispensable for any database system of any
scale for a multitude of reasons. This section tries to identify the requirements for such
a monitoring and management framework.
  [[BR]]
- === 5.2. Overview ===
+ === 5.2. Current Scenario ===
+ [[Anchor(Current)]]
              The following section identifies the what is currently supported in derby with
reference to:
  [[BR]]
     	   ''' 1. Monitoring the state the system ''' [[BR]]
@@ -68, +101 @@

          Although current features can not be termed as monitoring or management features,
but they do provide some primitive functionality. The following section describes these in
details with respect to the three ways Derby can be used - embedded and as network server.

  [[BR]]
  ==== 5.2.1. Embedded Instance ====
+ [[Anchor(Embedded)]]
  	  When Derby runs as an embedded database engine sharing the same JVM there are quite a
few ways for setting the properties for a Derby instance, both system wide and database. Such
properties can be set either in the derby.properties file or can be at run time by: [[BR]]
  		[[BR]]
  		* Using parameters while starting application e.g. java -Dderby.xxx=something YourApplication.
[[BR]]
@@ -81, +115 @@

  	What is needed is a functionality which a developer can use to tune the system while examining
its state from outside the application. A typical usage scenario would be when a user runs
his application and then starts the management console to view the current state of system
or to debug his application. Without writing any code in his application he is able to change
the system state and view how the system responds. Such functionality should be available
to all applications without any coding. The developer/administrator should be able to tune
the system at runtime without changing his code. 
  [[BR]]
  ==== 5.2.2. Embedded inside a server framework ====
+ [[Anchor(Embedded_Server)]]
  
  	     [[BR]]Essentially, this is same as 5.2.1 where the application server or some other
server framework becomes client for Derby. Most application servers come with a management
console that lets administrators and developers configure various system wide settings locally
or remotely. Since Derby does not provide any management framework that integrates into application
server frameworks, developers of such systems using Derby have to write wrappers around Derby
API calls to provide any management functionality, if at all.
  
@@ -88, +123 @@

  
  [[BR]]
  ==== 5.2.3. Network Server ====
+ [[Anchor(Network_Server)]]
  	   
  	   In this mode Derby runs in embedded mode, wrapped inside a server framework that multiple
remote clients connect to. Derby can run as full fledged relational database server with the
help of bundled server framework. Multiple remote clients can connect to database server simultaneously
while the server takes care of concurrency issues and ACID properties.
  
@@ -96, +132 @@

  	The proposed extensions will enable a server framework using derby to provide live monitoring
of system along with the "regular" administration features found in most commercial database
systems. Some of these features have been identified in the following sections. 
  [[BR]]
  === 5.3. Conclusion ===
+ [[Anchor(Conclusion)]]
  	   Whether running in embedded mode or as server, the developer or user has very limited
choices for controlling the behavior of system. In light of the facts above it is desirable
to have a monitoring and management extension for derby for that enables developers and administrators
to view the performance of a Derby instance without writing any extra code. The exact list
of features to be supported by such a extension are discussed below
  [[BR]]
  == 6. Requirements Identified ==
+ [[Anchor(Identified)]]
  
  === 6.1. Overview ===
+ [[Anchor(Feature_Overview)]]
  		   This section describes the requirements of the new monitoring and management system
for Apache Derby. The requirements are classified in three categories: [[BR]]
  
  	''' 1. Requirements for the Monitoring System: ''' Requirements identified under this category
are critical for assessing the health of the system. These are either counters or variables
that provide insight into the state of the system. [[BR]]
@@ -110, +149 @@

  
  
  === 6.2. Proposed Features ===
+ [[Anchor(Feature_Identified)]]
  
  		||<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;">Cateogory/Code || Features || Priority (Sanket)
||
  		||<rowstyle="font-weight: bold;	font-size: 12pt;color: white; text-align: center; BACKGROUND:
#00ccff; font-family: Helvetica, Arial, Tahoma, Verdana, 'Nimbus Sans L', lucida-sans, lucidasans,
sanserif; padding: 6px; border: none;"> a) Monitoring ||		||		||
@@ -167, +207 @@

  
  
  === 6.3. Remote VS. Local ===
+ [[Anchor(RemoteLocal)]]
  		In my opinion, remote access to these features should not be provided. My opinion is based
on the following observations: 
  
  	* ''' Embedded Nature of derby: ''' The scope of the database can not extend beyond that
of application. If the application as a whole does not provide any remote administration feature,
it does not make much sense for only a part of the application to be remotely accessible.[[BR]]
@@ -181, +222 @@

  	However, keeping in mind the pressing demand by users of Derby, a middle path can be providing
remote administration as "Optional Services" that can be enabled and disabled via some command
line option when Derby is stared. [[BR]]
  
  === 6.4. Conclusion ===
+ [[Anchor(Feature_Conclusion)]]
  	[[BR]]
  		The priorities assigned reflect my own personal views and are open for community discussion.
The final rakings will be decided by the community. 
  
  
- == 8.0 References ==
+ == 7.0 References ==
+ [[Anchor(References)]]
  
  	*Java Platform Profiling Architecture, JSR 163 at http://www.jcp.org/en/jsr/overview 
          

Mime
View raw message