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
