基于元数据的服务编排.docx
《基于元数据的服务编排.docx》由会员分享，可在线阅读，更多相关《基于元数据的服务编排.docx（11页珍藏版）》请在冰点文库上搜索。
基于元数据的服务编排
为了使得软件更加快速的开发和更高的可靠性，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文檔。
服务名和请求上下文，是服务器端执行请求的应用程序组件所要求的。
和请求上下文许可的数据结构的定义相连接的服务名，在数据库中仍然是“服务定义”。
这种定义，是数据库的有效条目，只属于那个唯一的服务。
系统包括一个新的一般请求处理程序模块。
这个模块被设计为，访问元数据库，并实现，新到的，联合服务描述元数据的请求。
它同样能创建上下文请求的内存结构来传递到目标服务的执行。
为程序增加一个新服务在服务器端是很简单的。
执行一般接口和完成请求上下文结构，需要服务请求，分配给服务一个名称，注册这个名字，并且需要数据库中的上下文请求描述，以及完成在服务器上配置新服务代码需要的配置行为。
但在客户端就不一样了。
除去确定的客户端头文件，或者程序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到WebServices，从SOA到
为了演示真正的基于元数据的服务设计师如何在竞赛中获胜的，让我们为一些实际的程序例子做一些修改。
∙我们有基础的服务器端的运行时配置，运行总共三个程序，保持一定状态。
∙我们打算基于网络服务（Webservices）在一项时髦的综合功能中加入一个干净的移植通道。
∙我们还想在不少通过CORBA综合起来的外部程序和许多程序#1的特定服务之间建立一个移植通道。
∙有人需要文档，我们就提供给他们。
∙外部的程序使用程序#2提供的相关服务来移植，需要程序#2和程序#1支持相同类型的CORBA接口
使用基础结构和代码生成可以更有效率的提供对CORBA和Webservices支持（以访问程序#2的服务）。
程序#1做不到这一点。
如果同样的方法应用到程序#1上，最可能的结果就是要忍受因缺少描述服务的中枢模型而持续增加的复杂性。
注意，中枢模型是十分重要的，UDDI中的TModel的概念就是中枢模型（与MSDE或SQLServer使用的物理数据模型相反）。
使用元数据服务的定义和合适的工具与基础结构环境相联系，元数据驱动的应用程序有能力提供这种搭桥方法来通过代码生成将其服务扩展至许多技术。
这是将所有服务都规范起来和用元——格式（一个描述性的格式——即元数据）来描述的一个直接结果，不论在编译时还是运行时。
设计直接实现——将元数据连接到工具
这个方法需要很多先决的条件，所以这一方法对很多人来说是比较困难的内容。
但是如果想简单概括的了解一下，我们需要准备以下的内容：
∙提供图形界面的建模工具可以帮助我们存储元数据模型和相关的元数据实例（不一定都在同一个物理存贮中）。
根据你的应用程序域，通常是类似UML方式的工具，一个过程建模工具或两者合一的。
该工具必须提供一个跟他的模型存贮部分可编程的接口。
∙对目标基础结构产品来说，最好是基于标准的，或一个实际的第三方标准，如果需要也可以是自定义的。
这些产品应该提供应用程序需要的技术服务，从存贮保持到过程管理（可能的话对该应用程序的所有层面都进行过程管理）。
∙支持建模工具和目标基础结构产品间的接口的开发环境工具，并且该接口可编程。
∙支持代码生成的开发环境工具。
如同Lex和Yacc的工具，不是我们考虑的工具类型。
支持代码生成需要比一般的表达方式和上下文无关的语法更高层的语法。
理想上的，代码生成工具需要收录一些处理元数据的原则，这对降低代码生成的复杂性大有帮助。
∙一个或两个强的技术领导者，熟悉元数据的概念和使用，由他来驱动该应用程序的开发周期。
∙一些熟悉元数据建模概念和应用程序基础结构设计的设计师。
∙一些熟悉如何使用元数据概念的开发人员，他们要和设计师达成一致。
这些建模工具，基础结构产品和开发环境在如今的市场上都存在。
最终的“面向人”是最难满足的先决条件，多数的软件开发组都是一堆人和各种方法的混合，非常容易打破软件的开发周期。
Belbin教授的测试可以帮助平衡“人员类型”的混合，但是一个一元化的组织并不可以。
这在元数据驱动的方法中十分重要，所有的组员都要对模型达成一致，这个应用程序才能达到它的目标。
综上所述，我们达到了一个解决方案分析可行（有时背需求分析限制）的过程，可以专注于应用程序和其基础结构的设计。
应用程序的设计涵盖了组件模型的设计和元数据的定义。
应用程序的基础构造通过一系列框架API和标准基础构造的重用或预定制的基础构造对应用程序进行支持。
最终，应用程序的加工就是询问这些模型和为应用程序设计的元数据，在应用程序基础构造的上层生成代码。
见图4。
图4一个元数据驱动的过程
返回页首
编译时
仔细看一看编译时，并再次注意服务接口，应用程序工具用元数据服务定义来提供服务接口执行的代码生成（服务代理,在不同的技术环境中）。
应用程序的元数据被直接用作代码生成。
元数据对应用程序的服务的构建十分重要，它构筑了应用程序的基础。
生成的代码必须和核心程序基于同一个代码基础（框架）。
这帮助你把生成的代码控制到最小容量——代码生成在基础层的顶端。
这对减少完全回归测试很有帮助。
生成的代码的任务是将请求从一个格式（比如来自aCORBApeer的请求，或一个POST网络服务）到一般内部的面向元数据的请求格式。
元数据必须包含该服务接口的信息，比如变量类型，名称等，但是可以被扩展以包含默认值和确认。
如果在这个脉络下扩展，生成的代理将可以使用跟核心服务相同的确认规则（假设核心服务使用相同的元数据——在本情况下，应该是这样！
）。
一般的基础结构基本上被扩展以支持相关特别的科技（经由系统代码生成）。
生成代码需要在底层应用程序基础上定义一个包装器，以配置从一方发往另一方的请求。
这是有元数据模型促成的，这个模型定义了服务接口的全局数据表示法。
这样做的结果是一个技术环境的底层结构可以独立于代码生成进行测试，这是增加代码生成质量的关键因素。
元数据也允许不同的代码生成策略，比如“包含为确认请求而生成的代码”或“不生成确认的代码”。
图5系统的代码生成
需要保证所有目标环境（由代码生成器连接）的苛刻的请求都在服务元数据模型中详细描述，这是一个代码生成的不利方面。
如果不这样，元数据模型就需要修订或扩展以支持目标环境中的不同于本模型的一些概念，也就是说，这样的模型是不完整的。
来自服务代理的另一个不利方面是版本控制。
版本和配置的管理经常是非常痛苦的，需要专门的处理。
无论如何，面向代理的版本控制和面向传统开发方法的版本控制并无太大区别。
如果一个服务的定义改变，相关的代理需要重新生成，代理相关的综合需要影响评估（本方法的可描述性使得一切都很简单）。
其它情况都没什么不同，但是我们要保证核心服务、基础构造和生成的代理都在部署方案中匹配。
对创造者来说，元数据模型如何被完全利用，没有一个真正的答案。
查看标准或许有帮助，但是组织严密、文文件翔实的模型更加强壮。
幸运的，对后者，从元数据模型中衍生意味着包装和包改变时的影响分析或在相同的基于工具的政策下来进行包装。
对代码生成来说，这个构造的确切配置是众所周知的，可以用来组织一个部署仓库。
运行时
回到使用元数据驱动的方法设计开发应用程序的最初目的，最好是在运行时来分析回顾一下。
假设构建过程采用了一个针对元数据服务定义裁减过的通用软件基础架构，同时元数据在创建（编写代码——那没什么神奇的）该程序的核心服务时和生成服务代理时都使用到了，整个解决方案的一致性就像是元数据模型那样完整。
来自任何支持的外部源的请求都被各自的服务代理做一下配置，在这个配置过程中，依靠使用的代码生成策略，服务代理可能根据元数据提供的一些规则对请求做些确认工作。
这可能包括证明，授权和过程管理，从元数据转交给相关代理子系统。
一旦配置成通用的服务请求格式，请求就被送至请求管理器处执行。
执行中，请求管理器对请求进行询问，根据目标（核心）服务的元数据对请求进行匹配。
如果全部顺利，目标服务接受请求，并且该服务可能在处理请求时使用额外的元数据。
见图6。
图6处理请求
最终结果是一个解决方案的设计方法，从开始设计到执行。
元数据驱动的应用程序比起其它传统程序为什么能有更长的寿命，这又是如何做到的？
最终我们提供了一个实际的解释。
文檔
如果本方法允许从服务定义中生成代码，不生成服务接口规格的文文件是没有道理的。
这是许多年的实践，使用象RationalRose（toMicrosoftOfficeWord）的工具进行自顶向下的文档生成，或是使用一些面向代码的工具（比如AutoDuck或JavaDoc）来自底向上的生成。
适应性
在这一方法中值得进行一些观察，对组织有关应用的方面做一个基本的概要。
在开发中，对元数据驱动的概念来说，刻画出组织的类型，本方法可能同如下相关：
∙需要在设计和执行中实现更紧密联系的设计者和开发者；
∙确实看中基础构造驱动，高生产力，高质量的开发方法的组织，
∙那些不因为一些简单生产力增强工具就满足的组织，
∙希望建立知识仓库和相关工具以更好的通过一种正式的描述性语言来描述他们的产品的组织。
∙需要支持更广的技术环境的组织，尤其是在系统边界。
有帮助么？
这个方法在许多项目的不同方面都有应用，这些工程有些是我讨论过的，或是参与过的。
许多这些项目都想从运行时的模型达到完全的前向模型这样一个高目标，其中一些确实在处理某些特殊领域时做到了。
在Temenos，我们在制作新的具有24*7能力的一个银行系统（“T24”，在2003年底投入使用）时使用过上述和一些相关的技术。
更确切的，我们在制作软件开发工具箱（现有功能上可编程的API）和网络服务部署工具时使用这些技术。
这不是很简单，可能时常让你头疼。
但是看看T24解决方案的模型，就会清楚地知道：
当新的科技浪潮来到时，使用元数据驱动的方法设计开发应用程序会帮你组织好已有的服务，并让其发挥更大的作用。
仔细分析许多IDE和工具的制作商的动机。
元数据表示和代码生成被再一次追求。
但是这次目标是通过提供针对如今科技环境的复杂性和抽象性的管理工具，使得开发过程更有效率。
参考资料
面向模式的阮家架构：
写作与网络对象的模式
DouglasCSchmidt,MichaelStal,HansRohnertandFrankBuschmann,JohnWiley&Sons
元数据案例
JNDI
LDAP和主动目录
EEO规范
升级会员 