A few months ago I wrote an article about using Ivy to jump-start new Java applications. Since then I have used Ivy in all the new components which often have dependencies between themselves or third-party libraries sometimes open source, sometimes proprietary. This article is about new insights from this experience and the more general issue of application modularization.

Application modularization is a hot topic in the Java community. A concise and good article by Alex Blewitt is: Modular Java: What Is It?. It is easy to see the dependencies being a problem in large applications, but it affects small/medium scale applications as well. In these days it is easy to create a component/application that depends on a dozen of external libraries. Modules can depend on each other at compile-time and runtime. For compile-time dependencies there is no standard specification, instead ad-hoc formats have been defined by development tools: POM for Maven and Ivy files for Ivy. For run-time dependencies the current standard is OSGi implemented by the major J2EE application containers.

It is easy to see how a development team can be easily confused and frustrated by the topic of modularization. On one hand this is a common issue: new components are build and new versions are released by other teams and external parties. Compile-time dependencies are managed inside build scripts, and hard to maintain. For run-time dependencies, the standards (OSGi) and tools (Eclipse, bnd) are too complex to the point where only the tool providers are able to use them.

For the people who want to go beyond manually maintained classpath entries, I am suggesting to a combination of Ivy and jar MANIFEST files.

(Continue reading …)

A large amount of effort and resources in an IT organization is dedicated to create and manage the hardware and software systems which directly supports the business, generically called the "production environment." Probably even more effort and resources are used to manage the hardware and software systems used for application development, testing, support and training – the “non-production environments.”

There are several ways to classify non-prod environments. Based on what they is used for, there are: development, testing, training and production-support environments. Testing environments are further split in integration, functional, structural (non-functional) testing and user acceptance testing environments. Another classification is based on how many applications are deployed in the environment. There can be one-system, multi-systems and all-systems environments. For example a development team uses a development/one-system environment and an integration/multi-systems environment.

This article is about how to define the scope for a non-prod environment in terms of applications deployed, application versions and application data.

(Continue reading …)

Excel is arguably the most used format for documentation by businesses organizations. One can speculate why that is the case: loosely-structured text format, tendency of people to think of complex data sets in table format, available on almost every desktop.  While most of us can think of better ways to capture and manage business data, the fact remains, Excel is here to stay and a lot of information used in IT projects is in that format. This article is about my experience in processing Excel files using Java.

(Continue reading …)

XML is the common data format in the exchanges between Business and Operations Support Systems (B/OSS). The exchanges carry  business objects (BO) which are identified by one of more member elements. This article is about how to declare and use object keys in XMLs in the context of an Enterprise Information System (EIS).

The key or identity information of a XML business object (XML-BO) is a "metadata" aspect: it is not explicit in the XML, instead  is defined separately, as meta-data,  known by the components that process the data. XML meta-data can be described in multiple  ways. The one that I will use in this article, and the most common, is the XML Schema Definition (XSD).

XSD does not directly support the concept of object ID but has related constructs. One of them is the ability to declare element identity constraints using the XSD elements: ID/IDREF/IDREFS and KEY/KEYREF. These constructs are used to impose uniqueness and/or referential integrity within an instance of XML. They are not intended as having a cross-instances meaning. But maybe, extending the semantic, we can use these constructs to define object identity in an EIS context.

(Continue reading …)