Replies below. > > 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. >
k :) > 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. > Okay. I can look into Hibernate. I haven't really messed much with the current object-rel mapping tools, but I've written a few custom layers myself (pre-decent cheap mapping tools), although none were that complex. Lately I've become convinced though of the need to make people's code more OO, and less procedural. I think aspects and JDO could go a long way to helping this. > 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. > That's an interesting thought. I'll keep it in mind. JMXDO? heh. > 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=- > Interesting thoughts. Thanks for the heads up. Steve __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.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
