Summary
While various Web frameworks devote lots of attention to making complex systems easier to build, most frameworks default to using a flavor of XML to specify how those complex systems are configured. A few projects started to innovate in the configuration space, but the requirements for an ideal configuration solution are still to be defined.

This week, Artima published excerpts from an interview with Van Simmons about his Jini-based ComputeCycles project. An interesting aspect of ComputeCycles is that it uses Groovy as a configuration language. In the interview, Van Simmons told us how he came to use Groovy for that purpose:

In this day and age, people do these enormous XML configuration files. The Jini design team had that option open to them, but they said, What we really would like is Java configuration. Write a Java class to do configuration, and we'll interpret that on the fly. If you think about it Spring does almost exactly that, does all the configuration, but instead of the configuration files being in Java, [they] are in XML. The Jini team decided to do it in Java...

One of things I've been asking about for a number of years is, How do you enforce security [with Java-based] configuration files? If the configuration files are in Java, what class loader do you load those classes into, and how much access do you give that classloader? And how do you [configure] how much access to give to the class loader loading the configuration?

That's how I came to start thinking about Groovy... Groovy has the Groovy class loader available. And I actually can constrain in its own security context a config file written in Groovy. There is a Groovy-Spring project for replacing all those XML files in Spring with Groovy files. It's the best use of Groovy I have seen so far. You don't have to program your config files in XML any more. That provided an model for using Groovy in ComputeCycles as well.

In addition to an innate dislike of complex XML files, one reason the Jini team opted for a subset of Java grammar as a configuration language for Jini services was that that language enabled the dynamic processing of configuration data. Dynamic evaluation of the environment can be helpful in setting up distributed services, but it also makes the behavior of a service harder to understand, since computed results in configuration scripts affect how services start and operate. The situation is further complicated when evaluating the configuration scripts results in side-effects, such as creating new files and directories, removing directories, or in other ways changing the state of the system.

Increasingly complex configuration may be as much a symptom of complex requirements as it indicates the inability of configuration languages to satisfy the need for greater configuration flexibility. A striking example of how an initially simple configuration mechanism contorted out of proportion is Ant. Ant has evolved into a language of its own, far extending its humble origins in a simple XML file. A cursory look at the set of Ant files NetBeans generates for a default project illustrates this point.

To be fair, Ant evolved into what it is in response to user needs. But something better than XML is certainly needed to configure complex systems. Van Simmons believes that Groovy is ideally suited as a configuration language for Java-based systems, since Groovy code easily interacts with Java objects, and is also less verbose than a Java subset, such as the configuration language used for Jini.

In your experience, what are the requirements for an ideal configuration language? What languages and configuration mechanisms have you found friendly, but still flexible, in your projects?

Talk Back!

Have an opinion? Readers have already posted 5 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.