IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope: Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  WebSphere | SOA and Web services  >

使用 WebSphere DataPower SOA Appliances 的 REST 服务模式

developerWorks
文档选项

未显示需要 JavaScript 的文档选项

英文原文

英文原文


级别: 中级

Daniel Colonnese, WebSphere 技术专家, IBM
Alex Klevitsky, 体系结构和企业软件主管, MIB, Inc.

2007 年 10 月 27 日

本文描述使用 WebSphere® DataPower SOA Appliances 来实现 REST 风格软件系统的服务模式。这些模式将帮助加速 DataPower Appliances 的采用,并帮助架构师构建更灵活的软件系统,以及改进 REST 风格软件服务的安全性和可伸缩性。

引言

本文描述在基于代表性状态传输(Representational State Transfer,REST)体系结构来实现 SOA 解决方案时,作为基础结构组件的 WebSphere DataPower SOA Appliances 所能发挥的作用。本文介绍的远景对 IBM 的 ESB 解决方案系列形成了补充,该系列包括 WebSphere ESB、WebSphere Message Broker 和 WebSphere DataPower Integration Appliance XI50。尽管简单性是建议的解决方案的重要特性,但是我们想要强调的是,驱动体系结构决策的是业务需求而不是技术偏好。

SOA 模式与 REST

IBM SOA Center of Excellence 将 SOA 定义为“由松散耦合的 IT 元素支持的灵活业务功能体系结构”。SOA 被视为一组体系结构指导原则,而不是一个参考体系结构。许多 SOA 定义尝试系统地阐述这个新的体系结构的指导原则。这些单独的原则并不是新的,但是现在作为单个内聚的单元来公开。这些指导原则为 SOA 参考模型提供了基础。

Exposed Broker 应用程序模式的 Exposed Router 变体(请参阅 Patterns:SOA with an Enterprise Service Bus)为 SOA 环境提供了基础。根据 Len Bass 在 Software Architecture in Practice 中的观点,软件系统不仅反映了需求(同时在功能和系统质量方面),而且还反映了架构师的背景和知识。架构师选择最常见和最熟悉的样式来满足系统需求。过去 30 年间,大型软件系统中的主导样式一直是“调用并返回”体系结构。在这些样式中,最流行的是客户机-服务器样式,其中程序是组件,而调用或远程过程调用(remote procedure call,RPC)则是连接器。正如在 Pattern-Oriented Software Architecture, Volume 1, A System of Patterns 中所述,客户机-分配器-服务器样式“在客户机和服务器之间引入了一个中间层,即分配器组件。它通过名称服务提供了位置透明性,并隐藏了在客户机与服务器之间建立通信连接的细节”。客户机-分配器-服务器模式描述了 Broker 模式的一种直接变体,表示服务器和客户机使用并理解同一种协议。本文描述如何将 DataPower 设备公开为分配器变体。

SOA 的优点可以通过异构的体系结构样式来实现,这些样式由 SOA 体系结构模式和 REST 所创建(请参阅 Roy Fielding 撰写的 Architectural Styles and the Design of Network-based Software Architecture)。REST 是包括现代 Web 在内的分布式超媒体系统的主要体系结构样式。WebSphere DataPower SOA Appliances 加速了基于这种样式的软件系统的实现。人们对 REST 的关注不断上升,主要的驱动因素归功于 Web——有史以来曾创建的最大的软件系统。Roy Fielding 的开创性论文阐述了 REST 数据元素、组件、连接器,并介绍了如图 1 所示的流程视图,以说明组件之间的交互:


图 1. 流程视图,摘自 Roy Fielding 的博士论文,2000 年
图 1. 流程视图,摘自 Roy Fielding 的博士论文,2000 年

Fielding 在对此流程视图的描述中指出,“REST 提供了一组体系结构约束,当将这组约束作为整体进行应用时,将强调组件交互的可伸缩性、接口的通用性、组件的独立部署,以及用于减少交互延迟、强制安全性和封装遗留系统的中间组件”(在这段引述中加粗的部分是我们自己添加的)。他补充说,“分层的系统约束允许在通信中的不同点引入中介——代理、网关和防火墙——而不需要更改组件之间的接口,从而使这些中介可以帮助进行通信转换,或者通过大规模共享缓存来改进性能”。特别是,“网关(也称为反向代理)组件是由网络或原始服务器强加的中介,目的是封装其他服务的接口,用于数据转换、安全强制和加速等。请注意,代理与网关之间的区别在于,客户端将确定自己何时使用代理”。DataPower SOA 设备提供了多协议网关(Multi-Protocol Gateway,MPGW)应用程序组件,此组件提供了廉价和松散耦合的 REST 网关组件实现。它还代表“服务器端代理”(即 Exposed Broker 模式的参与组件)的变体。

最近 SOA 和 REST 的流行对 DataPower 设备在 Dispatcher 或 Gateway 模式中的使用形成了完美的补充。虽然 DataPower 不支持表示形式缓存 (representation caching),这是 REST 样式的一个重要约束,但是该设备实现了有限的缓存,例如用于数据转换的 XSL 样式表的缓存。一般粗粒度的服务可以论证表示形式缓存的合理性。当信息高度动态时,这种方法也许无益,因为缓存引入的开销可能挫败缓存的预期目的。

DataPower 网关设计模式

本文不关心特定的实现细节;相反,它是讨论设计备选方案的意见书。在最近出版的 RESTful Web Services 一书中,作者讨论了基于 REST 体系结构样式的 Web 服务的设计和实现,并考虑到了功能需求(包括安全强制、协议转换、数据转换和路由)以及非功能需求(包括性能和易用性)。

引入 WebSphere DataPower Appliances 作为网关提供了设计选择方面的灵活性,否则在纯软件的设计中,这些设计选择可能需要复杂的代码编写逻辑。基于设备的功能,我们建议了网关模式的三种层次结构变体:安全网关、安全-加速器网关和安全-装饰网关,如图 2 所示。每个较低级别的模式帮助完善较高级别的模式。


图 2. 作为 REST 服务网关的 DataPower
图 2. 作为 REST 服务网关的 DataPower

安全网关模式使用 DataPower 来提供安全服务和协议中介。DataPower MPGW 使用 DataPower 安全功能,例如 AAA、CRL 验证、流量控制和 XML 威胁保护。DataPower 的集成功能包括对各种消息协议(例如 MQ、JMS)和 FTP 传输以及前端 HTTPs 的支持。根据 REST 流程视图,多传输支持并不与 REST 冲突。REST 的无状态性质要求安全网关假设所有客户端流量都是可疑的,并且所有后端消息都已经过授权并且有效。

由安全网关模式加以完善的安全-加速器网关添加了 XML 消息的数据转换和验证。DataPower XML 加速功能大大提高了 XML 处理性能,并提供了高度有效的解决方案,将从客户端接受的可编程表示形式(例如 XML)转换为公共的内部XML 消息格式(或特定于业务的 XML 词汇)。我们建议包括 XML 模式遵从性验证,使用其他基础结构组件来执行此验证的代价将更高。除了用于基本的 XSD 模式验证以外,我们发现 ISO Schematron 对于实现约束和复杂的业务规则验证也非常有用。对于 REST-AJAX Web 应用程序,您可以使用 DataPower 来通过 ISO Schematron 或 XPATH 执行客户端验证,从而进一步减少延迟,同时降低应用程序服务器上的负荷。您可以使用设备的基于内容的路由功能,以支持对公共的内部 XML 消息格式进行版本管理。

安全-装饰网关由安全-加速器网关加以完善,安全-装饰网关在公共的内部 XML 消息格式的基础上,添加了可读(例如 XHTML)和可编程(例如 XML)接口的表示形式构造。此模式是代理-装饰模式的变体,Design Patterns:Elements of Reusable Object-Oriented Software 一书的作者将其设想为众所周知的代理和装饰模式的组合。

Web 2.0 与展望

易用性或连通性是 Web 2.0 技术的重要关注焦点。许多架构师强调 REST 服务提供了这种易用性品质。DataPower WS-Proxy 和 MPGW 应用程序组件提供了相关功能,以通过提供对非 REST Web 服务的替代支持来进一步扩大这种品质。您可以扩展这些模式,以将 SOAP 包装、WSDL 和 Web 服务功能添加到现有的 REST 服务。

您还可以在 REST 和所选的 SOA 体系结构模式基础上构建其他异构体系结构样式。有关更多信息,请参阅 Patterns:SOA with an Enterprise Service Bus

结束语

本文描述了一些用于服务设计的基于高级模式的体系结构。请记住,要成功应用这些模式,您的软件系统必须建立在计算机科学中的常识性和经证实的实践基础上。但愿您能够应用这些软件模式来更好地组织下一代面向服务的软件。

总之,我们要建议的是,基于模式的体系结构样式和软件设计模式的使用方式,应该与模式体系结构语言之父 Christopher Alexander 在民用建筑领域中倡导的模式用法相同,这样才能构建更好的系统,而不只是解决给定上下文中的重复问题。



参考资料



作者简介

Daniel Colonnese 是一名 WebSphere 专家,致力于帮助保险和金融服务客户设计和构建基于服务的应用程序。


Alex Klevitsky 是 MIB, Inc. 的体系结构和企业软件主管。他在商业和工程应用程序以及软件工具的设计、开发和实现方面拥有超过二十年的经验。




对本文的评价










回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款