Strange Brew: The Blog of Warren Strange

In light of comments made comparing Jini and Indigo Craig McMurty's blog expands on the differences between the two, and concludes
In the years since Jini, though, we have learned a lot about how NOT to design those programming models, and those lessons suffuse Indigo

OK, fair enough, I didn't expect Microsoft to actually endorse Jini (although I am reasonably confident they will eventually "invent" something just like it. The benefits of mobile are hard to ignore).

There are a couple of specific points raised that are worth exploring:

A more important difference between Jini federations and Indigo applications is that Jini clients and servers share classes, whereas Indigo clients and servers only share contracts and schemas.

Not to be pedantic, but well written Jini services usually share interfaces, not classes. It's a small, but important difference. Well designed interfaces don't change often, while classes do. For example, the standard services that ship with the JSK have been remarkably stable over the years, even though the implementations have changed with each release.

Of course the nice thing about mobile code is that clients don't care about having the right version of a class installed. The implementation of the interface is dynamically downloaded. Once you grok this idea you get that "AhA"! moment when you realize the power this affords:

• Protocols are irrelevant. Clients can communicate over RMI, SOAP, HTTP, JXTA, or any other protocol you might require.
• Smart downloadable proxies allow for flexible client-service interaction. The proxy can be a thin veneer (like a web service) that calls out to the service to perform all of the work, or it can be "smart", and offload computation and bandwidth from the service. The WS-* folks like to remind us that it's all about "loosely coupled" services. Yes - this is a good architecural choice for many systems - but not all. Jini lets you build for both design centres.
• Jini supports multiple implementations of a service interface with varying QoS attributes (confidentiality, availability, performance, etc.). Clients don't have to change their code to change QoS - because the code is downloaded to their VM.

Indigo is considered "good" because it decouples the service code from the description of the service. I understand the essence of the argument - but I don't buy it. The service code might be decoupled - but you have introduced a very complex configuration language (WSDL and assorted goodies - whose spec weighs in at several hundred pages). And there is no free lunch afforded by describing services in XML. Your purchasing service still needs the right code installed that understands the semantics of an invoice.

Jini has it's own service description language. It's called a Java. It's simple, elegant and powerful. Mobile code allows Jini clients to gain isolation from at least some of semantic details of the service. The code behind the interface is never "installed" by the client, rather it comes dynamically as required. A nice side effect is that the client always has the "right" version of the code.

Jini components connect to each other via the initial intermediation of a service locator, which compromises their autonomy, for they are tied together by the service locator in just the same way that COM components are tied together via the registry.

Well components have to find each other some way, don't they? One could also say that WS-* clients compromise their autonomy because they rely on SOAP and UDDI for discovery. Once again, Jini's solution is simple, consistent and powerful. It's also not fair to compare Jini's lookup service with the COM registry. To be best of my knowledge COM has no notion of service registration leasing, lookup based on matching interface type, and so on.