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

环顾这IT产业中不同的基础构造提案，以及多种技术，很明显的是许多软件的基础构造提供者看起来正在把模式的概念应用到应用程序一般执行的构架当中。

希望拥有基础结构产品和通向功能层基础的工具。而应运而来的是产生了非原创综合病症的克星。这种工具不仅仅是帮助你建模，而且可以通过体系化代码生成来帮助你加速编程。

这种IT产业中的运动已经聚集力量好多年了。一个简单的观点应该自然，浅显。  基础结构的模式的位置越高，我们可以重复利用的就越多，也就能使市场商业应用软件拥有更高的质量，更快的开发时间。

 理解元数据，我们能创建支持基础结构。  生产基础结构，我们能创建高生产力的工具来支持基础结构。  把工具交给技术团体，我们将比今天以更快地创造更有可重复性，更高质量的应用软件。

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

一个好的模式能提供复杂数据结构的易懂的描述，同样也可以在帮助我们描述复杂关系。

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

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

通过描述模式来获得功能上的好处，政策和服务抽象 在设计和创建过程中，或者元数据驱动设计和应用软件开发中，使用元数据将提供一条能完美的支持强大的模式本质的解决方案。因此支持高值软件构架和基础构架产品在市场中是可行的。

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

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

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

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

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

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

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

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

当选择工具协助设计和开发的时候, 最重要的标准经常被集中在:  工具储存和使用元数据的能力，包括他们和你们的设计。  工具共享元数据的能力。这种能力对于帮助减少设计和执行之间的语义差距，在设计时和编译时上很有用。  开发工具和优先的软件基础结构的整合，运行时间平台，尤其是代码生成。  设计和代码生成技术的开发工具的整合，例如脚本语言，可能会被整合元数据模型所使用。  遵从标准（MOF）

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

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

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

由于我正在重点研究核心服务期上的服务接口层，我将做一些关于每一个应用程序执行的假想。第一，应用程序是运行在相同的数据库和数据模型上的——程序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文檔。

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