JFire is a new, powerful and free ERP, CRM, eBusiness and SCM/SRM solution for business enterprises. JFire is entirely free/open-source software, uses the latest technologies (J2EE 1.4, JDO 2.0, Eclipse RCP 3.2) and is designed to be highly customizable.
It is of interest for DataNucleus users because it is a good example of use of JDO 2.0 in a real-world application, and is developed using DataNucleus. Being open-source you can view how JDO 2.0 is employed to provide its data persistence. It is a prime example of usage of XDoclet 1.2.* JDO2 tags, too.
Being a client-server system, JFire uses a J2EE server for the backend, into which Enterprise Archives (EARs) are deployed. These EARs contain Resource Adapters, (stateless) Session Beans and the data model. Entity Beans are not used, because the data model is pure JDO 2.0. Even though J2EE allows the easy implementation of all kinds of clients, there is so far solely an Eclipse-RCP-based client implemented.
In order to guarantee strict privacy protection, JFire manages every organisation in a separate datastore. The organisations can even be hosted on different J2EE servers and thus be spread around the world. This makes the system highly scalable - in most cases even without employing a complex clustering configuration.
Because JFire is built in a very modular form, parts of it can be used for totally different purposes (e.g. solely for organisation and user management, without any trade related functionality).
Having written JDO metadata, you've probably recognized that you have to do some duplicate work - for example the names of the fields occur in both, the java classes and the XML files. For small projects, this is really not an issue, but when having more than a hundred JDO classes, you probably prefer to reduce duplicate work wherever possible. Additionally, maintaining two different files describing the same object is more error-prone than having all information for one class gathered in one single file.
Note, that the official XDoclet release very likely does not yet include support for all JDO 2.0 features. You should either use a recent CVS snapshot binary or build it yourself from current sources.
If you want to see how a JDO-tagged java class looks like, you can find an interesting example here ( direct link to source code). This abstract class uses application identity with a composite primary key. It declares queries, fetch-groups and much more.
DataNucleus has already some caching functionality included (see Cache and Cache (Developer)). These caches don't span the client however. That's why JFire implements a cache system which tracks changes to JDO objects in the server and is able to notify listeners of these changes. The JFire RCP-client uses this to cache detached JDO objects and reduce queries. This is part of the basic framework (JFireBase) and could be used in any other application that works on a J2EE server with JDO data-model and RCP clients.
JFire's JDO-cache-brigde is also used for another fundamental feature of JFire's base: the synchronisation of objects between organisations in a JFire network. It registers listeners to the cache and informs synchronised candidates about changes. Being push-based, remote organisations are instantly notified. The receiver however is himself responsible to actually grab the changed data and can independently decide when and to what extent this should be done.
The only thing remaining is to download JFire now and see how you can utilise JDO 2 and DataNucleus in your application. You might want to use parts of JFire, even if you don't implement a trade-related application, because user-management, remote-class-loading, client-sided caching and other functionality is helpful to many other use-cases, too.
Authors: Alexander Bieber, Marco Schulze