利用 .NET 3.0 技术构建互操作保险系统[转载]

简介

本白皮书系列旨在提供有关集成问题的指导。

在本白皮书中，我们将通过保险业的案例来说明 Microsoft 平台的互操作功能。随着技术发展以及新技术不断涌现，许多企业在企业发展的各个阶段可能选择了不同的技术：从基于大型机的 COBOL 或 FORTRAN 类型的传统应用程序，到更为现代的基于 .NET、移动系统或 Java 的解决方案，以及一切的中间技术。因此，随着企业所采用技术的日益庞杂，各类技术所面临的限制也越来越多。

保险互操作系列

本白皮书旨在为面临保险行业集成难点的结构设计师提供指导。本文将向您显示如何使用 Microsoft 集成技术为企业集成各种有着本质差别的系统。另外，本文档会针对使用开放式标准（如 WS-*）来构建互操作解决方案方面，提供实用的设计指南。此系列中还将包括下列文档：

用于构建互操作保险系统的结构概述

确保保险解决方案的安全性

分析和操作管理

部署企业解决方案

开发复合应用程序

涵盖的技术包括：

•	BizTalk 2006。用于此解决方案的集成技术。解决方案也会用到 BizTalk 业务规则和工作流编排功能。
•	Windows Communication Foundation (WCF)。用于开发 Web 服务消息以及使用 WS-* 协议来管理协议级通信的编程模型。
•	Windows Workflow Foundation (WF)。用于采用智能客户端技术来创建恰当的工作流。
•	SQL Server 2006。所有应用程序和客户数据的存储库。
•	Windows Server 2003。服务器平台。

该案例将使我们对业务流程有一个初步了解。与许多其他企业一样，每家保险公司都有自己独特的流程处理方式。但是，这些企业在平台级别具有一些相似之处。这意味着我们能够利用这些共有的平台服务来构建面向服务的体系结构 (SOA)，从而为这些具有特定业务流程的组织带来更大的灵活性。

 

保险业影响因素

目前保险业中所采用的技术有多种，包括大型机、UNIX 以及 Windows。在所应用的平台技术如此庞杂的情况下，要对不断变化的金融市场保持灵活应对的同时进行管理和运作正变得越来越困难。多年以来，各个组织一直在构建并购买技术以满足这些需要。互操作性已经成为在构建和/或实现了解决方案后不得不解决的棘手问题。之前，人们采用的是点到点集成的方式，但这种方法只能解决应用程序级或系统级的某些特定问题，而无法解决业务功能级的问题。

图 1. 点到点集成的结果

如果不谨慎，多年以来的点到点集成会导致：

•	由于系统重复、集成形式多样以及应用程序依赖性管理等原因，IT 资产组合变得无法管理。
•	大量的自定义集成造成 IT 系统成本大幅度上升。
•	由于代码复杂性增加、重用性有限以及企业内部缺乏标准化，因此显著降低了系统开发的速度，从而导致了灵活性的丧失。

那么，对于众多保险公司而言，这意味着什么？这表示互操作性非常重要，不仅是效率问题，对提高公司竞争力也极为关键。在现代商业竞争中，公司必须通过简化流程及提高灵活性来增加其 IT 系统的投资回报 (ROI)，从而保持竞争力。

我们的目标是利用 Microsoft 平台上的一组企业就绪技术来应对行业挑战。示例中包含以下要素：

•	企业级解决方案
•	标准通信： • 采用 WS-* 标准 • ACORD 消息
•	确保与现有解决方案之间的互操作性

 

本文档中使用的行业术语

ACORD―ACORD ([url]www.acord.org[/url]) 是一个非赢利协会，其目的是促进保险、再保险以及相关金融服务行业标准的发展和使用。

订单系统―创建对外部数据的请求，将其传输给相应的第三方数据提供者，管理收到的响应并将响应与相应的请求者对应起来。

第三方服务提供者―实现保险需求请求的外部系统（例如，信用评级系统）。

保险流程―执行新业务的评估和处理流程。

代理系统―可采用的智能客户端前端系统，由保险代理人使用，作用是订单输入以及过程监视。也可使用其他前端系统，例如为代理人提供的 Web 门户，或者由客户自助输入订单的 Web UI。

 

人寿保险保单案例

客户 Robert 要购买 1 百万美元的白金级寿险。代理人 Tom 使用其智能客户端应用程序来输入 Robert 的保单申请。保单被发送到订单系统，然后系统会对其进行处理并传送到相应系统以开始保险流程。保单处于订单系统中时，便会启动第三方服务。在此案例中，我们使用 Paramed，这是一种核实保险申请人健康状况以及医疗记录的第三方服务。

如果满足特定条件，内置业务逻辑也可以生成对第三方的请求。这里的第三方可以是代理人或保险公司的另一个合作伙伴。

图 2. 此案例的业务流程

 

结构概述

本节将介绍此案例中使用的高级逻辑结构。有关特定方面（如安全性、消息、开发和部署）的详细信息会在本系列的其他文章中介绍。

为了确保适用于实际问题，我们会提出一组高级要求。

要求

以下是对企业级解决方案的要求：

•	必须能够与已有的现成商业应用程序进行互操作。如前文所述，许多组织会购买并自定义软件。因此，满足此要求便显得极为关键。
•	集成技术必须为 Web 服务。许多形式的通信（例如二进制通信）都是专用的。直到出现 Web 服务，才有了消息通信的标准化方法。Web 服务提供了在完全不同的平台间进行通信的方法。
•	必须采用 WS-* 标准。多年以来，采用 SOAP 和 WSDL 的 Web 服务一直是行业的集成标准。但是，这些传统的 Web 服务缺乏消息传递所需要的健壮性。WS-* 标准提供了这些必要功能，而且不需要使用二进制通信。
•	长时间运行工作流。长时间业务管理非常困难，尤其是当该工作流还会衍生出许多更小的外部工作流时，在这种情况下协调和事务管理会变得极为复杂。

在此解决方案中，我们使用 BizTalk 作为消息中心，因为它功能强大，而且此保险解决方案非常需要将多个系统绑定在一起并管理多个外部工作流。

图 3. 采用消息总线技术

图 3 所显示的是作为企业服务总线 (ESB) 的 BizTalk 的企业视图。请注意，并不是一定要将它用作 ESB。本白皮书仅将此层作为消息层，因此在任何情况下都可以把它集成到解决方案中。

使用 BizTalk 的根本原因在于它能够提供用于以下功能的集中化平台：

•	业务流程管理―将可重复使用的业务流程集中化不仅可给出服务导向，而且向组织提供了在无需修改现有或购买的现成（基于 COTS）商业应用程序的情况下对其进行扩展的机制。
•	工作流编排―通过该平台可以简化对多个工作流的管理。从而按应有的方式管理解决方案，而不需要对每个工作流进行编码或协调。我们通过创建一个工作流，来从头至尾管理能够编排多个内部系统工作流的业务流程。
•	丰富的适配器支持―快速开发对于组织而言有着重要的意义。BizTalk 具有多种适配器，可满足集成需要。在保险领域，有一种 ACORD 适配器，可以使集成突飞猛进。Web 服务适配器和基于文件的适配器可与 ACORD 一起供 BizTalk 使用。
•	消息传送和转换―必须对消息进行转换其他系统才能理解时，消息的传送会非常复杂。BizTalk 可以提供平台，在降低复杂性的同时仍符合开放标准。

 

保险代理人保单系统

当前，保险行业中的技术发展方向包括门户、胖客户端、3270 主机终端仿真屏幕以及智能客户端。在该领域存在各种应用程序和众多供应商的情况下，基于以下理由，我们选择采用智能客户端用户界面 (UI) 来为代理人提供最佳体验：

•	离线和在线模式
•	不依赖网络连接
•	增强的功能带来更为丰富的用户体验

断开模型对代理人而言非常适用，因为代理人会经常处于移动状态或者在访问网络资源方面存在限制。但是，由于我们在构建此解决方案时将 Web 服务作为消息传递策略的核心，因此最终代理人提交保单的方式并不重要。

对于客户端结构，使用 Windows 窗体作为用户界面，来为代理人提供所需的用户界面。界面上有一些控件，如数据网格、文本框及命令按钮。Windows 窗体上的数据网格将由代理人使用，用作到保单管道的窗口。我们使用 Web 服务来更新该数据网格以确保实时更新。

由于这是智能客户端，返回数据可以存放在缓存中以供离线查看和更新。这对代理人极其有用。除了数据，在客户端应用程序上还会有一个小的业务逻辑层。大部分应用程序逻辑会驻留在保险公司这端。其根本原因是我们将使用轻量规则来驱动 UI 功能。

图 4. 客户端逻辑结构

要在客户端发起对消息传递层的调用，我们将使用 Windows Communication Foundation (WCF)。WCF 会采用 ACORD 消息传递架构来发送 SOAP 1.2 Web 服务消息。WCF 为开发人员提供了用于编码通信的统一开发模型。站在协议的角度，我们会采用一系列 WS-* 标准。但是，这还不足以确保互操作性。采用 ACORD 行业标准也很关键。我们应能在“本地生成”的应用程序、COTS 应用程序以及第三方服务之间进行无缝互操作。

消息传递结构

通过 Web 服务，各种通道便能利用通用的 Web 服务。该服务以 ACORD 103 消息（具有指定的保单号，在整个示例中将使用该号码来进行跟踪/关联）的形式接收新的业务申请并将申请加入保险流程中。该 ACORD 103 New Business Submission 消息基于 SOAP 消息传输优化机制 (MTOM/XOP) 附件，其中包含 Robert 签名的二进制表示，以根据 HIPAA 的要求授权发布医疗信息。显然，将 ACORD 标准集成到消息传递中非常重要。这可确保结构的可移植性。

通信的安全性和可靠性也非常重要。为达此目的，我们将 WS-Secure Conversation (WS-SC) 用于可能要通过未知数目中间方的个人信息。我们还将 WS-SC 用于量大且频繁的请求（例如信用审核），所有新的保单申请都会进行此类请求。我们将 WS-Security 用于频率较低的请求，例如主治医生报告 (APS)，其中建立会话的开销大小并不由请求的量来决定。在极少数情况下，服务会直接处理请求而不经过任何中间传送过程，此时我们也使用 TLS/SSL（也称作 HTTPS）。

对于需要跟踪接收情况的消息传递（例如确保接收到新的保单以获得代理权），我们会使用 WS- Reliable Messaging (WS-RM)。我们也会将 WS RM 用于处理起来代价高昂的数据请求（这种情况通常涉及人力工作流，如 APS 查询）。这确保请求只传递一次，避免了代价高昂的重复请求。

对于长时间运行的消息，我们使用 WS-Secure Conversation (WS-SC)（请参阅 资源）。

图 5. 客户端消息交换模式

事务	业务流程	WS-* 协议	结构决策
提交新保单（103 请求）	代理客户端 保险流程	WS-Security (WS-S) WS-Reliable Messaging (WS-RM)	WS-S 用于可能会通过未知数目中间方的个人信息。 WS-RM 用于跟踪消息接收。 由于事务不频繁，因此不需要面向会话的安全机制，如 WS-Secure Conversation。
状态查询（122 请求/响应）	代理客户端 保险流程 履行流程	WS-Secure Conversation (WS-SC)	可以轻松地重试非关键的个别请求或响应消息，但仍然会包含个人信息。
保险要求订单请求 (121)	保险流程	WS-Secure Conversation (WS-SC) 或 WS-Security (WSS) 或传输级别安全性 (TLS/SSL)	这些消息包含个人信息。
保险要求订单响应 (1122)	履行流程	WS-Reliable Messaging (WS-RM)	WS-SC 用于量大、频繁的请求（如信用审核）。 将 WS-Security 用于频率较低的请求，其中建立会话的开销大小不由请求的量来决定。 在服务直接处理请求而不需要任何中间传送的情况下，使用 TLS/SSL。 将 WS RM 用于处理代价高昂的数据请求。

表 1：业务流程消息传递设计决策矩阵

在进行提交后，您可能会问自己：为什么状态在单独的事务中返回？原因有两方面。首先，该过程异步进行很重要，并且 ACORD 标准不允许在没有将状态从提交分离出来的情况下进行实施。其次，通过查询状态服务，代理人可以定期从申请过程获得返回状态。

 

保险公司系统

过去在构建解决方案的服务器端时，需要考虑下列问题：

•	该结构用于碎片系统。
•	功能区域是自我包含的，需要进行管理。
•	操作系统和开发环境存在差异。

结果就是，存在大量与特定应用程序的点到点集成，因而需要专门的实现过程。在本解决方案中，会围绕这些现有的应用程序创建外层。

图 6. 保险消息总线

在本图中，您可以看到我们如何将企业服务总线 (ESB) 用作消息总线。该层会作为管理内部和外部消息的集中化消息传递层来发挥作用。管理和编排功能是该结构重要的优点。

此类基础结构可以将智能的长时间运行业务流程和事务策略置于一层而不是多层，从而使不同的点到点集成变得井然有序。在五或六个以上的系统中具有几个截然不同的基于 COTS 的应用程序以完成端到端的事务处理会很普遍。我们正通过合并冗余功能（例如工作流和消息传递）来减小系统，将基础结构级的功能留在其所属位置并在适用的应用程序中保留业务逻辑。

请务必牢记，此消息总线是“逻辑”表示。“实现”视图与此有相当大的差异。例如，消息总线可能是多个 BizTalk 服务器，或者是由位于不同 DMZ 环境中的服务器来管理内部和外部通信。

图 7. 工作流设计器

下面一层（在其中执行特定业务功能）包含以一个接口封装的两个不同的传统系统：订单系统和履行系统。我们将它们作为单独的系统而不是把它们合并在一起的原因是，多数时候，这是两个独立的、基于 COTS 的系统。

添加状态系统的原因是：

•	提供集中化的方法以向代理人报告状态。
•	减少查询多个系统所需的接口和控制逻辑的数量。
•	它能与用于长时间运行工作流的 ESB 的编排功能绝佳配合。

订单系统和履行系统已转换为过程消除服务。这样可以消除独立实现之间的依赖性。这些系统的所有通信现在都会经过消息中心。然后，通过消息总线来管理的公开 Web 服务端点可以利用内置在 BizTalk 中的编排技术来管理。

图 8. 端到端消息交换模式

由于这些应用程序作为 Web 服务公开，任何接受 Web 服务 XML 的技术都可以和这些应用程序集成。这消除了其他技术协议间可能会限制互操作性的紧密耦合。例如，如果您之前用的是基于 Java 的系统，您现在仍可对这些系统进行轻松使用。

SQL Server 在此处用于将应用程序数据存储在数据库层中。由于本白皮书的中心是集成和复合应用程序，在此我们就不对这一点进行重点介绍了。

引用的第三方服务是外部服务，由履行服务来调用。这些服务有不同的协议要求。但是，本白皮书会向您展示 WS-* 标准是如何提供更多用于服务的功能。请务必注意，许多实际的保险第三方服务只支持基于 XML 的通信，而不支持更加高级的基于 SOAP 的 Web 服务。后面的消息传递结构部分会介绍更多关于第三方服务的内容。

保险公司消息传递结构

本节会介绍由保险公司处理的基本寿险保单。在 Robert 所提供信息的基础上，保险流程中定义的业务规则/启发逻辑确定还需要主治医生报告 APS（即身体检查）。

因为另一个提供者必须执行该请求，订单系统会创建 ACORD XML TransType 121 General Requirements Order Request 事务 (TXLifeRequest)，并将它传输给 Robert 的医生所用的二级外部订单系统（APS 系统）。该消息还包含 Robert 签名的 MTOM/XOP 附件，签名初始由 ACORD 103 New Business Submission 携带，用于授权他的医生向保险公司发布其医疗信息。

在某个时刻，Robert 的医生会验证 Robert 的签名是否与他所拥有的文件上的签名匹配，然后检查 Robert 的疾病史，填写 APS 报告上要求的信息，从而完成 APS 订单的处理。

在医生完成 APS 报告后，会生成 1122 General Requirements Status/Results Transmittal 消息并将其传输回 WS-Addressing ReplyTo（在之前的 ACORD 121 中指定）中指定的端点引用。也会使用 WS-Reliable Messaging 来可靠传递该消息。

业务流程的其余部分开始执行，其中包括所有自动保险统计师决策。但是，在本例中，由于有 APS 以及一些可能无法自动处理的附加信息，因此该案例会被标记以供保险商检查和批准。

图 9. 保险流程消息交换模式

履行服务

在保险业中，履行系统或服务与履行的流程大不相同：

•	履行系统：接收请求并执行的系统或服务。可将履行服务视为用于收集数据的集成组件。在本例中，履行系统负责从第三方提供者收集各种报告。
•	履行流程：保险公司核发保单的流程。

您可能会问，为什么要保留履行服务。就本例而言，我们假设此类系统是被作为黑盒解决方案购买的。这并不是说不能删除这些层并转而将其合并到消息总线中。

选择消息传递模式并不像选择一组标准那么容易。在设计解决方案的这部分时，必须停下来查看一下每个事务的业务和传统方面。

某些事务，例如接收信用报告，比较容易确定。但是，诸如请求 APS 报告的事务，则要求具有附件功能。

以下是一些在设计消息传递时要考虑的内容：

•	理解业务流程。理解业务使用这些消息的方式（例如，确保数据安全）非常重要。如果正发送的数据不敏感，则无需对消息采取大量安全预防措施。
•	理解服务提供者如何使用事务。这包含内部和外部两方面。很多时候，在利用服务提供者时会存在技术上的限制，包括标准支持及操作时间等。
•	适当关注安全性。这一点经常被忽视。大多数情况下，SSL/TLS 之类的协议级安全便已足够，但并非总是如此。务必要对数据的敏感性进行评估，并检查消息路径以确定在最终使用者前有多少个端点。
•	注重实际。设计这些服务时，不要试图采用每一个标准。如果标准不属于某个消息，不要强行将它置于其中。这只会带来不必要的复杂性。

图 10. 履行系统消息交换模式

 

具有什么价值？

通过本示例，我们介绍了许多关于 Microsoft 平台和开发技术的知识。也重点介绍了结构决策。但是我们没有就这些 Microsoft 技术的功能进行专门介绍。

以下是在保险业中使用 Microsoft 技术的主要优点：

•	业务流程自动化―业务流程非常复杂，并且每个运营商都有其独特的运作方式。有了 BizTalk 提供的编排工具，便可由业务分析人员来开发业务流程，不但使开发人员从这项工作中脱离出来，还对业务提供了更好的支持。
•	减少集成代码―利用 BizTalk 中的自定义适配器以及 WCF 的统一编程模型，集成系统所需要的代码大大减少。
•	符合标准―WCF 和 BizTalk 本质上基于开放式 XML 标准。因此集成 Web 服务标准无需再进行自定义编码。
•	效率―通过集成的 Visual Studio IDE 和 .NET 3.0 技术，工具和开发语言两者相结合带来了其他语言无法比拟的高效率。

 

总结

如同本白皮书所展示的一样，仅采用协议级标准远远不够，捕捉消息传递事务的业务方面才是让互操作性为业务服务的关键。这适用于各个行业，而不仅仅是保险业。

我们拥有 Web 服务标准，但那不是全部。您仍然需要执行必要的操作以便为您的企业做出最佳技术决策。利用此特定的引用实现，我们介绍了一个实际的案例并根据该案例的业务影响因素来确定最佳消息传递。在选择适用于贵组织的消息交换模式时，可将此用作参考。建立了所有的结构后，选择特定标准时就有了权衡。重要的是理解这些权衡的意义并采用正确的标准。

Microsoft 致力于使其客户能够更加轻松地构建并开发面向服务的解决方案。通过本文，您可以发现 Microsoft 已消除了让客户望而生畏的行业壁垒和复杂性。从提供行业标准中的领先观念到自动执行并构建现成的 Web 服务支持，Microsoft 均能为您一一呈献。

原文: [url]http://www.microsoft.com/china/MSDN/library/netFramework/netframework/bb220799.mspx[/url]

自由、创新、研究、探索……