专利名称：用于web服务中介体的端口类型不可知的代理支持的制作方法
技术领域：
本发明涉及数据处理，更具体而言，涉及用于web服务中介体的端口类型不可知的(agnostic)代理支持。
背景技术：
术语“web服务”指的是集成基于web的应用的标准化方式。Web服务典型地在请求时通过数据通信以被称为绑定的标准化格式来提供商务(business)服务。绑定是一种数据编码方法与数据通信协议的规范。用于web服务的最通用绑定是根据SOAP协议以XML进行的数据编码以及利用HTTP的数据通信。
与传统的客户/服务器模型(例如响应于来自浏览器客户的请求而提供HTML文档的HTTP服务器)不同，web服务与显示无关。相反，web服务通过编程接口跨越网络共享商务逻辑、数据和过程。Web服务应用彼此接口而不是与用户接口。因为web服务之间的所有数据通信是根据标准化绑定实现的，所以web服务不依赖于任何一种操作系统或编程语言。在WindowsTM平台中运行的Java客户可以调用以Perl写成且在Unix下运行的web服务操作。以C++写成的Windows应用可以调用作为Java小服务程序(servlet)实现的web服务中的操作。
现在，web服务在许多产业中成长。随着web服务在重要性方面的增加，web服务中介体(intermediary)越来越被认为是提供许多增值服务的手段。Web服务中介体(在本说明书中被通称为“中介体”)是位于web服务客户和web服务供应者之间的web服务组件。中介体一般通过截取来自客户的请求、提供中介体服务以及随后将客户请求转发到web服务供应者而进行操作。类似地，来自web服务供应者的响应被截取，对其进行操作以及随后被返回给客户。可购买到的可以实现web服务中介体的产品示例包括IBM的Web Services GatewayTM和IBM的Web Services BusTM。
由中介体提供的服务包括对目标服务的请求源的认证、对内容和形式的消息确认、以及用于审计目的的消息记录。中介体可以提供由个体客户使用的管理报告服务、web服务命中数、服务量和计时等。例如，中介体通过存储频繁改变但又被频繁请求的数据(例如新闻故事)，可以被用作高速缓存以支持改进的性能。中介体可以被用于负载均衡意义上的性能改进，存储来自若干客户的服务请求以及在非峰值服务时间将它们转发给目标服务。中介体可以聚集服务，例如作为接受对帐户记录的请求的记帐中介体，该请求随后被转发到用于应付款、应收款和总帐服务的单独目标服务。
现有技术中通常是实现web服务中介体，使得它们紧紧耦合到它们的目标服务。即，特定的中介体仅仅向特定的目标web服务提供中介体服务。当例如中介体提供消息确认并且因此必须具有对正确消息内容与形式的准确知识时，对此的需要是明显的。在web服务的术语中，一组操作被称为“端口类型”。在该术语中，紧紧耦合的限制意指通常在现有技术中，中介体服务和由中介体服务所服务的所有目标服务将具有相同的端口类型。然而，存在这样的情形，其中中介体服务跨多个端口类型运行而不考虑端口类型是有用的，例如想要在指向任何目标服务的消息上提供完全相同认证功能的客户身份认证功能。现有技术在这些情形中强加了额外的配置复杂度，因此目前需要在web服务中介体方面的改进。
发明内容
根据第一方面，提供了一种用于web服务中介体的端口类型不可知的代理支持的方法，该方法包括在web服务中介体中接收对执行web服务操作的请求，其中所述请求包括可以从其标识出支持所述操作的目标服务的端点的参数信息；根据该参数数据，标识出支持所述操作的目标服务的端点；创建用于执行所述目标服务上的所述操作的目标服务请求；以及将所述目标服务请求发送到所述目标服务。
在一实施例中，确定出所述请求是否要求同步响应；以及如果所述请求要求同步响应，则等待来自所述目标服务的响应。
在典型的实施例中，确定所述请求是否要求同步响应是通过根据所述参数信息确定所述请求是否要求同步响应而实现的。在典型实施例中，创建用于执行所述目标服务上的所述操作的目标服务请求包括根据对所述请求是否要求同步响应的确定来创建所述目标服务请求。对于不要求同步响应的请求，某些实施例包括从目标服务接收目标服务请求的确认以及在不等待响应消息的情况下将所述确认返回到请求者。
对于要求同步响应的请求，某些实施例通过下述步骤实现等待来自所述目标服务的响应在所述中介体中同步接收来自所述目标服务的响应；根据来自所述目标服务的响应在所述中介体中创建来自中介体的响应；以及将来自所述中介体的响应返回到请求者。在典型的实施例中，在中介体中同步接收来自所述目标服务的响应是通过在所述中介体和所述目标服务之间的数据通信连接上调用阻塞(blocking)接收功能而实现的。
在许多实施例中，经创建并被发送到目标服务的目标服务请求带有在web服务中介体中接收到的请求的未经检查和未经修改的消息内容。示例性实施例典型地还包括请求-响应处理的返回路径在中介体中接收来自目标服务的响应；根据来自目标服务的响应在中介体中创建来自中介体的响应；以及将来自中介体的响应返回到请求客户。
本发明的典型实施例还包括对于请求者，将web服务中介体的端点标识为支持所述操作的端点。在这样的实施例中，参数信息常常包括用于所述操作的端口类型。此外，标识出支持操作的目标服务的端点常常还包括根据参数信息标识出支持所述操作的目标服务的多个端点，以及根据选择规则所述从多个端点中选择一个端点。标识出支持操作的目标服务的多个端点可以通过根据端口类型从登记簿(registry)中标识出用于所述端口类型的多个目标服务来实现。从多个端点中选择一个端点可以包括根据用于在目标服务之间进行负载均衡的选择规则，从多个端点中选择一个端点。
创建用于执行目标服务上的操作的目标服务请求可以通过下述步骤来实现以在与绑定无关的接口中有用的数据结构编写所述请求并且调用所述与绑定无关的接口，同时将所述请求作为调用参数传送。将所述目标服务请求发送到目标服务可以包括调用与绑定无关的接口中的一个或多个成员方法。
根据第二方面，本发明提供了一种用于web服务中介体的端口类型不可知的代理支持的系统，该系统包括用于在web服务中介体中接收对执行web服务操作的请求的装置，其中所述请求包括可以从其标识出支持所述操作的目标服务的端点的参数信息；用于根据该参数数据标识出支持所述操作的目标服务的端点的装置；用于创建用于执行所述目标服务上的所述操作的目标服务请求的装置；以及用于将所述目标服务请求发送到所述目标服务的装置。
根据第三方面，提供了一种用于web服务中介体的端口类型不可知的代理支持的计算机程序产品，该计算机程序产品包括记录媒体；记录在所述记录媒体上的用于在web服务中介体中接收对执行web服务操作的请求的装置，其中所述请求包括可以从其标识出支持所述操作的目标服务的端点的参数信息；记录在所述记录媒体上的用于根据该参数数据标识出支持所述操作的目标服务的端点的装置；记录在所述记录媒体上的用于创建用于执行所述目标服务上的所述操作的目标服务请求的装置；以及记录在所述记录媒体上的用于将所述目标服务请求发送到所述目标服务的装置。
本发明可以以计算机软件实现。
现在将参考下面的附图仅仅以示例的方式描述本发明的优选实施例图1A和1B描述了web服务的示例性体系结构的绘线图，在该web服务中可以根据本发明实施例实现用于web服务中介体的端口类型不可知的代理支持。
图2A描述了根据本发明实施例的示例性中介体的框图的绘线图。
图2B描述了根据本发明实施例实现SOAP-HTTP信道的示例性中介体(202)的框图的绘线图。
图3描述了图示出根据第一实施例的用于web服务中介体的端口类型不可知的代理支持的方法的流程图。
图4描述了图示出根据第二实施例的用于web服务中介体的端口类型不可知的代理支持的方法的流程图。
图5描述了图示出根据第二实施例的用于在请求要求同步响应时等待(361)来自目标服务的响应的方法的流程图。
具体实施例方式
在本说明书中在很大程度上是就用于web服务中介体的端口类型不可知的代理支持的方法来描述本发明的。然而，本领域技术人员将认识到，包括用于根据所公开的方法而工作的适当编程装置的任何计算机系统也落在本发明的范围之内。适当的编程装置包括用于引导计算机系统执行本发明方法步骤的任何装置，例如包括由耦合到计算机存储器的算术逻辑电路和处理单元组成的系统，该系统具有在计算机存储器中进行存储的能力，该计算机存储器包括被配置来存储数据与程序指令、经编程的用以由处理单元执行的本发明方法步骤的电路。
本发明还可以实现在计算机程序产品中，例如盘或其它记录媒体中，用于和任何适当的数据处理系统一起使用。计算机程序产品的实施例可以通过使用用于机器可读信息的任何记录媒体来实现，包括磁媒体、光媒体或其它适当的媒体。本领域技术人员将马上认识到，具有适当编程装置的任何计算机系统将能够执行在程序产品中实现的本发明的方法步骤。本领域技术人员将马上认识到，尽管本说明书中描述的大多数示例性实施例是针对经安装并在计算机硬件上执行的软件的，然而，被实现为固件或硬件的替代性实施例也在本发明的范围之内。
定义“商务(business)登记簿”，作为本说明书中使用的术语，是含有商务列表的web服务以及商务所提供的web服务的因特网目录。Web服务的列表包括所支持的操作、端口类型、端点和绑定等。一些商务登记簿是基于诸如ebXML的开放标准的，而一些是基于诸如UDDI的行业协会所倡导的规范。商务可以向登记簿登记自身。商务可以提交通过登记簿共享的材料，并且登记簿客户可以搜索到其他人已经提交的材料。商务登记簿可以通过浏览器手工地访问并搜索，或者通过API自动地访问并搜索，其中API自身可以是web服务。登记簿正在变成web服务的越来越重要的组件，因为它们允许商务彼此以松散耦合的方式动态合作。
HTTP意指“超文本传输协议”，是web上最通用的数据通信协议。然而，在本说明书中，术语“web”不限于HTTP通信，而是可以包括与支持类似通信模式的其它协议的通信，所述其它协议例如HDTP(手持设备传输协议)或WAP(无线接入协议)、以及本领域技术人员将想到的其它协议。
“SOAP”意指“简单对象访问协议”，其是用于在web服务请求与响应消息中在通过网络发送它们之前对其中的信息进行编码的轻量的基于XML的消息传送协议。SOAP消息不依赖于任何操作系统或协议，并且可以使用多种因特网协议(包括SMTP、MIME和HTTP)来传输。
“UDDI”意指“统一描述、发现和集成”，其是基于web的分布式目录，其使商务能够在因特网上列出自身并且发现彼此，这类似于传统的电话本的黄白页。
“WSDL”意指“web服务描述语言”。WSDL是XML格式的语言，其由Microsoft和IBM联合开发并且被用来描述作为能够交换消息的通信端点的集合的web服务的能力。WSDL是UDDI的集成部分，其中UDDI使用WDSL来描述web服务的能力。
“ebXML”意指“电子商务可扩展标记语言”，其是用于以XML来标准化web服务的描述以使电子贸易的买卖更加便利的模块化规范集。与UDDI类似，ebXML规范给予商务定义和登记web服务的标准方法。
本说明书一般利用类似于WSDL的术语来描述web服务的组件。Web服务被描述为能够交换消息的网络端点集合，网络端点是数据通信的端点。端点有时被称为“端口”。然而，在本说明书中术语“端点”一般优于“端口”，以减少和术语“端口类型”相混淆的风险。端口类型不是端口的类型或端点的类型。端口类型是“操作”的集合，即，由服务支持的软件动作或功能。
用于端口类型的特定通信协议和数据格式规范构成“绑定”。绑定的示例是SOAP/HTTP，其中根据SOAP对消息数据编码并且根据HTTP在端点之间传送消息。绑定的另一示例是GET/POST/HTTP，其中在GET或POST消息中编码消息数据，并且根据HTTP执行数据通信。
每个端口类型可以具有不只一个绑定。端点是通过将网络地址与绑定相关联而定义的，并且如所述的那样，端点的集合定义服务。对于web服务中的操作的请求和数据的通信是通过被称为“消息”的数据结构而执行的，“消息”又由“部分”构成。术语“请求”和“响应”一般是消息流方向的指示。用于特定绑定的请求消息和响应消息可以具有相同的数据结构。
用于web服务中介体的端口类型不可知的代理支持通过参考附图，描述了用于web服务中介体的端口类型不可知的代理支持的方法、系统和产品，开始于图1A和1B。图1A描述了web服务的示例性体系结构的绘线图，在该web服务中可以根据本发明实施例实现用于web服务中介体的端口类型不可知的代理支持。在图1A的体系结构中，中介体(202)能够连接到请求者(102)和目标服务(118)，用于通过协议进行数据通信。请求者(102)位置处的web服务组件有时被称为客户。类似地，中介体(202)位置处的组件，特别是从请求者的视角看来，有时被称为服务器。
在web服务的语境中必须谨慎使用客户/服务器的区分。在图1B的体系结构中，例如，目标服务(118)在准备对来自请求者(102)的请求的响应的过程中，可以又通过中介体(203)请求来自目标服务(119)的web服务。此时，目标服务(118)充当客户。中介体(202)在将请求转发到目标服务(118)的过程中充当客户。任何特定时间处特定组件被认为是客户还是服务器取决于此时由该组件执行的特定功能。即，web服务组件在一个时刻可以是客户，而在下一时刻可以是服务器。因此，为了减少混淆术语的风险，在本说明书中一般通过使用“请求者”、“中介体”和“目标服务”而非“客户”或“服务器”来描述web服务组件。
为了中介体(202)能代表目标服务(118)提供中介体服务，中介体(202)必须知道目标服务(118)上的端点。如上所述，在现有技术中，在中介体(202)上运行的服务(被称为“代理”)将支持与目标服务(118)相同的端口类型，并且在其配置数据中将具有用于目标服务(118)的端点。然而，在图1的体系结构中，代理是“端口类型不可知的”，意指对代理而言没有可用的配置数据描述目标服务的端点，并且请求者(102)可以在中介体完全未知的端口类型中提交对操作的请求。
图2A描述了根据本发明实施例的示例性中介体(202)的框图的绘线图。中介体(202)包括自动化计算机器，所述自动化计算机器是包括至少一个中央处理单元、计算机存储器和系统总线等的计算机系统。图2A框图中的框代表可在中介体(202)的计算机系统中运行的软件应用模块。图2A中的箭头代表在软件模块之间的数据流。
中介体(202)包括能够从请求者(102)接收包括参数信息(107)的请求(106)的入站引擎(208)，用于执行web服务操作。这里是用于SOAP-HTTP绑定的这种请求的示例POST/Channel/proxy portType=A HTTP/1.1Host:www.myIntermediary.comContent-Type:text/xml;charset="utf-8"Content-Length:nnnnSOAPAction:"Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
该示例性POST消息包括从中介体请求“myOp”操作的SOAP包封。即，在soap消息内部标识出要在目标服务(118)上执行的操作的名称。myOp操作、其端口类型及其端点在请求被接收之前对中介体来说是未知的。在该示例中，从其可以标识出支持所述操作的目标服务(118)的端点的参数信息(107)，在POST第一行中在经URI编码的查询串中的名称值对中被描述“portType=A”。
在第二实施例中，示例性请求的第一行应当读取POST/Channel/proxy portType=A&synchRespReqd=Ture HTTP/1.1在该第二实施例中，参数信息包括名称值对“synchRespReqd=Ture”，根据本发明实施例的端口类型不可知的代理从其可以确定请求是否要求同步响应。
除了从请求者(102)接收对网络服务的请求(106)(包括参数信息(107))，入站引擎(208)还具有将包括其参数数据的请求提供给端口类型不可知的代理(212)的能力。将上面描述的示例性请求视为入站引擎操作的示例。该示例性请求被绑定为SOAP-HTTP。因此，对于该示例性请求，入站引擎可以是使能SOAP的HTTP服务器，其将进入的请求转交给被实现为任意种类的服务器型应用的代理(212)，例如包括Java Bean、Java小服务程序或以Perl编写的CGI(公共网关接口)脚本。被提及的Java小服务程序和CGI脚本仅仅用于解释而不是用于限制。在本发明的范围内，本领域技术人员将想到的任何种类的服务器侧功能可以被用来实现用于web服务中介体的端口类型不可知的代理功能。
端口类型不可知的代理(212)可以被硬编码以专门作为端口类型不可知的代理而运行，或者可替代地，端口类型不可知的代理(212)可以根据配置参数(223)而模块化运行。可以提供配置参数以指示端口类型不可知的代理(212)是作为传统的中介体服务运行还是在端口类型不可知的模式下运行。这种配置参数有利地促进了高效的程序编码，特别包括可以在两个模式下使用的代码段的重用。支持程序代码的高效使用的另一配置参数是标识用于代理的绑定或“信道类型”的参数。如下面详细解释的那样，端口类型不可知的代理可以利用web服务支持的任何绑定(SOAP、MIME、GET/POST/HTTP等)而运行。端口类型不可知的代理可以被编码以利用任何绑定或信道类型来运行，并且随后利用下述参数进行配置，所述参数向代理建议其用于运行时操作的绑定或信道类型。此外，配置参数可以被提供来接通或关断将要求解析请求或响应消息的内容的代理中的中介体服务。这种参数可以有利地被用来优化性能，因为解析消息内容具有减慢中介体性能的趋势。许多端口类型不可知的代理和其它中介体服务可以在中介体(202)中同时运行，并且每个的名称可以作为配置参数被分配。消息处理机(handler)和过滤器可以在配置参数中被分配给代理。本段通过解释而非限制的方式描述了用于端口类型不可知的代理的若干配置参数。本领域技术人员所想到的任何配置参数的使用也在本发明的范围之内。
图2B描述了根据本发明实施例的实现SOAP-HTTP信道的示例性中介体(202)的框图的绘线图。如所述，对于具有SOAP绑定的请求能够将包括其参数数据的请求提供给端口类型不可知的代理(212)的入站引擎(208)可以被实现为使能SOAP的HTTP服务器。这种入站引擎可以被配置为具有用于代理的SOAPHandler对象(210)的多个引用，其中每个SOAPHandler对象(210)被配置为针对对代理的请求来提供某种数据处理任务。这种入站引擎典型地通过下述步骤运行在SOAPContext对象(209)中封装进入请求及其参数信息，将对SOAPContext对象的引用传送到为代理配置的每个SOAPHandler(210)，以及随后将SOAPContext(209)整体传送到代理(212)。在一般意义上，由端口类型不可知的代理来标识端点，但是，详细的实施级别可以在处理机中包括代理功能，如同对于SOAP的情形。即，进入引擎可以在SOAPContext中建立可以被设定到目标服务的端点的属性，对于SOAP/HTTP的情形是URL。在这样的实施例中，SOAPHandler对象(210)之一可以被有用地编程以从请求中提取参数信息，并且将它放入SOAPContext中的名称-值对中，从而代理可以使用它来标识支持所请求的web服务操作的目标服务(118)的端点。
可替代地，可以利用GET/HTTP而非SOAP来绑定进入请求。在这样的示例中，代理(图2A中的212)可以被实现为Java小服务程序。入站引擎(208)可以被实现为使能Java的HTTP服务器，该使能Java的HTTP服务器在HTTPServletRequest对象中封装包括其参数信息的请求，并且向代理提供对该HTTPServletRequest对象的引用。代理随后通过对HTTPServletRequest.getQueryString()的调用可以获得参数信息，其返回来自请求URL的查询串，即，请求URL中在问号之后的所有内容。在具有全部查询串之后，这种示例性代理被编程以从查询串中提取参数数据(即，在本示例中是“portType=A”)，并且使用如此提取的信息来标识支持所请求的web服务操作的目标服务(118)的端点。代理可以标识支持所请求的web服务操作的目标服务的端点的一种方法是从商务登记簿(211)(例如UDDI登记簿或ebXML登记簿)中检索端点描述。目标服务(118)典型地通过在商务登记簿(211)中登记它们来作出这样的描述，例如包括被表达为WSDL文档的描述。
在基于SOAP的web服务中，SOAP消息自身包含操作的名称和操作的参数；它们没有在端点URL中。中介体接收诸如portType参数的参数信息是有用的。该参数可以象portType的名称那样简单。如果是这种情形，则在服务器中(例如在处理机中，或者甚至在代理功能自身之中)运行的某种“商务逻辑”必须基于端口类型或其它参数信息来选择目标服务(118)的实际端点URL。参数信息甚至可以包括实际端点URL。在该情形下，“商务逻辑”可以最终发送请求到该URL。端口类型和端点URL两者都可以存在于参数信息中，并且“商务逻辑”随后可以尝试确定端点URL，并且如果没有发现更好的结果，则使用请求中的一个端点URL作为缺省结果。本发明优选地允许可以被商务逻辑控制的全部三种方案及其任意变体。总是可以存在帮助控制“商务逻辑”的其它参数。
尽管本说明书趋向于就SOAP/HTTP绑定以及有时就GET/POST/HTTP绑定来讨论示例性绑定，但是，这些示例性绑定的讨论是出于便于解释的目的而不是作为限制。根据本发明多种实施例的替代性示例性绑定包括MIME/SMTP(小型消息传输协议上的多部分因特网邮件扩展)和RMI/IIOP(公共对象请求调度程序体系结构的因特网ORB间协议上的Java远程方法调用)。实际上，任意Java类可以被视为web服务，其中利用原有Java调用作为访问协议，并且根据优选实施例，将由本领域技术人员想到的在端口类型不可知的代理中使用的任何其它绑定也在本发明的范围之内。
在图2A的示例性中介体(202)中，代理(212)是端口类型不可知的代理，该端口类型不可知的代理执行被设计用于请求者认证、消息确认、消息记录、消息报告服务等的任意中介体服务，标识出支持所请求的操作的目标服务(118)的端点，并且随后通过与绑定无关的接口(218)将请求发送到目标服务。如下面更加详细地解释的那样，与绑定无关的接口(218)是其使用形式不依赖于请求绑定的接口。
在图2A的示例性中介体(202)中，与绑定无关的接口(218)操作供应者(220)，供应者(220)随后调用出站引擎(222)，以将请求(106)转发给目标服务(118)。接口(218)能够以与绑定无关的的方式操作，因为它是由协议专用的供应者(220)中的代码所备份的。供应者(220)根据特定协议(SOAP、HTTP等)的细节来执行实际的消息交换。将执行实际数据通信的供应者与与绑定无关的接口去除耦合支持新供应者的动态登记，从而中介体可以提高其数据通信能力而不需要重新编译或重新部署。供应者可以被实现为对象，其通常由供应者的协议所支持的目标服务提供，并且对供应者的引用被动态安装在与绑定无关的接口中。出站引擎(222)是用于供应者(222)所实现的协议的实际数据通信引擎。当协议例如采用SOAP/HTTP时，出站引擎是SOAP/HTTP引擎，其能够向目标web服务发送SOAP/HTTP请求消息并从其接收SOAP/HTTP响应消息。当协议例如是HTTP时，出站引擎是HTTP数据通信客户模块，其与web浏览器的数据通信模块相类似。
为了提供其中介体服务，中介体有利地能够标识用于请求的端点。参考图3讨论了用于实现此操作的方法。图3描述了图示出用于web服务中介体的端口类型不可知的代理支持的方法的流程图，该方法包括在web服务中介体中接收(104)用于执行web服务操作的请求(106)，其中请求包括从其可以标识出支持所述操作的目标服务的端点的参数信息(107)。
这里又是这种用于SOAP-HTTP绑定的请求的示例POST/Channel/proxy portType=A HTTP/1.1Host:www.myIntermediary.comContent-Type:text/xml;eharset="utf-8"Content-Length:nnnnSOAPAction:"Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:myOp xmlns:m="Some-URI"></m:myOp></SOAP-ENV:Body></SOAP-ENV:Envelope>
该示例性POST消息包括从中介体请求“myOp”操作的SOAP包封。myOp操作、其端口类型及其端点在请求被接收之前对中介体来说是未知的。在该示例中，消息采用SOAP包封，并且从其可以标识出支持所述操作的目标服务的端点的参数信息(107)是HTTP参数“portType=A”。在该示例中，因为目标服务上的操作的名称已经在SOAP包封中被编码，所以要被添加的唯一参数数据是端口类型“A”，其是包括目标服务上的操作的端口类型。
图3的方法还包括根据参数数据标识出(108)支持所述操作的目标服务的端点(110)。在该SOAP-HTTP示例中，标识出(108)支持所述操作的目标服务的端点(110)是通过从商务登记簿(例如UDDI登记簿或ebXML登记簿)中检索端点描述而执行的。在该示例中，中介体从登记簿中检索到被描述为由SOAP-HTTP在网络地址http://www.myTarget.com/SOAP-HTTP/servlets/处绑定的端口类型A的端点。
图示的方法包括创建(112)用于执行目标服务上的操作的目标服务请求(114)。在该示例中，中介体被编程以创建作为使用目标服务上的端点的HTTP POST消息的目标服务请求。用于标识端点的参数数据被删除，并且请求被定向到用于处理SOAP消息的脚本，其自己将从SOAP包封中的操作名称中标识出操作。
所得的目标服务请求如下POST/SOAP-HTTP/servlets/QuoteServiceServlet HTTP/1.1Host:www.myTarget.comContent-Type:text/xml;charset="utf-8"Content-Length:nnnnSOAPAction:"Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:myOp xmlns:m="Some-URI"></m:myOp></SOAP-ENV:Body>
</SOAP-ENV:Envelope>
图3的方法还包括将目标服务请求(114)发送(116)到目标服务(118)。在该示例中，发送目标服务请求包括打开到http://www.myTarget.com/处的目标服务端点的TCP/IP连接，并且通过TCP/IP连接将HTTP POST消息发送到目标服务。
有用的是要注意，在本发明的至少某些实施例中，在诸如图3所示的端口类型不可知的代理支持的方法中，所创建并被发送到目标服务的目标服务请求带有在web服务中介体中接收到的请求的未经检查并且未经修改的消息内容。在上面讨论的示例中，中介体上的代理服务从参数数据“portType=A”标识出目标服务的端点，并且将消息重定向到如此标识出的端点，而完全没有接触、打开、检查、解析、或者以任何其它方式干扰消息主体，SOAP包封在将其从其请求者向其目标服务传送的整个过程中保持未被检查和未被改变。在该过程中，代理服务提供中介体服务、认证、管理报告、负载均衡、服务聚集等中的一个或多个。
作为进一步解释，示例性请求被提供用于GET/HTTP绑定，并且被定向到http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxy处的端点。示例性的进入请求消息具有这样的形式GET/servlets/proxy message=messageContentString&
operation=myOp&portType=A HTTP/1.1并且在URI空间中，示例性请求可以如下所示http://www.myIntermediary.com/servlets/proxy message=messageContentString&operation=myOp&portType=A在该示例中，消息采用被编码为名称-值对的经URI编码的查询数据“message=messageContentString”。消息内容是经URI编码的串。在该示例中，从其可以标识出支持操作的目标服务的端点的参数信息(107)是跟随在消息内容串之后的所有查询数据。在该示例中，查询数据包括目标服务上的操作的名称和端口类型“A”两者。
在该示例中，通过从商务登记簿(例如UDDI登记簿或ebXML登记簿)检索端点描述来执行标识(108)支持所述操作的目标服务的端点(110)。在该示例中，中介体从登记簿检索被描述为由GET/HTTP在网络地址http://www.myTarget.com处绑定的端口类型A的端点。
图3的方法还包括创建(112)用于执行目标服务上的操作的目标服务请求(114)。在该示例中，中介体被编程以通过链接用于目标服务请求的端点地址和操作名称及消息部分来创建作为HTTP GET消息的目标服务请求。所得的在URI空间中表达的目标服务请求是http://www.myTarget.com/servlets/myOp message=messageContentString图3的方法还包括将目标服务请求(114)发送(116)到目标服务(118)。在该示例中，发送目标服务请求包括打开到在http://www.myTarget.com/处的目标服务端点的TCP/IP连接以及发送HTTP GET消息GET/servlets/myOp message=messageContentString HTTP/1.1本领域技术人员想知道请求者如何知道向中介体发送用于目标服务上的操作的请求。答案是中介体或中介体的开发者对于请求者将web服务中介体的端点标识为支持目标服务上的操作的端点。将中介体的端点标识为支持目标服务上的操作的端点可以在WSDL文档中实现，WSDL文档被登记在商务目录中用以被请求者发现。可替代地，这种标识可以从中介体下载到请求者，或者甚至简单地通过电子邮件寄到请求者或请求者的管理员，用于由管理员安装在请求者的web服务配置数据中。
考虑其中目标服务由下述WSDL伪代码段描述的示例<definitions targetNamespace=…>
<message name="GetQuoteInput">…</message>
<message name="GetQuoteOutput">…</message>
<portType name="StockquotePT">…</portType>
<binding name="SOAPBinding"…>
<operation name="getQuote">…</operation>…</binding>
<service name="StockquoteService">
<port name="SOAPPort"binding="tns:SOAPBinding">
<soap:address location="http://myTargetService/soap/servlet/getQuote"/>
</port>
</service>
</definitions>
通过替换下述目标服务描述中的地址扩展元素的位置属性，用于该目标服务的中介体对于请求者可以将web服务中介体的端点标识为支持目标服务上的操作的端点<soap:address location="http://www.myIntermediary.com/Channel/SOAP/proxy portType=StockquotePT"/>
从而创建由下述段例示的WSDL文档<definitions targetNamespace=…>
<message name="GetQuoteInput">…</message>
<message name="GetQuoteOutput">…</message>
<portType name="StockquotePT">…</portType>
<binding name="SOAPBinding"…>
<operation name="getQuote">…</operation>…</binding>
<service name="portTypeAgnosticProxy">
<port name="intermediaryEndpoint"binding="SOAPBinding">
<soap:address location="http://myIntermediary.com/Channel/SOAP/proxy portType=StockquotePT"/>
</port>
</service>
</definitions>
其将web服务中介体的端点标识为支持目标服务上的“getQuote”操作的端点。通过登记簿、下载、电子邮件或本领域技术人员将想到的其它手段将该后一段例示的这类WSDL提供给请求者，这将对于请求者将web服务中介体的端点标识为支持目标服务上的操作的端点。
在图3的方法中，根据参数信息(107)标识出(108)支持所述操作的目标服务的端点通常可以包括标识不只一个目标服务的端点，而是标识出两个或更多支持所述操作的目标服务的端点。考虑下述的示例，其中根据本发明方法实施例的端口类型不可知的代理接收作为参数信息(107)的操作的端口类型，利用该端口类型作为查询参数查询商务登记簿，并且从而标识出支持所述操作的目标服务的两个或更多端点。例如通过利用端口类型查询UDDI登记簿并且作为响应接收描述用于该端口类型的目标服务的两个或更多WSDL文档，可以执行对两个或多个端点的这种标识。
当如此标识出两个或更多端点时，根据本发明实施例用于web服务中介体的端口类型不可知的代理支持的方法典型地包括根据选择规则选择端点之一。在普通的情形中，选择规则可以是选择如此标识出的第一个端点并且忽略其它端点。选择规则可以更加复杂，例如包括用于负载均衡的选择规则。用于负载均衡的规则可以通过使用类似于表1所示的数据结构来实现。
表001
表1中的每行代表中介体和目标服务之间的web服务数据通信中的请求-响应往返行程的等待时间测量。表1提供了用于请求与响应的每次往返的端口类型列和端点URI列。发送时间列记录请求消息从中介体被发送到用于端口类型操作的目标服务上的端点的时间。接收时间列记录从目标服务接收到相应的响应消息的时间。行程等待时间是接收时间和发送时间之间的差。累积等待时间是表中表示的每个端点的行程等待时间的连续和。利用类似于表1的结构，当对于请求不只一个端点被标识出时使用的选择规则可以被实现为下述的示例性规则.随着更多对于相同端口类型中的操作的请求到达中介体中，轮流使用不只一个标识出的端点中的每个一次，.记录用于每个这种使用的等待时间数据，.对于对相同端口类型的操作的后续请求，从等待时间表中选择具有最低累积等待时间的端点，将请求发送到该端点，并且在消息被发送到目标服务且当在中介体中接收到相应的响应时，记录相关的等待时间数据。
表1中的示例性数据示出了最近对于端口类型A发送到两个端点(在URI http://www.ibm.com/a TargetService处的第一端点和在URIhttp://www.ibm.com/another TargetService处的第二端点)的请求的累积等待时间。第一端点具有250微秒的累积请求等待时间，而第二端点具有100微秒的累积请求等待时间。通过使用上述的示例性选择规则，当前对于端口类型A上的操作的请求将被路由到第二端点，其是处于URIhttp://www.ibm.com/another TargetService处的端点。
在图3的方法中，创建(112)用于执行目标服务上的操作的目标服务请求(114)可以通过下述步骤而被执行以在与绑定无关的接口中有用的数据结构编写请求并且调用与绑定无关的接口，将请求作为调用参数传送。类似地，将目标服务请求(114)发送(116)到目标服务包括调用与绑定无关的接口中的一个或多个成员方法。
与绑定无关的接口是这样的一种接口，其中接口的使用不依赖于请求或消息绑定。即，用来实现接口以及通过接口执行数据通信的数据结构和调用方法不依赖于消息中使用的数据编码的类型，也不依赖于用于消息的数据通信协议。根据本发明实施例的中介体的端口类型不可知的代理的开发者通常将构造他们自有的与绑定无关的接口。然而，存在用于与绑定无关的接口的开放标准，被称为“WSIF”(web服务调用框架)。WSIF现在作为Apache Software Foundation的web服务项目的一部分而被支持。
与绑定无关的接口的使用提供了本发明的实施例的优点。SOAP-HTTP绑定在现有技术中是如此常用，以至于使用者和开发者有时忘记了存在其它的绑定。这导致在不是不可以使用其它绑定或经修改而使用其它绑定的情况下，系统的开发很困难。然而，随着web服务的增长，其它绑定将变得更加有用并且更常见。而且，使用用于本发明实施例的后端的与绑定无关的接口还意味着可以在运行时确定可用的绑定，从而提供灵活、强大并且更为通用的web服务中介体。
实现与绑定无关的接口的一种途径是提供能够在给定端口类型和端点的情况下调用目标服务中的服务的端点对象。提供这种端点对象的一种途径是使用类似于下面伪代码段中示出的端点工厂(factory)
//端点工厂类//定义用于创建端点对象的用参数表示的工厂方法//class EndpointFactory{public static Endpoint createEndpointObject(portType,networkAddress){//建立对于新的端点对象的引用Endpoint anEndpoint=null;
if(portType==“A”&&networkAddress==“www.abc.com”)anEndpoint=new Endpoint1;
if(portType==“B”&&networkAddress==“www.def.com”)anEndpoint=new Endpoint2;
if(portType==“C”&&networkAddress==“www.ghi.com”)anEndpoint=new Endpoint3;
…if(portType==“LAST” && networkAddress ==“www.lastSupported.com”)anEndpoint=new Endpoint465;
if(anEndpoint==null)reportError();
else return anEndpoint;
}//结束createEndpointObject()}//结束类EndpointFactory端点类Endpoint1、Endpoint2和Endpoint3等是继承抽象端点类(或者将其实现为接口)的具体类，抽象端点类提供用于创建消息对象以包含消息部分的成员方法。这样的与绑定无关的接口中的这种端点因子和其它元素可以被用来执行下述步骤创建(112)目标服务请求(114)以及将目标服务请求(114)发送(116)到目标服务，如下面的伪代码段所示//从端点工厂获得端点对象Endpoint ep = endPointFactory.createEndPoint(portType,networkAddress);
//准备输入消息Message input=ep.createInputMessage();
//使用消息存取器功能来插入消息内容input.setPart(“symbol”,“IBM”);
//准备用于响应值的占位符Message output=ep.createOutputMessage();
//执行操作ep.executeRequestResponseOperation(“getQuote”,input,output);
//返回结果return output;
该示例性伪代码段在给定端点的端口类型和网络地址的条件下，调用端点工厂来创建端点对象。该段随后通过将消息部分装入端点对象来创建目标服务请求，并且通过调用成员方法executeRequestResponseOperation()将目标服务请求发送到目标服务。图3的方法包括在中介体中接收(120)来自目标服务的响应(122)；根据来自目标服务的响应(122)在中介体中创建(124)来自中介体的响应(126)；以及将来自中介体的响应(126)返回(128)到请求客户。在该示例性伪代码段中，接收(120)来自目标服务的响应(122)并创建(124)来自中介体的响应(126)的步骤是由对executeRequestResponseOperation()的调用来实现的。该调用典型为阻塞调用，其等待来自目标服务的响应，并且通过对“output”的消息引用而使响应可用。
上面的示例性伪代码段图示了利用被称为端点的端口来对与绑定无关的接口的使用。然而，WSIF接口语法在涉及端点时使用术语“端口”。因此，作为关于与绑定无关的接口的使用的进一步解释，提供了更为符合WSIF标准的示例性伪代码段。在该示例中，“端口”被用来指“端点”，并且为了解释的一致性，工厂的名称被变为“portFactory”。
//从工厂获得端口(端点)WSIFPort port=PortFactory.getPort(portType,networkAddress);
//准备输入消息WSIFMessage input=port.createInputMessage();
//插入消息内容input.setPart(“symbol”,new WSIFJavaPart(String.class,symbol));
//准备用于响应值的占位符WSIFMessage output=port.createOutputMessage();
//执行操作port.executeRequestResponseOperation(“getQuote”,input,output,null);
//提取并返回结果return output;
尽管本说明书主要就处理从请求者到目标服务的请求而讨论了web服务中介体中的端口类型不可知的代理支持的示例性方法，但是有用的是要注意，根据本发明实施例的中介体典型地还能够处理从目标服务通过中介体返回到初始请求者的响应消息。图3的方法例如包括在中介体中接收(120)来自目标服务的响应(122)；根据来自目标服务的响应(122)在中介体中创建(124)来自中介体的响应(126)；以及将来自中介体的响应(126)返回(128)到请求客户。
图4描述了图示出用于web服务中介体的端口类型不可知的代理支持的方法的流程图，该方法包括在web服务中介体中接收(304)用于执行web服务操作的请求(106)，其中所述请求包括从其可以标识出支持所述操作的目标服务的端点的参数信息(107)。
这里又是这种用于SOAP-HTTP绑定的请求的示例POST/Channel/proxy portType=A&synchRespReqd=True HTTP/1.1
Host:www.myIntermediary.comContent-Type:text/xml;charset="utf-8"Content-Length:nnnnSOAPAction:"Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:myOp xmlns:m="Some-URI"></m:myOp></SOAP-ENV:Body></SOAP-ENV:Envelope>
该示例性POST消息包括从中介体请求“myOp”操作的SOAP包封。myOp操作、其端口类型及其端点在请求被接收之前对中介体来说都是未知的。在该示例中，消息采用SOAP包封，并且从其可以标识出支持所述操作的目标服务的端点的参数信息(107)是HTTP参数“portType=A”。在该示例中，因为目标服务上的操作的名称已经在SOAP包封中被编码，所以要被添加的唯一参数数据是端口类型“A”，其是包括目标服务上的操作的端口类型。
图4的方法还包括根据参数数据标识出(308)支持所述操作的目标服务的端点(110)。在该SOAP-HTTP示例中，标识出(308)支持所述操作的目标服务的端点(110)是通过从商务登记簿(例如UDDI登记簿或ebXML登记簿)中检索端点描述而执行的。在该示例中，中介体从登记簿中检索到被描述为由SOAP-HTTP在网络地址http://www.myTarget.com/SOAP-HTTP/servlets/处绑定的端口类型A的端点。
图4中图示的方法还包括确定(350)请求(106)是否要求同步响应。确定(350)请求(106)是否要求同步响应可以通过检查接收到的请求消息的第一行中的查询数据来执行。在上面描述的示例性POST消息中，其第一行中的查询数据是“？”和HTTP版本代码之间的所有数据，即portType=A&synchRespReqd=True在该示例中，“synchRespReqd=True”由中介体采用以表示要求同步响应。类似地，“synchRespReqd=False”可以指示不要求同步响应。当然，这些只是示例性的编码，而不是对本发明的限制。根据优选实施例，任何用于在参数信息内对是否要求来自中介体的同步响应的指示的编码的装置都在本发明的范围之内。在该示例中，确定(350)请求是否要求同步响应是通过根据参数信息(107)做出该确定而执行的，参数信息是名称-值对“synchRespReqd=True”。
图示的方法包括创建(312)用于执行目标服务上的操作的目标服务请求(114)。在该示例中，中介体被编程以创建作为使用目标服务上的端点的HTTP POST消息的目标服务请求。更具体地说，下面的POST消息代表用于所请求的web服务操作的输入消息或输入数据的示例。参数数据被删除，用于标识端点的参数数据以及用于确定是否要求同步响应的参数数据被要求，并且请求被定向到用于处理SOAP消息的脚本、小服务程序、或其它功能，其自己将从SOAP包封中的操作名称中标识出操作。
所得的目标服务请求如下POST/SOAP-HTTP/servlets/QuoteServiceServlet HTTP/1.1Host:www.myTarget.comContent-Type:text/xml;charset="utf-8"Content-Length:nnnnSOAPAction:"Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:myOp xmlns:m="Some-URI">
</m:myOp>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
在图4的方法中，创建(312)用于执行目标服务上的操作的目标服务请求(114)还可以包括根据对请求是否要求同步响应的确定(152)来创建(312)目标服务请求(114)。就像中介体可以创建带有用于所请求的web服务操作的输入数据的输入消息一样，中介体也可以创建输出消息。这种输出消息典型地是占位对象，用于存储并传输来自目标服务的响应消息。用于为要求同步响应的请求创建响应消息对象的示例性方法是让中介体创建适当类的对象，使其为空，以及将对其的引用作为参数传送到对下游接口(例如供应者或出站引擎，图2A和2B上的标号(220)和(222))的一个或多个调用中，所述一个或多个调用用于将请求传输到目标服务。为不要求同步响应的请求创建响应消息对象的示例性方法是让中介体将空引用(不仅仅是对空输出对象的引用，而是完全空引用)作为参数传送到对下游接口的一个或多个调用中，所述一个或多个调用用于将请求传输到目标服务。在这样的实施例中，下游接口被编程以解释这种空引用，作为在返回对其调用者的控制之前只等待“确认”的指示。
图4的方法还包括将目标服务请求(114)发送(3l6)到目标服务(118)。在该示例中，发送目标服务请求包括打开到http://www.myTarget.com/处的目标服务端点的TCP/IP连接，并且通过TCP/IP连接将HTTP POST消息发送到目标服务。
有用的是要注意，在本发明的至少某些实施例中，在诸如图4所示的端口类型不可知的代理支持的方法中，所创建并被发送到目标服务的目标服务请求带有在web服务中介体中接收到的请求的未经检查并且未经修改的消息内容。在上面讨论的示例中，中介体上的代理服务从参数数据“portType=A”标识出目标服务的端点，并且将消息重定向到如此标识出的端点，而完全没有接触、打开、检查、解析、或者以任何其它方式干扰消息主体，SOAP包封在将其从其请求者向其目标服务传送的整个过程中保持未被检查和未被改变。在该过程中，代理服务提供中介体服务、认证、管理报告、负载均衡、服务聚集等中的一个或多个。
作为进一步解释，示例性请求被提供用于GET/HTTP绑定，并且被定向到http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxy处的端点。示例性的进入请求消息具有这样的形式GET/servlets/proxy message=messageContentString&
operation=myOp&portType=A HTTP/1.1并且在URI空间中，示例性请求可以如下所示http://www.myIntermediary.com/servlets/proxy message=messageContentString&operation=myOp&portType=A在该示例中，消息采用被编码为名称-值对的经URI编码的查询数据“message=messageContentString”。消息内容是经URI编码的串。在该示例中，从其可以标识出支持操作的目标服务的端点的参数信息(107)是跟随在消息内容串之后的所有查询数据。在该示例中，查询数据包括目标服务上的操作的名称和端口类型“A”两者。
在该示例中，通过从商务登记簿(例如UDDI登记簿或ebXML登记簿)检索端点描述来执行标识出支持所述操作的目标服务的端点(110)。在该示例中，中介体从登记簿检索被描述为由GET/HTTP在网络地址http://www.myTarget.com处绑定的端口类型A的端点。
图4的方法还包括创建(312)用于执行目标服务上的操作的目标服务请求(114)。在该示例中，中介体被编程以通过链接用于目标服务请求的端点地址和操作名称及消息部分来创建作为HTTP GET消息的目标服务请求。所得的在URI空间中表达的目标服务请求是http://www.myTarget.com/servlets/myOp message=messageContentString如前所述，图4的方法还包括将目标服务请求(114)发送(316)到目标服务(118)。在该示例中，发送目标服务请求包括打开到在http://www.myTarget.com/处的目标服务端点的TCP/IP连接以及发送HTTP GET消息GET/servlets/myOp message=messageContentString HTTP/1.1图4的方法还包括如果请求要求同步响应(360)则等待(361)来自目标服务的响应。图5描述了图示出等待(361)来自目标服务的响应的方法的流程图，该方法包括在中介体中同步接收(320)来自目标服务的响应(122)；根据来自目标服务的响应在中介体中创建(324)来自中介体的响应(126)；以及将来自中介体的响应(126)返回(328)到请求者(102)。在图5的方法中，在中介体中同步接收(320)来自目标服务的响应可以通过在中介体和目标服务之间的数据通信连接上调用阻塞接收功能来执行。
下面的伪代码段是用于将请求从中介体传送到目标服务并且如果请求要求同步响应则等待来自目标服务的响应的HTTP绑定的示例。下述段例示了用于HTTP绑定的客户操作，诸如根据本发明实施例在web服务中介体的出站引擎中或通过web服务中介体的供应者(图2中的220、222)经常提供的客户操作import java.io.*;
import java.net.*;
BufferedReader in=null;
URL url=new URL(targetURL);
URLConnection connection=(HttpURLConnection)url.openConnection();
BufferedWriter out=new BufferedWriter(new OutputStreamWriter(connection.getOutputStream()));
BufferedReader in=new BufferedReader(new InputStreamReader(connection.getInputStream()));
out.println(request);
if(synchRespReqd==TRUE){Message responseMessage=in.readLine();
Return responseMessage;
}该示例性伪代码段创建了Java URL对象，并且使用URL对象打开到被标识为具有网络地址“targetURL”的目标服务的TCP/IP连接(被称为“connection”)。该段还打开被称为“out”的连接上的缓冲流以及被称为“in”的连接上的输入流。该段通过所述连接将请求作为“out.println(request)”传输，并且随后，如果要求同步响应，则进行阻塞调用以通过相同连接接收响应消息“Message responseMessage=in.readLine()”，并且将响应消息返回到其调用者。该示例用于HTTP绑定。
作为进一步解释，下面提供了用于“JMS”绑定的进一步示例，JMS即为到Java消息服务的绑定。JMS提供两个消息传送“域”，一个用于点对点消息传送，一个用于发布-订阅消息传送。该示例讨论中介体和目标服务之间使用JMS消息队列的点对点消息传送。在JMS点对点消息传送过程中，由JMS“连接”对象封装的诸如套接字(socket)的数据通信连接。JMS连接是通过被称为“连接工厂”的管理对象创建的。JMS连接被用来创建一个或多个JMS“会话”。会话是用于产生并消费消息的单线程语境。会话被用来创建消息产生者、消息消费者以及消息。消息产生者是用来将消息发送到队列的对象。消息产生者的点对点形式实现了JMS“queueSender”接口，其包括send()方法。消息消费者是用来从队列接收消息的对象。消息产生者的点对点形式实现了JMS“queueReceiver”接口，其包括可调用具有或不具有超时周期的阻塞receive()方法。
下述的伪代码段是将请求从中介体发送到目标服务并且如果请求要求同步响应则等待来自目标服务的响应的JMS绑定的示例。
//获得连接
QueueConnection queueConnection=queueConnectionFactory.createQueueConnection();
//使用连接来建立会话//“false”参数指没有事务，且AUTO_ACK为开QueueSession queueSession=queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
//创建发送者并将请求通过JMS队列//从中介体发送到目标服务QueueSender queueSender=queueSession.createSender(myQueue);
queueSender.send(requestMessage);
//如果要求同步响应，则创建接收者，//并在接收者上发送阻塞receive()if(synchRespReqd==TRUE){QueueReceiver queueReceiver =queueSession.createReceiver(myQueue);
Message responseMessage=queueReceiver.receive();
return responseMessage;
}该示例性JMS段创建被称为queueConnection的连接，创建被称为queueSession的会话，创建被称为queueSender的发送者，将请求消息通过JMS队列发送到目标服务，以及如果要求同步响应，则创建被称为queueReceiver的接收者，并且发送queueReceiver上的阻塞receive()以等待响应消息。
如果请求不要求(362)同步响应，则根据本发明实施例的用于web服务中介体的端口类型不可知的代理支持的方法可以包括除将请求发送到目标服务外绝对不做任何事情。即，如果请求不要求(362)同步响应，则根据下述优选实施例它将在本发明的范围之内，所述优选实施例关于确认、异步响应等不做任何事情。可替代地，如图4所示，根据本发明第二实施例的方法可以包括从目标服务(156)接收(354)目标服务请求的确认，并且将确认(156)返回(358)给请求者(102)而不等待响应消息。
这里是将确认返回给请求者而不等待响应消息的示例性伪代码段import java.io.*;
import java.net.*;
URL url=new URL(targetURL);
HTTPURLConnectionconnection =(HttpURLConnection)url.openConnection();
BufferedWriter out=new BufferedWriter(new OutputStreamWriter(connection.getOutputStream()));
BufferedReader in=new BufferedReader(new InputStreamReader(connection.getInputStream()));
out.println(request);
int acknowledgment=connection.getResponseCode();
if(acknowledgment==200)return acknowledgement;
else return ERROR;
该示例性伪代码段创建Java URL对象，并且以HTTPURLConnection对象的形式，为URL对象打开到被标识为具有网络地址“targetURL”的目标服务的TCP/IP连接(被称为“connection”)。该段还打开被称为“out”的连接上的缓冲输出流以及被称为“in”的套接字上的输入流。该段通过连接将请求作为“out.println(request)”传输，并且随后进行阻塞调用以通过相同连接接收确认“int acknowledgment=connection.getResponseCode()”。该段将确认返回给其调用者(本示例中的HTTP响应代码“200”)或者返回错误消息。所述确认是来自接收到请求的目标服务的程序性确认。该段不等待对请求的实质响应。
上面的示例性伪代码段仅仅是将请求从中介体传送到目标服务并且提供确认而不等待实质响应消息的示例。该段例示了用于HTTP绑定的客户操作，诸如根据本发明实施例在web服务中介体的出站引擎中或通过web服务中介体的供应者(图2中的220、222)经常提供的客户操作。
本领域技术人员现在想知道请求者如何知道向中介体发送用于目标服务上的操作的请求。答案是中介体或中介体的开发者对于请求者将web服务中介体的端点标识为支持目标服务上的操作的端点。将中介体的端点标识为支持目标服务上的操作的端点可以在WSDL文档中实现，WSDL文档被登记在商务目录中用以被请求者发现。可替代地，这种标识可以从中介体下载到请求者，或者甚至简单地通过电子邮件寄到请求者或请求者的管理员，用于由管理员安装在请求者的web服务配置数据中。
考虑其中目标服务由下述WSDL伪代码段描述的示例<definitions targetNamespace=…>
<message name="GetQuoteInput">…</message>
<message name="GetQuoteOutput">…</message>
<portType name="StockquotePT">…</portType>
<binding name="SOAPBinding"…>
<operation name="getQuote">…</operation>…</binding>
<service name="StockquoteService">
<port name="SOAPPort"binding="tns:SOAPBinding">
<soap:address location="http://myTargetService/soap/servlet/getQuote"/>
</port>
</service>
</definitions>
通过替换下述目标服务描述中的地址扩展元素的位置属性，用于该目标服务的中介体对于请求者可以将web服务中介体的端点标识为支持目标服务上的操作的端点
<soap:address location="http://www.myIntermediary.com/Channel/SOAP/proxy portType=StockquotePT"/>
从而创建由下述段例示的WSDL文档<definitions targetNamespace=…>
<message name="GetQuoteInput">…</message>
<message name="GetQuoteOutput">…</message>
<portType name="StockquotePT">…</portType>
<binding name="SOAPBinding"…>
<operation name="getQuote">…</operation>…</binding>
<service name="portTypeAgnosticProxy">
<port name="intermediaryEndpoint"binding="SOAPBinding">
<soap:address location="http://myIntermediary.com/Channel/SOAP/proxy portType=StockquotePT"/>
</port>
</service>
</definitions>
其将web服务中介体的端点标识为支持目标服务上的“getQuote”操作的端点。通过登记簿、下载、电子邮件或本领域技术人员将想到的其它手段将该后一段例示的这类WSDL提供给请求者，这将对于请求者将web服务中介体的端点标识为支持目标服务上的操作的端点。
在图4的方法中，根据参数信息(107)标识出(308)支持所述操作的目标服务的端点通常可以包括标识不只一个目标服务的端点，而是标识出两个或更多支持所述操作的目标服务的端点。考虑下述的示例，其中根据本发明方法实施例的端口类型不可知的代理接收作为参数信息(107)的操作的端口类型，利用该端口类型作为查询参数查询商务登记簿，并且从而标识出支持所述操作的目标服务的两个或更多端点。例如通过利用端口类型查询UDDI登记簿并且作为响应接收描述用于该端口类型的目标服务的两个或更多WSDL文档，可以执行对两个或多个端点的这种标识。
当如此标识出两个或更多端点时，根据本发明实施例用于web服务中介体的端口类型不可知的代理支持的方法典型地包括根据选择规则选择端点之一。在普通的情形中，选择规则可以是选择如此标识出的第一个端点并且忽略其它端点。选择规则可以更加复杂，例如包括用于负载均衡的选择规则。用于负载均衡的规则可以通过使用类似于表1所示的数据结构来实现。
表002
表1中的每行代表中介体和目标服务之间的web服务数据通信中的请求-响应往返行程的等待时间测量。表1提供了用于请求与响应的每次往返的端口类型列和端点URI列。发送时间列记录请求消息从中介体被发送到用于端口类型操作的目标服务上的端点的时间。接收时间列记录从目标服务接收到相应的响应消息的时间。行程等待时间是接收时间和发送时间之间的差。累积等待时间是表中表示的每个端点的行程等待时间的连续和。利用类似于表1的结构，当对于请求不只一个端点被标识出时使用的选择规则可以被实现为下述的示例性规则.随着更多对于相同端口类型中的操作的请求到达中介体中，轮流使用不只一个标识出的端点中的每个一次，.记录用于每个这种使用的等待时间数据，.对于对相同端口类型的操作的后续请求，从等待时间表中选择具有最低累积等待时间的端点，将请求发送到该端点，并且在消息被发送到目标服务且当在中介体中接收到相应的响应时，记录相关的等待时间数据。
表1中的示例性数据示出了最近为端口类型A发送到两个端点(在URI http://www.ibm.com/aTargetService处的第一端点和在URIhttp://www.ibm.com/anotherTargetService处的第二端点)的请求的累积等待时间。第一端点具有250微秒的累积请求等待时间，而第二端点具有100微秒的累积请求等待时间。通过使用上述的示例性选择规则，当前对于端口类型A上的操作的请求将被路由到第二端点，其是处于URIhttp://www.ibm.com/anotherTargetService处的端点。
在图4的方法中，创建(312)用于执行目标服务上的操作的目标服务请求(114)可以通过下述步骤而被执行以在与绑定无关的接口中有用的数据结构编写请求并且调用与绑定无关的接口，将请求作为调用参数传送。类似地，将目标服务请求(114)发送(316)到目标服务包括调用与绑定无关的接口中的一个或多个成员方法。
与绑定无关的接口是这样的一种接口，其中接口的使用不依赖于请求或消息绑定。即，用来实现接口以及通过接口执行数据通信的数据结构和调用方法不依赖于消息中使用的数据编码的类型，也不依赖于用于消息的数据通信协议。根据本发明实施例的中介体的端口类型不可知的代理的开发者通常将构造他们自有的与绑定无关的接口。然而，存在用于与绑定无关的接口的开放标准，被称为“WSIF”(web服务调用框架)。WSIF现在作为Apache Software Foundation的web服务项目的一部分而被支持。
与绑定无关的接口的使用提供了本发明的实施例的优点。SOAP-HTTP绑定在现有技术中是如此常用，以至于使用者和开发者有时忘记了存在其它的绑定。这导致在不是不可以使用其它绑定或经修改而使用其它绑定的情况下，系统的开发很困难。然而，随着web服务的增长，其它绑定将变得更加有用并且更常见。而且，使用用于本发明实施例的后端的与绑定无关的接口还意味着可以在运行时确定可用的绑定，从而提供灵活、强大并且更为通用的web服务中介体。
实现与绑定无关的接口的一种途径是提供能够在给定端口类型和端点的情况下调用目标服务中的服务的端点对象。提供这种端点对象的一种途径是使用类似于下面伪代码段中示出的端点工厂//端点工厂类//定义用于创建端点对象的用参数表示的工厂方法//class EndpointFactory{public staticEndpointcreateEndpointObject(portType,networkAddress){//建立对于新的端点对象的引用Endpoint anEndpoint=null;
if(portType==“A”&&networkAddress==“www.abc.com”)anEndpoint=new Endpoint1;
if(portType==“B”&&networkAddress==“www.def.com”)anEndpoint=new Endpoint2;
if(portType==“C”&&networkAddress==“www.ghi.com”)anEndpoint=new Endpoint3;
…if(portType == “LAST” && networkAddress ==“www.lastSupported.com”)anEndpoint=new Endpoint465;
if(anEndpoint==null)reportError();
else return anEndpoint;
}//结束createEndpointObject()}//结束类EndpointFactory端点类Endpoint1、Endpoint2和Endpoint3等是继承抽象端点类(或者将其实现为接口)的具体类，抽象端点类提供用于创建消息对象以包含消息部分的成员方法。这样的与绑定无关的接口中的这种端点因子和其它元素可以被用来执行下述步骤创建(312)目标服务请求(114)以及将目标服务请求(114)发送(316)到目标服务，如下面的伪代码段所示//从端点工厂获得端点对象Endpointep=endPointFactory.createEndPoint(portType,networkAddress);
//准备输入消息Message input=ep.createInputMessage();
//使用消息存取器功能来插入消息内容input.setPart(“symbol”,“IBM”);
//准备用于响应值的占位符Message output=null;
If(synchRespReqd==TRUE)output=ep.createOutputMessage();
//执行操作
ep.executeRequestResponseOperation(“getQuote”,input,output);
//返回结果If(synchRespReqd==TRUE) return output;
else return ACK;
该示例性伪代码段在给定端点的端口类型和网络地址的条件下，调用端点工厂来创建端点对象。该段随后通过将消息部分装入端点对象来创建目标服务请求，并且通过调用成员方法executeRequestResponseOperation()将目标服务请求发送到目标服务。如果请求要求同步响应，则图5的方法包括在中介体中接收(320)来自目标服务的响应(122)；根据来自目标服务的响应(122)在中介体中创建(324)来自中介体的响应(126)；以及将来自中介体的响应(126)返回(328)到请求客户。
在该示例性伪代码段中，接收(320)来自目标服务的响应(122)并创建(324)来自中介体的响应(126)的步骤是由对executeRequestResponseOperation()的调用来实现的。在该示例中，如果请求要求同步响应，则对输出消息的引用值为空。这类实施例中的空“输出”参数由供应者(图2A中的220)采用以表示不要求同步响应。供应者进而将请求发送到目标服务并且立即返回而不等待响应。
类似地，如果请求要求同步响应，则对响应消息“输出”的引用值通过output＝ep.createOutputMessage()被设置为非空。供应者(图2A中的220)采用下述调用ep.executeRequestResponseOperation(“getQuote”,input,output)中的响应消息(这里称为“output”)的参数引用为非空的事实，以表示要求同步响应。这种供应者随后被编程以在其出站引擎(图2中的222)上实施阻塞接收调用，并且等待来自目标服务的相应响应消息。对于图5的方法，该段随后代表根据对请求是否要求同步响应的确定(152)来创建(312)用于执行目标服务上的操作的目标服务请求(114)的示例性方法。
上面的示例性伪代码段图示了利用被称为端点的端口来对与绑定无关的接口的使用。然而，WSIF接口语法在涉及端点时使用术语“端口”。因此，作为关于与绑定无关的接口的使用的进一步解释，提供了更为符合WSIF标准的示例性伪代码段。在该示例中，“端口”被用来指“端点”，并且为了解释的一致性，工厂的名称被变为“portFactory”。
//从工厂获得端口(端点)WSIFPort port=PortFactory.getPort(portType,networkAddress);
//准备输入消息WSIFMessage input=port.createInputMessage();
//插入消息内容input.setPart(“symbol”,new WSIFJavaPart(String.class,symbol));
//准备用于响应值的占位符WSIFMessage output=null;
if(synchRespReqd==TRUE)output=port.createOutputMessage();
//执行操作port.executeRequestResponseOperation(“getQuote”,input,output,null);
//提取并返回结果if(synchRespReqd==TRUE)return output;
else return ACK;
尽管本说明书主要就处理从请求者到目标服务的请求而讨论了web服务中介体中的端口类型不可知的代理支持的示例性方法，但是有用的是要注意，根据本发明实施例的中介体典型地还能够处理从目标服务通过中介体返回到初始请求者的响应消息。图5的方法例如包括当请求要求同步响应时，在中介体中接收(320)来自目标服务的响应(122)；根据来自目标服务的响应(122)在中介体中创建(324)来自中介体的响应(126)；以及将来自中介体的响应(126)返回(328)到请求客户。
从前面的说明中将理解，在不背离本发明真实精神的条件下，可以对本发明的多种实施例进行修改和改变。本说明书中的说明仅仅是出于例示的目的，而不应被理解为限制意义。本发明的范围仅由所附权利要求的语言所限制。
权利要求
1.一种用于web服务中介体的端口类型不可知的代理支持的方法，该方法包括在web服务中介体中接收对执行web服务操作的请求，其中所述请求包括可以从其标识出支持所述操作的目标服务的端点的参数信息；根据所述参数数据标识出支持所述操作的目标服务的端点；创建用于执行所述目标服务上的所述操作的目标服务请求；以及将所述目标服务请求发送到所述目标服务。
2.如权利要求1所述的方法，还包括确定所述请求是否要求同步响应；以及如果所述请求要求同步响应，则等待来自所述目标服务的响应。
3.如权利要求2所述的方法，其中确定所述请求是否要求同步响应包括根据所述参数信息确定所述请求是否要求同步响应。
4.如权利要求2或3所述的方法，其中创建用于执行所述目标服务上的所述操作的目标服务请求还包括根据对所述请求是否要求同步响应的确定来创建所述目标服务请求。
5.如权利要求2、3或4所述的方法，其中所述请求不要求同步响应，并且所述方法还包括从所述目标服务接收目标服务请求的确认；以及在不等待响应消息的情况下将所述确认返回到请求者。
6.如权利要求2、3、4或5所述的方法，其中等待来自所述目标服务的响应还包括在所述中介体中同步接收来自所述目标服务的响应；根据来自所述目标服务的响应在所述中介体中创建来自所述中介体的响应；以及将来自所述中介体的响应返回到请求者。
7.如权利要求6所述的方法，其中在所述中介体中同步接收来自所述目标服务的响应还包括在所述中介体和所述目标服务之间的数据通信连接上调用阻塞接收功能。
8.如前面任何一个权利要求所述的方法，其中所创建并被发送到所述目标服务的目标服务请求带有在所述web服务中介体中接收到的请求的未经检查和未经修改的消息内容。
9.如前面任何一个权利要求所述的方法，还包括对于请求者将所述web服务中介体的端点标识为支持所述操作的端点。
10.如前面任何一个权利要求所述的方法，其中所述参数信息包括用于所述操作的端口类型。
11.如前面任何一个权利要求所述的方法，其中根据所述参数信息标识出支持所述操作的目标服务的端点还包括根据所述参数信息标识出支持所述操作的目标服务的多个端点；以及根据选择规则从所述多个端点中选择一个端点。
12.如权利要求11所述的方法，其中所述参数信息包括用于所述操作的端口类型，并且根据所述参数信息标识出支持所述操作的目标服务的多个端点包括根据所述端口类型从登记簿中标识出用于所述端口类型的多个目标服务。
13.如权利要求11或12所述的方法，其中从所述多个端点中选择一个端点还包括根据用于在目标服务之间进行负载均衡的选择规则，从所述多个端点中选择一个端点。
14.如前面任何一个权利要求所述的方法，其中创建用于执行所述目标服务上的操作的目标服务请求包括以在与绑定无关的接口中有用的数据结构编写所述请求；以及调用所述与绑定无关的接口，将所述请求作为调用参数传送。
15.如前面任何一个权利要求所述的方法，其中将所述目标服务请求发送到所述目标服务包括调用与绑定无关的接口中的一个或多个成员方法。
16.如前面任何一个权利要求所述的方法，还包括在所述中介体中接收来自所述目标服务的响应；根据来自所述目标服务的响应，在所述中介体中创建来自所述中介体的响应；以及将来自所述中介体的响应返回到请求客户。
17.一种用于web服务中介体的端口类型不可知的代理支持的系统，该系统包括用于在web服务中介体中接收对执行web服务操作的请求的装置，其中所述请求包括可以从其标识出支持所述操作的目标服务的端点的参数信息；用于根据所述参数数据标识出支持所述操作的目标服务的端点的装置；用于创建用于执行所述目标服务上的所述操作的目标服务请求的装置；以及用于将所述目标服务请求发送到所述目标服务的装置。
18.如权利要求17所述的系统，包括用于确定所述请求是否要求同步响应的装置；以及用于如果所述请求要求同步响应则等待来自所述目标服务的响应的装置。
19.如权利要求18所述的系统，其中用于确定所述请求是否要求同步响应的装置包括用于根据所述参数信息确定所述请求是否要求同步响应的装置。
20.如权利要求18或19所述的系统，其中用于创建用于执行所述目标服务上的所述操作的目标服务请求的装置还包括用于根据对所述请求是否要求同步响应的确定来创建所述目标服务请求的装置。
21.如权利要求18、19或20所述的系统，其中所述请求不要求同步响应，并且所述系统还包括用于从所述目标服务接收目标服务请求的确认的装置；以及用于在不等待响应消息的情况下将所述确认返回到请求者的装置。
22.如权利要求18、19、20或21所述的系统，其中用于等待来自所述目标服务的响应的装置还包括用于在所述中介体中同步接收来自所述目标服务的响应的装置；用于根据来自所述目标服务的响应在所述中介体中创建来自所述中介体的响应的装置；以及用于将来自所述中介体的响应返回到请求者的装置。
23.如权利要求22所述的系统，其中用于在所述中介体中同步接收来自所述目标服务的响应的装置还包括用于在所述中介体和所述目标服务之间的数据通信连接上调用阻塞接收功能的装置。
24.如权利要求17至23中任何一个所述的系统，其中所创建并被发送到所述目标服务的目标服务请求带有在所述web服务中介体中接收到的请求的未经检查和未经修改的消息内容。
25.如权利要求17至24中任何一个所述的系统，还包括用于对于请求者将所述web服务中介体的端点标识为支持所述操作的端点的装置。
26.如权利要求17至25中任何一个所述的系统，其中所述参数信息包括用于所述操作的端口类型。
27.如权利要求17至26中任何一个所述的系统，其中用于根据所述参数信息标识出支持所述操作的目标服务的端点的装置还包括用于根据所述参数信息标识出支持所述操作的目标服务的多个端点的装置；以及用于根据选择规则从所述多个端点中选择一个端点的装置。
28.如权利要求27所述的系统，其中所述参数信息包括用于所述操作的端口类型，并且用于根据所述参数信息标识出支持所述操作的目标服务的多个端点的装置包括用于根据所述端口类型从登记簿中标识出用于所述端口类型的多个目标服务的装置。
29.如权利要求27或28所述的系统，其中用于从所述多个端点中选择一个端点的装置还包括用于根据用于在目标服务之间进行负载均衡的选择规则从所述多个端点中选择一个端点的装置。
30.如权利要求17至29中任何一个所述的系统，其中用于创建用于执行所述目标服务上的操作的目标服务请求的装置包括用于以在与绑定无关的接口中有用的数据结构编写所述请求的装置；以及用于调用所述与绑定无关的接口并将所述请求作为调用参数传送的装置。
31.如权利要求17至30中任何一个所述的系统，其中用于将所述目标服务请求发送到所述目标服务的装置包括用于调用与绑定无关的接口中的一个或多个成员方法的装置。
32.如权利要求17至31中任何一个所述的系统，还包括用于在所述中介体中接收来自所述目标服务的响应的装置；用于根据来自所述目标服务的响应在所述中介体中创建来自所述中介体的响应的装置；以及用于将来自所述中介体的响应返回到请求客户的装置。
33.一种用于web服务中介体的端口类型不可知的代理支持的计算机程序产品，该计算机程序产品包括记录媒体；记录在所述记录媒体上的用于在web服务中介体中接收对执行web服务操作的请求的装置，其中所述请求包括可以从其标识出支持所述操作的目标服务的端点的参数信息；记录在所述记录媒体上的用于根据所述参数数据标识出支持所述操作的目标服务的端点的装置；记录在所述记录媒体上的用于创建用于执行所述目标服务上的所述操作的目标服务请求的装置；以及记录在所述记录媒体上的用于将所述目标服务请求发送到所述目标服务的装置。
34.如权利要求33所述的计算机程序产品，包括记录在所述记录媒体上的用于确定所述请求是否要求同步响应的装置；以及记录在所述记录媒体上的用于如果所述请求要求同步响应则等待来自所述目标服务的响应的装置。
35.如权利要求34所述的计算机程序产品，其中用于确定所述请求是否要求同步响应的装置包括记录在所述记录媒体上的用于根据所述参数信息确定所述请求是否要求同步响应的装置。
36.如权利要求34或35所述的计算机程序产品，其中用于创建用于执行所述目标服务上的所述操作的目标服务请求的装置还包括记录在所述记录媒体上的用于根据对所述请求是否要求同步响应的确定来创建所述目标服务请求的装置。
37.如权利要求34、35或36所述的计算机程序产品，其中所述请求不要求同步响应，并且系统还包括记录在所述记录媒体上的用于从所述目标服务接收目标服务请求的确认的装置；以及记录在所述记录媒体上的用于在不等待响应消息的情况下将所述确认返回到请求者的装置。
38.如权利要求34、35、36或37所述的计算机程序产品，其中用于等待来自所述目标服务的响应的装置还包括记录在所述记录媒体上的用于在所述中介体中同步接收来自所述目标服务的响应的装置；记录在所述记录媒体上的用于根据来自所述目标服务的响应在所述中介体中创建来自所述中介体的响应的装置；以及记录在所述记录媒体上的用于将来自所述中介体的响应返回到请求者的装置。
39.如权利要求38所述的计算机程序产品，其中用于在所述中介体中同步接收来自所述目标服务的响应的装置还包括记录在所述记录媒体上的用于在所述中介体和所述目标服务之间的数据通信连接上调用阻塞接收功能的装置。
40.如权利要求33至39中任何一个所述的计算机程序产品，其中所创建并被发送到所述目标服务的目标服务请求带有在所述web服务中介体中接收到的请求的未经检查和未经修改的消息内容。
41.如权利要求33至40中任何一个所述的计算机程序产品，还包括记录在所述记录媒体上的用于对于请求者将所述web服务中介体的端点标识为支持所述操作的端点的装置。
42.如权利要求33至41中任何一个所述的计算机程序产品，其中所述参数信息包括用于所述操作的端口类型。
43.如权利要求33至42中任何一个所述的计算机程序产品，其中用于根据所述参数信息标识出支持所述操作的目标服务的端点的装置还包括记录在所述记录媒体上的用于根据所述参数信息标识出支持所述操作的目标服务的多个端点的装置；以及记录在所述记录媒体上的用于根据选择规则从所述多个端点中选择一个端点的装置。
44.如权利要求43所述的计算机程序产品，其中所述参数信息包括用于所述操作的端口类型，并且用于根据所述参数信息标识出支持所述操作的目标服务的多个端点的装置包括记录在所述记录媒体上的用于根据所述端口类型从登记簿中标识出用于所述端口类型的多个目标服务的装置。
45.如权利要求43或44所述的计算机程序产品，其中用于从所述多个端点中选择一个端点的装置还包括记录在所述记录媒体上的用于根据用于在目标服务之间进行负载均衡的选择规则从所述多个端点中选择一个端点的装置。
46.如权利要求33至45中任何一个所述的计算机程序产品，其中用于创建用于执行所述目标服务上的操作的目标服务请求的装置包括记录在所述记录媒体上的用于以在与绑定无关的接口中有用的数据结构编写所述请求的装置；以及记录在所述记录媒体上的用于调用所述与绑定无关的接口并将所述请求作为调用参数传送的装置。
47.如权利要求33至46中任何一个所述的计算机程序产品，其中用于将所述目标服务请求发送到所述目标服务的装置包括记录在所述记录媒体上的用于调用与绑定无关的接口中的一个或多个成员方法的装置。
48.如权利要求33至47中任何一个所述的计算机程序产品，还包括记录在所述记录媒体上的用于在所述中介体中接收来自所述目标服务的响应的装置；记录在所述记录媒体上的用于根据来自所述目标服务的响应在所述中介体中创建来自所述中介体的响应的装置；以及记录在所述记录媒体上的用于将来自所述中介体的响应返回到请求客户的装置。
49.一种包括程序代码工具的计算机程序，当所述程序在计算机上运行时，所述程序代码工具适于执行权利要求1至16中的任何一个所述的方法。
全文摘要
公开了其中通过下述步骤典型地提供用于web服务中介体的端口类型不可知的代理支持的方法、系统和产品，所述步骤为在web服务中介体(202)中接收用于执行web服务操作的请求，其中该请求包括从其可以标识出支持所述操作的目标服务的端点的Fulanetric信息；根据所述参数数据标识出支持所述操作的目标服务的端点；创建用于执行目标服务(118)上的操作的目标服务请求；以及将目标服务请求发送到目标服务。示例性实施例典型地还包括请求－响应处理的返回路径在中介体(202)中接收来自目标服务(118)的响应；根据来自目标服务的响应在中介体中创建来自中介体的响应；以及将响应从中介体(202)返回到请求客户(102)。
文档编号H04L29/08GK1890944SQ200480036740
公开日2007年1月3日 申请日期2004年12月9日 优先权日2003年12月12日
发明者G·A·福卢里, S·A·J·霍尔兹沃思, J·M·斯内尔 申请人:国际商业机器公司