Edmund Philosophy
Sean Corfield
attention to Edmund starting next week (there is already some
experimental code in SVN, under my org-corfield-cfmx project). In the
mean time, I wanted to give you a little more background on my
thinking.
What is quoted below is a response I made to discussions on the
Mach-II list about how and whether to add a "Remote Proxy" to Mach-II.
The counter-argument had been made, rightly, that Mach-II (like the
other MVC frameworks) is meant for HTML applications and, whilst it
can stretch to XML views, it really isn't designed for more general
remote method calls. However, the XML approach was sufficient for
AJAX.
I responded:
--- 8< --- 8< --- 8< --- 8< ---
Yes, AJAX is a strange middle ground because it's making RESTful calls
and getting text back - either XML or JSON.
But I think you need to look at this in the context of the bigger
picture of SOA where your "application" provide services that are then
consumed by a number of clients (and client technologies). In that
model, the services are also consumed by your application's HTML front
end and so Mach-II is a client as well. The question then is where
should common logic be to follow the DRY principle. If you're
supporting Flex and Web Services, common logic must be in the services
layer that they interact with and that pushes you closer and closer to
a smart service layer and, essentially, a dumb client layer. In
Mach-II terms that means pushing authentication and other common logic
down into the services and providing only a thin control layer on top.
Now, Flex can of course traffic in XML and RESTful calls but that's
not its "native" tongue. Web Services fall into either XML and RESTful
calls or full SOAP encoding.
ColdFusion helps us here with DRY because a CFC with a remote method
can return JSON to AJAX, AMF to Flex and SOAP to Web Services. One
remote API, multiple client technologies. If you need plain XML, you
need to pick a data encoding anyway (what standard encodings are there
here? How about WDDX which CF supports natively too? Otherwise you
need a proprietary encoding).
So DRY suggests using a CFC for the service endpoint.
The pragmatic tension is between that "ideal" and the current reality
that people have existing ColdBox / Fusebox / Mach-II / Model-Glue
applications and they want to expose some functionality without having
to duplicate "everything". That's what is leading to what Matt calls
the tipping point for this request: adding remote adapters to
frameworks. Most people admit that it's not really the "right"
solution but it is a good interim step and helps people solve an immediate need.
So far Luis (ColdBox), Joe (Model-Glue) and Matt (Mach-II) have all
said that this doesn't seem like the "right" approach for frameworks -
and I agree with them (which is why I find the "appeal to a higher
authority" so amusing***). They're all taking the pragmatic position
that
demand from the community makes this a worthwhile interim addition to
the frameworks.
[*** this was a reference to an earlier comment in the thread where
someone said people say the remote proxy is a bad idea "because Sean
Corfield said so" and I made a joke that "appeal to a higher
authority" is an anti-pattern in an argument]
As Brian notes, Edmund may become appropriate for some people as it
attempts to provide the same event-driven architecture that folks like
from the main frameworks and push it down into the service layer. My
intent is that Edmund will be compatible with - and integrate tightly
with - the major frameworks as well as being able to operate
standalone. It's early days right now - some code exists as an
undocumented proof of concept. One of my experiments is to read
Mach-II and Model-Glue XML files to synthesize an event model in the
service layer (as a possible migration aid as well as simply allowing
people to use an XML format they're already comfortable with). Edmund
will probably go through some radical revisions on the way to a 1.0
release, probably in the summer of 2008. Who knows... maybe we'll
eventually see HTML application frameworks built on top of Edmund,
with Edmund just providing the core event handling model?
--- >8 --- >8 --- >8 --- >8 ---
So the idea is that Edmund will be lightweight and generic but will
support extension out into other frameworks so that it becomes
painless to migrate Mach-II / Model-Glue event handler logic down into
Edmund and/or use Edmund alongside any framework to provide the core
event handling *within the service layer* which should make services
more portable between different client technologies. Ultimately, if
Edmund becomes to event-driven models what ColdSpring has become to
IoC/DI in general - a common adjunct to every MVC framework and
actually part of the core of Model-Glue - then I will be extremely
happy. Even if Edmund becomes just an oddity that a handful of people
like using, I'll be happy enough.
I am actually working on a project for which Edmund will be the
"solution" for a generic observer / event subsystem within a very
large interactive application. So it will get real-world proving
through that, at least.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood