当你重视目标平台和中间件时，构建基于Web的分布式应用会变得更容易。
                                                                                                         ―― Peter Varhol      

      在软件开发中，过去我们经常看到开发人员犯同样的错误。其中意义比较重大，并且长期以来存在着很大分歧的错误，就是应用架构是在特定平台和操作系统上写成的。这个错误在大型分布式应用中尤其显著。这种情况在最初时可能没什么问题，但是随着平台和操作系统的变化，特别是遇到不可预见的情况时，问题就暴露出来了。

      当然你可能还要依靠其他一些软件，例如应用服务器、浏览器或者数据库管理系统。在很多情况下，这些应用比底层的硬件和操作系统更加趋向与动态。最终导致的结果是，当底层的硬件或操作系统发生变化时，必须对应用做重大调整才能使其正常工作在新的环境下。有些情况就更加糟糕了，一些应用的架构与它的底层支撑技术紧密结合，当底层支撑技术发生变动时，往往意味着整个的上层应用都要被推翻重新设计。

       进入MDA的世界吧！MDA能够将应用框架和其实现相分离。MDA的支持者希望支撑软件和硬件的改变不会使现有的企业应用无法使用。更重要的是，通过降低应用架构和其运行环境的耦合度，MDA能够带来更加优秀的设计，从而使应用寿命更加长久并且能够很容易地移植到其他底层平台上。

       如你所料，MDA使基于统一建模语言的(UML)的。当然光有UML还远远不够，MDA还要使用Meta-Object Facility (MOF) and Common Warehouse Meta-model (CWM)。MDA由许多核心模型、或用于企业级开发和其他一些用于实时开发的框架组成。其他的核心模型将会逐步作为标准开发并提供出来。MDA结构和工艺时对象建模组织(OMG)的一个标准，COBRA和UML也是这个组织维护的。

       UML提供了能够清除地描述嵌入式系统的可视化建模技术。UML定义了几个图形视图为开发提供了不同的系统透视图。每一个图标表现完整模型的不同方面。例如：用例图（use-case diagrams）和次序图（sequence charts）用于分析和确定系统；系统的行为可以用状态图（State charts）来建模。尽管每一个图表反应系统不同的方面，但是他们之间是有交迭的，至少是存在着依赖关系。UML图可以软件架构、行为以及与系统其他部分的协作建模。UML用部署图（deployment diagrams）描述系统的物理架构。部署图只是用几个简单的图像，因此很容易理解和实施。节点（Node）代表系统的重要物理对象。而交互连接（Interconnect）代表物理对象之间的连接。活动对象（Active Object）定义了分派给对象的任务。节点可以通过活动对象组合成能够在平台上部署的子系统。

      协作有助于决定在全局计算环境下应用适合什么位置，其中最重要的方面就是确定合适的目标平台。UML通过使用协作图来建模协作。协作图关注协作对象的静态结构。也可以是用次序图来完成这一工作。次序图描述了对象之间的信息。

      应用MDA的第一步就是用UML创建应用的模型，建模主要集中在建立应用的架构、行为和协作。这些模型是平台无关的。UML以框图的形式清晰的描述了应用的架构，以及它的行为和其与其他系统元素的协作。

      然而，目前为止，我们做的这些还不是软件的实现。有很多有效的工具可以帮助你将UML建立的框图转换成实际代码。但是你丢掉了很重要的一个因素，那就是应用可能用到的操作系统和中间件的特性。一个简单的例子就是Windows和对话框。有时程序在观念上就利用操作系统或平台（包括Java）服务，在特定平台上实现。

      因此出现了中间件。要实现分布式系统，就要确定使用CORBA, COM,  Java信息服务(JMS), Web服务还是其他支持技术。在实现应用时这些技术都要考虑到，但是这些技术却是在建模之外的。

      那么下一步就是让将模型转化成。MDA这一步处理的结果就是使UML模型映射到特定平台下的UML模型以及本地平台结构。应用的UML标识也维护着相同的内容，但是许多通过特定技术指引实现的附加信息加入来了。

      一旦UML模型指向了特定平台和特定技术，那么它就可以在那个平台上实现了。这是另一个有趣的过程。从特定平台上的模型到特定平台上的实现，你要作的当然不仅仅是代码生成，而是比代码生成多得多的事情，尤其是基于Web的分布式应用，要做的就更多了。因为基于Web的分布式应用要求你组合源文件、配置文件、定义文件和资源文件。用一句话概括，就是你构建一个基于Web的分布式应用时所需要创建的所有文件。

      这个方法看起来并不会给你带来多少利益除非某些文件创建工程时自动完成的。毕竟仅仅依靠UML模型和代码生成器，你就得通过模型将代码生成出来，然后再通过某些方法手工修改代码使其适应你的特定平台。让平台相关模型失去自动生成那些代码的能力可能并不比目前所能作的更加优越。然而一旦工具链从UML模型延伸到创建平台相关代码，MDA的优势就显现出来了。

      MDA当然不是专门为Java或Java 2 企业版（J2EE）而存在的。在保持技术独立的前提下，MDA允许使用.NET、J2EE、Web服务以及其他支持分布式应用的技术来实现应用架构。但是Java应用，尤其是那些跨系统、跨平台，使用Web界面的应用，最终都可以借助MDA来实现快速构建。

      MDA对于J2EE开发者来说到底意味着什么？由于Java语言的动态属性以及Java社区接受新技术的速度，MDA是延长应用的寿命，使其长于支持技术的寿命的唯一可行的方法。然而随着时间的流逝，底层技术也在不断的发展，一个合理架构的MDA能让应用持续有效。

      Java开发人员对此应该会万分激动。由于Java社区的活力，使得Java更新的速度比其他任何语言都快。设计应用时可以不需要考虑Java技术和版本变化带来的冲击会带来在开发时间和可靠性上会带来很多好处。很多时候我们要花在使应用适应不同版本的虚拟机JDK上的时间和实际写代码的时间一样多。MDA能够将这些时间从你的开发周期里抽取出来，把它交给能够完美的处理复杂平台的工具来完成。

      市面上生成支持MDA的开发工具越来越多，其中大多数是Java阵营里的，因为Java提供了从平台无关到平台相关的简易的建模途径。支持MDA意味着什么？没什么，至少现在并不意味着什么。大体上看来，目前支持能够传见平台无关模型的UML工具都被称作支持MDA。这些工具提供的能力只是自动实现MDA工程的第一步，建立模型，并且在某些情况下生特定平台下的代码。

      另一个不断有新工具涌现的领域是平台无关模型到平台相关模型的映射工具。简单地将模型转换为平台相关模型实际上却并不是很好理解，这比代码生成高级的多。这需要对构建技术有深厚的理解，而且知道如何将设计翻译成技术的构建模块。

      然而实际情况比这更加复杂。每年Java会出好几个版本和中间件技术。如果你使用流行应用服务的流行版本，MDA可以帮助开发团队更好的管理复杂度。
为了获得更好的软件质量，MDA允许开发人员进行更高层次的提取，而让软件来做具体的工作。在过去，能够很好地生成通用代码和特定平台和技术下的代码。MDA代表了应用开发领域的下一个技术舞台，并承诺大幅度改善J2EE应用的构建。

      但是MDA不是万能的。MDA并不能帮助开发人员写出比目前能写出的更好的代码。质量在复杂的技术和中间件理解中并不凸现，但是能够将用户的需求翻译成有用的、可靠的应用。与平台技术不同，通过需求创建成功应用的技术不会过时。MDA能够使开发变得简单，但这仅当你已经充分理解了你要做什么的情况下。