Cool questions:

Okay so, I’m aware some people have put a query facility on top of the JavaSpaces API and it does indeed muddy the waters. I guess their philosophy is to make a JavaSpace a “jack of all trades” which is the opposite of mine hence my original scribblings on the differences. IMHO, many a Java framework attempts to be “jack of all trades” and the result is horrible API’s, horrible configuration, horrible complexity in general.

Random thoughts:

LRU policy - you don’t have a guarantee that any space implementation actually does have such a policy or even uses caching.

Querying - most RDBMS’en have advanced query optimizers to accelerate performance - JavaSpaces don’t really yield to the same approach. In the case of the vendor I think you’re talking about, they’ve actually built their implementation on top of an SQL database with it’s associated advantages and disadvantages.

Do one thing well - I wouldn’t use a database as a substitute for a JavaSpace or vice versa, nor would I try and “have it all” in one thing. Especially in the context of SOA but in decent architecture in general, the “do one thing well” mantra yields better results. “Have it all” often leads to a compromise which loses you the key benefits of each and messes up your architecture as your system gains features over time. However, I have actually combined RDBMS and JavaSpaces as discrete components for certain kinds of system. And of course, I’m not going to say that my way is the only way!

Request for feedback:

I’d be interested to hear why you would like to avoid having both a JavaSpace and an RDBMS - is it architecture, license cost, machine cost or something else?

Non clustered HA solution:

Bits of this are being tested out with various of my customers in different kinds of deployment. I’m busy figuring out the best way to package it all up and make it available.

I could just supply it as a framework but getting the documentation right etc is difficult. I’m tempted to express it as a collection of design patterns - whether that’d be in book form or something else, dunno. I’m also thinking about providing it as part of some Web 2.0 style offering.

This muddies the purity of the statement that JavaSpaces is “snapshot of a set of conversations between multiple senders and recipients” because one could use the “space” as a database, relying on the persistent space with LRU eviction policy to keep the “working set” reasonable.

I have been tempted to “abuse” spaces in just that way so that both an RDBMS and a space are not needed. What do you think?

Also, I hope you will reveal more about your non-clustered HA solution!

thanks again,