Hey David.
- In Section 5.1 you are making the implicit assumption that the JMX functionality is targetted towards Derby being an enterprise-class database. I'm not sure if everyone would agree that's the sweet spot for Derby. If you look at the charter, the focus is on zero-administration, embeddability, standards-based, etc.
Well, I apologize for the loose phrasing of the sentence!. What I inteded was such a functionality is essential if Derby is to used as part of enterprise-class systems. I guess that is ok?
That said, I think JMX is important (see "ease of use" and "standards-based"), but when looking at requirements I want to make sure we don't get too top-heavy...
I let my imagination run wild while making the list. What features we finally incorporate will depend on a lot of factors including costs. We'll just have to do some sort of evaluation first.
- You talk about two key areas that JMX can contribute to: monitoring and tuning. I would assume "tuning" includes general system configuration too. I can see all the existing Derby properties being exposed through a JMX interface.
Precisely. I think that should be our first starting point. Expose all the properties.
- Under proposed features, it would really help if each feature had its own unique identifier, like MON-1, MON-2, MAN-1, MAN-2, NOT-1, NOT-2, etc.
Good idea. Will do that.
- A well-thought-out and great list of features! There are a *lot* of features here.
Thank You!!
So, how to decide? Your separate table with priorities is one
approach, but I'd >like to propose something a little more interactive. I'd like the feature list section >of the document to a Wiki page (or maybe it makes sense to migrate the entire >document to Wik? - your call), and announce it on the derby-user and derby-dev
lists. Each developers/user could add a column to the table and
assign their >priorities to each feature. This would be a chance for the community to get >involved in picking which JMX features they'd like to see. Ummm....
If you do decide to stick with the current model, I highly recommend merging the priorities with the main feature table, so you are not constantly having to keep the two in synch, and so that readers don't have to keep switching back and forth between the two tables.
I think Wiki is more interactive. I'll try and put the tables up on wiki. Last time I tried the table lost its formatting.
- I'm a little confused about not providing remote access. Can you describe how >an administrator who is not aJMX programmer can view, monitor, and tune an >embedded Derby database that is not part of a larger application framework that >provides JMX support? Whenever I talk to users, remote monitoring and >administration are on the TOP of their list. I think this is required, but we do have >to make sure we understand the security implications of such a topology.
For me, its more of a philosophical issue than anything. If I "embed" something inside my application, then I should not expose it directly to outside world. However, thats one philosophy. My initial take was to provide remote accessibility, because it makes so much sense. If you have 10 such applications running on 10 different machines it would certainly be nice to monitor them from one central location. And it also goes with the Derby on Amazon S3 device ;-). JMX supports few protocol connectors that let you monitor your applications/devices over different protocols like SNMP/HTTP etc. Anyways, an administrator not using API's has two options: 1)Browser interface: JMX provides a default web interface which is very primitive. We might have to do some Servlet/JSP to improve interface and to allow management of multiple instance 2)Using a management Console: This would be a Java GUI application that can connect to Derby instances using RMI. These are the two trivial cases. JMX can also work over array of other protocols. Let me know if it clears your doubts. One more thing I would like to add is that Security should not be a concern as Sun defines a whole bunch of API's to handle that.
- A commonly missed aspect of requirements documents are non-functional requirements. These are "qualities" of the overall feature. Things like performance (response time, thorughput, number of concurrent users), security, ease of use, etc.
Yeh..I missed those completely. Will update my document soon.
- You had mentioned building our own JMX console. Is that still on the plate? Or do we just let existing JMX tools plug into our framework?
I guess if usability and ease of use is our concern, we will have to do it? or atleast build something on top of existing tools. Best Regards, Sanket Sharma
