专利名称：计算网络中服务的动态部署的制作方法
技术领域：
本发明涉及计算机网络，更具体地说，涉及动态部署、重新部署和解除部署往/来于网络内的各个站点的服务(例如web服务或其它网络可达服务)的方法、系统和计算机程序产品。
背景技术：
Web服务技术正在快速显现为用于分布式应用程序集成的机制。一般来说，“web服务”是描述一批网络可达操作的接口(interface)。Web服务完成特定的任务或一组任务。他们可按照可互用方式与一个或多个其它web服务一起工作，从而完成他们的那部分复杂工作流或商业交易。例如，完成复杂的定货单交易要求位于定货企业的定单发出服务(即定单发出软件)和位于其一个或多个商业伙伴的定单履行服务之间的自动相互作用。
许多行业专家认为面向服务的web服务的创始是新的因特网发展阶段。借助web服务，对软件的分布式网络访问将更广泛地适用于程序-程序操作，而不需要人类的干预。而早期的因特网主要用作分布式文件系统，其中人类用户可请求传送已产生的静态文件，近年来的趋势是向供给请求者的内容中增加越来越多的动态和个人化特征。典型地，在企业网络中已产生这种动态和个人化的内容。但是，这种方法对企业计算资源提出了极高的要求。为了减轻对后端服务器的处理负担，提出了几种技术，包括静态内容的超高速缓存(在有限程度上，在动态产生内容之后超高速缓存内容)；工作负荷均衡；和内容分发。
超高速缓存试图通过保存内容，并且每当可能时，把保存的内容提供给后来的请求者，避免内容的重复产生。供给超高速缓存内容不仅减轻了后端计算资源的工作负荷，而且缩短了对用户的响应时间。工作负荷均衡通过动态调整发送给一组群集服务器中每个服务器的工作量，改进了Web站点的性能。内容分发试图抢先主动(静态地)向网络中的不同位置公布静态内容；例如，向超高速缓存服务器公布静态内容，以便增大可从超高速缓存满足请求的可能性。内容分发服务提供者(“CDSP”)通过提供对他们广泛网络基础结构的访问，以便把静态内容超高速缓存在非常接近最终用户之处，提供有价值的服务。这又使企业能够以成本低廉的方式缩放他们的操作。动态内容分布(即动态地把产生的内容移到更接近用户之处)会产生相同的可缩放性好处。对于一些应用(例如在其表示逻辑电路内提供话路管理，只以批量方式访问后端商务逻辑电路的那些应用)来说，能够(静态地)把表示逻辑电路部署在边缘。这些情况下，内容分发过程一般也会导致响应时间降低。
网络结构中“边缘服务器”的应用通过把静态应用组件(例如图像、表格等)超高速缓存在网络边缘附近，在网络边缘附近，所述静态应用组件可被快速返回给请求者(或者由表示逻辑电路快速取回，供装配将被传送给请求者的响应之用)，提高网络效率和可用性。边缘服务器是物理位于网络边缘或者网络边缘附近的服务器。边缘服务器可实现工作负荷均衡，有时被称为分布式web超高速缓存器、代替者和/或代理人。(例如，IBM WebSphere边缘服务器执行工作负荷均衡，还用作反向代理和/或超高速缓存服务器)。图1提供了网络内典型服务器站点100(即供应与指定的完全合格域名相关的web内容的一批服务器节点)的视图，所述服务器站点100(举例来说)可为诸如www.ibm.com之类域名供应内容。例证的服务器站点100包括应用程序服务器140(例如IBM WebSphere应用程序服务器)的群集150；数个后端企业数据服务器160(例如运行来自于IBM的DB/2、CICS、和/或MQI产品的IBM OS/390)；数个Web服务器130(例如Apache、Netscape、或者Microsoft服务器；注意应用程序服务器和Web服务器通常共同驻留在单一硬件箱中)；数个防火墙110；和数个边缘服务器或反向代理/超高速缓存/负载均衡器120。(“WebSphere”、“OS/390”和“CICS”是IBM的注册商标)。
下一代边缘服务器技术将为网络的边缘带来应用程序的一些动态特征。这可通过把web应用程序寄留在网络边缘，并且静态把表示逻辑(例如servlets，JSPTM、PHP等)部署在这些边缘服务器上来实现。JSP或JavaServer PagesTM是通过利用脚本命令动态地把内容嵌入Web文件中表现的表示逻辑。(“JSP”和“JavaServerPages”是Sun Microsystems，Inc.的商标)。PHP(“个人主页”)是可用于动态地把内容嵌入Web文件中的另一脚本语言。
借助基于Web的开放标准，例如HTTP(“超文本传送协议”)、SOAP(“简单对象访问协议”)和/或XML(“可扩充置标语言”)协议、WSDL(“Web服务描述语言”)和UDDI(“通用描述、发现和集成”)，Web服务将简化“准时(just-in-time)”应用程序集成。HTTP通常用于通过诸如因特网之类TCP/IP(“传输控制协议/网间协议”)交换消息。SOAP是用于在分布式环境中调用方式的基于XML的协议。XML协议是万维网联盟关于应用层传送协议的衍生规范，所述应用层传送协议能够实现应用程序-应用程序消息接发。XML协议可与SOAP汇合。WSDL是一种描述分布式网络服务的XML格式。UDDI是一种基于XML的注册技术，借助该技术，企业可列举他们的服务，并且借助该技术，服务请求者可找到提供特定服务的企业。通过经UDDI注册机发出UDDI请求，查找分布式服务的地点，并且利用服务信息动态地把请求者和定位服务捆绑在一起，可实现准时应用程序集成，通过利用SOAP/XML协议和HTTP消息，以中性平台WSDL格式传送服务信息。(下面对SOAP的引用应解释为等同涉及XML协议的在语义方面类似的特征)。通过利用这些组件，web服务将向请求者提供对可能驻留在一个或多个远程位置的程序组件的透明存取，即使这些组件可能运行于不同的操作系统上，并且用不同于请求者的编程语言编写。(有关SOAP的更多信息，参阅http//www.w3.org/TR/2000/NOTE-SOAP-20000508，题目为“SimpleObject Access Protocol(SOAP)1.1，W3C Note 08 May 2000”。有关XML协议的更多信息，参见http//www.w3.org/2000/xp。可在http//www.w3.org/TR/2001/NOTE-wsdl-20010315，题目为“Web Services Description Language(WSDL)1.1，W3C Note15 March 2001”找到关于WSDL的更多信息。有关UDDI的更多信息，参见“http//www.uddi.org/specification.html”。在来自因特网工程任务组的请求评议(“RFC”)2616，题目为“HypertextTransfer Protocol-HTTP/1.1”(1999年6月)中描述了HTTP)。
虽然静态地把表示逻辑部署在网络的边缘会减轻后端计算资源的负担，并将缩短对不需要执行后端商业逻辑的那些内容请求的响应时间，但是仍然存在必须被送入企业，以便产生内容的许多请求。当商业逻辑保持在企业的中心内时，不能实现网络效率，企业继续是商业增长方面的处理瓶颈和限制因素。此外，只有当应用模式保持恒定并且可预测时，在网络边缘静态部署表示逻辑才有效如果应用模式变化，那么静态部署的逻辑非常有效。另外，按照这种方式的软件静态部署可能会增大管理复杂性，具体地说是关于软件升级的管理复杂性，因为必须提供一种用于记录在哪些系统已部署哪些级别的软件，以及当需要时修改部署的软件的装置。这种升级过程通常是手动的，要求沉闷、易于出错的工作。并且，当web服务使分布式软件资源更广泛地适用时，对于大量的远程服务请求者来说，一些服务的物理位置可能会导致响应时间不太理想。
因此，需要一种避免现有技术的这些缺陷和局限性的技术。
发明内容
本发明的第一目的是提供一种在分布式网络中动态部署网络可访问服务(包括，但不限于web服务)的技术。
本发明的第二目的是提供一种在分布式网络中动态重新部署网络可访问服务(包括，但不限于web服务)的技术。
本发明的第三目的是提供一种在分布式网络中动态解除部署网络可访问服务(包括，但不限于web服务)的技术。
本发明的另一目的是提供一种根据应用量度动态部署网络可访问服务的技术。
本发明的又一目的是提供一种根据应用量度动态解除部署网络可访问服务的技术。
本发明的又一目的是提供一种根据负载均衡考虑因素，动态部署网络可访问服务的技术。
本发明的又一目的是提供一种根据负载均衡考虑因素，动态解除部署网络可访问服务的技术。
本发明的部分其它目的和优点将在下面的说明和附图中陈述，部分根据所述说明是显而易见的或者可通过实践本发明而了解。
为了实现前述目的，并根据这里概括说明的本发明的目的，本发明提供在计算网络中动态部署服务的方法、系统和计算机程序产品。在优选实施例中，该技术包括接收关于选择服务的客户请求；当选择的服务还未被动态部署时，从第一服务器服务接收的请求；当触发动态部署时，通过有计划地(programmatically)把选择的服务从第一服务器转移到一个或多个其它服务器，实现动态部署；在实现步骤导致选择的服务被动态部署之后，从一个或多个其它服务器服务接收的请求。
本发明还提供在计算网络中动态重新部署服务的方法、系统和计算机程序产品。在优选实施例中，该技术包括接收关于选择服务的重新部署触发；确定客户请求选择服务的一个或多个网络位置；当已从选择服务在起始服务器上的最初位置部署选择服务时，从第一服务器服务接收的请求；有计划地除去还未动态部署的服务；通过有计划地从网络位置和起始服务器移动选择的服务，实现动态部署；和有计划地替换所述网络位置和起始服务器的选择服务。
本发明还提供在计算网络中动态解除部署服务的方法、系统和计算机程序产品。在优选实施例中，该技术包括接收关于选择服务的解除部署触发；确定选择的服务所部署的一个或多个网络位置；并且通过有计划地从网络位置中的一个或多个选择网络位置除去选择的服务，实现动态解除部署。
本发明还可有利地用在进行交易的方法中，例如通过1)提供会导致更有效的web寄留站点的动态部署服务(所述web寄留站点又向其用户提供降低端对端费用和/或改进用户站点的效率的优点)；2)提供会导致更有效的web寄留站点的动态重新部署服务(所述web寄留站点提供和目前所需相比，更快速、工作量更小地更新部署的服务)；3)提供会导致更有效的web寄留站点的动态解除部署服务(其中可有计划地除去在网络边缘不再需要的服务)。
下面参考
本发明，其中相同的附图标记代表相同的部件。
图1是根据现有技术的，其中边缘服务器发送输入的内容请求的服务器站点的视图；图2图解说明本发明的组件以及在网络结构内，本发明的组件的布置和互连；图3图解说明可用于累积供本发明之用的应用量度的数据结构；图4根据本发明的优选实施例，图解说明借助其可实现动态服务部署的12阶段过程；图5根据本发明的优选实施例，图解说明可发出的例证部署请求的内容；图6根据本发明的优选实施例，图解说明响应接收图5中的消息，可发出的SOAP请求的内容；图7根据本发明的优选实施例，图解说明可作为对图6的部署请求的响应返回的例证SOAP包络的内容；图8和10根据本发明的优选实施例，图解说明可用于动态解除部署服务的两种方法；图9图解说明可用于记录已部署服务的部署位置的数据结构；图11根据本发明的优选实施例，图解说明可用于动态更新或重新部署服务的过程。
具体实施例方式
本发明定义通过动态部署网络可达服务，改进网络操作的技术，借此解决现有技术的缺点。另外，通过基于相同的动态部署机制的可选增加，借助系统升级的自动的有计划复制，降低了对先前部署的软件升级的复杂性。在另一种可选增强中，通过利用本发明的技术，也可自动地、有计划地解除部署先前部署的软件。(注意，虽然这里本发明的优选实施例被描述为在网络的边缘工作，不过对本领域的技术人员来说，这些技术显然也适合用在服务器场地(farm)的前端。此外，虽然这里把优选实施例描述为适合于与Web服务一起应用，不过这只是出于举例说明的目的，而不是对本发明的限制。公开的技术也可和其它类型的网络可达服务一起应用)。
按照优选实施例，根据到来的关于特定web服务的客户请求，动态计算应用量度(usage metrics)。通过随着用户需求的变化动态部署服务，即使在应用模式快速变动的情况下，也可从边缘获取合适的软件。
一般来说，如同本领域已知那样，web服务可内嵌任意形式的程序设计逻辑，包括脚本程序，JavaTM类程，COM类程，EJB(“Enterprise JavaBeans”TM)，存储过程，IMS或其它数据库事务等。(“Java”和“Enterprise JavaBeans”是SunMicrosystems，Inc.的商标)。由于web服务是操作系统、组件模型和程序设计语言，当使用本发明时，消除了现有技术的只在边缘部署表示逻辑的限制(假定在部署地点存在必要的运行期，如下更详细所述那样)。从而，现在可对于本质上确实动态的内容，实现现有技术中由静态内容的超高速缓存获得的网络效率。
这里，术语“应用量度”被用于表示收集的和特定web服务被请求的次数相关的信息，并可用于确定何时某一服务被多次请求，以致足以通过把所述服务部署在边缘服务器来实现效率。在本发明的一些实现中，最好对所有web服务使用单一阈值；在其它实现中，最好提供多个阈值(包括为每个单独的web服务提供一个不同的阈值)。一般，当配置网络参数时，由系统管理员设置阈值。(另一方面，一些阈值可使用默认值，和/或可有计划地设置一些阈值)。
本发明的动态部署技术可在诸如图1中所示的实例网络内工作，这里边缘服务器120被修改，以便实现这里所述的动态部署。图2表示了本发明可在其中工作的网络结构的抽象表现，图解说明了实现动态部署过程的组件的布置以及他们的网络互连。下面说明这些组件。
如图2中所示，部署系统的组件包括存在点(“POP”)部署服务商(facilitator)230(这里也称为“部署服务商”或“DF”)，CDSP部署节点260(这里也称为“部署节点”或“DN”)，和部署提供商280(“DP”)。可选地，可提供部署运行期贮存器(container)(“DRTC”)245。(DRTC用于本发明的可选增强，它提供解除部署和重新部署，如下所述。如果需要，DRTC也可用在动态部署系统中)。另外，表示了服务请求者210(例如客户应用程序)、公共UDDI注册机(registry)220、边缘服务器或POP 240、基于域名系统(“DNS”)的主解析系统250、专用UDDI注册机270和起始服务器290。一般来说，部件210、220、240、250、270和290本领域已知(除了这里要说明的动态部署、解除部署和重新部署功能之外)，这里不对这些现有部件进行详细说明。
部署服务商组件230驻留在边缘服务器240上，协调从一个或多个起始服务器290到与DF 230位于相同位置的CDSP接入点的web服务的部署，如同下面参考图4详细说明的那样。
在优选实施例中，部署节点260保存该CDSP的应用量度，并当它监视到输入的服务请求时，更新这些量度。当达到应用阈值时，部署节点负责启动向特定的POP(例如向特定的边缘服务器)部署相应的服务。部署节点还包括专用UDDI注册机270，专用UDDI注册机270管理该特定CDSP的服务部署的当前状态。这里使用的专用UDDI节点最好是寄留在CDSP的防火墙内，只允许核实的伙伴公布他们的服务，以便包含在其UDDI注册机中的伙伴目录UDDI节点。另外，只允许该组织内(即防火墙后)的请求者向该专用UDDI节点要求信息。通过用公共UDDI注册机220替代专用UDDI注册机270的内容，组织之外的请求者能够请求位于组织之内的服务。
注意另一方面，UDDI注册机220可以是寄留在CDSP的非军事(demilitarized)区(“DMZ”)中的入口UDDI节点(即另一种专用节点)。入口UDDI节点允许任意请求者查找服务，但是只允许CDSP公布服务。
现有技术的CDSP一般提供内部服务，所述内部服务包括动态查找提供被请求内容的服务器的DNS 250，确定请求者的地理位置的ping三角测量装置，和在已知公共请求URL(“统一资源定位符”)的情况下，用于透明地把客户请求重定向到恰当的POP(即重定向到距离请求者相对较近的POP)的IP地址图。根据本发明，DN 260将与这种系统交互作用，从而将向客户透明反映动态服务部署。(即，客户会请求特定的服务，DNS系统会确定该服务当前部署在何处，并自动把客户的请求发送给所述当前位置)。下面参考图4更详细论述这种透明重定向。
部署提供商280存在于企业网络内，最好存在于超始服务器290上，并且响应部署请求，以便自动并且有计划地把服务部署到请求边缘服务器240。假定服务应用程序的“可边缘性”方面(即能够部署到网络边缘的那些方面)将被恰当打包并保存在部署提供商的内容内(即以企业档案(“EAR”)的形式，以Web档案(“WAR”)的形式，以Java档案(“JAR”)的形式等)。
图3中图解说明了本发明的优选实施例可使用的数据结构。在优选实施例中，DN 260使用该数据结构存储位于单个POP的特定服务的应用计数。(在一些实施例中，最好根据反映全系统活动的应用量度，跟踪部署的服务)。如图3中所示，最好依据其UDDI绑定密钥识别服务。(另一方面，可依据其服务名称或者其它类似的标识符，服务提供商，最终端点识别服务)。为了举例说明起见，这里把数据结构称为“表格”，保存于其中的服务信息被表示成具有由CDSP管理的各个POP的不同行。
在优选实施例中，这里利用12个阶段描述的过程被用于动态部署web服务。在该部署过程中，基于标准的web服务平台最好被leveraged，该平台包括SOAP、WSDL、UDDI和HTTP消息流。W3C发布的题为“SOAP Messages with Attachments，W3C Note11 December 2000”的规范(参见http//www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211)描述一种利用多部分MIME(“多用途因特网邮件扩展”)结构传送附件，使SOAP消息与呈其本来格式的一个或多个附件联系的标准方式。由于SOAP是调用web服务的标准消息接发格式，在本发明的优选实施例中，SOAP附件标准被用作动态部署web服务的机制。如前所述，在不偏离本发明的范围的情况下，可用语义相似的组件代替这里描述的那些组件。例如，在一些实施例中，可用SMTP(“简单邮件传送协议”)流代替HTTP流，如前所述，可用XML协议代替SOAP。
图4关于图2中描绘的那些组件，使用带圆圈的数字表示优选实施例的12阶段过程中的每个阶段。下面参考图4说明这12个阶段中的每个阶段。
在阶段1中，web服务495被部署在起始服务器290上。该阶段使用不构成本发明一部分的现有部署技术。随后向部署节点260公布web服务495(阶段2)。在优选实施例中，该公布操作使用UDDI程序员API(“应用程序接口”)把WSDL文件从起始服务器290传送给部署节点260，以便保存在专用UDDI注册机270中。(可在http//www.uddi.org/pubs/ProgrammersAPI-V1-1.pdf中找到UDDI程序员API，其标题为“UDDI Programmer′s API1.0，UDDI Open Draft Specification 2000年9月30日”)。传送的WSDL文件利用在WSDL规范中规定的格式，描述部署的服务。除了把WSDL文件保存在注册机270中之外，部署节点260最好还保存与该文件相关的提供者元数据(例如发送文件的起始服务器290的网络位置)。
在阶段3中，部署节点260最好利用“公布”API的UDDI命令(例如“save_service”)，用公共UDDI注册TH 220代替其专用UDDI注册机270。例如，下述HTTP请求可被用于向名为“testregistry”的测试级IBM注册机发布信息http//www-3.ibm.com/services/uddi/testregistry/protect/publishapi此时，部署节点260最好还更新储存库452中的DNS项，从而DNS 250将自动使关于该web服务495的后续客户请求被发送给部署节点260。(部署节点随后会利用保存在图3中在300所示数据结构中的信息，把这些后续请求转发给web服务495的恰当位置。下面参考阶段5，更详细地说明输入的客户请求的DN处理)。DN最好还在其表格300中产生初始条目，包括发布的该服务的UDDI绑定密钥并且应用计数的值为0。
可选地，在专用UDDI注册机270(即伙伴目录)和位于220的公共UDDI操作员节点之间可建立hosting重定向关系。该关系使关于公共节点的任何“查找”请求能够参考专用节点中的条目。这种情况下，当路由请求时，不需要在阶段5中描述的三角测量过程。
在阶段4中，客户(即，服务请求者)210从“查询”API发出诸如“find_service”之类的UDDI命令，向公共UDDI注册机220询问特定服务的位置。例如，利用名为“testregistry”的注册机，下述HTTP请求可用于查问服务的位置
http//www-3.ibm.com/services/uddi/testregistry/inquiryapi根据本发明的优选实施例，解析的服务目的地会包含引用部署节点260的URL的终点信息(从而使客户210把其后续请求发送给DN)。另一方面，如果使用hosting重定向器方法，则UDDI绑定模板将提供引用由部署节点管理的第二绑定模板“B”的绑定密钥“A”。绑定模板“B”将为寄留在部署节点的重定向服务提供“入口点”部件。在已知恰当的绑定密钥“A”和为所需服务提供入口点的绑定模板的情况下，该重定向服务将响应get_bindingDetail消息。
客户随后发出服务请求(阶段5)，图4中描述成与服务“绑定”在一起。通过利用在阶段4中从UDDI注册机220获得的终点信息，服务请求被发送给部署节点260。CDSP的DNS功能250截取该请求，并从其DNS存储库452获得被请求服务的当前位置。如果服务已部署在客户的POP 240(这可通过利用诸如ping三角测量之类的技术确定客户位于何处，使用IP地图查找客户的POP，或者借助hosting重定向器关系来确定)，那么该请求被发送给该POP，以便处理(如图4中所示)。如果服务还未部署在客户的POP，则如阶段6中那样进行处理。
在阶段6，部署节点接收客户的服务请求，并将其转发给起始服务器290，所请求的web服务495目前部署在起始服务器290上。在起始服务器处理该服务，服务结果被返回给客户(图4中未示出)。
在部署节点接收每个服务请求之后，在优选实施例的阶段7中，部署节点更新服务的应用量度，以便反映客户请求。(参见图3中的表格，DN部署节点最好保持关于客户请求的信息)。如果服务先前已被访问，那么递增应用计数器。如果这是关于该服务发出的第一次请求，那么应用计数器被设置为1。图3中的例子表示具有UDDI绑定密钥“xxx”的服务已从基于旧金山的POP访问100次，但是从基于纽约市的POP只访问了33次。
在更新应用量度之后，在阶段8中，DN 260检查应用计数器是否等于或大于管理员配置的(或者以其它方式设置的)阈值。如果是，那么这表示服务应部署在客户的POP上。即，该POP的客户正在足够频繁地请求该服务，以致在本地POP部署该服务的副本是有用和高效的(例如，减小网络往返时间，从而提高对客户的响应时间，以及减轻后端系统内传输和处理负担)。于是，部署节点将向位于恰当POP 240的部署服务商发出部署请求(图4中表示为流8)。部署请求最好提供服务描述，所述服务描述可被用于从部署提供商280启动部署。图5表示了包含利用WSDL编码的服务描述的例证部署请求。
对熟悉WSDL编码的人来说，图5A和5B中的例证部署请求显然规定了接口定义。本例中，接口定义是本发明的部署服务的接口定义。如在510所示，例证的接口被命名为“Deployment-interface”并利用“getDeployedService”方法540调用(参见图5B)。定义了两个消息“DeploymentRequest”520和“DeploymentResponse”530。DeploymentRequest消息包括“runtimeEnvironment”部分，从而当为在该POP部署而准备特定服务时，部署服务商可规定将由部署提供商使用的POP专用信息(如同下面参考阶段9更详细论述的那样)。如图所示在550定义向SOAP提供WSDL操作和消息之间的映射的绑定。调用Deploy方法的结果或者是档案索引，或者是服务档案(参见组件560)。图5C规定了同样在阶段8中发送的部署服务的实现定义。
在阶段9中，位于客户的POP的部署服务商230利用在阶段8中从部署节点260获得的信息，向部署提供商280发出SOAP请求，该SOAP请求要求动态部署所涉及的服务。图6中表示了可在阶段9中传送的SOAP请求的一个例子。注意，要部署的服务的名称或者其它标识符被规定为诸如“ServiceName”610之类标记的内容。本例中，规定了唯一的服务标识符“urn.www.acme.comstockquoteservice”，指示客户210请求的，位于www.acme.com的“stockquoteservice”服务将被动态部署。
在POP上的运行期环境已知，并且对于将部署特定服务的每个POP来说，所述运行期环境一致的环境中，在阶段9中发送的部署请求只需要识别所请求的服务。例如，如果用Java编写所请求的服务，并且每个POP具有Java运行期，如果每个POP运行相同的操作系统，如果每个POP支持相同版本的SOAP，从而理解相同的部署消息语法，那么这种简单方法是恰当的。但是，在许多连网环境中，在不同的POP之中，可能存在这些类型信息的差异。例如，不同的SOAP服务器可以在相同的POP上运行，这些服务器具有不同的服务部署方式。或者，可以用不可移植的语言编写所请求的web服务。于是，在起始服务器上(或者在起始服务器可访问的存储库中)可保存要部署的每种服务的多个版本。随后根据在特定POP上可获得的支持，可向所述特定POP发送所述服务的一种不同版本。例如，可相对于特定服务的一个请求者，部署Windows操作系统的COM应用程序，而相同的服务可以C程序的形式部署到运行LinuxTM操作系统的POP上。(“Linux”是Linus Torvalds的商标)。于是，本发明的优选实施例支持在图5A的520中定义的“runtimeEnvironment”组件，以便当请求部署服务时，允许POP向部署提供商提供其配置信息。在图6中，在620图解说明了该技术的例子，这里部署服务商已提供了数种运行期信息。本例中，该信息包括在POP运行的操作系统(Windows 2000)，SOAP服务器的名称(Apache SOAP V2.1)，和运行期环境(Java)。通过利用该信息，部署提供商随后能够选择web服务的正确实现，以便部署在该特定POP上。部署运行期环境串的内容可根据整个环境的需要而简单或复杂(即，如果在整个环境内使用相同的SOAP服务器，并且用Java编写所有web服务，那么参数值可为空；否则，可提供不同的或者其它类型的信息。作为提供额外信息的一个例子，如果可从部署提供商获得多个版本的web服务，则部署服务商可规定供部署提供商使用的版本号)。
再次参考图4，在阶段9中发送部署请求之后，部署提供商280随后(在阶段10)向部署服务商230返回SOAP包络，SOAP包络包括档案索引或者服务档案(如上参考图5的组件560说明的那样)。如在图7中例证的SOAP包络中的730所示，根据已说明的Attachments规范，企业档案(EAR)以MIME附件的形式包含在传送该SOPA包络的HTTP响应中。(另一方面，WAR或JAR可以附件的形式包含于SOAP包络中，或者可根据SOAP包络查阅WAR或JAR)。如本例中在710所示，具有诸如“ArchiveRef”之类名称的标记的“href”属性指定和二进制附件中的内容ID 720匹配的地址。(另一方面，href属性可被省略，假定SOAP服务器适合于处理ArchiveRef标记，随后利用ArchiveRef标记的内容，对照附件的内容ID组件，发出搜索)。
在阶段11，在接收SOAP包络和附件之后，部署服务商230随后访问本地SOAP服务器API，把服务部署在客户的POP 240上。(SOAP服务器API本领域已知，不构成本发明的一部分)。
最后，在阶段12，部署服务商230最好向部署节点260返回成功返回代码，部署节点260随后更新储存库452中的DNS条目，指示该web服务现在部署在边缘服务器240(如图4中在448所示)。通过按照这种方式更新DNS，来自使用该边缘服务器240作为POP的那些客户的关于该服务的后续请求现在将被自动发送给部署在448的服务，而不是发送给部署在起始服务器290的服务495。
如上证明的那样，本发明的部署系统提供动态部署web服务的可扩展结构。这里说明的优选实施例使用应用量度来启动服务部署。其它实施例可使用其它触发事件，而不会偏离这里公开的发明原理。例如，DN可监视网络上的负载，可在阶段8的动态部署决定中使用该信息，代替上面论述的应用量度(或者除上面论述的应用量度之外)。由于如同已说明的那样，该部署系统的优选实施例融合(leverage)UDDI、WSDL、SOAP/XML协议和HTTP的web服务组，因此可在众多平台上无缝把这些实施例集合在一体。边缘服务器代表利用这种部署系统的一个应用平台，并且这里只是出于举例说明，而不是对本发明的限制，描述了边缘服务器。
就本发明的可选增强来说，一种实现可提供动态解除部署和/或重新部署web服务。现在说明这些增强。(注意虽然参考上面说明的部署过程描述这些可选增强的优选实施例，但是这是为了举例说明，而不是对本发明的限制。下面描述的解除部署和重新部署也可和以其它方式部署的服务一起使用)。
第一可选增强正象动态部署web服务一样，本发明的可选增强使得能够动态解除部署web服务。在一个方面，该解除部署可以是有条件的或者选择性的；在另一方面，解除部署是无条件的。下面依次说明每个方面。
为了能够实现有条件的解除部署，可使用web服务的应用量度确定何时应解除服务的部署。一般来说，应用量度是在一段时间内接收的应用请求的平均数。根据该应用量度，可设置指示利用率的阈值，在所述利用率下，应解除服务的部署。阈值最好被保存在部署节点260，并且如果需要的话，可任意改变所述阈值(例如，由部署提供商280，由系统管理员等改变)。例如，如果应用量度是一月内每天的平均请求数，阈值被设置成每天100次请求，那么如果月末利用率低于每天100次请求，就应解除部署该web服务。(在除应用请求之外的其它标准确定服务的动态部署的实现中，解除部署最好反映所述其它标准)。
最好，应用量度保留在边缘服务器240上。利用上述例子，通过把应用计数器保持一个月，计算应用量度。在该例中，为了计算利用率，边缘服务器还保存开始计数的日期，在每月的月末，重置应用计数器。或者，可使用可调整的一月间隔。(注意，并不严格要求每个边缘服务器保留在该服务器上部署的特定服务的应用量度。在一些实现中，在选择的边缘服务器上累积代表性应用量度就足够了)。
虽然应用量度保持在边缘服务器上，但是，根据该可选增强的优选实施例，部署节点260负责发出解除部署请求。于是，部署节点监视将用于确定何时应解除部署边缘服务器上的web服务的利用率。部署节点可定期查询每个边缘服务器，以便获得应用量度。如果应用量度小于阈值，则解除该web服务的部署。
在根据本发明动态部署web服务之后，在优选实施例中使用下述过程，有条件地动态解除web服务的部署。现在参考图8，带圆圈的数字图解说明可用于执行该过程的流程和操作。
1.当起动部署节点260时，部署节点260最好被配置成每隔规定的时间间隔，检查部署的服务的状态。应根据部署的web服务的应用模式，设置所述时间间隔。所使用的特定时间间隔并不重要，例如可用分钟、小时、天、周或月来表述使用的特定时间间隔。
2.当部署新的web服务时，最好把该服务的解除布置阈值保存在部署节点260上。随后可使用该阈值确定何时应解除部署动态部署的web服务。
3、每隔规定的时间间隔，部署节点会获得所有动态部署的web服务的清单。从专用注册机270获得该清单，因为对于每个动态部署的web服务，在该注册机中产生新的商业服务项。该清单包含已部署web服务的所有部署服务商的索引。图9中的表格900图解说明可保存该信息的格式的简单例子。如其中所示，诸如UDDI绑定密钥之类的服务标识符910识别每个部署的服务，诸如IP地址之类的信息920识别这些服务被部署在何处。(注意可根据需要合并或单独保存图3的表格300和图9的表格900中的信息)。
4.向每个部署服务商230发送应用量度请求。作为响应，部署服务商会从部署运行期贮存器(container)获得应用量度，并把获得的应用量度返回给部署节点260。(在每个POP 240中，每个部署服务商230可以接触部署运行期贮存器245，所述部署运行期贮存器为web服务提供与运行期环境的接口。部署运行期贮存器保持用于该解除部署机制的POP专用应用量度)。
5.部署节点260比较应用量度和阈值。如果应用量度小于阈值，部署节点将启动关于该web服务的解除部署过程。
6.通过向DNS服务器250发送从DSN储存库452除去该web服务的条目的请求，起动解除部署过程。在处理该请求之后，web服务不再接收任何其它请求。
7.部署节点随后向部署服务商发送解除该web服务的部署的请求。
8.当部署服务商接收解除部署请求时，关闭web服务448，并从边缘服务器240上的运行期环境除去web服务的可执行代码。在完成解除部署请求之后，最好向部署节点发送指示web服务已被成功解除部署的响应(图8中未示出)。
9.随后，部署节点会除去专用注册机中已被解除部署的web服务的条目。
就该增强的提供无条件解除部署的方面来说，当不再需要web服务时，或者当将用新的web服务替代该web服务时，解除部署web服务。对于如现有技术中那样静态部署的web服务来说，典型的解除部署过程有两个基本步骤。
1.不从服务注册机发布web服务的服务描述。在不发布服务之后，没有人能够查找服务描述。
2.从运行期环境除去web服务。这包括有序关闭运行的web服务，除去运行期环境所需的任何元信息，以及从运行期环境除去web服务的可执行代码。(部署SOAP服务所需的部署描述符是这种元信息的一个例子)。
对于根据本发明动态部署的服务来说，需要增强该解除部署过程，以便解除部署原始web服务，以及所有动态部署的web服务。现在参考图10说明在优选实施例中实现这一点的方式，图10中带圆圈的数字对应于列举的步骤。
1.部署提供商280将从起始服务器290向部署节点260发出解除部署请求。部署提供商最好是该方案中允许发出这种请求的唯一参与者。
2.部署节点通过在其专用注册机270中搜索web服务，核实该web服务部署在其节点上。
3.如果在专用注册机中找到该web服务，那么继续部署节点上的解除部署处理。部署节点负责完成来自部署提供商的解除部署请求。如果在专用注册机中没有找到该web服务，那么最好向部署提供商回送错误消息(图10中未示出)。
4.部署节点通过向公共注册机220发送不发布请求，启动解除部署过程。在处理该请求之后，服务请求者210不能够查找web服务描述，但是所有的web服务仍然继续运行。
5.在完成不发布请求之后，部署节点通知DNS 250服务器除去关于该web服务的所有条目。当这些条目被除去时，服务请求者可访问的唯一形式的web服务是在起始服务器上运行的web服务。
6.部署节点260上的专用注册机包含部署服务商和起始服务器290的引用。部署节点将除去关于起始服务器的条目，以便它不再把服务请求转发给起始服务器。
7.部署节点260将获得部署web服务的部署服务商230的清单。该清单从专用注册机270获得，因为关于每个动态部署的web服务产生新的商业服务项。
8.向在步骤7获得的清单中的每个部署服务商发送解除部署请求。
9.当部署服务商收到解除部署请求时，web服务448被关闭，从边缘服务器240上的运行期环境中除去该web服务的可执行代码。在完成解除部署请求之后，最好向部署节点发送指示web服务已被成功解除部署的响应(图10中未示出)。
10.当部署节点已完成来自部署提供商的解除部署请求时，最好向部署提供商发送指示解除部署请求已完成的响应。
11.部署提供商关闭正在起始服务器上运行的web服务495，随后除去可执行代码。
第二可选增强在一开始已部署web服务之后，该web服务可能必须被更新(例如修改缺陷或者增加新功能)。对于根据现有技术静态部署的web服务来说，典型的web服务更新过程有四个基本步骤。
1.通过从服务注册机中除去该web服务的条目，禁止对该web服务的动态访问。在除去其条目之后，服务请求者应该不能查找关于该web服务的服务描述。
2.从运行期环境除去该web服务。这包括有序关闭正在运行的web服务，从运行期环境除去运行期环境所需的任意元信息，和除去web服务的可执行代码。在关闭web服务之前，有序关闭会核实所有未完成的请求被处理。
3.在运行期环境中部署更新后的web服务代码和元信息，随后起动该服务。
4.重新发布关于该web服务的服务描述。这使得能够动态访问该web服务。
对于根据本发明动态部署的服务，该重新部署过程需要被增强，以便更新最初部署的web服务，以及所有动态部署的web服务。最好应更新所有web服务，从而同时在所有部署系统上可实现更新。下面参考图11说明优选实施例中实现这一点的方式，图11中，带圆圈的数字对应于下面列举的步骤。
1.最好当部署提供商更新起始服务器290上的web服务时开始更新过程。这可通过关闭web服务，更新该服务的可执行代码和元信息，随后再次起动该服务来实现。
2.部署提供商280从起始服务器290向部署节点260发出更新请求。部署提供商最好是本方案中允许发布这种请求的唯一参与者。
3.部署节点通过在其专用注册机270中搜索web服务，核实该web服务已部署。专用注册机包括部署在起始服务器290上的web服务，以及所有动态部署的web服务的索引。
4.如果在专用注册机中找到该web服务，那么部署节点将处理更新请求。部署节点负责完成来自部署提供商的更新请求。如果在专用注册机中没有找到该web服务，那么最好向部署提供商回送出错消息(图11中未示出)。
5.部署节点通过向公共注册机220发送不发布请求，起动更新过程。在该请求被处理之后，服务请求者210不能够查找该web服务，但是所有的web服务仍然在运行。
6.在完成不发布请求之后，部署节点将从其注册机270获得部署web服务的部署服务商230的清单。
7.对于该清单上的每个web服务，更新DNS服务器250，以致所有请求被发送给部署节点。在处理更新的同时，部署节点最好向试图访问该服务的任何服务请求者返回出错消息。
8.在DNS服务器被更新之后，部署节点向在步骤5中获得的清单中的每个部署服务商发送更新请求。最好，按照和部署过程的阶段8(参见图4)中发送的部署请求相似的格式格式化该更新请求，并且更新请求使用和部署请求相似的语法，但是区别在于它传送的是更新请求。
9.当部署服务商收到更新请求时，它会关闭该web服务，随后向起始服务器发送部署请求，以便获得更新后的web服务。在优选实施例中，(重)部署请求使用前面参考部署过程的阶段9(参见图4)说明的相同格式和语法。
10.在部署服务商从部署提供商280收到更新后的web服务分组时，它会在运行期环境中部署该web服务和元信息，随后起动该服务。
11.当部署节点完成来自部署提供商的更新请求时，它将向DNS服务器发送请求，以便重新激活所部署web服务的初始DNS项，并向公共注册机220发布更新后的服务描述。
12.在发布服务描述之后，服务请求者可查找更新后的服务描述，并使用任意更新web服务。服务请求将由DNS服务器重新发送给部署的web服务，或者将按照前面关于部署过程的阶段5和6说明的相似方式(关于这些流程的说明参见图4，图11中未示出)，被发送给部署节点，并被转发给正在起始服务器上运行的web服务。
13.当部署节点向部署提供商发送对更新请求的响应时(图11中未示出)，最好结束更新过程。
从而，可看出可选增强任一或者两者的应用提供除已说明的动态部署技术之外的优点。
本领域的技术人员会认识到，可以方法、系统或计算机程序产品的形式提供本发明的实施例。因此，本发明可采取彻底硬件的实施例，彻底软件的实施例或者组合软件和硬件特征的实施例的形式。此外，本发明可采取包含在一个或多个计算机可读存储介质(包括(但不限于)磁盘存储器、CD-ROM、光学存储器等)上的计算机程序指令的形式，所述计算机可读存储介质具有包含于其中的计算机可用程序代码。
已参考根据本发明实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图说明了本发明。显然可用计算机程序指令实现流程图和/或方框图的各个流程和/或方框，以及流程图和/或方框图中流程和/或方框的组合。这些计算机程序指令可提供给通用计算机、专用计算机、嵌入处理器或其它可编程数据处理设备，以产生机器，从而借助计算机或其它可编程数据处理设备的处理器执行的指令产生实现在流程图流程和/或方框图方框中规定的功能的手段。
这些计算机程序指令也可保存在计算机可读的存储器中，所述存储器可指导计算机或其它可编程数据处理设备按照特定的方式运行，从而保存在计算机可读存储器中的指令产生包括实现在流程图流程和/或方框图方框中规定的功能的指令装置的制造产品。
计算机程序指令也可被加载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列的操作步骤，从而产生计算机实现的程序，以致在计算机或其它可编程设备上执行的指令提供用于实现在流程图流程和/或方框图方框中规定的功能的步骤。
虽然已说明了本发明的优选实施例，不过本领域的技术人员一旦了解基本发明原理，那么他们可对这些实施例做出其它变化和修改。于是，附加权利要求应被理解为既包括这些优选实施例，又包括落入本发明的精神和范围内的所有这种变化和修改。
权利要求
1.一种在计算网络中动态部署服务的方法，包括下述步骤接收关于选择的服务的客户请求；当选择的服务还未被动态部署时，从第一服务器服务接收的请求；当触发动态部署时，通过有计划地把选择的服务从第一服务器转移到一个或多个其它服务器，实现动态部署；和在实现步骤导致选择的服务被动态部署之后，从一个或多个其它服务器服务接收的请求。
2.按照权利要求1所述的方法，还包括下述步骤监视接收的关于选择的服务的客户请求的数目；和当监视的数目超过预定阈值时，触发动态部署。
3.按照权利要求2所述的方法，其中预定阈值应用于若干可动态部署的服务。
4.按照权利要求2所述的方法，其中预定阈值应用于选择的服务。
5.按照权利要求2所述的方法，其中监视步骤计数在所述一个或多个其它服务器的单个服务器上的接收客户请求。
6.按照权利要求2所述的方法，其中监视步骤计数在所述一个或多个其它服务器中的若干服务器上的接收客户请求。
7.按照权利要求1所述的方法，还包括下述步骤监视计算网络上的负载；和当监视的负载超过预定阈值时，触发动态部署。
8.一种在计算网络中动态部署服务的系统，包括接收关于选择的服务的客户请求的装置；当选择的服务还未被动态部署时，从第一服务器服务接收请求的装置；当触发动态部署时，通过有计划地把选择的服务从第一服务器转移到一个或多个其它服务器，实现动态部署的装置；以及在实现步骤导致选择的服务被动态部署之后，从一个或多个其它服务器服务接收请求的装置。
9.一种在计算网络中动态部署服务的计算机程序产品，所述计算机程序产品包含在一个或多个计算机可读介质上，并且包括接收关于选择的服务的客户请求的计算机可读程序代码装置；当选择的服务还未被动态部署时，从第一服务器服务接收请求的计算机可读程序代码装置；当触发动态部署时，通过有计划地把选择的服务从第一服务器转移到一个或多个其它服务器，实现动态部署的计算机可读程序代码装置；以及在实现步骤导致选择的服务被动态部署之后，从一个或多个其它服务器服务接收请求的计算机可读程序代码装置。
10.一种在计算网络中动态解除部署服务的方法，包括下述步骤接收关于选择的服务的解除部署触发；确定部署选择的服务的一个或多个网络位置；和通过有计划地从网络位置中的一个或多个选择的网络位置除去选择的服务，实现动态解除部署。
11.按照权利要求10所述的方法，还包括下述步骤接收关于选择的服务的客户请求；和继续从与有计划地从其除去选择的服务的一个或多个选择的网络位置不同的网络位置服务接收的请求。
12.按照权利要求10所述的方法，其中解除部署触发以网络位置处选择的服务的应用率为基础。
13.按照权利要求10所述的方法，其中解除部署触发以网络位置处的网络负载为基础。
14.按照权利要求10所述的方法，其中解除部署触发是最初从其部署选择的服务的起始服务器发出的解除部署请求。
15.按照权利要求12所述的方法，还包括比较选择的服务的应用率和预定阈值，当应用率低于预定阈值时，发送解除部署触发。
16.按照权利要求15所述的方法，其中预定阈值的数值应用于若干部署的服务。
17.按照权利要求15所述的方法，其中预定阈值的数值应用于网络位置的一个或多个选择的位置。
18.按照权利要求12所述的方法，其中应用率是预定时间间隔内，关于选择的服务的客户请求的平均数。
19.按照权利要求15所述的方法，还包括定期获得供比较步骤之用的应用率的步骤。
20.按照权利要求10所述的方法，还包括下述步骤监视计算网络上的负载；和当监视的负载满足预定阈值时，触发动态解除部署。
21.按照权利要求10所述的方法，其中有计划地除去步骤还包括向一个或多个选择的网络位置发出关于选择的服务的解除部署请求。
22.按照权利要求21所述的方法，还包括下述步骤在网络位置中的一个特定网络位置接收解除部署请求，所述特定网络位置是网络位置中正在从其动态解除部署选择的服务的一个选择的网络位置；和响应接收步骤，关闭所述特定网络位置的选择的服务，并从所述特定网络位置的运行期环境中除去实现选择的服务的执行代码。
23.一种在计算网络中动态解除部署服务的系统，包括接收关于选择的服务的解除部署触发的装置；确定部署选择的服务的一个或多个网络位置的装置；和通过有计划地从网络位置中的一个或多个选择的网络位置除去选择的服务，实现动态解除部署的装置。
24.一种在计算网络中动态解除部署服务的计算机程序产品，所述计算机程序产品包含在一个或多个计算机可读介质上，并且包括接收关于选择的服务的解除部署触发的计算机可读程序代码装置；确定部署选择的服务的一个或多个网络位置的计算机可读程序代码装置；和通过有计划地从网络位置中的一个或多个选择的网络位置除去选择的服务，实现动态解除部署的计算机可读程序代码装置。
25.一种在计算网络中动态重新部署服务的方法，包括下述步骤接收关于选择的服务的重新部署触发；确定已从选择的服务在起始服务器上的最初位置向其部署选择的服务的一个或多个网络位置；有计划地从网络位置和起始服务器除去选择的服务；和有计划地替换网络位置和起始服务器上的选择的服务。
26.按照权利要求25所述的方法，其中重新部署触发包括来自起始服务器的重新部署请求。
27.按照权利要求25所述的方法，还包括当选择的服务要被修改时，发送重新部署触发的步骤。
28.按照权利要求25所述的方法，还包括下述步骤接收关于选择的服务的客户请求；在接收重新部署触发之前，从网络位置服务接收的请求；和在有计划除去和有计划替换步骤之后，利用替换后的服务，服务于接收的请求。
29.按照权利要求25所述的方法，还包括在接收重新部署触发之后，在完成有计划除去和有计划替换步骤之前，不发布选择的服务，以及之后重新发布选择的服务的步骤。
30.按照权利要求26所述的方法，还包括响应从起始服务器接收到重新部署请求，向每个网络位置发送后续重新部署请求的步骤。
31.按照权利要求30所述的方法，其中有计划替换步骤还包括下述步骤从网络位置中的一个选择的网络位置发出关于选择的服务的部署请求；在网络位置中的所述选择的网络位置接收响应消息，响应消息包括选择的服务的替换者；并在网络位置中的所述选择的网络位置部署选择的服务的替换者。
32.一种在计算网络中动态重新部署服务的系统，包括接收关于选择的服务的重新部署触发的装置；确定已从选择的服务在起始服务器上的最初位置向其部署选择的服务的一个或多个网络位置的装置；有计划地从网络位置和起始服务器除去选择的服务的装置；和有计划地替换网络位置和起始服务器上的选择的服务的装置。
33.一种在计算网络中动态重新部署服务的计算机程序产品，所述计算机程序产品包含在一个或多个计算机可读介质，并且包括接收关于选择的服务的重新部署触发的计算机可读程序代码装置；确定已从选择的服务在起始服务器上的最初位置向其部署选择的服务的一个或多个网络位置的计算机可读程序代码装置；有计划地从网络位置和起始服务器除去选择的服务的计算机可读程序代码装置；和有计划地替换网络位置和起始服务器上的选择的服务的计算机可读程序代码装置。
全文摘要
定义了监视输入客户请求的诸如应用量度之类条件(或者其它网络条件，例如负载均衡考虑因素)的过程，并被用于触发向网络中的位置动态部署、重新部署和/或解除部署web服务，以便改进效率。解除部署可应用于服务的分布位置，还可应用于最初从其部署服务的起始服务器。以对客户透明的方式，把服务请求动态发送给服务所驻留的目的地。在一个可选方面，通过利用相同的动态部署方法，可实现系统升级的有计划复制，能够显著降低升级以前所部署软件的复杂性。作为另一可选方面，利用公开的技术，也可自动并且有计划地解除部署以前部署的软件。
文档编号H04L12/00GK1620653SQ01822013
公开日2005年5月25日 申请日期2001年10月5日 优先权日2001年5月23日
发明者彼得·J·布里登汉姆, 道格拉斯·B.·戴维斯, 戴维·B.·林德奎斯特, 阿扎姆·A.·韦斯利 申请人:国际商业机器公司