Tuesday, March 2, 2004

Model Driven Architecture and Intentional Software - could it turn out to be just POJOs + metadata? Crikey, not much blogging around here for a while and then 3 rambling posts in one day! :) I've tended to agree with Martin about the Model Driven Architecture movement. I'm definitely a UmlAsSketch kinda guy. After watching case tools come and go, I've not been holding my breath for executable UML to become the new big thing any time soon. But increasingly as the use of metadata and POJOs for domain objects becomes more common place - I wonder could POJOs + metadata be considered a model driven architecture? Indeed through some clever IDE plugins and the use of metadata could we almost see Intentional Software take hold? e.g.  there's already eclipse plugins that allow classification of methods or code reviews of code or other different graphical representations of code - all integrated into the IDE. The BPEL folks are adding graphical views of code as workflows, BEA's Workshop does similar things - for message based interactions and web services - all using metadata in the code and graphical UIs which edit the metadata & code. So aren't we headed for an MDA or Intentional Software future - but rather than being based on some executable UML platform or some new language, its just POJOs + metadata? 11:49:53 AM    comment []

Thought for the day: Naked POJOs with autogenerated eclipse UI and forms I conceptually like the ideas behind Naked Objects - like max I'm just not too keen on the physical implementation. One of the main areas of development in the Java community right now is the invisible framework, where we all just write POJOs (or POGOs ;) and have some metadata (doclet tags, JDK 1.5 metadata or config files etc) and hey presto the framework does the rest whether it be persistence, transactions, remoting and so forth - maybe with AOP or just plain interceptors or code generation or dynamic proxies or whatever. There's gonna be lots of frameworks doing many different forms of this - the great thing is the POJOs will just drop into any of the frameworks so we all become loosely coupled allowing innovation without framework lock-in. So I wonder if something conceptually like the Naked Objects could be developed using pure POJOs with some optional metadata and no special base class or special collections or types etc. Then any domain model anywhere thats based on pure POJOs would work nicely in a Naked Object auto-UI front end. Being able to easily create & edit POJOs using a simple automatically created UI would rock - we shouldn't have to develop these things if we're not too fussy on the layout and so forth. e.g. I should be able to just open up any domain model, pick a persistence engine/mechanisms & data source (RDBMS or XML config files) and I should be able to create a bunch of objects for testing etc. Then if such a thing existed, maybe we could have a neat eclipse plugin using the new cool eclipse forms (and maybe groovy-swt) to both auto-generate these forms but also allow them to be easily customized. Or any other UI mechanism - a web front end, a Swing front end etc. From a quick skim read of the naked objects intro much of what its trying to do is really just expose metadata - plus intercept property changing (which all the AOP frameworks do a great job of solving). So is it maybe time for Naked POJOs? 11:23:11 AM    comment []

eclipse, groovy and dynaop I spotted a great post by Adrian Spinei (subscribed!) on eclipse plugins and groovy. Anyone who's developing an eclipse plugin should read this - it has some real gems on how to maintain binary compatibility of a plugin across various eclipse versions. On a related note, Christiaan ten Klooster has been working on groovy-swt which should hit groovy's CVS server in the next few days - which now includes support for the new Forms stuff in eclipse which looks awesome - I'm keen to play with it. Finally Thomas Heller has been doing some interesting things on GAP with groovy and dynaop. He's been using groovy closures to implement class or method pointcuts etc. This reminds me of Sam's post on needing a query language for pointcut declarations. I'm looking forward to seeing the third axis of GAP, adding Pico support to mix and match IoC, easy configuration and AOP. Dynaop looks cool while being very small & compact. I've not yet got a handle on AspectWerkz v dynaop in terms of features & ease of use but its great seeing healthy competition and innovation in open source. 8:13:51 AM    comment []