[发明专利]基于代理的双向Web服务路由器网关

说明书

相关申请的交叉引用

本申请要求2008年5月27日提交的美国临时申请序列号61/056,261的优先权，通过引用将其全部内容并入本文。

技术领域

本申请一般地涉及电信，更具体地，涉及双向Web服务的提供。

背景技术

对于通信启用业务流程(“CEBP”)和软件即服务(“SaaS”)以及分布式的面向服务架构(“SOA”)解决方案来说，远程服务接入和分布式服务集成是关键的。缺少了它，web服务应用和SOA解决方案将会被网络地址转换/防火墙的企业域限制。

一种广泛使用的解决这个问题的方法要求企业改变并开放其网络的网络地址转换/防火墙配置，以使其web服务端点可公开访问，正如在单向web服务情境下常做的。然而，对于双向web服务来说，其需要将服务提供者和服务用户都暴露于外部公共网络。这给服务提供者和服务用户都带来了很大的风险。由于企业的安全架构可能是非常复杂的，甚至需要通过特别的努力才可行，所以这不是企业IT优选的。更重要的是，其无法支持通信启用业务流程的动态特性，在通信启用业务流程中将按需增添或删除许多服务。

另外，因为潜在的风险，暴露服务于公共网络通常需要很长的时间并且历经很多级的批准。随着服务和应用的数量增加，通过不变的网络地址转换/防火墙重新配置来支持动态的通信启用业务流程应用对企业IT的工作负荷和费用可能变得过高。

换句话说，一些中小型企业可能不具有基础设施和专业技术来宣传其web服务。要求这些企业使其应用可公开接入将会给企业带来显著的费用，并且最后阻止这些企业使用这些服务或排除这些服务成为通信启用业务流程解决方案的一部分。在很多情况下，客户端应用仅想要从特定源接收感兴趣的事件，而使事件接收方暴露于外部网络不仅是不必要的，而且还引入安全问题。总之，目前的方法不适合于双向web服务的主机(hosted)服务、管理服务或按需服务，对于通信启用业务流程、分布式SOA以及通信服务来说，双向web服务是关键的。

处理该问题的另一现有技术要求企业部署虚拟专用网(“VPN”)以连接相异网络。然而，VPN非常昂贵和复杂。此外，在很多情况下，VPN并不合适。例如，企业通常不允许其合作者、第三方或供应商直接通过VPN接入其内部企业网。

微软刚刚发布了其BizTalk连接性服务，其允许开发者创建松散耦合的应用，并使服务从防火墙或网络地址转换后面暴露于互联网(详情参见http://connect.biztalk.net/)。然而，这是依赖于平台和应用的解决方案，并要求具有.Net构架的特定版本的Windows平台。暴露的服务由微软管理。这对于应用来说不是透明的，而只有使用BizTalk的SDK的那些应用才能够被从外部网络访问。

发明内容

本发明能够提供双向Web服务，而没有现有技术中的一些费用和技术缺点。例如，示例性的实施例使位于不同企业域和不同防火墙后面的客户端和服务器能够请求和接收双向Web服务，而仅需对防火墙进行很少的改变或无需对其进行改变。这对于通信启用业务流程(“CEBP”)、软件即服务(“SaaS”)以及分布式的面向服务架构(”SOA”)解决方案是特别有利的。

根据示例性实施例，在公共域中配置“隧道集线器(tunnel hub)”，在客户端请求双向服务以及服务器提供双向服务处的防火墙的后面配置“隧道网关”。每个隧道网关向外发起经过防火墙到目标集线器的安全隧道。此后，对服务的请求进入隧道网关，传播到隧道集线器，并到达提供服务的服务器所在的适当隧道网关。当服务器提供服务时，该服务进入隧道网关，传播到隧道集线器，并到达请求该服务的客户端所在的适当隧道网关。因为所有的隧道从企业防火墙的后面发起，所以双向web服务能够穿越防火墙，而仅需对企业的网络地址转换/防火墙配置进行很少的改变或无需对其进行改变。

附图说明

图1示出了本发明示例性实施例的显要部件的示意图；

图2示出了隧道网关123-i(其中i∈{1，2，3})的显要部件的示意图；

图3示出了隧道集线器112的显要部件的示意图；

图4示出了与示例性实施例的操作相关的显要任务的流程图；

图5示出了在执行任务403-建立隧道的网络期间，由示例性实施例执行的显要任务的流程图；

图6示出了在执行任务401-请求和接收双向服务期间，由示例性实施例执行的显要任务的流程图。

具体实施方式