内容


Web 服务最佳实践

第 8 部分

Web 服务最佳实践总结

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Web 服务最佳实践

敬请期待该系列的后续内容。

此内容是该系列的一部分:Web 服务最佳实践

敬请期待该系列的后续内容。

回顾客户情景

在过去的一年里,本系列的作者用 7 篇文章概述了 Web 服务最佳实践,其中包括现实世界中的 5 个客户情景,这些情景展现了通过使用 Web 服务技术来处理的业务和技术需求。业务和 IT 驱动程序映射到特定的电子商务模式来帮助确定在这 5 个客户约定中构建的解决方案的基本组件。对于这 5 个客户情景中的每一个,我们都详细地确定和讨论了业务目标、通用电子商务模式、逻辑体系结构;以及如何使用 Web 服务技术?在哪里使用以及为什么使用?。业务情景总结如 表 1中所示。

表1 —— 业务情景的总结

情景业务类型主要的业务需求得到的好处
Hopewell 国际贸易公司大宗金融服务公司集成 Microsoft 技术与 J2EE 技术以使需求实时访问金融数据的业务流程自动化。使得可以独立于平台或程序设计语言实时访问金融数据。从多渠道利用现有资源。使人工流程自动化。
协作型企业软件ERP 和 CRM 应用程序独立软件供应商集成支持客户-业务流程的第三方软件。减少集成工作的复杂性和成本。提高竞争能力。 集成不同平台上完全不同的应用程序。实现灵活的体系结构,使之能够适应业务需求的变化。通过集成第三方软件扩大客户群。
Galaxy Card全球支付公司提供通用工具来管理商家收购,这些工具为利益相关人实时传送和接收信息提供安全服务。消除对计划停止使用的现有资产的依赖。减少了运行成本。提高了收购新的商家的效率。使人工流程自动化。
PeoplesFuture 公司保险和金融服务公司提高与合作伙伴的运行效率来加强业务关系。减少集成成本。提高现有资产的利用率来提供新的金融产品以带来附加收入。使合作伙伴能够最优化数据检索来支持最终用户的任务。简化了集成工作。以新的方式重用现有资产。
Country-Wide Chartered Bank提供小额和大宗银行业务服务的全球性银行提高发展和运行效率。为利用现有的安全性服务的信息交付和应用程序部署提供基础架构。减少了维护和扩展软件基础架构的成本。以新的方式重用现有资产。

在总结这 5 个业务情景和它们的开发期间所使用的实现实践之前,让我们首先更明确地说明,当我们说到 实现实践时,我们是想要表达什么意思。到目前为止,在本系列文章中,除了这 5 个业务情景以外,我们还论及了一个语义框架并且采用了 IBM 电子商务模式的技术,来开发一种用来分析为什么以及在哪里 Web 服务可能在电子商务应用程序中起作用的方法。本文中的术语 实现实践是指在详细设计和开发阶段所使用的通用实践。它们不是关于特定行业的解决方案应该如何构造的通用业务实践,也不是用来确定应该在哪里应用 Web 服务的评估实践。然而,在决定了在什么地方利用 Web 服务之后,实现实践就可以用来促进互操作性,并且一旦部署好它们的初始项目,就可以更好地推动客户在他们的企业中利用 Web 服务。

除了上面为业务情景确定的主要的业务需求以外,一个更广泛的观点是,客户约定中提到的全部需求可以分成两个通用的需求集合:业务需求和技术需求。

业务需求

  • 提高流程效率
    • 缩短流程步骤的执行
    • 确保业务信息的质量
    • 使人工步骤自动化
    • 重用业务应用程序资产
  • 减少运行成本
    • 减少人工流程步骤的资源
    • 消除冗余的能力
  • 通过新的服务机会带来附加收入
  • 减少软件开发的时间、工作量和成本
  • 增强业务伙伴和客户关系
    • 更多地控制消费应用程序
    • 提高实现实现的方式的灵活性

从对约定的综合经验来看,上面的业务需求是有序的,位于顶部的是最普遍的。提高效率和减少运行成本是驱动约定最普遍的业务需求。

为了处理业务需求,需要把它们转化为技术需求,在技术需求中,可以通过使用技术来提供业务价值,即解决业务问题或者提供这样的机会。对于这 5 个业务情景的业务需求,下面的技术需求是通用的且可追踪的。并不是所有的技术需求都在客户约定的初始阶段处理;然而,下面用斜体字突出显示的技术需求是通过使用实现实践解决的,这将在下一部分中论及。

可追踪到业务需求的技术需求

  • 跨组织或企业边界的信息交换
    • 利用现有的基础架构组件和支持的传输
    • 在 Internet 上穿过防火墙发送消息
    • 在企业内联网内发送消息
  • 增强安全性
    • 加密机密或有市场价值的信息
    • 合作伙伴之间的验证
    • 利用现有的目录和公共密钥基础架构
    • 确保数据完整性
    • 遵循特定于公司的安全令牌格式和令牌生命周期策略
  • 多平台和程序设计模型间的互操作
  • 加强系统管理
    • 用于审计和不可抵赖性的日志事务
    • 版本 Web 服务实现
    • 确保可靠性、可用性和可服务性
    • 确定性能和负载能力
    • 确保管理和部署的简易性

一旦业务需求映射到可以通过技术解决的技术需求,IT 架构师、系统工程师和程序员通常会在他们的设计和开发阶段面临约束或强制条件。当利用现有的基础架构或集成遗留系统时,必须考虑到这些约束。通常,这些非功能的需求是真正的挑战或障碍,为了交付一个有效的解决方案,就必须对付这些挑战和障碍。下面用斜体字突出显示的技术需求是通过使用实现实践解决的,这将在下一部分中论及。

典型的挑战和障碍

  • 运行环境
    • 合作伙伴之间不同的安全性模型
    • 嵌入业务逻辑中的授权
    • 长期运行的后端进程
    • 经由现有的安全性组件的路由请求
    • 业务伙伴之间的语义差异
  • 运行时和部署
    • 相关的请求与它们的响应的相关性
    • 由于消息的解析或非本地传输而引起的性能问题
    • 由于不一致的供应商工具而带来的合作伙伴之间的互操作性问题
  • 策略、技巧、规划
    • 严格的安全性组织减缓了对新的集成技术的支持
    • 使用 Web 服务的经验水平
    • 能力规划

实现实践与业务实践

如前所述,本文中使用术语 实现实践来表示在详细设计和开发阶段使用的通用实践,它使得解决方案组件之间能够实现互操作性。在下表中,这些实践分成了 4 个不同的类别:设计、安全性、开发和基础架构。这些实践在客户约定中开发的许多解决方案之间是通用的,并且适用于没有在本系列文章中论及的其他业务情景类型。

在表的右列中用 OE来指示该实现实践用于 其他约定(Other Engagements),超出了本文中我们总结的 5 个业务情景。之所以在这里包括附加的实践,是为了让读者了解并熟悉如何解决在这些情景中不必解决的其他需求。

表 2 —— 设计实现实践

  • 利用现有的电子商务体系结构来实现 Web 服务。
    • 公开聚集简单服务的粗粒度服务并且只公开到合作伙伴需要的粒度来使他们的流程自动化。
    • 使用带有全部所需数据的无状态事务,这些数据包含在请求中。例如,将业务上下文信息(比如业务事务 ID 和授权代码)包含在 SOAP 消息体中。
  • 对于 Web 服务的同步 Internet 调用,使用 SOAP/HTTP 来促进互操作性。
    • 提供多重绑定(WSDL 端口类型)来使服务使用最优化。例如,利用通用平台之间的本地调用机制来提高性能(例如,EJB 之间内部使用 RMI/IIOP)。
  • 使用两个单独的同步调用并在初始请求时请求应用程序提供一个相关器来支持异步 Internet 操作。
OE
  • 消除对 XML 消息不必要的和冗余的的解析。
  • 利用行业 Schema(比如 Open Application Group Integration Specification(OAGIS)或 ACCORD。
    • 如果将 XML Schema 导入 WSDL,则可以利用由工具(例如,集成开发环境)和运行时提供的 JAX-RPC 映射。然而,请注意,在JAX-RPC V1.0 中,并不是所有的 XSD 类型都可以映射到 Java 类型。
    • 如果整个业务对象文档作为一个具有文档/文字(Doc/Literal)消息传递类型的字符串参数来传送,则可以使用 CDATA 标签来将文档嵌入 SOAP 体以减少 SOAP 解析的开销。
OE
  • 利用基础架构和运行组件来提供公共服务(例如,安全性、请求确认、数据/传输映射、路由、监控、记录)。

表 3 —— 安全性实现实践

  • 对于机密的或有市场价值的信息,将 HTTPS 用于 Internet 上的系统之间的所有外部流。
  • 当交换机密信息时,在合作伙伴之间使用相互 SSL 验证。
  • 利用 Web 服务安全性(WS-Security)。
    • 使用 SOAP 消息的 XML 数字签名来确保消息的完整性和特定于应用程序的验证。
    • 使用 SOAP 消息的 XML 加密来实现端到端的机密性。
  • 将与 Web 服务调用关联的用户的身份映射到共享的假名,以在不同的安全性域之间使用。通过将假名包含在请求之中而不公开单个安全域的细节可以降低安全性风险。
  • 使用 SOAP 头信息来交换安全性令牌和携带消息的时间戳。
  • 当使用 X.509 证书的私有密钥对消息进行数字签名时,将证书包含在请求之中,以使接收者能够提取证书的公共密钥来验证签名。

表 4 —— 开发实现实践

  • 依赖于行业工具使业务功能作为 Web 服务公开。比如,使用行业工具来生成用于描述服务接口的 WSDL。
  • 当通过应用程序处理 XML 时,使用文档/文字(Document/Literal)的消息传递和编码方式。
    • 当定义消息结构时,使用可扩展的 XML Schema 来添加新的数据特征。
    • 当处理消息时,只验证服务操作使用的数据,而忽略其他的参数。
  • 当使用采用 SOAP 编码的 RPC 时,使请求和响应的数据结构的复杂性减到最少。
  • 使用 SOAP 头信息块来交换非业务状态的信息(例如,相关器和消息 ID)。
  • 依赖于 SOAP Fault 元素而不是 HTTP 状态代码来确定 SOAP 处理错误或目标服务错误的出现。

表 5 —— 基础架构实现实践

  • 利用 HTTP V1.1 来提高性能。
  • 提供公共服务来卸载 Web 服务实现,比如:
    • 请求确认
    • 数字签名
    • 验证
    • 授权和身份映射
    • 事务的记录和监控
    • 数据和传输映射。
  • 通过公共网关或防火墙组件集中访问 Web 服务部署来实现操作和系统管理支持。
  • 动态地创建已部署服务的 WSDL,以便与产品中的保持一致。
  • 使用管理员控制的 UDDI 注册中心来管理内部和外部调用的 已批准服务。

在采用 Web 服务的现阶段,标榜上面的实现实践是真正“最佳”实践很可能有点为时过早,因此作者们更愿意地把它们称为“通用的”实践,期望随着时间的推移,它们中的大多数逐步达到达到“最佳”状态。如您所料,Web 服务互操作性(Web Services Interoperability,WS-I)组织制订的基本概要(Basic Profile)V1.0 中涵盖了上面列出的部分实践,其他的可能列入了基本概要(Basic Profile)V1.1 或未来的 WS-I 基本安全概要(Basic Security Profile)的计划之中。

吸取的经验教训总结

在这 5 个客户约定中,客户和 IBM 服务组织都获得了有价值的经验并且了解了使用 Web 服务的开发和部署业务集成解决方案的实际情况。关于什么起作用和什么不起作用的技术方面的经验教训通常是从实践中得来的,然而,新技术的出现对业务的影响不是总能得到开发解决方案的人的认可或理解。不过,本文将概述这些业务方面的影响和我们已经描述的情景中的客户提出的看法。

从业务的角度

  • 从小规模开始,快速扩大。
  • 部署 Web 服务的优先次序在合作伙伴之间和特定企业的组织内部有很大的不同。
  • 客户或合作伙伴能够通过 Web 服务接口来开发他们自己的自服务解决方案,这可能会引起业务的渠道冲突(例如从现有的渠道中取走收入)。
  • 将现有的客户基础迁移到新的技术模型,同时又不冻结当前产品的现行的销售,是一个挑战。

从开发和部署的角度

  • 每一个集成点都是一个进行抽象的机会,这使得组件之间的连接更灵活、更节省。
  • 尽可能快地使用安全性、基础架构和运行组织。
  • 利用现有的基础架构应用程序和服务需要详细的分析。
  • 规范本身并不能保证互操作性。
  • MS 和 J2EE 之间的互操作性还处在逐步成熟阶段,但是 WS-I 对于减少互操作性问题已经产生了重要的影响。
  • 行业工具对于有效地重用现有的应用程序功能是至关重要的。
  • 现有的标准提供了支持必需的异步操作类型的机制,但是异步操作还不是当今标准的主要部分(除了 BPEL 以外)。
  • 并不是所有成功支持基于浏览器与 HTTP 交互的标准都适用于 B2B,在 B2B 中,传输独立是必要条件(例如,用于 B2C 的 SAML 概要)。
  • 在不同的程序设计模型之间采用 SOAP 编码的 RPC 有非常大的问题。
  • 从原型迁移到产品需要对操作人员的技能有一个真实的评估,并且可能将需要 Web 服务方面的教育和培训。
  • 调整应用程序服务器能够对优化性能大有帮助。
  • Web 服务并不是到处都适用。

总结

从前面的文章中概述的业务情景和上面列出的吸取的经验教训,我们可以有把握的说,业界正在真正地使用 Web 服务来解决现实世界中的问题并且许多公司超过了概念证明阶段。从情景总结中不难看出,金融业正领导其他行业采用 Web 服务来提高运行效率和减少成本。同时也应该注意到,公司正有意识地决定何时使用 HTTP(S)之上的 SOAP 将业务功能作为 XML Web 服务公开来促进互操作性,以及何时利用本地传输或消息传递协议来优化他们的企业 Web 服务的性能。

通过设计 Web 服务基础架构来支持一组服务实现,在本系列中概述的许多客户第一次采用了完成上述工作的正确方法。Web 服务基础架构为安全性、系统管理、传输转换和现有系统组件的集成提供了公共服务。这些初始投资本身表明,这些公司已经非常严肃地接受了面向服务的体系结构方面有价值的建议来使基础架构更加有效、使 IT 更加灵活且实现资产的重用。

客户在 J2EE 和 .NET 环境之间遇到的互操作性问题已经通过定制组件解决了;然而,它们的情形是“时间点(point in time)”的一种反映。WS-I 组织的工作已经帮助解决了许多最近的基本互操作性问题。同样地,自从这样的约定出现以后,许多行业中间件和工具供应商已经更新了他们的产品来遵循 WS-I 基本概要(WS-I Basic Profile)。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=55136
ArticleTitle=Web 服务最佳实践: 第 8 部分
publish-date=01012004