Summary
I started working on this text several months ago after attending JavaOne. I originally had many disjoint topics wound into this, and tried to separate them into some other blogs. Hopefully you can make sense of the text here.
Advertisement
Jini - Sun's greatest Java technology
I had a great time at JavaOne this year, meeting with many people involved in the Jini community.
I also got to meet with the great folks from the Jini Technology development group at Sun Microsystems. I still keep relearning how much I appreciate the knowledge and the professionalism of the people in this community!
If you aren't using Java, then Jini may not seem very important to you. And, based on some of the comments I heard at JavaOne, there appear to be a sizeable number of Java developers that still don't understand Jini.
I believe that everyone developing distributed applications could, and really should benefit from the technologies that are encompassed in the Jini platform. The clincher is that many people still don't seem to want to make the commitment to the Java platform. If you still think that you can't use Java for your application, I encourage you to read my other Blog on why you should choose Java technologies for your
networking applications and more importantly, for your distributed network applications.
The Sales Pitch
Let me introduce you to Jini, or perhaps what I say below will be a refresher or clarifier to help you understand the power of the Jini platform.
The Prominent Features of Jini
There are of course the 7 (or 8 if you are serious about this stuff) falacies of distributed computing. Jini addresses more than 1/2 of them by providing some very powerful tools. The following sections highlight the capabilities of the tools in Jini.
Leasing
If you are not making sure that things have some limit or time constraints applied to their use by others, you will suffer with lost or limited resources everytime you have network or computer failures.
Transactions
Hand in hand with leases are transactions that will allow distributed systems to know that everyone agrees on the state of the system as a whole.
Notifications
In a distributed system, polling does not scale. You need to be able to be told about what is happening, when it happens, to make the system responsive to changes in the environment.
Mobile Code
Many newer distributed system technologies are not exploiting mobile code. JXTA for instance, uses XML messaging. It standardizes on a wire protocol, instead of a programatic interface. SOAP utilizes the same principles of compatibility on the wire. The end result is that everywhere these protocols are deployed, someone has to write code and integrate the actions of that protocol into the actions expressed by the payload. If mobile code was used, the capabilities of the object would come with the object.
Some people fail to see the simplifying details of this notion. Many others, are of course, paralized by the notion of letting someone else provide code to run. When you are just pushing data around, and all you have on your mind is storing some data into a remote database, or reading data from a remote database, you can certainly feel comfortable with just sending data.
With peer to peer networking finally coming of age, we need to get beyond data. The power of object mobility is the fact that the wire protocol from the object back to the server or other peer no longer needs to matter! Instead, each object can exploit whatever wire protocol is needed. A streaming audio or video application might utilize a protocol that either secures the content, or compresses it. An application needing peer authentication and authorization for access, can utilize an appropriate protocol.
When everything is controlled by the wire protocol, new requirements, such as security, integrity, bandwidth conservation can create real problems. The protocol might be versioned requiring updates everywhere to support the new version, or some type of tunneling might need to be laid over the top of the existing protocol. It is a given that applications and protocols will change over time. Perhaps if a protocol can't change, it becomes stale and is replaced slowly but surely with an extreme cost. So, it seems silly to believe that the API or wire protocol will be right the first time.
If, instead, we describe the application as a Java interface, we get several very important benefits which include:
The application uses a programatic interface that can include versioning through subclassing to
provide a natural, programatic control of new functionality. Applications wishing to use new functionality can see it in the mobile objects class structure.
The implementation of any part of the API can be optimized or otherwise changed in implementation without the application having to change. This is very important when the application source is not available, or the cost of changing the application in terms of system stability and integration costs is too high.
The implementation of part of the API might be moved from local to remote or vice-versa without the application being aware of the change. This allows the complexity and servicability of the application to change overtime in a way that the applications will/do not have to be directly aware of.
There are of course many issues associated with mobile code, including security. The Java platform, and more importantly the changes in Jini 2.0 solidify the security model to the point that there is the capability of keeping out all unauthorized code. Bad programming practices in Java still allow runaway CPU use and runaway memory consumption. Denial of service attacks are certainly possible at the network level, and at the OS networking interface (and this is a great example of why the protocol on the wire should not be what that applications are tied to.
In many operating systems, such as UNIX based operating systems, there are provisions for limiting process resource consumption. The use of Java doesn't present any less control over poorly written software, related to these issue, than a native language such as C or C++. So there are few arguments that hold water in the are of the operating system interfaces from Java, and the JNI interfaces are still an option which utilized with some thought can provide little attachment to a particular OS.
Jini 2.0 Provides Many Solutions
The new version of Jini, is called version 2.0. This dramatic upgrade includes support for secure RPC. Originally, the basis of Jini 2.0 was presented to the Java Community Process as 2 JSRs. One for providing a flexible, upgrade to the RMI infrastructure so that plugable protocols could be used behind the scenes. The other JSR was to provide the security implementation that is in Jini 2.0. The JCP failed to recognize the tradeoffs provided in the original JSRs as an important step, and rejected the JSRs in a demonstration of the political nature of many organizations that have paid for participation.
The Jini 2.0 security model has all of the foundations that provide:
Authentication - You can demand to know the identy of your peers
Authorization - You can specify who can do what
Integrity - You can make sure that you have what you were sent
The J2SE security model is leveraged for its contributions. The JSSE support for SSL (and other transport security implementations therein) are used in the Sun contributed implementation to provide data security and authentication. The JAAS framework is available for Authentication control. What Jini2.0 provides on top of all of these is a new transport protocol for the RMI framework called Java Extensible Remote Invocation or just JERI.
JERI provides the plugable architecture that allows some important things to happen.
The application exporting the RMI proxy/stub can dictate constraints on the use of that stub.
The receiving application can dictate the information and authentication they are willing to reveal to use a particular remote interface/object.
The client can dictate that integrity be provided so that SSL, Kerberos or similar capability is brought up automatically.
The client can request that the server authenticate.
The client can demand that the proxy be validated before it is used, utilizing code that is not downloaded, so that the integrity of the proxy can be guarenteed through a programatic analysis.
The httpmd: url protocol handler allows jar file integrity to be validated using MD5 checksums. Thus, in transit tampering can be detected.
What this means is that you can start solving the real problem that you have, instead of spending a year trying to develop the mechanisms to keep your distributed application bullet proof.
Okay, the security exercise still involves analysis of what you are exposing where, but the tools are in place to allow you to control that exposure, and to thus minimize the risks.
Immobility
The most amazing thing about immobile code is the shear volume of work that it creates everywhere. By demanding that there be no code, you require everyone, everywhere, to be prepared to create the effects of the information specified by the wire protocol, before they can start working on the real application. Now,
clearly protocol libraries get created in particular languages for a particular or a wide range of operating systems.
The bad thing about compiled, static libraries is that they distribute bugs everywhere, and don't provide for any automated way of fixing problems everywhere. Everyone must be able to get the updated library and compile it into their software, or rely on a vendor that used that library to provide the update. This creates way to much diversity of bug fix implementation. Before long there can be variations that cause new problems or expose existing problems more readily.
SMTP and POP are great examples of wire protocols embedded into applications that are not extensible. As soon as SPAM hit the scene, wouldn't it have been nice to have just turned on AUTHENTICATION.YES on your POP3 interface and thus demand that the server only provide you email from identities that were real?
Previous Topic
