Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Java's creators have often highlighted the JVM's three biggest benefits: automatic garbage collection, built-in security, and the ability to load classes from any network location. Automatic garbage collection is now taken for granted in most modern programming environments. However, network-mobile classloading and the Java security infrastructure have evolved on separate, parallel paths. As a result, completely satisfying the security needs of distributed systems based on mobile Java code has thus far been impossible. Jini's security model extends both Java's mobile code and security features, and combines their strengths, enabling secure distributed computing with mobile code.
The Jini security infrastructure has been in the works for almost two years. Starting in 2001, Sun's Jini team took the unusual step of releasing periodic snapshots of the early specifications and implementation to elicit feedback from the Jini community. Since then, the security project has also been a Jini community effort under the project name "Davis." At the time of this writing, the specifications resulting from Davis are winding their way through the Jini Decision Process. By the time you read this, most likely, both Jini community houses have approved the specifications, and they have become official Jini standards.
While no special contract or license prescribes the use of the new security model, many in the Jini community believe that security-conscious Jini projects will use these new specifications and APIs. The new specifications form the key innovations in Sun's Jini Starter Kit (JSK) 2.0. Thus, I refer to the security framework in Sun Microsystems' JSK 2.0 as "the" Jini security framework, even though other security-related Jini projects may spring up in the future. In this article, I describe the Jini security model and give you a taste of the new security-related APIs.
Perhaps the best news about the Jini security framework is that it requires few changes to existing Jini services. Instead, it defines security as a deployment-time option. If you have an existing Jini service, you can take advantage of utilities in the new JSK to deploy that service securely. Jini security, therefore, shares that similarity with J2EE (Java 2 Platform, Enterprise Edition) security—it primarily belongs to the domains of system architecture and administration.
The basic unit of a Jini service remains the service proxy you register in lookup services. When clients discover that proxy—based on the interfaces the proxy implements—code for the proxy object not already available at the client downloads into the client following RMI (Remote Method Invocation) mobile code semantics. Following that, the client invokes methods on the proxy. As a client, you don't care or know how the proxy implements those methods: some proxy methods may involve network communication with a remote service implementation, whereas others might execute locally to the proxy.
The Jini security model adds three steps to that simple programming model: First, as a client, it allows you to decide whether to trust a proxy object at all. If a service proxy is supposed to represent your bank account, how do you know the proxy you just downloaded is in fact your account's proxy? The Jini security framework helps you decide that.