Orcmid's Lair |
||||
|
2004-05-20MDA Lock-In?Modelling and MDA Michael Platt recommends Dan Haywood's MDA: Nice Idea, Shame About the ... article, and the related discussion thread. I don't think the arguments against the importance of MDA model durability are all that strong (and Microsoft COM is not as old as Haywood suggests, though his point about platform and infrastructure longevity is well-taken).Something that I find peculiar about current MDA products, though is the fact that they generate vendor lock-in, just as source-code CORBA bindings do. Duhhh? I remember how, at one stage in the 1994-1996 work to combine Document Enabled Networking and Shamrock into the Document Management Alliance (DMA) specification, that one of the main partners lobbied us strongly to adopt SOM and DSOM as the distributed-object layer. All we kept saying was, where's the binary interface? We were talking about an interoperability world into which vendors wanted to ship binaries. At that time, you couldn't do that with CORBA unless you locked into a binding and ORB implementation. With COM we knew we had it already and, although the DMA model that emerged wasn't that great for developers, it did deal with interoperability as far as the integration model was concerned. (We also did it in a way that did not require us to host any Microsoft infrastructure or libraries.) It looks like MDA, as an enterprise-focused tool, has the usual problem about whose MDA you choose to use and how far you will travel with it as MDA is used to target applications across varieties of (distributed) configurations. The problem is that the mapping from Platform Independent Models to Platform Dependent Models and the realization of Platform Dependent Components to provide smooth enactment of your model is serious black art. Something more transparent and open is needed at the design rules and component-introduction level to shake off this new model being just like the old model.
Comments:
Post a Comment
|