和很多其他企业一样，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. 案例研究的业务成果总结

　　案例研究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子系统间订单批处理方式的差异而导致收益损失的可能性
　　·通过加速更新周期和允许以增量方式重写、更改和重新部署功能来更快、更简单地满足业务需求
　　·允许通过建模和监视业务流程模型来进行业务流程管理。

　　图1. 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业务流程要使用的业务对象，用于在组件间进行通信。

　　开发构件——业务流程执行语言（Business Process &#101xecution 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是在实现工作流前由涉众定义的，可提供每小时通过系统的平均订单数量、系统处理的无效订单数量以及操作员处理无效订单的平均时间等交付信息，从而便于从业务的角度监视系统运行情况。最后，执行人员可以使用通过监视应用程序收集到的信息来进行业务流程更改决策，以满足业务单位性能目标。

　　业务成果

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

　　·订单事务处理时间从4分钟缩短到10秒。在COATS中，每天平均有大约2,500个请求（高峰时，每小时300个）。因此，节约了四分钟时间，总共节约的时间每天可能超过150个小时，所以在转换完成后，可以提高每天的订单处理速度。

　　·这个解决方案简化了系统间的集成方式，支持可减少交付计划中的差异的实时事务。

　　·能够通过简单的可选择规则对运行时工作流进行随需应变的更改。

　　·新系统消除了开发流程中的冗余

　　开发周期中的这些改进意味着，IBM能够更灵活地应对与其他订单执行流程相关的不断更改的业务需求
　　开发时间和成本节约超过25%

　　·包含了更好的错误处理工具，能够更快地进行异常处理，从而提高了收益。

　　·在此工作期间，我们获得了大量可重用的开发资产和最佳实践。此活动帮助我们强化了SOMA方法（请参见参考资料）。

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

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

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

　　不要包含活动细节——细节应该在用例中进行记录
　　创建业务流程模型的同时创建数据模型

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

　　通过阅读developerWorks系列文章“On demand business process life cycle”（请参见参考资料），可以了解有关如何构建可重用资产来转换订单处理系统的更多信息。

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

　　业务上下文

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

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

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

　　挑战

　　2000年中期，IBM Microelectronics遇到了与其他同行类似的挑战：

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

　　基于SOA的解决方案

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

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

　　服务示例：

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

　　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远程通信访问，也可以通过供应商的防火墙由供应商访问。

　　体系结构解决方案的突出特点：

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

　　业务成果

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

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

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

　　在此活动期间，我们获得了一些重要的经验教训：

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

　　关于作者

　　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的成员，拥有乔治华盛顿大学的计算机科学硕士学位，主修软件与系统，辅修人工智能与仿真。