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

作者 Joanna Baas, Andy Coughlan, Jennifer Fernandes, Steve Gies, Cy Pauly, Denis Rivera, Ilene Samowitz, Bill Seagren, Kari Wittgens, JJ Dubray译者 罗小平 发布于 2007年8月14日 上午10时37分

社区

Architecture,

SOA

主题

SOA平台,

Java+.NET集成,

故事和案例分析

标签

服务组件架构,

WCF,

微软,

IBM

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实现了。

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

    ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3SubjectKeyIdentifier" >
 lptrlv+cM5o0L2B954iFCDANFD0=

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。

• 更早的 >