CN106575305B - 反向代理服务器内的服务 - Google Patents

Abstract

本发明的实施例提供了用于处理在计算机网络之间传输的消息的技术。诸如来自客户端设备的对web服务和其它web内容的请求的消息可以在多个计算机网络之间传输。诸如代理服务器的中介设备或应用可以在通信端点之间接收、处理和传输消息。在一些实施例中，反向代理服务器可以被配置为在反向代理服务器内动态生成表述性状态传递(REST)服务和REST资源。反向代理服务器内的REST服务和REST资源可以处置来自客户端设备的传入请求并调用后端web服务，从而允许反向各种安全性策略在代理服务器上的设计抽象和/或实施。

Description

反向代理服务器内的服务

相关申请

本申请要求于2015年4月25日提交的标题为“SERVICES WITHIN REVERSE PROXYSERVERS”的美国非临时申请No.14/696,432的权益和优先权，该申请要求于2014年9月24日提交的标题为“MOBILE SECURITY ACCESS SERVER(MSAS)”的美国临时专利申请No.62/054,613的权益和优先权。以上识别出的专利申请的全部内容通过引用被结合于此，用于所有目的。

背景技术

本公开一般而言涉及用于提供跨计算机网络的安全性的系统、方法和计算机可读介质。更具体而言，本公开涉及用于在客户端设备与后端web应用和服务之间实现的代理服务器处提供安全性服务和其它功能的系统、方法和计算机可读介质。这样的安全性服务可以包括认证、授权、审计、单点登录、安全性策略实施、密钥管理和分发、安全通信、安全数据存储和安全数据共享等。

发明内容

本文描述的方面提供了用于处理在计算机网络之间传输的消息的各种技术。在一些实施例中，诸如来自客户端设备的对后端web服务、应用和其它web内容的请求之类的消息可以在多个计算机网络之间传输。诸如在物理子网络或逻辑子网络内实现的代理服务器之类的一个或多个中介设备或应用可以在通信端点之间接收、处理和传输消息。在一些实施例中，反向代理服务器可以被配置为在反向代理服务器内动态地生成表述性状态传递(Representational State Transfer，REST)服务和REST资源。反向代理服务器内的REST服务和REST资源可以处置来自客户端设备的传入请求并调取后端web服务，从而允许各种安全性策略在反向代理服务器上的设计抽象和/或实施。

根据本文描述的某些方面，代理服务器可以接收对由代理服务器内的REST web服务暴露的特定资源的web服务请求。代理服务器中的REST web服务内的适当资源可以被调取，并且可以继而调取后端web服务。在一些情况下，反向代理服务器可以暴露使各种后端web服务虚拟化和模糊的一组REST web服务。例如，反向代理服务器可以只暴露虚拟的统一资源定位符(URL)，使得不受信的网络上的客户端设备不能看到底层后端web服务或不具有关于底层后端web服务的知识。

根据本文描述的附加方面，REST服务和REST资源可以在反向代理服务器内生成，以处置从客户端设备接收到的REST请求中的一些或全部。这些REST服务/资源可以在反向代理服务器内动态生成并配置为处置REST请求和/或调取对应的多组后端web服务。为了动态地生成和管理REST web服务/资源，可以在反向代理服务器内实现REST基础设施和/或REST应用引擎。附加地，在一些实施例中，反向代理服务器内的REST资源可以生成后端web服务调用并将其提供给用于实施各种策略的策略实施引擎。

附图说明

图1是示出示例性分布式系统的组件的框图，可以在该示例性分布式系统中实现本发明的各种实施例。

图2是示出系统环境的组件的框图，由本发明的实施例提供的服务可以通过该系统环境被提供作为云服务。

图3是示出在其中可以实现本发明的实施例的示例性计算机系统的框图。

图4A和图4B是在高层级示出计算环境的例子的框图，该计算环境包括根据本发明的一个或多个实施例的、用于在计算设备和/或系统之间处理和传输消息的反向代理服务器。

图5是在高层级示出根据本发明的一个或多个实施例的、用于接收和处理REST请求的反向代理服务器的另一个框图。

图6A-图6B是示出根据本发明的一个或多个实施例的、用于接收和处理来自客户端设备的REST请求并且确定和调取后端web服务的过程的流程图。

图7是在高层级示出根据本发明的一个或多个实施例的、用于动态生成REST服务和REST资源的反向代理服务器的另一个框图。

图8是示出根据本发明的一个或多个实施例的、用于在反向代理服务器上生成、构建和部署REST服务和REST资源的过程的流程图。

图9是在高层级示出根据本发明的一个或多个实施例的、包括策略实施引擎的反向代理服务器的另一个框图。

图10是示出根据本发明的一个或多个实施例的、用于使用所确定的消息处理策略来处理和传输消息的过程的流程图。

具体实施方式

在以下描述中，为了解释的目的，阐述了许多具体细节以便提供对本发明的各种实施例的透彻理解。然而，对于本领域技术人员将显而易见的是，本发明的实施例可以在没有这些具体细节中的一些细节的情况下进行实践。在其它情况下，众所周知的结构和设备以框图的形式示出。

随后的描述只是提供示例性的实施例，并不旨在限制本公开的范围、适用性或配置。更确切地，随后的示例性实施例的描述将为本领域技术人员提供能够实现示例性实施例的描述。应当理解，在不背离如所附权利要求中阐述的本发明的精神和范围的情况下，可以对元件的功能和布置进行各种改变。

在以下描述中给出了具体细节以提供对实施例的透彻理解。然而，本领域普通技术人员将理解，实施例可以在没有这些具体细节的情况下实践。例如，电路、系统、网络、过程和其它组件可以以框图的形式被示为组件，以便不会以不必要的细节模糊实施例。在其它情况下，众所周知的电路、过程、算法、结构和技术可以在没有不必要的细节的情况下示出，以便避免模糊实施例。

此外，应当注意，各个实施例可以被描述为绘作流程表、流程图、数据流程图、结构图或框图的过程。虽然流程图可以将操作描述为顺序的过程，但是这些操作中的许多操作可以并行或并发地执行。此外，操作的顺序可以被重新布置。过程在其操作完成时终止，但是可以具有未包括在图中的附加步骤。过程可以对应于方法、函数、工作程序、子例程、子程序等。当过程对应于函数时，过程的终止可以对应于函数返回到调用函数或主函数。

术语“计算机可读介质”包括但不限于非临时性介质，诸如便携式或固定存储设备、光学存储设备，以及能够存储、包含或携带(一个或多个)指令/或数据的各种其它介质。代码段或计算机可执行指令可以表示工作程序、函数、子程序、程序、例程、子例程、模块、软件包、类、或指令、数据结构或程序语句(program statement)的任何组合。代码段可以通过传递和/或接收信息、数据、自变量、参数或存储器内容耦合到另一代码段或硬件电路。信息、自变量、参数、数据等可以经由包括存储器共享、消息传递、令牌传递、网络传输等的任何合适的方法来传递、转发或传输。

此外，实施例可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或其任意组合来实现。当用软件、固件、中间件或微代码来实现时，执行必要任务的程序代码或代码段可以存储在机器可读介质中。(一个或多个)处理器可以执行这些必要的任务。

本文描述了用于处理在计算机网络之间传输的消息的各种技术(例如，方法、系统、存储可由一个或多个处理器执行的多个指令的非临时性计算机可读存储存储器等)。在一些实施例中，诸如来自客户端设备的对后端web服务、应用和其它web内容的请求之类的消息可以在多个计算机网络之间传输。诸如在物理子网络或逻辑子网络内实现的代理服务器之类的一个或多个中介设备或应用可以在通信端点之间接收、处理和传输消息。在一些实施例中，反向代理服务器可以被配置为在反向代理服务器内动态生成表述性状态传递(REST)服务和REST资源。反向代理服务器内的REST服务和REST资源可以处置来自客户端设备的传入请求并调取后端web服务，从而允许各种安全性策略在反向代理服务器上的的设计抽象和/或实施。

在一些实施例中，代理服务器可以接收对由代理服务器内的REST web服务暴露的特定资源的web服务请求。代理服务器中的REST web服务内的适当资源可以被调取，并且可以继而调取后端web服务。在一些情况下，反向代理服务器可以暴露使各种后端web服务虚拟化和模糊的一组REST web服务。例如，反向代理服务器可以只暴露虚拟的统一资源定位符(URL)，使得不受信的网络上的客户端设备不能看到底层后端web服务或不具有关于底层后端web服务的知识。根据附加方面，REST服务和REST资源可以在反向代理服务器内生成，以处置从客户端设备接收到的REST请求中的一些或全部。这些REST服务/资源可以在反向代理服务器内动态生成并配置为处置REST请求和/或调取对应的多组后端web服务。为了动态地生成和管理REST web服务/资源，可以在反向代理服务器内实现REST基础设施和/或REST应用引擎。此外，在某些实施例中，反向代理服务器内的REST资源可以生成后端web服务调用并将其提供给用于实施各种策略的策略实施引擎。

图1是示出示例性分布式系统的组件的框图，在该示例性分布式系统中可以实现本发明的各种实施例。在所示的实施例中，分布式系统100包括一个或多个客户端计算设备102、104、106和108，这些客户端计算设备被配置为通过一个或多个网络110执行和操作诸如web浏览器、专有客户端(例如Oracle Forms)等之类的客户端应用。服务器112可以经由网络110与远程客户端计算设备102、104、106和108通信上耦合。

在各种实施例中，服务器112可以适于运行由系统的组件中的一个或多个组件提供的一个或多个服务或软件应用。在一些实施例中，这些服务可以作为基于web的服务或云服务或者在软件即服务(Software as a Service，SaaS)模型下提供给客户端计算设备102、104、106和/或108的用户。操作客户端计算设备102、104、106和/或108的用户继而可以利用一个或多个客户端应用与服务器112交互以利用由这些组件提供的服务。

在图中所绘出的配置中，系统100的软件组件118、120和122被示为在服务器112上实现。在其它实施例中，系统100的组件中的一个或多个组件和/或由这些组件提供的服务也可以由客户端计算设备102、104、106和/或108中的一个或多个来实现。操作客户端计算设备的用户然后可以利用一个或多个客户端应用来使用由这些组件提供的服务。这些组件可以实现在硬件、固件、软件或其组合中。应当理解，各种不同的系统配置是可能的，这些配置可以与分布式系统100不同。因此，图中示出的实施例是用于实现实施例系统的分布式系统的一个例子，并不旨在进行限制。

客户端计算设备102、104、106和/或108可以是便携式手持设备(例如，

蜂窝电话、

计算平板电脑、个人数字助理(PDA))或可穿戴设备(例如，Google

头戴式显示器)，这些设备运行诸如Microsoft Windows

的软件和/或诸如iOS、Windows Phone、Android、BlackBerry 10、Palm OS等各种移动操作系统，并且启用了互联网、电子邮件、短消息服务(SMS)、

或其它通信协议。客户端计算设备可以是通用个人计算机，例如包括运行各种版本的Microsoft

Apple

和/或Linux操作系统的个人计算机和/或膝上型计算机。客户端计算设备可以是运行任何各种可商用

或类UNIX操作系统的工作站计算机，这些操作系统包括但不限于诸如例如Google Chrome OS的各种GNU/Linux操作系统。可替代地或附加地，客户端计算设备102、104、106和108可以是能够通过(一个或多个)网络110通信的任何其它电子设备，诸如瘦客户端计算机(thin client computer)、启用了互联网的游戏系统(例如，具有或不具有

手势输入设备的Microsoft Xbox游戏控制台)和/或个人消息传送设备。

虽然示例性分布式系统100被示为具有四个客户端计算设备，但是任何数量的客户端计算设备都可以被支持。其它设备(诸如具有传感器的设备等)可以与服务器112交互。

分布式系统100中的(一个或多个)网络110可以是本领域技术人员熟悉的可以支持使用各种可商用协议中的任何可商用协议的数据通信的任何类型的网络，这些协议包括但不限于TCP/IP(传输控制协议/互联网协议)、SNA(系统网络体系结构)、IPX(互联网数据包交换)、AppleTalk等。仅仅作为例子，(一个或多个)网络110可以是局域网(LAN)，诸如基于以太网、令牌环网(token ring)等的局域网。(一个或多个)网络110可以是广域网和互联网。它可以包括虚拟网络，包括但不限于虚拟专用网(VPN)、内联网、外联网、公共交换电话网(PSTN)、红外网络、无线网络(例如，在电气和电子协会(IEEE)802.11协议族中的任何协议、蓝牙和/或任何其它无线协议下操作的网络)和/或这些网络和/或其它网络的任意组合。

服务器112可以由一个或多个通用计算机、专用服务器计算机(作为例子，包括PC(个人计算机)服务器、

服务器、中型服务器、大型计算机、机架式服务器等)、服务器群组、服务器集群或者任何其它适当的布置和/或组合组成。在各种实施例中，服务器112可以适于运行上述公开中描述的一个或多个服务或软件应用。例如，服务器112可以对应于用于执行上述根据本公开的实施例的处理的服务器。

服务器112可以运行操作系统，该操作系统包括任何以上讨论的操作系统以及任何可商用的服务器操作系统。服务器112也可以运行各种附加的服务器应用和/或中间层应用中的任何服务器应用和/或中间层应用，包括HTTP(超文本传送协议)服务器、FTP(文件传送协议)服务器、CGI(公共网关接口)服务器、

服务器、数据库服务器等。示例性数据库服务器包括但不限于来自Oracle、Microsoft、Sybase、IBM(国际商业机器公司)等的那些可商用的数据库服务器。

在一些实现中，服务器112可以包括分析和整合从客户端计算设备102、104、106和108的用户接收的数据馈送和/或事件更新的一个或多个应用。作为例子，数据馈送和/或事件更新可以包括但不限于

馈送、

更新或者从一个或多个第三方信息源和连续数据流接收到的实时更新，实时更新可以包括与传感器数据应用、金融报价机、网络性能测量工具(例如，网络监视和流量管理应用)、点击流分析工具、汽车流量监视等相关的实时事件。服务器112也可以包括经由客户端计算设备102、104、106和108的一个或多个显示设备显示数据馈送和/或实时事件的一个或多个应用。

分布式系统100也可以包括一个或多个数据库114和数据库116。数据库114和数据库116可以驻留在各种位置中。作为例子，数据库114和数据库116中的一个或多个可以驻留在服务器112本地(和/或驻留在服务器112中)的非临时性存储介质上。可替代地，数据库114和数据库116可以远离服务器112，并且经由基于网络的连接或专用的连接与服务器112通信。在一组实施例中，数据库114和数据库116可以驻留在存储区域网络(SAN)中。类似地，用于执行属于服务器112的功能的任何必要的文件可以根据需要本地地存储在服务器112上和/或远程地存储。在一组实施例中，数据库114和数据库116可以包括适于响应于SQL格式的命令来存储、更新和检索数据的关系数据库，诸如由

提供的数据库。

图2是示出系统环境的组件的框图，由本发明的实施例提供的服务可以通过该系统环境被提供作为云服务。在所示的实施例中，系统环境200包括可由用户用来与提供云服务的云基础设施系统202交互的一个或多个客户端计算设备204、206和208。客户端计算设备可以被配置为操作客户端应用(诸如web浏览器、专有客户端应用(例如，

Forms)或一些其它应用)，其中该客户端应用可以被客户端计算设备的用户用来与云基础设施系统202交互以使用由云基础设施系统202提供的服务。

应当理解，在图中绘出的云基础设施系统202可以具有除了所绘出的那些之外的其它组件。此外，在该图中示出的实施例只是可以结合本发明实施例的云基础设施系统的一个例子。在一些其它实施例中，云基础设施系统202可以具有比在该图中示出的组件更多或更少的组件、可以合并两个或更多个组件、或者可以具有不同的组件配置或布置。

客户端计算设备204、206和208可以是类似于上面针对102、104、106和108所描述的那些设备的设备。

虽然示例性系统环境200被示为具有三个客户端计算设备，但是任何数量的客户端计算设备都可以被支持。其它设备(诸如具有传感器的设备等)可以与云基础设施系统202交互。

(一个或多个)网络210可以便于客户端204、206和208与云基础设施系统202之间的数据交换和通信。每个网络可以是本领域技术人员熟悉的可以支持使用各种可商用协议中的任何可商用协议的数据通信的任何类型的网络，这些协议包括上面针对(一个或多个)网络110所描述的那些协议。

云基础设施系统202可以包括一个或多个计算机和/或服务器，该计算机和/或服务器可以包括上面针对服务器112所描述的那些。

在某些实施例中，由云基础设施系统提供的服务可以包括可以让云基础设施系统的用户按需使用的许多服务，诸如在线数据存储和备份解决方案、基于web的电子邮件服务、托管的办公套件和文档协作服务、数据库处理、受管理的技术支持服务等。由云基础设施系统提供的服务可以动态地扩展以满足其用户的需求。由云基础设施系统提供的服务的具体实例化在本文中被称为“服务实例”。一般而言，来自云服务提供商的系统的、经由诸如互联网的通信网络对用户可用的任何服务被称为“云服务”。典型地，在公共云环境中，构成云服务提供商的系统的服务器和系统与客户自己的内部(on-premises)的服务器和系统不同。例如，云服务提供商的系统可以托管应用，并且用户可以经由诸如互联网的通信网络按需订购和使用该应用。

在一些例子中，在计算机网络云基础设施中的服务可以包括对由云供应商提供给用户或者以在本领域中已知的其它方式提供的存储空间、托管的数据库、托管的web服务器、软件应用或其它服务的受保护的计算机网络访问。例如，服务可以包括通过互联网对云上远程存储空间的受密码保护的访问。作为另一个例子，服务可以包括用于被联网的开发人员私人使用的基于web服务的托管的关系数据库和脚本语言中间件引擎。作为另一个例子，服务可以包括对托管在云供应商的web站点上的电子邮件软件应用的访问。

在某些实施例中，云基础设施系统202可以包括以自助服务、基于订阅、弹性可扩展、可靠、高可用性并且安全的方式交付给客户的一套应用、中间件和数据库服务供应物。这种云基础设施系统的例子是由本受让人提供的

公共云。

在某些实施例中，云基础设施系统202可以适于自动供应、管理和跟踪客户对由云基础设施系统202提供的服务的订阅。云基础设施系统202可以经由不同的部署模型来提供云服务。例如，服务可以在公共云模型下提供，在公共云模型中，云基础设施系统202由销售云服务的组织拥有(例如，被Oracle拥有)并且使得服务对一般公众和不同行业的企业可用。作为另一个例子，服务可以在私有云模型下提供，在私有云模型中，云基础设施系统202只为单个组织而操作并且可以为该组织内的一个或多个实体提供服务。云服务也可以在社区云模型下提供，在社区云模型中，云基础设施系统202和由云基础设施系统202提供的服务由相关社区中的若干个组织共享。云服务也可以在混合云模型下提供，混合云模型是两种或更多种不同模型的组合。

在一些实施例中，由云基础设施系统202提供的服务可以包括在软件即服务(SaaS)类别、平台即服务(PaaS)类别、基础设施即服务(IaaS)类别、或包括混合服务的其它服务类别下提供的一个或多个服务。客户可以经由订阅订单订购由云基础设施系统202提供的一个或多个服务。云基础设施系统202然后执行处理，以提供客户的订阅订单中的服务。

在一些实施例中，由云基础设施系统202提供的服务可以包括但不限于应用服务、平台服务和基础设施服务。在一些实例中，应用服务可以由云基础设施系统经由SaaS平台提供。SaaS平台可以被配置为提供SaaS类别下的云服务。例如，SaaS平台可以提供在集成的开发和部署平台上构建和交付一套按需应用(on-demand application)的能力。SaaS平台可以管理和控制用于提供SaaS服务的底层软件和基础设施。通过利用由SaaS平台提供的服务，客户可以利用在云基础设施系统上执行的应用。客户可以获取应用服务，而无需客户购买单独的许可证和支持。可以提供各种不同的SaaS服务。例子包括但不限于为大型组织提供用于销售绩效管理、企业集成和业务灵活性的解决方案的服务。

在一些实施例中，平台服务可以由云基础设施系统经由PaaS平台提供。PaaS平台可以被配置为提供PaaS类别下的云服务。平台服务的例子可以包括但不限于使组织(诸如

)能够在共享的公共体系架构上整合现有应用、以及能够构建利用由平台提供的共享服务的新应用的服务。PaaS平台可以管理和控制用于提供PaaS服务的底层软件和基础设施。客户可以获得由云基础设施系统提供的PaaS服务，而无需客户购买单独的许可证和支持。平台服务的例子包括但不限于Oracle Java云服务(JCS)、Oracle数据库云服务(DBCS)以及其它服务。

通过利用由PaaS平台提供的服务，客户可以采用云基础设施系统所支持的编程语言和工具，并且还控制所部署的服务。在一些实施例中，由云基础设施系统提供的平台服务可以包括数据库云服务、中间件云服务(例如，Oracle Fusion Middleware服务)和Java云服务。在一个实施例中，数据库云服务可以支持共享服务部署模型，该共享服务部署模型使得组织能够汇集(pool)数据库资源并且以数据库云的形式向客户提供数据库即服务。在云基础设施系统中，中间件云服务可以为客户提供开发和部署各种业务应用的平台，并且Java云服务可以为客户提供部署Java应用的平台。

在云基础设施系统中，可以由IaaS平台提供各种不同的基础设施服务。基础设施服务便于管理和控制底层计算资源(诸如存储装置、网络和其它基本计算资源)，以便客户利用由SaaS平台和PaaS平台提供的服务。

在某些实施例中，云基础设施系统202还可以包括基础设施资源230，用于提供用来向云基础设施系统的客户提供各种服务的资源。在一个实施例中，基础设施资源230可以包括执行由PaaS平台和SaaS平台提供的服务的硬件(诸如服务器、存储装置和联网资源)的预先集成的和经优化的组合。

在一些实施例中，云基础设施系统202中的资源可以由多个用户共享并且按需动态地重新分配。附加地，资源可以分配给在不同时区中的用户。例如，云基础设施系统230可以使第一时区内的第一组用户能够针对指定的小时数利用云基础设施系统的资源，然后使得能够将相同资源重新分配给位于不同时区中的另一组用户，从而最大化资源的利用。

在某些实施例中，可以提供由云基础设施系统202的不同组件或模块以及由云基础设施系统202提供的服务共享的若干内部共享服务232。这些内部共享服务可以包括但不限于安全性和身份服务、集成服务、企业储存库服务、企业管理器服务、病毒扫描和白名单服务、高可用性的备份和恢复服务、用于实现云支持的服务、电子邮件服务、通知服务、文件传送服务等。

在某些实施例中，云基础设施系统202可以提供对云基础设施系统中的云服务(例如，SaaS、PaaS和IaaS服务)的综合管理。在一个实施例中，云管理功能可以包括用于供应、管理和跟踪由云基础设施系统202接收到的客户的订阅的能力等。

在一个实施例中，如在图中所绘出的，云管理功能可以由诸如订单管理模块220、订单编制模块222、订单供应模块224、订单管理和监视模块226以及身份管理模块228的一个或多个模块提供。这些模块可以包括一个或多个计算机和/或服务器，或者使用一个或多个计算机和/或服务器来提供，该一个或多个计算机和/或服务器可以是通用计算机、专用服务器计算机、服务器群组、服务器集群或任何其它适当的布置和/或组合。

在示例性操作234中，使用客户端设备(诸如客户端设备204、206或208)的客户可以通过请求由云基础设施系统202提供的一个或多个服务以及对由云基础设施系统202提供的一个或多个服务的订阅下订单来与云基础设施系统202交互。在某些实施例中，客户可以访问云用户接口(UI)(云UI 212、云UI 214和/或云UI 216)并经由这些UI下订阅订单。响应于客户下订单由云基础设施系统202接收到的订单信息可以包括识别客户以及客户打算订阅的由云基础设施系统202提供的一个或多个服务的信息。

在客户下订单之后，订单信息经由云UI 212、214和/或216接收。

在操作236处，订单被存储在订单数据库218中。订单数据库218可以是由云基础设施系统218操作以及结合其它系统元件操作的若干个数据库之一。

在操作238处，订单信息被转发到订单管理模块220。在一些情况下，订单管理模块220可以被配置为执行与订单相关的计费和记帐功能，诸如验证订单和在通过验证时接纳(book)订单。

在操作240处，关于订单的信息被传递到订单编排模块222。订单编排模块222可以利用订单信息为客户下的订单编排服务和资源的供应。在一些情况下，订单编排模块222可以编排资源的供应，以使用订单供应模块224的服务来支持所订阅的服务。

在某些实施例中，订单编排模块222实现对与每个订单相关联的业务过程的管理，并且应用业务逻辑来确定订单是否应当继续供应。在操作242处，当接收到新订阅的订单时，订单编排模块222向订单供应模块224发送分配资源和配置履行订阅订单所需的那些资源的请求。订单供应模块224实现为由客户订购的服务分配资源。订单供应模块224提供在由云基础设施系统200提供的云服务与用来供应用于提供所请求的服务的资源的物理实现层之间的抽象层级。订单编排模块222可以因此与实现细节(诸如服务和资源实际上是被即时(on the fly)供应，还是预先被供应并且仅在请求时才进行分配/指定)隔离。

在操作244处，一旦供应了服务和资源，就可以通过云基础设施系统202的订单供应模块224向客户端设备204、206和/或208上的客户发送所提供的服务的通知。

在操作246处，可以由订单管理和监视模块226来管理和跟踪客户的订阅订单。在一些情况下，订单管理和监视模块226可以被配置为收集订阅订单中的服务的使用统计数据，诸如所使用的存储量、所传送的数据量、用户的数量、以及系统运行时间和系统停机时间的量。

在某些实施例中，云基础设施系统200可以包括身份管理模块228。身份管理模块228可以被配置为提供身份服务，诸如云基础设施系统200中的访问管理和授权服务。在一些实施例中，身份管理模块228可以控制关于希望利用由云基础设施系统202提供的服务的客户的信息。这种信息可以包括认证这种客户的身份的信息和描述那些客户被授权相对于各种系统资源(例如，文件、目录、应用、通信端口、存储器段等)执行哪些动作的信息。身份管理模块228也可以包括对关于每个客户的描述性信息和关于该描述性信息可以如何访问和修改以及可以由谁访问和修改的管理。

图3是示出在其中可以实现本发明的实施例的示例性计算机系统的框图。系统300可以用来实现上述计算机系统中的任何计算机系统。如图所示，计算机系统300包括经由总线子系统302与若干外围子系统通信的处理单元304。这些外围子系统可以包括处理加速单元306、I/O子系统308、存储子系统318和通信子系统324。存储子系统318包括有形的计算机可读存储介质322和系统存储器310。

总线子系统302提供了用于让计算机系统300的各种组件和子系统按意图彼此通信的机制。虽然总线子系统302被示意性地示为单个总线，但是总线子系统的可替代实施例可以利用多个总线。总线子系统302可以是若干种类型的总线结构中的任何总线结构，包括利用各种总线体系架构中的任何总线体系架构的存储器总线或存储器控制器、外围总线、以及局部总线。例如，这样的体系架构可以包括工业标准体系架构(ISA)总线、微通道体系架构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线和外围组件互连(PCI)总线，其中PCI总线可以实现为按IEEE P1386.1标准制造的夹层(Mezzanine)总线。

可以实现为一个或多个集成电路(例如，常规的微处理器或微控制器)的处理单元304控制计算机系统300的操作。在处理单元304中可以包括一个或多个处理器。这些处理器可以包括单核处理器或多核处理器。在某些实施例中，处理单元304可以实现为一个或多个独立的处理单元332和/或334，其中在每个处理单元中包括单核或多核处理器。在其它实施例中，处理单元304也可以实现为通过将两个双核处理器集成到单个芯片中而形成的四核处理单元。

在各个实施例中，处理单元304可以响应于程序代码执行各种程序并且可以维护多个并发执行的程序或进程。在任何给定时间，要执行的程序代码中的一些或全部可以驻留在(一个或多个)处理器304中和/或存储子系统318中。通过适当的编程，(一个或多个)处理器304可以提供上述各种功能。计算机系统300可以附加地包括处理加速单元306，处理加速单元306可以包括数字信号处理器(DSP)、专用处理器等。

I/O子系统308可以包括用户接口输入设备和用户接口输出设备。用户接口输入设备可以包括键盘、诸如鼠标或轨迹球的指点设备、结合到显示器中的触摸板或触摸屏、滚轮、点拨轮、拨盘、按钮、开关、键板、具有语音命令识别系统的音频输入设备、麦克风以及其它类型的输入设备。用户接口输入设备可以包括例如运动感测和/或姿势识别设备，诸如Microsoft

运动传感器，Microsoft

运动传感器使得用户能够使用姿势和口语命令通过自然用户接口控制输入设备(诸如Microsoft

360游戏控制器)并与其交互。用户接口输入设备也可以包括眼睛姿势识别设备，诸如Google

眨眼检测器，Google

眨眼检测器检测用户的眼睛活动(例如，当拍摄图片和/或进行菜单选择时的“眨眼”)并将眼睛姿势变换为到输入设备(例如，Google

)中的输入。附加地，用户接口输入设备可以包括使用户能够通过语音命令与语音识别系统(例如，

导航器)交互的语音识别感测设备。

用户接口输入设备也可以包括但不限于三维(3D)鼠标、操纵杆或指点杆、游戏板和绘图平板、以及音频/视频设备，诸如扬声器、数码相机、数码摄像机、便携式媒体播放器、网络摄像机、图像扫描仪、指纹扫描仪、条形码读取器3D扫描仪、3D打印机、激光测距仪、以及眼睛注视跟踪设备。附加地，用户接口输入设备可以包括例如医疗成像输入设备，诸如计算机断层扫描、磁共振成像、正电子发射断层扫描、医疗超声设备。用户接口输入设备还可以包括例如音频输入设备，诸如MIDI键盘、数字乐器等。

用户接口输出设备可以包括显示子系统、指示器灯或诸如音频输出设备的非视觉显示器等。显示子系统可以是阴极射线管(CRT)、诸如利用液晶显示器(LCD)或等离子显示器的平板设备、投影设备、触摸屏等。一般而言，术语“输出设备”的使用旨在包括用于从计算机系统300向用户或其它计算机输出信息的所有可能类型的设备和机制。例如，用户接口输出设备可以包括但不限于可视地传达文本、图形和音频/视频信息的各种显示设备，诸如监视器、打印机、扬声器、耳机、汽车导航系统、绘图仪、语音输出设备和调制解调器。

计算机系统300可以包括存储子系统318，存储子系统318包括被示为当前位于系统存储器310内的软件元件。系统存储器310可以存储可加载在处理单元304上并且可在处理单元304上执行的程序指令，以及可以存储在这些程序执行期间生成的数据。

取决于计算机系统300的配置和类型，系统存储器310可以是易失性的(诸如随机存取存储器(RAM))和/或非易失性的(诸如只读存储器(ROM)、闪存存储器，等等)。RAM典型地包含可被处理单元304立即访问和/或目前正被处理单元304操作和执行的数据和/或程序模块。在一些实现中，系统存储器310可以包括多种不同类型的存储器，诸如静态随机存取存储器(SRAM)或动态随机存取存储器(DRAM)。在一些实现中，基本输入/输出系统(BIOS)典型地可以存储在ROM中，基本输入/输出系统(BIOS)包含有助于诸如在启动期间在计算机系统300内的元件之间传送信息的基本例程。作为例子而不是限制，系统存储器310还示出了应用程序312、程序数据314以及操作系统316，应用程序312可以包括客户端应用、web浏览器、中间层应用、关系数据库管理系统(RDBMS)等。作为例子，操作系统316可以包括各种版本的Microsoft

Apple

和/或Linux操作系统、各种可商用的

或类UNIX操作系统(包括但不限于各种GNU/Linux操作系统、Google

操作系统等)和/或诸如iOS、

Phone、

OS、

10OS和

OS操作系统的移动操作系统。

存储子系统318也可以提供有形计算机可读存储介质，以存储提供一些实施例的功能的基本编程和数据构造。当被处理器执行时提供上述功能的软件(程序、代码模块、指令)可以存储在存储子系统318中。这些软件模块或指令可以被处理单元304执行。存储子系统318也可以提供用于存储根据本发明被使用的数据的储存库。

存储子系统300也可以包括计算机可读存储介质读取器320，计算机可读存储介质读取器320可以进一步连接到计算机可读存储介质322。计算机可读存储介质322可以与系统存储器310一起以及可选地与系统存储器310组合来全面地表示用于临时地和/或更持久地包含、存储、传输和检索计算机可读信息的远程、本地、固定和/或可移除存储设备加存储介质。

包含代码或代码的部分的计算机可读存储介质322也可以包括本领域已知的或使用的任何适当的介质，包括存储介质和通信介质，诸如但不限于以用于信息的存储和/或传输的任何方法或技术实现的易失性和非易失性、可移除和不可移除的介质。这可以包括非临时性和有形的计算机可读存储介质，诸如RAM、ROM、电可擦除可编程ROM(EEPROM)、闪存存储器或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光学存储装置、磁卡带、磁带、磁盘存储装置或其它磁存储设备、或其它有形的计算机可读介质。这也可以包括非有形的计算机可读介质，诸如数据信号、数据传输，或者可以用来传输期望的信息并且可以被计算机系统300访问的任何其它介质。

作为例子，计算机可读存储介质322可以包括从不可移除的非易失性磁介质读取或写到不可移除的非易失性磁介质的硬盘驱动器、从可移除的非易失性磁盘读取或写到可移除的非易失性磁盘的磁盘驱动器、以及从可移除的非易失性光盘(诸如CD ROM、DVD和

盘或其它光学介质)读取或写到可移除的非易失性光盘的光盘驱动器。计算机可读存储介质322可以包括但不限于

驱动器、闪存卡、通用串行总线(USB)闪存驱动器、安全数字(SD)卡、DVD盘、数字音频带等。计算机可读存储介质322也可以包括基于非易失性存储器的固态驱动器(SSD)(诸如基于闪存存储器的SSD、企业闪存驱动器、固态ROM等)、基于易失性存储器的SSD(诸如固态RAM、动态RAM、静态RAM、基于DRAM的SSD、磁阻RAM(MRAM)SSD))以及使用DRAM和基于闪存存储器的SSD的组合的混合SSD。盘驱动器及其相关联的计算机可读介质可以为计算机系统300提供计算机可读指令、数据结构、程序模块及其它数据的非易失性存储装置。

通信子系统324提供到其它计算机系统和网络的接口。通信子系统324用作用于从其它系统接收数据和从计算机系统300向其它系统传输数据的接口。例如，通信子系统324可以使计算机系统300能够经由互联网连接到一个或多个设备。在一些实施例中，通信子系统324可以包括用于访问无线语音和/或数据网络的射频(RF)收发器组件(例如，利用蜂窝电话技术、诸如3G、4G或EDGE(用于全球演进的增强型数据速率)的先进数据网络技术、Wi-Fi(IEEE802.11标准族)、或其它移动通信技术、或其任意组合)、全球定位系统(GPS)接收器组件和/或其它组件。在一些实施例中，作为无线接口的附加或替代，通信子系统324可以提供有线网络连接(例如，以太网)。

在一些实施例中，通信子系统324也可以代表可以使用计算机系统300的一个或多个用户来接收结构化和/或非结构化的数据馈送326、事件流328、事件更新330等形式的输入通信。

作为例子，通信子系统324可以被配置为实时地接收来自社交网络和/或其它通信服务的用户的数据馈送326，诸如

馈送、

更新、web馈送(诸如丰富站点摘要(Rich Site Summary,RSS)馈送)和/或来自一个或多个第三方信息源的实时更新。

附加地，通信子系统324也可以被配置为接收连续数据流形式的数据，连续数据流可以包括实时事件的事件流328和/或事件更新330，连续数据流形式的数据本质上可能是连续或无界的而没有明确结束。生成连续数据的应用的例子可以包括例如传感器数据应用、金融报价机、网络性能测量工具(例如网络监视和流量管理应用)、点击流分析工具、汽车流量监视等。

通信子系统324也可以被配置为向一个或多个数据库输出结构化和/或非结构化的数据馈送326、事件流328、事件更新330等，其中这一个或多个数据库可以与耦合到计算机系统300的一个或多个流数据源计算机通信。

计算机系统300可以是各种类型中的一种，包括手持便携式设备(例如，

蜂窝电话、

计算平板、PDA)、可穿戴设备(例如，Google

头戴式显示器)、PC、工作站、大型机、信息站、服务器机架或任何其它数据处理系统。

由于计算机和网络不断变化的本质，在图中绘出的计算机系统300的描述旨在仅仅作为具体例子。具有比图中所绘出的系统更多或更少组件的许多其它配置是可能的。例如，也可以使用定制的硬件,和/或特定的元件可以实现在硬件、固件、软件(包括applets)或组合中。另外，可以采用到其它计算设备(诸如网络输入/输出设备)的连接。基于本文所提供的公开和教导，本领域普通技术人员将理解实现各种实施例的其它方式和/或方法。

如上面介绍的，本发明的实施例提供了用于处理在计算机网络之间传输的消息的技术。更具体而言，诸如在物理子网络或逻辑子网络内实现的代理服务器之类的中介网络设备或应用可以在通信端点之间接收、处理和传输消息。在一些实施例中，反向代理服务器可以被配置为在反向代理服务器内动态地生成表述性状态传递(REST)服务和REST资源。反向代理服务器内的REST服务和REST资源可以处置来自客户端设备的传入请求并调取后端web服务，从而允许各种安全性策略在反向代理服务器上的设计抽象和/或实施。

在各种实施例中，代理服务器可以接收对由代理服务器内的REST web服务暴露的特定资源的web服务请求。代理服务器中的REST web服务内的适当资源可以被调取，并且可以继而调取后端web服务。在一些情况下，反向代理服务器可以暴露使各种后端web服务虚拟化和模糊的一组REST web服务。例如，反向代理服务器可以只暴露虚拟的统一资源定位符(URL)，使得不受信的网络上的客户端设备不能看到底层后端web服务或不具有关于底层后端web服务的知识。根据附加方面，REST服务和REST资源可以在反向代理服务器内生成，以处置从客户端设备接收到的REST请求中的一些或全部。这些REST服务/资源可以在反向代理服务器内动态生成并配置为处置REST请求和/或调取对应的多组后端web服务。为了动态地生成和管理REST web服务/资源，可以在反向代理服务器内实现REST基础设施和/或REST应用引擎。附加地，在某些实施例中，反向代理服务器内的REST资源可以生成后端web服务调用并将其提供给用于实施各种策略的策略实施引擎。

图4A和图4B是示出包括反向代理服务器420的计算环境400a和计算环境400b的组件的框图，其中反向代理服务器420用于在各种计算机网络中的计算设备和/或系统之间处理和传输消息。在这个例子中示出的计算环境400a和计算环境400b(统称为400)可以对应于被设计为向各种客户端设备410提供对后端计算资源(诸如web应用和web服务430)的访问的高层级计算机体系架构。在各种实施例中，计算环境400可以从小而简单的计算系统到大且高度复杂的系统，其中大且高度复杂的系统包括被设计为与其它此类系统集成以支持各种组织的计算需求的硬件、软件和网络组件。计算环境400可以实现为多层计算机体系架构，该多层计算机体系架构可以包括基于web的实现和/或基于云的实现，并且在该多层计算机体系架构中，各种端点设备(例如，用户设备410、web服务提供者430等)经由一个或多个中间层系统进行交互。附加地，计算环境400中示出的每个组件可以实现为包括硬件、软件和/或网络组件的各种组合的单独的计算机系统。在其它情况下，在计算环境400中示出的多个组件可以实现为在组合的计算机系统内操作的逻辑子组件(例如，体现在计算机可读介质上的软件应用等)。

如图4A和4B所示，这样的计算环境400可以对应于客户端-服务器系统，在该客户端-服务器系统中，客户端设备410可以经由(一个或多个)计算机网络415、一个或多个防火墙435、反向代理服务器420和/或其它中介网络设备向一个或多个后端web服务430传输请求。web服务430可以包括由各种系统430暴露的任何应用编程接口(API)、服务、应用和任何其它信息资产，包括但不限于简单对象访问协议(SOAP)web服务或API、表述性状态传递(REST)web服务或API、和/或经由超文本传送协议(HTTP)或HTTP安全协议暴露的web内容。在这种情况下，反向代理服务器420可以在客户端设备410和后端web服务430之间提供安全性层。例如，代理服务器420可以为后端web服务430提供中央接入点以及与后端web服务430相关联的各种安全性和管理策略的服务虚拟化和实施。反向代理服务器420也可以在使后端web服务430虚拟化和模糊的同时暴露这些服务430。例如，反向代理服务器420可以只暴露虚拟的统一资源定位符(例如，URL)，使得不受信的网络上的客户端设备410不能看到底层后端web服务430或不具有关于底层后端web服务430的知识。

附加地或可替代地，计算环境400可以被配置为用于在相反方向上处理和传输请求-响应的客户端-服务器系统。例如，在一些实施例中，在内部计算机网络460内操作的一个或多个客户端设备(未示出)可以向在代理服务器420和(一个或多个)防火墙435a外的各种外部计算机系统和网络480上操作的web服务或应用(未示出)发送请求。因此，虽然服务器420在本文被称为反向代理服务器420，但是应当理解，它也可以充当前向代理服务器，并且可以在内部客户端设备440和外部后端web服务或应用之间提供安全性层。当执行反向代理的功能(即，反向代理模式)或前向代理的功能(即，前向代理模式)时，反向代理服务器420可以处置对SOAP web服务、REST web服务、HTTP/HTTPS web内容等的网络请求和来自它们的响应。当代理服务器420作为前向代理服务器操作时，内部客户端设备可能已经了解外部后端web服务/应用，并且那些后端服务/应用可以接收来自在客户端侧配置的代理服务器420的直接传输。在这种情况下，代理服务器420可以使用任何安全性策略或通信管理策略为前向代理统一资源标识符(URI)端点提供安全性。在前向代理模式或反向代理模式中，代理服务器420可以支持各种安全性和认证特征，诸如基于Kerberos Kinit的认证，基于Kerberos Pkinit的认证，基于授权协议版本2.0(OAuth2)的开放标准的认证，基于TLP的认证，使用简单和受保护的GSSAPI协商机制(SPNEGO)令牌、WINDOWS NT LAN管理器(NTLM)令牌、安全性断言标记语言(SAML)令牌等等创建后端服务的会话令牌和/或基于挑战的认证。

客户端设备410可以包括台式计算机或膝上型计算机、移动设备和其它各种计算设备/系统，包括以上在图1-图3中的说明性计算系统中讨论的硬件、软件和网络组件中的一些或全部。在一些实施例中，客户端设备410可以包括配置为请求和接收来自后端web服务430的数据的一个或多个客户端软件应用(例如，web浏览器)。客户端设备410也可以包括建立网络接口、安全性和认证能力以及内容高速缓存能力以接收实况内容并将其实时(或近实时)地提供给用户所需的硬件和软件组件。

通信网络415可以包括本文所描述的计算机网络和其它通信网络的任意组合。例如，网络415可以包括诸如局域网(LAN)、广域网(WAN)(例如，互联网)的TCP/IP(传输控制协议/互联网协议)网络以及各种无线电信网络。附加地，应当理解，通信网络415可以表示将客户端设备410与后端web服务430分离的许多不同物理网络和逻辑网络的组合。除了一个或多个防火墙435之外，诸如web服务器、认证服务器的各种服务器和/或诸如防火墙、路由器、网关、负载平衡器等的专用联网组件也可以便于客户端设备410与后端web服务430之间的通信。

在一些实施例中，反向代理服务器420可以实现为隔离的计算机系统(例如，代理计算机服务器)，或者实现为包括在如图4B所示的隔离的DMZ 470内的专用硬件、软件和网络组件的多个计算系统的组合。附加地或可替代地，反向代理服务器420可以是在网络设备(例如，网络服务器或防火墙435b)或受信的网络460内的计算机服务器内执行的代理服务器软件应用。因此，反向代理服务器420可以驻留在内部计算机网络460的物理子网络或逻辑子网络465中，如图4A所示。在任一情况下，反向代理服务器420可以充当受信的内部网络460上的客户端/服务器与不受信的外部网络480上的客户端/服务器之间的中介。附加地，反向代理服务器420内的组件421-423中的每一个(以及参考图5、图7和图9讨论的其它代理服务器组件)可以实现为配置为与反向代理服务器420通信的单独的计算系统，或者可以操作为在与反向代理服务器420相同的计算机服务器内集成的逻辑子组件。在任一情况下，每个组件421-423(以及参考图5、图7和图9讨论的其它代理服务器组件)可以使用专用硬件、软件、网络和存储器子系统来实现，以执行本文所描述的技术。

在这个例子中，反向代理服务器420包括配置为经由通信网络415和/或防火墙435a接收来自客户端设备410的消息的消息处置器421。在一些实施例中，消息处置器421可以是用于从任何外部网络到后端web服务430的所有TCP、UDP、HTTP和HTTPS流量的入口点。消息处置器421还可以被配置为接收来自后端web服务430的响应，并且将该响应传输到客户端设备410。在一些例子中，消息处置器421可以包括一个或多个专用硬件、软件和网络组件，诸如负载平衡器、高速缓存和/或消息节流器。

在接收和解析消息之后，消息处置器421可以将消息(例如，经由Java本地接口(JNI)或.NET编程框架等)传输到适当的web服务框架。例如，在反向代理服务器420处接收到的SOAP请求可以被传输到SOAP web服务框架(未示出)，而REST请求可以被传输到RESTweb服务框架(例如，REST基础设施422)。web内容请求可以由消息处置器421类似地处置，例如通过解析请求并将请求传输到各种组件(诸如URL虚拟化组件或服务)。在一些情况下，消息处置器421还可以被配置为执行协议变换，诸如SOAP到REST和REST到SOAP的消息变换，以及JavaScript对象符号(JSON)到XML或JSON到SOAP的变换，反之亦然。

代理服务器420还可以包括表述性状态传递(REST)基础设施422和一个或多个REST web服务(或REST API)423。如图4所示，REST基础设施422可以从请求处置器421接收对REST web服务的请求。如下面更详细描述的，REST基础设施422可以在将REST请求转发到适当的REST服务423以处置该请求之前分析和处理REST请求。每个REST服务423可以包括配置为处置请求并基于该请求调取对应的后端web服务430的REST资源。附加地，在一些实施例中，REST基础设施422可以动态地生成REST服务423和各个REST资源来处置请求。

REST基础设施422可以包括用于开发和执行REST web服务(也称为RESTful web服务、RESTful API等)的web服务框架。在一些实施例中，REST基础设施422可以是JAX-RS(用于RESTful web服务的Java API)规范的实现，诸如JAX-RS的JERSEY参考实现(referenceimplementation)。虽然下面的许多例子是根据JAX-RS和JERSEY web服务/API基础设施进行讨论的，但是在其它例子中可以使用其它框架和技术。例如，作为JERSEY和JAX-RS的替换或附加，可以使用其它REST web框架/API服务器，诸如SCALA、BOWLING FINCH/FINAGLE框架。

在各种实施例中，REST基础设施422可以(例如，在JERSEY JAVA servlet容器内)包括实现REST web服务的库，并且还可以提供配置为扫描预定义类以识别REST资源的应用(例如，JERSEY JAVA servlet)。REST基础设施422还可以提供与REST web服务423和/或430通信的客户端库。当接收来自客户端设备的请求时，REST基础设施内的应用(例如，JERSEYJAVA servlet)可以分析传入的HTTP请求并选择正确的资源和方法来对该请求做出响应。与某些类型的web服务不同，REST web服务不必以XML或任何其它特定数据格式进行通信。因此，REST基础设施422可以支持以XML、JavaScript对象符号(JSON)、逗号分隔的值(CSV)或各种其它数据格式创建数据。

如图4A和图4B所示，反向代理服务器420可以在两个或更多个计算机网络之间(例如，在提供web服务430的受信的内部网络460与各种不受信的客户端设备410可以通过其访问内部web服务430的不受信的外部网络480(例如，互联网)之间)的中介网络设备内实现。如图4A所示，反向代理服务器420可以在内部计算机网络460的子网络465内操作，以便为内部计算机网络460提供安全性和通信管理的初始层。例如，安全的内部网络460可以包括多个web服务和应用430以及各种其它服务器和/或客户端设备。反向代理服务器420和/或附加网络或计算设备可以是同一内部网络460的一部分，但是也可以在内部计算机网络的通过一个或多个网关、防火墙435b等与内部计算机网络分离的物理子网络465内操作。在一些例子中，反向代理服务器420可以实现为在内部计算机网络460的逻辑子网络465(但不是物理子网络)内执行的代理服务器应用。因此，反向代理服务器420可以驻留在与后端web服务430中的一个或多个相同的计算系统上或内部计算机网络460内的其它计算机系统上。

附加地，在一些实施例中，反向代理服务器420可以在受信的内部网络460和不受信的外部网络480之间的非军事化区(demilitarized zone，DMZ)网络470内操作。如图4B所示，DMZ网络470可以实现为具有专用硬件、软件和网络组件并且与内部网络460和外部网络480两者隔离的完全分离的计算系统。可替代地，如图4A所示，DMZ可以实现为受信的内部网络460的物理子网络或逻辑子网络465，由此DMZ提供与在客户端设备410和/或后端web服务处提供的端点安全性分离的第一层安全性和通信管理。在任一情况下，DMZ网络可以在两个防火墙435a和435b之间实现，或者可以使用单个防火墙或使用将DMZ网络470或子网络465与受信的内部网络460和不受信的外部网络415两者物理地或逻辑地分离的其它各种配置的网络设备实现。DMZ网络内的所有计算机服务器和其它设备(诸如反向代理服务器420)可以具有到内部网络460内的设备的具体子集(例如，托管web服务430的特定服务器)的有限连接性。这种连接性可以基于具体的主机、端口、协议等进行限制。类似地，当与任何外部不受信的网络(例如，网络415和客户端设备410)通信时，可以在DMZ内的设备上实施有限连接性的策略。除了在DMZ内操作反向代理服务器420之外，在某些实施例中，后端web服务430中的一个或多个也可以在DMZ内操作。例如，更脆弱或更易于受到来自外部系统(例如，web服务器、电子邮件服务器、域名系统(DNS)服务器等)的攻击的某些计算机服务器/服务可以移动到具有代理服务器420的DMZ中。

图5是示出根据一个或多个实施例的反向代理服务器的某些元件和系统的框图。在这个例子中的反向代理服务器520可以对应于反向代理420，并且反向代理服务器520的各个子组件521-523可以与以上讨论的对应的子组件421-423类似或相同。附加地，反向代理服务器520可以在计算环境400或其它类似的环境内操作，并且可以被配置为在客户端计算设备和后端web服务之间处理和传输消息。因此，反向代理服务器520可以包括以上参考图4A和图4B讨论的硬件、软件和网络组件及功能中的一些或全部。

REST基础设施522可以包括具有用于开发、部署、执行和访问REST服务和资源的各种组件(例如，应用和库)的一个或多个REST web服务框架。在各种实施例中，REST基础设施522可以包括JAX-RS规范的JERSEY实现和/或其它REST web服务框架实现。REST基础设施522可以提供实现REST web服务的一个或多个库、扫描预定义类以识别REST资源的应用、以及与REST web服务通信的客户端库等。

如上所述，请求处置器521可以将REST请求转发给REST基础设施522，REST基础设施522可以在将请求转发到反向代理服务器520内的一个或多个REST服务之前分析和处理这些请求。在这个例子中，REST基础设施522包括REST堆栈524、静态REST应用525(例如，在构建时(build-time)生成的JERSEY应用)以及REST提供者资源526。如下面更详细讨论的，反向代理服务器520可以动态地(即，在运行时期间)初始化REST堆栈524和注册静态REST应用525。静态REST应用525可以返回REST提供者资源526，REST提供者资源526可以负责识别适当的REST服务523的根资源以处置该请求。

如图5所示，REST提供者资源526可以将请求转发到反向代理服务器520内的任何REST服务523。在这个例子中，请求已经被转发到REST服务523b，并被该REST服务中的根资源527接收。如这个例子所示，REST服务523可以被设计和实现为资源层级结构，其中根资源527是服务523内的最高层级资源(例如，映射服务的“/”路径)并且负责识别将处置不同请求的子资源528(或孩子资源)。如下面更详细讨论的，根资源527和/或所有孩子资源528都可以被创建为动态的REST资源(例如，在运行时期间创建的资源)。附加地，虽然在这个例子中示出了简单的两层层级结构，但是在其它例子中可以实现许多不同层(例如，三层、四层、五层等)的复杂层级结构。

现在参考图6A-图6B(统称为“图6”)，其中示出了流程图，该流程图示出了用于经由反向代理服务器接收和处理REST web服务请求的过程。如下所述，该过程中的步骤可以由计算环境400中的一个或多个组件(诸如反向代理服务器420(和/或反向代理服务器520、720和920))以及其中实现的各种子系统和子组件执行。附加地，在一些实施例中，该过程中的某些步骤可以在客户端设备410、后端web服务430内执行和/或由其它各种中介设备执行。还应当理解，本文所描述的技术(包括接收和分析消息、选择消息处理策略和处理消息)不必限定于上述的具体系统和硬件实现，而是可以在包括硬件、软件和网络组件的其它组合的其它硬件和系统环境内执行。

在步骤601中，web服务请求可以由诸如反向代理服务器420的中介计算系统或应用接收。如上面所提到的，反向代理服务器420可以实现为在受信的内部网络460和一个或多个不受信的外部网络之间的中介服务器设备和/或应用。因此，反向代理服务器420可以拦截(intercept)由客户端端点(例如，客户端设备410)传输并且预期用于服务器端点设备(例如，托管后端web服务和/或应用430的计算机服务器)的消息，反之亦然。

在一些实施例中，进入或离开内部网络460的所有网络流量可以路由通过反向代理服务器420。在其它情况下，反向代理服务器420可以被配置为拦截具体类型或协议的网络消息，例如，来自客户端设备410的对SOAP、REST或URL资源的HTTP请求，以及来自SOAP、REST或URL web服务/应用430的返回到客户端设备的HTTP响应。因此，在步骤601中接收到的web服务请求可以是例如但不限于TCP消息、HTTP或HTTPS消息、简单邮件传输协议(SMTP)、用户数据报协议(UDP)消息和/或Java消息服务(JMS)消息。在一些情况下，web服务请求可以对应于从客户端设备410到后端web服务430的SOAP、REST或web内容请求，或者对应于后端web服务430对来自客户端设备410的SOAP、REST或web内容请求的响应。

在步骤602中，反向代理服务器420可以分析在步骤601中接收到的请求，以确定该请求是否针对由反向代理服务器420内的REST服务423/523暴露的REST资源528。如本文所使用的，“暴露”诸如编程对象或数据对象的资源可以指提供接口，其中该接口提供对资源的访问。例如，web服务和API可以通过提供允许客户端应用访问和/或操纵对象的方法和操作来暴露资源。

如上面讨论的，在步骤601中接收到的REST web服务请求可以是预期用于(和/或可以被最终转发到)后端web服务430的。然而，在各种实施例中，可以在反向代理服务器420内生成REST服务和资源来处置从客户端设备410接收到的REST请求中的一些或全部。例如，如图4A和图4B所示，可以生成一组REST服务423来在反向代理服务器420中处置REST请求，并且潜在地可以调取对应的一组后端web服务430。因此，在反向代理服务器420内的一组REST服务423/523可以暴露由后端web服务430暴露的相同资源中的一些或全部。在一些情况下，反向代理服务器420内的这些REST服务423可以被称为“虚拟服务”。如下面更详细描述的，这些REST服务423可以精确地对应于后端web服务430或可以不精确地对应于后端web服务430。例如，单个REST服务423可以暴露调取多个不同后端服务430的REST资源528，或者相反地，多个不同的REST服务423可以调取相同的后端服务430。附加地，反向代理服务器420内的REST服务423可以包括对后端web服务430不支持的新的或不同的操作或方法、参数、数据类型等的支持，反之亦然。

此外，在一些实施例中，可以在反向代理服务器420内动态地创建某些REST web服务423和/或REST资源527-528。例如，反向代理服务器420内的REST基础设施422(和/或522、722和922)和/或其它组件可以在运行时期间生成、删除、替换或更新各种REST服务和/或REST资源。在这种情况下，即使某些REST资源528在某些时间可能不存在于反向代理服务器420上，那些资源也仍然可以在相同时间由反向代理服务器420暴露。例如，可以生成web应用描述语言(WADL)文件来描述由REST web服务423/523暴露的所有资源。WADL文件可以用来确定哪些REST资源528被REST服务423暴露，即使这些资源528中的一些尚未被创建。在下面参考图7和图8更详细地描述用于在反向代理服务器420内动态地生成和更新各种REST服务423/523和REST资源528的技术。

为了在步骤602中确定请求是否针对由反向代理服务器420中的REST服务423/523暴露的REST资源528，可以解析和分析该请求，以识别消息头和/或消息主体的相关部分以及请求目的地。例如，如果请求是针对URL的HTTP请求，其中该URL与用于REST服务423的WADL文件(或其它web服务描述数据)内的REST资源对应，则请求处置器421可以确定该请求是针对由反向代理服务器420暴露的REST资源528(602：是)。可替代地，如果该请求是无效请求、SOAP请求、对正常web内容的请求、或针对不能经由反向代理服务器420访问的REST资源的请求，则请求处置器421可以确定该请求不是针对由反向代理服务器420暴露的REST资源528(602：否)。

在步骤603中，在步骤601中接收到的REST web服务请求可以被转发到反向代理服务器420内的REST基础设施422。例如，在步骤602中确定web服务请求是对由反向代理服务器420暴露的REST资源的请求之后，请求处置器421可以将请求转发到REST基础设施422内的REST堆栈524，并且然后REST堆栈524可以将请求转发到静态REST应用525。如上所述，在一些实施例中，REST堆栈524可以是JAX-RS堆栈，并且静态REST应用可以是在构建时期间生成的JERSEY应用。在一些情况下，反向代理服务器520内的组件可以被配置为动态地初始化JAX-RS堆栈524和注册静态JERSEY应用525。

在步骤604中，反向代理服务器420(和/或反向代理服务器520、720和920)内的各种组件可以确定所请求的(一个或多个)REST资源当前是否存在于反向代理服务器420上。如上面提及的，在一些实施例中，REST web服务423可以被动态地创建，即，由反向代理服务器420内的REST基础设施422(和/或522、722和922)和/或其它组件在运行时期间生成。因此，在步骤604中，REST基础设施422和/或REST服务423可以确定所请求的REST资源当前是否存在于反向代理服务器420上。在一些情况下，在接收REST请求(602：是)时，REST堆栈524(例如，JAX-RX堆栈)可以接收该请求并且调取静态REST应用525(例如，JERSEY应用)，该应用可以调取已注册的REST提供者资源526。REST提供者资源526可以将请求委托给适当的REST服务423和/或在虚拟REST服务423内的适当的REST资源428。如果被调取的REST服务的REST提供者资源526和/或根资源527确定所请求的资源先前已被生成(604：是)，则该请求可以在步骤606中被转发到REST服务523的根资源527，并且然后在步骤607中被转发到适当的REST资源528以处置该请求。在一些实施例中，提供者资源526可以利用请求的URI来确定适当的REST根资源527，并且REST根资源527可以被映射到资源的“/”路径。然后，REST根资源527可以使用子资源定位符来定位反向代理服务器420内的实际REST资源528以处置该请求。

可替代地，如果REST基础设施526和/或被调取的REST服务523内的一个或多个组件确定所请求的REST资源尚未生成(或需要被重新生成)(604：否)，则可以在步骤605中生成处置该请求的所请求的适当的REST资源。在下面参考图7-图8更详细地讨论反向代理服务器420内的虚拟REST web服务423的生成。在步骤605中已生成处置请求的适当的REST资源之后，请求然后可以在步骤606中被转发到REST服务523的根资源527，并且然后在步骤607中被转发到新创建的REST资源528。

在步骤608中，可以在请求的处置期间(例如在反向代理服务器420内的REST资源528的执行期间)确定一个或多个后端web服务调用。在一些实施例中，软件钩子(hook)和/或其它定制的软件代码可以在资源被创建时插入到REST资源528中。这样的软件钩子和/或定制的软件代码可以识别后端REST服务430和资源，以及识别可以在对后端web服务430的调用中传输的各个操作(或方法)、参数和其它数据。当调取反向代理服务器420上的REST资源528来处置请求时，可以执行软件钩子和/或定制的软件代码，并且可以生成对后端web服务430的调用。

在一些情况下，在步骤608中确定的后端web服务调用可以与由反向代理服务器420上的REST资源528处理的REST请求类似或相同。例如，如下面更详细描述的，反向代理服务器420内的REST服务423可以被创建为后端REST服务430的副本，从而具有相同资源定义(例如，基于web应用描述语言(WADL)文件)、支持方法和参数等。在这种情况下，反向代理服务器420上的REST资源528可以包含配置为调取对应的后端REST web服务430内的相同REST资源、利用参数和/或主体内容调用对应的后端REST web服务430内的相同方法等的简单软件钩子。

在各种其它情况下，在步骤608中确定的后端web服务调用可以与由反向代理服务器420上的REST资源528最初处置的REST请求不同。在这种情况下，由反向代理服务器420暴露给客户端设备410的REST服务423/523和资源528完全不必对应于由后端REST服务430暴露的REST资源。例如，简要地参考图4A和图4B，虽然虚拟REST服务423a及其对应的后端REST服务430a在一些情况下可以类似地实现(例如，具有类似(或相同)的WADL文件、包括相同的资源、支持相同的方法、参数、数据类型等)，但是在其它情况下，虚拟REST服务423和对应的后端服务430可以非常不同地实现。为了说明，在步骤601中从客户端设备410接收到的REST请求可以包括到REST资源528的URL路径、HTTP方法、一个或多个URL参数和/或消息头或消息主体内的附加参数或数据。然而，当REST资源528执行以处置消息时，它可以生成具有不同URL路径(例如，不同的子资源路径或资源名称)、不同HTTP方法、不同URL参数/或不同头数据或主体数据的后端web服务调用。附加地，在一些实施例中，后端web服务430不必是REST服务，而可以是SOAP服务、URL或其它类型的web服务、web应用或web内容。在这种情况下，反向代理服务器420内的REST资源528可以被配置为生成SOAP和URL调用和/或配置为调取各种不同类型的后端web服务、应用、web内容等。因此，客户端设备410可以只具有关于由反向代理服务器420内的REST服务423/523暴露的REST资源528的知识，并且可以不具有对底层后端web服务430的设计或结构的任何认知。对虚拟REST服务423及其对应的后端服务430使用不同的web服务/资源设计和实现在一些实施例中会是有利的，例如，用于对不受信的客户端设备410模糊后端服务430的底层设计，以及用于提供后端web服务430之间的更容易的集成、兼容性和可扩展性。

在步骤609中，在已生成后端web服务调用之后，反向代理服务器420可以实施与后端web服务调用相关联的各种安全性策略(和/或其它通信管理策略)。然后，在步骤610中，调用可以在反向代理服务器420内执行，以调取受信的内部网络460内的一个或多个后端web服务430。如下面参考图9-图10更详细描述的，反向代理服务器420内的REST资源428可以向可处理调用并实施各种策略的策略实施引擎960提供后端web服务调用。在某些实施例中，安全性策略(和/或其它通信管理策略)可以在从客户端410到后端web服务430并返回的请求-响应的端到端处理流程内的各种不同的附连点(例如，OnRequest、OnInvoke、OnResponse、MessageTransformation、OnError等)处实施。

图7是示出根据一个或多个实施例的反向代理服务器的某些元件和系统的框图。在这个例子中的反向代理服务器720可以对应于反向代理服务器420和/或反向代理服务器520，并且反向代理服务器720的各个子组件722-723可以与以上讨论的对应的子组件类似或相同。附加地，反向代理服务器520可以在计算环境400或其它类似的环境内操作，并且可以被配置为在客户端计算设备和后端web服务之间处理和传输消息。因此，反向代理服务器720可以包括以上参考图4A-图4B和/或图5讨论的硬件、软件和联网组件和功能中的一些或全部。

在图7中示出的某些组件可以被配置为生成反向代理服务器720内的REST web服务723。如上面提及的，在一些实施例中，REST服务723以及包含在REST服务723中或由REST服务723暴露的REST资源728可以在反向代理服务器720内动态地创建。在这样的实施例中，REST基础设施722、REST应用引擎740、网关管理系统750和/或反向代理服务器720内的其它组件可以被配置为在运行时期间生成、删除、替换或更新反向代理服务器内的各种REST服务723和/或REST资源728。

在这个例子中，REST基础设施722包括REST堆栈724、静态REST应用725(例如，在构建时期间生成的JERSEY应用)和REST提供者资源726。反向代理服务器720可以在运行时期间动态地初始化REST堆栈724，并且可以注册可返回REST提供者资源726的静态REST应用725。REST应用725和/或REST提供者资源726可以被配置为确定由反向代理服务器720暴露的哪些REST服务723和REST资源728已在反向代理服务器720上生成。在这个例子中，REST应用725可以确定何时应当创建REST web服务723或REST资源728，例如，以用于处置来自客户端设备410的REST请求。REST应用725然后可以指示REST应用引擎740生成新的REST服务723和/或REST资源728。

图7包括反向代理服务器720内的REST应用引擎740和配置为与反向代理服务器720通信的网关管理服务器750(例如，在内部网络460内)。REST应用引擎740可以包括配置为在反向代理服务器720内生成REST服务723和/或资源728的一个或多个软件工具或平台。如下面所讨论的，REST应用引擎740可以例如经由从网关管理服务器750接收到的WADL文件接收REST服务描述数据和/或资源描述数据。REST应用引擎740然后可以在反向代理服务器720内生成、构建和部署REST服务723和REST资源728。

现在参考图8，其中示出了流程图，该流程图示出了用于在反向代理服务器内动态生成REST服务和/或REST资源的过程。如下所述，该过程中的步骤可以由以上讨论的一个或多个组件执行，这些组件诸如反向代理服务器420(和/或反向代理服务器520、720和920)、REST应用引擎740、网关管理服务器750和/或其中实现的各种子系统和子组件。附加地，在一些实施例中，该过程中的某些步骤可以在客户端设备410、后端web服务430内执行和/或由其它各种中介设备执行。还应当理解，本文所描述的技术(包括传输和接收web服务描述数据以及动态生成REST服务和资源)不必限定于上述的特定系统和硬件实现，而是可以在包括硬件、软件和网络组件的其它组合的其它硬件和系统环境内执行。

如上所述，步骤801-步骤804可以相对于用于在代理服务器内动态生成REST服务和REST资源的过程来执行。例如，REST服务723和REST资源728可以在运行时期间而不是在构建时期间在反向代理服务器720内创建。REST服务或REST资源的动态生成可以基于由反向代理服务器720在运行时期间接收到的各种信息来发起(或触发)。例如，如果所请求的REST资源尚未在反向代理服务器720内创建，则从客户端设备410接收到的REST请求可以在反向代理服务器720内发起动态REST服务/资源生成过程。作为另一个例子，新的后端web服务730的部署或对现有后端web服务730的修改可以在反向代理服务器720内发起动态REST服务/资源生成过程，以便将反向代理服务器720中的REST服务723与后端web服务730同步。

在步骤801中，可以在反向代理服务器720内接收描述(和/或定义)一个或多个后端web服务730的数据。在一些实施例中，在步骤801中接收到的描述数据可以包括由后端web服务730和/或受信的网关管理服务器750生成的一个或多个web应用描述语言(WADL)文件。用于REST服务730的WADL文件可以描述由REST服务暴露的所有资源，包括资源URL、支持的方法、参数、数据类型等。如上面提及的，后端web服务730可以包括REST web资源730以及其它类型的web服务730，诸如SOAP web服务和其它类型的后端web服务、应用、web内容等。因此，对于SOAP web服务730，可以使用web服务描述语言(WSDL)而不是WADL，并且在其它例子中，取决于后端web服务730的类型，可以使用各种其它数据格式。

不管接收到的描述数据的类型或格式如何，数据都可以以可由接收方设备解析的机器可读格式传输，以确定后端web资源730的结构和所支持的操作。在一些实施例中，描述数据(例如，WADL文件)可以由各个后端web服务730生成、提供给网关管理服务器750、并且然后被传输到REST应用引擎740。例如，网关管理服务器750可以响应于新的后端web服务730的部署或对现有后端web服务730的修改而自动地将更新后的描述数据传输到REST应用引擎740。在其它情况下，REST应用引擎740可以周期性地或者响应于在反向代理服务器720内发生的事件从网关管理服务器750(或直接从后端web服务730)检索描述数据。

在步骤802-步骤804中，REST应用引擎740和/或反向代理服务器720内的其它组件可以在反向代理服务器720内生成、构建和部署REST服务723和/或REST资源728。在这个例子中，在步骤802中，REST应用引擎740可以基于由后端web服务730暴露的资源来修改和/或定制REST服务描述数据。在步骤803中，REST应用引擎740可以利用在步骤802中修改/定制的REST服务描述数据在反向代理服务器720内创建一个或多个虚设(dummy)REST资源。最后，在步骤804中，REST应用引擎740和/或REST基础设施722可以在反向代理服务器720内部署在步骤803中生成的REST服务723和/或REST资源728。

在一些实施例中，生成和构建REST服务的步骤可以例如由REST应用引擎740和/或REST基础设施722在反向代理服务器720内执行。然而，在其它例子中，REST服务723和REST资源728可以在被提供给反向代理服务器720和部署到反向代理服务器720上之前，相对于反向代理服务器720远程(例如，在内部网络460内)进行设计、生成和/或构建。

对REST资源728的修改和/或定制可以采用插入到虚设REST资源中以调取一个或多个后端web服务730的软件钩子和/或其它定制的软件代码的形式。这样的软件修改/定制可以例如识别后端REST服务730和资源，以及识别可以在对后端web服务730的调用中传输的各个操作(或方法)、参数和其它数据。在REST资源728被构建和部署到反向代理服务器720上之后，软件钩子和/或定制的软件代码可以被执行以调取后端web服务730。如上面讨论的，在一些情况下，在步骤803中插入到REST资源728中的软件代码可以包括配置为调取对应的后端REST web服务730内的相同REST资源、利用参数和/或主体内容调用对应的后端REST web服务730内的相同方法等的简单软件钩子。在其它情况下，在步骤803中修改/定制的代码可以被设计为使用不同URL路径(例如，不同的子资源路径或资源名称)、不同HTTP方法、不同URL参数和/或不同头数据或主体数据来调取一个或多个不同的后端web服务730。附加地，如上面讨论的，后端web服务730不必是REST服务，而可以是SOAP服务、URL或其它类型的web服务、web应用或web内容。在这种情况下，步骤803中的软件定制/修改可以包括生成SOAP和URL调用和/或调取各种不同类型的后端web服务、应用、web内容等的定制代码。

当在步骤804中在反向代理服务器720内部署REST资源728时，每个资源728可以根据资源728的URL分层级地部署在REST服务723内。如上面讨论的，REST服务可以具有作为服务723内最高层级的资源(例如，映射到服务的“/”路径)并且负责识别将处置不同请求的子资源728(或孩子资源)的根资源。

图9是示出包括策略实施引擎960的反向代理服务器920的元件和系统的框图。在这个例子中的反向代理服务器920可以对应于反向代理服务器420(和/或520和720)，并且反向代理服务器920的各个子组件921-923可以与以上讨论的对应的子组件类似或相同。附加地，反向代理服务器920可以在计算环境400或其它类似环境内操作，并且可以被配置为在客户端计算设备和后端web服务之间处理和传输消息。因此，反向代理服务器920可以包括以上参考图4A-图4B、图5和/或图7所讨论的硬件、软件和联网组件和功能中的一些或全部。

除了请求处置器921、REST实现922和REST服务923之外，这个例子还示出了反向代理服务器920内的策略实施引擎960。在这个例子中，REST服务923及其相应的REST资源428可以向策略实施引擎960提供要被调取的任何后端web服务调用。策略实施引擎960可以在调取后端web服务930之前和/或之后处理后端web服务调用并实施各种安全性策略和其它通信管理策略。

策略实施引擎960可以包括配置为在反向代理服务器920内实现安全性策略以及其它通信管理策略的各种安全性系统或组件。在这个例子中，策略实施引擎960包括消息节流系统961、认证和授权系统962、密钥管理系统963和令牌仲裁系统(token mediationsystem)964。策略实施引擎960内的这些系统和安全性组件可以认证来自客户端设备410的消息、提供安全性令牌仲裁、执行API密钥管理、执行细粒度(fine grained)授权和/或数据编校、支持机密性和完整性、执行基于风险的认证、为移动客户端设备410执行基于设备的安全性、支持非军事化区(DMZ)威胁保护、执行协议和有效负载仲裁等。例如，认证/授权系统962可以包括子系统来阻止拒绝服务(DoS)攻击、检测和过滤畸形消息、检测和阻止SQL、JavaScript和/或XPath/XQuery注入攻击、执行消息验证以阻止恶意内容(例如，检测消息附件中的病毒、验证XML和JSON数据结构、验证表格和查询参数等)。令牌仲裁系统964可以被配置为在指定的客户端设备410和后端web服务930之间转换认证令牌。安全性系统961-964也可以执行自动仲裁或合成以及通过移除操作(例如，通过聚合多个后端API或服务)来支持编排。

附加地，在这个例子中，策略实施引擎960包括消息处理策略的数据存储库965。消息处理策略可以以各种形式的计算机可读媒介存储，诸如XML、JavaScript或其它类型的可执行软件组件。如下面更详细讨论的，消息处理策略965可以用来在反向代理服务器920内实施安全性策略和其它通信管理策略。数据存储库965可以包括可以在用于各个消息的端到端处理流程期间在各个阶段被检索并应用到各个消息的各个消息处理策略。消息处理策略数据存储库965可以如这个例子所示驻留在反向代理服务器920中，或者可以驻留在受信的内部计算机网络460的后端服务器或安全的第三方服务器内等。

现在参考图10，其中示出了流程图，该流程图示出了用于确定消息处理策略和处理诸如REST请求和其它后端web服务调用的消息的过程。如下所述，消息处理策略的确定和实施可以由反向代理服务器920(和/或420、520和72)中的一个或多个组件以及其中实现的各种子系统/子组件来执行。附加地，在一些实施例中，该过程中的某些步骤可以在客户端设备410、后端web服务930内执行和/或由其它各种中介设备执行。还应当理解，本文所描述的技术(包括监视端到端消息处理流程、确定消息处理策略以及实施消息处理策略)不必限定于上述的特定系统和硬件实现，而是可以在包括硬件、软件和网络组件的其它组合的其它硬件和系统环境内执行。

在步骤1001中，策略实施引擎960可以分析从REST服务923接收到的消息以确定该消息的目的地后端服务930以及发起该消息的客户端设备410。消息的目的地可以通过解析和分析由REST服务923生成的后端web服务调用(例如，REST请求、SOAP请求或web内容请求)来确定。例如，REST或SOAP请求的统一资源标识符(URI)、或者web服务或应用的标识符和/或消息主体内的操作标识符可以对应于由内部网络460提供的后端web服务/应用930或web内容。在这个例子中，代理服务器920可以基于消息头和内容来确定该消息预期用于内部网络460内托管web服务930的具体计算机服务器。在消息内的识别消息的传输者的信息(诸如源IP地址或主机名称标识符)也可以用来确定该消息的预期目的地。除了确定消息的预期目的地之外，代理服务器420还可以确定发起消息的客户端设备410。

在步骤1002中，策略实施引擎960可以确定用于要传输到后端web服务930的消息的预定处理流程中的当前点。消息处理流程可以指要由代理服务器920执行的端到端消息处理流程，该端到端消息处理流程从代理服务器920从客户端设备410接收消息开始，并且以代理服务器920将响应传输回到客户端设备410结束。如下面所讨论的，确定用于消息的预定处理流程中的当前点可以包括识别与该消息相关联的策略模型，以及确定该处理模型内的当前处理位置。

在一些实施例中，用于消息的预定消息处理流程可以由策略模型来定义。策略模型可以包括定义一组策略(例如，安全性策略、通信管理策略等)的数据，该策略可以被策略实施引擎960应用以在消息的端到端消息处理流程期间在各个点处处理消息。定义消息的端到端处理流程的策略模型和各个消息处理策略可以是各种形式的计算机可读媒介，诸如XML、JavaScript或其它类型的可执行软件组件。策略模型和/或消息处理策略可以存储在策略实施引擎960内(例如，在数据存储库965中)或在内部网络460内的其它地方。

如上所述，策略模型可以定义一组消息处理策略，策略实施引擎960可以在消息的端到端处理流程中的各个点处将该一组消息处理策略应用到消息。在一些实施例中，取决于从REST服务923接收到的消息的特性，策略实施引擎960可以在步骤1002中应用不同的策略模型。例如，由策略实施引擎960检索和应用的具体策略模型可以取决于消息的预期目的地和/或发起请求的客户端设备410。附加地，

由策略实施引擎960检索和应用的策略模型可以取决于用来传输消息的网络协议和/或消息的请求类型或客户端类型。例如，对于REST请求、SOAP请求、web内容(URL)请求等可以使用不同的策略模型。

在一些例子中，策略模型可以以XML或其它机器可读格式来实现。策略模型可以包括处理流程内的各个点(其也可以被称为“断言(assertion)”)的标签或标识符，以及用于每个处理点/断言的一个或多个策略标识符。例如，策略模型可以(在“on-request(请求时)”标签内)识别当接收到请求时要执行的策略、(在“message-transformation(消息变换)”标签内)识别执行消息变换的策略以及(在“on-invoke(调取时)”标签内)识别当后端web服务被调取时要执行的策略。

在一些实施例中，策略实施引擎960可以在服务级别(或URL级别)和/或在操作级别(或方法级别)应用策略。因此，当调取后端web服务930时，在策略实施引擎960可以实施在策略模型内识别出的策略之前，策略实施引擎960可以首先确定操作(针对SOAP)或方法(针对REST和URL)。

在识别出与从REST服务923接收到的消息相关联的策略模型(或定义处理流程的其它数据)之后，策略实施引擎960可以根据该策略或处理流程确定在处理消息中的当前点。消息处理流程中的当前点可以由消息本身的特性来确定以及基于先前存储的关于消息的较早处理的数据来确定。如上面提及的，预定处理流程可以从客户端设备410的初始请求到传输回客户端设备410的响应来应用消息的端到端处理。因此，确定消息是否是来自客户端设备410的初始请求、来自客户端设备的附加数据(例如，与请求有关的认证凭证或附加数据)的传输、来自后端web服务930的响应、或来自后端服务器或设备的附加数据(例如，来自单点登录或令牌转换服务的数据)的传输可以允许策略实施引擎960确定在端到端消息处理流程内的消息处理的当前点。附加地，策略实施引擎960可以存储与对消息或其它相关消息执行的先前处理有关的数据(诸如先前消息变换的结果、服务的调取、遇到的处理错误)，以便确定策略实施引擎960应该应用到该消息的下一个消息处理策略。

以下段落包括策略模型或其它消息处理流程内的可能点(其也可以被称为“断言”)的若干例子，其中消息处理策略可以在这些可能点处应用。应当理解，这些例子仅仅是说明性的，并不必是穷尽的列表。此外，本文所述的断言名称(例如，OnRequest、OnInvoke、OnResponse、OnError、MessageTransformation等)以及用于断言和策略的XML结构和标签名称在各种其它实施例中可以改变。

在步骤1002中确定策略模型或其它预定消息处理流程内的当前点的第一例子可以包括确定接收到的消息与来自外部计算机网络中的客户端设备410的请求对应。在消息的端到端处理流程的开始处的这一点可以被称为“OnRequest(请求时)”断言或者类似物。如下面更详细讨论的，OnRequest断言可以包括对可以被应用以便保护虚拟服务、代理服务和/或web应用的策略的引用。例如，OnRequest断言可以包括表示策略实施引擎960应该对从外部客户端设备410接收到的新web服务/应用/内容请求实施的安全性策略的URI或其它标识符。OnRequest断言也可以指其它策略和/或可以包含其它断言。在一些情况下，OnRequest断言可以只在反向代理模式下操作，即，可以只处置来自外部客户端设备410的对内部web服务930的请求。

在步骤1002中可能发生的当前消息处理点的另一确定可以包括：在接收到来自客户端设备410的请求之后，确定代理服务器920应当将请求传输到后端web应用或web服务930。消息的端到端处理流程内的这一点可以被称为“OnInvoke(调取时)”断言或者类似物。与OnRequest断言类似，在一些实施例中，OnInvoke断言可以只在反向代理用例中应用，在反向代理用例中，从客户端设备410接收初始请求以调取内部网络460内的后端web服务/应用930。OnInvoke断言可以包括表示策略实施引擎960在端到端处理流程中的这一点期间应当实施的策略的URI或其它标识符。多个策略标识符(或引用)可以例如通过使用多个XML“Policy URI”XML要素来包括在OnInvoke断言内。附加地，OnInvoke断言可以使用客户端的资源模式唯一地识别客户端细节。用于OnInvoke断言的客户端类型(例如，REST客户端、SOAP客户端、URL/web客户端等)可以由策略实施引擎960在运行时基于OnInvoke断言内配置的值来确定。OnInvoke断言还可以指其它策略和/或可以包含其它断言。

确定当前消息处理点的另一个例子可以包括在接收到来自从客户端设备410的请求之后并且在调取后端web服务430之后，确定代理服务器920应当将响应传输到客户端设备410。在消息的端到端处理流程内的这一点可以被称为“OnResponse”断言或者类似物。与OnRequest断言和OnInvoke断言一样，在一些实施例中，OnResponse断言可以只在反向代理用例中应用，在反向代理用例中，从客户端设备410接收初始请求以调取内部网络460内的后端web服务930。OnResponse断言可以包括表示策略实施引擎960在端到端处理流程中的这一点期间应当实施的策略的URI或其它标识符。多个策略标识符(或引用)可以包括在OnResponse内，并且OnResponse断言还可以指其它策略和/或可以包含其它断言。

确定当前消息处理点的另一个例子可以包括在端到端处理流程期间的某一点处确定代理服务器920应该将消息从一种消息类型变换为另一种消息类型。消息的端到端处理流程内的这一点可以被称为“MessageTransformation(消息变换)”断言或者类似物。例如，代理服务器920可以接收具有第一消息类型(例如，REST请求)的消息，并且可以分析该消息以确定该消息预期用于只接受第二消息类型(例如，后端SOAP服务)的后端服务或应用。在这样确定之后，策略实施引擎960可以对消息执行适当的MessageTransformation断言，之后将经变换的消息发送到预期目的地。策略实施引擎960可以支持的变换策略的例子可以包括但不限于XML到JavaScript对象符号(JSON)策略和JSON到XML策略、XML到SOAP策略和SOAP到XML策略、以及JSON到SOAP策略和SOAP到JSON策略。在各种实施例中可以支持其它众所周知的媒介类型之间的变换。策略实施引擎960可以在后端服务虚拟化时自动地附加适当的变换策略，并且该变换可以使用在代理服务器920或计算环境中的其它地方安装的一个或多个转换框架来执行。

确定当前消息处理点的还有的另一个例子可以包括确定在用于消息的端到端处理流程期间的某个点处已经发生错误。消息的端到端处理流程内的这一点可以被称为“OnError(错误时)”断言或类似物。触发消息的OnError断言(例如，触发在与消息相关联的OnError断言中识别出的一个或多个策略的执行)的错误可以是在由反向代理服务器920完成的处理内发生的错误和/或由反向代理服务器920从后端计算机服务器或设备接收到的错误。例如，反向代理服务器920可以从在消息的处理流程期间调取的后端计算机服务器(诸如授权服务、令牌转换服务或后端web服务930)接收错误指示。附加地，反向代理服务器920可以在执行消息处理任务时识别或生成错误，诸如在解析或验证消息中的错误或者在执行消息变换策略时的错误。因此，与处理流程内的一些先前例子中的、可以在该点处应用具体消息处理策略的点(也称为“断言”)不同，OnError断言可以是有条件的。也就是说，在消息的端到端处理流程期间，取决于在处理期间可能发生的错误的数量和类型，策略实施引擎960可以将来自OnError断言的策略应用一次、应用多次或者根本不应用。

在步骤1003中，可以由策略实施引擎960来确定用于处理在步骤501中接收到的消息的一个或多个具体策略。如上面讨论的，由反向代理服务器920选择和应用到消息的具体策略可以包括安全性策略以及任何其它类型的通信管理策略。作为例子而不是限制，这样的策略可以执行与以下各项相关的功能：认证、授权、审计、单点登录、安全性策略实施、密钥管理和分发、安全通信、安全数据存储和安全数据共享等。

策略可以在步骤1003中由策略实施引擎960通过以下来选择：检索与消息相关联的(一个或多个)端到端处理流程(例如，策略模型)，并且然后使用端到端处理流程内的在步骤1002中确定的当前点(例如，断言)来识别将在端到端流程中的当前点处应用到消息的具体策略。例如，如果消息是来自客户端设备410的对后端web服务430的请求，则策略实施引擎960可以检索在管理用于消息的端到端处理流程的策略模型的“on-request”标签内识别出的任何策略。

在步骤1004中，策略实施引擎960可以使用在步骤1003中选择的策略来处理消息。如上面讨论的，策略实施引擎960可以通过从用于消息的预定端到端处理流程中识别URI或其它策略标识符来确定要应用到消息的适当策略。在一些实施例中，取决于与端到端处理流程中的当前点对应的断言，策略模型可以包含用于要应用的策略的策略URI(或其它标识符)。这种策略URI可以引用策略的存储位置。在其它例子中，策略标识符不必被表示为URI，而是可以包括诸如API或服务标识符、功能名称、方法名称和/或操作名称等的其它识别数据。在任何情况下，策略标识符可以识别消息处理策略的存储位置或其它访问信息。策略本身可以以各种形式的计算机可读媒介存储，诸如XML、JavaScript或其它类型的可执行软件组件。

消息处理策略可以存储在位于计算环境内的各种不同服务器或设备中的数据存储库中，诸如数据库和/或基于文件的存储系统。例如，某些策略(诸如消息变换策略、消息节流策略、负载均衡策略以及可以是相对不变的和没有安全数据的其它策略)可以被本地存储在代理服务器920内(例如，在消息处理策略数据存储库965内)。其它策略(诸如用户认证/授权策略以及可以频繁改变或可以包括安全数据的其它策略)可以存储在受信的内部计算机网络460的安全服务器或存储系统内。在其它情况下，某些策略可以存储在外部网络中的安全第三方服务器或客户端设备410上。策略实施引擎960可以被配置为在步骤1004中从这些各种位置中的任何位置检索和应用策略。

在步骤1005中，在步骤1004中使用各种安全策略和/或其它通信管理策略处理消息之后，反向代理服务器920可以将处理后的消息传输到消息的预期目的地。如上面讨论的，预期目的地可以在步骤1001中通过解析和分析消息头和/或消息主体的部分来确定。消息的预期目的地可以在内部网络460内，诸如对后端web服务930的请求。可替代地，消息的预期目的地可以在外部网络中，诸如对外部web服务或应用的请求、或者对客户端设备410的响应或其它传输。

如上面讨论的，选择和应用用于在代理服务器920内处理消息的具体策略可以通过用于消息的预定端到端处理流程以及对端到端流程内用于消息的当前处理点的确定来确定。上面介绍的策略模型可以定义策略实施引擎960可以在消息的端到端处理流程中的各个点处应用到消息的一组消息处理策略。在一些实施例中，用于定义端到端处理流程的策略模型和其它技术可以利用一组策略模板来创建。这样的模板可以对应于特定的断言，并且可以用来创建策略模型端到端处理流程。例如，可以复制一个或多个断言模板，并且可以将适当的策略URI插入到每个模板副本中。定制的模板然后可以被添加到适当的策略模型以定义可以在端到端处理流程期间执行的策略。

除了定义要在端到端处理流程期间执行的断言和策略之外，由策略实施引擎960实施的策略模型(以及其它形式的预定端到端处理流程)还可以定义可以执行或可以不执行某些策略的条件。在一些实施例中，策略模型可以包含一组逻辑指令，这组逻辑指令实现用于执行在策略模型中引用的每个策略的条件。例如，策略模型可以包括这样的条件，该条件向代理服务器920指示某个策略应该对某些消息类型(例如，SOAP、REST或URL消息)执行，而不对其它消息类型执行。附加地，如上面讨论的，在一些情况下，策略模型可以选择性地在服务级别/应用级别和/或在操作级别/方法级别应用策略，并且因此具体策略的应用不仅可以取决于正被调取的后端web服务930，还可以取决于在服务930内正被调用的具体操作或方法。在各种附加实施例中，一些策略模型可以包括这样的条件，该条件向策略实施引擎960指示某个策略应当对某些用户执行而不对其它用户执行、应当对某些客户端设备类型执行而不对其它客户端设备类型执行、应当对某些后端web服务/应用执行而不对其它后端web服务/应用执行、和/或应当对与消息相关的任何其它特性如此。

如以上例子所示，本文所描述的各种实施例可以支持动态策略模型，在动态策略模型中，在DMZ或其它逻辑或物理子网络内可以在贯穿消息的端到端处理流程的各个不同处理点处应用不同的安全性策略和其它通信管理策略。该动态策略模型框架可以用来构建和实现附加的安全性，以阻止来自恶意外部计算系统的攻击，并且可以实现在最后一英里安全性基础设施内(例如，在后端web服务/应用430内)可能不可能或不可取的附加类型的安全性策略。附加地，可以使用本文所描述的动态策略模型来实现强健的认证和授权系统(诸如令牌转换和/或单点登录访问控制系统)。例如，客户端设备410可以经由用户名/密码或其它用户凭证来认证，并且预定端到端处理流程可以在代理服务器420内执行，代理服务器420从内部网络460内的受信的认证/授权服务执行令牌检索和验证，以便检索或生成不同类型的各种不同的访问令牌(例如，Kerberos令牌、SPNEGO令牌、用户名令牌、NTLM令牌、SAML令牌等)。因此，在用户提供一组有效凭证并且被成功认证和授权之后，可以使用代理服务器420内的各种策略模型通过检索或生成用于随后由用户访问的各种不同的后端web服务/应用430的对应的令牌类型，来实现单点登录访问控制系统。

根据本申请的实施例，提供了一种包括处理单元和通信单元的系统。这种系统可以通过硬件、软件或硬件和软件的组合来实现，以执行本发明的原理。本领域技术人员应当理解，处理单元和通信单元可以通过上述组件(诸如图3所示的组件)来实现。同时，本领域技术人员应当理解，处理单元和通信单元可以组合或分离成子单元，以实现如上所述的本发明的原理。因此，本文的描述可以支持本文所述的功能单元的任何可能的组合或分离或进一步定义。

在以上实施例的例子中，处理单元和通信单元可以协作来执行以下操作：接收来自外部计算机网络中的客户端设备的web服务请求，其中系统被配置为在与外部计算机网络分离的内部计算机网络的子网络内操作；识别web服务请求内的第一资源；确定第一资源被系统内的第一表述性状态传递(REST)web服务暴露；调取系统内的第一REST web服务；以及在系统内的第一REST web服务的执行期间，调取内部计算机网络中的计算机服务器内的第二web服务。

在另一个例子中，处理单元和通信单元可以协作来通过执行以下操作以调取RESTweb服务：确定被第一REST web服务暴露的第一资源不存在于与处理单元相关联的存储器内；以及在该存储器内生成第一资源，其中第一资源在从客户端设备接收到web服务请求之后生成。

在另一个例子中，处理单元和通信单元可以协作以进一步执行以下操作：访问描述由内部计算机网络中的计算机服务器内的第二web服务提供的一组资源的web应用描述语言(WADL)文件；以及使用由第二web服务提供的该一组资源的WADL文件中的描述，在第一REST web服务中生成一个或多个资源。

在还有的另一个例子中，处理单元和通信单元可以协作来通过执行以下操作在系统内的第一REST web服务中生成资源：修改WADL文件内的一个或多个资源描述；基于修改后的资源描述创建一个或多个REST资源；以及在系统内的第一REST web服务中部署每个REST资源。

在前面的描述中，为了说明的目的，以特定的顺序描述了方法。应当理解，在可替代的实施例中，方法可以以与所描述的顺序不同的顺序来执行。还应当理解，上述方法可以由硬件组件执行或者可以以机器可执行的指令的序列来体现，机器可执行的指令可以用来使机器(诸如通用处理器或专用处理器或编程有该指令的逻辑电路)执行所述方法。这些机器可执行的指令可以存储在一个或多个机器可读介质或存储器设备上，诸如CD-ROM或其它类型的光盘、软盘、ROM、RAM、EPROM、EEPROM、磁卡或光卡、闪存存储器、或适于存储电子指令的其它类型的机器可读介质或存储器设备。可替代地，所述方法可以通过硬件和软件的组合来执行。

虽然本文已经详细描述了本发明的说明性和当前优选的实施例，但是应当理解，可以以其它方式不同地体现和采用本发明性概念，并且除了由现有技术限制，所附权利要求旨在被解释为包括这些变化。

Claims (17)

1.一种在计算机网络之间传输web服务请求的方法，所述方法包括：

在与内部计算机网络通信的代理服务器处，接收来自与内部计算机网络分离的外部计算机网络中的客户端设备的web服务请求；

识别所述web服务请求内的第一被请求的资源；

确定第一被请求的资源由代理服务器内的第一表述性状态传递REST web服务暴露；

确定由第一REST web服务暴露的第一被请求的资源不存在于代理服务器内；

响应于确定第一被请求的资源不存在于代理服务器内，在代理服务器内生成第一被请求的资源，其中第一被请求的资源在从客户端设备接收到所述web服务请求之后生成；

调取代理服务器内的第一REST web服务，并且将所述web服务请求转发到所生成的第一被请求的资源；及

在代理服务器内的第一REST web服务内的所生成的第一被请求的资源的执行期间，调取内部计算机网络中的计算机服务器内的第二web服务。

2.如权利要求1所述的方法，还包括：

访问描述由内部计算机网络中的计算机服务器内的第二web服务提供的一组资源的web应用描述语言WADL文件；及

使用由第二web服务提供的该一组资源的WADL文件中的描述，在代理服务器内的第一REST web服务中生成一个或多个资源。

3.如权利要求2所述的方法，其中在代理服务器内的第一REST web服务中生成第一被请求的资源包括：

修改WADL文件内的一个或多个资源描述；

基于修改后的资源描述创建一个或多个REST资源；及

在代理服务器内的第一REST web服务中部署这些REST资源中的每一个REST资源。

4.如权利要求1至3中任何一项所述的方法，其中第二web服务是内部计算机网络中的计算机服务器内的REST web服务。

5.如权利要求4所述的方法，其中代理服务器内的第一REST web服务暴露多个资源，所述多个资源包括配置为调取第二REST web服务的至少一个资源，并且包括配置为调取由内部计算机网络中的不同计算机服务器暴露的第三REST web服务的至少一个资源。

6.如权利要求4所述的方法，其中第二REST web服务暴露多个资源，并且其中代理服务器内的第一REST web服务暴露由第二REST web服务暴露的所述多个资源的子集。

7.如权利要求1所述的方法，其中第二web服务是在内部计算机网络中的计算机服务器内的简单对象访问协议(SOAP)web服务。

8.如权利要求1至3和5至7中任何一项所述的方法，还包括：

确定代理服务器内用于所述web服务请求的预定处理流程中的当前点；

基于所确定的用于所述web服务请求的预定处理流程中的当前点，检索一个或多个安全性策略；及

根据所述安全性策略处理所述web服务请求，其中所述web服务请求在调取由内部计算机网络中的计算机服务器暴露的第二web服务之前被处理。

9.一种在计算机网络之间传输web服务请求的系统，包括：

处理单元，所述处理单元包括一个或多个处理器；及

存储器，所处存储器与所述处理单元耦合并且可由所述处理单元读取，并且在所述存储器中存储一组指令，当所述指令被所述处理单元执行时，使得所述处理单元：

接收来自外部计算机网络中的客户端设备的web服务请求，其中所述系统被配置为在与外部计算机网络分离的内部计算机网络的子网络内操作；

识别所述web服务请求内的第一被请求的资源；

确定第一被请求的资源由所述系统内的第一表述性状态传递REST web服务暴露；

确定由第一REST web服务暴露的第一被请求的资源不存在于所述系统内；

响应于确定第一被请求的资源不存在于所述系统内，在所述系统内生成第一被请求的资源，其中第一被请求的资源在从客户端设备接收到所述web服务请求之后生成；

调取所述系统内的第一REST web服务，并且将所述web服务请求转发到所生成的第一被请求的资源；及

在所述系统内的第一REST web服务内的所生成的第一被请求的资源的执行期间，调取内部计算机网络中的计算机服务器内的第二web服务。

10.如权利要求9所述的系统，所述存储器在其中存储进一步的指令，当所述进一步的指令被所述处理单元执行时，使所述处理单元：

访问描述由内部计算机网络中的计算机服务器内的第二web服务提供的一组资源的web应用描述语言WADL文件；及

使用由第二web服务提供的一组资源的WADL文件中的描述，在所述系统内的第一RESTweb服务中生成一个或多个资源。

11.如权利要求10所述的系统，其中在系统内的第一REST web服务中生成第一被请求的资源包括：

修改WADL文件内的一个或多个资源描述；

基于修改后的资源描述创建一个或多个REST资源；及

在所述系统内的第一REST web服务中部署这些REST资源中的每一个REST资源。

12.如权利要求9至11中任何一项所述的系统，其中第二web服务是内部计算机网络中的计算机服务器内的REST web服务。

13.如权利要求12所述的系统，其中所述系统内的第一REST web服务暴露多个资源，所述多个资源包括配置为调取第二REST web服务的至少一个资源，并且包括配置为调取由内部计算机网络中的不同计算机服务器暴露的第三REST web服务的至少一个资源。

14.如权利要求12所述的系统，其中第二REST web服务暴露多个资源，并且其中所述系统内的第一REST web服务暴露由第二REST web服务暴露的所述多个资源的子集。

15.一种非临时性计算机可读存储器，包括存储在其中的一组指令，当所述指令被处理器执行时，使所述处理器：

在配置为在内部计算机网络的子网络内操作的系统处接收web服务请求，其中所述web服务请求从与内部计算机网络分离的外部计算机网络中的客户端设备接收；

识别所述web服务请求内的第一被请求的资源；

确定第一被请求的资源由所述系统内的第一表述性状态传递REST web服务暴露；

确定由第一REST web服务暴露的第一被请求的资源不存在于所述系统内；

响应于确定第一被请求的资源不存在于所述系统内，在所述系统内生成第一被请求的资源，其中第一被请求的资源在从客户端设备接收到所述web服务请求之后生成；

调取所述系统内的第一REST web服务，并且将所述web服务请求转发到所生成的第一被请求的资源；及

在所述系统内的第一REST web服务内的所生成的第一被请求的资源的执行期间，调取内部计算机网络中的计算机服务器内的第二web服务。

16.如权利要求15所述的计算机可读存储器，包括存储在其中的进一步的指令，当所述进一步的指令被所述处理器执行时，使所述处理器：

访问描述由内部计算机网络中的计算机服务器内的第二web服务提供的一组资源的web应用描述语言WADL文件；及

使用由第二web服务提供的一组资源的WADL文件中的描述，在所述系统内的第一RESTweb服务中生成一个或多个资源。

17.如权利要求16所述的计算机可读存储器，其中在所述系统内的第一REST web服务中生成资源包括：

修改WADL文件内的一个或多个资源描述；

基于修改后的资源描述创建一个或多个REST资源；及

在所述系统内的第一REST web服务中部署这些REST资源中的每一个REST资源。

Images