Summary
Rather than speak in vague generalities lets go through two specific overlapping APIs - JavaSpaces and JMS - and think about what a unified version would look like.

Sorry it has taken me so long to get back to this topic. I actually had a lengthy blog written and pretty much ready to go, but decided against posting it. The intent behind that blog was to elaborate a process for generating the decision tree I discussed in my last post. Unfortunately, it came out sounding priggish, pretentious and process-enamored (not to mention alliterative). I'll probably post it later anyway, but was prevented from doing so this week by the intrusion of some real design problems. Musing on these gave me the topic for this posting.

Electromagnetism, JavaSpaces and JMS

As a TIBCO/Rendezvous programmer of long standing, I've developed some facility with the publish/subscribe model and I was attracted to JMS as soon as it was announced. That background prevented me from understanding the proper use of Jini/JavaSpaces (going back to the Java Shared Data Toolkit) for quite some time. Over the past year, however, I've been working on problems which are best suited to JavaSpaces and as a result have come to understand that these two APIs are two sides of the same coin in the same way that electricity and magnetism are simply manifestations of the single underlying phenomenon described by Maxwell's equations. (As you can probably tell, I'm going to wear this physics analogy right down to its nub, so you'll just have to bear with me until I've gotten it out of my system.)

Since I've been thinking about some specific problems with these two things a lot this week, I'm going to take this opportunity to toss my thinking and a cleverly disguised version of my current problems out into the blogosphere and then listen to the echo rattling around.

Getting on Topic

I won't go into the specifics of the two APIs here since about two minutes with google will give you any number of citations of people (including me) doing a compare and contrast exercise on them. Suffice it to say that I perceive the main differences to be:

1. JavaSpaces has the “take” primitive that allows a message to be consumed by a single “subscriber”, JMS does not.
2. JMS matches messages on string-based topic names, JavaSpaces matches on Entry objects.
3. JMS dispenses with a centralized server and its associated infrastructure while JavaSpaces requires it.

Apart from these differences, both JavaSpaces and JMS are basically Message Oriented Middleware (MOMs). Each allow an application to asynchronously be a message source and/or message sink and neither intrinsically allows a message source to be aware of which sinks may have consumed a source's message.

I've used both Jini/JavaSpaces and JMS now for computationally intensive tasks and have found the following (and this gets us back to the topic of unification):

1. To completely implement the Master/Worker pattern, I need additional glue code on top of either of the two APIs
2. JavaSpaces needs a way for me to group entries in the space: I end up sticking a string in each entry that represents a group and I end up formatting that string so that it can be decomposed into something tree-like (e.g. org.worklet.lifescience.proteinfolding.simulation, org.worklet.finance.instrument.valuation). That string looks an awful lot like a JMS Topic to me.
3. JMS needs a way for me to make sure that my compute tasks aren't being duplicated: I end up typically using a database to register the state of a compute request and resolve race conditions. Basically, I let my SQL database play the conflict resolution role of JavaSpaces.
4. JavaSpaces needs fail over/replication/load balancing, this comes “for free” in industrial strength JMS implementations.
5. JMS needs a server to retain current state of any topic, this comes “for free” in industrial strength JavaSpaces implementations.
6. Both APIs lack an infrastructure out of the box to allow me to query worker state or explore the topic space (i.e. Find out what topics have people subscribed to them).

E pluribus unum

You can probably see what I'm getting at here. The two APIs target subtly different problems, and are actually quite good at dealing with the problems they are designed to handle, i.e. they greatly facilitate the use of specific design patterns associated with at those problems. Specifically: pub/sub engines with JMS front ends are gratefully used all over Wall St. to deal with the absolute flood of market data that runs across a trading floor. Space-based implementations have been helping folks with numerically intensive problems for about as long. JavaSpaces and JMS were both created in a sense to make sure that the Java platform had "coverage" of these two application spaces.

But as soon as I go to address my problem (via the Master/Worker pattern) I find that I can use either (in fact both) of them - provided I'm willing to add the necessary quanta of energy involved to move the APIs to the next level. From a “putting my kids through private school” vantage point, I appreciate there being problems out there like this - but the fact of the matter is that Master/Worker is a well-understood pattern whose use I think will grow substantially in the near future. As a result, I would argue that there ought to be a Java API which hides the implementation details of this specific pattern. My feeling is that such an API would subsume both JavaSpaces and JMS and would probably be associated with Jini, but admittedly I'm a bigot about Jini.

So ideally I'd like to see Javaspaces and Jini evolve to have some features like the following:

• Connectionless pushing of Java objects into topics. Lets do the Jini code movement thing on a JMS backbone
• Services spec'd out to sit on specific topics and do JavaSpaces-like functionality complete with replication and failover
• additional services which monitored the Master, Space, and Worker services for administrative purposes.

Here's the conclusion I've come to for my particular problem: I need to create a JMS/JavaSpaces bridge. This will allow me:

1. to store JMS Topic state in JavaSpaces
2. to do a segmented replication of a JavaSpace (segmented by topics)
3. to piggyback off my existing JMS infrastructure with little coding effort
4. to load balance my JavaSpaces transparently to my clients

What's missing here is actually bigger than what's present. How do I administer, deploy and manage a rack of servers with all this software running on it? Sounds like I need to do some J2EE homework.

Talk Back!

Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Van Simmons adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Most who've heard of Van Simmons before will remember him in his former role as President of VNP Software. Since 1990, Van has usually made a living architecting, designing, writing and generally being frustrated with large systems for Wall Street firms. Originally he hacked his way about these in Objective-C on the old NeXT platform, but starting in 1996, he realized that he was flogging a dead horse and transferred his allegiance to the (then) immature Java platform. These days, Van is an employee of a firm with a lot of numbers to crunch, so he's spending his days trying to figure out how to get an hours worth of computation done in a minute of elapsed time. Venting, musing and guffawing on this topic is what he plans to write about.