Slashdot Mirror


Are You Using OMG's Model-Driven Architecture?

Mazzaroth queries: "Over the last few years, system architects saw many middleware and language eras. RPC, CORBA, .Net, EJB/J2EE (with WebLogic, WebSphere, and the zillion of other apps servers), XML/SOAP, Java, C++, C#, to name a few. More recently, an effort has been initiated to isolate application's architecture from the middleware particularities: Model-Driven Architecture (MDA). The idea is pretty good. This will eventually allow me to model the application, deploy it on .NET, then change my mind and go for WebLogic instead for instance. Even if the number of software engineering tools supporting MDA is quite limited for now, I would like to get feedback from people using an MDA approach to develop their application. What are the drawbacks, difficulties and limitations of MDA? What would be required in UML to better support MDA? What percentage of code can actually be generated? Can you share your experience?"

2 of 22 comments (clear)

  1. almost none by random735 · · Score: 3, Interesting

    I'm working on a large project at a big blue colored company in which we use UML models coupled with a code generator to target EJB deployment. Let's just say getting the models and code generator correct for ONE distributed architecture is bad enough. I don't want to think about trying to get it working for multiple deployment platforms.

    And let's face it, the idea of writing your EJB and then deploying it on any EJBServer using any DB backend is a pipedream as well. So consider the problems with that, then imagine multiplying them by the number of different distributed architectures you want to support...forget it.

    What's the point of all this anyway? Abstraction isn't always needed... the appropriate platform, code for it, optimize for it, test on it. Don't target 5 when you only need 1.

  2. We did this by Myshkin5 · · Score: 2, Interesting

    Well we didn't do everything MDA claims but we did abstract out our middleware. Our goal was to keep middleware from occupying so much of day to day development. By defining our middleware relationships in XML we were able to generate tons of code. In practice we abstracted EJBs but in theory it wouldn't be too difficult to generate different wrappers for SOAP or some other middleware.

    It wouldn't be hard to recreate but I am trying to open source the existing code. The company I worked for while writing it has been liquidated and the code was never listed as an asset. I think it is fair game for anyone with a copy.