The Seventh Jini Community Meeting II

This is the second of a set of blogs from the Seventh Jini Community Meeting held in Cambridge, Massachusetts March 23-25, 2004.

caveat: I should remind everybody that these are my observations and thoughts and not necessarily of those of my employer, any other member of the Jini community, or indeed anyone else on the planet. I'm a member of the Jini development team so these next few blogs will be "a little closer to home" than the essays I've done for Artima previously. Well, consider yourself warned! <grin>

Coming of Age

Here are some observations from the afternoon sessions which backs up my views that Jini has come of age.

Orbitz

Orbiz has gained a foothold in its market as the third largest travel web site in roughly the last three years. They are also a monsterously large Jini shop. With over 1300 Jini-based services running in approximately 300 VMs, it is likely the largest Jini-based application you will use. That's right, you. Every time you buy an airline ticket, book a hotel room, reserve a car, or uses any of the other services sported by Orbitz, a hand-full of Jini-based services are employed.

You might think that the presentation by Orbitz to a audience full of Jini developers would concentrate on the general architecture and specific uses of Jini in the system. Nope. And that's a good thing. The Jini apsect of the system architecture is reasonably straightforward and was described easily in the first part of the presentation. The remainder of the time, and the thrust of the talk, was on the monitoring aspects of a large scale distributed system with Jini-based services.

It was subtle, but the message I got from this was clear: Jini is just another great technology used to construct high-value solutions... now let's talk about how to manage the deployment. Consider the alternative views: Jini is new, Jini is risky, Jini is obscure, Jini isn't ready for prime time. The presenters from Orbitz skipped right by any of those doubts and went directly to we created a great solution with Jini and now we're working to make it easier to manage.

The Orbitz folks had the same asperations I've had when I have built large systems. They wanted to create a system that would actively assess the health and efficacy of the distributed system components and be able to take preemptive actions to avoid customer-visible failures. One of the terms the presentation team (the presentation was done tag-team style with three engineers) put forth to describe their goals was autonomic computing-- a term that I know I heard kicked around the Jini group at least a year before it began appearing in IBM advertisements. Regardless of the genesis of the term, the meaning is clear: automation of management, provisioning, and error-recovery is critical to availability of a complex distributed system. The Orbitz team has a good idea of what the next steps will be for their system.

At the conclusion of the prepared remark, one audience member asked what many of us were wondering: why didn't they just use J2EE? (Or, more appropriately, how did you get away with not using J2EE for all this?) Their answer was thus: when they first looked at Jini, they couldn't help but notice that its cool. But, besides that, their first impressions of J2EE were that it was expensive and heavyweight. They do use some J2EE--but its wrapped behind a Jini-based service(!). In the end, the extra machinery, and cost, of a J2EE-based solution was a strong disincentive. But, such a statement probably "damns with faint praise" their view of Jini Technology.

The Jini Way(TM) was the best approach based on the Orbitz engineering team's understanding of the problem. The problems they were left with, that of monitoring the health of the constituent parts of the system and responding to problems, is the class of problems that you'd need to solve for any production web site.

Again, my impressions from the talk (other than the Orbitz folks are pretty smart) were this: Jini technology is a killer technology that's come of age.

Countrywide Group

Taking something new and carving out a solution from whole cloth is one thing; taking an existing company and an existing codebase and converting portions of a large application suite to use Jini is quite another. Countrywide Group, a large insurance provider in the United Kingdom, had such a challenge and found Jini's benefits to outweigh any transistion costs. Their view of Jini and its alternatives were captured in one sentence near the beginning of their presentation:

"Jini was the only way we could maintain all our generic requirements and our enterprise requirements in a cost-effective manner."

Like the Orbitz presentation, there was a question that was going to be asked about J2EE. Calum Shaw-MacKay, the presenter from Countrywide, anticipated the question and had this early in the presentation:

"Why didn't we choose J2EE? Of the vendors we talked to, no vendor understood what we wanted to do. They kept talking about XML and web services but that wasn't what we were trying to do. They were more helpful in sell us a product than helping us with our solution."

They went so far as to drop an existing J2EE effort in favor of Jini. That's right: they had J2EE and threw it out. Why? I'm guessing they were looking for the lesser of two evils:

• Changing horses in mid-stream (from J2EE to Jini), or
• Riding a dead horse that wasn't going to get you there anyway (J2EE)

This isn't meant to be an indictment of J2EE. Quite the contrary, J2EE is a fine technology that has its place. But, no technology is a perfect solution to all problems. Jini happens to provide a reasonable set of tools for the problems that Countrywide had as highlighted by this notion found later in the presentation.

"We have not yet come across an intergration problem that cannot be solved using Jini and JDK. Jini isn't just 'cool', and it is suitable for enterprise environments. Jini lends itself to more solutions than J2EE... but is compatible with J2EE."

Jini isn't a one-size-fits-all solution any more than J2EE is. However, the ability to use only those pieces of Jini appropriate to your problem was also an attractive attribute of Jini technology. J2EE, somewhat monolithic and indivisible, doesn't provide the same kind of granularity that a Jini-based service architecture provides.

Money on the Table

Did you notice something about both of these applications? They were both dealing with real money. There is money on the table with both of these applications. Failure of these applications will result in losses that can be traced directly to the bottom line.

While there are many metrics that can be employed to assess the maturity of a technology, here's one that I think is irrefutable: if folks with use the technology to manage money, it is a mature technology. To that end, I think the jury is in: Jini has come of age.