Sponsored Link •
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.
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.
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:
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):
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:
Here's the conclusion I've come to for my particular problem: I need to create a JMS/JavaSpaces bridge. This will allow me:
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.
|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.|