跳转到主要内容

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

这是您第一次登陆到 developerWorks,已经自动为您创建了您的概要文件。 选择您概要文件中可以公开的信息的信息(如姓名、国家/地区,以及公司),这些信息同时也会与您所发布的内容相关联。 您可以随时更新您的 IBM 账号。

所有提交的信息确保安全。

  • 关闭 [x]

当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

所有提交的信息确保安全。

  • 关闭 [x]

Web 服务: Web 服务改进员工津贴处理

Storebrand ASA 通过 Web 服务提高效率

Natalie Walker Whitlock 是 Casaflora Communications 的主编,专门撰写电子商务及技术刊物有关内容。她经常为 developerWorks 撰写文章,同时还在一些出版物上发表文章,比如 PC World、Smart Computing、Office.com、iVillage、Intraware、 CBS Marketwatch 以及 The Tribune Syndicate。 您可以通过 Casaflora@aol.com 与她联系。

本文的有关信息由英格兰温彻斯特 Java 技术中心的 jStart 新兴技术小组的欧洲区编程经理 Anton(Tony)Fricko 提供。您可以通过 anton_fricko@uk.ibm.com与他联系。

Rawn Shah 提供了关于本文的其它信息。他是 developerWorks Web 服务专区的编辑,这些年他已经为许多技术杂志和几本技术读物撰写了 250 篇以上的文章。可以通过 rawn@us.ibm.com与他联系。

简介: 挪威公司 Storebrand 使用 Web 服务,通过使因特网上的系统自动化,帮助其客户提高员工津贴处理服务的效率。

发布日期: 2001 年 10 月 01 日
级别: 初级
访问情况 : 1131 次浏览
评论: 


作为挪威最大的金融服务公司,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 商务难题

  • 减少操作成本(50 名专门人员)
  • 自动化数据库录入和维护
  • 通过 Web 表单消除手工数据录入
  • 引入并使用业界标准来连接其它企业
  • 工作日内继续保持电子地连接另一个企业
  • 包含第三方供应商
  • 链接关键产品和服务
  • 为发展开拓新的机会

寻找通用的格式


该过程的第一步是确认并达成一个通用的数据格式。客户需要有一个通用的格式,使之能以一致的方式向 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详述了工程系统概念性的体系结构。


图 1. Storebrand 工程体系结构
图 1. Storebrand 工程体系结构

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

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

  • 定义和构建服务及其接口。
    • 构建 Java 类、C++、VB、COM 组件
  • 以 SOAP 路由器注册服务。
    • 通过 Apache SOAP 管理员 GUI 的 Webform 输入
  • 编写操作服务的客户程序。
    • 构建 Java 程序进行 Apache SOAP API 调用
      • 创建 SOAP 信封(envelope)
      • 发送 HTTP 请求
      • rpc 路由器为请求的服务选择部署描述符
      • 创建 Java 对象,并且将参数传给正确的方法
      • 产生响应:“响应对象”或显示错误(或其它预期的)结果
  • 定义“ Web 服务定义”及其接口
    • 创建部署描述符文件(或使用 Webform 进行定义)
    • 调用 Apache 实用程序来部署 RPC 路由器
    • 执行来自 JVM 的客户程序
    • 调用 SOAP API
    • 通过 RPC 路由器的端口或 SOAP 侦听器的 URL(http://localhost:8080/soap/servlet/rpcrouter)知道服务
  • 开发将 XML 文件封装为 COM 对象的客户代码,并且调用到 Storebrand WebSphere Java 环境的 SOAP 通信。
  • 连接到“UDDI 注册中心”(UDDI Registry)。
    • 用 UDDI 注册企业(“服务供应商”)
  • 也从使用 HTTP 上的 SOAP 的客户调用服务:
    • 直接使用基本的 SOAP 接口,忽略 UDDI 注册
    • 通过在 UDDI 中查找服务,并且经 WSDL 进行绑定

这种规模的工程使用崭新的技术不是没有原因。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 工程中使用的关键产品和技术

服务器端:

  • WebSphere 3.5.2
  • VisualAge for Java 3.5
  • IBM MQSeries Integrator 2
  • IBM XML Parser
  • IBM WSDE v1.1 [Version:R0.5 Alpha Build:0.033] 20/12/2000 来自 Alphaworks
  • IBM WSTK v2.2 16/02/2001 来自 Alphaworks
  • Web 服务工具箱(包括工具箱本身、一个 UDDI 实现以及各种演示)
  • IBM DB2 UDB PE v7.1(本地 UDDI 所需要的)
  • 几个 XML 工具(提供 WSDE)
  • HTTP 嗅探器(提供 WSTK)
  • Schema Beans

客户端:

  • Microsoft SOAP Toolkit v2.2
  • Visual Basic 6
  • XMLSPYeditor

请参阅 参考资料以获取更多的信息


成功的解决方案


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

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

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

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


参考资料

作者简介

Natalie Walker Whitlock 是 Casaflora Communications 的主编,专门撰写电子商务及技术刊物有关内容。她经常为 developerWorks 撰写文章,同时还在一些出版物上发表文章,比如 PC World、Smart Computing、Office.com、iVillage、Intraware、 CBS Marketwatch 以及 The Tribune Syndicate。 您可以通过 Casaflora@aol.com 与她联系。

本文的有关信息由英格兰温彻斯特 Java 技术中心的 jStart 新兴技术小组的欧洲区编程经理 Anton(Tony)Fricko 提供。您可以通过 anton_fricko@uk.ibm.com与他联系。

Rawn Shah 提供了关于本文的其它信息。他是 developerWorks Web 服务专区的编辑,这些年他已经为许多技术杂志和几本技术读物撰写了 250 篇以上的文章。可以通过 rawn@us.ibm.com与他联系。

关于报告滥用的帮助

报告滥用

谢谢! 此内容已经标识给管理员注意。


关于报告滥用的帮助

报告滥用

报告滥用提交失败。 请稍后重试。


developerWorks:登录


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 使用条款

 


当您初次登录到 developerWorks 时,将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人,但您可以随时修改这些信息的显示状态。您的姓名(除非选择隐藏)和昵称将和您在 developerWorks 发布的内容一同显示。

请选择您的昵称:

当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

(长度在 3 至 31 个字符之间)


单击提交则表示您同意developerWorks 的条款和条件。 使用条款.

 


为本文评分

评论

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=21172
ArticleTitle=Web 服务: Web 服务改进员工津贴处理
publish-date=10012001
author1-email=CASAFLORA@aol.com
author1-email-cc=
author2-email=rawn@us.ibm.com
author2-email-cc=