Thursday, December 14, 2006

Jini/JavaSpaces & Distributed Caching

We are taking a gander at some space / cache technology and looking at ideal ways to do service orchestration with it in the architecture.

I am fortunate enough to work with Patrick Logan and he has some good questions. He worked for Gemstone a while ago so he knows their are opportunities to hurt oneself if one chooses unwisely.

I like JMS enough, but it has its issues. If there is a better, simpler way to do service orchestration I'm all ears.

Master/Worker with spaces might work. What else?

I like location transparency. It’s neat.

Update 27-DEC-2006 Just tickling your RSS reader - some good comments on this post. Please chime in if you have an opinion. I am becoming fascinated with this topic. There are a lot of parallels between SBA/distributed caching and EDA service orchestration models. I'm spending some time getting my hands dirty trying to get my head around it better.

13 comments:

waffletchnlgy said...

Take also a look at the Data Distribution Service (http://portals.omg.org/dds). You'll also find a comparison between DDS and JMS (http://portals.omg.org/dds/WhitepapersPage?action=AttachFile&do=get&target=Comparison_of_DDS_and_JMS.pdf)
It might not fit all your requirements, but I suggest it's worthwhile to take a look and understand this new data centric technology.

Unknown said...

I would like to understand more of your requirements on "service orchestration" before I suggest a particular solution. Also, I responded to your email (thanks :-) and hope it helps explain my point of view on the subject.

Peace.

fuzzy said...

Hi Cameron,

On the service orchestration - pretty standard stuff.

Request/Reply, Async Request/Reply, Fire/Forget, Pub/Sub (Events).

In terms of the actual service orchestration, I am thinking of things like content based routing, itinerary based routing, etc. I'm not talking about things like BPM etc.

If we have to use JMS that is ok - I know a lot about that. But I'd prefer to avoid the layering of middleware if there is a simpler way to do it with either Coherence or JINI/JavaSpaces (e.g., master/worker).

Mr Pickles said...

Hey Fuzzy,

care to expand more on what you mean by "service orchestration"? Is that what might be thought of as "workflow" in other areas, or have you something more specific you're meaning here?

TOby

fuzzy said...

Hi Toby, thanks for the post. Did you see my response to Cameron above yours?

I do not mean BPM engine etc. Just basic orchestration. The systems I work on typically have many services. It is not uncommon for 1 click in a browser to result in 5-10 service being called.

I am very familiar with concepts like content based routing and itinerary based routing from messaging and ESB type architectures.

From learning more about JavaSpaces, I know that you can use Templates to do the same thing as content based routing. Basically as fields change on an object in the space, different services are notified (per how their template is set up). I believe that Coherence has the same concept with continuous queries.

I'm looking for what technologies / patterns etc. people are using with both Coherence and Jini/JavaSpaces for this type of service orchestration.

Anonymous said...

Fuzzy

You can find more details/patterns on how JavaSpaces is used for service orchestration here. It outlines patterns for using Space Based Messaging for point to point communication, publish/subscribe, Content Based Routing and Workflow.

There is an interesting code example that shows basic workflow scenario for order processing service and the way it works with space based matching template.

I would also recommend that you would look at our Mule (POJO Based ESB) paper.It provides broader context for using Space Based Architecture as part for high performance and light weight ESB using a combination of JavaSpaces and Mule.


I also think that you would find the following presentation that was given at the latest JavaPolis event:
"Everybody talks about SOA but how the hell do I build the damn thing in a high performance-stateful environment?" It provides an interesting walk through discussion on SOA patterns in general and how Space Based Architecture can be used to build scalable and SOA using light weight ESB patterns based on spaces.

Note that in all the references provided above the term SOA is very different then the classic WS* definition. It refers to SOA as a generic model for building loosely coupled applications.


I'm sorry for throwing all those links at you. I'll be happy to answer your specific questions directly if you're interested. Feel free to contact me if you need more information on that topic.


Nati S.

GigaSpaces

Erik Onnen said...

Cheers to Gigaspaces for doing a great job documenting the messaging patterns and producing the nice drawings. I fell obligated though to point out that there is *nothing* unique to Jini or JavaSpaces that better enables them to implement these patterns over any other distributed, associative memory arrangements. All of these patterns can quite easily be accomplished using either Tangosol's Coherence or JBoss Cache. To say that these are unique benefits of Jini or JavaSpaces would be inaccurate.

The power in these patterns comes from the fact that you have a reliable system of shared data exchange with low impedance at the API level, especially when compared to traditional JMS. The power is not from using Jini or JavaSpaces per say.

Anonymous said...

Hi Erik

I wanted to have better understanding of your statement below:

".. there is *nothing* unique to Jini or JavaSpaces that better enables them to implement these patterns over any other distributed, associative memory arrangements…"

Without referring to vendor specific enhancements were talking on two alternatives: DHT (Distributed Hash Table) and JavaSpaces right? I already outlined how spaces can address different messaging patterns. I honestly fail to understand how those patterns and even the simplest one of them, (point to point) can be address through DHT model. If I use dht.put(key,value) and dht.get(key) i'll get the current version assigned to a specific key. i.e. you can have multiple put operation that will be red by the receiving party as a single get/remove which is not what your looking for in point to point communication. I think that this is a good opportunity to introduce you to some of the unique characteristic of the space API vs DHT on that regard:
Template based matching provides more fine grained matching which include matching over class hierarchy and attribute values, blocking operations which enables you to wait for the arrival of specific object, in our case this will be waiting for any item in an associative queue. The matching semantics of spaces enables you to take (in sequence) more then one match for a specific key/template which is essential to address the point to point scenario mentioned earlier. In addition to that the template based matching provides associative means for achieving content based routing etc. This is only a very small list of the differences but I think that the point should be clear by now. The point that I wanted to make is that the space does exposes specific semantics that makes it more suitable for messaging scenarios.

At this point of the discussion I wanted to note that we support both the DHT API and the Space API, we also support JMS as well as JDBC since we believe that there are cases in which one API would have benefit over the other based on the specific scenario and application need. We felt that it wouldn't be right to dictate only one model. I hope that this also indicate that I'm not necessarily biased to specific API vs the other. We simply found that relying on the space model as the core model for implementing all the variety of the API's is the right approach since we view the space API as the superset of them all.


HTH
Nati S.

Erik Onnen said...

Nati,

You certainly covered a lot of ground, but unfortunately it's not the ground laid out in my OP.

"Without referring to vendor specific enhancements were talking on two alternatives: DHT (Distributed Hash Table) and JavaSpaces right?"

No, I never said that. I never claimed to compare JavaSpaces and the generic Map API for DHTs, I was comparing JavaSpaces to products provided by Cache vendors of which I name two.

"If I use dht.put(key,value) and dht.get(key) i'll get the current version assigned to a specific key. i.e. you can have multiple put operation that will be red by the receiving party as a single get/remove which is not what your looking for in point to point communication."

May not be what you want, but it's exactly what I want. If an entity in the architecture has updated the value of that key, the consumer should see it when it takes the value of that key. If you are adding a new message to the map, it should not be added with the same key but rather a new key (it's a new message after all). I'm not sure I see the point to your example. If I want to override a value I replace the value using its key. If I want to enqueue a new message, I use a new key. Unintentionally overwriting an existing value by reusing a key would be a programming error, just like putting the same object into a space five times when you didn't mean to. This is an issue of programming idioms not APIs.

"Template based matching provides more fine grained matching which include matching over class hierarchy and attribute values"

As you describe it here, there it is no different than simple map behavior for my purposes. If I want to match an object in the map using this technique, then I simply use the same object for the key and the value with a proper hash and equals implementation. However, this is relatively primitive and the more powerful vendor features that allow me to search the map are preferred for their expressiveness. The ability to write a behavioral match implementation (ala Java Comparators) is far more powerful than simple template matching.

"blocking operations which enables you to wait for the arrival of specific object, in our case this will be waiting for any item in an associative queue."

Your term "queue" implies an ordering to the messages, that I believe would be beyond the JavaSpaces specification and a GigaSpaces-specific feature. I'm sure there are many great ones, my point was to compare Cache Products vs. the JavaSpaces specification. Note also that vendor APIs provide this very behavior for watching a map in a blocking manner and sorting the results according to delivery order if desired.

"The matching semantics of spaces enables you to take (in sequence) more then one match for a specific key/template"

Again, easily accomplished using vendor provided APIs for enumerating cache content with comparator-like behavior.
Alternatively, simply place a list as your key value when using a map, get/add to list/put. Again, as I mention above, this is not a part of the JavaSpaces specification so you've gone beyond the scope of my OP.

"which is essential to address the point to point scenario mentioned earlier."

That depends on the nature of the service but it's not a given. For a stateless service that has no business drivers for time-sensitive processing, this is not essential. For higher-level event processing, ordering is often irrelevant. As already mentioned though, this is not a guarantee that JavaSpaces makes, perhaps GigaSpaces but not JavaSpaces.

Anonymous said...

Hi Erik

"I never claimed to compare JavaSpaces and the generic Map API for DHTs, I was comparing JavaSpaces to products provided by Cache vendors of which I name two."

Thanks for the clarification.
If that is the case, then I don't think that it would be appropriate of me to comment on other products.

Nati S.

Anonymous said...

Hi Eric,

"Cheers to Gigaspaces for doing a great job documenting the messaging patterns and producing the nice drawings. I fell obligated though to point out that there is *nothing* unique to Jini or JavaSpaces that better enables them to implement these patterns over any other distributed, associative memory arrangements. All of these patterns can quite easily be accomplished using either Tangosol's Coherence or JBoss Cache. To say that these are unique benefits of Jini or JavaSpaces would be inaccurate."

If all that you do is use Jini/JavaSpaces in the same way that you use all the other products you mention above then, there is indeed little difference and therefore little benefit.

But, if you design to take advantage of Jini/JavaSpaces broad support for moving code around at runtime (that is sharing code not by default available on the classpath of all JVM's that may encounter that code at runtime) then your system will look rather different from what you would get with other products.

For example, deployment and upgrading can be easier. Addition of new functionality can become easier. Your JVM's are more loosely coupled because they can obtain new implementations for existing types as the system continues to run. Thus you can change one part of your system and not have it induce knock-ons elsewhere.

Basically, if you use Jini/JavaSpaces to implement a conventional cache or a conventional message bus, you're doing what you've always done the way you've always done it with the same results you always get.

Dan Creswell
http://www.dancres.org/

Anonymous said...

How about trying out Fiorano's Service orchestration tool ? www.fiorano.com But it does involve a middleware based on jms. Its orchestration seems robust to connect to a variety of tools and services and also creating your own ...

fuzzy said...

re: Fiorano - perhaps if I wanted an ESB, but I don't.