Steve, I've been preparing an email directly for Alex for several days now, but since you're interested in the subject, I decided to reply on the list. Hopefully this would spur a good discussion.
I recently exchanged several emails with Alex about JBossDO contributions and I have on my plate to evaluate the feasibility of wrapping the CMP API and possibly the JDO API around Hibernate. JBoss has been known to embed solid third party tools like Tomcat and JavaGroups. Since I am now working with Sacha and Adrian on some clustering and JMX features, you may start looking into it instead. Another topic which is an ambitious but logical derivative of the JBossDO subject is a persistence layer for ModelMBeans and possibly any MBeans in general. Someone from the core JBoss group should please raise a flag if the rest of my email is nonsense. JBoss currently ships with an XMBean persistence mechanism which reads/writes ModelMBeanInfo from/to XML files. This is fine as an example application of ModelMBeans, but I would like to see JBoss push the limits again. The JMX spec requires that access to MBeans always goes through the MBean server. This makes it inherently very convenient to efficiently save/load the state of an MBean. A lot of optimization can be applied, such as detecting dirty attributes. Hibernate looks like a good candidate to leverage, because it already has the dirty detection logic. Ideally the persistence should be db agnostic, so that the RDBMS can be swapped as scalability requirements change. Hibernate is already popular for that and can be considered. Another nice feature would be to scale horizontally. Cluster support can be transparent to the MBean server users. Hibernate currently does this via the Apache JCache library, but once the JBoss transactional distributed cache is solid, it should be feasible to replace. Yet another possible requirement is that on a per MBean basis, the MBean server persistence layer swaps out the MBeans to a database, when not all of them can be kept in memory. Here are some use cases for being able to transparently persist the state of MBeans to a database: 1) In case of larger distributed systems, it is convenient to use a single JMX console to modify state of preferences MBeans that would normally be loaded from a properties file or an XML config file. It is much easier to work with a visual JMX client application and not worry about how the state will be made permanent, then knowing where to look for config files and having to redeploy modules on change throughout a cluster. 2) Since the JMX API is more lighterweight, has a shorter learning curve and is getting adoption faster than the EJB CMP, many domain objects can be modeled via mbeans and it may be more convenient to resort to the MBean server with its fast and simple query language before going heavy weight with the EJB CMP or advanced SQL. 3) Persisting plain POJOs is becoming very popular especially in J2EE apps. It is the JBoss strategic direction for 4.0 with its AOP architecture. Since AOP itself is so generic and powerful, in many cases it may be safer and more convenient to use a well understood API like JMX, which conveniently and transparently implements persistence. Since the JMX Query language is relatively simple, it can be mapped to Hibernate's OQL. This will be useful for swapping out mbeans from memory to db. For example the MBean server persistence layer can try to swap out to the db some of the ModelMBeans that are inactive. Inactive has to be better defined, but intuitively this means ModelMBeans that are not being accessed for a long time. I can keep going on and on with use cases for this idea, because it is based on a real problem that my team is working on for the fourth generation of a large J2EE app. Notifications and relationships are next on the list of things that make this idea appealing. Looking forward to hear comments. Cheers! -=Ivelin=- ----- Original Message ----- From: "Steve Lewis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 19, 2003 12:31 AM Subject: [JBoss-dev] JBossDO > I'd like to get involved with the JBossDO project. > I've asked a few questions in the persistence forum > but no one has answered. I know you guys are busy :), > but I'd like to work on table generation, since no one > seems to be working on it right now. > > I'd like to see how it's currently being done by the > CMP engine and see how different it will be in the JDO > implementation. > > I'm also interested in the idea of managing JDO in the > container via JCA, since JBoss 3.0 is so JCA-centric > and JCA-friendly. > > Also, if you have any suggestions for > projects/packages to look at (besides the obvious > current CMP and new persistence projects), I'll be > grateful for any pointers. > > Thanks, > Steve > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
