作为挪威最大的金融服务公司，Storebrand ASA 需要为整个挪威 280,000 个以上的客户提供健康和人寿保险以及银行业务和资产管理的支持。这个庞大的公司面临的最艰巨的难题之一是，在操作近 6,500 家挪威公司的 390,000 名员工的养老金计划时对员工记录进行跟踪和管理。

多年来，这项非同寻常的同步任务一直是大规模的手工处理，有 50 名专门人员从事维护相关数据库录入的工作。所涉及的工作包括数据（比如日期、工资、地址、合同、帐号以及其它详细信息）的传输、确认、更新以及复核，然后将之输入到 Storebrand 的中央数据库。为了完成这些工作，从客户的多个工资单系统抽取数据并发送到 Storebrand ? 往往通过使用在线表单，但通常是以书面形式手工完成。通过结合智能卡和证书来提供数据认证。这种繁重的处理急需自动化的解决方案，而在此之前不可能使用已有的 Web 标准。因此，Storebrand 在寻求一种方法，这种方法利用开放标准与合作伙伴在因特网上电子地交换文档。

与员工记录同步一道，Storebrand 面临的其它业务难题还包括将关键产品和服务链接在一起，比如人寿险保单、养老金基金以及银行业务选择之间。他们还寻求为经销商和客户提供产品的更好方法。最终，Storebrand 希望通过提高内部以及与商业伙伴的效率来控制成本，通过使商务过程自动化来降低操作成本。

结果，通过再分配当前手工数据输入和管理所涉及的大部分员工，Storebrand 如期看到了操作效率的提高，因此潜在地节省了公司每年成千上万个小时的劳动成本。

业务和技术难题

Storebrand ASA 联合“IBM j(ump)Start 新兴技术”（IBM j(ump)Start Emerging Technologies）英国小组一起面对他们所碰到的难题。在与“jStart 约定管理组织”（jStart Engagement Managers）商讨之后，Storebrand 确定了一个双管齐下的目标：

1. 修改现有的员工手工数据处理的内部业务惯例。
2. 使用“Web 服务”从客户工资单系统捕获数据，自动地完成关于这些数据的计算，然后将结果信息直接传到其大型机数据库。

在 jStart 实现端，工程目标确定如下：

• 为 Storebrand 端创建 Web 服务（作为 Servlet）
• 使“供应商工资单系统”（Vendor Payroll System）适应 Web 服务
• 实现必需的基础架构
• 确保安全性
• 连接现有的 Storebrand 商业伙伴
• 为 Web 服务提供技术证据

表 1：Storebrand 商务难题

回页首

寻找通用的格式

该过程的第一步是确认并达成一个通用的数据格式。客户需要有一个通用的格式，使之能以一致的方式向 Storebrand 表示数据，还需要 Storebrand 应用程序能够抽取恰当的数据，并将其存放到它们的中央数据库中。

大多数 Storebrand 客户和合作伙伴已经电子地捕获到了员工数据，并且大部分已将员工信息链接到他们自己的工资单系统。最初进行员工津贴精确计算所需的信息保存在每个公司的工资单系统中。也就是说，通常将收入以及其它数据的变化抽取到文件中，该文档以传真或邮件的方式传到 Storebrand ASA 以便手工输入。

为了启用多个工资系统（最终支持所有系统的目标为 6,500 + Storebrand ASA 为之提供服务的企业），必需提供基于标准的解决方案，能在各种硬件平台的不同操作系统上运行的多个工资单系统中实现。

Storebrand ASA 将此目标确定为特定的业界 XML 词汇 ? XMLife 由美国业界团体 ACORD 制定。使用一些附加的标记（请参阅 参考资料部分中完全修改的 DTD），Storebrand ASA 能够为公司的工资单系统及它们自己的津贴管理系统间的数据交换提供遵循标准的方法。

在选择 XMLife 的过程中，Storebrand 和 jStart 联合开发小组成员考虑到几个因素。首先，格式需要一个面向所有合作伙伴的通用解决方案，而不是针对某一个供应商的方案。没有经济实体想要花时间或金钱来开发它们自己的标准。因为 ACORD 是当前用于保险业务的业界标准（代表了 Storebrand 近 44% 的业务），而 XMLife 是普遍接受的公认和恰当的 XML 模式，因此将二者结合起来是显而易见的选择。

使用这种解决方案，每一个工资单供应商抽取必需的数据，并且将数据转换成为 XMLife。供应商提供的 COM 组件生成 SOAP 请求，在 Storebrand 的 Web 服务接收数据并将之传到 IBM 的 MQSeries Integrator 中间件。

回页首

理想的解决方案：业界特定的 tModel

为企业间数据交换确定 XML 词汇是一个伟大的开始，而保险业所需要的是在 Web 服务基础上进行标准化。Web 服务定义允许以 tModel 形式的细节描述。tModel 基本上是元数据的自由格式扩展，概述了服务全面的规范。同样地，由 WSDL 文档定义的以 tModel 形式的描述可能包含用过的 XML 词汇的指针，而且也包含进一步的描述，比如业务规则、成本或与使用特定服务相关的义务。

但是，这不是 Storebrand 希望在它们自己系统上所做的工作。理想情况下，保险业将对此（即，人寿保险数据交换）以及其它的商业事务进行定义，以 Web 服务进行标准化以及以 tModel 形式做成文档使整个业界很快接受。

对于 Storebrand 及其客户这种联合定义的系统正合需要。达成了通用的数据格式之后，下一步涉及到多个使用不同的编程语言的全异系统彼此间能进行通信。许多 Storebrand 的客户使用基于 Intel 系统体系结构的 Windows 2000 操作环境，而 Storebrand 的中央数据库在运行完全不同的操作环境的 IBM 大型机上进行操作。

2001 年 1 月初，小组开始工程定义工作，对当前基本结构的工资单部门、商业伙伴、工资单供应商提供者以及技术小组进行调查。2 月开始开发，在接下来的两个月（5 月初初始系统完成前）进行全面开发。在此期间，为了使用新系统，Storebrand 必须与它的客户适时地签订合同，这一直持续到 8 月。新系统的初始测试有两到三个客户，处理几百个员工津贴客户程序。最初，系统包含 Storebrand 及其客户公司之间的直接关系。以后，第三方作为工资单供应商提供者，可以作为中介被包含在系统中。在这种情况下，工资单供应商提供者将作为实际客户公司的应用程序服务提供者为个体提供津贴服务。

为了使不同的环境共享数据，jStart 建议使用 SOAP （“简单对象访问协议”，Simple Object Access Protocol）连接，通过连接大部分工资单应用程序的 Windows 环境和在 Storebrand Life 中的 WebSphere Java 环境来实现。

小组确定有三种可用选项：

1. 单独使用 SOAP? SOAP 将提供基本的程序到程序的“粘合剂”，使应用程序能绑定在一起进入对等通信。
2. SOAP + WSDL 定义? WSDL 将提供标准化的服务描述，但是不会提供完全库查询。应用程序服务一经描述，将用服务代理发布它，帮助 Web“请求者”（在这种情况下，为新的 Storebrand 经销商）知道应用程序／服务。
3. SOAP + WSDL + UDDI（包括注册中心中的服务描述）? UDDI 也是用于 Web 服务集成的框架。它包含一个描述 Storebrand 产品和服务的基于标准的规范，并且允许全局注册中心体系结构中的发现。

最初 Storebrand 选择利用所有三种技术的组合。为了这样做，小组创建了 COM 对象，该对象以 XML 文档作为输入，并通过 HTTP 协议在因特网上进行传输，将其发送到 Storebrand Web 服务。这种情况下，客户站点主要使用 Microsoft Windows NT 或 2000 系统来完成津贴处理的数据录入。这样，小组决定用 VB 为客户端构建 COM 接口，并且使用面向该服务的 Microsoft SOAP 工具箱。在 Storebrand 的服务器端，通过简单使用 IBM XML 的 Web 服务开发环境中提供的向导，小组将现有的 Java 应用程序转化为服务。这个启用 Web 服务的应用程序接收 XML 文档，并且为了给 Storebrand 的 DB2 中央数据库提供数据，转换用于验证和更新过程的数据。用 MQSeries Integrator管理后端数据传输和操作。 图 1详述了工程系统概念性的体系结构。

表 2展示了计划交付使用的条目以及工程中个别用到的软件组件。

表 2：Storebrand 工程计划交付使用的条目

这种规模的工程使用崭新的技术不是没有原因。2001 年初，小组对实现 Web 服务怎么会缺乏安全性还没有头绪。Storebrand 要求与当前的在线系统具有同等级的安全性，当前的在线系统他们使用 Web 页面的表单而不是发送传真或文件记录（通常也要求客户将数据重新输入到 Web 表单）为客户提供服务。小组结束了使用“安全的”HTTP 和 SSL 协议，这些普遍地用在许多商务 Web 站点上。但是，一个首先的问题是用于客户端开发的 Microsoft SOAP 工具箱这时不支持 SSL。这样他们必须使用对 Microsoft Wininet.dll 库的直接调用初始化对服务器端服务的调用。这些 Visual Basic 调用的示例在 参考资料部分中给出。然后他们将进行 SOAP 调用（请参阅 参考资料）。

第二个问题是以幂等方式处理序列消息，这样这些消息被执行一次，且一次。这是今天 Web 服务普遍的缺陷。为了避免这类问题（可能引起服务多次重处理同样的消息），小组添加了在服务级之上的应用程序软件中生成的独一无二的记录号。

此外，服务器没有别的方法识别客户端环境。由于是实现的安全系统的一部分，小组必须将证书包括进去，作为 SOAP 消息的部分。为了完成这些，他们在 Apache SOAP 实现中使用可用的 可插入提供者接口。

最后，在工程中，小组碰到了 Microsoft 和 IBM 工具箱中不兼容的 WSDL 实现问题。这是导致他们在部署系统中不能使用标准 WSDL 而选用他们自己的文档描述格式的原因之一。当工程一移入到更广阔的环境并且加入更多的公司（以及更多的客户系统），他们计划朝单一的兼容 WSDL 实现方向发展。他们使用的文档描述符的示例以及与描述符匹配的服务器端的示例存根在 参考资料部分中给出。

一旦经由 Wininet 库的调用建立了到服务器端的安全连接，Visual Basic 客户应用程序将进行恰当的 SOAP 调用来发送数据。理论上这将通过 WSDL 文件中的描述访问服务。但是，正如所提到的，它使用客户部署描述符。一组示例文件可在 参考资料部分中得到，描述了对 Wininet 的调用、Microsoft SOAP 工具箱、理论的 WSDL 文件、实际的客户部署描述符以及该特殊示例的服务器存根。

对于新修改的工资单系统的用户，将会有几种结果。首先，每个新的客户公司客户端软件的安装时间少于一天。假设客户软件支持标准化的 XML，所有真正需要的是使工资单应用程序可用所提供的 DLL 文件。在执行期间，在因特网上建立 SOAP 连接以及将必需的数据传给 Storebrand，操作者在进行客户数据录入时不需要做别的事。将 XML 包装为 COM 对象也消除了潜在的安全危险，在执行中故障期间，如果 XML 文件（作为客户机的文件系统的文档）仍然可访问将退出。这是特别不希望的，由于数据包含薪水以及其它相关员工信息，这种数据需要作为各自的义务进行维护。

回页首

成功的解决方案

现在，该工程投入工作几个月，随后将要为适应该领域所有 Storebrand 客户更复杂的情况而改进。这个初始系统采用了由 Storebrand 的客户广泛使用的一种领先的津贴处理软件（来自 Scandinavian 公司，Tietoenator）。但是，要使 Storebrand 的 6500 多个客户被广泛接受，他们预计将要对至少 30 个流行的津贴处理包进行处理。在客户端它包括相当多的不同平台，这说明系统真正的优点在于它确实是平台和语言独立的。

Storebrand 期望有一种组合 ? 能够容易地与使用不同系统体系结构的经销商和客户进行通信（使用 SOAP），能够使其服务为业界所知（使用 UDDI）以及能够发布关于怎样使用 Storebrand 应用程序的详细信息，这种组合将为其金融服务、银行业务、保险产品找到新的经销商，以及将潜在地将它的一些商业伙伴的供给吸收到 Storebrand 应用程序档案中。

Storebrand 也期望将 Web 服务用到 Storebrand 银行和基金业务单元内的其它业务领域中，也可以在这些地方减少内部的操作成本。

对于 Storebrand 的 Web 服务解决方案，数据维护有效的多，使现有客户和合作伙伴感到满意，公司认为其新的功能对预售有利。通过利用 XML 捕获和表示数据、通过修改 Storebrand 和客户间的业务过程以及通过使用面向程序到程序通信的 SOAP Web 标准，公司将能够节省手工信息捕获和输入时间所花费的成千上万小时 ? 这样就降低了直接影响公司成本底线的操作成本。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请参加关于这篇文章的 讨论论坛。
  
  
• 查找更多的关于 Storebrand ASA的资料。
  
  
• IBM jStart小组帮助公司将新技术实施到它们的企业系统。
  
  
• 此处有关于 Wininet 调用、 Microsoft SOAP 工具箱调用、潜在的 WSDL 文件、 部署描述符以及 服务器存根的示例文件。
  
  
• 从该工程一开始， Web 服务工具箱增加了许多新功能。
  
  
• 您也可以下载用于该工程的 XML 和 Web 服务开发环境。
  
  
• 学习 IBM MQSeries Integrator。
  
  
• 请在由 Larry Loeb 著的 developerWorks 文章中查找关于嗅探器的信息。
  
  
• 请访问该站点，学习更多的关于 IBM WebSphere 3.5.2的知识。
  
  
• 请核查以获取更多的关于 IBM VisualAge for Java 3.5的信息。
  
  
• 此处有更多的关于 IBM MQSeries Integrator 2的信息。
  
  

作者简介

为本文评分

评论

回页首

内容

• 业务和技术难题
• 寻找通用的格式
• 理想的解决方案：业界特定的 tModel
• 成功的解决方案
• 参考资料
• 作者简介
• 建议