加载中…

加载中...

个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,188,040
  • 关注人气:5,925
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

读《SOA设计模式》第一部分

(2011-09-03 15:26:52)
标签:

soa

设计模式

分类: IT咨询
原文:http://www.infoq.com/cn/articles/3-SOA-Design-Patterns-Thomas-Erl

可以看到第一部分主要围绕标准规范的服务目录库的建设而展开,这些设计模式在服务设计一开始就必须考虑,以降低后期服务目录库的管理难度。

规范表述(Canonical Expression,275)提炼了服务契约,从而使服务更容易被发现,它通常与元数据集中(Metadata Centralization,280)联合使用,元数据集中的核心是为了促使服务契约的发现而建立一个服务注册中心。二者被规范版本控制 (Canonical Versioning,286)进一步补充,而后者要求采用统一的,服务目录级的版本策略。

我们认为这三个模式是服务目录治理的基础,它们支持服务发现原则,并受其影响。服务发现原则要求以方便有效发现和解释的方式来规范服务的元数据信息。

规范描述

首先再来看下服务契约,服务契约是服务提供方和服务消费方之间就服务名称,类型,安全,描述,服务提供操作,服务提供的数据等各种信息的一个详细约定。契约也需要对那些服务和数据到底怎样将被提供进行细节性的阐述。服务契约可以看做是SOA开发方法中重要的需求文档。

高级的分析师Ronald Schmelzer曾经提到了服务契约的拟定步骤,他建议首先确定服务, 包括服务提供的价值,服务功能性,服务质量和任何在服务的消费上的限制条件。下一步, 他说应该阐明服务将怎样被消费, 包括确定请求的消息和语义的形式,标识结果条件和行为,并且确定过程和活动的流程。最后, 他说阐明服务将怎样相互作用, 包括消费者将怎样与服务通讯,可接受的通信协议是什么,什么样的引用风格是适当的,以及预计的潜伏期是多久等。

问题域:由不同时期的不同项目交付或扩展的服务契约自然是由开发或扩展它们的架构师和开发者所确定的。这种方式就会导致服务上下文以及由服务上下文语法所定义及描 述的服务个体功能的不同。有些可能采用详尽冗长的描述习惯,而其他可能采用简洁且技术性的格式风格。再者,用于描述常用及相似功能的实际词汇也不尽相同。

解决方案:标准化的命名规则能够应用于所有服务契约的交付过程,从而保证服务上下文和服务功能的表达一致性。因此需要定义详细的服务域,服务命名规则,服务操作方法命名规则,服务契约定义模板和属性定义要求,特别是Web服务,该模式可能会影响WSDL定义文件的设计。可以看到这是SOA治理的一个关键内容。

完整的服务契约应该包括了服务WSDL文件定义,服务数据结构的XSD文件定义和WS-Policy定义三个方面的内容。其中WS-Policy主要是服务策略,重点体现了服务契约中约束的实现。

Policy的管理包含两个部分内容:一是要在设计和运行时规定服务策略(Service Policy)的定义,交换和强制执行的方式和方法;二是要有基于标准(比如 WS-*)和组织内部规章。那么我就可以看到WS-Policy在SOA项目实施过程中,或者说在SOA的管控(governance)领域实际的应用意义。

Weblogic对WS-Policy支持相对于CXF开源框架来说,还不够完整和全面。CXF的WS-Policy框架提供了一个允许CXF用户和开发者使用WS-policy应用架构和API。CXF支持规范的版本是1.5。框架是由一个核心运行环境(Core)和允许开发人员插入自己定义的断言的API组成的。

核心运行环境(Core)从不同源文件(WSDL,外部文档)中获取Polices信息,对实施的Policy(策略)的服务,端点,操作和消息对象的计算。通过拦截器对某个特定的Message实施的策略的运行状态的监管。对于一个替代的实施策略的支持性验证。可以看到其核心实现策略仍然是对策略解析后通过拦截器加载和执行。

元数据集中化

元数据是数据的数据,而在服务定义中所涉及到的服务域,服务目录,单个服务和服务操作,服务名称,类型,版本,安全等各种信息都属于元数据管理的范畴。这些元数据包括两个核心,一个是这些元数据应该结构化管理,一个是这些元数据应该集中管理。

问题域:在增长目录和支持由服务标准化(Service Normalization,131 )和逻辑集中(Logic Centralization,136)所实现的基本服务质量时,项目组不断面临着这样的风险,他们在不经意间(或有意地)交付的新服务和现存或开发中的 服务具有相同的功能。由于元数据没有办法进行共享和查找,导致了重复服务逻辑的引入(和逻辑集中(Logic Centralization,136)相违背),重复服务上下文的引入(和服务标准化(Service ­Normalization,131)相违背),这些导致整个服务目录和技术架构的实效。

解决方案:建立服务注册库,除了注册已有的服务和能力外,还需要注册开发中或候选的服务和能力。服务注册后有详细的服务元数据描述,这些描述信息足可以解释服务的语义和功能边界,服务的调用和交互需求。通过提供一个更新及时且维护良好的服务上下文和服务功能的注册库,可以收获有效的服务发现。

基本服务发现过程,人们首先通过代表服务目录的服务注册库定位到潜在服务,然后翻译该服务,从而确定其是否适合。即我们说的服务注册库真正意义上变化为一个能力提供中心,元数据集中化后消费方系统可以很容易的进行服务查找和发现,确认服务是否满足需求,提升服务的复用率。

服务注册和发现过程是服务目录有效治理的关键因素。如果该过程不受项目组的重视和一致遵守,或者注册库更新不及时,那么元数据集中的潜在价值就会大打折扣。然而,从设计的角度看,基于服务发现原则,该模式会引入元数据标准的需求。它还会进一步要求元数据文档和注册成为标准服务交付的生命周期的一个环节。

元数据集中的核心是建立一个服务注册库,它是保证逻辑集中(Logic Centralization,136)和契约集中(Contract Centralization,409)长期有效应用的关键。如果能够有效定位正确的服务及其契约,那么无意中引入冗余服务逻辑的风险就能大大降低,从而 进一步支持服务标准化。

服务规范版本控制

问题域:对同一服务目录里的服务契约使用不同的版本控制会导致无数的互操作性以及治理问题。当同一服务目录内的服务契约受到不同的版本控制方法以及规则影响时,实现后的契约级的不一致性就产生了,势必会破坏互操作性以及有效的服务治理(图10.8)。这将给设计时客户端开发,运行时服务访问,服务重用以及全局服务目录的发展带来不利影响。

解决方案:同一服务目录里的服务契约应依据同一的规则进行版本控制,并且也作为整体企业版本控制策略的一部分(图10.9)。这样才能保证对每一个服务有统一的治理路径,进而保持契约标准化以及目录内的兼容性以及互操作性。当服务受统一的版本控制策略管理时,它们可以保持原有的标准和互操作性,并且能够更容易被客户端设计人员理解。

对于服务版本控制策略,可以给出的三个基本控制原则如下:

  • 严格 ——所有兼容或不兼容的更改都将产生服务契约的新版本。该方法不支持向后兼容或向前兼容,在当服务契约被多个伙伴机构共享且服务契约的修改可能会带来法律上的影响的环境里,这是最常见的做法。
  • 灵活 ——所有不兼容的更改导致服务契约的新版本,契约的设计支持向后兼容,但不支持前兼容。
  • 松散 ——所有不兼容的更改导致服务契约的新版本,服务契约设计既支持向后兼容,也支持向前兼容。

对于服务版本变更最常见遇到的问题即是服务是否可以直接修改还是需要产生新的服务版本。特别是当一个服务已经被多个消费方使用的时候,必须要考虑到遗留消费系统消费情况和向后兼容性,如果修改的不是统一的规则和统一的调整,很多时候都必须要需要考虑到遗留系统对旧版本的需求。新旧服务版本并存,新接入的系统采用新版本,旧版本在使用过程中逐渐被替代掉是常用的方法。

版本标识(Version Identification,472)将应用于:

  • 版本信息如下表达,大版本号在小数点左边,小版本号在小数点后边,如(“1.0”)。
  • 契约的小版本号和大版本号在WSDL文档中描述,并在版本号之前加上“Version”的字样,(如<documentation>Version 1.0</documentation>)
  • 大版本号附加在WSDL定义文件的目标命名空间的后面,并使用“v”作为前缀,比如:http://alleywoodlumber/contract/po/v1

兼容性变更(Version Identification,465)将应用于:

  • WSDL定义文件的兼容性变更会增加小版本号,但不更改WSDL中的目标命名空间。
  • XML模式定义的兼容性变更增加小版本号,不修改XML模式和WSDL中的目标命名空间。
  • WSDL文件中的非兼容性变更增加大版本号,且强制WSDL使用新的目标命名空间。
  • XML模式定义中的非兼容性修改增加大版本号,并强制XML模式和WSDL使用新的目标命名空间。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有