Ten years of MDA soon
On November 27, 2000 the OMG published the so-called MDA whitepaper Draft 3.2 . This will soon be ten years ago.
Ten years is a good period to reflect on where we stand, what has been achieved, what remains to do and where we are leading.
But before doing that, we may quote some interesting parts of this seminal report and indulge in some paraphrasing (the subtitles have been added).
It’s about integration. It’s about interoperability. For eleven years, the Object Management Group (OMG) has focused on making sure that you can integrate what you’ve built, with what you’re building, with what you’re going to build. As the pace of technology continues to quicken, and the demands of integrating your existing legacy systems, your new intranet, and your ebusiness fall on your shoulders, you need an architecture that makes interoperability central to your infrastructure. The bad news is that there will never be a single operating system, single programming language, or single network architecture that replaces all that has passed; the good news is that you can still manage to build systems economically in this environment.
CORBA was a powerful first step, but we have more steps to take.
UML, the Unified Modeling Language, allows a model to be constructed, viewed, developed, and manipulated in a standard way at analysis and design time. As blueprints do for an office building, UML models allow an application design to be evaluated and critiqued before it is coded, when changes are easier and less expensive to make. In addition, the Common Warehouse Metamodel (CWM) standardizes how to represent database models (schema), schema transformation models, OLAP and data mining models, etc. The MetaObject Facility (MOF) standardizes a facility for managing models in a repository. And finally, XML Metadata Interchange (XMI) is an interchange format for models, based on the MOF and the popular language XML. The OMG’s modeling specifications complement but not limited to CORBA. They are being used in virtually every development environment including Java/EJB, messageoriented middleware, DCOM/COM+/.NET and XML/SOAP.
The OMG standardization process may be used in modeling also
In addition to its technologies, OMG has the world’s best standardization process. Executing our process, building consensus as they converge on technical details, OMG members produce each new specification in nine to seventeen months. Proven in the marketplace with the standardization of CORBA, the CORBAservices, Domain Facilities, UML, the MOF, and OMG’s other modeling standards, the process is one of our group’s major assets. OMG’s technology adoption process will play a major role in the extended standardization work proposed in this paper.
The problems caused by middleware proliferation
What’s middleware? Middleware environments started out providing interoperability using architectures that are standard (i.e., CORBA), proprietary (e.g., DCOM or MQseries), or somewhere in the middle (e.g., JMI or HTTP/XML/SOAP). Essential services such as transactions, directory, persistence, event handling, and messaging, were added over time.
Recently, more powerful middleware has emerged that builds on the basic interoperability environments to make it easier to construct transactional enterprise components (CORBA Component Model, EJB, MTS/COM+) that execute on application servers.
Over the past decade or more, companies have endured a succession of middleware platforms.
Let’s end the middleware war …
It’s difficult — in fact, next to impossible — for a large enterprise to standardize on a single middleware platform. Some enterprises found themselves with more than one because their different departments have different requirements, others because mergers or acquisitions created a mix. Even the lucky enterprise with a single middleware choice still has to use other technologies to interoperate with other enterprises and B2B markets.
The middleware environments that are most visible today are CORBA, Enterprise JavaBeans, messageoriented middleware, XML/SOAP, COM+ and .NET. However, over the past decade or so, the middleware landscape has continually shifted. For years we’ve assumed that a clear winner will emerge and stabilize this state of flux, but it’s time to admit what we’ve all suspected: The sequence has no end! And, in spite of the advantages (sometimes real, sometimes imagined) of the latest middleware platform, migration is expensive and disruptive. (We know an industry standards group that, having migrated their standard infrastructure twice already, is now moving from their latest platform du jour to XML.)
… and move to the new modeling era
… There is a way to manage this situation, and it’s based on the core modeling standards from OMG. What we have is the ability to apply modeling technology to pull the whole picture together.
Companies that adopt the MDA gain the ultimate in flexibility: the ability to derive code from a stable model as the underlying infrastructure shifts over time. ROI flows from the reuse of application and domain models across the software lifespan.
The central figure
The core of the architecture, at the center of the figure, is based on OMG’s modeling standards: UML, the MOF and CWM. There will be multiple core models (UML profiles) : One will represent Enterprise Computing with its component structure and transactional interaction; another will represent RealTime computing with its special needs for resource control; more will be added to represent other specialized environments but the total number will be small. Each core model will be independent of any middleware platform. The number of core models stays small because each core model represents the common features of all of the platforms in its category.
Whether your ultimate target is CCM, EJB, MTS, or some other component or transactionbased platform, the first step when constructing an MDAbased application will be to create a platformindependent application model expressed via UML in terms of the appropriate core model.
Platform specialists will convert this general application model into one targeted to a specific platform such as CCM, EJB, or MTS. Standard mappings will allow tools to automate some of the conversion. In Figure 1, these target platforms occupy the thin ring surrounding the core.
When we map a platform-independent model to a particular platform, we produce not only artifacts native to that platform (IDL, deployment descriptors, etc.) but also a platform-specific UML model. We do this because the UML model can express the semantics of the platform-specific solution much more richly than IDL or XML.
Maximizing automation of the mapping step is a goal; however, in most cases some hand coding will be required, especially in the absence of MDA tools. As users and tool builders gain experience, and techniques for modeling application semantics become better developed, the amount of intervention required will decrease.
The platforms-pecific model faithfully represents both the business and technical runtime semantics of the application. It’s still a UML model, but is expressed (because of the conversion step) in a dialect (i.e. a profile) of UML that precisely mirrors technical runtime elements of the target platform. The semantics of the platformindependent original model are carried through into the platformspecific model.
We can generate a lot of the code and reduce the need for hand programming by an order of magnitude, and in some restricted cases we will be able to generate all of the code.
The next step is to generate application code itself. For component environments, the system will have to produce many types of code and configuration files including interface files, component definition files, program code files, component configuration files, and assembly configuration files. The more completely the platform-specific UML dialect reflects the actual platform environment, the more completely the application semantics and runtime behavior can be included in the platform-specific application model and the more complete the generated code can be. In a mature MDA environment, code generation will be substantial or, perhaps in some cases, even complete. Early versions are unlikely to provide a high degree of automatic generation, but even initial implementations will simplify development projects and represent a significant gain, on balance, for early adopters, because they will be using a consistent architecture for managing the platformindependent and platformspecific aspects of their applications.
Modeling as much of the application semantics as precisely as possible enables a greater degree of code generation.
Then the main direction
As the next generation of OMG standards, the MDA plays the role of the next generation Internet ORB, integrating across all middleware platforms — past, present, and future.
OMG, the organization that knows ORBs better than any other, is the ideal organization to extend this concept beyond middleware standards to a middlewareneutral, modeldriven approach.
Models are built, viewed, and manipulated via UML,transmitted via XMI
and stored in MOF repositories.
Formal declaration of semantics of systems (through modeling) will increase software quality and extend the useful lifetime of designs (and thus return on investment).zTrue integration requires a common model for directory services, events and signals, and security.By extending them to a generalized model, implementable in the different environments and easily integrated, the Model Driven Architecture becomes the basis of our goal of universal integration: the global information appliance.
We are continuing our quest to support integration and interoperability across heterogeneity at all levels. Our first mission, to enable integration through the introduction of the distributed object model, is complete: objects are the way systems are built today, at the core of every vendor’s enabling architecture and also at the core of all ebusinesses. But the integration task is not yet done. To focus on this, OMG will extend our focus from a middleware centric to a modeling centric organization.
CORBA is a foundation of this new architecture. As the only vendor and languageindependent middleware, it is a vital and necessary part of the MDA superstructure; software bridges would be hard to build without it. Extending this superstructure, the MDA is expressed completely in terms of modeling concepts, moving the reuse equation up one level.The need for integration remains strong and OMG’s work is not yet complete — we need to build on the success of UML and CORBA. With our experience, cohesive membership, established process, and tradition of consensusbased decisionmaking, OMG is in the ideal position to provide the modelbased standards that are necessary to extend integration beyond the middleware approach. We’ve outlined the task, and directions of the solution, in this paper.
Now is the time to put this plan into effect.Now is the time for the Model Driven Architecture._______________________________________
Ten years after this report was written, we can only congratulate Richard Soley and his team for the vision they proposed to the computer industry. Happy birthday MDA!