jmi,mof,cwm

http://www.myfaq.com.cn/2005September/2005-09-04/191535.html

简介

随着当今Internet驱动的经济的发展，用户更加期待能够在应用程序中信息资源的自由访问和透明的数据交换。这种交换要求深入理解每种应用程序、工具和服务如何组织和解释它所使用的信息。元数据（metadata）这个术语同时描述了这些信息是如何组织的（即其语法）以及它们所代表什么含义（即其语义）。

不幸的是，大多数应用程序以不同的方式定义元数据。每个应用程序使用稍微不同的编程结构、语法和语义建立相应的元数据模型。这些不兼容性使得一个应用程序发现另一个应用程序所维护的数据并与之交互变得很困难。要克服这种障碍，公司通常的做法是使用大量的开发人员时间和金钱在应用程序之间建立硬连接（hard-wired）接口，以便它们能够通过复杂的方式共享数据。这种昂贵的、不断的精力付出是由于缺乏通用元数据的结果，或者更具体地说，就是缺乏一种创建元数据的通用模型（元模型metamodel）。这种情况阻碍了用于解决常见业务问题的健壮程序的开发，这些常见业务问题需要结合或使用多个异构应用程序的数据。这种业务问题通常包括：

企业应用集成
数据仓库
商业情报
B2B交易
信息门户
软件开发

元数据管理中的困难限制了开发人员在上述和其他领域中创建集成的、可互操作的应用程序的能力。许多行业试图通过标准化XML DTD或XML Schema来解决这个问题，但是这些方法也是不足够的，因为这些方法不能对复杂的、语义丰富的层次数据建模。随着电子经济中应用程序、服务、数据源、交换协议和部署平台的数目和复杂性的不断增加，这个问题变得越来越严峻。

为了促进元数据的互操作性，一些的销售商已经通过JPC（Java Community Process）组织起来，提供一种平台独立的元数据规范。这就是Java元数据接口（Java Metadata Interface，JMI）规范，这个规范就是JCP网站jcp.org上的JSR-40。 JMI规范定义了一种动态的、平台无关的基础结构，通过这种基础结构可以使用Java接口创建、存储、访问、发现和交换元数据。JMI基于对象管理组织（OMG）提供的元对象设施（MOF，管理元数据的一个工业标准）规范。

本文描述了什么是元数据，为什么元数据的管理如此重要，元数据管理的基础结构的需求是什么，以及JMI是如何来满足这些需求的。牋?/p>

什么是元数据？

元数据可以定义为关于数据的信息，或者就是关于数据的数据。实际上，元数据就是各种工具、数据库、应用程序和其他信息服务用来定义其对象、服务和其他计算工件（artifact）的结构和含义的东西。元数据的例子包括：

数据库schema，它们不仅仅描述了数据项是如何设计的，而且还描述了这些数据的含义。
Java类文件中对象属性和方法的含义。
企业JavaBean（EJB）的部署描述符，描述应用服务器所需的元数据，以便部署和使用EJB。

上述例子提到的是被称为“技术元数据”的东西。除此之外，还有一种业务元数据（也叫做过程元数据），这种元数据用于捕捉关于诸如业务规则、业务名称和业务术语等的语义。词汇表就是业务元数据的一个例子。还有些系统提供了标注元数据的手段，XML DTD就是一个在结构化文档中标注和交换语义信息的例子。统一建模语言（UML）定义了一种形式化地描述系统的功能、结构和行为的方法。稍后我们将介绍如何将UML用作元数据管理基础结构的一部分。

元数据为什么重要？

没有元数据，或没有语义，我们就没有办法知道数据对象所代表的意义。例如，程序中出现的一个整型值“39”可以代表几乎任何意思。就目前来看，由于这些语义中的许多、或许是绝大多数都倾向于嵌入到使用这些语义的系统中，因而元数据的管理变得极其困难。由于缺少一种通用的方法来表示和共享元数据，因而导致共享这些即使最简单的数据也会产生巨大的困难，更不用说复杂的应用程序、组件和系统的集成了。

人们对XML感到激动，部分是因为从某个层次上讲（使用封装在描述符标签内的数据），XML似乎可以解决这个问题。然而，作为表示和管理元数据的一种通用解决方法，XML具有相当大的局限性。当前各种行业都在标准化XML DTD的一个子集，以表示他们的特定工件的语义，这种各行其是的活动尽管实现了很有价值的第一步，但在实际上却把重点集中到了实现真正元数据交换的错误层次上。

哪里需要元数据管理？基本上任何地方都会发现大量的元数据工件，这样一来的结果是到处都需要元数据管理。应用程序开发工具和框架需要管理和理解：模型、记录定义以及数据库定义。基于组件的开发环境必须处理大量的接口、类和组件，而且它们还可能使用不同的编程语言。数据仓库和信息门户必须管理以不同格式组织为表、列、schema、多维数据集或者平面文件的数据。

最后，全面的元数据管理是启用我们一直努力实现的基于服务的体系结构的先决条件。除非你理解其对象的语义以及它提供的特性，否则就不能共享或使用某个服务。例如，诸如业务对象、业务过程、公司简介和贸易伙伴协议等ebXML（启动电子商务的标准）的高级工件，它们全都需要以一种独立于平台、独立于实现的方式被描述出来。我们指出ebXML是因为，使用ebXML的人正在使用我们接下来将要描述的元数据技术来刻画他们的工件。

http://www.myfaq.com.cn/A-A-B/Image/2005/09/04/image003(1).jpg

例子：数据仓库中元数据管理所面临的挑战

由于面临着各种各样的互操作挑战，上图说明了数据仓库应用程序因为缺少通用元数据标准而遇到的一些问题。典型的数据仓库应用程序处理许多不同的数据源。每个数据源理所当然地具有自己唯一的元数据（即其schema）。不仅仅是数据仓库应用程序必须集成这些不同的数据库，数据库自身也通常捕捉业务的不同方面（也就是说，不仅仅是schema的结构不同，同一schema也往往代表不同的内容）。进一步讲，这些数据库通常处于不同的系统中，这些系统可能不在一个公司。另外，举例来说，其他的数据源可以给出自己的文件，这些文件记录了网站点击流数据。应用程序自身也可以是数据源，例如ERP或CRM系统的输出。所有这些不同种类的数据都需要被提取、转换并装载到数据仓库中。这就是上图中间写着ETL的方框所代表的内容。这个处理过程十分复杂，目前市面上有超过250个的ETL销售商，这些销售商分别为各种数据源的输入端和各个数据仓库的输出端编写独立的接口。并且任何一个在适当位置使用数据仓库的公司不可能只使用一个ETL版本，而是需要许多个来处理其特有的数据源需求集。接下来在输出端还有一个问题，在输出端，我们希望利用已经提取到数据仓库中的数据，并且使用不同的报告工具分析这些数据。理所当然地，这些工具自身也期待它们的数据具有某种（不同且唯一的）格式。

管理元数据需要哪些条件？

我们已经看到管理元数据所带来的巨大好处。如果有标准的方法来表示和共享元数据的描述，那么应用程序级的集成就十分容易了。Java 2平台，即J2EE框架，基本上没有处理绝大多数应用程序级集成，该平台主要处理平台级集成问题。那么描述和管理元数据需要什么条件呢？

首先我们需要一种通用的、标准的方法来表示元数据。换句话说，我们需要一种方法来对元数据建模。一个定义明确的模型对于每一个模型实例的特性、属性的意义具有精确的定义。这些精确的定义能够帮助我们在模型特性和特定编程语言、交换格式之间定义精确的、没有歧义的映射关系。这个模型还需要在不同的抽象级别上描述元数据，以便该模型可以在元级别上变化。一个系统的数据是另一个系统的元数据，又是其他某一个系统的元－元数据。当你考虑它时，我们实际上需要一种元-元模型。换句话说，我们需要一个定义可以描述元数据的元模型的模型。也就是需要一种可以在任何抽象级别上定义元数据的语言。

这正是对象管理组织（OMG）的元对象设施（MOF）规范所提供的。MOF定义了一个很小的概念集（例如数据包、类、方法、属性、操作、引用、约束、联合以及数据类型），使用这个概念集合可以定义和操纵元数据的模型。这些概念是用统一建模语言（UML）标记的一个子集来描述的。由于MOF使用UML的标记，因此对于熟悉UML的人来说，使用这种方法定义和刻画元数据就十分容易了。MOF提供一种开放的建模能力，既提供了一组基本的元模型建模结构集合，可以直接用来描述技术和应用程序域，同时还提供了这些结构到CORBA IDL（CORBA接口定义语言）的映射，以便自动生成特定于模型的API。MOF还定义了一种反射编程能力，允许应用程序在运行时查询某个模型，以判断被建模的系统的结构和语义。MOF标准是OMG在1997年11月批准的。

然而，MOF只完成了一半的功能，因为我们还需要定义从这种公认的高级别且抽象的定义到实际的编程语言语义的映射。这就需要引入JMI。JMI定义了如何把MOF用来对元数据建模的结构映射到Java语言。当Java语言映射到MOF时，JMI为Java平台提供了一种用于元数据访问的通用Java编程模型。JMI提供了一种独立的并且易于使用的机制，在MOF相容的数据抽象（通称使用UML定义）和Java编程语言之间作映射。通过JMI，使用MOF相容的UML来指定其原模型的应用程序和工具可以自动生成模型的Java接口。进一步说，JMI可以使用XML元数据交换（XMI）规范实现元模型和元数据的通过XML（via XML）的交换，XMI是一种用于在应用程序之间交换元模型信息的基于XML的机制。Java应用程序可以创建、更新、删除和检索包含在JMI元数据服务中的信息。MOF的灵活性和可扩展性允许在更大的范围内使用JMI。

这样，我们可以使用类UML的语义清晰地定义元数据，并且JMI将会自动生成用以创建、管理、访问和查询元数据实例的Java API。另外，JMI使用XML元数据交换（XMI）标准定义从基于MOF的元模型到XML DTD的精确映射，以及从元数据实例到XML数据流的映射，从而实现基于XML的标准数据交换。

XML怎么样？

我们前面提到了单靠XML不足以对元数据建模。为什么会这样？ XML不是一种定义其它语言的语言，因而能够用来描述元数据？尽管XML的确很适合用于数据和元数据交换，但事实证明它并不能充分捕捉高级别的语义信息。诸如层次关系、联合、数据类型和其他必要的关键信息这些用来描述元数据的特性，在XML中只能通过扩展XML自身来表示。这类扩展可以在XML Schema中找到，但仍然没有提供一种通用的元数据建模环境。例如，虽然任何一个XML Schema都可以由特定的应用程序、组件或服务用来表示元数据，但是却无法在多个不同的域中提供一种通用的解决方法。我们需要的是一组高级别的概念集合，使用这种集合可以创建任何类型元数据的模型。MOF模型提供了这些结构。

现在我们可以看出，早先我们提到的XML DTD标准化的努力把解决问题的焦点放在了错误的抽象级别上。这些团体实质上是在标准化某种交换格式。尽管这很有用，但是如果他们可以标准化问题域中所使用的实际对象、标准化数据仓库与公共仓库元模型（CWM）产生联系的方法，那么他们的努力将更加有效。在这种情况下，行业领导已经就这些行业特定的高级定义达成一致，这些概念包括维度、大纲、列、关系表和OLAP多维数据。通过标准化元数据，数据仓库提供商显著地提高了系统的互操作性。

JMI – 使元数据管理基础结构成为可能

JMI规范的实现将提供一种元数据管理基础结构，这种基础结构将极大地促进应用程序、工具和服务之间的集成。以前，由于没有一个标准的方法来表示各自独有的特性，因此全异系统之间完全的互操作性和集成十分困难。JMI提供的这种元数据框架能够捕捉这些语义。EJB在隐藏计算平台的复杂性和允许开发人员在不用直接处理事务、安全、资源和一系列其他低级编程任务的前提下创建组件方面，已经被证明是十分高效的。相似的，JMI允许开发人员通过创建特定技术和业务领域的高级模型来隐藏复杂性。这样JMI通过提供下述方法降低了互操作和集成的复杂性：

一个通用的语义模型（用来创建模型）。
一个通用的编程语言模型（用于访问元数据的API，这些API是自动生成的，同时伴随一组丰富的生命周期管理接口）。
一个通用的交换格式（通过XML）。

有些公司参与了JMI规范的定义。这些公司包括：Adaptive、DSTC、Hyperion Solutions Corporation、IBM Corporation、Iona、Novosoft、Oracle Corporation、Perfekt-UML Rational、Software Corporation、SAS Institute、Sun Microsystems、Sybase和Unisys Corporation，Unisys Corporation是JCP规范的领袖。JMI规范已经公开发布了。Unisys、Sun、IBM、Adaptive和其他公司正致力于该规范的实现。另外，如Hyperion和Oracle将在其产品所提供的OLAP Java（JSR-69）和数据挖掘Java（JSR-73）中，把JMI接口和功能作为嵌入式元数据管理服务的一部分来实现。

对这种规范的遵循将由JMI技术兼容包（TCK）来保证，当该标准最终完成时，TCK将会可用，届时可用的还有这个规范的一个参考实现。

JMI的价值

让我们回顾一下JMI实现所提供的所有特性：

整个过程是模型驱动的；访问元数据的Java接口是根据元模型（元数据模型）提供的信息自动生成的。如果元模型发生了改变，接口将自动地被改变（生成）以反应元模型的改变。这种特性便于维护系统模型与其实现之间一致性。注意元模型和创建元模型的工具是独立于JMI服务的任何实现的。用来创建这些模型的工具通常也被用来设计和创建复杂的系统。JMI实现了这种直接在Java平台中建模的能力。
JMI提供反射。除了上面提到的与模型相关的接口之外，元模型产品的每个接口为每个产品实现了一个JMI反射接口。这些接口可以通过一种更普遍的方法，提供那些已经产生的接口所提供的所有功能。这些JMI映射接口由于提供了JMI功能，因而是对Java映射接口的补充，这种JMI功能允许应用程序在运行时查询模型，以确定被建模的系统的结构和语义。这样工具就能实现通用的浏览和发现机制。
JMI提供生命周期管理。例如，对“Foo”模型中的每个类产生了两个接口――Foo.java接口和FooClass.java接口。FooClass.java接口是Foo实例的一个类工厂对象，用于创建和管理Foo的实例。如果这个类被建模为一个抽象类，那么类工厂对象就不会产生。Foo的接口是由Foo类的所有实例实现的。这些生成的接口包含用来遍历该模型中的所有链接（联合的实例）所需的全部导航功能。JMI还有一个JMI参考（不要与Java参考混淆）。JMI参考提供访问函数来操纵和导航连接。注意由于有些系统没有知识库和持续性机制，但是仍然希望能够通过特定于JMI模型的反射接口访问元数据，因而生命周期管理是JMI系统的一个可选组件。
JMI提供XML输入和输出功能。JMI的XML映射详细说明了如何使用XML DTD表示模型，这些模型可以用来验证表示实例数据的XML文档。使用JMI的XML多用途API，可以输入或输出一个特定的JMI模型数据包中的所有或部分数据。

模型驱动开发

逐渐地，软件开发人员开始在开发系统时，寻求捕捉和利用最好实践的方法。他们是使用模式（pattern）来实现这点的，即对重复出现的问题使用软件解决方案的高级描述。著名的例子包括模型－视图－控制器模式，该模式分散了应用程序的表示、控制和数据管理方面；还有一个例子是数据访问对象，该对象封装了对后端数据源的松散耦合的访问。这些模式提供了更大范围内的重用，而不再局限于该模式最早被定义的特定领域。

正如在多个抽象级上被捕捉到的工件一样，模式最常使用UML标记来刻画。这些模式只不过是另一个形式的元模型。加上JMI为该模型提供了自动生成Java接口和XML DTD的便利，模式具有加速设计和开发完备的成功系统的潜力。OMG已经将其未来的体系结构和开发的基础建立在这种基于模型的方法上了，这种基于模型的方法被称为模型驱动的体系结构（MDA），在这种体系结构中，MOF和JMI是核心组件。

利用JMI的其他规范

目前有许多规范正在使用JMI的这种元数据管理功能，这些规范包括：

UML/EJB映射规范(JSR-26)，这种规范定义了UML的一组侧面，使得EJB与UML之间的精确映射成为可能。该规范还定义了一种使用这些在EJB-JAR中保存的UML模型的机制，EJB-JAR中保存的UML模型用来描述jar中的内容。这将使企业工具和框架提供商使用jar文件中保存的UML模型实现自动化和反射。JMI将提供用于访问那些模型的API。
OLAP规范的Java API(JSR-69)定义了一个用于数据仓库和联机分析处理（或OLAP）的标准Java API。它基于通用仓库元模型（CWM），并且还会依赖JMI产生数据仓库对象的接口。
数据挖掘API (JSR-73)定义了一个用于数据挖掘标准Java API。这个专家组正在建立实现数据挖掘引擎接口所必需的对象和产品的元模型描述，然后利用JMI生成API。

我们继续讨论其他JSR规范的先驱，以探索可利用这种技术的其他的领域。

小结

我们已经看到，为了实现应用程序、工具和服务之间的集成和互操作，元数据管理的标准是如何变得日益重要的。我们已经了解到必须有一种表示元数据的通用的方法，并且这种表示必须能够对多层次抽象建模，同时必须能够在使用通用的、精确定义的工件。有了这些精确定义的工件、到诸如Java等特定语言的明确映射，或者诸如XML等交换机制，就可以得到定义了。

JMI规范提供了这种标准。JMI允许Java应用程序使用标准元数据服务来指定、存储、访问和交换元数据。通过使用广泛应用的UML标记描述元数据，开发人员可以利用JMI框架的能力自动生成管理和交换其元数据所必需的API。

这个规范很可能增加基于标准的元数据的应用，并且因此加速健壮的应用程序和解决方法的产生，在这种应用程序中没有信息交换的障碍。重用模块和系统的能力也提升了，因为这些组件可以被很好的刻画。最后，可理解的元数据管理促进了基于服务的体系结构。描述对象和服务的标准对于创建可以彼此查询、协商和交互的服务是很关键的。

JMI规范的最终版本将在2002年六月发布，该版本还包括JMI的参考实现和兼容性测试包。JMI的一个较早的实现是元数据仓库（MDR），该实现与NetBeans的开放源码IDE一起配合工作。该版本可以在netbeans.org下载。更多的信息，包括所有规范的索引、白皮书、演示和其他附属产品，可以在JMI Web站点找到。