Jini as an Enterprise Solution

In April 2000, I was asked to develop an enterprise, web-based Business to Business (b2b) exchange for the Facultative Reinsurance industry. Prior to this, I'd worked with many teams using Enterprise JavaBeans (EJB), CORBA, and JSP solutions, all of which had been found lacking in terms of development complexity and cost. I decided to deploy a Jini-based solution. I thought Jini, and JavaSpaces in particular, would provide a natural fit for a dynamic trading exchange. This turned out to be the case, while providing other benefits that only became apparent during the development process.

The advantages of the Jini architecture are

• simplicity of modeling,
• simplified parallel development environment, and
• simplicity of retrofitting.

These advantages alone justified the decision to deploy Jini, one that led to the launch of our exchange (Risk2Risk.com), within schedule and budget.

Simplicity of modeling

Figure 1. The design for the b2b exchange.

Jini provides simple fault tolerant patterns. A b2b exchange is at heart a very simple piece of software. Any complexity emerges from the need to provide business logic, security, and roll-back features. Our design was centered around a JavaSpace that functioned as a messaging layer between the servlet front end and JDBC-compliant database, SMTP server at the back end. The exchanges themselves were modeled as lightweight Entries that carried internal logic in order to archive themselves.

We created Manifest Entries for each User that held lists of active Exchanges available to the User. These Manifests were maintained by a lightweight Service we named Ernie. Each time an Exchange enters the space, Ernie updates everyone's manifests as needed. Because Ernie is able to run independently of the space as well as other system components, as are all Jini services, we were able to develop it fairly late in the process; scaling the speed of the manifest generation is simply a matter of running more Ernies.

Similarly, in order to keep an archive of the Exchanges, we wrote a lightweight service called Karen which retrieves Entries from the space and runs their archive() methods to archive that Entry in a JDBC-compliant database (mySQL in our case, but it can be SQLJ or another database query language).

Other lightweight services include Pat, an email agent that retrieves MailEntries and passes them on to an SMTP server using the JavaMail interface, and Kirk, a federation service which keeps parallel spaces synchronized.

As seen in Figure 1, the entire design can be sketched on the back of a napkin.

Simplified parallel development environment

We used half the staff we thought we'd need, and the true brilliance of Jini shone clearly when each team was able to run their own complete development environments on laptops, looking up the completed codebases from other machines as they needed. Therefore, developers could work both independently and in parallel.

For the first half of the project we had four developers working in an oval shaped arrangement of desks to facilitate paired programming and to encourage team conversation. We hold to the software development philosophy that good code is generated from developer interaction, not from the physical labor. Each developer had a reasonably powerful Windows 98 laptop (700mhz P3, 256mb RAM) running Tomcat, Cocoon, Metrowerks Codewarrior RMID, Textpad, and Internet Explorer. Code versions were managed by CVS.

In addition, we ran two dedicated machines for Development and Staging JavaSpaces and dedicated Development and Staging machines for the Servlet codebases. Note when I refer to Servlets, I actually mean Cocoon as it generates the appropriate Servlet given the XML and associated XSL style sheet requested, but that is beyond the scope of this article.

Each developer pointedtheir laptop at either the Developer or Staging box by modifying the Tomcat.bat file on their local machine. Because the core primitives seldom change, each developer could work on distinct pieces of business logic at the JavaBeans level while remaining connected to a live back end. This parallelism gave us a massive development speed boost and simplified the task of inducting new developers as we expanded the team to include XSL specialists and other programmers. The only time code base synchronization was especially needed was when a developer made a rare change to a Primitive Entry. Then everyone needed to be sure to checkout the latest Primitives from CVS, recompile, and do the same on Developer and Staging machines. As the code base matured, this happened less and less frequently. Now this happens less than once a week.

To the ongoing amusement of visitors to our lab, there are huge signs in red on the walls which read "If you change a Primitive you must reboot Karen, Otto, Ernie, and Pat."

By using the Codewarrior targeting and FTP post linking, we could keep most of the code base in one project file and recompile targeted agents into place without disrupting other developers. I am sure that other IDEs provide this via build mechanisms such as Ant, but we decided to stick with what we know.

Simplicity of retrofitting

Design changes, which would have been very difficult to implement late in development using EJB, are easier and more efficient using Jini. The loosely coupled nature of the services means that there are fewer inter-object dependencies and the whole codebase can be revamped quickly and cleanly.

Every good project benefits from the ability to retrofit code rapidly. Occasional sweeping design changes are justified when benefits outweigh costs. Because the coupling between the presentation layer (XSL), the business logic (JavaBeans), and the back end (Jini services) are as loose as possible, even major changes to the underlying code came at a greatly reduced cost. I like to use the analogy of Indiana Jones swapping the idol for the bag of sand in the opening scenes of Raiders of the Lost Ark. The huge spherical boulder is the looming deadline, client, or manager. Loosely-coupled architectures give you the edge that Dr. Jones never had.

A few gotchas

When we began our project, we encountered several gotchas. Jini services announce themselves as widely as possible. While this is excellent in a production system where fail-over and redundancy are mandatory, in a development environment you don't want your services and spaces announcing themselves to the wide world. We ran into a few hitches initially as the default policy files allowed every service to see every other service and our development and staging environments collided regularly. Once we realized what was happening, this was easy to fix. Also, we discovered that Reggie, Sun's implementation of the Jini lookup service, would continually try to announce itself to an international lookup service at mbone.org. I cannot emphasize enough the need to keep development systems locked down behind a firewall.

On recruiting developers

Jini is easy. Any Java developer, even one with no or little experience in enterprise systems, can be a valuable member of a Jini team with very little ramp-up time. This compares favorably to EJB developers who are, by and large, more expensive and sadly a little stuck in their ways. In our experience you can start an enterprise Jini project with a very small team and then grow your team as the project gains definition. You are not forced to plan your whole project well in advance as retrofitting is so easy; you are not forced to hire a full development team in advance.

On cost of development

Faster simpler projects are cheaper of course, but there are other financial advantages to Jini based projects too.

First, you do not need to invest in application servers, EJB frameworks, or ORBs of any kind. Other development teams, who used EJB to develop very similar applications, spent up to 20 times our budget. It's certainly a lot easier to earn a return on a much smaller investment.

Second, we were able to deploy an enterprise system using a suite of open source software on a large number of cheap boxes. We avoided the expense of on-going license fees for proprietary software running on a cluster of expensive machines. The result of this is zero ongoing costs outside of continued development. This compares to an average of over £1M per year in service agreements and license fees to deploy a more traditional, identically-featured system.

Example code

We announced the open sourcing of our b2b code base at the recent Jini Community Meeting in Amsterdam (December 2000). The code is divided into three layers. The base layer provides the core event model for abstract communication between the XML front end and JavaSpace back end, and is called org.crudlet. Crudlet stands for Create, Retrieve, Update, Delete, Lifecycle, Exists and Template. The next layer uses Crudlet events and provides abstractions for actual b2b exchanges and is called org.crudlet.tennis. The final layer is the com.risk2risk layer which contains the proprietary code specific to Risk2Risk.com Ltd. The crudlet and tennis code bases are available at www.crudlet.org.

Dave Sag is a skilled Object Modeler and Software Designer, using Java as well as other programming environments.

Return to ONJava.com.