|
[ Home ][ Executive
Overview ][ MDA FAQ ][ Presentations
and Papers ][ Specifications ][ Education ]
[ Committed Companies & Their
Products ][ Success Stories ][
Vendor Directory ]
 |
|
"The
Architecture of Choice for a Changing World"
|
|
Model
Driven Architecture (MDA) FAQ...
Q:
What is the Model Driven Architecture® (MDA®) and
how is it different from other architectures?
A:
The MDA is a
new 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.
This
article in SD Times, by OMG's Dr. Jon Siegel, explains the MDA
development process in more detail.
Top
Q:
Can you tell me something about the history of the MDA?
A:
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.
Top
Q:
What is the role of UML and MOF in the MDA?
A:
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.
Top
Q:
What is the role of Patterns in the MDA?
A: 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.
Top
Q:
What is the role of middleware platforms in the MDA?
A: 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.
Top
Q:
How does MDA enable cross-platform interoperability?
A:
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.
Top
Q:
What services will be available in the MDA environment?
A:
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 here. 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:
Additional services, as suggested by the list of
CORBAservices already available, will be added as needed to
keep the environment complete.
Top
Q: How will Domain-Specific Software and
Standards take advantage of the MDA?
A: 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!
Top
Q: How does MDA compare or compete with Microsoft's .NET
or Web Services?
A: 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.
Top
Q:
Who is responsible for the MDA?
A:
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.
Top
Q: What are the top three benefits of the MDA to
enterprises trying to cope with today's computing
environment?
A: 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.
Top
Q:
How is the MDA being delivered? In what kind of tools?
A: 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.
Top
Last updated on
06/28/2012
|
