基于元数据的服务编排

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

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

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

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

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

∙理解元数据，我们能创建支持基础结构。

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

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

无处不在的模式

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

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

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

在这一点上需要提一下，模式不是并且永远不能被限制设计时间。以前，标准，例如统一标准的模型语言和提案（如模型驱动机构），指出许多模型和元数据在

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

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

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

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

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

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

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

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

技术

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

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

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

当选择工具协助设计和开发的时候, 最重要的标准经常被集中在: ∙工具储存和使用元数据的能力，包括他们和你们的设计。

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

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

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

∙遵从标准（MOF）

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

建议

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

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

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

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