Richard Soley
主席兼首席执行官，OMG &OMG Staff Strategy Group, Object Management Group, Inc.
2004 年 9 月
“CORBA 是我们首先迈出的重要一步，但今后的路还很长。”
- Fred Waskiewicz，OMG Director of Standards
从一开始，Object Management Group （对象管理组，OMG）就为企业提供了独立于供应商和语言的互操作性标准。针对需要专门的实时系统、容错系统和嵌入式系统的环境，CORBA （Common Object Request Broker Architecture，公共对象请求代理体系结构）标准最近进行了修订，并受到了欢迎。OMG 有一组互相补充的核心建模规范，包括 UML（Unified Modeling Language，统一建模语言）、CWM（Common Warehouse Meta-model，公共仓库元模型）、MOF（Meta-Object Facility，元对象设施）和 XMI（XML Metadata Interchange，XML 元数据交换）。
在 CORBA 和 UML 取得成功的基础上，现在 OMG 把目光投向了随着企业中间件的普及而引起的问题。它的 MDA（Model Driven Architecture，模型驱动体系结构）计划支持 CORBA 的扩展性和可靠性，同时又承认企业无法轻易放弃在其他技术上的投资。（关于 MDA 的更多信息请访问 [URL=http://www.omg.org/mda/index.htm]www.omg.org/mda[/URL]）。
在和其他 OMG 成员公司一道创建 MDA 的过程中，Rational Software 非常积极地贡献了自己的思路和原则。如果您是一位对建模或者软件开发基础设施感兴趣的 Rational 用户，我想您将会对本文所介绍的 OMG MDA 的概念、目标和计划感兴趣。
过去的十年左右，中间件领域不断变化。多年来，我们设想最终会出现一个绝对的赢家，使这种一盘散沙的状态稳定下来，而时间公开承认了我们很多人一直埋在心底的怀疑：新竞争者的出现永远不会停止！虽然最新的中间件平台有很多优势（有时候是真的，有时候是想象的），但新旧之间的迁移几乎总是非常昂贵而且易于造成混乱。
OMG 的分层服务和纵向型市场（vertical market）规范建立在 CORBA 的基础上，这是我们认为的最佳中间件，它是严格通过 OMG 社区过程建立的。但是我们也看到，企业中常常还有其他中间件上的应用程序必须集成到新的或者改变后的系统中，尽管这个过程非常耗时而且昂贵。此外，这些企业所用的中间件也在不断的演化中。
使问题更加复杂的是，在 Internet 卷入企业市场之前，企业往往在防火墙之内和之外使用不同的通信技术。现在，一些企业希望把为内部通信而建立的组件公开到防火墙之外，比如为了进行 B2B 电子商务。另一些则由于收购或者合并，希望把外网上的组件移到防火墙之内。因此，除了要解决基本的集成问题之外，IT 企业还必须找出一种方法，在由于企业边界移动而造成底层技术也发生变化时，能够保护它们在新组件方面的开发投资。
解决问题的方案：模型驱动体系结构
所幸的是，有一种办法可以应付这种情况。在 OMG 核心建模标准的基础上，我们建立了MDA（Model Driven Architecture，模型驱动体系结构），它是语言、供应商和中间件中立的。
如图 1 所示，这个体系结构的核心建立在 UML、MOF 和 CWM 上。目前已开发了多个 核心模型[URL=http://www-900.ibm.com/developerWorks/cn/rational/r-mda-tmi/#1]1[/URL] ： 一个表示企业计算，包括组件结构和事务交互；一个表示实时计算，包括资源控制的特殊要求；还将增加更多模型来表示其他专门的环境。每个核心模型都独立于任何中间件平台。然而，总数不会很大，因为每个核心模型都表示所属类别中所有平台的共同特性。[URL=http://www-900.ibm.com/developerWorks/cn/rational/r-mda-tmi/#2]2[/URL]
无论最终目标是 CCM（CORBA Component Model，CORBA 组件模型）、Enterprise JavaBeans（EJB）、Microsoft MTS 还是新的 .NET 体系结构，或者其他基于组件或基于事务的平台，构造基于 MDA 的应用程序的第一步都是使用 UML 创建一个平台独立的、与适当核心模型一致的应用程序模型。然后，平台专家可以把这个一般的应用程序模型转化成针对特定平台的模型，如 CCM、EJB 或 .NET。图 1 把这些目标平台放在围绕核心的简单环形结构中。
图 1 ： OMG 模型驱动体系结构
虽然标准映射使工具能够自动完成某些转换，多数情况下还是需要一些手工编码，特别是在缺少 MDA 工具的情况下。随着用户和工具构建人员积累的经验越来越丰富，建模应用程序语义的技术越来越先进，对人为干预的需要也会越来越少。
特定于平台的模型忠实地表示了应用程序在业务和技术上的运行时语义。它仍然是一个 UML 模型，不过是用 UML 的方言（也就是概要文件）表示的（因为经过了转换步骤），这种方言准确地反映了目标平台技术上的运行时元素。原来的平台独立模型的语义被带入特定于平台的模型中。
下一步是生成应用程序代码本身。对于组件环境而言，系统必须生成多种类型的代码和配置文件，包括接口文件、组件定义文件、程序代码文件、组件配置文件和装配配置文件。特定平台的 UML 方言对实际平台环境的反映越完整，在特定平台的应用程序模型中能够包含的应用程序语义和运行时行为就越多，生成的代码也就越完善。在成熟的 MDA 环境中，如果使用 Rational Software 及其竞争对手提供的工具，代码生成是很有价值的，有时候甚至很完善。早期版本不大可能提供高度的自动化生成功能，但总体来说，对于早期的采用者而言，即使最原始的实现也可以简化项目开发，这代表了重大的收益；他们将使用统一的体系结构来管理应用程序独立于平台和特定于平台的各个方面。
如图 1 所示，很多当今的连接技术将通过 MDA 来集成，为明天的“下一代最佳方案”留下了空间。CORBA 代表了最佳的中间件选择，因为它是供应商和语言中立的，很容易连接到所有其他中间件环境。但是，为了适应那些网络上具有多种中间件平台的企业，很多非 CORBA 平台也将被合并到 MDA 中。其中最先一个将是纯 Java 的 EJB。
增加新的中间件平台
由于 MDA 在核心上是平台独立的，向这个互操作环境中添加新的中间件平台非常简单：在确定新平台表示和实现公共中间件概念和功能的方式之后，OMG 成员可以把这些信息作为映射合并到 MDA 中。各种面向消息的中间件工具，再加上 XML/SOAP（简单对象访问协议）和 .NET，将以这种方式集成进来。事实上，通过消除某些行业提出的 XML文档类型定义（DTD）的冲突，MDA 可以帮助企业对不同的文档互操作。随着多种中间件平台添加到 MDA 中，MDA越来越成熟，类似于桥接器（bridge）、网关（gateway）和从一种平台到另一种平台的映射（mapping）等集成工具的生成将变得更加自动化。
互操作性在同一类应用程序中最为透明：企业应用程序和其他企业应用程序；实时应用程序和其他实时应用程序。这和我们采用的每种类别均有单一核心模型的方法是一致的；应用程序类别之间的差异使我们不能把所有应用程序都建立在单一核心模型上。但确定和利用两种或多种类别的公共概念能够在某种程度上打破相互之间的藩篱。
处理遗留应用程序
到目前为止，我们的讨论都是假设从头开始构建应用程序及其模型。遗留应用程序提出了另一项挑战：很多应用程序是在组件环境还没有出现之前构建的，不能很好地符合任何一种核心模型。但是，通过包装与 MDA 核心模型一致的代码层，遗留应用程序也可以引入到 MDA 中。如果首先构建包装程序的 MDA 模型，那么包装程序的外部部分（即面向网络并与其他应用程序和服务互操作的那一部分）就可以自动生成，至少可以部分自动生成。包装程序的另一部分（即对遗留应用程序本身进行调用并返回的那一部分）通常必须手工编码。
Internet ORB
MDA 是目前正在开发的下一代 OMG 标准，它可以作为 ORB（Object Request Broker，对象请求代理程序）来整合所有中间件平台，无论过去的、现在的还是将来的。OMG 是对 ORB 理解最深刻的组织，最适合于肩负扩展这一概念的职责，不仅仅是中间件标准，而是成为一种中间件中立的、模型驱动的方法，为用户带来以下具体的好处：
企业可以使用所选的中间件构建新的基于 MDA 的应用程序。他们可以放心地知道，因为应用程序的基本语义系统地凝聚在平台独立的模型中，如果将来需要使用不同的中间件（或者相同中间件的新版本），这种迁移是相当易于管理的。此外，通过使用一致的体系结构和某种程度的代码生成，他们能够系统地建立与企业中其他基于 MDA 的应用程序之间互操作性的桥梁和通路，以及与客户、供应商、业务合作伙伴之间的联系。
保持公司业务正常运转的遗留应用程序，只要按照前面所述方法进行包装并将其功能合并到 MDA 中，就可以与企业当前应用程序互操作。这些程序仍然保留在建立它们的平台上，MDA 可以帮助自动构造从一个平台到另一个平台的桥梁。
各个层次的行业标准将包括按照 MDA 核心标准定义的平台独立模型：您可以买到完成标准功能的标准设施而不必自己构建，由于这些标准设施均以 MDA 为基础，因此提高了其互操作性和可演进性。我们将在后面介绍这类设施及其作用。
当出现新的中间件平台时，OMG 的快速且遵循多数意见的标准化过程将通过定义新的标准化映射，把它们合并到 MDA 中。然后，MDA 工具将针对新的平台实现到平台独立模型的转换。这些工具也能够支持到新平台的桥梁。
开发人员可以获得最大限度的灵活性，当底层基础设施随时间变化时，能够从稳定的、平台独立的模型重新生成代码。在软件生命期尤其是长期的支持和维护过程中（这也是应用程序生命周期中最昂贵的一个阶段），应用程序和领域模型的重用将提高 ROI。
模型通过 UML 来构建、查看和操纵，通过 XMI 传输，在 MOF 资料库中存储。
系统语义的正式文档（通过建模）将提高软件质量，延长设计的有效生命周期（从而提高 ROI）。
利用我们的标准和支持这些标准的工具，OMG 成员正在完成集成方面的工作。他们在定义 Enterprise Computing Core Model（企业计算核心模型）并把它映射到应用最广泛的中间件平台。他们也在定义实时计算的核心模型。
标准化领域模型
自从 1996 年 1 月以来，很多 OMG 成员参加了 Domain Task Forces（领域任务组，DTF），标准化特定纵向型市场的服务和设施成为了社区关注的焦点。目前，这些规范包括用 OMG 交互式数据语言（Interactive Data Language，IDL）编写的接口和相应的英文语义说明。就像我们对 CORBA 所做的那样，在平台层次上标准化组件无疑是一种解决集成和互操作性问题的可行方案，但是现在我们准备更进一步。
计划良好的服务或设施总是建立在独立于目标平台的底层语义模型的基础上，即使没有明确地描述该模型。OMG 的领域规范就属于这种情况，因为它们的模型没有从 IDL 接口中单独表示出来。由于它们的模型是隐含的，这些服务和设施在 CORBA 环境之外既没有得到它们应得的认可，也没有得到广泛的实现和使用，尤其是考虑到它们的底层模型的质量。把隐含的模型扩展到 CORBA 外显然是合理的。例如，OMG 已经使用 Java、EJB 以及 CORBA 实现了“医疗保健资源访问决策设施（The Healthcare Resource Access Decision Facility）”。还有更多的正在进行之中，如图 1 所示。
基本上每个 DTF 都会产生所属应用程序空间中用于标准设施的标准框架。其中包括规范的、平台独立的 UML 模型，并附有非正式的、特定于平台的 UML 模型以及至少一种目标平台的接口定义。MDA 的公共基础也会促进部分代码的生成和实现，当然这些代码不是标准化的。
比方说，对于制造业，DTF 可以为 CAD/CAM 互操作性、PDM（Product Data Management，产品数据管理）和供应链集成（如图 2 所示）生成规范的 MDA UML 模型、IDL 接口、Java 接口、XML DTD 等等。一旦这些模型完成并被采用，它们的实现可以在任何 MDA 支持的中间件平台上部分自动化。
图 2： 制造业基于 UML 的模型框架
该例中的三种设施： CAD/CAM、PDM 和供应链都将从只有 MDA 才能提供的互操作性中受益。因为 CAD/CAM 和 PDM 应用程序紧密地结合在一起，很可能由单个企业或和软件供应商实现，比方说，CORBA 或者 EJB。而供应链集成更注重于企业间的功能，因此我们可能期望一种基于 XML/SOAP 的实现能够得到普遍认可，它受到行业市场决策者或商业组织的支持。然而这三者之间的互操作是根本性的：CAD/CAM 设计提供驱动供应链的 PDM 产品设施，而供应链又反过来引用 CAD/CAM 中特定的部件。如果这三方面的功能都从 MDA 中的 UML 模型出发，我们最终可以为各自选择的平台生成大部分实现，以及整合这三种设施之间的桥梁。
包括普及服务
企业、Internet 和嵌入式计算依赖于一组基本服务。这些服务在一定程度上取决于资源，但通常包括目录服务、事件处理、持久性、事物和安全。此外，计算系统或应用程序在硬件或软件上可能具有专用属性，比如可伸缩性、实时性、容错性，或者设计成适应受限制的（嵌入式）环境。
在特定平台上定义和建立这些服务时，它们必然带有将其束缚在该平台上的特征，或者保证它们在该平台上工作最佳的特征。为了避免这种情况，OMG 在 UML 的平台独立模型层上定义了普及服务（Pervasive Services）。只有在确定了服务的特征或者体系结构之后，才能够为 MDA 支持的所有中间件平台生成特定于平台的定义。
在平台独立业务组件模型的抽象层中，服务在非常高的层次上进行描述（类似于组件开发者在 CCM 或 EJB 中的视图）。当模型映射到特定平台时，开发人员将使用所选的开发工具来生成调用该平台上本地服务的代码（或者动态调用它）。普及服务仅对底层应用程序可见，即那些直接为服务编写的应用程序。
硬件和软件属性（如可伸缩性、实时性、容错性或者嵌入式特征）也要进行建模。通过定义这些属性的 UML 表示，或者定义把属性与企业计算结合起来的环境容错性情况，OMG 将对 MDA 进行扩展，以便支持和集成带有这些期望特征的应用程序。
图 3: MDA支持普及服务和专门计算环境
图 3 中强调了普及服务可用于任何环境中的任何应用程序。真正的集成需要一种目录服务、事件和信号，以及安全性的公共模型。通过澄清这些服务可以在不同环境中实现并且很容易集成，MDA 代表了我们的通用集成目标：成为一种全球性信息设施。
来自 OMG 的邀请
虽然 MDA 的大部分基础设施已经就绪或者正在构造之中，但还有很多的工作要做。如果您的公司从事建模或者基础设施层的工作，您可以就 MDA 的定义发表意见。UML 2.0已经发出了请求建议（Requests for Proposals，RFP），除了最早的一批外，所有业务对象计划（Business Objects Initiative，BOI）组件都还处于 OMG 采用过程的成型阶段。在各种中间件环境的映射中，只有到 CORBA 的映射正在进行之中，其他还只是可能的 RFP。普及服务的 UML 模型还没有构造或采纳。
DTF 定义的应用程序模型将作为实现从 CORBA 扩展到每种中间件环境的基础。无论您的公司是领域层应用程序的提供者还是用户，现在都是参与这类程序标准化的好时机。作为提供者，您可以充分发挥对未来标准的影响，被看作是重要参与者。作为用户，您可以把公司的需求整合到 RFP 中，这些 RFP 将定义新的标准，并影响您最终将使用的模型和标准。您将会非常高兴与行业中最优秀、最睿智的人共同开发您选择的体系结构。只有一个条件：为了确保 OMG 标准能够应用于市场，所提交建议被 OMG 成员采纳为标准的公司必须同意该规范的实现可在市场上销售或者进行商业应用。
利用 MDA，OMG 继续寻求异构系统间所有层次上的集成和互操作性。我们的第一个目标——通过引入分布式对象模型来支持集成——已经实现了。当今，对象已成为每个供应商的支持体系结构和所有电子商务的核心。但是我们的集成任务还没有完成；现在，我们必须从以中间件为中心的组织演变成以建模为中心的组织。
当然，这并不意味着我们要抛弃 CORBA。CORBA 是这种新体系结构的基础。作为唯一的独立于供应商和语言的中间件，它是 MDA 上层结构必不可少的重要组成部分，没有它就很难建立软件之间的桥梁。但是，为了赋于这种上层结构最大的灵活性，在更高一层上实现重用，我们必须考虑完全按照建模的概念表达这种体系结构。
这种新体系结构的另一组成部分更关注一致性测试、程序员认证和产品认证（评估）。这一方面我们将利用 Analysis and Design Task Force（分析和设计任务组）目前的成果，该组织曾经负责测试和评估与 UML、MOF、XMI 和 CWM 有关的项目，目前正致力于企业应用集成（Enterprise Application Integration，EAI）的 BOI 和 UML 表示。当然，最终我们在这些领域的成功将取决于与具有相关专业知识的外部组织的密切联系。
1 OMG 称这些模型为 UML profile（概要文件），其中很多概要文件已经逐渐成为标准。
2 从技术上讲它是类别的元模型。
参考资料
您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/rational/library/403.html]英文原文[/URL]。
[返回] 计算机科学论坛 →
计算机技术与应用 → 『 软件工程论坛 』 → 应对中间件互操作性的挑战：模型驱动体系结构
(订阅本版)
2004/12/15 0:25:00
新浪微博
应对中间件互操作性的挑战：模型驱动体系结构
