Summary
Dan: Great blog entry - well said and supported. I think the discussion is pointing out some very big reasons why Jini isn't taking off: people don't get distributed computing. They just don't get it.

Here's one comment:

About Dan, he misses the point when he says "This difference in granularity is introduced because of a need to avoid network round trips". That is not the only reason, and (I think) not even the most important for avoiding distribution of objects. Designing distributed systems involves DISTRIBUTED STATE, that can cause a hell of problems and an explosion of complexity. It's not about "saving some bytes" of bandwidth, it is about consistency, simplicity (simplicity as 'avoiding unnecessary complexity'), and productivity.

I've seen this problem before. It's usually the result of writing a lot of code around managing the interactions for remote participants. It results in twisted, incomplete, custom transaction management for each and every type of interaction.

Frankly, one service should not have state dependencies on another service... if there are, why are they different services? Carlos Perez' Loose Coupling Leads to Robustness quotes an interesting paper Crash-Only Software. The interesting point ¹ is

4. Requests are entirely self-describing.

The authors George Candea and Armando Fox explain it to mean:

Requests are entirely self-describing, by making the state and context needed for their processing explicit.

This means to me that any state needed by a service ² will be included in the request either directly by including it as a request parameter, indirectly through a parameter containing a global reference, or implicitly ³ through some asynchronous mechanism ⁴.

My practical solution to this is to perform remote method calls, or groups of calls, within a Jini transaction that also contains any and all JavaSpace entries representing service state ⁵. This buys me consistency in state for all distributed participants AND fault-tolerant fail-over for when a service becomes unavailable.

So, where is the explosion in complexity? I can probably do this with less code than programmers only capable of implementing it in a "local" manner.

Talk Back!

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

RSS Feed

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

Digg | del.icio.us | Reddit

About the Blogger

R. Dale Asberry been hacking since 1978, professionally since 1990. He's certified in Java 1.1 and has a four digit MCP number. He discovered Jini at the 2000 JavaOne and has been building incredibly cool, dynamic, distributed architectures ever since! Over time, he's discovered several principles that have contributed to his success - they are the Princples of: Enabling Others, Simplicity, No Complaining, Least Work, Least Surprise, Least Damage, and "It Just Works".