专利名称：分布式计算机系统中接口改变的管理方法和系统的制作方法
技术领域：
本发明涉及分布式计算机系统中接口改变管理的领域。本发明特别涉及在分布式计算机系统中管理客户端和服务器接口的多个版本之间的改变。
背景技术：
随着计算机网络的发展，分布式计算机系统已经变得更加普遍。分布式计算机系统包括由一个或多个网络连接的多个计算机系统，使得可以共享计算机系统的资源。可以在远程计算机系统上执行由本地计算机系统命令的进程。连接网络可以包括局域网(LAN)、广域网(WAN)和全球性网络如因特网。
多个计算机进程可以协同执行任务的分布式体系结构的一种形式是在“客户端-服务器”关系下的。在这样的关系中，“客户端”或呼叫计算机进程将对远程过程的请求发布或发送到执行该过程的“服务器”或接收计算机进程。应该理解，尽管一个计算机进程可充当发布过程请求的客户端，而另一个在其执行该过程时可以充当服务器，但是任何计算机进程均可以以不同角色既充当客户端又充当服务器。术语“客户端”和“服务器”也可以用于同等的系统。
通过由接口描述的通信，在客户端和服务器计算机系统上运行的应用程序之间传递请求。
当在计算机进程和环境中实施新的功能性时，常常可以增强远程过程接口来支持该新的功能性。按照计算机程序或应用的一般惯例，在新版本的接口中体现对接口的增强。
为了支持新版本的接口，使用该接口的客户端和服务器都必须都支持该新版本。然而，在很多分布式计算机系统中，同时将所有客户端和服务器升级到新版本的远程过程接口是不可能或不切实际的。尤其是在共享或公共网络中更是如此。因此，在分布式计算机系统中可能存在多种版本的接口。
在现有系统中，客户端通常仅支持单个版本的接口的情况下，通过允许服务器支持多个版本来处理多个接口版本。只要客户端可能需要访问旧版本，该客户端就可以同时访问新旧版本的接口。这允许客户端在利用旧接口进行有用的工作时测试其对新接口的使用。
所产生的问题是服务器必须长期维持旧接口和实现(implementation)，可能还有多个旧等级，这将最终使维护和功能进步变得昂贵甚至不可能。
这个问题源自这样的事实因为在一段不可预知的时间内，客户端可能不需要该服务，所以服务器没有可揭示是否有客户端依赖于旧接口的信息。在客户端和服务器处于单一管理范围内的体制下，有可能审核软件并强制升级到新版本。然而，在诸如因特网的公共网络环境中，这样的控制是不可能的，并且需要其它通信和影响(influence)方式。
因特网的发展已经导致了开放或共享计算的使用，其中，用户可通过因特网自由且动态地获得应用，而不需要许可协议来使任何长期关系正式化。这样的系统导致进一步丧失对所使用的接口版本的控制和影响。因特网最近的趋势是使用“网络服务”，由此，由公司联盟制定与具体行业或底层结构需求相关的标准功能，从而表示标准接口。
有几种方案用于现有系统。首先，有可能提供允许一定的信息内容灵活性的接口描述。一个示例称为REST体系结构，其由R.T.Fielding描述(http://www.ics.uci.edu/～fielding/pubs/dissertation/rest_arch_style.htm)，具有对任意复杂程度的文件的少量、稳定操作(例如GET)。另一个示例是提供可在某些描述性语言如xml中得到的可扩展参数。这些方案不可避免地提供关于接口的不精确信息，包括超出用户预期的范围的改变内容的能力。因此，它们不能实现对改变的描述以及对改变进行计划。
第二方案是接受接口必须是稳定的，但是，如果发现需要新版本，则向该接口的所有用户和实施者广播信息。此方法可以用在应用是广泛使用的底层结构的一部分如因特网中使用的域名服务器(DNS)的情况下。RFC 921(由因特网工程任务组(IETF)http://www.ietf.org/rfc.html公布)是这种广播的示例。很明显，如果不向用户提供大量信息，则必须将这种广播的使用限制在少量特殊情况下。
第三方案可以是提供许可程序，其利用可在分布式系统中得到的接口。该程序可以与有限使用期限的许可证一起分发，因此提供关于分布式系统中的设施的潜在使用的信息。这一方案与因特网中许多技术标准的需求、特性不一致，以提供任何客户端均可自由实施的开放接口。
第四方案是在引入新版本时，继续长期支持旧版本。这一方案限制了服务的发展。
发明内容
因此，根据本发明的第一个方面，提供了一种在分布式计算系统中管理对服务应用的接口从第一接口到第二接口的改变的方法，第一和第二接口提供对服务应用的访问，该方法包括从客户端接收进行第一接口的操作的请求；建立对该请求的响应；以及将信息添加到该响应，该信息包括对已有第二接口可用的指示。
根据本发明的第二方面，提供了一种数据处理系统，用于管理对服务应用的接口从第一接口到第二接口的改变，第一和第二接口提供对服务应用的访问，该系统包括用于从客户端接收进行第一接口的操作的请求的装置；用于建立对该请求的响应的装置；以及用于将信息添加到该响应的装置，该信息包括对已有第二接口可用的指示。
根据本发明的第三方面，提供了一种计算机程序产品，其包括当在数据处理主机上执行时，使所述主机执行根据第一方面的方法的指令。
可选地，包括对已有第二接口可用的指示的信息可以包括以下的一个或多个对第二接口的引用，其可用来获得对第二接口的访问；对时间间隔的指示，在该时间间隔中，如果客户端希望继续使用第一接口，则客户端应将该愿望登记为需求；对到期时间的指示，其定义了从何时起将不可使用第一接口访问服务应用；以及统计表，其指示通过那些接口访问服务应用的一组客户端对第一和第二接口的相对利用率。
优选地，该操作用于明确地(specifically)获取所述信息。可替换地，该信息在发往客户端的响应流内包括的上下文中传递。
例如，第一接口是较旧的接口，第二接口是较新的接口，并且所述信息设计为鼓励客户端开始优先于第一接口而使用第二接口。
下面将参考附图，仅作为示例来描述本发明的实施例，其中 图1是根据本发明的分布式计算机系统的示例结构的示意方框图； 图2是根据本发明的分布式计算机系统的客户端和服务器的示意方框图； 图3是根据本发明的具有多个接口版本的服务器的示意图；
具体实施例方式 参考附图，描述分布式计算机系统100。图1是分布式计算机系统100的图示，其提供了这样的系统100的可能结构的示例。分布式计算机系统100的种类(nature)意味着有不确定数目的可能的布置或结构。
在图1中，示出了由公共网络110(例如，可以是因特网)互联的四个计算机系统101、102、103、104。一个计算机系统104还通过局域网(LAN)112连接到另外两个计算机系统105、106。
每个计算机系统101、102、103、104、105、106可以充当客户端、服务器或者兼作二者。每个计算机系统通常包括中央处理单元(CPU)、诸如只读存储器(ROM)的非易失性程序存储装置、诸如随机存取存储器(RAM)的工作区以及诸如硬盘的大容量存储装置。
还应当理解，尽管这一描述涉及充当客户端和服务器的计算机系统之间的通信，但是它也包括在相同的多任务计算机或处理系统上运行的计算机进程之间的通信。
参考图2，示出了两个分布式计算机系统的软件组件的示意图，其中一个计算机系统充当客户端201，一个充当服务器202。客户端201和服务器202通过网络203相连。
在分布式应用中，客户端201和服务器202处于由一种接口描述的关系中，该接口通过网络203使得能够在分布式计算机系统之间进行通信。通过该接口，分布在网络中的应用程序可以共同工作，彼此通信并交换数据以完成处理任务。两个应用程序之间的通信序列可以完成一个或多个处理任务。
应用程序包括也称为调用应用的客户端应用，其驻留在充当客户端的计算机系统上，并为最终用户完成任务。应用程序还包括服务应用，其驻留在充当服务器的计算机系统上，并向其它程序提供服务。分布在一个或多个网络上的应用程序共同进行分布式处理。
图2示出了具有调用应用204和接口205的客户端201。该客户端通过网络203与服务器202通信。服务器202具有服务应用206和接口207。
服务是可以通过远程数据传输来调用的过程，其调用单向消息或者请求以及其相应的答复。
接口205、207是对用来调用服务的操作以及相关参数类型的描述。该描述可以由程序设计人员、可能利用编程工具来使用，以创建服务应用206，服务应用206通过提供对为该接口定义的操作的支持而实现该接口。接口描述表示调用应用204和目标服务应用206之间的协议(contract)。
在服务器202上执行的服务应用接收对由接口提供的操作的请求，对其进行动作，并产生响应。例如，该动作可以是改变和/或获取所存储的信息。注意，给定的接口可以由任意数目的不同服务应用实现，每个服务应用具有独立于该接口描述的各种不同特性，如执行速度或成本。
所描述的方法可以有用地应用于任何可由希望被动态地选择而与客户端没有任何持久协议关系的服务器应用实现的接口上。因此，在接口为开放标准的情况下，它可能是有用的。在一实现必须提供对某些不能被容易地复制以将新实现和接口从其前身分离开的设施如数据库的访问的情况下，它非常有用。
一个示例是通用描述、发现和集成(UDDI)目录，其是称为“网络服务”的新兴因特网技术的重要部分。在http://uddi.org/pubs/uddi_v3.htm的最新规范中对这些进行了描述。UDDI具有接口版本1、2和3。UDDI的实现考虑应当支持哪个版本很重要，而支持全部三个版本是给定未知数量的客户端系统时的合理决定。每个新版本可能对实现施加复杂性的负担。在UDDI V3规范的第10节(“Multi-Version Support(多版本支持)”)中描述了这样的问题的示例。
如UDDI所显示，服务器202可以要求纠正或者希望改进接口或其实现，并且，为了给客户端提供合理的服务质量，这些操作必须在不干扰客户端的情况下引入。
在此描述中，对实现的改变被描述成好像是对接口的改变一样；即使接口语法保持相同，(由实现的行为揭示的)接口的语义也可以改变。例如，可以提供一个或多个新操作，和/或一个或多个现有操作可以被去除或需要不同的参数，和/或可以改变现有操作的行为。
在所描述的方法中，每个新版本的接口通过唯一的标识符来识别，以使客户端清楚已经发生了改变。例如，标识符可以是通用唯一标识符(UUID，参见参考文献http://ftp.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt)或者对接口名称的扩展。
当开发新版本的接口时，例如，服务器可以为提供几种版本的接口的实现的服务应用提供支持。可替换地，例如，服务器可以对多个版本的服务应用提供支持，每个服务应用提供不同版本的接口的实现。这使得不管客户端的调用应用使用哪个版本的接口，客户端都能通过其来访问服务应用。这在图3中示出。服务器302具有这样的服务应用其提供分别对应于原实现306以及改变307、308的三个版本的接口303、304、305的实现。第一客户端308使用第一版本的接口303，而第二客户端309使用第二版本的接口304。
服务器302公布了接口的最新的版本版本3305，其希望感召(influence)仍在使用先前的版本的客户端使用。客户端1308仍在使用原始版本的接口版本1303，该版本不适应对实现306的任何改变。客户端2309正在使用接口的版本2304，该版本包括对实现306的第一组改变307。接口的最新版本(版本3305)适应对实现的第一组改变307和第二组改变308。
在所描述的方法中，每个版本的接口包括一个或多个操作，该操作可用来获取提供已有替代版本的接口可用的指示的信息。例如，该信息可以涉及使用中的接口版本和其它接口版本，因此，服务应用可以通知客户端已有后续版本的接口可用，并进一步指向接口的后续版本。在另一实施例中，每个版本的接口提供特定的操作，从中可以获得这样的信息。在另一实施例中，提供这样的信息作为关于为接口定义的一个或多个操作的一个或多个参数，以进行除了明确地获取该信息之外的某些其它功能。在另一个实施例中，可以将这样的信息作为包括在对请求的响应中的上下文的一部分来传递，以进行由接口提供的操作。上下文是具有响应流但不是所述操作的参数的数据字段，并经常由中间件使用。例如，应用服务建立对操作的响应，并将其提供给中间件，以发送回客户端，然后中间件以上下文的形式将额外的数据附加到响应流。现在，当这样的流到达客户端时，其由中间件接收，该中间件去除并使用与流一起接收的上下文，然后将响应提供给调用应用。
可由接口提供作为对已有替代版本的接口可用的指示的信息示例有 3.客户端应当在其间再一次表明对继续使用该接口的需求的时间间隔。
4.对较新版本的接口(如果有一个的话)的引用。
5.不再支持该接口的日期/时间。
6.指示客户端对该接口的使用与不同版本相比的统计表。
如果提供了客户端应当在其间再一次表明对继续使用该接口的需求的时间间隔，则可以例如通过简单地使用所述服务，或者通过向所述服务应用的提供者登记对客户端正在使用的接口版本的持续关注，来表明这一需求。如果客户端不在该时间周期内表明这一需求，则服务器可以在决定是否撤销该接口版本时，假定客户端不再对此接口版本感兴趣。例如，所提供的时间间隔可以随时间改变，例如，随着去除对该接口的支持的愿望增加，可以随时间减小所提供的间隔。
如果提供了对较新版本接口的引用，那么，例如，此引用的存在隐含地通知客户端已有较新的接口可用，并且不再推荐使用当前接口。该引用可以是例如URL或TCP/IP地址，从中可以获得较新接口的细节。或者，该引用可以例如通过包括一个或多个操作的细节以及可请求那些操作的网络地址，来提供足够的细节，以请求较新版本的接口的操作。
如果提供了到期时间，那么这表明何时将不再支持当前接口，并向仍在使用将停止使用的淘汰接口版本的客户端提供预警。例如，到期时间可以是日期和时间或时间段。客户端应当在到期时间之前及早更新为最新版本的接口，从而留出客户端使用两种版本的接口的重叠时间，以便克服客户端可能经历的有关新版本的接口的任何初始问题。如果提供了这样的信息，但是尚未决定到期时间，则不包括这样的日期和时间信息。
如果提供了统计表，则可以用它们来例如向客户端表明，与其它版本的接口相比，由使用服务应用的这组客户端对所述接口的利用率。统计表可以包括对当前接口和后续接口的当前请求比率，以及这些比率的变化率的细节。例如，统计表可以表明在给定的时间周期内对每个接口所做的请求的百分比、或请求的数目，或者在给定的时间周期内对于多个间隔接收的请求数目的平均。例如，统计表还可以提供不同时间周期的统计表和不同时间周期内统计表改变的细节的多个副本。统计表的目的是鼓励采用改进版本的接口，并基于使用来证明撤销旧版本是正确的。例如，如果客户端发现在前一星期内，只有1％的客户端在使用与其相同的接口，而99％的客户端在使用较新的接口，则因为这将被视为表示例如该接口将很快撤销、或者较新的接口更好，所以将鼓励其进行变动。
在优选实施例中，周期性地获取该信息(即使这仅仅是查询统计表)是每个客户端的义务，以便登记其兴趣，并使用统计表来计划任何适当的升级。
在优选实施例中，最优地合理设置用于撤销接口版本的时间是服务应用提供者的义务。该定时可以取决于(在其它因素中)登记间隔、客户端的历史和期望、新版本接口的采用率、其在较大部件及那些部件的使用期限内的使用。
再次参考图3，客户端1308正在使用版本1303形式的淘汰接口版本。接口版本1303包括提供对已有替代版本的接口可用的各种指示的操作。版本1303提供客户端1308应当在其间通过使用该接口来表明继续使用接口版本1303的需求的时间间隔。因为客户端1是接口版本1303的唯一用户，所以如果其不在此时限内使用该接口，则该接口将被撤销。接口版本1303还提供对接口版本3305的引用，接口版本3305是由服务器302支持的最新版本的接口。接口版本1303还提供将撤销对该接口的支持的到期日期和时间。接口版本1303还提供统计表，其向客户端1308表明对接口的版本1303和版本3305的请求率。
根据接口版本1303中提供的信息，客户端1308应当明白其应当升级到较新的接口版本，并且应当在到期日期和时间之前及早采取行动。
客户端2309正在使用版本2304形式的淘汰接口版本。尽管指示的值不同，并且因为尚未计划而没有设置到期时间，接口版本2304也包括提供与版本1相同的、对已有替代版本的接口可用的指示的操作。
根据接口版本2304中提供的信息，客户端2309应当明白其能够升级到较新的接口版本，但是不需要立即采取行动，因为还没有到期日期和时间。
下面是描述网络服务接口格式的XML文档的具体示例，该接口可结合另一个更具体的服务接口来使用，以从客户端收集有关它们对组合接口的使用的信息，并向客户端提供表明该组合接口将被取代的信息。
＜？xml version＝“1.0”encoding＝“UTF-8”？＞ ＜definitions name＝“VersionInformation_v1” targetNamespace＝“http://Migration/” xmlns＝“http://schemas.xmlsoap.org/wsdl/” xmlnstns＝“http://Migration/” xmlnsxsd＝“http://www.w3.org/2001/XMLSchema” xmlnsuddi＝“urnuddi-orgapi_v3”＞ ＜types＞<!-- SIPO <DP n="8"> --><dp n="d8"/> ＜xsdschema attributeFormDefault＝“qualified” elementFormDefault＝“qualified” targetNamespace＝“http://Migration/” xmlns＝“http://schemas.xmlsoap.org/wsdl/” xmlnstns＝“http://Migration/” xmlnsxsd＝“http://www.w3.org/2001/XMLSchema”＞ ＜xsdcomplexType name＝“VersionInformation”＞ ＜xsdsequence＞ ＜xsdelement name＝“ContactInterval” type＝“xsdduration”/＞ ＜xsdelement name＝“NewVersion” nillable＝“true”type＝“uddidiscoveryURL”/＞ ＜xsdelement name＝“NotValidAfter” nillable＝“true”type＝“xsddateTime”/＞ ＜xsdelement name＝“PercentMigrated” type＝“complete tnspercent”/＞ ＜/xsdsequence＞ ＜/xsdcomplexType＞ ＜/xsdsimpleType name＝“percent”＞ ＜xsdrestriction base＝“float”＞ ＜xsdminInclusive value＝“0.”/＞ ＜xsdmaxInclusive value＝“100.0”/＞ ＜/xsdrestriction＞ ＜/xsdsimpleType＞＜/xsdschema＞＜/types＞＜message name＝“getInformationRequest”＞＜/message＞＜message name＝“getInformationResponse”＞＜part name＝“result”type＝“tnsVersionInformation”/＞＜message＞<!-- SIPO <DP n="9"> --><dp n="d9"/> ＜portType name＝“VersionInformation_V1”＞ ＜operation name＝“getInformation”＞ ＜input message＝“tnsgetInformationRequest” name＝“getInformationRequest”/＞ ＜output message＝“tnsgetInformationResponse” name＝“getInfornationResponse”/＞ ＜/opearation＞ ＜portType＞ ＜/definitions＞ 接口的操作为客户端和服务器之间的信息流做准备，并允许建立合理的规则作为用于使用其接口的暗含协议的一部分，以从一个版本转移到另一个版本而不中断。
该方案解决了这样的问题设定对自由网络中的客户端的合理期望，以感召它们升级使用最新级别的接口/实现级别，并设定何时可以由服务器撤销旧等级的接口。
本发明通常作为计算机程序产品来实施，其包括一组用于控制计算机或类似装置的程序指令。这些指令可以通过预先加载到系统内或者记录在诸如CD-ROM的存储介质上来提供，或者使得可以通过诸如因特网或移动电话网的网络下载而得到。
可以对前述内容进行改进和修改而不脱离本发明的范围。
权利要求
1.一种在分布式计算系统中管理对服务应用的接口从第一接口到第二接口的改变的方法，所述第一和第二接口提供对服务应用的访问，该方法包括
从客户端接收进行第一接口的操作的请求；
建立对该请求的响应；以及
将信息添加到该响应，所述信息包括对已有第二接口可用的指示。
2.如权利要求1所述的方法，其特征在于，所述信息包括以下的一个或多个
对第二接口的引用，其中可以使用该引用来获得对第二接口的访问；
对时间间隔的指示，在该时间间隔中，如果客户端希望继续使用第一接口，则客户端应将该愿望登记为需求；
对到期时间的指示，其定义从何时起将不可使用第一接口访问服务应用；以及
统计表，其指示由通过那些接口访问服务应用的一组客户端对第一和第二接口的相对利用率。
3.如权利要求1或权利要求2所述的方法，其特征在于，所述操作用于明确地获取所述信息。
4.如权利要求1或权利要求2所述的方法，其特征在于，所述信息在发往客户端的响应流内包括的上下文中传递。
5.一种数据处理系统，用于管理对服务应用的接口从第一接口到第二接口的改变，所述第一和第二接口提供对服务应用的访问，该系统包括
用于从客户端接收进行第一接口的操作的请求的装置；
用于建立对该请求的响应的装置；以及
用于将信息添加到该响应的装置，所述信息包括对已有第二接口可用的指示。
6.如权利要求5所述的数据处理系统，其特征在于，所述信息包括以下的一个或多个
对第二接口的引用，其中可以使用该引用来获得对第二接口的访问；
对时间间隔的指示，在该时间间隔中，如果客户端希望继续使用第一接口，则客户端应将该愿望登记为需求；
对到期时间的指示，其定义了从何时起将不可使用第一接口访问服务应用；以及
统计表，其指示由通过那些接口访问服务应用的一组客户端对第一和第二接口的相对利用率。
7.如权利要求5或权利要求6所述的数据处理系统，其特征在于，所述操作用于明确地获取所述信息。
8.如权利要求5或权利要求6所述的数据处理系统，其特征在于，所述信息在发往客户端的响应流内包括的上下文中传递。
9.一种计算机程序产品，包括当在数据处理主机上执行时，使所述主机执行根据权利要求1至4中任何一项的方法的指令。
全文摘要
提供了一种分布式计算机系统(100)中接口改变的管理方法和系统，其中，有多个描述分布式客户端和服务器应用(308、309、302)之间通信的接口版本(303、304、305)。该方法和系统包括连同对接口操作的响应一起提供已有替代接口可用的指示。该信息可包括时间间隔，在其中客户应用(308、309)必须使用该接口版本来联系服务器应用；对后续接口版本(305)的引用；和/或对接口的到期日期和时间的指示。使用接口本身来将版本和有效性信息以及改变传送给客户端应用(308、309)。
文档编号H04L12/24GK1638386SQ20041009233
公开日2005年7月13日 申请日期2004年11月8日 优先权日2003年12月30日
发明者蒂莫西·班克斯 申请人:国际商业机器公司