Page 1 of 4  >>

Advertisement

Summary

Secure large-scale Java distributed computing is at the heart of the 2.0 Jini release. Every aspect of building a secure distributed computing environment is configurable in Jini. However, that freedom introduces a new set of choices Jini developers and service deployers must make. To ease that complexity, Jini 2.0 introduces a service configuration model. Instead of the configuration language du jour - XML - the Jini model uses Java objects to configure complex services and their clients. This article provides a tutorial on using the Jini service configuration model, and also illuminates the decisions by the Jini architects to rely on objects, rather than on a document model, for service configuration.

Jini 2.0 offers many new tools to the developer. Not only do these tools help you build highly secure distributed systems, but they also make developing and deploying Jini systems easier.

Before illustrating the key new Jini 2.0 tools, I'd like to mention that you do not need to change your pre-2.0 services' code to run those services on the latest version of the Jini starter kit: You can run those services unmodified by simply adding jar files to your classpath and JDK ext directory.

The most important reason to take advantage of the new Jini tools is to add security to your services. Every aspect of securely deploying and using a Jini service is configurable in Jini 2.0. That includes your choice of a communication protocol, including protocols based on a new, security-conscious implementation of RMI, Jini Remote Method Invocation (JERI). Because the level of security your services need often depends on the environment those services run in, security-related attributes are not hard-coded into Jini service implementations and clients. Rather, Jini 2.0 defines a configuration mechanism to assign security features to Jini services at deployment time. This article provides a tutorial on the new Jini configuration framework. While the primary use cases for classes in the net.jini.config package are related to configuring security, the framework is flexible enough to configure any aspect of a Jini service. You may prefer to use that new model to configure all runtime attributes of your services instead of relying on ad-hoc property files and system properties.

Runtime Configuration of Jini Services

A normal Jini service or client has a number of aspects that are best determined at deployment time. I use "aspects" here in the traditional English sense, not referring to aspect-oriented programming. By deployment time I mean the time when the service/client is run, instead of the time of application development. These aspects include the groups and locators to use, where to persist state, what lease durations should be granted, and what codebase to use. Prior to Jini 2.0, these settings were controlled by a number of ad-hoc mechanisms, including command-line arguments and system properties.

The 2.0 release of Jini introduced a number of new service aspects that should be determined at deployment time. These include the implementation of Java RMI to use, the constraints to employ when making remote calls, the transports and protocols to use for discovery, or what JAAS subject to log in as. These configuration items are best represented by non-trivial objects that would be hard to derive from simple string properties and command-line arguments.

Version 2.0 of the starter kit introduces a new model for addressing this issue: net.jini.config, which I will henceforth refer to as the config model. The config model allows a developer to determine what aspects of a Jini service are controlled by the person deploying the module. The developer can define Java objects for those configuration options. Those objects are then loaded into a Jini system at runtime.

Page 1 of 4  >>

Spontaneous Networking | Jini Community News | Discuss | Print | Email | First Page | Previous | Next