MDA FAQ

In 1996, OMG expanded its scope to include modeling and in 1997 adopted the Unified Modeling Language™ (UML)® and Meta-Object Facility™ (MOF™). Although it has always been true that UML models can be implemented on any platform, the continuing proliferation of middleware "silver bullets" suggested that a platform-independent MOF-based model is the secret to software stability and ROI - a stake that remains fixed in the ground while the infrastructure landscape around it shifts over time. The MDA unites OMG's well-established modeling standards with every middleware technology - past, present, and future - to integrate what you've built, with what you're building, with what you're going to build. Rather than focusing on yet another "next best thing," MDA raises the bar and designs portability and interoperability into the application at the model level.

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."

Patterns play a critical role in most MDA-based development projects. Successful transformation from PIM to PSM, and from PSM to code, requires that the PIM contain enough detail to completely guide the software tools through the process. By incorporating this detail through the use of patterns, instead of inserting it by hand, we gain multiple benefits: Our architects do less work, the resulting PIM reflects the collective wisdom of many contributors, and the tools can work the pattern (parameterized as necessary in our UML models) through the transformations, ultimately pulling implementation code from a library written by experts and inserting it into the application.

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.

In the MDA, the base specification of every service, facility, and application is a platform-independent model. Architects specify links from an application to needed services and facilities, and to other applications, as part of its model. As the PIM for the new MDA specification or application is transformed into a PSM and then a coded application by the MDA tool chain, interoperability with other applications and services is built into it according to these links which are implemented properly regardless of the target's native middleware.

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

Additional services, as suggested by the list of CORBAservices already available, will be added as needed to keep the environment complete.

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!

MDA works at a different level than .NET and Web Services. These are individual platforms, aimed at specific albeit broad application targets, while the MDA is (as its name declares) a Model Driven Architecture that works above the level of every middleware platform, .NET and Web Services included. A middleware platform is incorporated into the MDA as a platform-specific profile. As .NET and Web Services establish market share, OMG members will define platform-specific profiles for them, allowing them to participate in the MDA along with the other platforms which will almost certainly include Java/EJB and additional protocols and platforms dictated by the industry or the marketplace.

The MDA became the official base architecture for OMG specifications by unanimous votes of the technical representatives attending the organization's meeting in February, 2001. Like all the other work of the OMG, MDA was defined and will be developed by the OMG membership which includes a diverse cross-section of computer vendors, software suppliers, and many end-users. (If your company is an OMG member, please come to our meetings and get involved! If it's not, here is information about membership and an invitation to join us.) The wealth of experience contributed by these hundreds of organizations is one of the great strengths of OMG's process, and has been put to good use in defining and refining the MDA. This technical architecture document is the current MDA specification. The initial vision was drafted in late 2000 in this OMG white paper, and subsequently refined with the help of many individual contributors into this technical perspective.

There are many benefits to using the MDA approach, with the most important being:

• 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.