SOA面向服务的业务转换在零售业中的最佳实践

Min Luo （[e-mail]） , 高级认证 IT 架构师, IBM Global Services
Prakash Mall （[e-mail]） , 咨询 IT 架构师, IBM Global Services
Diptiman Dasgupta （[e-mail]） , 咨询 IT 架构师, IBM Global Services
Rajesh Nachaloor （[e-mail]） , 咨询 IT 架构师, IBM Global Services
Julian C. Petriuc （[e-mail]） , 认证咨询 IT 架构师, IBM Global Services
Liang-Jie Zhang （[e-mail]） , 总架构师，行业标准, IBM Software Group
Richard Baca （[e-mail]） , 管理顾问, 分配实践, IBM Global Services
Jack Ehrhardt （[e-mail]） , 系统架构师——零售存储操作, Circuit City Stores

2005 年 3 月

<abstract-extended>从最近多个百万美元的项目（包括服务、硬件、软件和托管）的实施框架中发现创新的解决方案框架，将其用于能够创建更有效基础架构的最大的电子零售链之一。该框架有助于线形存储销售并支持办公操作，具备中央办公功能，劳动力管理、订单管理和库存管理。项目开发组及本文作者采用了以模型为中心的解决方案来分析并设计用于集成包解决方案组件和遗留系统中的面向服务的集成层。此外，他们设计并开发了轻量级的企业服务总线（Enterprise Service Bus，ESB）来实现基于服务的集成。解决方案提供者使用此套标准服务规范通过 ESB 提供或使用这种服务。提出的这个解决方案框架提供了以零售业为中心、技术和平台独立的、基于服务的整合层（最终是一个以零售为中心的 ESB 实现），其他零售商可以无需费力地将其采用。本文（该系列文章中的第一部分）重在创建用于集成的以零售为中心的服务模型创新解决方案。</abstract-extended>

引言
六年多的时间里，我们的客户试着将他们的超过 16 年的以存储为中心的（高级分布式的，每个存储都是自我提供的计算岛）、包罗万象的、重量级的零售终端（Point of Sale，POS）系统。遗留 POS 系统使用私有设备（包括存储服务器本身），提供了越来越复杂的僵化的业务逻辑，并且需要越来越昂贵的支持和维护。经过这些年，存储系统已经发展成能够支持许多复杂的业务流程，适合于内部的存储及共有的操作。现有的系统被建立在高度定制的体系结构上，使得修改非常困难且繁琐。此外，客户端不再是老式的私有 POS 设备的替代部分的来源，并且生产更多在财政上是不可行的。最终，存储服务器的容量不能再被扩大了，并且它不再完全支持对于最繁忙的存储的需求。它是缓慢的、不响应的，并且将对存储销售和客户服务产生越来越重大的影响。

在九十年代末，替代的系统被开发出来，它试着利用商业现货供应（commercial-off-the-shelf，COTS）POS 产品，但是它只能代替原始系统的一部分功能。对于替代系统被安装的位置的存储，老式的系统仍旧需要许多内部存储的共有功能。这导致了过量开销的影响和风险，因为它需要客户端来维护两个系统。广泛的定制和以存储为中心的特性使它非常昂贵，并且客户端不能承受研究出详细的解决方案所需的时间。

在本文中，我们提出了新的系统，最初设想它不仅能克服以前系统中的许多问题，而且能够引入新的细存储操作的概念，它仅提供了存储中需要的最少的系统功能，并且在托管和数据中心环境下集中了许多其他功能。我们采用了一个创新的解决方案来分析并设计基于服务的集成层，利用业务流程建模和执行中最新的技术，面向服务的体系结构（Service-Oriented Architecture，SOA）和 Web 服务，并且有效地使用建模及设计开发工具。这个最终的系统被称作 Store of Tomorrow (SoT).

确定关键业务的目标
SoT 项目的目标是利用现有的基于零售的知识并且应用行业标准、最佳的实践和商业现货供应应用程序。下面的关键目标是有帮助的：

• 采用主要行业的最佳实践及 POS 的零售业标准。
• 利用 COTS POS 和其它支持应用程序组件的最佳类别。
• 最小化定制。
• 调整业务流程和规则以适应所选的应用程序组件。
• 推动细存储的基础架构。
• 增长客户的经验。
• 减少应用程序支持。
• 应用开放技术标准。

细存储概念
SoT 将存储 IT 的基础架构最小化。仅每个销售终端和基本的正常存储操作上的必要 POS 功能仍旧被存储，所有其它的业务功能交给集中的托管环境。这导致：

• 减少了存储 POS 的设备并且更好地利用了不太昂贵的工作站和大众化设备。
• 在传统存储中的软件堆栈被转换成了中央托管环境（如图 1 和 2 所示）。
• 不太强大的、非常有成本效益的内部存储的服务器仅被用于数据引用及其它设备和位置之间传递信息。
• 增长客户的存储经验，因为销售事务是非常有效的，并且客户的需求能适合于更多的服务、销售代表和其它设备（例如，手持和不太昂贵的工作站）。
• 更多的资源被定向到核心策略业务指导。

下两图描述了基本的 IT 基础架构以及传统存储与细存储之间操作上的差异：

图 1. 当前系统的上下文

图 2. 今后系统的上下文

约束
SoT 项目必须处理下面的主要问题和约束：

• 细存储概念的存在需要被确认及验证。
• 组织中文化变迁的影响：客户端需要被调整以适合于现有的 COTS 业务流程和规则，以便优化未经优化的 COTS 应用程序组件及新技术的使用效果，并且为了今后的功能及技术停留在已更新的路径上。
• 需要评估 COTS 供应商的能力来配置必要的基于极度挑战性的时间线的资源（Gartner Group 评估，2004 年 9 月和 11 月）。
• 部署日程安排，需要适合于季节性的销售日程。
• 需要将存储的部署配置的数目降到最小。

SOA、服务和组件的概述

面向服务的体系结构的更新及集成
正如 Albert Einstein 所提出的，“事情应当处理得尽可能简单，但是不能太简单。”许多过去已建立的软件系统没有通过该测试，因为它们太复杂、太昂贵，或走向另一个极端 —— 太简单以至于不能完成实际的业务需求。达到恰当的简单化水平好像是不现实的。将事情变得更加困难的是，在 SOA 出现之前，不存在有效的机制来消除业务需求与 IT 功能之间的隔阂。

SOA 是一种体系结构样式，它努力实现交互的软件组件之间的松耦合。通过使用 SOA，服务集通过简单传递的数据或调整业务活动（包括两个或更多的服务）来彼此传递信息。它通过一套简单通用的接口（在接口上仅编码通用的语义）实现了交互软件组件之间的松耦合。所有提供者和客户都应当能够使用该接口。此外，SOA 采用了描述的消息，该消息受可扩展的通过接口传递的 schema 的限制。这样的 schema 限制了消息的词汇和结构，并且允许在不破坏现有服务的条件下引入服务的新版本。即便要也是非常少的，系统行为通过描述的消息来指定。以这种方式，您可以有效地建立一套服务，它有明确定义的接口，并且能够在多重业务上下文中潜在地被复用。使用 SOA，应用程序是松耦合的，并且可以在服务/接口（协议）级被集成，而不是在实现级，如同过去的实践一样。这使得在 IT 满足任何业务需求的变更时更加灵活、机动、可扩展。

SOA 不是新概念；Common Object Request Broker Architecture（CORBA）和 Distributed Component Object Model（DCOM）早就提供了类似的功能。然而，这些对于服务定位的解决方案受一些问题的困扰，如紧耦合场景和所有权设计及实现。

服务与组件
什么是服务？服务只是一些应用程序功能，它们被发布成业务流程的组件。同组件一样，它提供了独立的构建模块，这些模块共同代表业务应用程序环境。服务是明确定义的、独立的工作单位，不依赖于上下文或其它服务的声明，由服务提供者执行来完成服务客户所需的最终结果。提供者及客户都通过代表他们自己的软件组件来承担职责。使用 SOA，所有的业务任务或流程都可以被设计并作为互联网（或其它任何网络）上使用的服务来构建。

软件组件体系结构已经作为应用程序开发的许多领域中的标准设计范例而形成了。它从面向对象的技术发展而来，通过提供高级别的提取并将低级别的对象封装进可复用的技术组件（调整以适合于业务操作并可以被反复设计、开发和提炼）中而实现。

为了解释组件和服务之间的关系，通过阅读组件如何被定义成“可执行的代码单元，它提供了相关服务的物理黑盒封装。仅通过包含交互标准的一致的、发布的接口才能访问它的服务。组件必须能连接到其它组件上（通过通信接口） 来组成大组”（企业系统中基于组件的开发：应用选择透视图——请见参考资料）可以得到启发。

企业 JavaBean 是构建基于 Java 的桌面应用程序的组件标准。COM 是通用的 Microsoft® 组件模型，它是应用程序互用性的核心。在 1999 年 7 月，Object Management Group 通过了 CORBA 组件模型（CCM）规范，它扩展了用于电子商务部门的应用程序的企业 JavaBean。在所有情况下，组件体系结构的目标是简化应用程序设计流程并提高应用程序开发的速度。

以商业为中心的、基于服务的集成

业务建模
业务模型是实际的复杂业务的简化视图及业务如何运转的提取。业务结构表示在模型“将承担交流、提高或创新的基本任务，并定义了支持业务所必需的信息系统需求。这样的业务模型对于指导业务起到规划的作用”（使用工作中的 Uml 业务模式的业务建模：工作中的业务模式——请见参考资料）中。

挑战是以精确且对用户友好的方式来将业务流程和业务系统建模。业务系统的描述包括流程描述和静态结构。流程的最直接的模型是为了达到某一目的而执行的活动或任务的序列。如同普遍接受的符号标准一样，统一建模语言（Unified Modeling Language，UML）及其可能的扩展对于描述软件系统来说是足够丰富的。UML 也可被用于抽象层，这里不涉及实现细节。一些 UML 图表从直观上看（例如，活动图、时序图或协作图）与域专家使用的那些非常类似。而且，他们的语义是精确定义的。为了软件设计，如果必要的话，同一图表可以配有实现细节。例如，UML 时序图和 UML 活动图是对用户友好而且精确的业务流程规范。

在我们的以模型为中心的解决方案中，使用标准流程建模软件（例如 Microsoft Visio）创建的业务流程被转换成 IBM® Websphere® Business Integration Modeler（Business Integration Modeler），并且使用 IBM Rational® Rose 中的 UML 时序图来将内部组件的交互建模并分析。

连同我们的以业务为中心的服务模型一起，一套适合业务的服务被结合进来（包含并编排）以实现业务目标。IT 系统提供了这些服务的接口并将它们结合进应用程序中以支持快速变更的业务需求。将服务显示成一套接口，该接口完全不依赖于它们的实现或位置。有时（不必经常）需要在业务用例级创建这些服务。在这个级别上，我们处理业务希望在业务流程中发布、触发或支持的原始活动。

采用 IBM 的组件业务建模（Component Business Modeling，CBM）和面向服务的模型和体系结构（Service-Oriented Modeling and Architecture，SOMA）（请见参考资料），我们采用从上到下的解决方案来从基础零售组件模型中确定一套以零售为中心的业务服务。我们创新的解决方案及适当地使用 Business Integration Modeler and Rational Rose 使我们能够发现适合业务的服务、它们的从属和支持的大规模的业务应用程序组件。同时，我们也采用从下往上的解决方案来确定 COTS 或现有的遗留应用程序最好提供哪个服务，并且最终将确定的业务服务映射到选定的 COTS 零售应用程序组件或遗留系统中。

组件业务建模（CBM）
组件业务建模（CBM）是 IBM 分析和建模的技术，它将企业表示成一套不重叠的协作业务构建模块（组件），它提供了通过交互来实现业务需求的业务服务。它提供了其它业务分析方法（例如价值链或流程分解）没有提出的重要的观点。

在 CBM 中，业务组件是企业的部分逻辑视图，该企业是由资源、人、IT 知识资本和需要传递一些业务值的性能测试支持的。组件具有不连续的边界，由它提供的业务服务和它使用的业务服务来定义。类似于基于组件的开发方法中使用的软件组件概念，CBM 业务组件是黑盒：它的服务用户无需知道组件如何知道它是怎样实现的。这使得业务应用程序组件可以很好地更新或还原。此外，业务组件映射被用于组织列表视图中的业务组件，表的纵行代表业务资格（诸如商品、产品、开发或营销），表的横行代表责任级别，它表现了决策和业务活动的范围和意图。

目前，CBM 组件为一些已经开发的关键行业映射，一些已经被确定并组织成候选服务。对于零售业，创建初步的组件映射（表 1），没有很多细节或服务鉴定。本文的一个目的是使用更加具体的规范来扩展 CBM Retail Component Model，用于组件和它们的服务。此外，实行以模型为中心的解决方案利用 UML 和 Rational Rose 的功能来获取业务需求和业务流程及用例，并逐渐将它们转换成业务组件和服务。当然，本文我们更强调集成。

下表展示了 CBM 零售映射的当前版本：

表 1. CBM 零售映射

	销售及客户管理	产品	存储及通道	分配及入库	业务管理
规划	客户分段，客户关系策略，销售策略及规划	商品策略，销售规划，分类规划，产品开发（如私有标签），商标管理，定价策略，资源规划	多通道策略，存储及通道策略，存储设计和布局，通道设计和布局	分配、仓库、供应链策略；运输规划，供应者关系规划（物流）	法人策略，财政管理及规划，LOB 规划，位置策略
管理	客户行为建模，市场及竞争者的研究，客户满意度的衡量及管理，委托，呼叫中心，活动管理	价格/提升管理，存货管理，供应期限管理及定价，产品生命周期管理（product lifecycle management，PLM）	存储及通道的收益率，存储操作管理，事务管理，计划管理	供应者性能管理，内部物流，公司内部及外部物流，运输/车队管理，仓库管理	联合管理，业务性能报告，合法的常规命令，实际的资产及结构管理，风险管理，股票分类帐，人力资源（职业发展、培训和招聘）
执行	客户服务，诚实，客户交流，大规模销售及广告，目标营销，售后服务，客户库	分配，PO 和贸易资金管理，购买/来源，需求预测，主数据管理	补给，服务发送，价格变更，时间及出现，库存层，密室任务管理，失去防范，劳动力管理，POS 执行/现金管理，多通道呼叫中心	分配中心操作，衡量标准管理，返回及回收，产品跟踪，运输/车队操作	人力资源管理/薪水册，法人的审计，法人的账目（GL、AP、财政部等），销售审计，间接获得，存款操作，PR 及投资者关系，IT 系统及操作

服务模型的描述

什么是服务模型？
如何确定、设计及构造服务仍旧保持艺术形式。服务没有以标准的形状或大小实现，并且它们都承担着如我们前面所述的不同职责。依赖于利用那些服务的程度，可以在主要方面实现大量的标准化，例如：

• 应用程序体系结构
• 企业基础架构
• 全球的数据交换

服务模型被用于统一标准化的工作并提供系统的标准方法来描述服务及它们之间的关系。Thomas Erl 最初指定并提倡 XML & Web Services Integration Framework（XWIF），其中阐述了服务的主要概念，尤其业务服务、流程服务和许多其它公共有效的服务类型（面向服务的体系结构——集成 XML 和 Web 服务的领域指导——请见参考资料）。Ali Arsanjani 也讨论了被引入到 SOMA 中的分层的 SOA 模型，不仅是服务而且将它们关联的属性及关系形式化（请见参考资料）。我们依照解决方案并将它们扩展到某种水平，即将所有服务都建模并利用它们。

基于服务的集成
SOA 通过引入逻辑服务集成层（建立集成的公共基础）来扩展了传统的多层应用程序体系结构。一套标准程序接口被发布成表示层和业务层之间的服务，或一个业务（伙伴）与另一业务（另一伙伴）之间的服务。因此可以创建开放的共同操作的环境，它统一了异类的遗留平台并超出了任何个人应用程序的范围。本文重在应用 SOA 和面向服务的集成（service-oriented integration，SOI）方法和最佳实践来设计适用于 SoT 的 SOI 层。

设计以零售为中心的，基于服务的集成层
下面，我们描述了设计以零售为中心的、基于服务的集成层的步骤和流程，以通用的购买项目业务流程为例。特别地，我们使用该业务实例来阐述服务确定、设计和实现细节的步骤。

这些步骤表明我们如何从 Business Integration Modeler 中的 CBM 逻辑业务组件中获取候选服务，我们如何在 Rational Rose 中创建服务模型，以及我们如何使用 Business Integration Modeler 来发布业务流程文件，最终我们将这些文件引入到 WebSphere Studio Application Developer——集成版（Application Developer）中来生成 Web 服务描述语言（Web Services Description Language，WSDL）中的服务规范。我们连续地展示了这些步骤，即使现实中它们是试探性的，并且实际上是这样反复的。

1）领域分解
我们将 SoT 项目范围的业务领域分解成了功能范围的价值链。我们引导了并行的工作来确定并将业务流程（使用 Microsoft Visio）及用例（使用 Microsoft Word）建模。在那些工作中，我们也重新设计并确认了未被优化的 COTS POS 应用程序组件中的现有的实现的业务流程。

如前面所描述的一样，我们使用 CBM 零售业映射作为创建逻辑组件模型的起点，因为它提供了该套业务组件（遍及零售业的各领域）的第一个入口。基于业务流程及支持的用例，我们确定了与 SoT 相关的功能范围，如表 2 所述。这样的领域可以作为技术子系统实现的候选。

表 2 展示了与 SoT 相关的确定的 CBM 领域。

表 2. CBM 命中映射

	销售及客户管理	产品	存储及通道	分配及入库	业务管理
指导		商品和位置规划
控制		价格/提升管理，存货管理，订单管理，种类管理，产品生命周期管理	存储操作管理，事务管理，经营，计划管理	业务性能报告，人力资源管理（职业发展、培训等）
执行	售后支持，客户库，客户服务，诚实	主数据管理	补给/价格变更，时间及出现，产品生命周期管理，失去防范，POS 执行和现金管理	产品跟踪	存款操作

2）确定候选服务

业务流程建模
从业务流程建模的实践中，我们创建了相关的完整的（还可以被提炼）适用于 SoT 的业务流程，然后将它们引入到 Business Integration Modeler 中。我们进一步提炼那些流程以帮助确定候选服务。

流程分解
通过使用 Business Integration Modeler，多个业务流程的公共任务被结合并发布成全球的任务。对于业务流程的特定任务被声明成本地任务。一套公共的实现多个业务流程中可复用的业务功能的连续的任务被设计成子流程。

图 3 展示了流程、子流程及任务的等级关系：

图 3. 流程、子流程及任务之间的等级关系

图 4 展示了购买项目的业务流程模型：

图 4. 购买项目的业务流程模型

服务确定
我们确定了基于内部组件交互的候选服务，我们从业务流程中获得了这样的交互。基于所选的 CBM 零售业务组件，我们首先通过组件将业务任务分组，然后确定内部组件的交互模式。这种内部组件的交互最初在 Rational Rose 中使用 UML 时序图将其建模。

为了最终得出服务规范（在 WSDL 中适用的），将这种内部组件的交互建模得更好的方式是有效地使用 Business Integration Modeler。在回顾了产品特征之后，我们发现实现该功能的一种创新的方法：我们可以使用组织单元结构来表示组件，并且我们可以使用这种组织单元的出入流作为天然的服务候选。以这种方式，将任务分配给特定的组织单元依照它的核心业务功能，并且任何通过组织单元传递的信息都代表内部组件的交互并且可以作为候选服务。

图 5 通过组织单元以泳道视图展示了购买项目的业务流程模型。

图 5. 购买项目业务流程模型的泳道视图

从泳道视图中可以明显看出下列是可以被发布的用于购买项目业务流程的两个候选服务：

• 在 Web 上找到存货——由 Web Store 组织单元发布
• 在商店中找到存货——由 Inventory Management 组织单元发布

为了确定数据服务，我们进一步分析了核心 POS 解决方案和已支持的或即将被支持的遗留系统之间的数据流。此外，设计数据服务使它们能够被访问以满足应用程序的大多数（或所有的）数据需求。这里有 SoT 解决方案所需的三种类型的数据服务：

• 支持内部组件交互的数据服务
• 支持将 POS 事务数据上传到遗留系统（私有格式）的数据服务
• 从遗留系统中下载公共支持的数据（包括商品、价格和财政等）的数据服务

我们也提取了通用的安全及工具服务来帮助内部组件的交互。

然后，我们列出了在这一步中确定的服务并将它们映射到文档中。图 6 展示了购买项目的候选服务清单。

图 6. 候选服务清单

3）业务流程实现
在这一步中，我们使用已确定的一套服务来说明可以通过应用程序组件和集成服务来实现所有需要的业务流程（请参阅图 14 的购买项目的服务组合视图。

4）服务分配及组件规范
如先前所述，我们通过将流程分解合并及对现有系统的分析来确定所有需要的服务。在这一步中，我们确保所有已确定的服务都有一个起点，它们都可以被业务流程及支持的组件追踪到。

在这个过程中，我们进一步提炼并重构了候选服务，按照它们与逻辑业务组件的调整。最终，我们确定了业务应用程序服务的有限集，并将它们映射到提供这些服务的实现和管理的业务组件中。随后，我们扩展了逻辑组件的规范使其包含分配的服务。

图 7. 组件的服务分配

在这一阶段，我们开发了实际平台、产品和具备独立供应商的以零售为中心的由逻辑 CBM 功能组件（可以被看作 CBM 零售组件模型的扩展）分类的服务的清单。

5）构造企业组件
在这一步中，我们分析并构建了所有选定的 COTS POS 应用程序组件、客户端遗留应用程序和数据系统，从当前或今后系统的上下文中启动并保持与所选的 CBM 逻辑组件的协调。我们称那些技术组件为子系统。技术子系统是现有的客户端企业系统或遗留系统，由供应商的产品或伙伴系统、或新确定的用于消除 COTS 产品性能与客户端需求之间的障碍的应用程序封装。该确定的 CBM 组件被映射到那些基于功能匹配的技术子系统中。

此外，我们将应用程序集成模式（流程集成及协作）应用到构建集成组件中。我们采用了企业服务总线（Enterprise Service Bus，ESB）模式来为所有应用程序提供统一的集成层。图 8 描述了高级集成系统的视图。

图 8. 体系结构：系统视图

6）确定及构建技术子系统
如同我们前面所讨论的一样，SoT 的关键决策之一是使用 COTS POS 应用程序组件并将对这些 COTS 产品和客户端遗留系统的更改降到最小。基于一套共同开发的选择标准，我们必须选择一些 COTS 产品。此外，为了满足标准业务的需求，我们必须定制 COTS 产品并设计开发一些新的应用程序组件。

在这一步中，我们采用从下至上的解决方案来分析如何构建 COTS 产品、新的应用程序组件和客户端遗留系统，来帮助逻辑组件和服务的设计向物理实现的转变。为了简化，我们使用现有的 COTS 应用程序组件作为供应商封装的解决方案和从新的应用程序中创建的新技术子系统。图 9 展示了我们确定的技术子系统。

图 9. 技术子系统确定

7）将功能组件映射到技术子系统中
在这一步中，我们将每个逻辑业务组件都映射到体系结构中的技术子系统中。下面是为了达到该目的而设计的电子表格的实例：

图 10. 技术组件的服务分配

为了扩展 CBM，我们创建了下面的映射电子表格来说明 CBM 逻辑零售组件如何能被映射到确定的技术子系统中。

图 11. 将 CBM 逻辑零售组件映射到确定的技术子系统中

8）创建服务模型
服务模型是我们的基于服务的集成的核心。分析和设计执行下面操作的构件是非常有用的：

• 确定需要被发布的服务。
• 指定服务提供者和服务客户之间的合约。
• 指定关系、层次（如果存在的话），及其它服务属性。
• 指定实现服务所需的组件。

下面的部分简要地描述了如何将我们的创新的服务模型建模并归档。

服务组合：服务清单
该部分以业务功能或业务区域的年月日的次序列出了所有前面确定的服务。

a）服务映射（组合）
服务映射包含我们使用从上到下和从下到上的分析而确定的服务的清单。这里，我们列举了前面步骤中确定的候选服务，以及它们的用法和调用关系。我们创建它来可视化地描述核心业务组件或技术子系统提供及使用的所有服务。图 12 展示了为 SoT 所开发的一个版本。

图 12. 服务映射

b）服务层次
服务层次将服务分类。我们将未分类的服务的候选清单依照业务服务路线、多路业务服务和企业服务将它们组织在一起。我们使用服务层次来说明服务是否可以调用其它服务，它是否是其它现有服务的简单组合。

c）服务发布决策
我们需要确定发布哪些服务，我们可以使用服务最终测试（回答问题：这些服务是否与业务相关以及业务是否要在企业周边发布它们？）来完成。最终测试包括：

• 业务校准：业务是否同意发布服务？子流程和高级业务用例是服务发布的优秀候选。
• 透明度：服务提供者对服务客户是否透明？
• 服务粒度：服务是否以适当的粒度水平来发布？服务不应当发布技术工具除非技术工具对服务客户来说是有价值的。

d）服务流
该部分描述了如何使用确定的服务来将各种应用程序组件绑定在一起以完成业务流程的特定需求。下面的 UML 时序图展示了内部组件的服务与实现购买项目的业务流程的交互。

图 13. 服务流

e）服务组成
服务组成提供了服务的动态视图。它展示了我们如何将这些服务编排进支持业务功能的组合服务中。如服务流部分中所示，我们也设计了组合服务，购买项目，它由许多小的服务组成，如Authenticate、FindInventory 等等，如图 14 中所描述的。

图 14. 服务组合

您可以使用 Application Developer 来执行服务编排（关注该系列文章的第二部分，将讨论如何使用 Business Integration Modeler 和支持的开发工具来创建基于服务的集成层）。

f）服务相关性
这里有两种服务相关性：

• 前提条件的相关性：在开始执行当前调用之前另一服务调用必须已经成功地执行了。例如，找到存货应当发生在存储存货之前；
• 处理相关性：另一服务调用需要成功地执行当前服务。

g）其它服务属性
其它服务属性包括服务级协议（如性能需求）、能力和安全。在这个阶段，我们详述并实验了如何使那些属性更合理且可实现。

9）服务规范及实现
当考虑如何实现服务时，我们需考虑：

• 服务细节
• 服务的数据输入及输出
• 服务是同步的还是异步的
• 协议需求（XML/HTTP、SOAL/HTTP、JMS、XML/MQ 等等）
• 服务组合
• 对于服务无功能需求。

我们也需要确定如何使用遗留和现有的企业功能，通过询问诸如“我们要不要在遗留功能上放置包装器？”或“我们需要为企业服务更改发布的接口吗？”之类的问题。在回答完这样的问题之后，就能做出服务实现决策并在服务模型中归档。

10）向 Application Developer 输出服务模型
最后，我们将来源于 Business Integration Modeler 的模型作为 Business Process Execution Language（BPEL）和 WSDL 输出，然后我们将它们引入 Application Developer 中。然后，我们进一步地编辑、增强、开发 Application Developer 中的流程编排。

结束语
作者提出了以模型为中心的解决方案，用于分析和设计基于服务的适用于集成包解决方案组件和遗留系统的集成层。他们使用 CBM 零售映射作为逻辑组件模型的启动，过滤掉与 SoT 的当前范围无关的内容。使用业务分析组开发的可用业务流程及用例文档作为主要输入，它们使用 WebSphere Business Integration Modeler 来为内部组件的交互建模，并将每个交互都确定成那些逻辑组件中的候选业务服务。他们分析输入输出消息和数据需求，并指导对每个服务的复杂性的最初的评估。他们将那些服务构建到逻辑服务模型中，他们进一步扩大逻辑服务模型使其包括公共业务和工具服务、数据和安全服务。他们将所选的逻辑业务组件映射到确定的包应用程序组件（子系统）中，并合并逻辑服务到那些子系统中。