级别： 初级 Holt Adams (rhadams@us.ibm.com), IT 设计师, IBM jStart
Dan Gisolfi (gisolfi@us.ibm.com), 客户经理兼解决方案设计师, IBM jStart
James Snell (jasnell@us.ibm.com), 设计师兼策略专家, IBM Software Group
Raghu Varadan (rvaradan@us.ibm.com), 顾问 IT 设计师, IBM Global Services
2003 年 3 月 01 日 继续关注 Web 服务的最佳实践，通过分析用户的需求，我们为他们的业务伙伴们提供了一次安全单点登录的体验，这使他们能从分布式应用程序中聚集信息，同时也能使他们控制他们的最终用户体验而无需多次手动登录的过程。在这部分中，我们将新兴 Web 服务理念和 IBM 电子商务模式应用于现实世界的业务环境，来实现帮助 IT 管理人员和设计者更好地理解 Web 服务的角色和恰当使用 Web 服务的目的。
在此系列的头两篇文章中我们引进了 IBM 电子商务模式中的一个语义框架和一些实用技术来完善一个关于 Web 服务为什么以及在哪里可能在电子商务应用程序中发挥作用的分析方法。我们的方法已经被用来考虑由真正的 IBM 客户提供给我们的各种业务问题，以及探究通过使用 IBM 电子商务模式提供给我们的语义和组织框架来解决这些问题的解决方案。在这部分中，我们关注的客户是希望将 Web 服务技术融入到他们的解决方案中以便能更好地实现与他们的伙伴相关的业务应用程序的集成。他们也希望满足他们伙伴的要求以尽量减少用户直接介入多系统的应用程序界面的情况。
对于许多正在试图应用 Web 服务的开发者和应用程序设计师来说，主要挑战是：目前几乎没有提供关于如何在真实的业务情景中用最好的方式应用诸如 SOAP、WSDL 和 WS-Security 之类新技术的指导。本文的目的就是举一个真实的业务示例，按照前面几篇文章所列出的概念对这个示例进行分析；并在分析过程得出一些关于这种新技术的承诺和使用这种新技术来解决实际问题的现实如何相一致的经验教训。具体来说，我们将针对下面一组问题来分析该示例情景：
- 解决方案的业务目标是什么？
- 解决方案实现哪种通用的电子商务模式？
- 应用程序的逻辑体系结构是什么？
- 在构建应用程序的过程中，如何使用 Web 服务技术？在哪里使用以及为什么使用？
- 在应用程序中使用 Web 服务得到了哪些具体好处？
- 对于所用的技术和方法学，您取得了哪些经验和教训（正面的和反面的）？
另外，需要提一下，我们将这一系列文章放在一起的目的之一是使用实际的客户情景，IBM 的 Emerging Technologies jStart 小组和 IBM 的 Global Services 小组为这些客户情景实现了 Web 服务或类似于 Web 服务的应用程序。在本文和后续的文章中给出的分析是直接基于这些情景的。然而，为了保护 IBM 与我们的客户的关系的机密性和完整性，我们使用了虚构的公司名。但是，在此要记住的关键的一点是：这些项目是真实的，而不是基于假设的练习。我们将获得的最佳实践是基于设法使工作完成的真实情况，而不是基于理论或我们想当然的做法。
业务目标
PeoplesFuture 公司（PeoplesFuture Company，PFC）是一家提供财产／人寿保险、投资管理和退休储蓄计划的保险和金融服务公司。PFC 的业务范围很广，PFC 把它们的服务提供给其战略业务伙伴，后者再将金融和信息产品销售给各个公司和消费者。这些服务都目前是通过诸如呼叫中心和供注册业务伙伴的参与者访问的 Web 站点等传统渠道提供给业务伙伴的。进出服务间的信息交换经常是在保密状态下进行的，而且对于 PFC 和它的伙伴之间业务流程的执行来说很关键。
目前，区域销售代理商和电话销售商一般是从互联网上的各种资源或通过 PFC 呼叫中心访问信息的，并将其作为他们销售过程的一部分。对于代理商来说，在不同的 Web 站点上有多个用户帐户很正常，这些站点要求用户帐户来管理多用户的身份标识与密码，更别提还要浏览站点来检索相关信息以与客户合作。作为销售代理商雇主身份的业务伙伴通常想以他们自己的名义从分布式应用程序／站点上检索信息，以达到优化其销售过程和控制销售商查阅和运用信息的方式的目的。
PFC 希望通过集成他们的应用程序以及在增加他们现有内部资产的使用的同时降低集成的成本的方法来改善和他们的业务伙伴间的操作效率。同样地，PFC 想加强他们的业务伙伴关系。PFC 的目标是使得他们的伙伴能更好地与其后端系统进行通讯，并且提供的界面和控制系统能允许伙伴完全掌握其雇员在递交和使用从 PFC 中检索来的信息的过程。通过实现这些目标，PFC 期望能减少呼叫中心的资源和对现有资产的再利用来提供新的服务，以便达到降低总成本的目的。
PFC 将上面提出的各条要求看作是能够完全成功地把它们的业务伙伴迁移到面向服务的体系结构中的关键所在，能涵盖这些要求的一个业务目标是，集成解决方案必须使工作量最小、复杂度最低，并且合作伙伴只需最少的成本就可以利用 PFC 提供的新功能。
PFC 概括后提出他们的业务目标的技术要求包括使用能更有效地启用互操作性的开放标准技术，以及确保针对他们的伙伴能有最广泛的技术厂商的选择。他们主要的技术担忧是集成解决方案要求与平台无关（操作系统和编程语言），它需要支持集中监控，允许网络传输独立的信息交换，允许网络传输安全策略的独立实施，使得现有的认证和授权系统被利用，并且使用易用的对解决方案组件的执行和部署进行的工业加工。为了实现这些目标和要求，PFC 选择了 Web 服务，并允许它们提出一切所需。
展望未来，PFC 也要求解决方案的基础结构能够支持出站 Web 服务的请求，这样当将来有新的业务需求需要 PFC 业务应用程序与其他业务伙伴应用程序开始交互时，它们能有构建的基础。
适用的电子商务模式：公开业务服务和集成器
从规定的业务目标和技术要求出发，我们已经能控制解决方案的总需求来使现有的业务功能可以通过一个集中控制点安全地被已注册的参与者们使用，其中通过这个集中控制点我们能实现对流程和功能的管理和监控。
在下面的
表 1中，（您已从这个专栏的前面几篇文章中熟识），我们将业务要求映射到特定的电子商务模式。我们使用这张表来帮助确定特定的电子商务模式，该模式有助于我们识别我们需要构建的解决方案的基本组件。在这张表中，我们已经突出显示了适用于当前情景的各项要求，其中最适用的用蓝色表示。尽管我们不会讨论业务伙伴的解决方案的体系结构和设计，但用粉红色突出显示的模式表明了那些业务合作伙伴仍然必须遵循的要求。
表 1.选择电子商务模式
| 业务和 IT 驱动因素 | 业务模式 | 集成模式 | |
自助服务
|
协作
|
信息聚集
|
扩展企业
|
访问集成
|
应用程序集成
| | 最终用户和客户需要直接与业务流程和／或数据进行交互。 | X | X | X | | X | | |
业务流程需要与现有的业务系统和信息进行集成。
|
X
| | | | |
X
| |
业务流程需要与存在于伙伴组织中的流程和信息集成。
| | | |
X
| |
X
| |
业务活动需要从组织内外的各种来源聚集、组织和提供信息。
| | |
X
| |
X
|
X
| | 必须能够以一种普通、一致和简化的方式通过多种传送渠道访问业务流程。 | X | | | | × | | | 业务活动要求并鼓励协作以及协作参与者之间的共享信息。 | | X | | | | |
该表为 PFC 提供了几个不同的选项。然而，基于关键的业务驱动因素，扩展企业业务模式对 PFC 而言是一个显而易见的选择，因为其主要情景包含了一个公共流程中的伙伴间的交互。扩展企业业务模式（也叫做企业到企业或者 B2B 模式）是在不同的企业业务流程间进行交互和协作的。在解决方案中经常使用该模式来实现连接企业间应用程序的编程接口。该业务模式直接映射到 PFC 的情景中，最常见的实例如下所示：伙伴 B 调用一个公共流程，而该流程又去调用伙伴 A（或 PFC）里的一个特定的私有流程流。伙伴 B 并不关心伙伴 A 进行内部处理的细节。伙伴 B 只对它希望从调用的公共流程中获得的结果感兴趣。也请参阅
图 1。
考虑到 PFC 情景的本质，其中来自伙伴的请求是相互独立的（不需要相互关联）并且它们包含了多 PFC 应用程序的处理过程或者对多 PFC 数据存储的信息的检索，因此公开业务服务是一种满足它们当前要求的极好的应用程序模式。该模式如
图 2所示。
PFC 想将自己定位为不仅支持遵循 Web 服务开放标准的 B2B，而且支持它的后端系统和它各种内部应用程序和伙伴的后端系统的企业应用程序集成（Enterprise Application Integration，EAI）。该应用程序集成模式在服务于集成多业务模式或者服务于在个别业务模式中的集成应用程序和数据（我们的案例属于后者）时也是适用的。产生该模式的要求要求对 PFC 现有财产进行再利用，以及实现利用现有的认证和授权系统应用程序的解决方案。由于 PFC 的主要目标是支持业务伙伴启动的公共流程，所以内部集成现有的安全系统来支持该公共流程是必要的。在回顾应用程序集成的应用程序模式时，聚集器模式（如
图 3所示）是最佳选择，因为 PFC 在处理一个外部请求时不得不将多个内部请求分配给业务应用程序和基础应用程序。
该应用程序模式的关键功能部件是消息路由和分解与重组的转换处理。对于一个一对多的集成流程而言，启动程序的（或伙伴 B 的）请求必须分解成多个请求传到目标应用程序（带有关联消息转换），然后在接收响应时它必须聚集回一个单一的响应传到该启动程序。对于 PFC 来说，来自他们伙伴之一的业务服务请求会导致多个基础应用程序将在补充流程实体的业务应用程序功能被调用（用户标识映射，认证／授权），正如
以上所述。在把公开业务服务和聚集器应用程序模式组合起来时，在上图右边标为
Process的实体将包括 1）Exposed Business Services Tier（作为业务应用程序的前端系统）和 2）被聚集起来响应业务伙伴请求的公共系统应用程序。即使基础应用程序没有提供在构建响应时使用的直接输入，它们的服务对于授权以及构建发送至业务流程的请求来说也是必需的，这样该应用程序模式才可能被应用。
图 4显示了公开业务服务和聚集模式的基本运行时的体系结构。
逻辑解决方案体系结构
既然我们已经建立了基本的业务目标，选择了特定的应用程序模式，并且对最终解决方案应该是什么样子有了基本了解，现在是探究基础结构解决方案的特定体系结构的时候了。在该解决方案体系结构中，
消息／集成代理程序实体是通过使用 J2EE 编程模型和连接器体系结构以及新兴 Web 服务的标准集来实现的。我们所使用的关于 Web 服务基础结构的方法是尽量多地使用开发 Web 服务技术的中间设备组件，利用现有系统组件的功能以及利用集成现有软件资源的集成点。同样，提供给业务应用程序和系统应用程序的接口是被作为 J2EE 平台上的 XML Web 服务来内部公开的，这样 PFC 现在就能利用它们，以及将来在其他企业应用程序集成项目中利用它们。
图 5显示了逻辑应用程序的体系结构。
支持公共流程的解决方案的公共组件是由 WebSphere Business Connection（包括 WebSphere Application Server 版本 4 和 Web Services Gateway）组成的，它还提供了一个公开业务服务的集中控制点和充当了一个启用消息路由、监视、记录、控制出入站请求和整个 Web 服务解决方案的系统管理的服务代理人的角色。WBC 的 Web 服务网关（Web Services Gateway）组件提供了许多对 Web 服务的操作性支持，使得过滤器在业务服务调用之前和之后被调用。对 PFC 来说，基础服务在业务服务将尚待证实的用户身份映射到本地身份之前被调用，然后用来检索用户在使用服务权限时的特权。
代表应用程序 Web 服务接口的 Java 组件位于各 WebSphere Application Server 的第二层，并且支持后端业务应用程序和系统应用程序的本地接口。将接口作为 Web 服务在内部，在防火墙中公开使得 PFC 达到资产再利用的目的。通过利用和扩展构建于 WebSphere Studio 和 Web 服务网关内部的功能，PFC 启用了数字签名和对消息交换在 SOAP 层进行加密，使得它们的解决方案传输独立。它们也实现了一个联合身份模式来传递用户声明和安全性上下文令牌以支持业务伙伴和他们的应用程序间的单点登录。
除了允许
内部应用程序的功能作为 Web 服务被外部公开以外，Web 服务网关在仍然利用基础服务公共集的同时，还允许内部应用程序访问由外部伙伴提供的 Web 服务。强调对 Web 服务调用的双向支持对于说明固定的体系结构是如何允许 PFC 满足所有它们提出的要求的很重要。
Web 服务的适用性
在
第 2 篇文章中，我们介绍了一条普遍规律，即“在所有必须交换信息的边界上（这个边界可以存在于业务之间、应用程序之间或是解决方案的逻辑组件之间，等等），Web 服务将影响业务模式、集成模式以及应用程序模式的实现。”对于 PFC 的情景这种情况，解决方案的公共组件和内部业务应用程序的接口都是基于 Web 服务技术的。
具体地说，解决方案采用带有私有接口的内部应用程序组件，并将其作为 Web 服务进行内外公开。使用
第 1 篇文章中的术语（请参阅图
6和图
7），由于 WSDL、SOAP 和 HTTP 分别作为说明、消息传递和传输协议来使用，因此我们将对公开为 XML Web 服务的 Web 服务进行分类。我们这么做是为了允许内外流程具有最好的互操作性。
即使 PFC 使用 Java 组件来作为他们旧系统的前端，他们在初始阶段也已经选择了 HTTPS 上的 SOAP 来确保与其他企业应用程序集成的内部应用程序之间的互操作性。然而，由于 Java 组件是 EJB，它们可能也在为 J2EE API 创建 WSDL，使得 Web 服务网关能利用它们的本机 RMI 接口。随着时间的推移，PFC 将完成评估并在优化性能的基础上可能还会将业务应用程序作为企业 Web 服务来公开，使 Web 服务网关和其他的基于 J2EE 的应用程序来利用 Web 服务实现的本机协议的潜在利益（例如，用于同步操作的 RMI 和用于异步操作的 JMS）。
XML Web 服务的实现主要是为了确保不同种类的运行时和开发环境之间的互操作性（例如 Microsoft .NET 和 J2EE）。企业 Web 服务的实现在另一方面是为了利用应用程序间松散耦合的集成点。SOAP 和 HTTP 被人们广泛接受，并且是能在各种环境下都被支持的可互操作的消息传递和传输协议；它们还已经被标准化或者在被标准化的过程中。这使得它们的使用对于达到互操作性的目的来说是理想的。JMS 和 RMI 只被 Java 平台所支持，而且它们也并不是确保互操作性的最佳协议，但它侨肥滴?J2EE 环境下运行的集成应用程序形成了一个很好的框架。因为在
消息／集成代理程序中的公共和私有组件都是基于 J2EE 技术的，JMS 和 RMI 的使用非常合适，并可能被证实为比 SOAP 和 HTTP 更为有效。
吸取的经验
在构建解决方案的体系结构和该情景的最初实现时，我们获得了几个关于所涉及的技术、标准和业务概念的重要经验：
- 工业加工对于实现现有应用程序的有效再利用来说是重要的（例如，为 Java 组件自动生成 WSDL 描述）。
- 利用现有的基础应用程序和服务需要详细的分析，为了：
- 标识要用到的特定功能
- 判定和优化要公开的接口
- 通过确定哪里是最适合进行功能集成的地方来确保松散耦合，这将使得总的解决方案的可行性最大化。
- 尽量利用公共的基础组件或成功支持基于 HTTP 交互的浏览器的当前工业标准，对于将传输独立作为一个要求的 B2B 来说并不总是可行或者并不总是一个好主意（例如，SAML － 现有相关定义为 Security Assertion Markup Language）。
- 从原型到成品要求对操作人员技术的一个诚实评估，并将可能要求 Web 服务（例如，部署、配置和检测）方面的教育和训练。
- WS-Security 的互操作性在此没有给出，但独立研究成功地表明了 Microsoft 和 IBM 之间的互操作性（请参阅
参考资料部分的报告）。
总之，PFC 的 Web 服务首创精神带领着他们走过了一条充满干劲的学习之路，使得他们能提供对他们的战略伙伴的后端系统的访问，给予了他们那种使得他们的代理商更好地销售和服务 PFC 的金融和信息产品的能力。从使得 B2B 集成的单点登录的联合身份模式概念到集成私有认证和授权系统，进一步为 PFC 强调了 Web 服务技术在集合和确保异构设计环境之间的互操作性上的价值。
参考资料
作者简介  | | | Holt Adams 是支持 IBM 的 jStart 计划的高级 IT 设计师，他与客户和业务伙伴一起工作，帮助他们采用新兴技术（如 Web 服务）。1982 年从 University of Tennessee 获得电子工程学位毕业后，他加入了 IBM 位于北卡罗来纳州的 Research Triangle Park。他在以下这些方面有经验：通信和网络产品的软硬件开发、移动和无线解决方案的技术市场营销以及基于因特网的解决方案的体系结构和集成。在过去两年间，他一直致力于把 Web 服务提升为 IBM 的战略性集成技术，起初是和客户一起开发概念的证据，最近在为生产环境开发解决方案。您可以通过
rhadams@us.ibm.com与 Holt 联系。
|
| | | Dan Gisolfi 是 IBM 的 jStart emerging technologies 小组的客户经理兼解决方案设计师。他从事客户约定的商业和技术两方面的工作。他有很多头衔，从业务开发经理和宣传者到解决方案设计师和合同谈判代表。Dan 目前致力于通过实际的商业解决方案来帮助 IBM 推进 Web 服务的采用。您可以通过
gisolfi@us.ibm.com与 Dan 联系。
|
| | | James Snell 是 IBM 的 software group 中的 emerging Internet technologies 小组的一名设计师兼策略专家，在这个小组中，他在 Web 服务技术不断发展的体系结构和实现中起到了积极的作用。他是
Programming Web Services with SOAP（O'Reilly 和 Associates 出版）一书的合著者。您可以通过
jasnell@us.ibm.com与 James 联系。
|
| | | Raghu Varadan 是 IBM Global Services 的 Architecture Center of Excellence 的顾问 IT 设计师。在软件咨询、阐述技术的广泛业务应用、策略技术规划以及系统体系结构方面，他有超过 14 年的经验。他在开发大型的、复杂的、企业范围的体系结构、面向对象和客户机-服务器体系结构和开发方面有丰富的经验，并且曾参与软件开发的整个生命周期的业务和技术两方面的工作。您可以通过
rvaradan@us.ibm.com与 Raghu 联系。
|
对本文的评价
| 
