指导 商品和位置规划
控制 价格/提升管理，存货管理，订单管理，种类管理，产品生命周期管理 存储操作管理，事务管理，经营，计划管理 业务性能报告，人力资源管理（职业发展、培训等）
执行 售后支持，客户库，客户服务，诚实 主数据管理 补给/价格变更，时间及出现，产品生命周期管理，失去防范，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 来为内部组件的交互建模，并将每个交互都确定成那些逻辑组件中的候选业务服务。他们分析输入输出消息和数据需求，并指导对每个服务的复杂性的最初的评估。他们将那些服务构建到逻辑服务模型中，他们进一步扩大逻辑服务模型使其包括公共业务和工具服务、数据和安全服务。他们将所选的逻辑业务组件映射到确定的包应用程序组件（子系统）中，并合并逻辑服务到那些子系统中。
参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文。
在文章 "面向服务的建模和体系结构：如何确定、指定和实现您的 SOA 的服务"中发现分析和设计 SOA 所需的关键活动（developerWorks，2004 年 11 月）。
着手于应用程序开发工具及 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的中间件产品。您可以免费下载产品的测试版，或选择 developerWorks 免费的 Software Evaluation Kit 的 Linux® 或 Windows® 版本。
获得由 Thomas Erl 所著的书籍面向服务的体系结构：集成 XML 和 Web 服务的领域指导（Prentice Hall，2004）。
阅读 IBM Redbook 中有关 SOA 和 Web 服务的内容——由 M. Endrei、J. Ang、A. Arsanjani、S. Chua、P. Comte、P. Krogdahl、M. Luo 和 T. Newling 所著的模式：面向服务的体系结构和 Web 服务（IBM 印刷，2004 年 4 月）。
了解更多关于企业系统中基于组件的开发：应用选择透视图，在 P. Allen 和 S. Frost 所著的书中（Cambridge 剑桥大学印刷，1998）。
了解更多关于业务建模的内容，在书使用工作中的 Uml 业务模式的业务建模：工作中的业务模式中（OMG 印刷，2000）。
通过参与 developerWorks blogs 加入 developerWorks 社区。
IBM developerWorks 小组在全球了主持数百次技术简报，您可以免费参加。
想获取更多信息吗？developerWorks SOA 和 Web 服务专区有成百上千篇信息文章，以及关于如何开发 Web 服务应用程序的入门级、中级和高级教程。
作者简介
Min Luo 在 IT 行业有超过 15 年的经验，对于管理软件应用程序的设计和开发的整个生命周期有 8 年多的经验。他完全了解业务上的各种技术的作用，并且知道如何有效地将它们应用于解决大规模且复杂的实际问题。他是面向对象的分析和设计、基础组件和面向服务的计算和改进的开发方法的早期采用者、提倡者及导师。他成功地设计并实现了运输、财政、制造业和大规模的政府社会福利事业。他也具备设计和开发与在线的分析处理和数据采集相集成的数据仓库、各种操作的应用程序的研究和管理科学技术的专门技能。在 2000 年进入 IBM 之前，Luo 博士作为 Fortune 400 的两个公司的高级经理和主管。自从 1997 年他作为一些大学的助理研究员。他拥有计算机科学的 B.S.（1982）和 M.S.（1987）以及电子计算机工程的 Ph.D.（1992）。
Prakash Mall 是 IBM Global Services Enterprise Architecture and Technology Center of Excellence 的咨询 IT 架构师。他在应用程序架构和开发、与广泛发布的 Java 和基于 J2EE 的应用程序的整合解决方案、中间件技术和多层体系结构系统上有超过 8 年的经验。他与财政和零售业有广泛的接触。他持有工程学的学士学位，专攻电子和通信。
Diptiman Dasgupta 是 IBM Global Services Enterprise Architecture and Technology Center of Excellence 的咨询 IT 架构师。他在应用程序开发、产品开发以及用于信息技术业的应用程序整合和广泛发布的 Java 和基于 J2EE 的应用程序和诸如 CORBA 的中间件技术及诸如 WebSphere ICS 的集成产品的研究领域有将近 7 年的经验。他在计算机科学及信息技术方面拥有硕士学位，并且在电子工程方面拥有工程学士学位。他已经撰写并发布了两本有关 Web Application 框架和 Data Access Object Layer 框架的技术白皮书。
Rajesh Nachaloor 是 IBM Global Services Enterprise Architecture and Technology Center of Excellence 的咨询 IT 架构师。他在 IT 业有 10 多年的经验。他主要参与了应用程序体系结构和与 Java 和基于 J2EE 的应用程序及电子商务应用程序的发布相集成的解决方案。他获得了 MSc（技术）——BITS，Pilani 的信息系统学位。
Julian C. Petriuc 是 IBM Global Services 组织中的认证咨询 IT 架构师。在 IT 业他有超过 26 年的经验。在进入 IBM Global Services 之前，Petriuc 先生是 25 亿 USD 公司的 IT 部门的首席架构师，领导企业体系结构开发组（应用程序体系结构、技术及信息体系结构）。在大规模合作信息系统中他有非常高的知名度，由于他具有广泛丰富的职业知识和企业级的经验。Petriuc 先生在企业 IT 体系结构（技术、应用程序或信息）的设计和实现、战略规划、企业应用程序集成（EAI）和中间件、电子商务系统和集成、应用程序开发、企业系统管理和项目管理方面有丰富的专门技术。他在美国和罗马尼亚实施他的专门技能。
Liang-Jie（LJ） Zhang 是 IBM T.J. Watson Research Center 的一位研究员兼 Services Computing PIC 的主席。他是业务信息研究小组的成员，主要研究用于行业解决方案和业务性能管理服务服务中的 SOA 和 Web 服务。他在电子商务、Web 服务、网格计算、宽带媒体、数据管理和信息工具领域有超过 30 项专利应用程序，并且已经在期刊上、书中和会议学报中发表了超过 80 篇技术文章。
Richard Baca 着重于帮助零售、食物服务和消费产品客户通过策略、供应链和需求管理解决方案来提高业务性能。在他 18 年的工作中，他已经进行了大量的业务转换活动，包括策略规划、客户应用程序开发和包实现。在他的许多项目中，应用了 IBM Global Services Methodology 并且承担了许多主要角色，如项目经理、业务流程和再工程的领导及变动管理的顾问。Baca 先生也开发了许多关键活动的专门技术，包括零售存储系统、供应链管理系统（SCM）、系统测试、客户应用程序开发及包的选择。
自从 1972 年 Jack Ehrhardt 已经在 US Navy、US National Oceanic 和 Atmospheric Administration、Nixdorf Computer AG、Digital Video Express LP 和 Philips Semiconductors 拥有了软件和硬件开发领导的职位。他实现了商业上配置的嵌入式 JVM，对一些主要的计算机安全标准作出了贡献，并且在数字内容保护及数字视频工程领域拥有六项专利。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
