案例学习：Safeco 的复合应用模型

Safeco 是一家总部位于西雅图的保险公司，它提供汽车、房屋和小企业保险业务。Safeco 建设了一个全国性的代理商网络。调查表明，这些代理商高度认可公司目前的 Web 销售服务平台，认为它是业界最好的。这个平台前端用.NET 开发，后端则是使用了多年的 IMS 应用系统。

2006 年初，Safeco 为了提升产品研发和业务流程运作水平，启动了 SOA 系统项目。即便仅从 IT 角度看，此项任务也是颇具挑战性的，因为我们每次启动的新产品、解决方案和流程优化项目往往都是独立的，缺乏对系统一致性和项目边界的精确度量。我们还必须在减低解决方案实现成本的同时，显著提高对用户的响应速度，从而满足市场需要并实现我们的财务目标。

SOA 介绍

SOA 是实现业务改进和敏捷的良方，因为它的可重用模型为通过复用和扩展现有组件实现新的解决方案提供了可能。现在，通过分布式、特别是面向服务技术，我们可以在性能、扩展性、可靠性、安全性和互用性等多个方面赋予 IT 资源（数据和代码）复用能力，并确保复用成本低廉。依靠传统手段，每次在新地点配置 IT 资源时，都需要耗费一份预算。而使用新的模型，将能从逻辑而非物理上建立一个统一的信息系统。具体来说，就是依靠新型的代理、服务等这些提供了数据和功能访问能力的技术来实现这个目标的。

当然，SOA 并非等同于服务概念，它其实是一个完整的、组件构成式的应用模型（参见图 1）：

1. 所有操作都被定义为规范的、具有严格边界的活动，如用户交互、服务调用甚至整个流程。
2. 这些活动之间实现了松散耦合（如各活动的实现技术和调用堆栈可以不同，但它们之间的连接通道是专用的，安全授权等级是统一管理的）。
3. 每个服务都是整个企业业务流程的一个组成部分，它们协作完成复杂的业务功能。

图 1 SOA 中，整个应用的各个部件松散耦合

在 SOA 中，基础模型上的重要变化，就是将现有应用转化为“Systems of record”（译者注：可理解为原始数据源或数据的第一产生地），并通过实现了 Act、Record、Inform 和 Compute 等活动的服务接口予以呈现。成功转化的关键是将业务流程实例的状态从业务对象的内容中分离出来。分离形成的服务，应该不依赖于它的应用环境。比如，它们不需要知道用户在某个时刻调用它们的原因。服务的实现目标是强化整个系统的集成能力；每个服务，本质上都可以看作是一个纯粹的数据接口层。

至于服务的应用环境管理则由业务流程层负责（参见图 2）。通常情况下，SOA 都将依赖于业务流程引擎实现系统功能流转。

一旦应用模型各层松散耦合后，BAM（Business Activity Monitoring。通过消息流实现对事件的监控）就容易建立了。甚至通过 CEP（Complex Event Processing），BAM 还可将各个事件相互关联起来。

图 2 SOA 应用模型

技术选择

Safeco 在其项目中选择了 Microsoft 的 WCF（Windows Communication Foundation）实现服务层、IBM 的 WPS（WebSphere Process Server）实现流程层和 ASP.NET 实现表现层（参见图 2）。

WCF 是迄今为止最为优秀的服务容器之一。Microsoft 是业界第一个创新实现服务容器的公司。此容器的特点在于编程模型不依赖于特定技术：用.NET 编写的同样代码，可以用各种分布式技术发布，而不局限于 WebService。作为 WCF 的搭档，Service Factory 用向导化方式帮助开发者轻松创建完整的服务工程——其基础可以是 WSDL 文档，也可以是一系列定义了各种操作方法的类。Java 在 WCF 的启发下，也发布了新的组件模型（SCA）。通过 SCA，任何 Java 代码都可使用在发布时选择的分布式技术实现调用。 SCA 提出了一种新的装配式编程模型，技术人员可通过依赖注入（Dependency Injection pattern）的帮助，快速集成各种服务和组件（无论是用 Java、C++ 还是 BPEL 编写的）。SCA 的这种装配机制是过去那种在运行时注册逻辑（非物理）路由方式的优秀替代者。对于任何可装配实现的系统来说，都可在装配时而非开发时选择中间件技术。IBM 的 WPS 是一个基于 BPEL 的业务流程引擎，它可以说是 SCA 规范的前身。WPS 并不了解业务内部细节，它是一个以流程为中心的集成平台——流程本身的定义，则可以利用 WBM（WebSphere Business Modeler）这个建模工具来实现和优化。因此，对复杂解决方案的装配，通常应该由集成技术员而非业务分析师完成。

至于在表现层选择 ASP.NET，主要是因为 Safeco 的开发团队与这项技术素有渊源，选择其他技术，可能在未来造成被动。当然，我们仍然希望 SOA 在未来能一直保持让用户根据自身需要、为支持各种用户交互能力而自由选择实现技术的能力。

Safeco 的 SOA 卓越中心

我们现在有一个 SOA 卓越中心（Center of Excellence），它作为整个企业结构的一个分子，聚集了包括主题领域架构师（Domain Architect）、解决方案架构师以及开发人员、QA 和业务分析师等人员在内的众多资源。我们选择这样一个模式，是为了依靠资源集中，对多个项目同时发挥作用。我们希望过一段时间后，能用遍布整个组织体系的众多小型 SOA 组代替现在的卓越中心，这将帮助我们更好地提升每一个项目的专业化水平。

图 3 Safeco 的 SOA 卓越中心

当然，瘦身后的卓越中心在未来仍将保留并发挥作用，特别是在方法学、规范与标准、治理过程建设，以及服务的注册管理等方面，其根本目标，就是要开展能将服务的复用性最大化的设计时最佳实践。

案例学习

问题描述：所有 Q&I（Quote & Issue）和续费流程，都离不开用户申报情况（如票据、车辆事故）与其 MVR（Motor Vehicle Registry，机动车登记）记录的核对过程。而取得 MVR 记录是需要成本的，所以在实际中，我们尽可能在处理流程中延迟获取 MVR 记录。更为麻烦的是，美国一些州可以实时提供 MVR 记录，但另一些州只能在每天夜里提供当天申请的整批数据。所以，我们的目标是要开发一个全公司可用的组件，由它通过对 MVR 记录和保险单的比较，处理所有审核请求。这个组件将用在所有的 Q&I 和续费流程中。

我们现在的 Q&I 销售与服务平台不支持批量数据条件下的自动核对，这部分工作需要人工完成。在新开发的组件中，对批量数据自动化处理的支持，是我们的目标。另外要解决的一个问题是，现在的人工流程还可能造成对同一份保单的多次处理（如在一份车辆保单存在多个驾驶者的情况下）。

图 4 目前在批量 MVR 条件下的审核流程

在这个流程中，客户首先在 Safeco 代理处登记并取得保单。如果用户车辆是在批量返回 MVR 的地区注册的，那么发出 MVR 记录请求后的两天内，我们会收到一个批量数据文件。此后 CSR（Customer Service Representative，客户服务代表）根据 MVR 对保单做人工核对，以决定是否需对保单做报价修正。若需要，修正后的保单将同时发送给代理商和客户。根据我们的统计，大约 35% 的 MVR 记录与保单信息正确匹配。匹配逻辑也比较复杂，每个州有各自的规定。要想让 CSR 掌握所有州规定的细则，是非常困难的。

匹配逻辑的复杂，经常引起服务质量问题。另外，一份保单可能存在多个驾驶员。以前，这个问题常常引起对保单的多次修改和对保险商的多次赔偿请求。因此，匹配服务设计的一个关键需求，是必须解决一份保单存在多个驾驶员的问题。

解决方案概述：SOA 非常适合这个项目。我们可通过复用已经实现在现有系统中部分逻辑，开发一个全公司可用的匹配服务。一个以流程引擎为基础的解决方案，是快速实现以 MVR 合并过程为中心的自动化架构的重要手段。我们的这个方案要直接解决核对完成后，需修改保单，以及为 CSR 生成包括保单全部驾驶者的核对报告问题。CSR 最终还是使用现有系统完成保单的价格重核。

图 5 未来的 MVR 审核流程

MVR 整合方案

项目启动前，我们的 SOA 业务分析师进行了为期三个月的培训，主要任务是掌握 IBM 流程工具（WBM 和 WID（WebSphere Integration Developer））。在此过程中，他设计了 As-Is 和 To-Be 模型。

通过分析，我们发现有必要设计一个人工任务（译者注：工作流中的任务分为两类，即人工任务和自动任务。人工任务是需要用户干预的，而自动任务可由系统自己完成），向 CSR 提供核对报告。CSR 拿到这个报告后，就有了修正保单系统的全部必须信息。

To-Be 模型的任务，是用 BPEL 初步实现此流程。

因此，此解决方案包括了两个主要的服务：MVR 记录核对服务和保单服务。具体来说，主要包括 getPolicy、updatePolicy 和 matchMVRPolicy 方法。

图 6 MVR 解决方案的技术架构

MVR 文件首先上传到我们的老系统（参见图 6）。每天早晨，WMB（WebSphere Message Broker）将请求 PS 为每条 MVR 记录对应的保单创建一个业务流程实例。凡是属于同一个保单的所有驾驶者的 MVR 记录，都被合并到与此保单对应的流程实例中去。MVR 文件处理完成后，每个流程实例将依次调用 getPolicy 和 matchMVRPolicy。如果匹配成功，BPEL 将执行 updatePolicy 操作，并结束流程实例的运行；否则，将创建一个新工作项并等待，直到用户认领此工作并做处理。

流程建模、模拟与运行

过去，业务流程引擎和业务流程标准（如 BPEL、BPML）厂家都号称用户建立的流程模型可直接在引擎中部署并运行。

而我们过去的经验表明，事实并没有这么简单。因此在 SOA 项目启动时，我们在这个问题上未抱任何奢望。

图 7 模型驱动的优势

在实践中我们发现，有些流程可能会比其他流程表现得好一些。因为 MVR 流程的特殊（如驾驶者记录合并、匹配逻辑的复杂等等），我们的流程视图和最终的 BPEL 实现差异很大。而我们过去设计的一些流程，与在其视图基础上得到 BPEL 实现接近得多。从纯实践经验的角度看，我们认为，凡是“在 BPEL 实现中嵌入了系统调用逻辑”时，上述二者的差异都会非常明显。

MVR 合并实现

此项目的一个关键问题，是同一份保单的不同驾驶者记录能被合并处理，以避免对保单的重复更新，和对代理商和用户的多次通知。

这个问题，我们是在 BPEL 定义中直接解决的。

图 8 BPEL 对 MVR 记录合并的实现

PS 接收到新的 MVR 记录时，会创建一个业务流程实例。此后，我们在 processMotorVehicleReport 中建立了一个将属于同一份保单的其他 MVR 记录导引到该保单对应的流程实例的关系映射表。

BPEL 如此循环，直到 MVR 批量数据文件处理结束。

Microsoft/IBM 平台互用性

因为我们选择了多个平台，就必须直面互操作问题。在整个流程中，ASP.NET 实现的表现层调用 PS（Process Server）的服务，PS 再调用 WCF 服务（参见图 6）。

处理好整个系统的互用问题，关键是要弄清楚各部件的互操作能力。目前，WPS 只能与 basicHttpBinding 型 WCF 实现互用。而 basicHttpBinding 是建立在以下规范基础上的：

• HTTP 1.1
• MTOM
• WSDL 1.1
• SOAP 1.1
• WSS SOAP Message Security 1.0
• WSS SOAP Message Security Username Token Profile 1.0 & X.509 Token Profile 1.0

因此，诸如 WS-Policy、SOAP 1.2 等 WCF 最具优势的功能，是不能在我们的项目中使用的。

在各部件处理名字空间的方法不同问题上，我们也遇到了一些麻烦。WCF 使用服务视图（service view），每个服务都有其特定的名字空间，而 PS 使用居于服务接口之上的业务对象视图（business object view）。因此，如果要求策略文件为保单和核对服务公用，就必须保证它能在 WSDL 层次实现共享——毕竟，同一个业务流程定义的策略规范应该是唯一的。所以，我们对 WCF 生成的名字空间进行处理，以保证最后得到的 WSDL 可为 PS 使用。

当然，这只是在应用 Web Service 技术过程中的一个普通处理手段，目前还没有出现一个专门的“业务对象模型”，明确定义诸如此类的资源交换方法。每个厂商都可自由选择最适合于它们产品和客户的策略。

安全互用性

讨论 Safeco 系统安全的基础架构，已经超出了本文的范围。而在安全互用方面，我们已经探索出几种混合型安全机制，以支持身份、完整性和机密性验证功能。

Web Service 安全（WS-Security），是建立在消息安全概念基础上的：消息的 SOAP 封包本身以明文发送，但其资料体是加密的。

在 WCF 端，有很多种办法实现消息的安全，但各有各的适用环境。比较常见的如下表：

Binding Credential Type basicHttpBinding Certificate basicHttpBinding UserName encrypted via Certificate wsHttpBinding UserName- 证书验证（Certificate Authentication）：除了通过加密方法增强安全性，WCF 还支持通过客户端证书实现对客户端身份的验证。

• Windows 身份验证（Windows Authentication）：跨服务传送 WindowsPrinciple 票证后，以服务为基础的 WCF 可实现对客户端的模拟，即运行在客户端拥有的权限环境内。
• 用户令牌验证（UserName Token Authentication）：当客户端身份无法与有效的 Windows 用户身份匹配时，可依靠用户令牌机制，将客户端身份传送到服务端。

我们项目的一大亮点，就是安全机制的百分之百可配置（如代码不依赖于所使用的安全机制类型）。所有安全设置都可在部署时完成。

另外，我们实现了数字签名和加密机制在 PS 与 WCF 之间的互用。

在这里，我们得提到一个小问题。Oasis 组织曾发布一个非标准的勘误文件，不过并非所有厂商都给予了支持。如 Microsoft 没有，而 IBM 实现了。

因此，请求消息会包含如下形式的公钥标识：

<keyidentifier><br></br> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3SubjectKeyIdentifier" ><br></br> lptrlv+cM5o0L2B954iFCDANFD0=<br></br></keyidentifier>X509v3SubjectKeyIdentifier 中的 v3，就是这次勘误引入的，而 Microsoft 是未作支持的。因此，需要我们要么人工修改此名字空间值，要么将 Websphere 升级到最新版本。

经验总结

学习曲线比较陡峭。倒不是说某方面的知识非常难懂，关键是必须了解大量技术和工具的使用，才能熟悉项目的完整执行过程。

为此，我们邀请了 IBM 和 Microsoft 的两位咨询专家辅导我们完成第一个项目。结果表明，他们为我们在解决组件的互用能力、配置和分发等方面提供了极大帮助。

我们认为，在建模活动中就引入业务用户的想法是不切实际的。经验丰富的业务分析师可以轻松将业务需求转化为业务流程模型。但这个模型一般不可能马上在目前的业务引擎中展开，通常还需要集成技术员先将此流程转化为可执行组件。初期，我们不妨将 SOA 当作一个传统项目看待。随着时间的推移，为业务组提供一个可展开模型就慢慢显示出价值了。特别是进展到需将运行度量指标植入 as-is 模型时，我们希望这个价值能成长到足够大，从而激发业务组的积极性，高质量展开建模活动，最终建立一个闭环的由交付流程驱动的模型。

这个项目让我们充分认识到了 SOA 能给一个组织带来的各种好处。

首先，我们可以复用现有代码，如果不使用 Web Service 技术将它们改造为服务，就不可能做到这一点。我们将解决方案部署到产品中后，拥有代码的 Q&I 组对审核服务的实现做了一些修改。修改的效果马上就在 MVR 解决方案中体现了出来；如果还是采用过去的复制方式部署，根本不可能做到这一点。

第二，Web Service 技术为组件互用能力提供了保障，而这一点恰恰是构造复合式应用的成功关键。我们的项目没在互用性上遇到大的障碍，真心希望在 SOAP1.2、WS-Transaction 和 WS-ReliableExchange（我们目前的项目还没有用到这项技术）等的支持下，互用性在未来可以做得更好。

第三，我们能够以 4 个开发人员、2 个 QA 和 2 个架构师的团队，在 8 周内完成包含 5 个系统的集成解决方案。

第四，在整个流程的实现中，我们只写了不到 20 行代码，用以实现一项较特殊的映射功能。流程组件、服务和 CSR 活动间的装配，都可以通过 SCA 实现。这充分说明了模型驱动方法解决现实问题的有效性，而且它可以在流程层次上削减超过 90% 的代码。假如使用传统的编程模型（如 J2EE 或.NET）实现整个流程，没有中央引擎，将至少需要几千行代码。而这些代码是有状态的，很难调试，以后也不便修改。

总的来说，Safeco 已经成功完成了面向服务、以流程为中心和模型驱动应用开发的第一阶段迭代。

未来方向

我们目前的 SOA 整体架构还不完整。下一步，我们将重点在 BAM（Business Activity Monitoring，业务活动监控）、登记管理与监控等方面提升我们的能力和水平。

我们的业务量已经进入高峰期，这得益于我们运作成本的降低、效率的提高以及能持续优化客户解决方案的能力。流程运作效率和资源复用能力的关键，在于系统治理和架构方法。我们仍将持续努力，不断到达新的高度。

SOA 架构的最大好处，是它赋予了 IT 资源在未来构建新的解决方案时可复用与可扩展的能力。未来项目如果能够利用现存资源，实施将变得更容易、更快速、成本更低。可以这么说，SOA 是实现系统升级、改善业务流程、IT 资源布局和反应速度的关键。利用 SOA，Safeco 在更短的研发周期中，满足了市场需求，实现了公司的财务目标，同时降低了研发成本。

查看英文原文： Case Study: Composite Applications at Safeco - - - - - -

译者简介：罗小平，上海某大型公司互联网中心技术总监， CSDN 大版主，网络 ID 为 lxpbuaa(桂枝香在故国晚秋)，曾著有《Delphi 精要》一书。个人博客为 http://blog.csdn.net/lxpbuaa ，现在 CSDN 主持翻译国外专家 Herb Sutter 的中文博客。他的 Email 和 MSN 为 lxpbuaa AT 263.net 。