Sponsored Link •
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
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
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
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.