IBM内部的SOA案例研究（一） | ERPWorld.net-信息推动产业

案例研究 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 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 是在实现工作流前由涉众定义的，可提供每小时通过系统的平均订单数量、系统处理的无效订单数量以及操作员处理无效订单的平均时间等交付信息，从而便于从业务的角度监视系统运行情况。最后，执行人员可以使用通过监视应用程序收集到的信息来进行业务流程更改决策，以满足业务单位性能目标。
业务成果
应用基于 SOA 的新解决方案的若干增量版本后，提高了业务性能和灵活性。此外，也实现了减少开发成本和缩短开发周期的目标。业务成果简要总结如下：
订单事务处理时间从 4 分钟缩短到 10 秒。在 COATS 中，每天平均有大约 2,500 个请求(高峰时，每小时 300 个)。因此，节约了四分钟时间，总共节约的时间每天可能超过 150 个小时，所以在转换完成后，可以提高每天的订单处理速度。
这个解决方案简化了系统间的集成方式，支持可减少交付计划中的差异的实时事务。
能够通过简单的可选择规则对运行时工作流进行随需应变的更改。
新系统消除了开发流程中的冗余
开发周期中的这些改进意味着，IBM 能够更灵活地应对与其他订单执行流程相关的不断更改的业务需求
开发时间和成本节约超过 25%
包含了更好的错误处理工具，能够更快地进行异常处理，从而提高了收益。
在此工作期间，我们获得了大量可重用的开发资产和最佳实践。此活动帮助我们强化了 SOMA 方法(请参见参考资料)。
所用的最佳实践及获得的经验教训
此活动帮助我们创建、实现和获得了将遗留业务功能以增量方式转换为实时而灵活且支持 SOA 的解决方案的方法。所用的最佳实践及获得的经验教训简要总结如下：
使用服务的增量实现获得早期的支持，通过对预期情况进行管理来实现无干扰迁移。与遗留代码服务共存，支持将系统功能逐步过渡到新体系结构。
通过服务建模保持业务/IT 体系结构一致。
要开发灵活的业务流程，需要在方法和工具的支持下考虑整个服务生命周期——从建模到监视。
遵循迭代设计和增量开发方法，采用建模、设计和集成模式(请参见参考资料)。
创建早期 BPEL 流程模型
不要包含活动细节——细节应该在用例中进行记录
创建业务流程模型的同时创建数据模型
我们通过恰当使用服务建模、增量开发方法、工具和中间件组件说明了如何进行增量转换。在此活动中确定的流程自定义、增量转换和遗留集成方法正在 IBM 和我们的客户中广泛应用。