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.
Therefore, JFire makes heavy use of XDoclet for the auto-generation of JDO meta
data, objectid-classes (see application identity) and EJB
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.
BIRT is an open source reporting framework that JFire
uses for creation and rendering of forms like invoices or delivery notes or to generate statistical
reports. The project JFireReporting provides a new data-source for BIRT reports that let users
with access to a PersistenceManager or via direct JDOQL. Take a look at the
documentation for JFireReporting
or browse the
source code for more information.
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