LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Making the Case:


OMG's Model Driven Architecture

By Jon Siegel
October 15, 2002 — 
Information technology serves the enterprise best when it focuses on business first, technology second, but this is hard to do when your most powerful tools focus exclusively on technology. Business modeling serves the enterprise, but needs to couple directly to IT in order to deliver the goods. Object Management Group Inc.'s Model Driven Architecture (MDA) makes the connection, unifying business modeling with technology (from legacy systems to the latest and greatest middleware platforms) into an industry-standard architecture that leading enterprises are using today to build and run IT systems that keep them ahead of the competition. In this article we'll describe the MDA, starting with its foundation on world-class business modeling, and show how this extends into the technological realm to support the portability and interoperability on which today's enterprise depends.

But first, why focus on modeling? Because modeling is the only way to ensure that enterprise IT systems deliver the functionality that a business requires, comprehensive and stable, yet able to evolve in a controlled manner as business needs change over time. Models built in the Unified Modeling Language (UML) represent exactly what a business application-even a complex, multiplatform integrated application-can do, and record it with a clarity and stability that far exceeds that of the applications themselves, which change with the technological fashion. An enterprise with a repository of models has a confidence level in its IT that cannot come from any other source. Based on technology-independent representations of their business functionality and behavior, its applications last for decades and maximize IT return on investment (ROI).

If modeling is the answer, why doesn't every enterprise center its IT on a group of architects and designers today? Pre-MDA, models and code have been developed separately by different groups of people. Programmers regarded the models as guidelines or rough plans rather than firm requirements. Disadvantages abound: Compared with development without modeling, in this environment it costs twice as much and takes twice as long to produce a final application that resembles and benefits little from its model, regardless of how good it may have been.

The MDA addresses this problem directly, codifying and standardizing the steps that take a model through development into implementation. Automating the route set down by the OMG standard, MDA-based tools produce applications that faithfully meet the business and nonbusiness (scalability, security and so on) requirements built into models by domain experts and IT architects. Models become the prime development artifact in this environment, not only defining and recording business requirements, but also serving as the basis for development, maintenance and evolution.

This architecture brings many benefits. Some are business-oriented (requirements built into the model always appear in the final implementation); others technical (MDA-based applications are interoperable, portable and middleware-platform-independent). If you're building a Web services application, you're surely coupling a number of legacy functions on legacy middleware to a new front end. The OMG believes that MDA is the best possible way to design and build this kind of application.

MDA BASICS
Encompassing both the modeling and development spaces, the MDA is a comprehensive IT architecture that unifies business modeling and implementation into a synergistic environment that maximizes IT ROI and gives businesses that employ it a competitive advantage. Encompassing every aspect of IT, from technology-independent modeling of business functionality and behavior, through development and integration on virtually every platform used in the industry today, to deployment and maintenance, and extending to evolution to tomorrow's new platforms when shifts in technology require, the MDA is standardized and supported by dozens of prominent vendors (including IBM, HP, Rational, Iona, Borland and many others) in both declarations and products on the market today.

In this article, we'll describe the basic structure of the MDA and explain how it delivers the benefits we've already listed, plus these:

• MDA-enabled tools follow OMG-standardized pathways to automate the transformation from your designers' business model into your implementation, producing new applications faster, better and cheaper.

• The MDA process ensures not only that the business requirements built into the design end up in the final implementation, but also that nonbusiness functional requirements (such as scalability, security and transactionality) carry through as well.

• Code generated by MDA-enabled development tools derives from libraries based on patterns designed by the industry's best developers. Few companies have access to programmers with the skill level to produce code as well suited for infrastructure and application as the next few generations of MDA tools will produce.

• MDA applications interoperate: The MDA, designed from the start to implement in multiple middleware platforms, codes cross-platform invocations where needed, not only within a given application, but also from one to another regardless of the target platform assigned to each.

• MDA applications are portable: Based on technology-independent business models, they can be generated on any middleware platform.

• MDA applications are future-proof: When new platforms are introduced (as they must be over the next decades as networking continues to mature and computers become smaller, more specialized and more ubiquitous), OMG will add mappings for them and tool vendors will implement them in their offerings. Using these new mappings, existing MDA-based applications can be made either to interoperate with others, or can be reimplemented on the new platform entirely.

• The MDA supports enterprise application integration (EAI): Think of your entire enterprise's suite of applications as a library of UML models. Select the ones that need to work together, bring them into your MDA tool simultaneously, and draw lines denoting the interoperability pathways. When you generate the application, the invocations will be part of it.

Because the MDA is technology-independent at its core, an application or standard defined in the MDA can be implemented equivalently and interoperably on one or several middleware platforms. Business segments benefit tremendously from standards that can be used by multiple companies in the industry, each on its preferred middleware platform, with full interoperability among them.

It's no accident that MDA comes from OMG: We already provide the industry with its modeling standard (the Unified Modeling Language, UML) and foundations for modeling (the Meta-Object Facility, MOF, and Common Warehouse Metamodel, CWM), and the vendor-independent middleware standard CORBA with its libraries of services and facilities. The MDA builds logically on this foundation.

MDA STRUCTURE
Here's how it works: Think of MDA as a spectrum with business at the top and technology at the bottom. Your business domain experts work at the top, of course, in modeling space. Here, UML-based tools provide support and the UML language's structure and narrower profiles (i.e., tailored subsets) provide guidance. The product of the first development step, termed the Platform-Independent Model, or PIM, represents the business functionality and behavior that this MDA application will execute, as undistorted by technological factors as possible.

As you move down toward the bottom, the business domain recedes and technology takes over. In a perfectly efficient world, the MDA might jump directly from the business model at the top to the implementation at the bottom, but today the discontinuities are too great, so the MDA inserts an intermediate step. (The artifact produced in this step is termed the Platform-Specific Model, or PSM.) Produced primarily by MDA-enabled tools following OMG-standardized mappings, the PSM provides a way station where your skilled architects can mark up the model with their preferences or hints about how they want particular steps to be designed, or execute.

The completed PSM contains the same information set as a coded application, but in the form of a UML model instead of program language and makefiles. Taking advantage of the tight mapping, today's MDA-enabled development tools automate the conversion from PSM to code very well. In fact, this step is more mature than the PIM-PSM conversion in the previous step.

This overall structure makes a lot of sense, especially compared with today's alternative development practice: Using the MDA, your input and investment concentrate in the business zone at the top, where decisions can make or break your company. Once you've specified the business functionality, you turn development over to automated tools (assisted by your skilled architects). Drawing from libraries of code assembled by the most skilled programmers available, these tools build scalable, secure, enterprise-quality applications. Cross-platform invocations, hard to program but hardly creative, are coded and maintained by machines, not people.

Building MDA Models.

MDA models must be extremely detailed: The application will be generated from it, and will include only functionality represented explicitly-in the MDA, the business designers and architects play a crucial role.

PIMs are designed in one of a number of OMG-standardized UML profiles-that is, subsets of UML tailored to specific environments. For example, OMG has defined a profile for Enterprise Distributed Object Computing (EDOC), especially good at modeling collaborations of all types (think of a sales transaction as a collaboration, and then generalize), and a profile for EAI, specialized for applications based on asynchronous communication. Additional profiles are used to define PSMs.

Interoperability.

An MDA application is not constrained to make all of its remote (and even internal) invocations using the middleware of its PSM-the code generation process is flexible, and the code database of an MDA tool includes invocation formats for every supported middleware platform.

Taking advantage of this, developers will pull models of existing applications and services from libraries into the project's environment as they construct new PIMs, and set up cross-platform invocations by simply drawing the connections in their new model. It's likely that some of these existing applications will not be on the same platform as the new PSM. Taking its cue from the actual middleware platform of these existing applications, MDA tools will generate cross-platform invocations where needed.

Integrating Older Applications.

Any legacy application based on a UML model and a supported middleware platform can be included in a company's circle of MDA interoperability by simply importing its model into MDA tools as PIMs for new applications are built. Lack of a model is not a barrier; tools on the market today reverse-engineer UML models from code, and some even work from executables. Alternatively, stand-alone legacy applications can be wrapped with a layer of code that exposes key functionality to the network on a suitable middleware, and the model for this functionality and its interfaces stored in a library for use by MDA developers.

Pervasive Services.

Every distributed application needs essential services: Naming/directory, transactions, distributed event handling and security are used in virtually every application, but other services come in handy as well. OMG's Object Management Architecture contains the industry's most mature set of standardized services. Originally constructed for CORBA, these now define security, transactionality and persistence for J2EE thereby proving their multiplatform applicability. OMG will retro-fit these services to the MDA by extracting UML models and generating uniform service definitions for virtually every platform: Web services, .NET, messaging environments and more.

Domain-Specific Specifications.

Until now, industries have typically defined computing standards in a particular technology. This is necessary to guarantee interoperability, but requires every company to use the same middleware. Worse yet, when technology advances and the chosen middleware platform is superseded, the standard and all of its users are forced to port to something new.

By defining standards in the MDA, industries avoid both of these severe disadvantages: Defined fundamentally as a PIM, their standard can be implemented equivalently and interoperably on multiple middleware platforms. Over time, if one or some of these platforms become obsolete, the industry can define new implementations on new platforms from the original PIM. Many industries are working on MDA standards at OMG now, including telecommunications, biotechnology, manufacturing, health care, finance and more.

We've listed many of the benefits of the MDA and described, in a very general way, how the architecture supports them. OMG members adopted the MDA as the group's base architecture in September 2001. Many developments at OMG support the MDA, including adoption of profiles for additional platforms. Upgrade of the UML specification to revision 2.0 is being tailored to MDA needs, and OMG's domain Task Forces were quick to expand from their CORBA-only architecture to work in multiple platforms with the first non-CORBA domain specification, the Gene Expression Model from the Life Science Research Domain Task Force, being adopted in May 2002.

OMG members invite you to learn more about the MDA and the specifications that comprise it at the OMG Web site. The best place to start:www.omg.org/mda.

Jon Siegel is vice president of technology transfer at Object Management Group Inc.


Share this link: http://www.sdtimes.com/link/26807
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading