在 IBM 的开发者网站发现了一个，关于 IBM 内部SOA 应用的帖子，还是中文的，给大家持续转载，学习下。

注引：

和很多其他企业一样，IBM 在对自身进行转换，以应对激烈的全球竞争和伙伴合作关系、实际的安全威胁、过多的日常需求、成本压力以及更高的灵活性和敏捷性要求。面向服务的思考方式和面向服务的体系结构（Service-Oriented Architecture，SOA）在此转换过程中扮演着重要的角色。

本系列将描述七个 IBM SOA 支持的转换活动，按照不同的业务价值主张进行划分——从法律法规遵从到更灵活的业务模型，再到通过消除重复系统和流程减少成本。对于每个案例研究，我们都将描述业务情况和挑战、有效进行转换所需的更改、SOA 支持解决方案和实际业务成果。我们还描述了所使用的最佳 SOA 实践、支持解决方案的技术以及所得到的经验教训。本文是本系列的第一篇文章，将详细说明 Customer Order Analysis and Tracking System (COATS) 和 IBM Microelectronics 的“盒子里的工厂 (Factory in a box)”。

引言

人们对当前业务环境和正在发生的巨大变化进行了大量的讨论：来自传统和非传统对手的激烈竞争、不断变化的法律法规遵从要求、创造新收益来源的压力以及对更多创新和更高灵活性的要求。为了在这种环境中取得成功，各个企业正在进行转换工作，开始重新思考行业结构，准备实现组件化和采用面向服务的方法来实现所需的灵活性。

SOA 受到越来越广泛的接受，正逐渐成为支持此类业务转换的主要技术，可提供业务流程和启用 IT 支持之间更紧密的联系。虽然 Ron Schmelzer 和 Jason Bloomberg（ZapThink，2006 年 4 月，请参见参考资料）等很多分析家称 IBM 是其客户“面向服务的体系结构运动中的主要先锋之一”，但在过去数年中，IBM 本身也在进行 SOA 支持业务转换。

客户经常要求我们分享 IBM 内部的此类经验。在本文中，我们将简单介绍七个 SOA 案例研究中的前两个——真正的内部转换活动。后续文章将讨论剩下的其他案例研究。每个活动都已有了实际的业务成果，并提供了宝贵的经验和教训：

案例研究 1：Customer Order Analysis and Tracking System [COATS]
案例研究 2：Microelectronics“盒子里的工厂”[Microelectronics]
案例研究 3：Export Validation 法律法规遵从 [Export]
案例研究 4：Central Customer Master System [CCMS]
案例研究 5：IBM Intranet Password——内部应用程序标识管理 [IIP]
案例研究 6：IBM Intranet Password——外部业务合作伙伴应用程序标识管理 [IIPX]
案例研究 7：客户 Web 标识管理 [Web Identity]

我们专门精选了这些案例研究来代表利用 SOA 解决的各种业务挑战。其中一些挑战通常会出现在跨行业场景中，如第五、六、七个案例研究。其他案例（如第二个案例）是特定于行业的，其中也包含可由 SOA 成功处理的典型挑战。

那些仍然在问为什么应该考虑 SOA 的读者或需要为其采用创建业务用例的读者会发现，表 1 和每个活动的业务驱动因素的详细描述非常有用。

对于每个案例研究，除了业务上下文，我们还描述了活动必须克服的挑战、所得到的解决方案的体系结构概述及其支持技术和工具。我们还将描述每个活动实现的实际业务成果和我们所获得并在 IBM 及我们的客户中得到应用的最佳实践和“经验教训”。

不错， 谢谢 楼主 ！
阅读

谢谢，继续转载

SOA 价值主张

在过去几年中，作者和 IBM 同事曾与数百客户协作，以实现基于 SOA 的解决方案来解决各种业务问题。虽然所有人都在谈论总体的业务灵活性和敏捷性，但每个活动通常都是由一个具体的业务价值主张（或希望的业务成果）驱动的。企业采用 SOA 来应对不同的业务挑战。希望的业务成果可以由下表中所示的多个类别进行表示。

表 1. SOA 采用的业务价值主张

业务价值主张                    业务驱动因素
---------------------------------------------     ----------------------------------------------------------
业务流程灵活性^^^^^^^^^^^^^^^^快速对市场变化做出响应
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^改进上市时间

减少外部流程成本和周期时间^^^^从手动事务过渡到自动事务
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^促进与业务合作伙伴的协作

减少风险和对外暴露程度^^^^^^^^提高业务操作的可见性

法律法规遵从^^^^^^^^^^^^^^^^^  符合政府强制要求
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^符合行业法规

简化系统集成^^^^^^^^^^^^^^^^^^集成以前的独立系统
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^便于处理合并和收购的情况

降低成本^^^^^^^^^^^^^^^^^^^^^^消除重复系统、技能和投资
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^一次性构建功能，方便重用
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^提高效率

-------------------------------------------------------------------------------------------------------------

成功的 SOA 实现可以实现多种不同的业务成果，而通常是由一个或两个关键驱动因素促成相关活动的。尽管通过服务重用实现的好处可以减少开发和集成的成本这一事实非常重要，但就长远来看，SOA 的业务转换价值却更为重要。

在以下部分中描述的 IBM 案例研究具有不同的预期结果（公司内部和外部）， 如表 2 中所示。
表 2. 案例研究的业务成果总结
^^^^^ ^^^^^^^^^^^^^^^ COATS Microelectronics Export CCMS IIP IIPX Web Identity
业务流程灵活性^^^^^^^^^^^^  X X - X - X X
减少外部流程成本和周期时间^^^^^^  - X X X - X X
减少风险和对外暴露程度^^^^^^^^^  - X X X X X X
法律法规遵从 ^^^^^^^^^^^^^  - - X - - - -
简化系统集成 ^^^^^^^^^^^^^  X X X X - X X
降低成本 ^^^^^^^^^^^^^^^^  X X X X X X X

(! 其中，X 代表涉及，- 代表不涉及)

案例研究 1. Customer Order Analysis and Tracking System：从遗留结构到随需应变



业务上下文

Customer Order Analysis and Tracking System 是供全球二十多个工厂使用的共享订单输入应用程序，每个工厂都具有自己的自定义需求和访问模式，如“高容量低价格”与“高价格低容量”。COATS 是 IBM Supply Chain 的一部分，在订单执行中扮演着重要的角色，可处理大量订单，帮助每天处理 10,000 个以上的包裹。COATS 提供全天候服务，可接受 IBM 客户、业务合作伙伴和 IBM 销售专业人士的复杂配置硬件订单：System i、System p、System z、Storage、Printers 和 Retail。

购买者通过提交有关新计算机、升级、定制的订单和对现有订单的其他更改来间接访问 COATS。应用程序会将这些订单与制造规则和客户已安装硬件库加以比较，从而进行排序和确定优先级。COATS 会将订单流“翻译”为制造材料列表（物料清单，Bill of Materials）和其他指令，这些内容通常被转发到全球相应的 IBM 制造工厂。制造工厂将随后开始执行订单，并运送到客户的收货地点。订单的一个例子是指定了详细规格、预装软件和交付日期等的大型机。对应的输出示例将包括特定工厂的制造车间的配置，而对应的相关术语包括物料单、配置计划等。


挑战


原始应用程序是已经使用了 25 年的复杂旧式批处理系统。其中包含 140 万行 PL/1、OS/390 汇编语言、Java 和其他编程语言代码，峰值时已非常接近其处理容量极限。批处理瓶颈和冲突数据对订购和配送造成延迟。

COATS 具有硬编码的业务规则、过程、逻辑和数据访问，已发展为难于针对现有和新兴业务需求进行调整的系统。更改业务流程通常要求进行大量的重新编码工作：开发人员必须理解一组复杂的点到点连接和组件独立性，以便预测变更的效果。为了应对不断发生的订单变化（包括调度系统为了满足客户的交货日期而进行的自动调整），必须对多个数据库进行更新和查询，具体取决于地理位置和其他参数（如所保留的五到十年的计算机销售历史记录等）。

为了支持新活动、新产品和业务机会，频繁地对应用程序进行了更新。由于采用了严格的遗留代码，花费了大量资源（时间和资金）进行新功能开发——每个版本的开发时间都要花费六个月时间，占用超过 8,000 小时开发时间。

存在这样的实际需求，需要提高对功能和驻留在现有遗留系统中的宝贵业务数据的访问，并要求能够从其他系统方便地进行访问。

和很多企业关键应用程序一样，大规模进行替换费用太高，且会带来干扰。


基于 SOA 的解决方案


COATS 转换项目的重点在业务涉众认为非常重要的几个目标上：

降低应用程序更改或错误导致的生产停滞频率
降低由于 COATS 子系统间订单批处理方式的差异而导致收益损失的可能性
通过加速更新周期和允许以增量方式重写、更改和重新部署功能来更快、更简单地满足业务需求
允许通过建模和监视业务流程模型来进行业务流程管理。

订单管理组件服务项目负责将总体 COATS 系统转换为实时的订单提交系统。

解决方案的面向服务的体系结构（参见图 1）对业务流程和 IT 需求进行了标准化。在此体系结构中，业务规则被外部化，而遗留系统功能则被组件化，以便提高灵活性、可伸缩性和重用性。

Order Process Subsystem 负责接收处理客户订单组的请求，并随后将订单发送到其他服务。此系统能够处理多个通道，包括用于实时处理和批处理的 B2B 消息传递系统。

接收到订单后，Order Process Subsystem 将其标记为需要进行验证，并将订单转发给 Validation and Topology Generation 服务。该服务将进行分析，并为不同类别的订单使用专门的验证服务。

传递验证步骤的制造订单组将随后发送到 Manufacture Plant 服务，以转换为物料单，并转发给制造工厂。这些服务将通过服务适配器与实际向目标工厂交付物料单的现有遗留应用程序或业务合作伙伴应用程序交互。

开发过程将首先从支持 IT 系统中分离业务流程和数据。在 IBM WebSphere® Business Modeler（以下称为 Business Modeler）内对业务流程进行了建模和表示。

COATS 开发团队采用了迭代的方法进行此转换项目。迭代过程从使用 Business Modeler 进行业务分析开始，业务分析的目的是为了构建原始 COATS 应用程序中使用的“原样”业务流程的模型。获得了模型后，分析人员就能够确定进行改进的机会、提出更改建议，并能够预估更改对 COATS 应用程序的影响。此外，对“原样”模型的分析还能帮助标识现有资产，以供进行重用。

为了创建模型的“原样”版本并最终确定业务流程的规范，团队使用了业务涉众认为重要的项目目标来确定服务和组件。这些目标用于定义标识“原样”模型的各个领域的决策标准，以从转换到利用工作流和业务规则的灵活实现获得最大的好处。

为了标识和指定 COATS 业务服务，该团队采用了一种可重复方法，而这个方法后来促成了 IBM 面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的形成。SOMA 是一种旨在通过从 SOA 基础标识、指定和实现与业务一致的服务来支持目标业务流程的方法。SOMA 将业务特征扩展到 IT 分析和体系结构决策中，从而创建了业务意图与 IT 实现间的连续体。SOMA 期间执行的分析和建模工作并不特定于技术和产品，而是要建立一个上下文，以便在生命周期的以后阶段进行技术和产品特定的决策。其目标是提供 SOA 建模（分析和决策）的指南。IBM 流程工程师和架构师将 SOMA 用于进行客户合作项目和内部项目。

在进行业务分析的同时，数据架构师使用了 Rational ® eXtended Development Environment 来定义基于统一建模语言（Unified Modeling Language，UML）的数据模型。这些数据模型表示 COATS 业务流程要使用的业务对象，用于在组件间进行通信。

图 1. COATS 体系结构概览


开发构件——业务流程执行语言（Business Process Execution Language，BPEL）、Web 服务描述语言（Web Service Definition Language，WSDL）、XML 模式定义（XML Schema Definition，XSD）和 Business Modeler 与 Rational eXtended Development Environment 产生的基于 Java 的数据模型实现——都由集成开发人员通过使用 WebSphere Studio Application Developer Integration Edition 工具进行了进一步增强。开发团队使用了 WebSphere Studio Application Developer Integration Edition 来实现以下更改，以完成工作流实现：

通过创建到 MQSeries® 和 CICS® 的适配器来允许访问遗留系统
添加用于人工决策和异常处理的成员活动
将决策点重构到存储在外部 BRBean 存储库中的业务规则内
与 WebSphere Portal 表示层集成。

COATS 的生命周期扩展到了开发之外，包含业务流程管理的各个方面。开发迭代产生应用程序的可部署工作版本（应用程序的工作构建）后，业务分析人员可以通过跟踪关键性能指标（Key Performance Indicator，KPI）来监视系统的实时性能。KPI 是在实现工作流前由涉众定义的，可提供每小时通过系统的平均订单数量、系统处理的无效订单数量以及操作员处理无效订单的平均时间等交付信息，从而便于从业务的角度监视系统运行情况。最后，执行人员可以使用通过监视应用程序收集到的信息来进行业务流程更改决策，以满足业务单位性能目标。

(替楼上的上传图片如下)

图 1. COATS 体系结构概览

！谢谢楼上的朋友， 请让我继续贴上来：

业务成果

应用基于 SOA 的新解决方案的若干增量版本后，提高了业务性能和灵活性。此外，也实现了减少开发成本和缩短开发周期的目标。业务成果简要总结如下：

订单事务处理时间从 4 分钟缩短到 10 秒。在 COATS 中，每天平均有大约 2,500 个请求（高峰时，每小时 300 个）。因此，节约了四分钟时间，总共节约的时间每天可能超过 150 个小时，所以在转换完成后，可以提高每天的订单处理速度。
这个解决方案简化了系统间的集成方式，支持可减少交付计划中的差异的实时事务。
能够通过简单的可选择规则对运行时工作流进行随需应变的更改。
新系统消除了开发流程中的冗余
开发周期中的这些改进意味着，IBM 能够更灵活地应对与其他订单执行流程相关的不断更改的业务需求
开发时间和成本节约超过 25%
包含了更好的错误处理工具，能够更快地进行异常处理，从而提高了收益。
在此工作期间，我们获得了大量可重用的开发资产和最佳实践。此活动帮助我们强化了 SOMA 方法（请参见参考资料）。


所用的最佳实践及获得的经验教训

此活动帮助我们创建、实现和获得了将遗留业务功能以增量方式转换为实时而灵活且支持 SOA 的解决方案的方法。所用的最佳实践及获得的经验教训简要总结如下：

使用服务的增量实现获得早期的支持，通过对预期情况进行管理来实现无干扰迁移。与遗留代码服务共存，支持将系统功能逐步过渡到新体系结构。
通过服务建模保持业务/IT 体系结构一致。
要开发灵活的业务流程，需要在方法和工具的支持下考虑整个服务生命周期——从建模到监视。
遵循迭代设计和增量开发方法，采用建模、设计和集成模式（请参见参考资料）。
创建早期 BPEL 流程模型
不要包含活动细节——细节应该在用例中进行记录
创建业务流程模型的同时创建数据模型

我们通过恰当使用服务建模、增量开发方法、工具和中间件组件说明了如何进行增量转换。在此活动中确定的流程自定义、增量转换和遗留集成方法正在 IBM 和我们的客户中广泛应用。

案例研究 2：Microelectronics“盒子里的工厂”


业务上下文

对公司的结构进行分解（划分）并允许将重点放在核心业务竞争力上的做法自然会导致协作生态系统的出现。制造行业首先发现了规范化和协作的强大力量，并使其达到了新的高度，随后这也在电子行业得到了广泛的认可（请参见参考资料）。

在这种协作生态系统中，半导体行业正逐渐从完全自包含的制造系统的垂直集成转向合作伙伴的集成参与网络，其中的每个合作伙伴均能以高效低成本的方式提供专业的制造服务。考虑到当今希望尽可能利用全球资源的经济环境，运营环境也迅速从关注本地力量发展到了关注来自多个国家的力量的全球协作。微电子行业产品解决方案的复杂性不断增加，以满足新客户需求，而这促使自定义解决方案出现了超过传统标准产品服务的势头。这就要求制造系统具有更高的适应能力，且要具有更广泛的执行能力，而这已不再能完全通过“内部”解决方案得以解决了。

2003 年，IBM Microelectronics 认识到需要更大的灵活性，以满足与跨多个场所和供应商的晶片和模块制造关联的不断变化的制造需求。对更高灵活性和响应能力（以获得“随需应变”的制造能力）的需求是虚拟制造企业概念的起源，此概念的重点在于跨多个微电子生产场所（内部的和已外包的）进行制造控制和执行的集成方法。


挑战
2000 年中期，IBM Microelectronics 遇到了与其他同行类似的挑战：
[List]
财务模型：尽管激烈的竞争正导致单个产品单元的成本和价格下浮，但与新产品相关的复杂性和成本却在持续升高。更复杂的解决方案还提高了计划、开发和制造流程的复杂性。当今半导体行业的高级需求易失性带来了高费用投资易失性。经常很难预测产品需求的快速波动和为之准备制造系统。必须对制造基础设施的投资进行策略规划，以与预期或非预期市场情况吻合。
领域集成：尽管现在主要的重点在核心竞争力，但半导体产品存在一定程度的的多样性，需要集成以前独立的制造系统。这个集成需求也适用于各个业务领域，如工程、企业资源规划、测试、机会管理、财务、产品发布、产品设计和开发以及信息数据仓库等。
外包：新全球化趋势提出了集成多个可互换的合作伙伴的需求。内部制造功能必须通过一次性构建功能并在以后加以利用，从而在操作停机时间尽可能少的前提下快速复制到外包供应商。这些供应商功能必须针对晶片制造、晶片测试、模块构建和模块测试等功能进行集成。所有参与者之间的通路必须可靠和安全，而且 IBM 必须能看到出现的所有事件，还必须能够收集产生的所有数据。供应商参与者必须接受 IBM 的一定控制，以获得一致的产品流程结果，而且必须能访问所有必要的功能——即使不是本地/本机环境也应如此。全球化的虚拟制造体系结构要求使用开放的行业标准来提高互操作性和尽可能减少合作伙伴采用 IBM 的接口所需花费的时间。
[List]

基于 SOA 的解决方案


为了处理上述挑战，IBM 的 System Technology Group (STG) 半导体制造部门基于集成的模块化体系结构创建了一套解决方案。他们的目标是创建一个虚拟化框架来管理与高效外包计划并存的内部制造资源，从而形成了他们称为“盒子里的工厂”的新概念。这是一个全球的模块化制造功能“盒子”，包括网络传输、安全性、数据管理、监视、制造控制以及独特的自定义等功能。“盒子里的工厂”是通过将这些功能打包为一组 IBM 软件产品和自定义代码实现的，而这些产品和代码也称为多源数据集成器（Multi-source Data Integrator，MDI）。MDI 安装在 IBM 和供应商合作伙伴的厂区内（如图 2 中所示），以创建 STG 的各种制造业务领域与物理制造安装之间的无缝交互，而不受其位置限制——从而创建了一个虚拟化的制造环境。这允许将供应商视为 IBM 制造环境的扩展。

有人可能会问，“不错，这是一个很好的随需应变业务的例子，但 SOA 在哪里呢？”关键的 MDI 集成元素包括其企业服务总线（通过 Business Modeler Message Broker）和一组基于 SOAP 的自包含 Web 服务。Message Broker 除了完成路由任务外，还可在建立了 ESB 体系结构模式后通过协议和消息转换实现高度分离。有些服务是完全自包含的，仅支持内部 MDI 功能，对盒子外部的任何对象都是透明的。不过，其他服务则可以由 IBM 应用程序用户、供应商应用程序用户访问（有时候两者都可以访问）。正是这样将 SOA 功能打包为可移植的形式，从而使有些人将 MDI 的原始名称改成了“盒子里的服务 (Services in a Box)”。


图 2. 虚拟制造体系结构概述