案例研究：SOA 零售业务模式

 

本文中的案例研究重点是零售行业部门，以及组织如何使用 SOA 构造解决方案，以改进周转时间、流程效率、客户满意度，并加快上市速度和降低成本。

本文重点关注零售行业的两个方面：

• 多渠道零售（从在线到商店）
• 新产品引入

零售行业中的 JKHL

JKHLE 是一家虚构的公司，正在寻求扩大其零售业务。过去，JKHLE 在零售行业的长处一直是作为供应商。在 JKHLE 作为集团企业快速扩张的过程中，JKHLE 计划利用其强大的零售根基作为零售商迅速发展壮大。

我们在本文中介绍的案例研究包括以下关键人员和角色：

• Thomas Arnold，JKHLE 的首席运行官
• Sandy Osbourne-Archer，JKHLE 的首席技术架构师
• Julia Wang，JKHLE 的营销负责人
• Charles Hunt，JKHLE 的电子商务负责人
• Maria Gomez，JKHLE 的销售副总裁
• Jonathan Spencer，IBM 的零售行业架构师

JKHLE 的业务目标和需求

在与 Sandy Osbourne-Archer 的对话中，JKHLE 的首席运营官 Thomas Arnold列出了公司的零售业务部门的目标和业务需求。Thomas 告诉 Sandy，JKHLE希望通过在最低风险的情况下取得快速增长，从而成为该行业最赚钱的零售商。

Thomas 希望零售部门通过以下方式在竞争者面前取得竞争优势：

• 交付独特、无缝、跨渠道的体验。
• 成为提供符合客户需要的流行产品的领跑者。

JKHLE 已经开了一家在线网络商店和 900 家零售商店。它正在寻求扩展在线商店的功能，以及解决 JKHLE 在产品主数据管理方面遇到的麻烦问题。

Sandy 提醒 Thomas，IBM 最近使用 SOA 方法重新构造了 JKHLE 的帐户开立流程。重新设计的帐户开立流程已证明取得了极大的成功，她建议 Thomas 利用 IBM 帮助 JKHLE 实现在零售行业的目标。

她告诉 Thomas，IBM 拥有 30 年的零售行业经验，并拥有 6000 名顾问与客户合作从事零售解决方案。

Thomas 决定聘请 IBM 的零售行业架构师 Jonathan Spencer。他为 Jonathan 分派了任务，要求他分析 JKHLE 的现有零售业务流程并提供业务转换建议。

标识 JKHLE 的公司活动

IBM 的零售行业架构师 Jonathan Spencer 与 JKHLE 进行了会谈，以讨论 JKHLE 针对零售业务的公司活动。

组件业务建模

Jonathan建议 JKHLE 与他和他在 IBM的团队合作制定战略和路线图，以将需求合理化、标识难点和依赖关系，以及最终基于公司战略确定活动的优先级。IBM在此类工作中使用的一个重要工具是组件业务建模（Component Business Modeling，CBM），它使 IBM 能够考虑对 IT环境不可知的零售商功能，并确定要处理的领域。

使用 CBM，Jonathan 帮助 JKHLE 确定了每个组件对业务的贡献，并基于每个特定组件的成本对投资回报进行了评估。了解与每个组件关联的业务价值使得设定转换优先级和规划公司活动变得更加容易。

使用此过程，JKHLE 能够确定其实现业务目标所需要的主要功能：

• 跨渠道共享一致的产品信息的能力。
• 快速和准确地整合新产品并将这些产品与客户概要集成在一起的能力（例如，基于客户购买模式创建产品建议）。
• 客户在任何时候购买产品并将产品送达客户手中或让客户在商店中领取产品的能力。
• 销售与产品关联的服务（例如安装服务）并跨渠道集成诸如礼品登记等服务的能力。

JKHLE 的公司活动

完成 CBM 以后，IBM 帮助 JKHLE 确定了两个主要公司活动：

• 从在线到商店的多渠道活动
• 产品信息管理、新产品引入活动

从在线到商店的多渠道活动

此活动处理客户对跨多种渠道（Web、零售商店和商品目录）的一致体验的预期。

在当今的零售行业中，购物者预期跨渠道实现无缝的转换。JKHLE 拥有 Web上、零售商店中和商品目录中的销售渠道。零售行业还正在往以下方向发展，即购物者在零售商店之外发起交易（例如使用网站或移动设备），而在商店中完成交易。根据 Aberdeen Group 的调查，84% 的零售商通过多个渠道从事销售，69% 的零售商计划将当前的电子商务系统替换为跨渠道平台。

JKHLE 首席运营官 Thomas Arnold 解释了为什么此活动非常重要：

当今 90% 的客户在多个网站上调查产品。利用多渠道运营来处理现有客户基于 Web 的需要和吸引新客户，这对我们的业务来说至关重要。

基于客户调查和与 JKHLE 进行的讨论，Jonathan 建议 JKHLE 将重点放在以下从在线到商店的用例上：

• 客户在线下订单，然后到零售商店为订单付款并领取商品。
• 客户在线下订单，所购商品将送达他们手中。客户可以在零售商店退还或更换所购商品。

产品信息管理、新产品引入活动

此活动的重点是加速 JKHLE的新产品引入过程，以处理竞争压力、成本挑战和提高的客户要求。产品信息管理关注如何集中管理有关产品的信息，并将重点放在通过一个或多个销售渠道推广或销售产品所需要的数据上。集中的产品数据集可用于向多种输出媒介提供一致、准确和最新的信息，例如网站、印刷商品目录、ERP系统，以及到交易合作伙伴的电子数据馈送。新产品引入重点关注与新产品的推出相关联的产品信息管理（例如，产品数据、供应商数据和订购单数据的管理）。

Thomas Arnold 对此活动的重要性进行了解释：

JKHLE 拥有 5 名持续地定义和管理产品数据的全职员工。这是一个手动和非常容易出错的流程——我们的产品数据和属性的不准确性在去年导致了 500 万美元的销售损失。此手动流程还非常慢。要花太长的时间才能使我们的新产品上市。

JKHLE 的营销负责人 Julia Wang 补充说：

我们无法智能地分析业务智能和分析数据，因为几个重要的产品属性要么缺乏，要么不可见。例如，在去年的橄榄球超级联赛中，我们销售了大量的餐巾纸，但是我们无法判断它们是单层还是双层的，因为该属性没有得到一致地维护。我们面对的另一个问题与错误的产品数据有关。客户基于我们网站上显示的错误产品描述在线购买产品。但是当他们在家收到产品时，由于产品数据不准确，客户的预期没有得到满足，从而导致非常高的产品退还率。

回页首

从在线到商店的实现

本部分将讨论 SOA 零售业务模式的从在线到商店的实现。JKHLE 使用此实现来处理他们从在线到商店的多渠道销售活动。

观察现有的业务

通过与重要的 JKHLE 人员进行一系列访谈，IBM 零售行业架构师 Jonathan Spencer 得出了以下观察结论：

• 订单

客户可以使用多种方法下订单。这些方法引入了相对于标准下单途径的多种差异。例如，客户可以下订单，并在领取产品前将订单保留 1 天、1 周 或 1个月，具体取决于他们的订购途径和所订购的产品。客户在 JKHLE的零售商店位置下订单的时候，将严重依赖客户的谨慎处理（例如，客户可能必须向多个商店打电话以确定某个产品的可用性）。

• 客户

客户群中存在着显著的多样性。有些客户更喜欢在 JKHLE 的零售商店购物，而其他客户则更喜欢网上购物。许多客户使用多种渠道下订单，并且他们不理解为什么库存、价格和服务在这些渠道之间是不同的。

• 系统

支持各种渠道的 IT 系统被设计为单独的系统。例如，有些渠道使用现有的应用程序，而有些则使用基于 Web 的较新技术。这些渠道没有很好地集成，意味着客户和产品数据在渠道之间没有实现同步。

每个渠道还具有自己的一组流程。例如，用于从 Web 渠道购买的商品的退还流程与用于从零售商店渠道购买的商品的退还流程不同。

基于这些观察结果，Jonathan 记下了以下重要发现：

• 现有的系统和流程不再有效地支持业务需求。当前系统是围绕单个渠道中的订单而优化的。
• 现有的系统和流程正在日益增加组织的负担。例如，维护复杂的现有应用程序的代价日益昂贵。
• 业务受到多渠道订单管理问题的约束。使用新解决方案响应不断变化的市场条件的难题正在显著影响总销售收入的增长。此外，客户对商店存货描述或商店交货的信心缺乏导致订单被放弃或转换到其他竞争零售商。

业务流程建模

基于 Jonathan 的观察结果和主要发现，JKHLE 同意它需要更改其业务流程。通过一系列进一步的访谈，Jonathan 能够对现有的从在线到商店业务流程做文档记录，并提出有关如何改进流程设计的建议。

当前业务流程分析

当前，现有的 JKHLE 从在线到商店流程包含以下阶段：

1. 客户在线购物并标识他们希望购买的产品。

2. 然后客户选择是在线购买并送货上门，还是在线购买并在他们选择的物理商店领取所购商品。

• 如果客户选择送货上门，他们将输入送货和付款详细信息，并接收确认电子邮件。所购商品将尽快从配送中心送达客户手中。
• 如果客户选择在零售商店领取所购物品，则必须首先确定所在区域的商店位置（通过提供邮政编码），然后手动给每家商店打电话以确定订单所购商品是否有存货。当客户在商店下订单时，零售员工将从货架取下订单所购商品，并为商品做相关准备工作以便客户取走。

当客户到达零售商店位置时，他们将使用销售点系统支付订单款项。

Jonathan 确定了这些流程阶段的许多挑战：

• 当前流程仅为单个渠道服务。它仅知道以前曾经使用过 Web 渠道购物的客户。通过其他渠道所下订单的客户偏好、帐户信息或帐户状态对 Web 渠道不可用，反之亦然。
• 可在线购买和可在零售商店购买的产品之间存在太多的不一致。例如：

• 有些产品可在线购买，但是零售商店却不销售。
• 完全相同的产品在在线和零售商店具有不同的定价。
• 不存在实时的商店存货清单，因此客户可能尝试订购已经脱销的商品。

• 客户在线下订单并在零售商店领取所购商品的选项遇到了许多问题，其中包括：

• 客户没有接收到关于所购商品已经可以领取的确认函。
• 该流程依赖于员工能够接听电话、接受订单并定位所需的商品以满足该订单。这些电话订单常常容易出错。
• 此多渠道流程不存在监视功能。例如，JKHLE 无法获得有关某个特定产品的商品退还百分比的信息。

• 客户在到达商店并在销售点系统上付款之前，没有对订单做出经济上的承诺，这常常导致订单被放弃。

当前从在线到商店流程的缺点主要可归因于该流程需要随时间推移而发展，以支持不断变化的业务需求。JKHLE 很清楚地了解该流程，但它是一个手动和劳动力密集型的流程。

建议的业务流程设计

Jonathan 与他的 IBM 顾问团队和 JKHLE 参与者合作设计了改进的从在线到商店业务流程。他解释了他和他的 IBM 团队用于重新设计从在线到商店流程的主要设计原则：

• 自动化的流程要比手动流程更加高效。自动化的流程降低了劳动力需求，从而减少了成本。自动化还可以通过提供警报和见解促进工作团队之间的协作，并使得经理能够有效地查看、测量和主动地管理流程。
• 冗余的流程应该废止，相似的流程应该合并到完全集成的流程中。
• 通过在流程中整合智能、监视和警报，可以改进总体流程质量。
• 流程的设计应该集成管理远景、行业最佳实践、最佳品种的流程、行业基准、关键性能指标监视，以及行业主题专家的专业技术。

基于这些重要设计原则，Jonathan 描述了建议对从在线到商店业务流程的每个阶段做出的改进：

下订单

用于下订单的流程本质上保持不变。但是，要使此流程与从在线到商店流程的其余部分高效地协作，Jonathan 建议合并所有的订单录入和处理技术，以便通过单个跨越 Web、零售商店和产品目录渠道的流程处理所有的订单。较旧的技术应该逐步淘汰。

做出这些更改可以为 JKHLE 带来以下益处：

• 将向客户提供更有用的信息。
• JKHLE 将实现更低的维护成本（只需维护更少的技术）
• 跨所有渠道的服务和流程执行一致性。

处理订单

订单的处理应该进行相当多的更改。从在线到商店业务流程应该提供商店存货信息，并提供预留存货中的商品的功能。此外，应该向客户发送自动化的电子邮件通知，向他们提供其订单的状态。

该流程还应该提供实时的潜在反常分析，并且应该在遇到反常的时候实时生成警报。例如，商店存货可能永远无法完全准确。某个产品可能显示为可在商店领取，但在该零售商店的另一个客户可能正在从货架上取下该产品，打算购买该产品。如果客户订购了在商店中已经售完的商品，则可以生成警报，并通知 Web客户该产品在他或她计划领取所购商品的零售位置暂时脱销。

做出这些更改可以为 JKHLE 带来以下益处：

• 实时的商店存货可用性信息
• 实时的订单状态监视

领取所购商品

建议的业务流程需要在客户已领取所购商品时提供存货更新。它还应该更新客户偏好，并提供向客户进行交叉销售和提升销售其他产品的机会。

做出这些更改可以为 JKHLE 带来以下益处：

• 客户将绕过商店结帐流程，并直接从在线订货处结算订单，因为他们已经在在线下订单时支付了款项，从而提高了客户满意度。
• 现在可以准确跟踪 JKHLE 的存货。

总而言之，Jonathan表示建议的业务流程设计将简化用户在网站上的交互。例如，当前零售商店存货信息将在下订单时可用，因此客户不必向商店打电话咨询商品的可用性。新流程还将提供订单、状态和发票的实时可见性。这种实时的信息可见性潜移默化地灌输在业务流程管理功能中，以监视流程执行并促进持续的业务流程改进。

服务建模

在执行业务流程建模之后，下一个任务是详细描述将构成建议的业务流程的服务。Jonathan 建议 JKHLE 使用 IBM推出的面向服务的建模和体系架构（service-oriented modeling andarchitecture，SOMA）方法来标识这些服务。

SOMA 提供了一种构建 SOA 的方法，这样构建的 SOA 与业务目标保持一致，并通过服务将业务流程与基础应用程序直接绑定在一起。SOMA 的过程包括三个一般步骤（图 1）：

• 标识
• 规范
• 服务、组件和流的实现

图 1. 面向服务的建模和体系架构 (SOMA)

Jonathan 解释了 SOMA 的服务标识步骤如何由三种技术组成，这些技术可以帮助 JKHLE 标识用于从在线到商店业务流程的服务：

• 领域分解

这是从在线到商店业务流程的自顶向下视图。它包括流程分解，其中将流程细分为子流程和高级业务用例。例如，可以将从在线到商店业务流程分解为下订单、处理订单和结算订单子流程。每个子流程又可以进行进一步的分解，最终产生一系列业务用例（例如，创建购物车和处理付款）。这些业务用例通常是业务服务的很好候选者。

• 现有系统分析

与领域分解相反，这是一种自底向上的方法。其中对现有系统进行分析，以确定将它们包括在从在线到商店业务流程中的适合性。例如，JKHLE 可以分析由 IBM WebSphere®Commerce提供的现有服务，以确定其中是否有任何服务满足新的从在线到商店流程的需要。通常，与创建新的资产相比较，重用现有的系统和资产可以提供较低成本的解决方案来实现服务功能。

• 目标-服务建模

这种中间相遇方法验证领域分解和现有系统分析方法未捕获到的其他服务。在此阶段中，将基于目标和指标标识业务服务。例如，JKHLE可以为从在线到商店流程定义三个目标：无缝的客户体验、提高客户满意度和以客户为中心的业务模型。可以在这些目标之下对业务服务进行标识和分组。

注意：有关应用 SOMA 的更多信息，请参阅位于以下地址的 developerWorks® 文章“基于服务的建模和架构”：http://www.ibm.com/developerworks/cn/webservices/ws-soa-design1/

现有体系架构

在对现有的业务流程建模、定义改进的业务流程和标识业务服务之后，Jonathan 需要全面了解当前存在的技术体系架构（现有体系架构）。

电子商务负责人 Charles Hunt 对该体系架构进行了描述。他告诉Jonathan，当前的体系架构包括系统之间的许多点对点连接。信息存储在竖井中，需要夜间的批处理来执行数据库之间的同步，因此很难信赖信息的准确性和质量。在此体系架构中，获得实时的业务和 IT 操作指标也充满了挑战。

Charles 抱怨说，不同渠道之间的客户数据、存货和订单管理系统没有集成，并且技术基础结构不灵活，使其难以更改和适应变化。

图 2 显示了 Charles Hunt 所描绘的现有体系架构。

图 2. 现有体系架构

SOA 原子模式

来自 IBM 的零售行业架构师 Jonathan Spencer 告诉电子商务负责人 Charles Hunt，定义满足 JKHLE需要的体系架构的理想方法是将解决方案细分为 SOA 原子模式。这些 SOA 原子模式可以简化从 SOA 的角度对总体解决方案的理解。

应用 SOA 原子模式和最佳实践使得 JKHLE 更容易了解解决方案的每个部分的影响，并帮助 JKHLE 分阶段采用该解决方案。

表 1 显示了 Jonathan 向 JKHLE 建议的 SOA 原子模式，以及与这些模式相关的 SOA 入口点或规程。

表 1. 用于从在线到商店体系架构的 SOA 原子模式
SOA 入口点/规程适用的 SOA 原子模式信息入口点合并连接入口点内部连接
ESB 联合流程入口点流程自动化
业务活动监视SOA 设计规程用于服务设计的 SOMASOA 安全性、治理和管理规程端到端服务管理
服务安全性
SOA 治理

Jonathan 描述了每个 SOA 原子模式旨在解决的技术问题、每个 SOA 原子模式如何应用于 JKHLE，以及通过采用该模式所带来的业务价值。

注意：在下面的部分中，每个 SOA 原子模式描述 JKHLE 面对的单个技术问题示例，然后描述如何应用 SOA 原子模式来解决该问题。在许多情况下，SOA 原子模式实际上可以帮助 JKHLE 解决多个技术问题。

这些 SOA 原子模式代表用于实现从在线到商店解决方案的路线图。通过应用所有这些 SOA 原子模式，JKHLE 采用了一个利用许多 SOA概念的参考体系架构（请参见第 23页上的“预期参考体系架构”）。采用类似解决方案的组织可以检查这些模式，并根据他们的特定环境选择适用的模式。我们在本文中描述的体系架构所演示的案例中，该零售商是相当高级的 SOA 采用者。

合并模式的应用

合并模式讨论如何集成广泛来源的数据，对于要求高数据可用性、高级别并发访问、高度可伸缩性和高性能的使用者来说，这些数据是高度异构的。

技术问题

JKHLE 的源信息分布在多个异构和自主的系统中（例如商务、销售和供应链数据库）。此源信息以不一致或不完整的格式存在。

JKHLE 如何应用此模式

从多个不同来源收集数据（例如商业数据库和销售数据库）。将此数据合并到公司数据仓库数据库中以便分析。

JKHLE 按如图 3 所示应用此 SOA 原子模式。

图 3. 合并模式

采用此模式的业务价值

通过采用合并模式，JKHLE 可以得益于拥有及时、准确的数据的优点，他们可以信赖这些数据来做出决策。例如，可以使用公司数据仓库中的合并数据来计算销售收入和现金流。

进一步的信息：请参考案例研究：作为服务的信息 SOA 场景。

内部连接模式的应用

内部连接模式描述多个内部客户端如何访问组织中的服务。例如，可以使用此 SOA 原子模式描述组织的远程办公室如何使用 Web 服务标准访问总部系统。

技术问题

诸如销售、供应链和商务系统等核心 JKHLE 零售系统之间的点对点连接导致无法灵活地更改当前系统和添加新系统。JKHLE需要在从在线到商店渠道之间支持多种协议和消息格式。此外，如果到主服务的请求失败，JKHLE 需要主服务地址和备份服务地址之间的基本路由功能。

JKHLE 如何应用此模式

JKHLE向从在线到商店实现添加了一个企业服务总线（enterprise service bus，ESB）。该 ESB在公司总部引入，并使用开放标准提供松散耦合、基本路由和灵活的连接。该 ESB提供了对应用程序之间的多种开放协议和消息格式的支持。这些应用程序包括付款处理、销售和供应链应用程序。JKHLE 使用 WebSphereESB 实现此 ESB。

JKHLE 按如图 4 所示应用此 SOA 原子模式。

图 4. 内部连接模式

采用此模式的业务价值

通过 ESB 采用内部连接模式，JKHLE 可以进行更好的定位，以快速和有效地适应从在线到商店业务流程中的变化。他们将能在特殊业务条件出现时对这些条件做出响应。

进一步的信息：请参考案例研究：服务连接性 SOA 场景。

ESB 联合模式的应用

ESB 联合模式描述如何在不同的领域中集成多个 ESB，从而实现领域需求与产品功能之间的最佳匹配。

技术问题

JKHLE 使用基于套接字和基于 WebSphere MQ 的解决方案在其零售商店与公司总部之间集成信息。商店和公司之间的信息更新需要实时和基于标准的方式完成。

JKHLE 如何应用此模式

JKHLE向每个零售商店添加了 ESB。有些零售商店使用 WebSphere Message Broker Starter Edition 实现此ESB，其他则使用 WebSphere Remote Server。这其中每个 ESB 提供了与公司 ESB 的集成。例如，在每个零售商店使用ESB 可以提供商店内与诸如接收和库存控制等后端应用程序之间的集成。零售商店和公司总部基础结构拥有单独的 ESB可以提供更强的灵活性。零售商店可以得益于商店中较轻量级的 ESB 版本，而企业功能则通过高级 ESB 来实现。JKHLE 按如图 5所示应用此 SOA 原子模式。

图 5. ESB 联合模式

采用此模式的业务价值

JKHLE 能够通过实时的库存检查，从而得益于跨零售商店、Web 和产品目录渠道的准确和及时的产品信息。产品信息的更改在渠道之间是一致的。

进一步的信息：请参考案例研究：服务连接性 SOA 场景。

流程自动化模式的应用

流程自动化模式处理有关如何自动化工作流的问题，包括自动化人工任务的集成。它还处理如何能够自动化跨多个应用程序和后端存储库的集成。

技术问题

JKHLE 的现有从在线到商店业务流程非常僵化，不够灵活。例如，当客户在线下了订单，然后将来自该订单的商品退还给零售商店时，将遵循公司的退还策略。目前，要花太长的时间才能引入针对特定产品系列的新退还策略。

当前的从在线到商店流程还包含了太多的手动流程。例如，如果客户希望在商店中交结所购商品，则必须在电话上直接与零售代表交谈。

JKHLE 如何应用此模式

在WebSphere Business Modeler 中对新的业务流程建模，将此建模活动的结果转换为将在 WebSphere ProcessServer 中运行的实现。这个新的业务流程更加高效，能更好地适应 JKHLE的需求。例如，其中包括一个针对退还商品的业务策略，以及一个任务，此任务针对客户希望在零售商店领取商品的订单。此任务在客户做出购买时，在电子邮件中向客户服务代表分派订单信息，以便他或她能够从零售货架中取出该订单所购的商品，为客户领取商品做好准备。

JKHLE 按如图 6 所示应用此 SOA 原子模式。

图 6. 流程自动化模式

采用此模式的业务价值

更改业务策略所需的时间在新流程中可以显著缩短。这些策略的更改很容易整合，并且在某些情况下可以动态地添加。例如，使用新的敏捷业务流程，更改退货策略将变得相当简单，这样客户就不再需要获得商店经理的批准，无需提供收据即可退还商品。

进一步的信息：请参考案例研究：业务流程管理 SOA 场景。

业务活动监视模式的应用

业务活动监视模式提供了一种监视业务活动的方法，以便对流程的成功与否做出明智的业务决策，以及迅速识别该流程中的问题领域。

技术问题

JKHLE 无法监视围绕主要业务流程的关键指标。例如，他们希望获得从在线到商店流程中的指标以测量特定客户退还的商品百分比，以及围绕特定产品在购买后被退还的百分比的指标（以提供对有关可能的缺陷产品系列的了解）。

JKHLE 如何应用此模式

JKHLE使用 IBM WebSphere Business Monitor对从在线到商店业务流程应用业务活动监视。该监视流程基于一组所记录和跟踪的业务度量。JKHLE使用这些业务度量为给定的境况生成警报，例如由于大量的退还商品而可能发生欺诈的商店位置。

JKHLE 按如图 7 所示应用此 SOA 原子模式。

图 7. 业务活动监视模式

采用此模式的业务价值

JKHLE 使用业务活动监视更好地了解从在线到商店业务流程的运行状况。他们可以迅速识别问题领域，生成有意义的业务报告，并确定新出现的机会。

进一步的信息：请参考案例研究：业务流程管理 SOA 场景。

端到端服务管理模式的应用

服务管理包括监视和管理 SOA 的方面。

技术问题

JKHLE 需要根据服务水平协议 (SLA) 监视零售服务组件（例如商务、销售和供应链）。当前的基础结构中不存在清楚和自动化的方法来完成此任务。

JKHLE 如何应用此模式

JKHLE 使用 IT 事件管理系统跨 IT 层执行事件关联，以缩短问题确定时间。例如，如果商店的某个销售点系统停止运行，远程呼叫中心可以通过分析中间件发出的事件来确定问题。

JKHLE采用的两个功能强大的软件应用程序是 IBM Tivoli® Compliance Insight Manager 和 IBM TivoliSecurity Operations Manager。Tivoli Compliance Insight Manager使审核人员可以通过查看历史安全日志确定一段时间以来对 Sarbanes-Oxley Act 法律法规遵从性的违反情况。TivoliSecurity Operations Manager 使零售 IT 数据中心管理员可以在仪表板上监视操作安全性事件（例如，对 Web商务服务器的多次失败登录）。

采用此模式的业务价值

通过实现端到端服务管理，JKHLE 的 IT 基础结构遭遇的中断将会更少，从而减轻与中断相关联的损失。

进一步的信息：请参考案例研究：SOA 安全性和管理场景。

服务安全性模式的应用

SOA 安全性模式包括两个领域中的安全性管理方面。第一个领域是针对授权、消息安全性和访问控制的安全策略/配置在多组端点之间的一致性。第二个领域是 SOA 环境中的身份管理。

技术问题

当客户向 JKHLE 下订单时，客户的信用卡数据必须加密。用于加密数据的基础结构必须符合 Payment Card Industry (PCI) 数据安全性标准。

注意：PCI 数据安全性标准由主要的信用卡公司创建以保护客户信息。维萨、万事达、美国运通和其他信用卡协会要求零售商和服务提供商在存储、处理和传输信用卡持有人的数据时必须满足某些最低安全标准。

JKHLE 如何应用此模式

JKHLE 通过对 IT 基础结构做出更改来解决此挑战。存储在商务数据库中的数据必须加密。IBM WebSphere Commerce Server 与付款处理程序之间的事务必须通过安全的通信通道（例如 SSL）进行。

关于访问控制，IBM Tivoli Access Manager 可以确保在零售店、公司总部的 JKHLE员工和客户服务代表只能访问各自的角色所允许访问的功能。最后，Tivoli Federated Identify Manager支持安全令牌服务，此服务用于在身份和令牌通过 ESB 从服务使用者流向服务时对身份和令牌进行映射。

采用此模式的业务价值

通过采用这些措施，JKHLE 能够遵守 PCI 的指导原则，从而保护客户并保护自身避免代价昂贵的入侵和处罚。

进一步的信息：请参考案例研究：SOA 安全性和管理场景。。

SOA 治理模式的应用

SOA 治理模式包括控制新服务创建、实现更多的服务重用、强制标准和最佳实践、服务更改管理和服务版本控制，以及实现 SOA 策略。

技术问题

JKHLE 的整个当前基础结构中使用了多个集成解决方案。其中许多解决方案（例如基于套接字的技术）导致了使用专有技术和协议。需要着手进行治理，以便建立基于开放标准的通信协议。

此外，还需要对业务服务的标识和规范进行治理，因为 JKHLE 正在向跨所有渠道提供相同服务的方向迈进。

JKHLE 如何应用此模式

JKHLE 已建立了用于跨体系架构的所有领域强制实施治理的指导原则。例如，它拥有一个针对每个零售商店的标准解决方案，基于 ESB 的集成是其中的必备要求。

JKHLE还建立了用于对任何 JKHLE 系统访问强制安全身份验证策略的治理。它还建立了有关供应商将如何与 JKHLE 系统通信的治理。JKHLE建立了针对业务服务（例如产品和订单）的标识和规范的治理。这帮助 JKHLE 不必在渠道之间投资建立相同服务的不同实现。

为了促进 SOA 的治理，JKHLE设立了公司治理委员会。它还创建并建立了体系架构审批、体系架构例外、体系架构活力和体系架构交流流程。该委员会由业务主管、IT主管、首席架构师、操作架构师、项目经理和业务及 IT 主题专家提供支持。JKHLE 还建立了所有体系架构参与者的决策权限。

采用此模式的业务价值

通过对每个商店采用标准解决方案，JKHLE 可得益于成本的降低，因为标准强制要求使用相同的监视工具。供应商可以轻松地与 JKHLE 通信，从而为公司提供更大的供应商群，这样又可以实现更有竞争力的定价和商品品种多样性。

进一步的信息：请参考案例研究：SOA 治理场景，REDP-4384。

预期参考体系架构

通过应用上面描述的 SOA 原子模式，Jonathan Spencer 和他的 IBM 顾问团队与 Charles Hunt 一起为 JKHLE 定义了建议的参考体系架构。

图 8. 预期参考体系架构

通过使用 IBM Information Server，JKHLE 现在拥有单个合并的订单、销售和商品信息存储库。这可以为决策制定和报告系统提供及时、准确和高质量的信息。

零售商店（使用 IBM WebSphere Message Broker Starter Edition）和公司总部（使用 IBMWebSphere Enterprise Service Bus 和 WebSphere Message Broker）引入了 ESB，以提高IT 对跨渠道业务流程中的更改的响应能力。

JKHLE 的新建模的业务流程在 WebSphere Process Server 中执行。IT 环境中添加了由 IBM WebSphere Business Monitor 和 Cognos BI® 实现的业务监视和报告，以更好地监视和测量关键性能指标。

JKHLE将重点集中在法律法规和安全遵从性方面，以保护客户和自身避免入侵和处罚，因此采用了来自 IBM产品组合的关键产品实现端到端安全和服务管理，其中包括 Tivoli Compliance Insight Manager 和 TivoliSecurity Operations Manager。

图 9 显示了用于实现此基础结构的 IBM 产品。

图 9. 用于实现端到端参考体系架构的 IBM 产品





回页首

新产品引入实现

在本部分中，我们将讨论 SOA 零售业务模式的新产品引入实现。JKHLE 使用此实现来处理他们的产品信息管理和新产品引入活动。

观察现有的业务

来自 IBM 的零售行业架构师 Jonathan Spencer 与 JKHLE 的销售副总裁 Maria Gomez 和电子商务负责人Charles Hunt 进行合作，以了解当前的新产品引入（new productintroduction，NPI）解决方案。通过一系列的访谈，Jonathan 得出了以下观察结论：

• JKHLE 的现有 NPI 解决方案是手动的，成本高昂，而且非常耗时。它缺乏集中的产品信息存储库，并且没有产品信息的单一视图。
• 平均来讲，JKHLE 要在每件商品上花 19 分钟纠正错误，雇用五个人员专门负责检查和审批新产品，并且平均每年花 130 万美元来管理商品信息。
• 支持 NPI 的 IT 系统没有实现自动化。例如，有关新商品的数据在进入销售系统、营销目录系统等之前，在多个电子表格中进行捕获并重复。
• 使用了许多现有应用程序，并且 NPI 解决方案利用了许多不同的技术，从而导致系统之间的通信非常困难。

基于这些观察结果，Jonathan 记下了以下重要发现：

• 存在一个 IT 系统、数据库、电子表格和流程的特别集合。不同的产品系列使用不同的产品研究系统和不同的产品开发系统。这导致严重的重复工作和糟糕的团队间协作。
• 产品数据经常不完整和不准确，不存在此产品数据的单一视图。这使得产品信息的目录公布和目录传播变得复杂化。此外，由于产品数据的质量非常糟糕，经常在不具备所有必需信息的情况下做出重要产品决策。
• 线性流程运行时间非常漫长并创建瓶颈。关键资源将时间和精力浪费在非增值活动上。
• 对外部提供的行业信息的利用非常有限，只存在有限的流程可见性和管理。

业务流程建模

基于 Jonathan 的观察结果和主要发现，JKHLE 同意它需要更改其业务流程。通过一系列进一步的访谈，Jonathan 能够对现有的 NPI 业务流程做文档记录，并提出有关如何改进流程设计的建议。

当前业务流程分析

当前的 JKHLE NPI 流程包含以下阶段：

1. JKHLE 零售商与供应商会谈：

• 为 Maria 的 JKHLE 销售组织工作的零售商与市场上的供应商会谈（通常是在贸易展会上），以捕获有关新供应商和 JKHLE 可能有兴趣销售的新商品的详细信息。
• JKHLE 的零售商还携带了商品销售详细信息记录板，这些商品是以前从已经与 JKHLE 建立现有关系的供应商处购买的。 零售商使用这些记录板组合来自多家供应商的相关商品。

2. JKHLE 零售商捕获新的供应商详细信息：

• JKHLE 的零售商通常在 Microsoft® Excel® 电子表格中捕获供应商信息。
• 零售商将电子表格中捕获的供应商信息通过电子邮件发送给应付帐款团队，后者手动将这些详细信息输入供应商管理系统。有些供应商信息还要输入核心销售系统。此手动流程非常容易出错和非常耗时。

3. 零售商捕获新商品的详细信息：

• 与捕获供应商详细信息类似，JKHLE 的零售商也在 Microsoft Excel 电子表格中捕获商品信息。
• 当零售商从市场上返回时，将把商品详细信息手动输入核心销售系统，其中某些商品信息还要输入供应商管理系统。与供应商数据输入流程类似，这种手动的商品数据输入也非常容易出错和非常耗时。

4. 与供应商进行初步交流：

• 当 JKHLE 对购买某种特定商品感兴趣时，供应商与 JKHLE 的采购部门之间将进行多次电子邮件交流。这些交流通常为供应商提供估计的购买数量，或者表达对相关商品样品的需要。
• 核心销售系统将进行相应的更新。

5. 下订购单：

• 使用供应商管理系统和核心销售系统中的信息将订购单详细信息输入 Microsoft Exdel 电子表格。
• 提交订购单以便审批，并且在创建批准的订购单并将其发送给供应商之前，很可能会对订购单进行多次修订。

建议的业务流程设计

使用从在线到商店业务流程的重新设计中强调的同一组主要设计原则（请参见“建议的业务流程设计”），Jonathan 描述了建议对全面修改后的新 NPI 业务流程的每个阶段做出的改进：

供应商信息创建

对于该流程的此部分，IBM WebSphere Portal将用作入口仪表板，零售商在该仪表板上的字段中输入供应商详细信息。这些详细信息被即时捕获，并在充当所有供应商详细信息主存储库的主数据管理系统中创建供应商数据。然后基于已定义的业务规则，根据情况将供应商详细信息发送到核心销售系统和供应商管理系统。如果需要，将引发并自动处理审批任务。

做出这些更改可以为 JKHLE 带来以下益处：

• 流程自动化各就其位。消除手动错误，总体流程显著更快。
• 存在多个系统的供应商详细信息的单一视图，这是通过主数据管理系统实现的。
• 不需要将信息从 Microsoft Excel 电子表格重新输入后端系统。

商品信息创建

该流程的此部分以类似于创建供应商信息的方式实现了自动化。零售商将商品信息输入由 IBM WebSphere Portal 实现的仪表板，在主数据管理系统中创建商品数据，并基于已定义的业务规则相应地更新核心销售系统和供应商管理系统。

除了在“供应商信息创建”中讨论的益处以外，该流程的新的“商品信息创建”部分给 JKHLE 带来了附加的益处，使其可以避免使用电子邮件作为在零售商和商品专家之间传递商品信息的主要方法。

供应商门户

IBM WebSphere Portal用作入口仪表板，供应商在其中输入商品详细信息。供应商根据情况编辑诸如估计价格和交货时间等字段。这些详细信息被即时捕获，商品数据在主数据管理系统中得到更新，并基于已定义的业务规则相应地发送到核心销售系统和供应商管理系统。如果需要，将引发并自动处理审批任务。

做出这些更改可以为 JKHLE 带来以下益处：

• 流程自动化各就其位。消除手动错误，总体流程更加快速。
• 供应商可以更新相应的商品字段，商品的详细信息将被即时捕获。
• 避免在供应商和零售商之间使用传真和电子邮件。

增加订购单

IBM WebSphere Portal用作入口仪表板，零售商在其中输入订购单详细信息。这些详细信息被即时捕获，订购单数据在主数据管理系统中得到更新，并基于已定义的业务规则相应地发送到核心销售系统、供应商管理系统和财务管理系统。如果需要，将引发并自动处理审批任务。

与供应商门户一样，流程可以得益于自动化，手动任务中的错误消除了，并且端到端的流程更加快速。

总而言之，Jonathan表示该建议的业务流程设计将自动化流程的流，从而可以改进与供应商、商品和订购单相关联的内容的及时性和准确性。该建议的流程还可以消除多个手动步骤和多余流程。建议的流程可以改进流程性能的可见性，以及更好地管理流程流，并持续地注入确定异常的能力。新的业务流程还发掘出了 JKHLE的更多能力，使其能够在业务流程建模和执行过程中获得对流程成本、流程持续时间和预期行为的业务认识。

服务建模

在执行业务流程建模之后，下一个任务是详细描述将构成建议的业务流程的服务。与从在线到商店实现一样，Jonathan 建议 JKHLE 使用 IBM 推出的 SOMA 方法来标识将构成此 SOA 的这些服务。有关 SOMA 的更多信息，请参阅“服务建模”。

使用领域分解、现有系统分析和目标-服务建模，JKHLE 可以标识将支持该 NPI 流程的服务。例如，使用领域分解，可以将 NPI业务流程分解为商品管理、供应商管理和订购单管理子流程。每个子流程又可以进行进一步的分解，最终产生一系列业务用例（例如，创建商品和更新订购单）。这些业务用例通常是业务服务的很好候选者。

现有体系架构

在对现有的业务流程建模、定义改进的业务流程和标识业务服务之后，Jonathan 需要全面了解当前存在的技术体系架构（现有体系架构）。JKHLE 的销售副总裁 Maria Gomez对此体系架构进行了描述。Maria 告诉 Jonathan，当前的体系架构是 Microsoft Excel 电子表格和数据系统的混合。

图 10 在系统上下文关系图中显示了该技术环境的现有体系架构。

图 10. 现有体系架构

SOA 原子模式

与在从在线到商店活动中的做法类似，来自 IBM 的零售行业架构师 Jonathan Spencer 告诉电子商务负责人 Charles Hunt和销售副总裁 Maria Gomez，定义满足 JKHLE 需要的体系架构的理想方法是将解决方案细分为 SOA 原子模式。这些 SOA原子模式可以简化从 SOA 的角度对总体解决方案的理解。

应用 SOA 原子模式和最佳实践使得 JKHLE 更容易了解解决方案的每个部分的影响，并帮助 JKHLE 分阶段采用该解决方案。

表 2 显示了 Jonathan 向 JKHLE 建议的 SOA 原子模式，以及与这些模式相关的 SOA 入口点或规则。

SOA 入口点/规程适用的 SOA 原子模式信息入口点用于产品信息管理的主数据管理人员入口点流程门户
使用 AJAX Portlet 的基于富 Web 的应用程序
使用简单的 Portlet 聚合和调用服务连接入口点使企业应用程序与 Web 服务相适应流程入口点业务流程建模、自动化和监视SOA 安全性、治理和管理规程服务安全性
端到端服务管理

Jonathan 描述了每个 SOA 原子模式旨在解决的技术问题、每个 SOA 原子模式如何应用于 JKHLE，以及通过采用该模式所带来的业务价值。

注意：在下面的部分中，每个 SOA 原子模式描述 JKHLE 面对的单个技术问题示例，然后描述如何应用 SOA 原子模式来解决该问题。在许多情况下，SOA 原子模式实际上可以帮助 JKHLE 解决多个技术问题（本文前面可能没有提到这一点）。

这些 SOA 原子模式代表用于实现新产品引入解决方案的路线图。通过应用所有这些 SOA 原子模式，JKHLE 采用了一个利用许多 SOA概念的参考体系架构（请参见第 43页上的“预期参考体系架构”）。采用类似解决方案的组织可以检查这些模式，并根据他们的特定环境选择适用的模式。我们在本文中描述的体系架构所演示的案例中，该零售商是相当高级的 SOA 采用者。

“用于产品信息的主数据管理”模式的应用

用于产品信息管理（product information management，PIM）的主数据管理演示如何使用单个权威主数据源协调商品数据，当商品信息存在于多个不同位置时，可以将该数据源用作参考源。

技术问题

产品和供应商信息分布在 JKHLE 的多个系统中，从而导致产品数据不一致和重复。

JKHLE 如何应用此模式

JKHLE对所有产品和供应商信息采用主数据管理解决方案。IBM InfoSphere™ Master Data Management Serverfor Product Information Management（以下称为 InfoSphere MDM Server forPIM）为核心销售系统、供应商管理系统和各种其他电子商务系统（例如产品采样跟踪系统）提供了产品和供应商数据的单个主副本。

JKHLE 按如图 11 所示应用此 SOA 原子模式。

图 11. 用于产品信息管理的主数据管理模式

采用此模式的业务价值

通过使用产品、供应商和订购单数据的单个主副本，以前与不准确的数据相关联的代价昂贵的混乱得到了显著缓解。客户对不准确的产品数据产生的挫折感（通常导致退货和客户不满意）急剧减少了。

进一步的信息：请参考案例研究：将信息作为服务 SOA 场景。

流程门户模式的应用

流程门户模式处理向当前流程添加流程流功能的需要和在流程流中插入人工任务的需要。

技术问题

JKHLE 希望拥有一个个性化和统一的界面管理主数据管理服务器以及现有的销售系统。JKHLE 员工希望拥有熟悉的个性化界面（而不是使用主数据管理服务器的本机图形用户界面，该界面使用起来非常不方便）。

JKHLE 如何应用此模式

JKHLE在 IBM WebSphere Portal 中创建了一个流程门户，该门户与 WebSphere Message Broker相互配合以访问应用程序服务。该流程门户包含许多流程 Portlet，这些 Portlet 提供了个性化界面，并支持人工交互和基于角色的交互。

人工交互为 NPI 流程中的内联人工交互提供了支持。例如，在处理审批时将需要人工交互。在引入新产品时，零售商必须审批商品的引入。

基于角色的交互为供应商和零售商提供了个性化的界面，使他们可以完成日常活动（例如商品管理、订购单管理等等）。

JKHLE 按如图 12 所示应用此 SOA 原子模式。

图 12. 流程门户模式

采用此模式的业务价值

通过采用流程门户模式，JKHLE 拥有了可自定义的单一用户界面，此用户界面可以进行个性化，并允许 JKHLE 使用门户界面轻松管理产品、供应商和订购单。

进一步的信息：请参考案例研究：交互与协作服务 SOA 场景。

“使用 AJAX Portlet 的基于富 Web 的应用程序”模式的应用

此模式演示了 AJAX Portlet 相对于传统或简单 Portlet 的价值，包括性能和响应能力方面的益处。

技术问题

产品由许多不同类型的数据构成，其中包括：核心产品详细信息、区别因素详细信息（例如产品的颜色和尺寸）和库存单位（Stock KeepingUnit，SKU）。给定产品的 SKU 由 InfoSphere MDM Server for PIM自动生成。目前，当零售商输入新产品信息时，SKU 的生成需要重新加载整个产品页面，从而严重减慢了输入产品信息的过程。

JKHLE 如何应用此模式

通过在 WebSphere Portal 中使用 Portlet，零售商可以输入产品的核心产品详细信息和区分因素详细信息。该 Portlet 的SKU 部分通过新 SKU 动态进行更新，而不需要重新加载整个页面或 Portlet。这种局部的 Portlet 重新加载是在 AJAX的帮助下实现的。

JKHLE 按如图 13 所示应用此 SOA 原子模式。

图 13. 使用 AJAX Portlet 的基于富 Web 的应用程序模式

采用此模式的业务价值

JKHLE 的零售商可以更高效地工作，而不必等待整个页面重新加载。考虑到零售商处理的数据输入量，时间上的累积节省是实质性的。

进一步的信息：请参考案例研究：交互与协作服务 SOA 场景。

“使用简单的 Portlet 聚合和调用服务”模式的应用

此模式引入了用于将多个服务聚合到单个视图中的 Portlet 的使用。

技术问题

向 JKHLE 零售商描述的产品信息不一致。重要产品详细信息经常缺失，并且某些产品具有与之关联的图像，而有些则没有。产品详细信息和产品图像没有得到有效地管理。

JKHLE 如何应用此模式

JKHLE 使用内容管理系统来存储产品图像。对产品图像的引用存储在 InfoSphere MDM Server for PIM 中。

当向零售商显示产品详细信息时，WebSphere Portal 聚合来自 InfoSphere MDM Server for PIM 和内容管理系统（针对产品图像）的产品信息来显示用户界面。

JKHLE 按如图 14 所示应用此 SOA 原子模式。

图 14. 使用简单的 Portlet 聚合和调用服务模式

采用此模式的业务价值

通过门户向 JKHLE 零售商显示重要产品详细信息（包括产品规格和关联的图像），零售商能够做出更加明智的决策。

进一步的信息：请参考案例研究：交互与协作服务 SOA 场景。

“使企业应用程序与 Web 服务相适应”模式的应用

此模式演示组织如何构建新应用程序，此类新应用程序使用行业 Web 服务标准利用现有系统中的功能。

技术问题

JKHLE 利用了许多来自第三方供应商的打包应用程序。JKHLE 希望通过其 ESB 继续使用这些打包应用程序，以消除点对点连接。此外，JKHLE 希望使用 Web 服务调用这些打包应用程序。遗憾的是，打包应用程序并不内在地具备 Web 服务接口。

JKHLE 如何应用此模式

使用自定义的 IBM WebSphere 适配器将打包应用程序连接到 ESB。这些自定义 WebSphere 适配器利用 IBM WebSphere Adapter Framework。

此外，在环境中引入了服务注册中心以及服务监视，这是迈向全面 SOA 实现的第一步。

JKHLE 按如图 15 所示应用此 SOA 原子模式。

图 15.“使企业应用程序与 Web 服务相适应”模式

采用此模式的业务价值

JKHLE 可以利用其对打包应用程序的现有投资。将来还可以将此投资扩展到其他企业信息系统。

进一步的信息：请参考案例研究：服务连接性 SOA 场景。

“业务流程建模、自动化和监视”模式的应用

此模式处理用于对业务流程进行建模、自动化和监视的业务流程管理。

技术问题

JKHLE 需要某种方法对新 NPI 流程建模。它还需要某个解决方案来构建自动化的端到端流程。需要对新 NPI 流程进行监视，以测量关键性能指标。

JKHLE 如何应用此模式

JKHLE 使用 IBM WebSphere Dynamic Processes Edition 对该 NPI 流程进行建模、组装、部署和监视。

JKHLE 使用 IBM WebSphere Business Modeler 对现有 NPI 流程做文档记录，以及对新的 NPI 流程建模，新流程要求跨 JKHLE 的现有核心销售、供应商管理和新引入的 MDM 系统进行流程编排。

JKHLE 的业务规则之一规定新产品在获得销售部门经理批准之前，不得进行销售。审批流程的工作流是使用 WebSphere Process Server 构建的，并利用了人工任务管理。

IBM WebSphere Process Server 编排核心销售系统中的信息收集，以便填充到 InfoSphere MDM Server for PIM 中。

在运行时，可以使用 WebSphere Business Monitor 从业务角度测量 NPI 流程的性能。

JKHLE 按如图 16 所示应用此 SOA 原子模式。

图 16.“业务流程建模、自动化和监视”模式

采用此模式的业务价值

通过使用 WebSphere Dynamic Processes Edition，JKHLE 可以端到端地自动化新的 NPI 流程。手动流程得以消除，从而改进了引入新的供应商和产品的及时性和准确性。

对该 NPI 流程进行监视，以测量关键性能指标，例如平均商品设置时间、获批准的商品百分比、平均供应商设置时间，等等。

进一步的信息：请参考案例研究：业务流程管理 SOA 场景。

“服务安全性”模式的应用

SOA 安全性模式包括两个领域中的安全性管理方面。第一个领域是针对授权、消息安全性和访问控制的安全策略/配置在多组端点之间的一致性。第二个领域是 SOA 环境中的身份管理。

技术问题

新的 NPI 流程需要访问许多后端服务和系统。此访问需要得到适当保护。JKHLE 还希望标准化用于与合作伙伴公司交互的安全身份管理。

JKHLE 如何应用此模式

身份验证的强制是通过 WebSphere Portal 的身份验证模块和 Tivoli Directory Server的组合进行管理的。Tivoli Federated Identify Manager 用于提供安全令牌服务，此服务在身份和令牌通过 ESB从服务请求者流向服务提供者时对其进行映射。例如，在访问核心销售系统和供应商管理系统时，将使用此安全令牌服务。

JKHLE 正在考虑使用 Tivoli Federated Identify Manager 来允许合作伙伴公司将他们自己的 LDAP 系统联合到 JKHLE 环境中，以便 JKHLE 不必管理其合作伙伴的身份。

JKHLE 按如图 17 所示应用此 SOA 原子模式。

图 17.“服务安全性”模式

采用此模式的业务价值

通过采用此模式，JKHLE 能够更好地控制对其后端系统的访问。

进一步的信息：请参考案例研究：SOA 安全性和管理场景。。

“端到端服务管理”模式的应用

服务管理包括监视和管理 SOA 的方面。

技术问题

JKHLE 需要根据服务水平协议 (SLA) 监视零售服务组件（例如核心销售系统）。当前基础结构中不能存在用于监视零售服务组件的清楚和自动化的方法。JKHLE 还希望监视其整个 SOA 基础结构，包括前端 Portlet 和 ESB 中间件。

JKHLE 如何应用此模式

JKHLE使用了 IBM Tivoli 监视产品的集合。它使用 Tivoli Composite Application Manager forWebSphere 监视 WebSphere Portal、WebSphere Message Broker，以及 WebSphereProcess Server 中的业务流程执行。

JKHLE 使用 Tivoli Composite Application Manager for SOA 监视通过 ESB 从业务流程引擎流向服务提供者的服务请求。这些服务提供者包括核心销售系统、供应商管理系统和 MDM 服务器。

此外，JKHLE 还使用 Tivoli Enterprise Console® 和 Omnibus 作为 IT 事件管理系统，以跨 IT层执行事件关联，从而缩短问题确定时间。例如，如果 MDM系统停止运行，由于能够分析中间件发出的事件，呼叫中心只需花更少的时间即可远程发现问题。

采用此模式的业务价值

通过实现端到端服务管理，JKHLE 的 IT 基础结构可以得到更加密切的监视，并且遭遇的停机将会更少，从而减轻与中断相关联的损失。

进一步的信息：请参考案例研究：SOA 安全性和管理场景。。

预期参考体系架构

通过应用上面描述的 SOA 原子模式，Jonathan Spencer 与他的 IBM 顾问团队、Maria Gomez 以及 Charles Hunt 一起为 JKHLE 定义了建议的参考体系架构。

图 18 显示了预期的参考体系架构。

图 18. 预期参考体系架构

与其非 SOA 前身相比，这个新的预期参考体系架构具有许多优点。其中一些主要优点包括通过 IBM InfoSphere Master DataManagement Server for Product Information Management 实现的单一产品信息视图。此外，以WebSphere Message Broker 的形式存在的企业服务总线消除了使得 JKHLE 的体系架构高度复杂化的点对点连接。

还要注意到 WebSphere Portal的存在，它用作入口仪表板，相应的各方可以通过高度可自定义、个性化的图形界面在其中输入供应商和产品详细信息。业务流程流由 WebSphereProcess Server 进行编排。业务流程由 WebSphere Business Monitor进行监视，后者提供了对流程成本、持续时间和执行情况的深刻认识。

图 19 显示了用于实现此基础结构的 IBM 产品。

图 19. 用于实现端到端参考体系架构的 IBM 产品