SOA专题
SOA最佳实践
SOA需要通过松耦合 碎片化系统使得SOA实现能够更快速更简单更可扩展。
一些领域的客户和业界正经历SOA扩展性的困难:
- 生成一个系统规范所需的时间和资源
- 导致错误高频率发生的系统规格定义含糊
- 全面实施导致对系统复杂性的可见都降低。
- 无法保证在执行过程中对最初规定保持一致性
- 需求评估的变更先于代码
大部分系统规范的生成是有问题的。目前,业务分析员使用MS-Word文档和
标准的图形包进行业务解释性说明,
随着业务流程变得更加复杂,使用这些工具实现信息交换变得更加困难。
随着复杂性的增加,说明书开始变得模糊,从而导致执行错误。
收集业务需求
第一阶段是文档要求。为了确保需求有效地可以验证实现, 需要以一种机器可处理的方式进行描述。为了实现这一目标,需求被分离两大类:
1.说明系统之间交互的业务消息
2.有关消息处理可选路径的细节场景。
举例来说,一个场景可能代表一个客户交易完成后,一个成功的信用 检查:而可选替代路径失败的交易导致信用检查失败。这些 可选路径的选择,或“方案”的记录需要使用的序列图描述。
过程设计
下一步是创建或重用消息的类型定义来建立过程设计,以及定义在场景中的上下文。如果说消息是基于XML的,消息的类型可以是使用XML架构定义。
为了描述的动态行为的定义,类型可以表示使用编排描述语言,例如CDL。
“choreography”从一个中立的或“全球”的视角描述了在一组服务之间的相互作用
。这不能与业务流程的概念混淆,它提供了一个只有从服务角度描述特定的行为。
一旦类型定义已经被定义,信息是用来验证方案。这确保了 类型定义正确表示源的要求。这是一个重要的步骤,因为类型定义 随后将被用来实现系统。这提供了描述的场景和代表业务需求的需求之间的连接验证
信息采用XML,验证解析器可以用来确保消息实例符合XML schema。使用场景中的消息通过模拟执行路径可以验证编排描述。
举例:下面是一个场景显示验证错误,购买(buyconfirmed) 竟然跟着checkCredit(creditcheckinvalid)的消息响应:
当检测到错误,系统设计师需要确定编排描述或场景是否正确。 如果场景已经签署代表业务,代表一个有效的用例,系统建筑师 需要用业务重新确认,以确保业务被正确地描述。在这种情况下, 编排描述需要调整以反映所需的使用案例。
一旦过程设计的编排描述已被验证是正确的,它可以被导出到
BPMN等格式或UML活动/状态图和HTML,并进行审查并签字。
评价已经存在的服务
一旦过程设计得到了验证,系统架构师需要确定服务是否可重用, 为了能够重用,还是需要修改这些服务重新构建。为了完成这点 系统架构师需要了解每个服务在过程设计背景下的具体行为,使用 一种叫端点项目的技术可以实现这点,它为每个服务场所端点行为描述。
下面是一个Store服务的端点行为描述:
Receive BuyRequest from Buyer;
Send CreditCheckRequest to CreditAgency;
choice {
Receive CreditCheckOk from CreditAgency;
Send BuyConfirmed to Buyer;
} or {
Receive CreditCheckFailed from CreditAgency;
Send BuyFailed to Buyer;
}
端点行为描述是用来询问服务存储库和确定匹配服务的可用性。
如果只有部分匹配,就要分析需求以确定它是否是适当的修改现有的服务,或建立一个新的
版本。
服务设计
对于需要开发的服务,端点行为描述可以使用BPMN UML状态图等生成一个服务设计的模板
这项服务的设计可以由设计师精心设计,提供有关服务的内部实现进一步的细节。以下
比如显示商店服务BPMN模板:
服务是有态的还是无态的?
1. 使用消息调用服务。(HTTPSession or cookies不能使用)
2. 服务接口设计不要依赖任何共享的知识。
一个商店系统试图从消费者信用卡中扣除电视费用,但是因为费用太昂贵,商店系统必须要求信用卡发行商显式授权这笔交易。
Connected服务实现
- 客户端: Bruce能为新电视支付 $1000 吗?
- 服务提供者: Yes
- 客户端:: 授权给他 $1000
- 服务提供者: OK
这里的“他”涉及到上一段对话的意义,
Connectionless服务
- 客户端: Bruce能为新电视支付 $1000 吗?
- 服务提供者: Yes
- 客户端:: 授权给Bruce $1000
- 服务提供者: OK
Connectionless服务每次调用意义都是完整的,不涉及上下文。
服务应该被设计成无连接是一个原则。对于共享的活动序列,该活动的每个实例应被唯一地标识(例如,通过一个事务ID,或通过客户ID Bruce)。标识应该成为服务调用的组成部分。
服务的粒度
SOA的服务一般是大粒度,但是
可重复使用,细粒度的服务也可以存在
技术功能(例如日志记录)
业务功能(如getBalance )
业务事务(如openAccount )
业务流程(如applyForMortgage )
在对应的粒度级别实现编排或聚集:
1. 用户提交一个请求到自助服务的应用程序,是为了创建一个抵押贷款帐号,自助服务应用程序提交到业务流程服务, 通过服务基础设施请求choreographer组件createMortgageAccount,其目的是为了将业务交易服务纳入业务流程的服务。
2 .服务基础设施一旦接收到createMortgageAccount业务过程的请求,首先调用认证authentication和 授权authorization技术功能服务,以确保该请求是有效的,最后还有日志记录。
3。服务choreographer执行 createMortgageAccount 业务流程服务,如果请求验证有效,当其他流程元素完成后,choreographer调用createCustomerRecord业务事务,将新客户的记录在服务基础设施中。
4. 在客户管理系统,
createCustomerRecord 业务事务服务有必要验证新客户信息,验证的内容有检查邮编和地址是否匹配。为了实现这些,
CheckPostCode业务功能服务将通过服务设施完成。
聚合或编排都(分散)是按照服务粒度来实现的。
- 服务编排者 choreographer:编排事务服务进入高层次的业务流程服务。
- 服务基础设施 (也许是企业服务总线):编排技术功能服务,以便控制业务流程服务 业务事务服务和业务功能服务的调用。
- 独立的应用组件:负责调用业务功能服务,是按照业务事务服务的执行顺序调用的
服务实现
从端点行为描述中导出服务实现的主要代码,比如Store商店系统导出的WS-BPEL如下:
<process name="Store"... >
...
<sequence>
<receive createInstance="yes" operation="buy" partnerLink="Store" portType="tns:Store"/>
<scope>
<faultHandlers>
<catch faultName=”tns:CreditCheckFailed” >
<reply faultName="tns:BuyFailed" operation="buy"
partnerLink="Store" portType="tns:Store"/>
</catch>
</faultHandlers>
<sequence>
<invoke operation="checkCredit" partnerLink="CreditAgency"
portType="tns:CreditAgency"/>
<reply operation="buy" partnerLink="Store" portType="tns:Store"/>
</sequence>
</scope>
</sequence>
</process>
服务测试
一旦服务已经实现,需要服务仓库中存在的服务进行单元测试,场景是用来
进行单元测试,场景发送一个消息给服务,一个服务单元测试工具是用来传递消息,消息能够被服务单元测试工具拦截,和预期场景的消息进行比较,这确保
这个服务的端点行为描述能够正确被描述。
服务部署
一旦服务测试完成,每个服务被验证然后被部署,端点行为描述被记录在服务仓库,
这样以后能用于新的子过程设计 为重用定位一个服务。
运行流程的管制
设计时的流程治理能使服务在部署之前被检测到不兼容的行为, 也包含运行时处理错误的风险。运行流程管制需要运行过程中治理,以确保持续 针对原始需求不断验证的过程。这包含了“实施漂移”的风险,因为 服务的修改和新服务被引入。
对每个服务使用部署服务的验证程序。该验证器报告所有服务 涉及相互作用过程的相关使用方法,这些方法能够重建整个事务过程。 eventsourcing是一种值得推荐的方法。
服务行为验证
服务验证器监测每个服务的入站和出站消息,并将这些与 预计服务端点的行为描述相比。在“激活”模式,服务验证器将阻止乱序或无预测的交互 ,这样保护下游流程:在“非激活”模式,所有消息事件无论是否 符合或不符合流程设计都会被允许执行。所有互动,包括不符合规定的事件,都会 上报流程关联器Correlator.。
该流程关联器Correlator是一个集中的关联引擎。它作为用于发送 接收和错误 警告的仓库。记录由服务验证器报告,以及不遵守流程设计的相关操作。
这种确认性验证循环能确保整个SOA实现是否按照原始设计正确执行。
由于所有消息事件被报告给流程关联器Correlator,这样细腻度的可视性得以实现,
包括包括消息的时间标记的集合,用来识别和监控相关的过程的性能指标。
流程相关器不同于通过单独监控每个服务的传统方法,它是确保端到端处理的一致性,
并确保遵守上级流程设计。这弥补了针对具体的业务监控的缺点,
以及可能会影响下游处理的交互等缺点。
希斯罗机场5号航站楼手机SOA实现,每个子系统作为功能设计, 整体的处理未按照需求执行,在这种情况下,行李处理子系统激活使用一个过滤器 ,以防止它连通与相互关联的系统。这也防止了行李处理系统访问托运行李传送目的地 。导致返回的行李返回了终端,而飞机已经飞离却没有装载乘客行李。这造成的混乱导致了估计1千6百万英镑的损失。
治理过程应该直面这种风险,通过确保整体的运行行为在执行时能按照需求全局性统一性的描述(DDD统一语言和流程语言结合)。
流程维护
无论是在SOA的设计和运行阶段,流程治理执行了一种重要职能,
它也在维护阶段有重要职能。
对于跨越一个高度分布式架构实现的变化保持强大的控制权是一个复杂的问题,
是维护整个系统完整性的关键。
下面的方法描述了如何使用程序来实现治理:
更新需求和流程设计
无论使用原始产生的方案场景或通过生成新的场景发生的改变都要被明示, 一旦场景更新,流程设计也需要修改以反映需求的改变,并且对新场景进行验证。
实现效果分析
实施效果分析是一个静态的检查,以确定修改对部署的系统可能产生的影响 。这样能够识别部署实现和修改的实施之间的不相容。从而减少了对系统的测试 时无意中引入运行时错误。
确保服务资源库包含了客户端与和服务之间的所有相互依存关系的信息是很重要的,否则只可能是实施的局部效果分析。
实施和部署服务变更
一旦发现执行影响了分析,将可能开始计划实施执行和
部署以应对任何新的或修改的服务。
如果需求的改变是补充现有的客户端使用,那么服务部署可能简单地进行升级。在这情况下,该变化是与现有的客户端使用不兼容的,这是不可能同时
该服务的修改版本可能影响现有部署和客户端。
如果服务细节“硬编码”到相关的客户端,以确保他们访问了正确版本的部署服务。 是没有困难的。但是如果使用了动态服务发现,那么流程治理确保受影响的 客户机都配有正确的参考服务的相应版本。这可由客户端实现 执行服务查找时提供所需的端点行为描述。客户端提供的说明可以和记录在服务信息库比对, 以确保符合服务描述一致性。