With the release of the MX version, ColdFusion has moved from its strict procedural programming background toward object-oriented design and programming. This move has evoked both hope and fear in developers, some welcoming the decidedly new concepts of object orientation (OO) and some dreading that they will lose the language they love.

Within the Fusebox community, the introduction of ColdFusion components (CFCs) has stirred a great deal of interest: Would Fusebox leverage these new capabilities and, if so, how? Almost a year ago, we - along with John Quarto-vonTivadar - began work on a new version of Fusebox that would leverage the new capabilities of MX. At once there was a good deal of speculation on what "Fusebox MX" would look like. Would Fusebox become an OO framework? Would developers have to understand polymorphism and inheritance to use it? This article answers these questions and will, we hope, inspire people to look at a new, unashamedly object-oriented framework called Mach-II. In next month's issue of ColdFusion Developer's Journal, we'll explore Fusebox 4 - the worthy successor to Fusebox 3.

ColdFusion's initial appeal was to "Webmasters" who wanted to make their sites more dynamic - and it succeeded admirably. But just as the term "Webmaster" is an anachronism, the call for more dynamic Web sites was succeeded by the need for true Web applications.

As these applications became more involved and more ambitious in scope, ColdFusion developers discovered that even a thorough knowledge of tags and functions was just not enough. Realizing that the same problems presented themselves again and again, a group of developers wondered if these problems couldn't be solved - or at least ameliorated - by building some sort of framework on which Web-based applications could be developed. These visionaries traded ideas and code over e-mail. Ideas evolved and Fusebox was thus born, and it too succeeded admirably.

The Rise of OO
When ColdFusion MX was released, it generated a great deal of interest. For many developers, the most interesting aspect of the new release was the inclusion of a new encapsulation mechanism, the ColdFusion component (CFC). CFCs promised ColdFusion developers the ability to move from writing purely procedural code to object-oriented code. Macromedia began touting CFCs as "objects without all the fussiness."

For some developers, this represented a profound "this changes everything" shift - not without reason. Object orientation represents a shift in thinking. The procedural approach views each problem as a series of actions that must be taken in the correct order to achieve a desired result. Data is separate from functions. The object-oriented approach identifies separate, encapsulated components ("objects") in which data and functions are combined.

Fusebox represents a procedural approach to building applications. The object-oriented approach is very different from the procedural approach. Solutions result from first building classes that provide abstracted and simplified models of real-world counterparts. For example, a billing system might have classes for Invoice, Receipt, Customer, etc. When the application is run, instances of these classes (objects) are created. The running application then resembles an extended conversation between objects, with different objects sending messages to other objects to request information or ask that a service of some type be performed.

Shortly after the release of CFCs, we wrote "Discovering CFCs" (Techspedition Press, 2002), in which we explored in what ways CFCs were - and were not - truly object oriented. And since we were both involved in the Fusebox world, we decided to write a new version of Fusebox that would make use of the new capabilities of CFCs. We labeled the initiative, seemingly sensibly enough, Fusebox MX.

When we began talking about it openly, we heard from people who asked whether, with CFCs, the need for Fusebox was gone altogether? "Why do we need Fusebox when we have objects?" they asked. As we saw it, there were three ways to answer this question.

First, as we showed in our book, there were aspects of CFCs that simply could not be squared with an object-oriented approach. Second, if objects obviated the need for frameworks, why would Java, a language with first-class objects, have strong communities for over a dozen framework projects? Finally, however helpful individual components might be, they didn't address the issue of an underlying architecture. In short, we felt that Fusebox remained a valuable framework for the ColdFusion community.

OO and You
But a funny thing happened on the way to Fusebox MX. We began to ask questions about the appropriate software architecture on which to build the framework. Would Fusebox MX essentially be Fusebox - doing little more than adding components into a still procedural toolkit? That would be the easiest change for existing Fuseboxers to get used to, but would be little more than adding "super custom tags" to procedural code.

We felt strongly that the continued reliance on procedural code would put ColdFusion programmers at risk. Over the past 10 years, essentially the current lifespan of ColdFusion, a revolution has taken place. This revolution was not political, but technological, and it represented the ascension of object orientation as the dominant software construction paradigm. While languages such as Java, C#, Delphi, Visual Basic .NET, and Ruby (to name only a few) represented the new guard in this revolution, ColdFusion - and Fusebox - remained solidly procedural. Developers using ColdFusion simply didn't need to come to terms with object orientation.

Being involved in the Fusebox community, we felt a duty to ensure that Fuseboxers would not be using a proprietary framework cut off from the bigger IT world. We decided to rethink everything about Fusebox - including its architecture.

A Focus on Architecture
For many developers, the idea of "software architecture" simply means "how I put my application together." While obviously inexact, that definition of architecture was reflected by the great architect, Ludwig Mies van der Rohe, who wrote: "Whenever someone puts two bricks together, there architecture begins."

In practice, software architectures are commonly treated as a collection of components and connectors. Components are the system's functional elements, such as a shopping cart, a contact manager, or a database. Connectors define the protocols for communication between components. Examples of connectors include method calls, SQL queries, and HTTP requests. The architecture chosen for a system determines the vocabulary of components and connectors that can be used as well as the set of constraints defining how they are combined.

The choice of a particular software architecture is made on the basis of the goals of the designers, which is to say that there is no single-fit, perfect architecture. Over time, several different software architectural styles have risen to the fore, each with its own strengths and weaknesses. Our choice of a software architecture for a new Fusebox would then depend on what we wanted to accomplish. To determine this, we examined what others had come to rely on with Fusebox.

Fundamental Fusebox Goals
We began to speak with other Fuseboxers: What was it they most valued about Fusebox? From many voices, a few themes emerged. What Fuseboxers wanted from Fusebox was:

The ability to document an application: What developer wants to be forever chained to an application he or she has built? Yet without good documentation (and that meant documentation that was simple and easy to produce), developers were locked into maintaining their existing applications. It was simply too difficult for someone else to take over the responsibility for the application's maintenance.

Our own concerns centered on software maintenance. It is an often overlooked fact that between 70-90% of the life-cycle cost of an application is spent on maintenance. A framework that misses this point, by treating maintenance as an afterthought, gives away the enormous leverage that cost and time savings in maintenance can offer adopters of the framework. And if saving money is not a worthy enough goal, surely saving the sanity of coders who must work on poorly maintained code is. Thus, software maintainability became one of our chief goals.

Maintainability, we knew, was intimately tied to code reusability, since the same problem that causes an application to be difficult to maintain causes the components to be difficult to reuse - namely, the tight coupling between components.

Excessive dependencies between code components adversely affects all. Therefore, we felt that by tackling software maintainability, we would increase the chances for significant code reuse.

Cohesion and Coupling
Two metrics important for consideration in defining the publicly exposed interfaces of an architecture's components and connectors are a system's cohesion and coupling. Cohesion is the measure of the degree to which a component has a singular purpose. The greater cohesion a component exhibits, the more focused the component and the fewer the assumptions about contexts for reuse.

Coupling is the degree of interdependence between components. The less a component relies on other components (the looser its coupling), the more independent and reusable it is. Maximized cohesion (simple components) and minimized coupling (fewer connectors) are hallmarks of a flexible, maintainable architecture.

One of the more broadly accepted architectural styles in software engineering is known as implicit invocation. Implicit invocation architectures intrigued us. Event-based, implicit invocation is an example of a well-crafted architectural style with high cohesion and loose coupling. As such, it is one of the more broadly accepted architectural styles in software engineering. Examples of implicit invocation systems abound, including virtually all modern operating systems, integrated development environments, and database management systems.

Events and Listeners
Implicit invocation systems rely on the idea of events and listeners. Events are triggered whenever the system needs to do something, such as respond to an incoming request. Events can take many forms across different types of implementations; often for object-based systems, an event is an object whose properties contain any contextual information needed to process the event (similar to how an HTTP request carries with it all its form and query-string variables).

Listeners are business logic components that are registered with the system. When an event is announced, the system finds the listeners registered for that event and announces the new event to those listeners. Listeners fit the same criteria for components that we've already discussed - they are functional modules of the system. Components that wish to act as listeners are registered to listen for certain events at configuration time (by specification in an XML file, for instance). When an event is triggered, all registered listeners of that event are passed the event by means of a dynamically determined method call. In this way, functions are implicitly invoked. This process of notifying listeners of an event is called event announcement.

Events and listeners can themselves trigger other events. Let's consider how a common login/authentication scenario can be represented in terms of events and listeners. In this example, a login form is filled out by a user and then submitted. The incoming HTTP request triggers the creation of a LoginEvent, and the system populates the event with information in the request.

Next, the system determines the listeners for LoginEvent; in this case there is only one - the AuthenticationListener. Determined by a configuration file, the system invokes the AuthenticationListener's tryLogin() method, passing to it the event. Based on information in the event, the tryLogin() method will seek to authenticate the user. If the authentication succeeds, a new LoginAcceptedEvent is triggered. If authentication fails, a new LoginFailedEvent is triggered. The cycle then continues, with any listeners of the new event being notified (see Figure 1).

 

Loosely coupled components work together, but do not rely on each other to do their own jobs. The interaction policy is separate from the interacting components, providing flexibility. Components can be introduced into a system simply by registering them for events of the system, aiding greatly in reusability and maintainability. Introduction of new components does not require change in other component interfaces, providing scalability as new features are added. Overall, implicit invocation eases system evolution.

Rather than starting with the idea of making a Fusebox for ColdFusion MX, we began with the idea of making a true, object-oriented framework that would meet the goals we adopted. Work on the framework proceeded without regard to a specific language. Instead, we wanted to ensure that this new framework would be adaptable to any language that implemented object-oriented principles. Only after all architectural decisions were made did we set about the task of implementing it in ColdFusion, where we found CFCs provided us the encapsulation we needed.

The end results have surprised and gratified us. We find that the system offers enormous flexibility. New functionality (a.k.a., "You know what would be nice...") is often as easy as adding a new listener to the system. Loose coupling ensures that other components do not need to be altered. We found that the implementation of the Model-View-Controller design pattern was a natural fit with an event-based invocation architecture. Finally, we found that the system could easily work with Web services, Flash remoting, Enterprise JavaBeans, and more.

Only one problem remained: What should we call this new framework? We began this journey with the idea that we were creating a "Fusebox MX". What emerged was something different and better than what we had hoped for. But was it Fusebox MX? In the end, we decided that a different name would better serve all involved. Certainly, the underlying architecture had little in common with Fusebox. Better, we felt, to give it a separate name. Fusebox 4 would be the successor to Fusebox 3, and would continue to offer enormous benefits to procedural programmers.

After too many late-night discussions (for some reason, naming something takes on enormous importance!), we decided that we wanted the framework name to reflect the fact that it was meant to help developers break the procedural barrier. Mach-II was thus born. Next month, we'll explore the inner workings of Mach-II. In the meantime, we invite developers who want to use a powerful, flexible, object-oriented framework to build robust and maintainable applications to explore Mach-II at www.mach-ii.com.