3. Solution Details

The solution focused on simplifying the system by targeting the bulky frameworks and services that ‘wrapped’ the application code.

The result was the development of a very lean Object Server that supported very fast server code compilation times and that was not intrusive into server application code. This became the OccamJ application server.

3.1. Communication Protocol and server-stub generation

The system clients were Java applications and all non-java client processes were serviced through web-services so IIOP was not needed by the server. Java2IIOP compilation was slow and accounted for over a minute of compile time. RMI was adopted as the server protocol and façade objects were served using Java dynamic proxying thus avoiding the compile-time penalty of stub generation. This also allows OccamJ to serve POJO objects that do not extend communication framework classes.

3.2. Data Persistence and Object to Relational Mapping

JDO was chosen as the ORM mechanism for OccamJ. JDO applies the POJO approach to data persistence. It allows for radically smaller deployment descriptors than CMP and allows for a choice of ORM vendor. For this application Open Access from Versant was chosen as the JDO implementation. It performed well and the workbench allowed for easy mapping of the entities and relationships in the object model.

3.3. Built-in services

The server had services built-in for error-logging, executing startup code and loading property files. Property files were chosen over xml for ease of use. In addition a console was added to allow runtime monitoring of resources and connected users.

3.4 IDE support

Since developer productivity was a major focus, plug-ins were added for Eclipse and JBuilder. The server applications can executed and debugged from within either environment. For faster development, the server code can be run from within the development class folders without packaging or deploying.