【IT168 技术文章】
本文提供了两个 SOA 实现来说明 IBM 内的关键业务服务的部署。在第一个实现中，出口管制服务允许组织确保遵循美国政府出口限制（其中定义了美国公司不能与之开展业务的个人、公司或国家/地区）。第二个 SOA 服务为从各种来源聚合的客户信息集的管理和可用性提供支持。
引言
本部分将介绍以下案例研究
案例研究 3：法律法规遵从方面的 Export Validation Export Validation Service (EVS)
案例研究 4：Central Customer Master System [CCMS]
EVS 和 CCMS 分别代表了遵从性管理和“作为服务的信息”方面的主要 IBM 内部解决方案。考虑到政府法律法规要求的复杂性不断增加，以及管理联合数据源来支持位置透明性的需求（有关更多信息，请参见参考资料部分），这两个服务无疑是 IBM 内部 SOA 解决方案的突出例子。
案例研究 3：法律法规遵从方面的 Export Validation Export Validation Service (EVS)
业务上下文
美国出口法律法规规定了有关可将哪些物品出口到境外的哪些对象的限制。这些法律法规适用于涉及最广泛意义上的任何出口类型的所有情况——包括从美国向任何其他国家/地区提供硬件、软件、服务、工具或技术。除了传统的物理交付方式外，通过电子方式将软件或技术信息提供给美国之外的实体（个人、公司、组织、政府）也受到控制。
可能不可将与国家安全相关的特定产品或技术（如加密技术、核武器、化学或生物武器、或导弹）售出或提供给规定名单中的国家/地区。美国政府发布了一份实体名单，称为出口管制黑名单（Denied Parties List，DPL），不允许美国公司与其中的实体开展任何形式的业务。另外，美国政府还发布了禁运或恐怖主义相关的国家/地区名单，从而对业务活动进行了进一步的限制。
挑战
正式制定的用于确保符合政府法律法规的策略正变得越来越重要，需要在企业级别加以控制，以避免巨额罚款和其他由于违规而导致的负面影响。IBM 的 Export Regulation Office (ERO) 负责 IBM 必须如何遵循美国出口法律程序，并每月更新美国政府关于不能与之开展业务的个人、公司和国家/地区的名单。IBM 的在线软件销售和下载（免费和付费软件）需要更为自动化的方法来对交付内容及其接受人进行实时验证。这对于保证不会违反美国的相关限制非常必要。
在 IBM 内已部署了多个应用程序来支持美国出口法律法规遵从。由多个业务领域实现了多个出口检查的版本。它们都需要包含 ERO 每月更新的管制名单，以避免执行费时的手工任务来恢复与规定的名单上的实体进行的错误业务事务。公司内出口管制功能的大量增加带来了不必要的开发和维护成本，而且 ERO 需要与多个开发团队合作来确保遵从一致性。
IBM 的 Software Delivery and Fulfillment (SDF) 组织最初为自己的在线销售和交付功能创建执行各种出口检查的功能。不过，他们需要更为高效的解决方案，以便方便地进行集成，以供自己使用；此解决方案还需要具有高度可重用性，以便将其功能扩展到其他的企业部门。SDF 的业务模型允许其接受来自潜在服务使用组织的新需求，从而促进在公司内更广泛地使用服务。
此解决方案需要处理的挑战简要小结如下：
美国萨班斯·奥克斯利 (Sarbanes-Oxley) 法案提高了对需要新 IBM 内部服务来支持对各种政府法律法规遵从的认识。
应用程序之间的冗余性以及过多的开发和维护成本。
每个月需要对多个应用程序进行更新，以将美国政府的出口管制名单包含到各自的本地副本中。
如果未及时包含出口管制名单的更改，则可能导致在 IBM 的 Integrated Supply Chain 流程中出现延迟。
基于 SOA 的解决方案
与其他几个早期 SOA 业务解决方案类似，此服务的基础已经存在于 Web 应用程序，在本例中即为对通过浏览器下载软件的客户执行实时检查的应用程序。2003 年 12 月，SDF 组织对其面向浏览器的基础设施进行了扩展，创建了基于 SOAP 的 Web 服务，即 Export Validation Service (EVS)。它允许其他请求者调用其客户分析功能，以便遵循美国政府出口法律法规。
根据提交的客户人口统计学信息（如名称、地址、位置、IP 地址以及涉及的 IBM 服务产品），此服务当前支持多个关键领域的出口检查：
进行以下方面的用户检查：1) 与美国政府的 DPL 进行比对；2) 详细审核，以避免将可用于导弹、化学与生物武器或核用途的技术扩散到指定的国家/地区；3) 与美国政府的禁运国家/地区名单进行比对（通过地址、电子邮件或 IP 地址）
加密产品检查，以控制包含强加密的加密产品的出口
按照丹麦和爱尔兰政府的要求进行专门的出口检查（支持这两个国家的 IBM 软件执行操作）
图 1 中所示的解决方案包括采用 ERO 美国政府出口管制黑名单更新形式的分散企业数据。
图 1. Export Validation 体系结构概述
除了 HTTPS 上的基于 SOAP 的 Export Web 服务外，此关系图还显示了更新 DPL 的后台流程——手动访问 ERO 的正式更新名单，然后使用 DPL Administration Tool 来将最新的更新包含到 EVS 数据库中。另外还描述了用于在“模糊”逻辑不正确地确定某个客户在规定名单中时覆盖错误的确定信息的管理员功能 (Override Administration Tool)。必须进行此提交信息的模糊分析，以处理名称类似而拼写存在细微差别的情况。
和很多业务服务一样，EVS 并不是完全独立的功能，它与手动业务流程进行了集成，以提供额外的服务价值。存在“人工服务总线”(Human Service Bus) 的概念，用于将人工任务集成到组织化结构中，并与服务实现进行协作，以确保遵循企业标准（请参见参考资料部分中列出的文章“Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals”），而在本例中，这也反映了政府的法律法规。
此开发团队最开始使用 IBM WebSphere? Studio Application Developer?，后来随着将工具更新为最新的 IBM 应用程序开发产品转而使用 IBM Rational? Application Developer?。WebSphere Application Server Version V5.1.x、IBM DB2? Connect Enterprise Edition? 和 IBM HTTP Server 均运行于其运行时环境的 AIX 服务器上。
EVS 已经在多个现有 IBM 业务流程中启用，将供由需要进行客户检查来遵循出口遵从性的新流程使用。这包括销售时（网上或通过电话）的事务以及在向客户交付货物前的最后检查。
业务成果
现在能以实时的方式更方便地将美国政府出口管制集成到所有与客户的网络和电话交互中。这个服务现在支持采用集中而一致的方式执行所有 IBM 出口检查功能，并确保及时将美国政府更新的管制名单包含进来，从而消除受到政府处罚的风险。
EVS 的基于服务的可重用性降低了与为多个应用程序构建冗余出口管制功能相关的开发和维护成本。除了成本外，还通过提供使用现有服务（而不是构建新功能）来减少了开发计划。
EVS 在 IBM 的企业目标体系结构中定义为主要的 SOA“企业组件”，实际就将其定义为了供所有 IBM 的业务单位重用。EVS 正在作为潜在的 IBM 商业资产进行评估，因而 IBM 可能会为客户的业务流程同时提供此服务和手动覆盖流程。企业和业务单元体系结构治理组织要协同工作，以确定何种情况下应用程序必须使用这些企业组件，而不是构建冗余功能。
所使用的非常好的实践及获得的经验教训
在处理多个业务部门的需求时，经常会考虑采用集中资金投入的企业服务。很多企业服务都通过其属于承担整个企业的业务功能任务的组织的方式来进行集中资金投入。EVS 采用了一种不同的业务模型，在其中，为满足新需求而对服务进行的更新由每个请求针对其独特需求进行更改的服务使用者组单独提供资金投入。这个模型非常成功地确保了 EVS 获得足够的资金投入，以应对新业务方向的挑战。
不过，由于采用此业务模型，使用增量开发一次满足新使用者的一个需求，有时候会导致功能改进延迟。具有独特需求的新使用者有时候不愿意为企业级服务的一般性基本功能元素提供资金投入。为了将 EVS 扩展到软件产品之外更大的企业范围需要进行更新，以获得更好的稳健性，从而确保 EVS 能够处理额外的负载。这种情况的一个例子是基于 Perl 脚本的旧代码，除了进行其他性能改进外，还必须将此代码转换为 Java?。一般企业功能（功能性和非功能性的）都在新客户具有与企业类似的需求时由 EVS 团队采用增量方式加以处理，并接受 IBM 业务转换 CIO 提供的一定指导和资金注入。
EVS 说明了使用者业务所有者需要了解更多信息，而不仅仅是其自己自动使用某个特定的 Web 服务。当前在 EVS 中需要一个手动后端流程，以进行潜在的错误出口检查结果的后续处理。很多使用者开发团队经常只将精力放在服务的接口上，事实上还需要考虑手动支持功能，这也能增强服务的有用性。
案例研究 4：Common Customer Master System——IBM 内的单一客户视图
变化点是确定可能发生更改而应该外部化的位置。具有内置变化点的服务组件允许用户通过对这些服务进行配置来满足不同的需求。可以将可扩展性机制加入到 UI、服务组件接口、服务组件本身以及数据模型中，从而实现可配置应用程序。
非常有必要对可配置性 和自定义 进行一下对比。可配置性为我们提供在不更改代码库（编写代码）的情况下使组件适应不同需求的能力。可配置性构建到服务（Switch、Dial 和 Lever）中，可以由应用程序的用户进行调用。相反，自定义要求开发额外的代码（使用编程语言）来扩展和更改软件组件，以支持特定的“自定义”行为。
业务上下文
根据使用的通道（如呼叫中心、Internet 和业务合作伙伴）不同，IBM 有时候会让客户觉得像独立操作的多家公司。客户的体验以及客户组织和联系信息有时候会缺少一致性和连续性。这对客户满意度造成了负面影响。为了处理这个问题，IBM 部署了 Common Customer Master System (CCMS)，这是一个基于 SOA 的解决方案，支持为其客户提供“一个 IBM”的体验。
CCMS 的主要业务目标有：
通过将所有 IBM 客户数据合并到单个系统和关联的存储库中，从而消除存在于 IBM 内的多个客户信息实例以及对应的冗余维护开销。从这些其他分布式客户存储库获得的信息将退出历史舞台，由这个单一的系统予以取代。
通过将组织层次结构合并到客户数据中，从而使得客户信息更有意义、更有用。组织层次结构提供有关不同业务实体彼此如何相关、其地址以及分支机构的业务信息。必须每月对这些层次结构进行更新，并作为 IBM 的组织层次结构数据受信任来源提供。
改进客户数据质量
通过图形用户界面（浏览器）提供直接用户可访问性，从而提高客户信息使用率。
提供服务接口，从而允许服务使用应用程序将这个集中的系统作为 IBM 所有客户信息的单一客户记录创建和客户信息源加以使用。
挑战
问题的范围以及复杂性包括：
集成来自不同数据源的客户数据——包括 Dunn and Bradstreet (D&B)、存储在 Reference Data customer (RDc) 连接点的 IBM 客户数据（代表来自各个 IBM 客户数据库的客户信息）和 CRM/Siebel（具有三个实例，分布在北美、欧洲和亚太地区）。这个集成任务还将处理对来自 D&B、IBM CRM 源和 RDc 的输入间的记录重复进行数据验证和纠正的需求。
使用支持 SOA 的单个功能集同时满足用户和应用程序访问功能
由于需要支持 119 个不同的国家/地区而产生的各种需求
将多个客户数据模型集成到单个逻辑模型的复杂性，此逻辑模型符合 IBM 的标准化业务数据定义，以便支持加载D&B、CRM 和 RDc
将多个异类客户遗留数据源转换为 SOA 支持的内聚解决方案
需要以一致的方式引入能够统一进行实现的新规则，包括：
将每个数据元素从数据源的数据模型映射到新的集中数据模型的业务规则，包括数据质量和可接受的值要求的列表
每个数据源的数据元素的转换规则，这些规则对在 CCMS 中创建和维护数据是非常必要的
所有数据源的数据元素的数据聚合规则，也对在 CCMS 中创建和维护数据非常必要 \
基于 SOA 的解决方案
CCMS 团队首先标识并优化对体系结构非常重要的各种场景，以便将其作为基础来定义所需的服务。 此分析和设计工作也涉及到对使用 WebSphere Business Integration Modeler 创建的流程进行建模，从而标识和协调独立构建的服务的使用。对每个场景进行了分析，以确定服务的非常好的范围和粒度，而这涉及到进行重构来改进服务的分离。对 CCMS 遗留系统进行了研究，以确定可以将哪些现有软件组件“包装”为服务，需要开发哪些新服务来提供这些系统所没有的功能。
使用 IBM Rational XDE 来创建 UML 用例和 IT 构件的对象模型，以供在组件模型的定义中使用。使用 WebSphere Application Developer -- Integration Edition 设计基于工作流的流程，从而以现有服务集合为基础组织新服务。Rational XDE 和 Business Integration Modeler 模型直接输入到 WebSphere Application Developer -- Integration Edition 中，从而用于将其他构件（XML 模式、Java 代码、服务和规则）与 BPEL 工作流相关（后者部署到了 WebSphere Business Integration Server Foundation 上）。
图 2 所示的 Core Transaction Update Service 是基于服务的 CCMS 工作流的一个示例，可供各种更新相关的流程（如 CRM update、RDc update 和 D&B update）使用，以确保一致性、数据质量和消除冗余。这个特定的更新服务包括处理标准化、进行匹配（确定输入记录是否唯一或已经存在）、聚合或持久性的活动。聚合活动实现数据聚合规则，该规则会在更新 CCMS 数据前对要更新的客户数据中每个数据组的数据的来源进行考虑。聚合规则指示更新 CCMS 数据时信任哪个数据源（按数据组确定）。
图 2 还显示了 CRM 更新服务 (CRM update service)，该服务实现了一个 CRM 更新流程，并使用 Core Transaction Update Service。
图 2. CCMS 体系结构概述
将现有资产转换为服务的示例有 Address Standardization Service、Matching Service 和 Assign Key service。地址标准化和匹配（检查记录是否唯一）的服务是通过包装现有遗留 Trillium 引擎提供的功能创建的。这些通过封装 Trillium 创建的服务现在可以在其他客户信息业务流程中重用，而不仅限于客户更新流程中。另一个步骤涉及到在没有现有基础可重用的情况下创建新服务，如 CCMS Persistence Service。
业务成果
CCMS 的 SOA 转换是 IBM 实现随需应变企业的业务远景的一个主要步骤。通过使用 SOA，CCMS 成为了基于重用的灵活而适应性强的解决方案。企业业务流程重用 CCMS 服务，而不用自己开发冗余的等效服务。CCMS 的 Update service、Search service、Address Standardization service、Match service 都是可重用服务的良好示例。CCMS 不仅提供了可重用服务，而且现在 CCMS 还能够将其服务编排为企业流程。重用所带来的灵活性给 IBM 提供了巨大的业务价值。此解决方案的业务价值非常明显，不过尚没有从资金的角度计算可测定的业务价值好处。
CCMS 另一个明显的业务价值是将客户信息作为服务实现。由于客户信息对 IBM 的业务至关重要，因此 CCMS 是主要的 IBM 内部“作为服务的信息”之一。在 CCMS SOA 解决方案中，信息包装为供业务流程使用的服务，因此可通过标准化的方式向每个流程提供一致的可管理的信息。在采用 CCMS 之前的环境中，每个业务流程都创建自定义信息访问，从而导致了流程之间不一致的客户数据视图、不一致的规则应用和相同逻辑存在多个维护点的情况。
CCMS 的一个可测定的业务结果是数据质量的改进。为了测定客户数据质量而实现的企业流程的报告表明，CCMS 数据质量相对于之前的解决方案有了大幅度的改进。由于 CCMS 中的数据质量改进，依赖于准确而及时的客户数据的 IBM 业务领域（如销售与机会管理以及服务等）的客户满意度得到了提高。据估计，基于 SOA 的 CCMS 解决方案每年大约可带来 815 万美元的资金节约，而这主要是通过淘汰 CCMS 所替代的冗余客户数据库来实现的。
通过为其后端功能使用工作流，CCMS 启用了更为全面的方法来集成源自 IBM 内多个客户数据源的客户信息。这就减少了客户信息不完整或不准确的风险，而出现这些情况可能会对重要业务事务造成严重的延迟。CCMS 现在代表的是 IBM 的单一客户记录创建点和客户数据的主要来源。此外，可从多个业务部门方便地交叉引用客户信息带来新的销售机会。这还允许以增量的方式逐渐讨论很多冗余客户信息数据源。
所使用的非常好的实践及获得的经验教训
CCMS 是另一个 SOA 解决方案示例，其中后端流程在管理从服务接口提供的信息的过程中扮演着重要的角色，而服务接口不过是冰山一角而已。在部署服务接口前，CCMS 首先需要创建所有 IBM 客户信息的集成视图。这涉及到利用 WBI Server Foundation 提供的业务流程灵活性创建操作工作流，以将其用于管理多个来源的客户数据。
和很多企业关键应用程序一样，“大爆炸 (Big Bang)”方法费用太高，且会带来干扰。在开发 CCMS 后端流程管理客户信息之前，需要使用 Web 服务来访问主要客户信息。部署了一个战术性的解决方案，从而向现有 RDc 连接点公开了一个服务接口。此战术实现使用了策略客户信息访问接口（CCMS 最终部署了此接口）。此增量方法尽可能减少了从战术服务到 CCMS 的迁移工作。
从遗留客户数据系统迁移到 CCMS 所需的成本和资源导致有必要采用没有干扰的渐进迁移路线。由于 IBM 处理过很多设计用于满足企业需求的常见服务，将会通过一段时间以渐进方式迁移到这些服务，并可以采取积极有效的措施进行加速，以快速讨论遗留客户数据存储库。
