Sean Corfield ist einer der aktivsten Blogger der Macromedia Community und ein Experte, wenn es um Web-Frameworks und Webarchitekturen geht. Das MX Magazin hatte Gelegenheit zu einem ausführlichen Interview mit Sean während der MX Down Under 2005 in Sydney.

MX Magazin: Sean, Du arbeitest im Moment als Director of Architecture bei Macromedia. Was genau ist darunter zu verstehen, womit beschäftigst Du Dich alltäglich?
Sean Corfield: Der Titel Director of Architecture bedeutet mehr oder weniger, dass ich der Senior Architect für die IT-Abteilung bei Macromedia bin. In dieser Position werde ich zum einen zu allen IT-Projekten hinzugezogen, die mehr als ein einzelnes Team innerhalb unserer IT-Abteilung betreffen, zum anderen arbeite ich sehr intensiv mit unseren Senior-Entwicklern, um unsere sehr komplexe Integration-Umgebung so halbwegs unter Kontrolle halten zu können.

MX: Du bist als sehr aktiver Blogger bekannt und giltst als sehr engagiert für alle Community-Belange. Wie kommt man aus dieser doch eher internen IT-Position denn in eine solche Rolle?
SC: Nach dem Merger von Macromedia und Allaire arbeitete ich sehr eng mit Jeremy Allaire zusammen, der damals mein Vorgesetzter war. Jeremy lud mich zur englischen CFGURU-Mailing-Liste ein und versorgte mich mit einem Paket von Links und mit weiteren Com-munity-Ressourcen - ich fand die CF-Community sehr offen und hilfsbereit - und unglaublich enthusiastisch.

MX: Was magst Du an ColdFusion und warum hast Du letztlich angefangen, es für Deinen Berufsalltag intensiv zu nutzen?
SC: Ich habe im Jahr 2001 begonnen, mit ColdFusion zu arbeiten. Als der Merger von Macromedia mit Allaire vollzogen wurde, beschlossen wir, macromedia.com (damals mit Broad-Vision erstellt) komplett neu zu entwickeln und dafür ColdFusion zu nutzen. Am Anfang sagte mir ColdFusion eigentlich gar nicht zu, da es genau wie BroadVision eine Tag-basierte Sprache hatte. Im Gegensatz zu BroadVision stellte sich ColdFusion jedoch als extrem leistungs- und erweiterungsfähig dar und bot mir mit Custom Tags die Möglichkeit, die Sprache CFML in der CFML-Sprache selbst zu erweitern. Ziemlich schnell mit den ersten Frühversionen von ColdFusion MX entdeckte ich CFCs und stellte fest, dass diese alle meine Kenntnisse in objektorientierter Programmierung wieder wertvoll machten. Noch heute stelle ich immer wieder fest, dass ColdFusion es mir ermöglicht, IT-Probleme schneller zu lösen als jede andere Sprache, mit der ich in der Vergangenheit gearbeitet habe - und das waren sehr viele.

MX: Sean, in Deinem Job arbeitest Du in komplexen Projekten. Kommt daher die ziemlich starke Verbundenheit zu Frameworks und Architektur-Themen in Deinem Blog? Du bist immerhin einer der wenigen Blogger, die sich ernsthaft mit solchen Themen auseinandersetzen.
SC: Zum Applikations- und Modelldesign nutze ich UML-as-sketch (www.martinfowler-.com/bliki/UmlAsSketch.html) und nahezu alle Applikationen, an denen ich beteiligt bin, basieren auf ColdFusion Components. Das Macromedia-Webteam war unter den ersten Nutzern von Mach II (nach einer ausgiebigen Evaluierung von Fusebox 3), daher nutzen wir Mach II für alle unsere Projekte in diesem Umfeld. Für alle meinen eigenen und privaten Projekte nutze ich Fusebox 4.1 und habe vor kurzem begonnen, mich mit Tartan und Model-Glue zu beschäftigen. Alles in allem kannst Du mich wohl als großen Fan und Unterstützer von Frameworks und generell Standards bezeichnen.

MX: Du warst sehr lange als Unterstützer von Mach II aktiv. Was magst Du an diesem Framework, was ist zu kritisieren?
SC: Mach II war das erste ernsthafte ColdFusion-Framework, das auf einer objektorientierten Vorgehensweise aufsetzte. Am Anfang war sein Name noch Fusebox MX und ich habe mit sehr frühen Versionen des Frameworks erste Applikationen geschrieben. Die Version 1.0.4 hatte noch sehr viele Ecken und Kanten, um die man herum programmieren musste. Ben Edwards, der Erfinder von Mach II, war für Anregungen und Ideen zum Framework sehr aufgeschlossen, und als immer mehr Entwickler in unserem Webteam Mach II nutzten, waren wir in der Lage, sehr detaillierte Rückmeldungen an Ben zu geben. Sehr schön an Mach II sind die klare und einfache XML-Struktur und das Konzept von Listener, Filter und Plug-ins. Nach und nach frustrierte mich jedoch die Notwendigkeit, die Views zu deklarieren, bevor sie benutzt werden konnten und die Tatsache, dass die Grammatik der XML-Steuerungsdatei sehr aufwändig wird. Gerade in großen Applikationen muss man eine Menge an kleinen Filtern und Plug-ins schreiben. Aber alles in allem hat jedes Framework bestimmte Vor- und Nachteile. Ben Edwards hat eine sehr klare Vision, wie Mach II funktionieren soll und in welche Richtung es gehen soll, daher ist es eine sehr gute Plattform zur Applikationsentwicklung mit ColdFusion.

MX: Du hast bereits erwähnt, dass Du Dich auch mit Fusebox und anderen Architekturen beschäftigt hast. Kann man Vor- und Nachteile dieser Frameworks kurz zusammenfassen?
SC: Hmm, Fusebox bietet seit der Version 4.1 sehr guten Support für CFCs und die Grammatik der XML-Steuerungsdateien ist sehr ausdrucksreich, sodass man für die Steuerung des Kontrollflusses keinen ColdFusion-Code verwenden muss. Fusebox ermöglicht außerdem das Herunterbrechen einer Applikation in kleine und modulare Komponenten (Circuits) und es bietet sehr feingranulare Kontrolle über die Event-Handler (Fusebox). Ein weiterer wichtiger Ansatz ist, dass Fusebox die XML-Steuerdateien in ColdFusion-Code kompiliert, was sich unter Performanzaspekten sehr positiv auswirkt.
Model-Glue von Joe Rinehart ist ebenfalls ein sehr interessantes Framework, weil es einfach und in sich selbst konsistent ist. Im Prinzip verfolgt Model-Glue den Ansatz der Trennung des Event-Modells vom Listener-Modell durch Einführung einer Nachrichtenschicht. Model-Glue ist wie Mach II eine Architektur, die auf impliziertem Aufruf basiert, man kann damit allerdings auch direkte Aufrufe an Controller-Methoden absetzen - vergleichbar mit der verzögerten Ausführung in Mach II Tartan von Paul Kenney hat viele Stärken in der Entwicklung von Backend-Code. Tartan basiert auf einer Service-Command-Architektur mit ColdFusion Components, ein Aspekt, den kaum eines der anderen Frameworks ausreichend beleuchtet. Paul hat Tartan mit der Intention entwickelt, gut mit anderen Frameworks kooperieren zu können. So wird zum Beispiel ein Mach II Listener mitgeliefert, außerdem gibt es in Model-Glue einen Tartan Proxy. Ich selbst habe es auch sehr einfach zur Zusammenarbeit mit Fusebox konfigurieren können.

MX: Wenn Du die letzten Jahre Revue passieren lässt - siehst Du eine Änderung in der Haltung von CF-Entwicklern gegenüber abstrakten Themen und Frameworks?
SC: Ja, auf jeden Fall. Es ist hochinteressant zu beobachten, wie sich die Gewichtung der Themen in Blogs und Mailinglisten verschiebt. Mit dem Erscheinen von ColdFusion MX und den darin bereitgestellten ColdFusion Components haben zunächst sehr wenige Entwickler den Sprung auf diesen neuen Ansatz gewagt. Für die große Mehrzahl der CF-Entwickler waren Begrifflichkeiten wie OO oder Design Patterns Fremdworte. Die ersten Nutzer der CFC-Technologie waren oftmals Leute mit Informatikhintergrund oder vorhandenen Erfahrungen in objektorientierter Entwicklung und diese begannen mit der Entwicklung von CF-Applikationen, die dem entsprechen, was ich einen traditionellen und erprobten Architekturstil nennen würde. Das Erscheinen von Mach II hat gerade den CFCs und der Objektorientierung mit ColdFusion einen großen Schub gegeben.
Viele Entwickler haben sich sehr schnell auf OO gestürzt und sind dabei über Bord gegangen. Das ist ein Phänomen, das man gerade unter den Early Adaptors häufiger findet. Inzwischen ist ein wenig Ruhe und Pragmatismus eingekehrt. CF-Entwickler sehen OO und Design Patterns heute eher als Werkzeuge, die sie in der Entwicklung von besseren und wartbaren Applikationen unterstützen. Man macht heute in der Regel nicht mehr OO um der OO willen. Auch die Nutzung von Design Patterns, nur weil Design Patterns cool oder in sind, führt nicht automatisch dazu, dass wie von Geisterhand perfekter und gut strukturierter Code entsteht.
Ich mache auch immer häufiger die Beobachtung, dass die Akzeptanz des Refactoring steigt: Zuerst wird Code geschrieben, der funktioniert und danach wird der Code in weiteren Schritten verbessert und Design Patterns werden an den Stellen angewendet, an denen sie Sinn machen. Alles in allem durchläuft die CF-Community gerade einen Reifeprozess, den Entwickler in traditionellen OO-Sprachen wie Java, C++ oder Smalltalk schon hinter sich haben. Ich finde es extrem ermutigend, dass sich diese Entwicklung jetzt auch im ColdFusion-Umfeld vollzieht.

MX: Als Entwickler hat man allein mit den verschiedenen Frameworks viel Auswahl und viel Arbeit während der Evaluierung. Siehst Du für die Zukunft Bestrebungen zur Vereinheitlichung bestimmter Technologien - oder werden gar durch die Vielzahl von Ansätzen manche Frameworks einfach wieder verschwinden?
SC: Wow, das ist eine schwierige und umfassende Frage. Ich fange vielleicht einmal mit Fusebox an, denn ich denke, dass die Fusebox-Community weiter sehr stark sein wird und vor allem mit Fusebox 4.1 und der OO-/CFC-Unterstützung einen großen Sprung nach vorne gemacht hat. Ich bin selbst Mitglied des Teams Fusebox und kann daher sagen, dass es eine Roadmap für die Weiterentwicklung des Frameworks in den nächsten Jahren gibt, die einerseits Kompatibilität sichern und andererseits die Ausdrucksmöglichkeiten und die Erweiterbarkeit des Frameworks noch steigern wird.
Mach II ist sehr stabil und robust, aber es lässt sich schwer abschätzen, wie es in Zukunft weiter entwickelt werden soll - letztlich genau aus dem Grund, dass es stabil und robust ist und weiterhin genau das ermöglicht, wozu es ursprünglich entwickelt wurde.
Model-Glue ist eine interessante Alternative zu Mach II, die eine ähnliche Grundidee wie Mach II verfolgt, in einigen Bereichen Verbesserungen bringt, dafür in anderen Bereichen hinter Mach II zurücksteht. Ich denke, dass Model-Glue auf dem Weg zu einer Version 1.0 noch einige Anhänger finden wird und ermutige jeden, sich neben Mach II auch Model-Glue näher anzuschauen, wenn ein neues objektorientiertes Framework erforderlich ist.
Tartan ist vor allem dann sehr interessant, wenn es darum geht, komplexe Geschäftsmodelle abzubilden. Meines Wissens ist Tartan das einzige Framework, das explizit das Modell in einem MVC-Kontext betrachtet und sich nicht weiter mit dem View und dem Controller beschäftigt. Es passt daher sehr gut zu Flash und Flex (über Flash Remoting) und lässt sich mit den drei anderen Frameworks integrieren.
Es gibt noch weitere Frameworks, die sich teilweise in sehr frühen Entwicklungsstadien befinden. Zum Beispiel Reaction von Murat -Demirci, das sehr durch das Codebehind-Konzept von ASP.NET inspiriert wurde. Wenn man seine Applikationsstruktur verbessern möchte, ohne einen Front Controller wie in Fusebox, Mach II oder Model-Glue nutzen zu müssen, ist Reaction ein interessanter Ansatz.
Als ich zum ersten Mal mit Mach II in Kontakt kam, habe ich erwartet, dass Mach II den Markt dominieren wird. Inzwischen sehe ich aber, dass Fusebox sich weiterentwickelt hat und vielleicht eine klarere Strategie für die Zukunft bietet. Wenn man einmal die verfügbaren Plattformen untersucht, bieten Fusebox und Mach II sowohl PHP- als auch ColdFusion-Versionen, allerdings ist fraglich, wie stark der Einfluss vor PHP-Versionen ist, da es gerade für PHP viele etabliertere Frameworks gibt. Model-Glue bietet neben ColdFusion eine C#-Version.
Ganz realistisch würde ich sagen, dass Fusebox aufgrund der großen Community und der klaren Roadmap auf jeden Fall überleben wird. Ich würde Tartan und Model-Glue gerne in der Zukunft sehen, da sie sozusagen die ersten Frameworks der zweiten Generation nach Fusebox und Mach II sind - und die Autoren Freunde von mir sind (lacht) - aber gerade in diesem Bereich des Marktes ist Mach II sehr etabliert. Vielleicht wird das Überleben wirklich davon abhängen, inwieweit Entwickler dazu bereit sind, mehrere Frameworks zu lernen und von Projekt zu Projekt über das einzusetzende Framework zu entscheiden.

MX: Sean, vielen Dank, dass Du Dir die Zeit genommen hast. Wir sind schon sehr gespannt darauf, was die Zukunft im Umfeld der CF-Frameworks bringt!
SC: Sehr gerne, vielen Dank Euch für das Interview!

More Info:

• www.corfield.org/blog/
• www.fusebox.org
• www.mach-ii.com
• www.model-glue.com
• www.tartanframework.org/tartan/