Prakash Mall （mprakash@in.ibm.com） , 咨询 IT 架构师, IBM Global Services
Diptiman Dasgupta （ddasgupt@in.ibm.com） , 咨询 IT 架构师, IBM Global Services
Rajesh Nachaloor （rnachalo@in.ibm.com） , 咨询 IT 架构师, IBM Global Services
Julian C. Petriuc （jpetriuc@us.ibm.com） , 认证咨询 IT 架构师, IBM Global Services
Liang-Jie Zhang （zhanglj@us.ibm.com） , 总架构师，行业标准, IBM Software Group
Richard Baca （rbaca@us.ibm.com） , 管理顾问, 分配实践, IBM Global Services
Jack Ehrhardt （Jack_Ehrhardt@circuitcity.com） , 系统架构师——零售存储操作, Circuit City Stores
2005 年 3 月
从最近多个百万美元的项目（包括服务、硬件、软件和托管）的实施框架中发现创新的解决方案框架，将其用于能够创建更有效基础架构的最大的电子零售链之一。该框架有助于线形存储销售并支持办公操作，具备中央办公功能，劳动力管理、订单管理和库存管理。项目开发组及本文作者采用了以模型为中心的解决方案来分析并设计用于集成包解决方案组件和遗留系统中的面向服务的集成层。此外，他们设计并开发了轻量级的企业服务总线（Enterprise Service Bus，ESB）来实现基于服务的集成。解决方案提供者使用此套标准服务规范通过 ESB 提供或使用这种服务。提出的这个解决方案框架提供了以零售业为中心、技术和平台独立的、基于服务的整合层（最终是一个以零售为中心的 ESB 实现），其他零售商可以无需费力地将其采用。本文（该系列文章中的第一部分）重在创建用于集成的以零售为中心的服务模型创新解决方案。
引言
六年多的时间里，我们的客户试着将他们的超过 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 命中映射
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/