IBM 内的 SOA 应用，转载来研究一下

蚂蚁飞 · 发表于 2007-3-29 09:55

(！接上)

[B]服务示例： [/B]

[List]
Wafer Die Disposition：各种与晶片制造及测试相关的功能。这些功能最初的目的是为了用于外包制造，但正越来越多地用于内部用途。
Manufacturing Execution System Transaction：为大量制造执行系统提供无依赖性的接口，允许查询制造批次状态和属性。
Module Disposition：支持涉及到模块制造和测试的各种功能
ULL Generator：支持基于规则生成特定于位置的唯一通用批次标签（Universal Lot Label，ULL）。ULL 服务通常针对每个独特的 MDI 位置进行了自定义，以使用位置特定的规则生成 ULL。

[/List]

MDI 是在经过验证的 IBM 中间件和操作管理产品基础上构建的。这些产品包括 DB2®、WebSphere Application Server、MQSeries®、WebSphere Business Integration Message Broker、WebSphere Business Integration Connect 和 Tivoli Management Environment® for Monitoring。由 IBM Global Technology Services 将其安装在 IBM 和供应商的工作区内。供应商安装在 IBM 托管服务器上的非专用区域，可通过 IBM 远程通信访问，也可以通过供应商的防火墙由供应商访问。

[B]
体系结构解决方案的突出特点：
[/B]

[List]
快速外包：一个由标准驱动的公共机制，用于和 IBM 内部及供应商制造工具进行交互，可以促进将 IBM 的制造工作有效外包。
“盒子里的服务”：一个全新的概念，允许在远程位置方便地传输和管理一组预定义的可配置服务。
外部化的业务规则：MDI 中的规则引擎已与操作代码分离，可提供灵活性，能在无需重新编码的情况下针对新业务情况进行调整。
“虚拟工厂”：受业务域（每个域都具有自己的一组流程和数据）间的技术隔离层框架支持的 MD 的黑盒实现。
服务：将新功能和遗留功能分解为可重用服务。
[/List]

[B]
业务成果
[/B]

此解决方案为 IBM Microelectronics 创建了一个“虚拟”制造系统，涉及多个可互换的集成合作伙伴（供应商）——通过 SOA 实现的“盒子里的工厂”。

例如，Technology Group 将半导体测试工具外包给 Amkor Technologies，从而使得 IBM 系统在从 IBM 进行迁移的过程中仅停机四个小时，而在以前通常需要三天才能实现其新的支持 SOA 的体系结构。规则已更新到新工具的路由事务，而这个转变在很大程度上对普通操作是透明的。而这正得益于 MDI 的“盒子里的工厂”构造所实现的模块化技术。此外，这个“预先打包”的 SOA 体系结构现在可方便地完成外包计划，比针对每个新机会进行自定义更为高效。这就可以在数周前进行计划，而无需像以前一样需要三个月前就开始计划工作。

[B]所用的最佳实践及获得的经验教训[/B]

在此活动期间，我们获得了一些重要的经验教训：
[List]
业务域的虚拟化及与相关流程和数据的隔离形成了一个“隔离框架”，可实现域之间最佳的分离，从而实现了“虚拟工厂”
规则引擎中包含的外部化业务逻辑与主要操作代码和服务分离，允许更快地进行业务流程更新
可以使用工具 Beta 版，从而有助于为将来的项目定义工具需求
在启动项目前完成 SOA 试验项目可帮助更有效地发挥技术的作用，减少对项目计划的影响。
[/List]

[B]致谢[/B]

我们要感谢以下同事提供的观点以及通过提供案例研究经验报告而为撰写本文做出的贡献：Jim Doran、German Goldszmidt 和 Dick Panko。

IBM Technology Group 的一个核心团队定义了案例研究 2（Microelectronics“盒子里的工厂”）的策略、体系结构和实现。负责 IBM 内这个优秀的 SOA 示例的主要人员有 Steven Pike（体系结构经理）、Mike Maslack（策略专家）和 Dave Lutton（开发团队负责人）。

我们还要感谢很多 IBM 同事、顾问、架构师、开发和项目经理，他们开发和描述了本文中的创新解决方案，并花时间记录和共享他们得到的经验和教训——最佳实践和反模式。由于涉及人员太多，恕不一一提及。

[B]关于作者[/B]

Luba Cherbakov 是 IBM 杰出工程师和 IBM Academy of Technology 的成员，是 IBM Global Services 一位重要的技术领军人物。在使用面向服务和基于组件的方法进行企业体系结构设计和复杂分布式应用程序开发方面，她是一位得到广泛认可的专家。Luba 是一位重要的体系结构设计者，为很多客户行业提供了很多复杂的一流 IBM Global Services 解决方案。Luba 负责了 IBM 面向服务的建模和体系结构方法的开发。她编写并倡导使用参考体系结构资产、体系结构描述标准和网格计算产品。Luba 获得了 IBM 杰出技术成就奖。Luba 是 IEEE 计算机学会、Society of Women Engineers 和 ACM 的成员，拥有乔治华盛顿大学的计算机科学硕士学位，主修软件与系统，辅修人工智能与仿真。

吉普赛人 · 发表于 2007-3-29 10:00

这么巧，一上来，就看到更新的文章，阅读，谢谢楼主！

蚂蚁飞 · 发表于 2007-3-29 10:01

下面部分将介绍以下案例研究

案例研究 3：法律法规遵从方面的 Export Validation Export Validation Service (EVS)
案例研究 4：Central Customer Master System [CCMS]

EVS 和 CCMS 分别代表了遵从性管理和“作为服务的信息”方面的主要 IBM 内部解决方案。考虑到政府法律法规要求的复杂性不断增加，以及管理联合数据源来支持位置透明性的需求（有关更多信息，请参见参考资料部分），这两个服务无疑是 IBM 内部 SOA 解决方案的突出例子。

蚂蚁飞 · 发表于 2007-3-29 10:11

[B][B]

案例研究 3：法律法规遵从方面的 Export Validation Export Validation Service (EVS)
[/B][/B]

[B]
业务上下文
[/B]
美国出口法律法规规定了有关可将哪些物品出口到境外的哪些对象的限制。这些法律法规适用于涉及最广泛意义上的任何出口类型的所有情况——包括从美国向任何其他国家/地区提供硬件、软件、服务、工具或技术。除了传统的物理交付方式外，通过电子方式将软件或技术信息提供给美国之外的实体（个人、公司、组织、政府）也受到控制。

可能不可将与国家安全相关的特定产品或技术（如加密技术、核武器、化学或生物武器、或导弹）售出或提供给规定名单中的国家/地区。美国政府发布了一份实体名单，称为出口管制黑名单（Denied Parties List，DPL），不允许美国公司与其中的实体开展任何形式的业务。另外，美国政府还发布了禁运或恐怖主义相关的国家/地区名单，从而对业务活动进行了进一步的限制。

[B]挑战[/B]

正式制定的用于确保符合政府法律法规的策略正变得越来越重要，需要在企业级别加以控制，以避免巨额罚款和其他由于违规而导致的负面影响。IBM 的 Export Regulation Office (ERO) 负责 IBM 必须如何遵循美国出口法律程序，并每月更新美国政府关于不能与之开展业务的个人、公司和国家/地区的名单。IBM 的在线软件销售和下载（免费和付费软件）需要更为自动化的方法来对交付内容及其接受人进行实时验证。这对于保证不会违反美国的相关限制非常必要。

在 IBM 内已部署了多个应用程序来支持美国出口法律法规遵从。由多个业务领域实现了多个出口检查的版本。它们都需要包含 ERO 每月更新的管制名单，以避免执行费时的手工任务来恢复与规定的名单上的实体进行的错误业务事务。公司内出口管制功能的大量增加带来了不必要的开发和维护成本，而且 ERO 需要与多个开发团队合作来确保遵从一致性。

IBM 的 Software Delivery and Fulfillment (SDF) 组织最初为自己的在线销售和交付功能创建执行各种出口检查的功能。不过，他们需要更为高效的解决方案，以便方便地进行集成，以供自己使用；此解决方案还需要具有高度可重用性，以便将其功能扩展到其他的企业部门。SDF 的业务模型允许其接受来自潜在服务使用组织的新需求，从而促进在公司内更广泛地使用服务。

此解决方案需要处理的挑战简要小结如下：
[List]
美国萨班斯·奥克斯利 (Sarbanes-Oxley) 法案提高了对需要新 IBM 内部服务来支持对各种政府法律法规遵从的认识。
应用程序之间的冗余性以及过多的开发和维护成本。
每个月需要对多个应用程序进行更新，以将美国政府的出口管制名单包含到各自的本地副本中。
如果未及时包含出口管制名单的更改，则可能导致在 IBM 的 Integrated Supply Chain 流程中出现延迟。
[/List]
[B]
基于 SOA 的解决方案[/B]

与其他几个早期 SOA 业务解决方案类似，此服务的基础已经存在于 Web 应用程序，在本例中即为对通过浏览器下载软件的客户执行实时检查的应用程序。2003 年 12 月，SDF 组织对其面向浏览器的基础设施进行了扩展，创建了基于 SOAP 的 Web 服务，即 Export Validation Service (EVS)。它允许其他请求者调用其客户分析功能，以便遵循美国政府出口法律法规。

根据提交的客户人口统计学信息（如名称、地址、位置、IP 地址以及涉及的 IBM 服务产品），此服务当前支持多个关键领域的出口检查：
[List]
进行以下方面的用户检查：1) 与美国政府的 DPL 进行比对；2) 详细审核，以避免将可用于导弹、化学与生物武器或核用途的技术扩散到指定的国家/地区；3) 与美国政府的禁运国家/地区名单进行比对（通过地址、电子邮件或 IP 地址）
加密产品检查，以控制包含强加密的加密产品的出口
按照丹麦和爱尔兰政府的要求进行专门的出口检查（支持这两个国家的 IBM 软件执行操作）
[/List]

除了 HTTPS 上的基于 SOAP 的 Export Web 服务外，此关系图还显示了更新 DPL 的后台流程——手动访问 ERO 的正式更新名单，然后使用 DPL Administration Tool 来将最新的更新包含到 EVS 数据库中。另外还描述了用于在“模糊”逻辑不正确地确定某个客户在规定名单中时覆盖错误的确定信息的管理员功能 (Override Administration Tool)。必须进行此提交信息的模糊分析，以处理名称类似而拼写存在细微差别的情况。

和很多业务服务一样，EVS 并不是完全独立的功能，它与手动业务流程进行了集成，以提供额外的服务价值。存在“人工服务总线”(Human Service Bus) 的概念，用于将人工任务集成到组织化结构中，并与服务实现进行协作，以确保遵循企业标准，而在本例中，这也反映了政府的法律法规。

此开发团队最开始使用 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 业务流程中启用，将供由需要进行客户检查来遵循出口遵从性的新流程使用。这包括销售时（网上或通过电话）的事务以及在向客户交付货物前的最后检查。

[B]
业务成果
[/B]

现在能以实时的方式更方便地将美国政府出口管制集成到所有与客户的网络和电话交互中。这个服务现在支持采用集中而一致的方式执行所有 IBM 出口检查功能，并确保及时将美国政府更新的管制名单包含进来，从而消除受到政府处罚的风险。

EVS 的基于服务的可重用性降低了与为多个应用程序构建冗余出口管制功能相关的开发和维护成本。除了成本外，还通过提供使用现有服务（而不是构建新功能）来减少了开发计划。

EVS 在 IBM 的企业目标体系结构中定义为主要的 SOA“企业组件”，实际就将其定义为了供所有 IBM 的业务单位重用。EVS 正在作为潜在的 IBM 商业资产进行评估，因而 IBM 可能会为客户的业务流程同时提供此服务和手动覆盖流程。企业和业务单元体系结构治理组织要协同工作，以确定何种情况下应用程序必须使用这些企业组件，而不是构建冗余功能。

[B]

所使用的最佳实践及获得的经验教训
[/B]

在处理多个业务部门的需求时，经常会考虑采用集中资金投入的企业服务。很多企业服务都通过其属于承担整个企业的业务功能任务的组织的方式来进行集中资金投入。EVS 采用了一种不同的业务模型，在其中，为满足新需求而对服务进行的更新由每个请求针对其独特需求进行更改的服务使用者组单独提供资金投入。这个模型非常成功地确保了 EVS 获得足够的资金投入，以应对新业务方向的挑战。

不过，由于采用此业务模型，使用增量开发一次满足新使用者的一个需求，有时候会导致功能改进延迟。具有独特需求的新使用者有时候不愿意为企业级服务的一般性基本功能元素提供资金投入。为了将 EVS 扩展到软件产品之外更大的企业范围需要进行更新，以获得更好的稳健性，从而确保 EVS 能够处理额外的负载。这种情况的一个例子是基于 Perl 脚本的旧代码，除了进行其他性能改进外，还必须将此代码转换为 Java™。一般企业功能（功能性和非功能性的）都在新客户具有与企业类似的需求时由 EVS 团队采用增量方式加以处理，并接受 IBM 业务转换 CIO 提供的一定指导和资金注入。

EVS 说明了使用者业务所有者需要了解更多信息，而不仅仅是其自己自动使用某个特定的 Web 服务。当前在 EVS 中需要一个手动后端流程，以进行潜在的错误出口检查结果的后续处理。很多使用者开发团队经常只将精力放在服务的接口上，事实上还需要考虑手动支持功能，这也能增强服务的有用性。

图 1 中所示的解决方案包括采用 ERO 美国政府出口管制黑名单更新形式的分散企业数据。
图 1. Export Validation 体系结构概述

蚂蚁飞 · 发表于 2007-3-29 10:21

[B][B]
案例研究 4：Common Customer Master System——IBM 内的单一客户视图
[/B][/B]
[B]
业务上下文
[/B]

根据使用的通道（如呼叫中心、Internet 和业务合作伙伴）不同，IBM 有时候会让客户觉得像独立操作的多家公司。客户的体验以及客户组织和联系信息有时候会缺少一致性和连续性。这对客户满意度造成了负面影响。为了处理这个问题，IBM 部署了 Common Customer Master System (CCMS)，这是一个基于 SOA 的解决方案，支持为其客户提供“一个 IBM”的体验。

CCMS 的主要业务目标有：
[List]
通过将所有 IBM 客户数据合并到单个系统和关联的存储库中，从而消除存在于 IBM 内的多个客户信息实例以及对应的冗余维护开销。从这些其他分布式客户存储库获得的信息将退出历史舞台，由这个单一的系统予以取代。
通过将组织层次结构合并到客户数据中，从而使得客户信息更有意义、更有用。组织层次结构提供有关不同业务实体彼此如何相关、其地址以及分支机构的业务信息。必须每月对这些层次结构进行更新，并作为 IBM 的组织层次结构数据受信任来源提供。
改进客户数据质量
通过图形用户界面（浏览器）提供直接用户可访问性，从而提高客户信息使用率。
提供服务接口，从而允许服务使用应用程序将这个集中的系统作为 IBM 所有客户信息的单一客户记录创建和客户信息源加以使用。
[/List]

[B]挑战[/B]

问题的范围以及复杂性包括：
[List]
集成来自不同数据源的客户数据——包括 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 支持的内聚解决方案
需要以一致的方式引入能够统一进行实现的新规则，包括：
[List]
将每个数据元素从数据源的数据模型映射到新的集中数据模型的业务规则，包括数据质量和可接受的值要求的列表
每个数据源的数据元素的转换规则，这些规则对在 CCMS 中创建和维护数据是非常必要的
所有数据源的数据元素的数据聚合规则，也对在 CCMS 中创建和维护数据非常必要
[/List]
[/List]

[B]基于 SOA 的解决方案[/B]

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。
将现有资产转换为服务的示例有 Address Standardization Service、Matching Service 和 Assign Key service。地址标准化和匹配（检查记录是否唯一）的服务是通过包装现有遗留 Trillium 引擎提供的功能创建的。这些通过封装 Trillium 创建的服务现在可以在其他客户信息业务流程中重用，而不仅限于客户更新流程中。另一个步骤涉及到在没有现有基础可重用的情况下创建新服务，如 CCMS Persistence Service。
图 2. CCMS 体系结构概述

蚂蚁飞 · 发表于 2007-3-29 10:22

[B]业务成果[/B]

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 的单一客户记录创建点和客户数据的主要来源。此外，可从多个业务部门方便地交叉引用客户信息带来新的销售机会。这还允许以增量的方式逐渐讨论很多冗余客户信息数据源。

[B]所使用的最佳实践及获得的经验教训[/B]

CCMS 是另一个 SOA 解决方案示例，其中后端流程在管理从服务接口提供的信息的过程中扮演着重要的角色，而服务接口不过是冰山一角而已。在部署服务接口前，CCMS 首先需要创建所有 IBM 客户信息的集成视图。这涉及到利用 WBI Server Foundation 提供的业务流程灵活性创建操作工作流，以将其用于管理多个来源的客户数据。

和很多企业关键应用程序一样，“大爆炸 (Big Bang)”方法费用太高，且会带来干扰。在开发 CCMS 后端流程管理客户信息之前，需要使用 Web 服务来访问主要客户信息。部署了一个战术性的解决方案，从而向现有 RDc 连接点公开了一个服务接口。此战术实现使用了策略客户信息访问接口（CCMS 最终部署了此接口）。此增量方法尽可能减少了从战术服务到 CCMS 的迁移工作。

从遗留客户数据系统迁移到 CCMS 所需的成本和资源导致有必要采用没有干扰的渐进迁移路线。由于 IBM 处理过很多设计用于满足企业需求的常见服务，将会通过一段时间以渐进方式迁移到这些服务，并可以采取积极有效的措施进行加速，以快速讨论遗留客户数据存储库。

[B]致谢[/B]

我们要感谢以下同事提供的观点以及通过提供案例研究经验报告而为撰写本文做出的贡献：Geoffrey Meissner 和 Carl Osipov 与我们共同撰写了本系列中的文章；EVS 架构师 LeeAnn Kania 和 Greg Terwilliger 在其领导的 EVS 工作中率先尝试 SOA，并提供了对本文颇有价值的体系结构文档；Bob Fremin、Jim Anderson、Wes Williams、Tim Owings 和 Scott Joffe 在其 CCMS 策略实现中扮演了重要的角色。

我们还要感谢很多 IBM 同事、咨询师、架构师、开发和项目经理，他们开发了很多创新性的 SOA 解决方案，并挤出宝贵的时间记录和与我们分享所得到的经验和教训。由于涉及人员太多，恕不一一提及。