服务规范

　　服务规范定义依赖关系、组合、公开决策、消息、服务质量约束以及与服务状态管理相关的决策。服务规范任务的目标是详细描述服务模型。

　　服务规范包括以下子任务：

　　·应用Service Litmus Test以做出公开决策
　　·确定服务依赖关系
　　·确定服务组合和流
　　·确定非功能性需求
　　·指定服务消息
　　·编写状态管理决策文档

　　应用Service Litmus Test以做出公开决策

　　使用Service Litmus Test以做出服务公开决策。图9突出显示了需要公开的JKHLE候选服务。

　　图9要公开的服务
 
　　确定服务依赖关系

　　详细的服务检查可以揭示对用于实现服务功能的其他服务或应用程序的服务依赖关系。

　　存在两种需要考虑的依赖关系类型：

　　·功能依赖关系是这样的服务之间的依赖关系，即这些服务彼此依赖以交付所需交付的服务。例如，AccountActivation组合服务具有对ARSetup、AccountSetup和createAccount服务的依赖关系。
　　·流程依赖关系是这样的服务之间的依赖关系，即这些服务编排在一起以构成业务流程。例如，帐户开立流程依赖“确定资格”前提条件和“创建帐户”流程依赖关系。

　　确定服务组合和流

　　检查功能区域和业务流程可以帮助详细描述服务及其流的组合。服务流规范描述服务之间的编排。例如，帐户激活组合服务是一个长时间运行的可中断流程宏流。“帐户查询”是一个短时间运行的不可中断流程（微流）。

　　确定非功能性需求

　　服务模型必须考虑用于指定服务质量(QoS)的非功能性需求。例如，“帐户查询”服务可用性需求为99.999%，帐户激活服务的帐户激活性能需求为在四天内激活。

　　指定服务消息

　　服务模型中的数据流通常以在服务之间流动的消息的形式表示。在确定服务规范的过程中，存在数据模型未完成的情况。要考虑有关将实现的服务的详细信息在此时间点不足够的情况。虽然如此，仍然需要考虑用于服务输入和输出的数据和消息。例如，表2指定了AccountInquiry服务的服务消息。

　　表2指定服务消息

　　编写状态管理决策文档

　　在某些情况下，服务组合需要编写状态管理文档，例如有状态、无状态、带有缓存状态的状态等等。

　　例如，存在流程的某些部分的状态管理可能由组合服务或其他元素控制的情况。

　　服务组件规范

　　服务规范任务的最后一部分是组件规范。孤立地执行此任务通常是非常困难的，因此实现任务通常并行地执行并且是迭代的。服务组件规范包括以下子任务：

　　·确定组件属性
　　·确定事件和消息
　　·确定组件内部流
　　·创建组件类关系图
　　·面向变化的设计

　　可以使用IBM Rational Software Architect，以UML的形式为服务组件规范任务创建若干工作产品。

　　服务实现

　　在确定并指定服务以后，需要做出有关每个组件如何实现功能的关键体系结构决策。

　　服务分配

　　在整个生命周期中以迭代的方式将服务分配到组件，以执行用于将服务分配到企业组件的服务分配。例如，帐户查询服务被分配到客户CICS后端系统（请参见第12页上的图7）。

　　技术可行性探索

　　需要确定并评估技术约束，以确保公开候选服务在技术上是可行的，对于在现有系统分析期间确定的服务尤其是如此。通常使用技术原型来探索技术可行性。

　　将组件分配到各层

　　将组件分配到应用程序体系结构中的各个SOA参考体系结构层是在指定组件并编写实现决策文档之后执行的（请参见第12页上的图7）。

　　表3 提供了关键的服务实现决策的摘要

　　表3 服务实现决策

　　SOMA建模环境

　　SOMA建模环境（Modeling Environment，ME）提供模型、方法、IBM工具和内容的内聚联系，以支持对用于IBM客户服务合作项目的SOA解决方案进行基于资产的开发。

　　业务转换分析和服务设计

　　注意：业务转换分析（Business Transformation Analysis，BTA）和服务设计实现使用RUP SOMA业务转换分析方法。

　　服务设计使用IBM Rational Method Composer包括的RUP SOMA方法中捕获的过程。IBM Rational Software Architect用于创作和重用服务设计模式和最佳实践，包括数据和部署建模以及服务组装。

　　Ursula和服务设计团队成员开始进行有关如何使用BTA和服务设计的培训。该团队计划使用此方法为将来的SOA项目创建服务设计。

　　在“用于服务设计的SOMA”中，我们在“帐户开立项目”的上下文中描述了SOMA的核心元素。在本部分，我们将重点介绍业务转换分析(BTA)和服务设计实现的关键元素，这些元素利用了IBM Rational Method Composer中包括的RUP SOMA方法。BTA和服务设计实现通过应用自动化的设计工具和流程，以改进设计一致性和缩短上市时间，从而提供正式的说明性SOA设计方法。

　　图10显示了核心RUP SOMA用例和参与者。RUP SOMA利用了“应用基于模式的工程方法”的概念。

　　请注意，参与者将带模式的BTA和服务设计应用于执行业务转换分析用例，以及包括标识、指定和实现服务的核心SOMA用例。

　　图10核心RUP SOMA用例
 
　　图11显示了用于BTA和服务设计的扩展流程。RUP SOMA流程步骤显示得非常粗略。更详细的信息在IBM Rational Method Composer包括的RUP SOMA方法中。

　　请注意数据建模、集成服务和部署建模的连锁流程。在此例中，RUP SOMA流程使用数据建模的结果。集成服务和部署建模主要是RUP SOMA的后续流程。管理可重用资产是扩充所有其他流程的基础结构流程。

　　IBM推出的重用管理解决方案基于IBM Rational Asset Manager，后者用于管理和治理对任何角色和规则有利的几乎任何资产的重用。Rational Asset Manager可以与IBM WebSphere集成在一起。服务注册中心和存储库支持在组织的标准资产重用流程上下文中重用和治理与服务相关的运行时资产。

　
　　图11 BTA和服务设计扩展流程关系图
 
　　图12显示了RUP SOMA中定义的主要活动：

　　·执行业务转换分析：生成用作服务设计输入的业务和业务流程模型。
　　·标识服务：发现候选服务并将其组织为层次结构以便于理解。
　　·指定服务：指定服务的外部视图，并充实服务传递的消息。
　　·实现服务：做出有关服务实现的决策。

　　RUP SOMA流程没有充分强调可靠的需求管理在整个SOA设计生命周期中的作用。因此，添加了管理需求流程元素。如图12所示，整个生命周期中非常协调地使用了IBM WebSphere Business Modeler、IBM Rational RequisitePro?和IBM Rational Software Architect。

　　图12用于BTA和服务设计的核心RUP SOMA流程
 
　　在下面的几个部分中，我们将重点介绍核心BTA和服务设计用例的重要参与者、方法与模式、工具和工作产品。

　　执行BTA

　　图13显示了执行BTA流程中的主要活动。BTA的结果是创建了描述以下内容的工作产品：

　　·业务的静态结构

　　创建业务分析模型并执行功能区域分析的活动。

　　·业务的动态特性

　　创建业务用例模型，并通过WebSphere Business Modeler业务流程实现业务用例。

　　BTA活动可以产生业务体系结构的完整描述。BTA活动还可以提供与业务相关并且是服务设计的必需输入的模型。服务设计还使用业务规则和业务目标作为服务发现的输入。BTA还包括集中于那些构件的活动。

　　图13RUP SOMA——执行BTA
 
　　标识服务

　　图14显示了用于标识服务的RUP SOMA流程。该流程依赖并行执行的子任务，这些任务用于标识候选服务。同时使用不同的方法可以极大地提高发现完整候选服务集的机会。

　　图14 RUP SOMA——标识服务
 
　　指定服务

　　图15显示了用于指定服务的RUP SOMA流程。该流程用于定义服务的外部视图，以及用于实现服务的子系统和组件的外部视图的设计。在每个抽象级别，描述了接口、接口签名、接口协议和消息。此外，将在总体流程的此部分期间处理更细粒度的元素（例如原子服务）的编排，以实现更抽象的元素（例如组合服务的接口操作）。

　　在此级别的设计完成之后，可以使用产品化的Rational Software Architect转换来创建可供IBM WebSphere Integration Developer使用的项目和内容，包括描述服务接口的WSDL文件和描述元素（这些元素用于实现服务）执行的BPEL。内容为集成开发人员提供了起点，此起点基于解决非功能性以及功能性需求的已架构IT解决方案，从而给集成开发人员带来好处。

　　图15 RUP SOMA——指定服务
 
　　实现服务

　　图16显示了用于实现服务的RUP SOMA流程。做出有关使用哪些现有资产来实现服务的决策。

　　在使用新组件以实现服务的情况下，将做出有关在总体系统体系结构中的何处使用那些组件的决策。

　　图16 RUP SOMA——实现服务
 
　　用于流程组合的业务服务设计

　　注意：用于流程组合的业务服务设计实现演示了使关键业务度量与业务目标保持一致的流程建模和模拟。

　　Ursula从业务分析人员那里了解到需要对帐户验证流程进行流程改进。Ursula使用IBM WebSphere Business Modeler来模拟现有的流程，然后在通过关键度量模拟来实现的流程优化基础上创建了建议的流程。

　　当前帐户验证流程

　　下面，我们将描述当前帐户验证流程（如第26页上的图17所示）。帐户协调人员检查客户申请，并研究有关多个不同系统的信息，以确定是否需要信用报告。

　　如果不需要信用报告，则客户申请将跳过该流程的大部分内容。如果需要信用报告，则帐户协调人员将向信用调查机构打电话或发送传真，以请求信用报告。由于通信方法（传真或电话）问题，信用调查机构没有为JKHLE提供针对其服务的优惠定价。获得多个信用报告非常昂贵并且耗时。

　　JKHLE无法区分高风险和中等风险的客户，从而导致远高于行业平均水平的大量拒绝受理请求。最后，帐户协调人员发出了批准。批准的定价是通过参考一组复杂的纸质手册来确定的。

　　当前流程中存在多处流程改进余地。

　　·缺乏单一客户视图和信用流程业务规则导致我们定购了超过需要的信用报告。
　　·手动的信用报告检索流程高度不一致、代价昂贵并且非常耗时。
　　·太多的客户请求被拒绝，导致潜在客户不愉快并导致销售代表不满。
　　·虽然定价和帐户规则相当简单，但是其值更改得非常频繁。由于该过程是手动的，很难实现快速更改。

　　图17帐户验证（现有）

 
　　预期的帐户验证流程

　　Ursula在WebSphere Business Modeler中修改了模拟的帐户验证流程来处理上述流程改进，以创建如图18所示的基准。接下来，Ursula可以通过更改流程中的关键度量或值，从而试着优化该业务流程。这称为流程优化（请参见图19）。

　　优化后的流程具有以下改进：

　　·自动化的完整客户视图减少了需要信用报告的客户数量。
　　·自动化的信用报告显著降低了成本并更加快速。
　　·批准更大比例的客户请求。
　　·基于规则的动态定价，可在业务需求的基础上根据需要进行更改。
　　·平均持续时间变化百分比：加速97.6%
　　·加权平均利润：增加84.7%

　　图18 帐户验证（预期）

 
　　图19 帐户验证——用于优化的流程模拟

 
　　集成开发人员Jason Smith根据前面的实现中描述的方法，使用指定的服务和实现的组件组装并组合了该业务流程。

　　总结

　　了解到Ursula已完成了帐户开立项目的设计，Sandy非常高兴。通过与IBM的合作，Ursula能够将用于服务设计的SOMA方法应用于帐户开立服务设计。此外，服务团队学会了如何使用RUP SOMA方法来为将来的SOA采用创建服务设计。

　　帐户开立服务的设计和开发团队发现，用于SOA设计场景的IBM工具集成良好并且很容易使用。诸如IBM Rational RequisitePro、Rational Method Composer和Rational Software Architect等工具提供了功能丰富的工具环境，可用于加速创建应用IBM方法的服务设计。使用IBM WebSphere Business Modeler对于业务服务设计和流程组合非常有帮助。

　　总而言之，帐户开立案例研究中对SOA设计场景使用了以下IBM产品：

　　·Rational Method Composer
　　·IBM Rational RequisitePro
　　·IBM Rational Software Architect

　　IBM Rational Software Architect中包括的产品功能：

　　·IBM Rational Application Developer
　　·IBM Software Modeler
　　·IBM Rational Data Architect

　　·IBM WebSphere Business Modeler
　　·IBM WebSphere Integration Developer
　　·IBM WebSphere Studio Asset Analyzer