Developing easily configurable software is of paramount importance in today's business environment. Software applications are no longer judged simply by the amount of business logic that they encapsulate; they are also judged by how easy they are to maintain. The ability to alter software behavior, via configuration, forms an important aspect of this maintenance cycle.
While the Java language provides a number of features, such as property files and resource bundles, to aid configuration, these lack the features required for today's dynamic business environments. Many Java standards, tools, and containers already utilize more advanced and custom XML configuration formats.
The Obix Framework is an open source framework that provides the common means and formats for storing configuration data in XML, and for accessing this data via simple Java objects. It enables the modularization of configuration data by allowing configuration files to be imported and included in each other, and by organizing configuration information into "modules."
In addition, it supports "hot" configuration amendments—through auto-detection and auto-reload of changes to configuration data—and also provides support for the Java Naming and Directory Interface API (JNDI). Furthermore, it can be integrated into Java applications in numerous ways, including through Java Management Extensions (JMX) and Java Platform, Enterprise Edition listeners that do not require coding, as well as plain Java classes that can be invoked directly. Finally, the framework provides an easy-to-use plug-in API that lets developers extend it to perform initialization-related tasks. This API has been used by the Obix team to provide initialization utilities for other open source frameworks such as Apache's log4j, Hibernate, and Commons DBCP (database connection pools).
In this tutorial, I describe a hypothetical scenario that requires configurable software and for which we create skeletal applications using Obix. The first example provides the closest thing to a "Hello World"-style proof of concept, while the second and third extend this application to showcase less trivial aspects of configuration.
Please note that all the code samples in this article are packaged as an archive, which can be downloaded via the link provided in Resources.
Valuing financial assets such as stocks or options sometimes involves simulating the price of the asset thousands of times, and taking the average of these values—in the belief that the average provides a best guess as to the asset's "true" future value. Such simulations typically require statistical input in the form of the current price of the asset(s), the average price over a given time span, as well as the deviation from the average.
Let's suppose we are creating an application for valuing such instruments. As such, this application will need to download the statistical inputs via a Web service, and the details—such as URL and authentication information—for connecting to this service are stored in a configuration document. Suffice to say, the number of simulations to be performed for a given valuation request should also be flexible and, as such, will be specified via configuration.
Archived Discussions (Read only)