Basic setup

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).

XDoclet

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 interfaces/util-classes.

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.

Cache for the client

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.

Inter-Organisation-Sync

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 datasource for JDO

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 access a PersistenceManager in the JFire server. Users can collect their data either by JavaScript 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.

Download

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.