元数据驱动的应用程序设计和开发

全面介绍使用元数据驱动处理应用程序设计。如果软件构架的使用能够用模式来定义，元数据就是用来描述那些模式的语言。

本页内容

牢记30岁？
你的模式有多牛
无处不在的模式
谁想减负阿？
通过描述模式来获得功能上的好处，政策和服务抽象
技术
链接SOA和使用元数据的网络服务
建议
元数据驱动SOA
从SOA到CORBA，从SOA到Web Services，从SOA到
设计直接实现 ——将元数据连接到工具
编译时
运行时
文档
适应性
有帮助么？
参考资料

在这篇文章中，我提供了一个使用元数据驱动的方法来设计应用的概述，这是一个注重实效的方法，而且在应用程序的开发中实际可行。本文使用一种开放的模式写成，所以并不是针对很深入技术的人群的。我希望本文能演示出为什么元数据驱动的设计是投身软件产品创造的IT专家最有力的工具之一。

牢记30岁？

回忆起30岁，那是一段简单经历。没有积极的参加过大型的“美好20岁”聚会，没有在深夜的时候去过夜总会，也没有喝酒喝到第二天早上还不舒服。但是失去了炫耀和庆典的经历也是很值得纪念的。取代宿醉的是一个很小的现实——明确地叙述模式对科技工作者来说是很重要的。

我在新加坡协助一个小组为一个银行运作外包选择和项目集成。我在我生日的前不久到达，先放下自己的想法，阅读一些资料，可能也能做一点事，并且在我回家之前肯定要推迟所有的庆祝活动。我的一个同事Lyn明显被我的态度吓住了，并且她有完全不同的看法。在那个隆重的一天举行的宴会上，我找准时机摸到了我们旅馆十七层的酒吧里。我们就在那坐着，欣赏着新加坡港美丽的景色，我喝着新加坡流行的斯林酒，Lyn喝着水果鸡尾酒 ，当时她已经有将近六个月的身孕了。我已经不止一次的幻想过我30岁的生日了。

这是我们第一次工作的如此之近，因此我们坐着讨论了职业的好运气，因为是它把我们带到这个项目上来的。Lyn从前为SWIFT工作过，并且拥有大量项目所需要的商业知识。对于我而言，我的上一份工作是从事一个大型自定义应用软件项目。但是这一次，我的角色是定义一个构架，并且把各种各样项目将要使用的产品定位并整合起来。

很明显，Lyn和我由于有着不同的职业背景而扮演者不同的角色，一个是商业角色，另一个是技术角色。快到最后的时候了，很奇怪的是我们不想以争论的方式结束，开始协调商业和技术的因素了，但是Lyn和我那天晚上就一件事达成了共识，这件事影响了我的专业工作，就从阅读模式文献开始。当同种情况发生在IT项目上时，它在模式上也发生作用，并且这些模式不仅仅只是为了技术。

返回页首

你的模式有多牛

事实上，模式的分析，设计和执行在当今的IT产业中已经到处存在，且已收到宣传作用。在模式领域内，如果把可用资金放开，毋庸置疑，多数IT产业中的关键人物相信，把模式应用到应用程序的创建当中将是一条颇有价值和力量的方法。许多模式的方面已经满足了方法论学者，分析师，设计者，实现者，测试者和经营者的共同目标。换句话说就是，模式拥有高质量，高可维持性，高可靠性和快速发现解决方案的特性。

在已经被有力地证明很难实现的应用程序设计和开发领域，有着强大作用的模式也占了一席之地。从以标准的，基于框架的执行为基础的解决方案分析领域到应用程序的创建，这都是可描述性（和因此而来的连贯性）的一个实质性的进步。

这是一个简单而又崇高的目标。为了使得软件更加快速的开发和更高的可靠性，IT产业需要学会更有效的再次利用软件的基础构造。为了达到这个目的，我们需要定义目标软件的基础构造使用的可承认的（或可支持的）模式。你可能会潜意识的认识到应该在软件生命周期中引入一个更完善的可描述性内容。因为可描述性内容提供一条正式的通道来转换分析时产品到编译时产品。这是有能力进行前向工程分析的关键。你需要明确将用生成的代码去工作的技术（基础）环境。

环顾这IT产业中不同的基础构造提案，以及多种技术，很明显的是许多软件的基础构造提供者看起来正在把模式的概念应用到应用程序一般执行的构架当中。在某种程度上，这在IT产业中已经上演好多年了。但是，这一次，基础结构的提供者在应用程序结构上看的很高。这一次，他们正在用应用程序结构帮助构架一臂之力。

看一看我们今天可以利用什么，传递途径中有什么是清晰的。应用程序结构应该时刻认真考虑到这些问题。这一次，我们拥有基础结构产品和通向功能层基础的工具。而应运而来的是产生了非原创综合病症的克星。这种工具不仅仅是帮助你建模，而且可以通过体系化代码生成来帮助你加速编程。

想要这种工具吗？那么你就需要用模式来工作，不管是基础结构还是应用层。

这种IT产业中的运动已经聚集力量好多年了。一个简单的观点应该自然，浅显。

• 基础结构的模式的位置越高，我们可以重复利用的就越多，也就能使市场商业应用软件拥有更高的品质，更快的开发时间。

越不简单，则用技术的视角去观察就会发现越冗长的内容。

• 理解模式，我们能创建支持基础结构。

• 生产基础结构，我们能创建高生产力的工具来支持基础结构。

• 把工具交给技术团体，我们将比今天以更快地创造更有可重复性，更高品质的应用软件。

返回页首

无处不在的模式

如果我们在信息科技方面的工作像产业一样和模式紧密相连的话，利用模式工作对于我们大多数来说将成为可能。我们很可能没有意识到模式在我们每天的生活中扮演的角色。但是这是每个普遍升入的对象问题的天性。如果有一样东西到处都是，在经过一个短暂的蜜月期，我们中的大多数人将对他视而不见。特别是跟它跟我们的任务相关并且频繁执行。

如果它们到处都是，那这对利用模式工作有什么意义吗？我肯定的说，每个人的理解都不一样，但是这篇文章的主旨有两个具体的含义。在设计过程中，利用模式意味着把设计建立在一般事件结构的基础上（设计模式，例如每一个定义已经在“四人帮”丛书——“软件设计模式”中被成功的证明。）。更适宜地使用设计工具能将设计存储为模型表示形式，例如UML。在创建过程中，在真实代码段删节的地方，使用模式意味着使用软件的基础构造产品和工具，包括代码框架和代码生成器（就像Codesmith）

幸运的是，构造的本质和设计提供识别和划分模式的机会。这个被其他作者完成的有价值的工作意味着我不需要在讨论设计中的模式建议的价值了。但是，同样的陈述对于软件生命周期的执行阶段并不是全权委托的，而在执行阶段当中，模式或者是更多特定的构架不幸地染上了恶名。

构架遭受了“非特殊”的痛苦。应用或者滥用经常有几种不同的途径。为了给可供选择的使用和使用类型提供合理的数字，为了为创建应用程序提供一般的基础服务，构架获得了一个不公平的评价，因为它太复杂。因此很难理解，就像IT职业人员陷入了多种多样的使用方法的泥潭。搞好构架的级别，达到规定性和适应性的平衡已经被证明是一个艰巨的挑战。如果搞坏框架的级别，你就会经常遇到问题。你需要模式来执行基于软件的系统吗？

这个问题的根本原因很可能是许多应用软件工作组为了更快的生产更高质量的解决方案，而因此也背上了沉重的包袱。很自然的这使得工作组远离了那些潜在的更复杂的方法，也因此可能延长应用程序创建的进程。当工作在这种压力是，没有人会去寻找一个很可能为他们带来更多压力的方法。

返回页首

谁想减负阿？

考虑到压力将带来思想上的问题，那能不能找到一种模式来帮助减轻压力阿？我有一个绝对美妙的想法。回到家，离开喧嚣的人群，隐匿于学习中，查看着当天的电邮，并且试着更新点工作，玩我一直藏在电脑中的智力拼图，所有这些都是良好的感受。瞧，这就是一种很好的模式。

在很多地方都有模式，从每天的日常例会如何举行，到每日的结束。模式的本质是有天生的，它帮助我们解决困难。一个好的模式能提供复杂数据结构的易懂的描述，同样也可以在帮助我们描述复杂关系。这能使生活更加舒适，并能缓解那些经常要从事复杂工作的人的工作压力。无可否认的，这还能给我们带来很多有用的效果，我们在这篇文章里稍后再研究。

如果软件的构架和基础结构的使用能被定义为模式，那么元数据将是描述这些模式的语言。因此，描述模式将是元数据的责任。元数据不是一个长期的语言，元数据有很多方言，并且甚至会混杂起来。元数据是描述模式的数据模型的表示的共同项。因此，对于任何一组给定的元数据，它所提供的高质量的描述将由联合的元数据模型决定。

在这一点上需要提一下，模式不是并且永远不能被限制设计时间。以前，标准，例如统一标准的模型语言和提案（如模型驱动机构），指出许多模型和元数据在工程生命周期中逆流而上。如IBM，像很多大型科技机构一样，在90年代一直致力于使基于UML的总系统的模型形式化。许多这样的提案永远不能成为官方外部的宣传物。但是2003年10月，微软打破了这个僵局，并且发表了他们未解决的系统定义模型（SDM）。利用这些概括了整个系统的模型（如SDM），你将能看到模型驱动，因此元数据驱动处理几乎涉及软件开发生命周期的所有领域。

返回页首

通过描述模式来获得功能上的好处，政策和服务抽象

在设计和创建过程中，或者元数据驱动设计和应用软件开发中，使用元数据将提供一条能完美的支持强大的模式本质的解决方案。因此支持高值软件构架和基础构架产品在市场中是可行的。

元数据帮助描述你的应用程序领域中的模式。描述（或者模拟）应用程序必须使用的模式将辅助促进软件基础结构的必须提供的特征，以及基础结构最大使用的风格。这就提供了必需和被允许的基础构造的早期可见性，这一基础构造是非常重要的，更安全的，更为可控的环境，在这个环境中，软件的基础结构能在应用程序构造法的层次上走的更远。控制基础结构网更高级别上发展是为应用程序开发者提供更有价值的服务，这给你的应用程序开发者带来了在功能抽象方面的能力进步。

用模式模拟应用程序的需求（藉由元数据来描述）可能会被应用到几乎所有领域。因此，元数据能被用来描述对象特征到相关表格的映射，从定义相关对象运行时会话管理角色，到特定类对象提供的服务的签名，这种规则构成了应用程序开发者控制基础结构潜在行为的政策定义。

当认真地，并且正确的模拟你的应用程序时，元数据可以应用于基础结构和应用程序服务分界的描述，以及整合的服务执行的配置数据。随后，和这些服务（还有元数据模型）结合起来的元数据描述可能在你的服务的前提工作中使用，在现存的或者未来的技术环境。这就为服务定义提供了一个充足的，并且可重复使用的方法。

这样使用元数据，在商业（应用程序）和技术（基础结构）领域，需要在商业分析和软件基础结构之间就元数据模型达成一致。这就达成了应用程序和基础结构之间的行为协议，并且允许了详细的功能分析和并行结构的软件基础机构。在这种情况下，应用软件开发小组可能现在在开发过程中的早期阶段抓住主要问题。而这个阶段是提高软件发展周期效率的关键因素。

元数据驱动方法和其他主流方法配合的也很好，例如使用条件模型和基于人工的方法论（如合理的统一化过程）。元数据驱动方法有潜力重复利用，并且相对于目标技术平台是独立的。

返回页首

技术

在深入讨论元数据怎么链接面向服务构架和网络服务之前，我们值得花点时间来讨论元数据背后的技术问题

思考着怎么更好的描述这个问题，我得到一个结论，那就是在一篇技术相关的文章里，不容易叙述。所以，我们就先把它放在那，非常简单，元数据中没有技术。

元数据本身是一个概念。这就是许多不同元数据模型存在的原因。元数据概念能在很多技术领域内应用，因此，很多软件产品，在商业和技术层次JNDI上有元模型，LDAP和主动目录也是如此。它们都在元模型中使用了相似的概念，但是都有不同的（物理）元数据。

清楚的是，那些设计和开发产品使用元数据的同时也使用（使嵌入）或者链接（整合）到工具。这些工具通常是图形化的，并且越来越多的被链接到提高开发产品率当中。联系到元数据本身，它有主要的重要性。这种使用和工具的整合对于软件周期里储存的支持，传播和元数据模型的使用可能是设计和创建环境技术中最重要的方面。

当选择工具协助设计和开发的时候, 最重要的标准经常被集中在:

• 工具储存和使用元数据的能力，包括他们和你们的设计。

• 工具共享元数据的能力。这种能力对于帮助减少设计和执行之间的语义差距，在设计时和编译时上很有用。

• 开发工具和优先的软件基础结构的整合，运行时间平台，尤其是代码生成。

• 设计和代码生成技术的开发工具的整合，例如脚本语言，可能会被整合元数据模型所使用。

• 遵从标准（MOF）

返回页首

链接SOA和使用元数据的网络服务

取代写一篇数千字的关于如何在设计和开发中使用元数据的论文是如此之妙。我将尝试另一种选择，一种更技术友好的方法。让我们假设，我们都承认元数据驱动设计和开发很完美。模式是很美妙的，模式决定了我们在IT中所作的大部分。元数据是描述你的模式的好方法，最终元数据在设计和创建中都能使用。

由于我们都承认，元数据驱动设计和开发非常完美，我们就不需要浪费时间去讨论它的优点了。取代论文，代之以观察我们可以用这种基于SOA和网络服务链接的方法执行什么。

首先，在继续之前，我要给读者敲一下警钟，例子仅仅就是例子。聚焦在系统元数据应用的反面，不是意味着，一些相同的概念不可以在其他领域应用。许多系统的领域已经使用了接受了的元数据模型，尤其是在鉴定和批准方面是用像Active directory/LDAP这样的产品并且肯定服务管理。

返回页首

建议

经过两个建立在相似原则但不同的执行结果的应用软件例子，我将研究，基于元数据的方法如何能在现有的和新创建的的应用软件上定义服务接口。这个练习的基本目标是将这些接口向附加的使用基础结构整合的技术环境，创建应用程序的基础结构，和在设计阶段建立的元数据模型。

应用程序举例——共有基础

在这个经过中，两个应用程序例子表现出了相似的功能角色，并且对外部世界有相似的正面作用。

由于我正在重点研究核心服务期上的服务接口层，我将做一些关于每一个应用程序执行的假想。第一，应用程序是运行在相同的数据库和数据模型上的——程序2是程序1的备份；第二，我不关心接口状态或者任何中等等级用户的接口部件；第三，我关心任何调度的细节方面或者任何通信机构的配置；第四，服务请求和服务端部分共享的应用部分时和服务器模型相同的，这些部分处理了程序或者运行时间平台的内嵌问题；第五，应用程序的开发是多个小组在数个时间域内进行的。

实际的（商业）功能性可能在应用程序之间是相似的，程序之间不一样的是表示他们系统边界服务结构的模型。

程序举例 1 ——原始的，遗传下来的

服务段原始程序的接口是由C头文件组成的。接口上的每个函数使用量身定制的信号。外部机构通过基于DCE的远程调用程序来调用接口函数。

增加一个函数相对比较简单，但是和DCE技术连接紧密。增加一个可供选择的访问，来提供函数的non-DCE（不使用DCE）的频道，是不可能离开流程再设计过程的。

注意到所有服务的数据字典在程序接口上都是公开的。函数名字直接放在程序整体名空间里（它们在小组正在开发的所用函数种必须是独一无二的）。

图一：应用程序 1

应用程序举例 1 ——发展

原始程序1稍后通过一组C++类被打包，使得CORBA总线的服务器端接口暴露在外。C++接口不起直接的打包作用，但是，把C函数封装到一组服务中，并且提供统一“一般”的对象作为上下文的请求。

每一种服务定义一些源于上下文请求类的类，目的是为服务器端基本的C函数需求的参数，创造一组专门的“容器”。

因此函数被封装到服务中，所有函数的参数定义被一组“容器”类定义封装起来。

为了更方便的处理这些“更一般的”请求，引入一个新的服务器端（应用程序）组件类型，来核实上下文请求，使得提供的正确参数生效，并把这些参数映射到正确的基本C函数里。请求映射器，是接口定义语言（IDL）中定义的服务执行。一般情况下，并行开发需要在每个IDL服务中有一个请求映射器。但是这个模型也不是系统强迫的。

为一个现有的服务增加新的函数，需要引出一个新的容器类，需要为映射器增加新的代码来排列容器数据，并且生成基本的C访问。为一个新服务请求增加一个新函数，首先，服务接口应该在IDL中定义，还要穿件一个基于服务接口的映射器。

注意到所有服务的数据字典直接暴露在程序接口上，但是都被服务和请求上下文定义仔细研究。如图2

图 2 ，程序 1 发展

应用程序例 2 ——山丘之王？

程序1和2的关键区别是程序2是用基于元数据的方法来创建的。程序2没有被限制重复使用现有的C函数。

程序2中的每一个程序端函数都是建立在一个共同的，用来表示服务请求的元数据模型基础上的。这和发展的程序1在概念上是相似的。但是一般上下文请求的处理被嵌入到服务期代码中了。服务器端函数必须明白一般的上下文请求格式。见图3。

图 3 ，程序 2

表示上下文请求时，不需要具体参数。抛开具体的函数信号，在运行时间内，程序2处理上下文请求时，使用了一般的结构。但是，在这个例子中，上下文请求对命名值对的属性包在本质上应该是相似的。道具包能分等级，因此能被用来表示任意数据结构，尤其是基于XML计划基础上的XML文档。

服务名和请求上下文，是服务器端执行请求的应用程序组件所要求的。和请求上下文许可的数据结构的定义相连接的服务名，在数据库中仍然是“服务定义”。这种定义，是数据库的有效条目，只属于那个唯一的服务。

系统包括一个新的一般请求处理程序模块。这个模块被设计为，访问元数据库，并实现，新到的，联合服务描述元数据的请求。它同样能创建上下文请求的内存结构来传递到目标服务的执行。

为程序增加一个新服务在服务器端是很简单的。执行一般接口和完成请求上下文结构，需要服务请求，分配给服务一个名称，注册这个名字，并且需要数据库中的上下文请求描述，以及完成在服务器上配置新服务代码需要的配置行为。

但在客户端就不一样了。除去确定的客户端头文件，或者程序1中的IDL接口定义，程序2的客户端只通过相同的专业界面连接技术来接收一般的入口点函数。这是一个巨大的改变，在这种情况下，服务数据字典不再直接在服务接口上传播。这些从外部观测到的服务接口，在数据库中都是软件指定的。同样注意到，一个服务定义的范围是和服务执行一一对应的。

很明显的，程序2遭受了不均衡。服务器端现在很宽松，并且定义的很好；但是用户端在理解服务能提供什么之前，必须先理解元数据。

进入服务字典的世界。为了使用这些服务，程序2的服务必须是可见的。这通过可靠的文件模式是可以实现的。程序服务的使用者（用户）能阅读接口说明，并且因此建立组织好了的，有效地请求。

返回页首

元数据驱动SOA

明显的，例子程序#2时在系统边界上是十分面向服务的——它不知道其它任何事情——但是说程序#1不支持某些方面上的面向服务的架构也是不公平的。

程序#1就像是“C”语言或COBOL编写的一些所谓的传统程序。代码可能被更改许多次，但是就当时的技术来说，这些程序本质上是面向服务的。“C”程序有他们的外部函数签名；COBOL程序有他们的拷贝手册。包括一些如IMS或CICS的基础结构，以肯定会有一个面向服务的系统对应这些TP监控器迫使这些模型输入数据块运行请求，然后输出数据块并且利用数据结构来描述这些数据块，这就是一个服务，对吧？

程序#1和程序#2之间的本质区别是什么？答案（对我而言）是两个都在系统边界面向服务，但是真正的面向服务的程序的不规则碎片模型必须从系统边界到数据库都适用，服务接口对每个模块或子系统都定义好，每个服务对调用者来说都是一个黑盒子。

无论如何，例子中对系统边界保持注意的行为告诉我们他们之间服务描述的质量是大不相同的。

• 原始的程序#1无非就是一个开放的库或可执行的终端，通过DCE技术在系统边界开放入口函数签名。

• 扩展过的程序#1还是一样，但是引入了简单的抽象，有更好的终端描述机制。入口函数被开发成简单的经由CORBA的面向对象的抽象，通过编码配置在抽象和具体的执行间建立联系。

• 程序#2仅有一个技术终端可以开放。在任和一个技术环境中以相同的方式开放这个终端（通过DCE，CORBA，COM，异步通讯，等等）将会产生同样的结果——数据字典永远不会被公开，仅仅是一般的服务调用签名被公开。这个方法的价值在于使用元数据驱动服务定义和调用那些服务的相关的应用程序基础结构，作为利用各种技术生成被服务广泛使用的多种代理的运行时实现环境。

如果使用纯技术编码的方法提供对那些服务的访问，程序#2的服务中元数据驱动的特性将导致该方案走投无路。在这样的元数据驱动的程序中开放功能函数被开放元数据代替。

听起来有些危险，开放元数据的想法？开发元数据本身并不是元数据驱动应用程序的本意。使用元数据来驱动服务在系统边界的传播是一个更为正确的方法。

返回页首

从SOA到CORBA，从SOA到Web Services，从SOA到

为了演示真正的基于元数据的服务设计师如何在竞赛中获胜的，让我们为一些实际的程序例子做一些修改。

• 我们有基础的服务器端的运行时配置，运行总共三个程序，保持一定状态。

• 我们打算基于网络服务（Web services）在一项时髦的综合功能中加入一个干净的移植通道。

• 我们还想在不少通过CORBA综合起来的外部程序和许多程序#1的特定服务之间建立一个移植通道。

• 有人需要文档，我们就提供给他们。

• 外部的程序使用程序#2提供的相关服务来移植，需要程序#2和程序#1支持相同类型的CORBA接口

使用基础结构和代码生成可以更有效率的提供对CORBA和Web services支持（以访问程序#2的服务）。程序#1做不到这一点。如果同样的方法应用到程序#1上，最可能的结果就是要忍受因缺少描述服务的中枢模型而持续增加的复杂性。注意，中枢模型是十分重要的，UDDI中的TModel的概念就是中枢模型（与MSDE或SQLServer使用的物理数据模型相反）。

使用元数据服务的定义和合适的工具与基础结构环境相联系，元数据驱动的应用程序有能力提供这种搭桥方法来通过代码生成将其服务扩展至许多技术。这是将所有服务都规范起来和用元——格式（一个描述性的格式——即元数据）来描述的一个直接结果，不论在编译时还是运行时。

返回页首

设计直接实现 ——将元数据连接到工具

这个方法需要很多先决的条件，所以这一方法对很多人来说是比较困难的内容。但是如果想简单概括的了解一下，我们需要准备以下的内容：

• 提供图形界面的建模工具可以帮助我们存储元数据模型和相关的元数据实例（不一定都在同一个物理存贮中）。根据你的应用程序域，通常是类似UML方式的工具，一个过程建模工具或两者合一的。该工具必须提供一个跟他的模型存贮部分可编程的接口。

• 对目标基础结构产品来说，最好是基于标准的，或一个实际的第三方标准，如果需要也可以是自定义的。这些产品应该提供应用程序需要的技术服务，从存贮保持到过程管理（可能的话对该应用程序的所有层面都进行过程管理）。

• 支持建模工具和目标基础结构产品间的接口的开发环境工具，并且该接口可编程。

• 支持代码生成的开发环境工具。如同Lex和Yacc的工具，不是我们考虑的工具类型。支持代码生成需要比一般的表达方式和上下文无关的语法更高层的语法。理想上的，代码生成工具需要收录一些处理元数据的原则，这对降低代码生成的复杂性大有帮助。

• 一个或两个强的技术领导者，熟悉元数据的概念和使用，由他来驱动该应用程序的开发周期。

• 一些熟悉元数据建模概念和应用程序基础结构设计的设计师。

• 一些熟悉如何使用元数据概念的开发人员，他们要和设计师达成一致。

这些建模工具，基础结构产品和开发环境在如今的市场上都存在。最终的“面向人”是最难满足的先决条件，多数的软件开发组都是一堆人和各种方法的混合，非常容易打破软件的开发周期。

Belbin教授的测试可以帮助平衡“人员类型”的混合，但是一个一元化的组织并不可以。这在元数据驱动的方法中十分重要，所有的组员都要对模型达成一致，这个应用程序才能达到它的目标。

综上所述，我们达到了一个解决方案分析可行（有时背需求分析限制）的过程，可以专注于应用程序和其基础结构的设计。应用程序的设计涵盖了组件模型的设计和元数据的定义。应用程序的基础构造通过一系列框架API和标准基础构造的重用或预定制的基础构造对应用程序进行支持。最终，应用程序的加工就是询问这些模型和为应用程序设计的元数据，在应用程序基础构造的上层生成代码。见图4。

图 4 一个元数据驱动的过程

返回页首

编译时

仔细看一看编译时，并再次注意服务接口，应用程序工具用元数据服务定义来提供服务接口执行的代码生成 (服务代理,在不同的技术环境中)。

应用程序的元数据被直接用作代码生成。元数据对应用程序的服务的构建十分重要，它构筑了应用程序的基础。生成的代码必须和核心程序基于同一个代码基础（框架）。这帮助你把生成的代码控制到最小容量——代码生成在基础层的顶端。这对减少完全回归测试很有帮助。

生成的代码的任务是将请求从一个格式（比如来自a CORBA peer的请求，或一个POST网络服务）到一般内部的面向元数据的请求格式。元数据必须包含该服务接口的信息，比如变量类型，名称等，但是可以被扩展以包含默认值和确认。如果在这个脉络下扩展，生成的代理将可以使用跟核心服务相同的确认规则（假设核心服务使用相同的元数据——在本情况下，应该是这样！）。

一般的基础结构基本上被扩展以支持相关特别的科技（经由系统代码生成）。生成代码需要在底层应用程序基础上定义一个包装器，以配置从一方发往另一方的请求。这是有元数据模型促成的，这个模型定义了服务接口的全局数据表示法。这样做的结果是一个技术环境的底层结构可以独立于代码生成进行测试，这是增加代码生成质量的关键因素。元数据也允许不同的代码生成策略，比如“包含为确认请求而生成的代码”或“不生成确认的代码”。

图 5 系统的代码生成

需要保证所有目标环境（由代码生成器连接）的苛刻的请求都在服务元数据模型中详细描述，这是一个代码生成的不利方面。如果不这样，元数据模型就需要修订或扩展以支持目标环境中的不同于本模型的一些概念，也就是说，这样的模型是不完整的。

来自服务代理的另一个不利方面是版本控制。版本和配置的管理经常是非常痛苦的，需要专门的处理。无论如何，面向代理的版本控制和面向传统开发方法的版本控制并无太大区别。如果一个服务的定义改变，相关的代理需要重新生成，代理相关的综合需要影响评估（本方法的可描述性使得一切都很简单）。其它情况都没什么不同，但是我们要保证核心服务、基础构造和生成的代理都在部署方案中匹配。

对创造者来说，元数据模型如何被完全利用，没有一个真正的答案。查看标准或许有帮助，但是组织严密、文档翔实的模型更加强壮。幸运的，对后者，从元数据模型中衍生意味着包装和包改变时的影响分析或在相同的基于工具的政策下来进行包装。对代码生成来说，这个构造的确切配置是众所周知的，可以用来组织一个部署仓库。

返回页首

运行时

回到使用元数据驱动的方法设计开发应用程序的最初目的，最好是在运行时来分析回顾一下。

假设构建过程采用了一个针对元数据服务定义裁减过的通用软件基础架构，同时元数据在创建（编写代码——那没什么神奇的）该程序的核心服务时和生成服务代理时都使用到了，整个解决方案的一致性就像是元数据模型那样完整。

来自任何支持的外部源的请求都被各自的服务代理做一下配置，在这个配置过程中，依靠使用的代码生成策略，服务代理可能根据元数据提供的一些规则对请求做些确认工作。这可能包括证明，授权和过程管理，从元数据转交给相关代理子系统。

一旦配置成通用的服务请求格式，请求就被送至请求管理器处执行。执行中，请求管理器对请求进行询问，根据目标（核心）服务的元数据对请求进行匹配。如果全部顺利，目标服务接受请求，并且该服务可能在处理请求时使用额外的元数据。见图6。

图 6 处理请求

最终结果是一个解决方案的设计方法，从开始设计到执行。元数据驱动的应用程序比起其他传统程序为什么能有更长的寿命，这又是如何做到的？最终我们提供了一个实际的解释。

返回页首

文档

如果本方法允许从服务定义中生成代码，不生成服务接口规格的文档是没有道理的。这是许多年的实践，使用象Rational Rose（to Microsoft Office Word）的工具进行自顶向下的文档生成，或是使用一些面向代码的工具（比如AutoDuck或JavaDoc）来自底向上的生成。

返回页首

适应性

在这一方法中值得进行一些观察，对组织有关应用的方面做一个基本的概要。在开发中，对元数据驱动的概念来说，刻画出组织的类型，本方法可能同如下相关：

• 需要在设计和执行中实现更紧密联系的设计者和开发者；

• 确实看中基础构造驱动，高生产力，高质量的开发方法的组织，

• 那些不因为一些简单生产力增强工具就满足的组织，

• 希望建立知识仓库和相关工具以更好的通过一种正式的描述性语言来描述他们的产品的组织。

• 需要支持更广的技术环境的组织，尤其是在系统边界。

返回页首

有帮助么？

这个方法在许多项目的不同方面都有应用，这些工程有些是我讨论过的，或是参与过的。许多这些项目都想从运行时的模型达到完全的前向模型这样一个高目标，其中一些确实在处理某些特殊领域时做到了。

在Temenos，我们在制作新的具有24*7能力的一个银行系统（“T24”，在2003年底投入使用）时使用过上述和一些相关的技术。更确切的，我们在制作软件开发工具箱（现有功能上可编程的API）和网络服务部署工具时使用这些技术。这不是很简单，可能时常让你头疼。但是看看T24解决方案的模型，就会清楚地知道：当新的科技浪潮来到时，使用元数据驱动的方法设计开发应用程序会帮你组织好已有的服务，并让其发挥更大的作用。

仔细分析许多IDE和工具的制作商的动机。元数据表示和代码生成被再一次追求。但是这次目标是通过提供针对如今科技环境的复杂性和抽象性的管理工具，使得开发过程更有效率。

返回页首

参考资料

面向模式的阮家架构：写作与网络对象的模式

Douglas C Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann, John Wiley & Sons

反模式

William J Brown, Raphael C Malveau, Hays W McCormick III, Thomas J Mowbray John Wiley & Sons

应用 Microsoft .NET Framework 编程

Jeffrey Richter, Microsoft Press

.NET 应用架构 , Microsoft Patterns & Practices 小组

Microsoft Press

基于组件的流程揭秘 CBDi Newswire Commentary www.CBDiForum.com

设计模式 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley

Dinosaurs Battle in the Tar Pits CBDi Newswire Commentary www.CBDiForum.com

分布式应用的建模语言 白皮书, Microsoft Corporation

现代 C++ 设计 Andrei Alexandrescu, Addison-Wesley

使用 UML 的对象，组件和框架 Desmond Francis D'Souza & Alan Cameron Wills, Addison-Wesley

SOA—精简费用的战略 CBDi Newswire Commentary www.CBDiForum.com

面向服务流程的本质 CBDi Newswire Commentary www.CBDiForum.com

计算机编程的结构与解释 Harold Abelson, Gerald Jay Sussman, Julie Sussman, The MIT Press