Many people ask me the following:

What’s the difference between JMS and JavaSpaces?

JMS is essentially a “one-way” comunication technology - fire and forget. Hope that someone on the other side accepts the message and does the right thing with it. This is okay for many things in particular certain aspects of financial systems.

JavaSpaces can certainly support this “one-way” pattern but they are designed to be more generic which means you can use them for JMS-type applications but they might not be the best choice. The key difference comes down to the fact that JavaSpaces can support a more “interactive” style of communication, typically two or multi-party, single or multi round bi-directional “conversations” which explains why they are a favourite for master/worker patterns. JavaSpaces can also be a potential solution for cases where a JMS approach is suffering from “topic explosion”.

Many people get hung up on JavaSpace.notify() because it is “not reliable”. This needs careful explanation - most JavaSpaces will endeavour to deliver all appropriate events to a client. If the client becomes permanently unavailable (NoSuchObjectException) further events will not be delivered to it.

A client that is temporarily unavailable might not receive all events with this typically occurring due to network partition. Those applications that can’t tolerate such loss tend to be deployed on reliable networks with backup infrastructure to ensure no events are lost. It has to be done this way because even JMS implementations have finite storage and if a network is down too long, there is potential for overflow leading to lost messages.

As of JavaSpace05 a client can figure out what events it missed by re-registering for notify and then using contents to locate any messages not received. Typically, such messages are leased so the client must return within the leased time period but that could be as much as 24 hours. The reason for leasing the messages is to automatically clean them up after a period of time.

Clients of JavaSpace.notify() have an additional option which is to have all their events routed to an EventMailbox located (in network hop terms) close to the JavaSpace which they can then receive events from (and as of Jini 2.1 you can have those events pulled by your client).

Update: Updated the last paragraph, as of Jini 2.1, clients can pull events - shame on me for getting that wrong.

Cedric has been playing around with distributed testing. And it’s generated quite an interesting discussion. He’s obviously been thinking about it some given various of the issues he raises and wants feedback on.

For me, the highlights are the bits about remote class loading, load balancing/management, slave location etc.

I can certainly think of one technology that others have used for tackling these kinds of issues and it’s even been used in another distributed test platform and a build system

Cedric seems to be working from first principles here so it’s going to be fascinating to watch where this goes and the solution he adopts.

Sleepycat have been busy creating a new developer area. I think this is a good step, alongside their adoption of blogs etc.

They’ve also started up what they call a Community Recognition Programme and would you believe it, there I am under the Advisor and Leader categories. I’ve been using Db in it’s various forms for Blitz JavaSpaces, submitted patches and contributed some advice to the lists but I hadn’t expected any thanks.

So the other day, I received an email thanking me for my efforts, pointing at the recognition page and requesting my mailing address. Cool, I thought and in the snail mail this morning arrived a couple of t-shirts courtesy of Sleepycat. Not a bad reward for doing something that I enjoy.

Sleepycat have a bunch of quality products but the best thing about them is that they are very much a human company. If you need an embedded database with good tech support and a friendly sales team check them out.

As I’ve said in a previous posting, I’m not a fan of infrastructure level clustering. It basically comes down to the fact that this kind of approach to resilience and scale is achieved through centralization and strict control of the environment. Whilst such a level of control and centralization might be possible in certain well-defined, small scale circumstances, it gets much more difficult across a network of any size and with any more than a few machines.

There are other problems too like the fact that clustering in this fashion is infrastructure specific not application specific. Basically, the infrastructure will offer you configuration options that fit with what the infrastructure can support/implement generically in an application unaware fashion. You must then fit your application around what the infrastructure will offer which can mean design or performance compromises or maybe maintenance load (hand-holding by system admins etc).

There can be no argument that many adopt this approach and accept the compromises and for a certain class of system, as I’ve said, it’s probably acceptable. However, the typical profile for most systems is that they grow and evolve over time such that those compromises you made are no longer acceptable or viable. They become an albatross around the architects neck. Witness the number of people entrenched in battles to get scaling out of application servers or to add new services etc.

This approach to clustering often goes hand in hand with the denial of the realities of networking. It’s often assumed nothing breaks, there’s always enough bandwidth etc. And everything is coded like it runs in one JVM creating a single difficult to manage monolithic piece of code (something I find ironic given that the people that adopt this approach quite often talk about loose-coupling, service oriented architecture, networked applications etc) which is deliberately naive of it’s under-pinnings.

In an ironic twist, the people that choose to build things this way then throw their hands up in horror and complain when things become difficult to scale, or they haven’t got the level of control they want or they don’t like the way their code has turned out or whatever. What did they expect? They turned all these responsibilities over to some vendor’s software stating “I don’t want to deal with that, you handle it, just tell me what to do” and then in the very next breath said “why on earth did you tell me to do it that way?”

So if I don’t want to suffer this, what might I do? Start looking at building more modular, network aware modules which can be dynamically interlinked at runtime. And find a way to achieve resilience/scale at application level using simple unreliable components. I said in my previous posting:

“I can’t help but feel that there must be a better way……..”

Yep, there is - and I have a prototype to prove it. And, in case you’re wondering, yes the prototype does have persistent state and no it doesn’t require RAID or any other cool hardware, a bunch of blades on a network is all that’s needed. And of course, it uses Jini.