Getting Agile

I am working on a personal project right now where I am developing Jini-aware services. Working with a “true” SOA is quite nice once you have the mindset. There are a few areas of Jini development which still cause me some grief though:

• Jini starter kit distribution- the lack of base service startup scripts for the reference implementation which are downloaded with the starter kit bundle
• Security - the creation of policy files can be somewhat tedious
• Proxies - choosing and implementing different proxy options can also be somewhat tedious
• Proprietary configuration - this is not as big of a deal, but it would be nice to have options in this area and many have created such options (RIO for instance)

I have initiated an attempt at alleviating grief point number one above, the lack of scripts for base reference implementation services in the Jini starter kit bundle, by creating a Maven Jini plug-in which downloads the starter kit, starts the services, and generates a generic service project. Unfortunately, the next two are entirely different and complicated beasts and the last is just a personal problem.

To tackle such large beasts in a distributed system framework, such as Jini, I am thinking initially that these considerations in your services should be done at object/class level and at a service distribution level. Within a service, there is the possibility to have a complicated security policy file to describe Java runtime access permissions.

grant codeBase "file:${jiniHome}${/}lib${/}jsk-lib.jar" {
permission java.security.AllPermission;
};
grant codeBase "file:${jiniHome}${/}lib${/}reggie.jar" {
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.lang.RuntimePermission "accessClassInPackage.sun.util.logging.resources";
permission java.lang.RuntimePermission "accessClassInPackage.sun.net.www.protocol.c";
permission java.lang.RuntimePermission "getClassLoader";
permission java.io.FilePermission "${appHome}${/}example${/}reggie${/}jeri${/}config${/}activatable-reggie.config", "read";
permission java.io.FilePermission "${appHome}${/}example${/}reggie${/}jeri${/}config${/}nonactivatable-reggie.config", "read";
permission java.io.FilePermission "${appHome}${/}example${/}reggie${/}jeri${/}config${/}transient-reggie.config", "read";
permission java.io.FilePermission "${persistDir}",      "read,write,delete";
permission java.io.FilePermission "${persistDir}${/}-", "read,write,delete";
permission java.io.FilePermission "${java.io.tmpdir}jeri-reggie-log",      "read,write,delete";
permission java.io.FilePermission "${java.io.tmpdir}jeri-reggie-log${/}-", "read,write,delete";
permission java.io.FilePermission "${/}tmp${/}jeri-reggie-log",      "read,write,delete";
permission java.io.FilePermission "${/}tmp${/}jeri-reggie-log${/}-", "read,write,delete";
permission java.net.SocketPermission "224.0.1.84", "connect,accept";
permission java.net.SocketPermission "224.0.1.85", "connect,accept";
permission java.net.SocketPermission "*", "resolve";
permission java.net.SocketPermission "*:1024-", "connect,accept";
permission java.net.SocketPermission "*:80", "connect";
permission java.util.PropertyPermission "java.io.tmpdir",   "read";
permission java.util.PropertyPermission "serverHost",       "read";
permission java.util.PropertyPermission "serviceClasspath", "read";
permission java.util.PropertyPermission "serviceConfig",    "read";
permission java.util.PropertyPermission "serviceName",      "read";
permission java.util.PropertyPermission "interfaceName",    "read";
permission java.util.PropertyPermission "implName",         "read";
permission java.util.PropertyPermission "persistDir",       "read";
permission java.util.PropertyPermission "jiniHome",         "read";
permission java.util.PropertyPermission "appHome",          "read";
permission net.jini.discovery.DiscoveryPermission "*";
permission net.jini.export.ExportPermission "exportRemoteInterface.com.sun.jini.reggie.Registrar";
permission com.sun.jini.phoenix.MonitorPermission "java.rmi.activation.ActivationMonitor.inactiveObject";
permission com.sun.jini.phoenix.SystemPermission "java.rmi.activation.ActivationSystem.unregisterObject";
};
grant {
permission java.util.PropertyPermission "com.sun.jini.reggie.enableImplToStubReplacement", "read";
};

This is the policy description created by Brian Murphy for launching Reggie using his reference implementation startup scripts. By the way, this is downloaded automatically when using the Maven Jini plug-in to launch the starter kit services. At first glance of these policy files, I thought that these might be a good candidate for annotations. Then after some brief thought and a little bit of clarity I remembered what I think is a great rule of thumb for deciding on usage of annotations, “Is the configuration in question class level meta data?”. Most of the above policy declarations have to do with external resources or remote access permissions.

So, I then moved on to proxy implementation options. If you look at Chapter 11: Choices for Service Architecture in Jan Newmarch's Guide to Jini Technologies you will see a large selection of proxy implementations depending upon your need to do all processing on the service host, some processing on the service host and some on the client side, or move all the code to the client for processing. Another variable in the proxy implementation decision could be whether you want to use RMI or not. The introduction of JERI as the preferred RMI implementation to use with Jini services has allowed a lot of flexibility in conjunction with the Jini 2.x configuration framework. Yes, I mention this configuration framework in the general grief area of this blog entry, but that is only regarding the proprietary syntax implementation for which you could develop your own version based upon the interfaces in this package.

Although there is the capability to develop your service launcher in an infinite number of ways, I think it would be a substantial “ease of use” feature to enable a significant set of these proxy options using annotations. An example might be something like the following:

@JiniService(proxy="smart",rmi="true")
public class MyServiceImpl implements IMyService, java.io.Serializable {
public MyServiceImpl(String[] configArgs) {
...
}
...
}

This would hopefully generate your main service starter class with proxy registration for clients to locate your service. Besides allowing the developer to create their generic Jini-aware services easily, this could also allow developers who wish to use the service to gain neccessary usage information quickly by acknowledging the generic proxy usage requirements.

While looking around for others who have commented on the subject of annotations and Jini (either directly or indirectly), I ran into this article at Clark Richey's blog about Jini accomplishing 80% of the perfect SOA qualities. He describes the last 20% missing in Jini being derived from it‘s ease of use or lack there of. I entirely agree with Clark on this subject and believe it is up to the Jini community to create the missing linkages for enabling developers in the use of Jini related technologies. If there are others out there who believe that annotations could alleviate some of the barriers to Jini development or somebody has another idea that they believe is better, I would be more than happy to help in developing a community project to implement it.

As a side note to this whole conversation, I thought it would be a good to post an article to reminisce on the launch of Davis (Jini 2.0), Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo. Also, since I mentioned Jan Newmarch, I thought that I would plug his book which I think is possibly the best reference on Jini so far, A Programmer's Guide to Jini Technology.