Indigo and Jini

Some folk who read David Chappell's excellent article on Indigo found Indigo to be reminiscent of Jini. Let me mention just two of the fundamental differences. 

I think that service is a good word to describe what you build with Jini, although I think we can all agree that the customary meaning of service has changed a little since Jini debuted several years ago. I don't think there is much debate that when we use the word, service, today, we are generally referring to software designed in accordance with four tenets that Don Box enumerated several months ago: that the boundaries are explicit, that they are mutually autonomous, that they share contracts and schemas rather than classes, and that their compatiblity with one another is made explicit in the form of policy. The "services" that one can construct with Jini do not conform to any of those four tenets, whereas one of the express purposes of Indigo is to make it simple to build software in accordance with them.  

The two key tenets that differentiate Jini federations from Indigo applications are mutual autonomy and sharing only contracts and schemas, not classes. Concerning mutual autonomy, 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. Naturally, an Indigo client and server need to know where each other are located, and how to talk to one another, but they can do that in any number of ways ... because they are natively independent. 

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. In particular, Jini clients communicate with Jini servers via proxies that run within the client's Java Virtual Machine, and those proxies are constructed from definitions of classes that match class definitions resident on the Jini servers. That characteristic is readily apparent in Jini code, such as this snippet which orginates from elsewhere:

package nonworking;

public class TestUnicastFileClassifier {

    public static void main(String argv[]) {
new TestUnicastFileClassifier();
    }

    public TestUnicastFileClassifier() {
LookupLocator lookup = null;
ServiceRegistrar registrar = null;
FileClassifier classifier = null;

        // Prepare for discovery
        lookup = new LookupLocator("jini://www.all_about_files.com");

        // Discover a lookup service
        // This uses the synchronous unicast protocol
registrar = lookup.getRegistrar();
// Prepare a template for lookup search
Class[] classes = new Class[] {FileClassifier.class};
ServiceTemplate template = new ServiceTemplate(null, classes, null);

        // Lookup a service
classifier = (FileClassifier) registrar.lookup(template);

        // Call the service
MIMEType type;
type = classifier.getMIMEType("file1.txt");
        System.out.println("Type is " + type.toString());
    }
} // TestUnicastFileClassifier

It should be apparent from this code, that, with Jini, one is using an object about which one knows everything, from a remote location. With Indigo, by contrast, one's clients typically know absolutely nothing about any classes on the server, save for a neutral description of an interface, the implementation of which presumably delegates work to those classes. This distinction has profound implications for how one programs Jini and Indigo applications. Using Jini, one aims to distribute objects; using Indigo, one aims to "outsource" work to an automated service. 

One must grant though, that a primary and very good idea behind Jini lives on in Indigo. That idea is that there should be an excellent, simple programming model usable across any kind of networking infrastructure. In the years since Jini, though, we have learned a lot about how NOT to design those programming models, and those lessons suffuse Indigo.