The MDA is OMG's way of developing applications and writing specifications, based on a platform-independent model (PIM) of the application or specification's business functionality and behavior. A complete MDA specification consists of a definitive platform-independent base model, plus one or more platform-specific models (PSM) and sets of interface definitions, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support.MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology platform or platforms on which it will be implemented. In this way, MDA divorces implementation details from business functions. Thus, it is not necessary to repeat the process of defining an application or system's functionality and behavior each time a new technology (Web Services, for example) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once. Mapping from a PIM through a PSM to the supported MDA platforms is being implemented by tools, easing the task of supporting new or different technologies.
Even though UML® is usually thought of as the basis for MDA® because of its visibility, it is actually MetaObject Facility™ (MOF™) compliance that is formally required in order for a tool or tool chain to be labeled "MDA Compliant". The MOF is OMG's foundation specification for modeling languages; MOF compliance allows UML structural and behavioral models, and CWM™ data models, to be transmitted via XMI®, stored in MOF-compliant repositories, and transformed and manipulated by MOF-compliant tools and code generators.
Although not formally required, UML is still a key enabling technology for the Model Driven Architecture and the basis for 99% of MDA development projects. (Work in some specialized fields requires specially tailored modeling languages, although the additional capabilities added to UML by the 2.0 revision satisfies this need in many cases.) So, application development using the MDA is typically based on a normative, platform-independent UML model. By leveraging OMG's universally accepted MOF and UML standards, the MDA allows creation of applications that are portable across, and interoperate naturally across, a broad spectrum of systems from embedded, to desktop, to server, to mainframe, and across the Internet.
The basis on MOF was made official in August, 2004, when OMG's Object and Reference Model Subcommittee (ORMSC) unanimously adopted the definition of MDA that is being used to revise the official MDA Guide (from this current version). The August definition states:
"Any modeling language used in MDA must be described in terms of the MOF language, to enable the metadata to be understood in a standard manner, which is a precondition for any ability to perform automated transformations."
In the MDA, middleware-specific models and implementations are secondary, rather than primary, artifacts: A specification's PIM - the primary artifact - defines one or more PSMs and sets of interface definition, each specifying how the base model is implemented on a different middleware platform.Because the PIM, PSMs, and interface definitions are all part of an MDA specification, OMG now adopts specifications in multiple middleware platforms under the MDA. Suitable targets for MDA development projects and OMG specifications includes Web Services, XML, .NET, EJB, and of course OMG's own favorite, CORBA.
OMG members are well aware of the extensive services necessary to support distributed computing, both within an enterprise and among many over the Internet. In CORBA, OMG's answer to this need was originally the CORBAservices, already defined and available. In the MDA, these have been renamed the Pervasive Services because a single implementation of each, regardless of the platform on which it runs, can service every application or client that needs its capabilities via MDA-generated cross-platform bridges. Enterprises struggling to maintain and synchronize large directory services replicated on multiple platforms will surely appreciate the opportunity to trim down to a single instance!OMG plans to define four Pervasive Services:
- Directory Services
- Transaction Services
- Security Services
- Distributed Event and Notification Services
The MDA has so many advantages for industry-specific software that some of OMG's Domain Task Forces started writing specifications in the MDA before it became an official part of our architecture!
In order to benefit an industry, a standard must be used by a critical mass of companies. Technology-specific standards will have trouble getting established where platform incompatibility prevents achieving this critical mass. Sometimes the problem is even deeper than this: In some industries, architecturally excellent standards have been adopted in the formal sense but failed to gain hold because they were written for a platform that few companies were willing to support.
MDA completely removes these roadblocks. Under MDA, the functional description of every standard is technology independent, and the architecture is capable of producing interoperating implementations on multiple platforms. This allows an industry to define the business functionality and behavior of its standards as a PIM, and then produce PSMs and implementations on whatever platforms the participants require.
In addition, technology-based standards become obsolete as their base platform ages; in fact they lose some of their appeal as soon as a new platform gets some play in the industry press. This is not a problem for MDA-based specifications: Because they are based on platform-independent PIMs and can be made to interoperate with new platforms, or even re-implemented on them, through the MDA development process, MDA-based applications and specifications are truly "future-proof".Bottom line: Using MDA, the industry gets a standard, every company uses it, none are forced to switch platforms in order to benefit, and the standard lasts as long as the industry process that it serves. Everybody wins!
- In an MDA development project, attention focuses first on the application's business functionality and behavior, allowing stakeholders' investment to concentrate on the aspects that critically affect core business processes. Technical aspects, also critical but secondary to business functions, are well-handled by automated or semi-automated development tools.
- An architecture based on the MDA is always ready to deal with yesterday's, today's and tomorrow's "next big thing" and makes it easier to integrate applications and facilities across middleware boundaries.
- Domain facilities defined in the MDA by OMG's Domain Task Forces will provide much wider interoperability by always being available on a domain's preferred platform, and on multiple platforms whenever there is a need.
All of the key parts of the MDA vision have already been standardized, including not only UML 2.0, the MOF, XMI and CWM, but also a number of middleware mappings (including one to OMG's own CORBA and a middleware-independent mapping for enterprise systems called "UML Profile for Enterprise Distributed Object Computing").In terms of products, MDA is being implemented by tools - or tool chains, which may come from a single vendor or a number of vendors - that integrate modeling and development into a single environment that carries an application from the PIM, through the PSM, and then via code generation to a set of language and configuration files implementing interfaces, bridges to services and facilities, and possibly even business functionality. Several vendors already provide tools that support integration at about this level, including substantial code generation. OMG has collected links to MDA products and vendors that we know about here. Today's tools typically automate 50% to 70% of the PIM-to-PSM transformation; because the industry got started on the second step much earlier, automation of the PSM-to-code transformation is typically 100% or nearly so.