CF Conf Central
August 30th - September 1st, 2003
Las Vegas, NV


Each week from now until the Fusebox conference (Aug 31 - Sep 1), we're talking with one of the conference speakers.

WEEK 1: Ben Edwards

FB: This week, Fusebox is talking with Ben Edwards. Ben is presenting with Hal on Monday morning of the conference on Mach-II, a new object oriented framework for building applications. Ben, we've heard about Fusebox MX for some time, but it seems that Fusebox MX has become Mach-II. What's the story behind the name change? Was it purely for marketing purposes?

Ben: When we started out, Hal and I were thinking that we'd create an MX version of Fusebox, so "Fusebox MX" made sense, we thought. At one point, we asked each other, "What is FBMX? What exactly are we building? Are we just porting Fusebox to CFMX?" We decided that no, we were really trying to build a framework that would support developers who wanted to make a shift to object oriented programming. And of course, we wanted to solve some real problems. So we looked at everything again and made a decision that the architecture for this new framework should be event-based, implicit invocation—"

FB: You mentioned "implicit invocation". That's a term probably new to most Fuseboxers. What exactly is "implicit invocation" and does it really matter what architecture was used? Will it affect the way people writing applications with Mach-II?

Ben: I said that we were talking about the framework in the context of Fusebox. I'm a Fusebox fan; I built the J2EE implementation of Fusebox and worked on the Adalon IDE for Fusebox. But we said, "What's still a pain about building applications?" Maintenance—that's a pain. And yet, it's the single biggest item in the lifecycle cost of an application. Much bigger than the costs to originally write the code. Mach-II allows you to rapidly develop an application, but it really shines when software maintenance comes into play. But anyway, you asked about implicit invocation. II [implicit invocation] is a well-documented architectural style and it happens to excel at supporting maintainable code. It's got a rich, proven history in commercial, desktop software, DBMSs, IDEs, etc.

FB: Maintenance is very high on most developers' Least Favorite lists, so having a framework built for maintenance piques our interest. What differentiates implicit invocation architecture from other architectural styles?

Ben: Each style has its own structure. It helps define the decisions that the application architecture must make, what tradeoffs are involved, etc. Now, for a long time, people thinking about building better software have realized that when one bit of code is dependent on another bit of code—and that second bit of code depends on a third bit of code—well, when that happens the software becomes both fragile and brittle.

FB: Not a good combination.

Ben: Not at all. So this idea of keeping things independent has become ingrained in good software engineering practices. We call it "loose coupling". I read recently someone said that the perfect architecture is one in which "everybody knows nothing about anyone else." That's the ultimate in loose coupling. Well, that idea is built into the nature of II. Individual components-think of Fusebox circuits-don’t have to know which other components are available and how to explicitly make use of them (they are not tightly coupled). Instead II—and Mach-II—has the idea of events occurring within the system and then individual components "listening" for these events. Mach-II itself is the controller in a Model-View-Controller pattern and makes sure listening components are properly notified of appropriate events.

FB: That does seem quite different from traditional Fusebox.

Ben: Right—that was why we thought, "We can't keep the Fusebox name; it will just confuse people." And so, Mach-II got chosen.

FB: What do you say to people who say that the name sounds like a razor?

Ben: Well, hopefully, people will evaluate the framework based on its merits, so I'd probably say something like: A razor? Sure, think of "shaving" time and money off your software development (and maintenance) efforts.

FB: You've mentioned events. What is an event?

Ben: An event is an encapsulation of an intention. It's the way we encode anything that needs to be done in the software—whether that intention occurs by a user clicking something on their screen or whether the business logic components — the listeners — create an event. Events are objects, so they contain information that listeners can use. Things like form and URL variables, maybe, or information about the user's security profile.

FB: How do these business logic components "listen"?

Ben: The listeners are registered at configuration time with the framework through an XML file. The framework uses invokers to call the listener in its native format and formats the information from the event in a way that's meaningful to the listener.

FB: Can you give us an example?

Ben: Yes, let's say that you have a web service as a listener. Web services have a well-defined manner of accepting arguments, defined in a WSDL XML format. The invoker's job is to pass the event to the listener in a way that the web service can process it.

FB: So you can have a web service as a listener. Are there other types of listeners?

Ben: Sure, listeners can be web services, CFCs, Enterprise Java Beans--
even Flash clients.

FB: When would you advise someone to use Fusebox 4 and when would you use Mach-II? Are certain applications better suited to one or the other?

Ben: If you're using ColdFusion MX and you want to approach your application in an OO manner, Mach-II is probably the best choice. If you're committed to a procedural approach, Fusebox 4 is the ticket.

FB: You said that Mach-II is built around MVC. Does this mean that application programmers need to understand Model-View-Controller?

Ben: MVC is a design pattern with broad scope. It's enormously helpful for the framework writers. It lets us build a very flexible framework that can be used in many contexts, but MVC is fairly transparent to the application programmer. To the application developer, Mach-II supports separation of business logic through MVC, but you don't have to know much about MVC to use Mach-II. A good framework provides the benefits of appropriate design patterns but shields users of the framework from having to think about those design patterns.

FB: How hard will it be for people to learn this new framework?

Ben: You can approach this on different levels. In some ways, building an app in Mach-II is easier than building one in Fusebox 4. The real challenge for the programmer is to learn to leverage OO to build robust, powerful applications. That's not a framework issue; that's an OO issue. But you don’t need to be an OO expert to make use of Mach-II. Though being comfortable with OO will yield tremendous power when combined with Mach-II.

FB: Any last thoughts?

Ben: Mach-II empowers developers wanting to build maintainable and reusable code. For people who want to investigate Mach-II in depth, Hal and I are giving a class on Mach-II on August 25-27 in Las Vegas. You can just come to the conference early. You can get more info at halhelms.com and mach-ii.com. The mach-ii.com site will be up shortly. And, let me put in a word of thanks to Vlad Friedman of edgewebhosting.net, who kindly offered Mach-II a home on the web.

FB: Thanks, Ben.

Previous weeks:
Week 5: Jeff Peters
Week 4: Hal Helms
Week 3: John Quarto-von Tivadar
Week 2: Michael Smith

If you have any questions, contact [email protected]