Sunday, October 16, 2005

Zachman Lecture

I attended a two day seminar on the Zachman framework for Enterprise Architecture last week. I have read about Zachman before, and have even bought a book on the subject (which as an aside must be the work book ever written). However the seminar was presented by John Zachman himself so I thought it would be a good opportunity to get the message from the horse's mouth.

I was not disappointed; I have always thought of the Zachman framework as just being a means of classifying the various artefacts created during the development and maintenance of an enterprise's architecture. However John's compelling vision is that the Zachman framework is a schema for defining the primitive elements of enterprise architecture. He describes the framework as being the basis for enterprise physics, and draws an analogy with the periodic table. This analogy also allows him to justify the fact that not all of the models that comprise the cells in the framework have been articulated yet. Continuing the analogy, he argues that any architectural artefact needed will either be one of the primitive models in the framework, or a composition of these primitive models. By separating out the independent variables in the enterprise (represented by the columns, defined by interrogatives) the enterprise can support the flexibility needed in the information age.

One of the points made repeatedly during the two days was that in the absence of architecture models there are only three ways to support change:
  1. Change by trial and error
  2. Reverse engineer the models
  3. Scrap the legacy solution and start again
Another interesting observation concerned the use of COTS; here the advice was to change the organization and/or business processes to fit the COTS package, and not vice-versa.

John's presentational style was very interesting; it was not a seminar in the sense of dialogue and discussion. It was more a high-powered intensive lecture, with a huge quantity of facts, knowledge and anecdotes delivered at breakneck speed.

All in all, it was an excellent lecture to attend. I left with a feeling that I need to change the way that I think about architecture, which is all I could really ask for.

Saturday, August 13, 2005

Back in Britain

Having spent nearly six years abroad I returned to Britain in March of this year. Things have been a bit hectic but I have a few observations:
  • Brits are obsessed with buying and selling houses; unlike anything else that you buy, house price growth is measured on a month by month basis. The press seems to think that anything other than rampant house price inflation is a sign of a weak economy.
  • Being able to walk to a nice pub that sells decent beer is one of life's simplest pleasures.
  • Bread is better in Denmark.
  • Steak is better in Texas.
I will add other observations in the fullness of time...

Saturday, February 26, 2005

Reflection: type madness or ultimate flexibility

On a number of recent occasions I have found myself looking at Java code that makes extensive use of reflection. Being somewhat conservative in my ways I was initially somewhat suspicious of this technique. However over time I have come to appreciate the flexibility it provides. However to my mind it is one of the features Java provides that is most open to abuse.

Let's consider the positive side of reflection first. Using reflection I can work with classes at runtime that I don't know about at compile time. A typical application of this idea is a piece of software that supports plugins such as Eclipse. The following diagram shows the basic idea.




The plugin manager is responsible for loading plugins according to some policy (at startup, polling during runtime etc). The plugin supplier creates the plugin and some kind of descriptor identifying the class in the plugin that implements IPlugin. This is a string, so the plugin manager uses something on the lines of the following to load the plugin:


Class pluginClass = Class.forName(pluginClassName);
IPlugin plugin = pluginClass.getInstance();
... // use plugin


Note here that due to the fact that constructors can not be specified by interfaces, such an approach requires an agreement about the constructors provided by the plugin class that can not be checked by the compiler. Typically this is resolved by requiring a zero argument constructor, and then having an init method defined in IPlugin which is called immediately after instantiation. Alternatively the agreement could be for a constructor with a list of parameters of specified types, and then pluginClass.getDeclaredConstructor() would be invoked with a list of parameter types as argument. This would return an instance of java.lang.reflect.Constructor which could then be instantiated.

This use of reflection, where at application compile-time not all of the runtime classes are available, is how I think it ought to be used. So far so good. Where's the problem then?

Consider the following example, based on a little application I developed for fun recently (more of that in a later blog). Suppose you wish to use a wizard dialog to gather information in a number of stages. There is a certain amount of repetition in the structure of the dialogs (buttons for next and previous, handlers for these buttons etc) which means it makes sense to capture the commonality in an abstract superclass and the specifics in concrete subclasses - a straightforward implementation of the template method pattern. Stripping away all detail irrelevant to the discussion at hand we might have something like


public abstract class WizardDialog implements ActionListener {

public abstract void display();

public void actionPerformed(ActionEvent ev) {
if (...) // source of event ev is "next" button
{
String className = nextDialog();
if (className != null){ // null indicates the wizard has completed
Class nextClass = Class.forName(className);
WizardDialog nextDialog = (WizardDialog) nextClass.getInstance();
nextDialog.display();
}
} else if (...) // handle other events including previous button
...
}

// return class name of previous dialog
public abstract String previousDialog();

// return class name of next dialog
public abstract String nextDialog();

}


The first step in the wizard might then be implemented as follows:

public class View1 extends WizardDialog {

public void display() {
// populate dialog
}

public String previousDialog() {
return null;
}

public String nextDialog() {
return "view.View2";
}
}


This example summarizes a number of uses of reflection I have seen over the years, from relative novices to high-profile open-source projects that really ought to know better.

There are two drawbacks to using reflection in this way; both revolve around the fact that it isn't actually necessary.

The first drawback is that in general using reflection has its price in terms of performance. It's difficult to quantify this, but I have seen studies where a factor of 10 is quoted as the lower bound. In practice for this particular example I wouldn't worry too much as performance is less of an issue but in general it seems foolish to waste performance in this way.

The second drawback is the one that is more important: by using reflection in this way, type information is being voluntarily discarded. We know that the next dialog is an instance of WizardDialog, yet we willingly throw away that information and instead pass back a string. Having a background in strongly-typed functional programming languages such as Haskell and Miranda, this bothers me. By doing this we are relinquishing the automatic type analysis that the compiler is able to perform for us. This might not seem like a big deal in this kind of toy example, but in real applications that I have worked on, this is the kind of thing that leads to runtime class cast exceptions.

What is the alternative then? Well the point is that we know about all the classes we are working with at compile time, so we can just use them directly:


public abstract class WizardDialog implements ActionListener {

public abstract void display();

public void actionPerformed(ActionEvent ev) {
if (...) // source of event ev is "next" button
{
WizardDialog nextDialog = nextDialog();
if (nextDialog!= null){ // null indicates the wizard has completed
nextDialog.display();
}
} else if (...) // handle other events including previous button
...
}

// return instance of previous dialog
public abstract WizardDialog previousDialog();

// return instance of next dialog
public abstract WizardDialog nextDialog();

}

public class View1 extends WizardDialog {

public void display() {
// populate dialog
}

public WizardDialog previousDialog() {
return null;
}

public WizardDialog nextDialog() {
return new view.View2();
}
}


Given the simplicity of this solution, how is it that I ended up messing around with reflection in the first place? Well, laziness, normally the friend of the developer, was in this case the villain. I am using the value returned by nextDialog and previousDialog for two purposes: to identify the dialog, and to indicate (by returning null or an object) whether there is a next (or previous) dialog. This latter use is exploited by the code that displays the buttons: if there is no next dialog, then the button is labelled "Finish" otherwise it is labelled "Next". Similarly the previous button is labelled "Cancel" if there is no previous dialog. I wanted to avoid creating unnecessary objects each time I invoked nextDialog() and previousDialog(). However in this case my laziness led to a poor solution; if that was my concern I should have used a singleton pattern or cached an object reference, rather than discarding type information and resorting to strings and reflection. Still, at least my laziness gave me something to blog about!

Sunday, February 06, 2005

Sun Certified Enterprise Architect

I recently completed Sun's "Sun Certified Enterprise Architect for Java 2 platform, Enterprise Edition Technology" certification. There are lots of online resources for this certification, so I am not going to provide an in-depth description of what is involved. However I did learn a few things along the way which might be of interest.

The certification is in three parts where Part I is a multi choice exam, Part II is a project and Part III is an essay exam. Part III is essentially just a confirmation that you are the person who did the project. Part I is a bit of a pick and mix across various enterprise architecture topics. By and large it takes a wide and shallow approach rather than a narrow but deep approach. Thus you really need superficial knowledge of the topics in the syllabus rather than in-depth hands-on knowledge.

The project in part II requires you to create an architecture and high-level design for an enterprise application. Some requirements are provided for the application, and obviously the architecture needs to be J2EE-based (more of this below) but otherwise you have pretty much free reign over how the application should be structured.

One of the good things about the project is that the requirements are deliberately vague, inconsistent and misleading. I say this is good, because in my experience it is an accurate reflection of reality. Of course normally such issues would be resolved by talking to the requirements team etc but for the project you just need to provide an overall interpretation of the requirements that makes sense.

Even though I have worked as an architect for several years now, the thing that really dawned on me while doing the project, was something that has also become apparent for me in my current day job: an architecture is a function of the underlying requirements and the design decisions made along the way. Without either of these it becomes very difficult to assess the quality of the architecture or even maintain the architecture. While it is usual to have the requirements documented in some way (either as a formal requirements document or in the form of use cases) it is less usual to include a complete list of the design decisions made. And yet, without them, any architecture expressed as say a UML model has very limited value. Architectural models are intended for communication (the "what" of the system) but without the "why" how can you say that the "what" makes any sense at all?

Since this is a Sun certification, the architecture has to be J2EE based. But what does this actually mean? I took a fairly conservative approach using the model 2 design pattern with various kinds of EJB. Would I have done that for a real application? Probably not; I would most likely use Spring and Hibernate, or even a JDO persistence layer. I could of course have tried that in my project, but I was more interested in getting the certificate than having an argument with an assessor about the validity of my solution. Does that observation devalue the certification? I don't think so; there are situations where the heavyweight canonical Java blueprints approach is appropriate so there is certainly value to be gained in understanding how to apply this approach.

Now that I have completed this, I am going to go over to the dark side and start looking at .Net...