Note: www.cdegroot.com is in rebuild. Please accept my apologies for broken links, missing stuff, etcetera - more
  Home

Mobile code in the Jini environment

This week I want to complete the picture of how Jini differs from other "spontaneous networking" systems by examining how mobile code helps with decoupling systems.

When a node (a computer, a device, whatever) wants to join a network it starts with sending a multicast discovery packet. It knows what it is looking for: a service registrar, defined by the Java interface net.jini.core.lookup.ServiceRegistrar. But it has no knowledge of the particular implementation it will encounter, nor where this particular implementation lives. In fact, it will never know where the service lives, because upon receiving the multicast packet, the service registrar responds by sending back a bit of code that implements the ServiceRegistrar interface - the node loads the code and starts talking to it, but has no idea how (or even if) the code talks back to the service registrar.

Think about it - all that you need is a) knowledge of the ServiceRegistrar interface, and b) some code that implements the multicast discovery, and you will be able to talk to all possible Jini service registrars, without concern for how they communicate over the network. The code you receive could talk back to a server with plain RMI calls, or it could talk back with some highly optimized TCP protocol. You don't care: just put the two tiny bits of software on the node and connect.

After you discovered the registrar, the story repeats. Say you have an XML document and a XSL stylesheet and want to convert the document into PDF. You ask the registrar for something that implements the com.foo.PdfFormattingService interface, and you get a bit of code back. Pass the documents to the code, and you get back a PDF file. Your code could look like:

PdfFile pdf = formattingService.format(xmlFile, styleSheet);

Again, you don't know what happened in this method call. It could be that you received a complete PDF formatter that locally processed the file (including jar files for the XML parser, the XSL processor, and the flow object processor). Or it could be that you got a small network client that passed your data on to some corporate server via SOAP and all the processing took place there. Or something else...

Jini allows you to concentrate on Java interfaces and, from the client perspective, completely do away with protocol concerns. The protocols are chosen at run-time, and it is up to the discretion of the service provider to select an optimal protocol. This puts responsibilities squarely where they belong, thanks to mobile code.


 
Copyright (C)2000-2011 Cees de Groot -- All rights reserved.