Digital Edition

SYS-CON.TV
Mach-II
Mach-II

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 more rapidly develop applications: Developers voicing this concern told us that they were being asked to develop applications without sufficient time or resources. They were far less concerned about "future-proofing" their careers by learning OO than they were simply about getting out from under the current backlog of work.
  • The ability to help manage complexity: Simple apps are...well...simple, but they seldom remain simple. We've often noted that the most dangerous words clients can utter are, "You know what would be nice...." Despite our best efforts at requirements gathering, new requirements evolve and suddenly a simple application becomes more complex. Nor does ongoing development ever stop. Each new change becomes the basis for a new round of "improvements."
  • The ability to do effective team development: In corporate environments especially, application development is done by teams. Each member has unique strengths to offer, but very few have all the needed skills to solely craft an entire Web application. Any change to the current version of Fusebox needed to ensure that the support for team development was not diminished.
  • 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.

  • About Hal Helms
    Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

    About Ben Edwards
    Ben Edwards is a Sun Certified Java Programmer and holds a degree in
    computer science from the Georgia Institute of Technology. He
    currently trains developers on software engineering practices
    focusing on Java, object-oriented programming, and software
    architectures. Ben is also cofounder of the Mach-II project.

    In order to post a comment you need to be registered and logged in.

    Register | Sign-in

    Reader Feedback: Page 1 of 1

    I've really benefitted from Fusebox3 and liked the idea of Mach-ii. However the mach-ii site has almost no documentation! Come on guys, if you want the programming community to take up Mach-ii then at least tell us how it works !!

    Mach II does a very good job of abstracting the subtleties of the Implicit Invocation Architecture and the Model View Controller design pattern on which it is based.

    The end result is a well-defined framework that lets you build applications that are easy to maintain and enhance.

    Whatever you want to. You are not forced to take advantage of the improvements in ColdFusion. While not the optimum usage, CF still has the same ability to be procedural if you like.

    Gentlemen,

    The reason I was attracted to Coldfusion, Macromedia and Fusebox was that some of the complexity had been abstracted from what I thought I would need to do. It seems to be going the opposite direction. If I wanted to be a C++ OO programer I would have done that years ago. I want to run a business and be in touch with technology not be a slave to it.




    ADS BY GOOGLE
    Subscribe to the World's Most Powerful Newsletters

    ADS BY GOOGLE

    As DevOps methodologies expand their reach across the enterprise, organizations face the daunting ch...
    As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being soft...
    You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know ...
    ChatOps is an emerging topic that has led to the wide availability of integrations between group cha...
    The need for greater agility and scalability necessitated the digital transformation in the form of ...
    In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an over...
    The cloud era has reached the stage where it is no longer a question of whether a company should mig...
    Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection...
    In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and ...
    While some developers care passionately about how data centers and clouds are architected, for most,...
    "Since we launched LinuxONE we learned a lot from our customers. More than anything what they respon...
    Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every ...
    DevOps is under attack because developers don’t want to mess with infrastructure. They will happily ...
    "As we've gone out into the public cloud we've seen that over time we may have lost a few things - w...
    In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Ser...
    Sanjeev Sharma Joins June 5-7, 2018 @DevOpsSummit at @Cloud Expo New York Faculty. Sanjeev Sharma is...
    We are given a desktop platform with Java 8 or Java 9 installed and seek to find a way to deploy hig...
    "I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis too...
    "Cloud4U builds software services that help people build DevOps platforms for cloud-based software a...
    The question before companies today is not whether to become intelligent, it’s a question of how and...