Chris Sterling’s Blog

When first working with the Jini 2.0 betas a while back, I quickly became aware of the new configuration scripts which had a Java-like syntax. I liked the idea of a more programmatic configuration because I thought it might be more robust. Since I was somewhat enthralled with the idea of this type of configuration, I think that I lost site of the bigger picture. Who is going to configure my services in a production environment?

Recently I spoke with a detractor of the 2.x configuration approach. He gave some good examples of why this approach may be unappealing such as it‘s close relationship to Java, but not quite Java feeling. Now, he did go further in a direction I didn‘t expect and that is to create a configuration approach based entirely on Java classes. This made me think more about what would be a good approach for configuration of Jini services in a production environment.

I came up with some possible ideas for Jini service configuration: JavaScript, XML, dependency injection, and Apache-like properties files. It looks like the usual suspects to me. So, I asked a friend of mine who is a system administrator what they thought would be the best mechanism. This person had a small bout with a Jini production system in the 1.x days and I thought they could provide me with some good answers on both fronts. Their response was that the service developers could provide any mechanism for their distribution configuration that they wished, but that it was probably a better choice to provide a nice user interface to control the deployment and runtime configuration for production systems. This is probably the basis for AdminUI and ServiceUI in the overall scheme of things.

Well, that gets me back to the base service module configuration. How do we configure Jini services with their security policies, exporters, communication protocols, and service specific options? I was at a Seattle mobile SIG a couple months back and there was a product presentation which spoke about JavaScript configuration deployment from a carrier administration console to their application running on a customer‘s mobile device. The company‘s name is SnapIn, located in downtown Seattle, and their speaker was Tom Trinnear who is a well respected figure in the telecommunications community. Is this scheme of allowing the mobile operators to deploy scripts with JavaScript syntax a plausible way of configuring a system in runtime? If so, can all of the Jini service configuration parameters be allotted a value at runtime or during service deployment into a container/grid such as Rio?

I think that I am more apt to believe in JavaScript configuration over the current configuration approach and other ideas I thought of for the following reasons:

• Current configuration is not Java-like enough and is quite proprietary in nature to the Jini environment. This makes it another barrier to entry for developers. I think that an all Java configuration (which you can do, but is not touted often) would be a better solution, but…
• All Java class configuration makes it a build time procedure. This is not conducive to production systems which may need to modify configuration parameters due to network and system environment modifications.
• Apache-like properties files are not robust enough to configure complicated services since it lacks object instantiation. In the J2EE world, properties files have been used to configure environments such as JNDI and I think that is one of the many reasons J2EE has become a difficult environment to develop in for many enterprises.
• I find that XML configuration is just barely a step up from Apache-like properties files and therefore suffers from some of the same issues. The hierarchical nature of XML also does not lend itself easily to object instantiation.
• Dependency injection (or IoC container type configuration) is another good solution in my opinion. This type of configuration is usually done through XML but is usually a language constructed of markup which is digested by factories or builders of factories which create the actual objects based on configuration parameters and inject them into the objects which reference them. (more information at Martin Fowler's web site http://www.martinfowler.com/articles/injection.html) The one knock I have on this approach as opposed to JavaScript configuration files is the amount of markup that must be created in order to define the dependencies of a Jini service to be created. When using Spring I have found that there is a substantial amount of XML to define quite simple entities.

I believe that the use of JavaScript is a natural approach to bridge Jini service development and deployment configuration. In the “mustang” release of the Java SDK there will be built in support for JavaScript as a scripting language to work with Java virtual machine environments (see JSR 223 and the Language section of “Core Java Technology Features in Mustang” announcement for more details). It seems like as good a contender as any to replace a configuration approach which I believe is a distraction from the overall goal of Jini to enter the mainstream market.

Comments Off on Alternatives to Current Jini Configuration Scripting