详细描述
本发明涉及用于根据web服务合同文档的改变来自动修改或更新服务实现的方法、系统和计算机程序产品。本发明的各实施例可包括如以下所很详细讨论的包括各种计算机硬件或模块的专用或通用计算机。
各示例实施例通过提供更新现有服务实现的各部分的自动化机制来解决了与服务合同的改变相关联的问题。例如,一种机制修改实现的骨架(例如,方法、方法签名、数据结构等)以便符合对NPDL(例如,WSDL)合同的改变。在这一实施例中,开发者通常只需对通常不能从合同定义中已知的业务逻辑作出必要的改变(如果有)。因此,对实现的这一自动修改便于开发者采用基于合同的方法来用于web服务开发。
例如,一个示例实施例取以下各项作为输入:服务实现;web服务使用的类的类型;web服务合同;和/或其它输入信息(例如,用于绑定的映射信息)。使用不同于web服务当前实现的合同的指定web服务合同,更新当前实现,使得其类、类属性、方法、方法属性、方法签名和其它各种数据结构或特性符合指定合同。然而,注意,该更新的wb服务实现可能在符合之后不能编译或运行。因此,为了完成该进程,开发者可能需要检查所作出的改变并且完成以下各项中的一个或多个:(1)为所添加的对应于新合同中存在但先前的合同中没有的操作的方法提供适当业务逻辑和/或方法主体代码;(2)如方法的签名已改变并且签名中需要新的或改变的行为和/或引用新的和/或改变的类型,对于该方法按需地修改业务逻辑和/或方法主体代码;或(3)可任选地移出由于先前存在的操作被从合同中移出而导致不再映射到各操作的方法。
注意,此处的实施例允许在更新的实现中保留方法的各部分(例如,用户编写的业务逻辑),这可包括有价值的信息或表示用户可能希望在某一其它上下文中使用的重要工作。例如,在操作被重命名而导致实现改变的情况下,所保留的方法主体代码可以只需被移至新命名的方法。此外,对方法的保留可以是以某种形式将方法、方法属性、方法签名等注释掉。另外,其它实施例还允许在使实现符合更新的合同的过程期间生成注释,由此使得开发者甚至更容易地标识出完成整个服务更新活动所需的工作。
尽管以下参照附图更详细描述了对优点特征的更具体的引用,但是本发明范围内的各实施例还包括用于承载或在其上储存计算机可执行指令或数据结构的计算机可读介质。这类计算机可读介质可以是可由通用或专用计算机访问的任何可用介质。作为示例而非局限,这类计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或可用于承载或储存计算机可执行指令或数据结构形式的所需程序代码装置并可被通用或专用计算机访问的任何其它介质。当信息通过网络或另一通信连接(或者是硬连线的、无线的、或者是硬连线和无线的组合)被传输到或提供给计算机时,该计算机将该连接适当地视为计算机可读介质。上述的组合也应当被包括在计算机可读介质的范围之内。
计算机可执行指令包括,例如使得通用计算机、专用计算机或专用处理设备执行一个或一组特定的功能的指令和数据。尽管本主题是以对结构特征和/或方法动作专用的语言来描述的,但是可以理解,所附权利要求书中所定义的主题不一定限于以上所述的具体特征或动作。相反,上述具体特征和动作是作为实现权利要求的示例形式来公开的。
如此处所使用的,术语“模块”或“组件”可以指在计算系统上执行的软件对象或例程。此处所描述的不同组件、模块、引擎和服务可以被实现为在计算系统上执行的对象或进程(例如,作为单独的线程)。尽管此处所描述的系统和方法较佳地用软件来实现,但是硬件实现或软件和硬件的组合也是可行的且是被构想的。在本说明书中,“计算实体”可以是先前所定义的任何计算系统,或是运行在计算系统上的任何模块或模块的组合。
图1A示出了用于自动修改web服务实现的至少一部分以符合更新的web服务合同文档的计算系统100。计算系统100描绘了可在实现各实施例时使用的各种模块和组件。这各种模块和组件可以被组合成一单独的模块并使用软件、硬件或其组合来实现。此外,这些模块/组件可以被包括在同一计算机内,或者它们可以分布在任意数量的系统中。当然,用于执行由此处所描述的实施例提供的功能的其它配置和机制也可用于本发明的各实施例。因此,计算系统100仅用于说明性目的,并不意味着限制或以其它方式缩小此处的实施例的范围。
不论计算系统100的类型或配置如何,计算系统100都接收或以其它方式访问第一合同或描述(此处互换地使用)文档110,该文档定义了web服务实现要如何与其中提供的服务或端点通信(注意,此处所使用的术语“端点”可包括客户机、服务、或被配置成根据合同与服务通信的任何其它实体)。如上所述,在某些实施例中,一个或多个开发者170在构造web服务实现130之前可以对第一合同文档110达成一致并生成该文档。开发者170可以被认为是个人开发者170或两个或多个开发者170的团队或是企业,确切的数量或组成对于此处所描述的实施例并不重要。另外,上述实体(个别地或组合地)中的任一个可以生成被描述为由开发者170生成的各种文档。
不论谁或如何创建了web服务描述110,第一合同110通常将描述所提供的一个或多个服务的行为。因此,第一描述110特别地描述了所提供的操作、交换的消息的格式、以及其它特性。注意,该清单既不是包括一切的也不是穷尽的。例如,服务的操作可以接收输入消息但不返回输出消息。另外,在第一(以及其它)描述110内可以有此处未列出的其它行为和数据对象。因此,此处所提供的行为和数据对象的清单仅是出于说明的目的,并不意味着限制或以其它方式缩小各实施例的范围,除非明确要求保护。
还要注意,由于在本领域中对WSDL格式的广泛使用,图1的web服务合同文档(例如,第一合同文档110和第二合同文档140)可以被设计为WSDL合同文档。然而,如上所述,WSDL仅是的网络协议描述语言(NPDL)的一个示例格式。因此,WSDL指定不应该被用于限制所公开的实施例或所附权利要求书的范围,除非另外明确要求保护。
尽管如此,web服务合同110可用于创建web服务实现130。例如,构造模块120可用于取得包括在第一web服务描述110中的数据以生成特定实现130。如图1B中所示,web服务实现130可包括由该服务使用的web服务类类型132,该类型将通常具有与其相关联的各种类属性131。web服务类132定义了web服务的实际实现130,包括所提供的各种方法。如上所述,web服务使用如在服务合同(例如,第一合同文档110)中定义的操作来定义了其所接受的消息的类型。这些操作与web服务实现130中的web服务方法133中的每一个相关。
每一方法133具有与其相关联的各种方法属性134和其它数据结构和特性137。另外,方法133通常还包括定义诸如方法133的方法名、方法类型、预期输入参数和/或返回类型等内容的方法签名135。另外,如将在以下更详细描述的,方法签名通常包括如由开发者170所定义的业务逻辑136。当然,在方法133、方法属性134、方法签名135和/或其它数据结构或特性137内也可定义诸如消息通信格式(例如,SOAP)、绑定协议等其它特性。
作为示例而非局限,使用构造模块120创建的web服务实现130可以是类类型132“算术”,它具有各种类属性131和方法133。例如,此实例中的方法133可包括“加”、“减”、“乘”、“除”等等。方法属性134、方法签名135以及其它数据结构或特性137还可对每一方法133定义特定操作的名称(例如,除)、方法类型(例如,除法)、输入所需的整数个数(例如,2)、将得到的输出的类型(例如,单个INT)、输入和/或输出的格式(例如,SOAP消息)以及任何其它适当的特性。
注意,实现服务的类类型132的方法133通常不被自动映射到web服务定义(例如,第一合同文档110)中的操作。例如,典型的工具(例如,骨架模块112)创建骨架代码115,该代码在其中定义了方法133、方法属性134、方法签名135、类类型132等等,而不需要业务逻辑136来完成实现。因此,开发者170通常需要手工规定(使用例如业务逻辑输入模块165)哪些方法132应被展示为服务定义中的服务请求和响应。另外,开发者170需要对用于该服务的第一合同110定义的每一操作完成业务逻辑136的细节。然而,注意,在某些实施例中,创建骨架代码115然后生成web服务实现130的中间步骤是可任选的。
如上所述,构造模块120产生web服务实现130。web服务实现130可包括由第一NPDL(例如,WSDL)文档110规定的类、方法、方法属性、web签名、消息类型等,并且还可包括实现web服务要提供的行为的特定业务代码。当被编译时,web服务实现130应当执行由NPDL合同规定的行为。
不论web服务实现130是如何产生的,如上所述,第一服务合同110可在创建了wb服务实现130之后改变。例如,开发者170可能产生更新、修改或以其它方式完全替换第一服务合同110的第二服务合同140。这些改变可以特别地包括对所提供的操作、交换的消息的格式以及其它特性的改变。因此,使用利用第一合同110生成的web服务实现130的端点可能不再能够与在第二合同140中指定的服务通信。(然而,注意,在某些情况下,对第一合同110的改变不一定意味着使用原始的服务实现130的端点不能与在第二合同140中提供的服务通信。)
例如,在以上“算术”类类型的示例中,开发者随后可能改变输入的个数和/或类型。例如,假设第一合同110允许“加”方法具有开放结尾的输入数组。开发者170可能希望出于诸如减少潜在的安全风险而倾向于对此类事情作为服务攻击拒绝等原因或出于任何其它原因而约束输入的个数。因此,开发者170可改变第一合同110(即,创建第二合同140)以仅允许有限的输入数组,例如5个显式数值自变量。如果当前web服务实现130是被创建为具有开放结尾数组的,则大于5个的输入可能不再能够与根据第二合同140的服务通信。
因此,各示例实施例提供了用于自动评估web服务实现130和第二合同140之间的改变并修改实现130的至少一部分的符合模块150。该模块150本质上提供了一从第二合同140创建一组新类并将该新类与实现130中的现有类进行比较且在需要时作出改变的差异系统。这些改变确保例如实现骨架(例如,类、属性、方法、方法签名、方法属性、数据结构等)符合第二合同140。例如,比较模块可取以下的一个或多个作为输入:web服务实现130;当前和/或先前被服务使用的类型类135;更新的或第二服务合同140;和/或所述原始的或第一服务合同110。基于在实现130(和/或第一合同100,视情况而定)与第二合同之间所标识的变化,可修改web服务实现130的一个或多个部分以生成web服务实现160,来试图使原始实现130符合第二合同140。
注意,在各示例实施例中,实现130(例如,业务逻辑)内的方法的各部分通常在修改的实现160内保持不变。例如,如以下更详细描述的,对操作的移除可以导致相应的方法被注释掉或者以其它方式被标记、移动等。因此,修改的实现160可能无法编译或运行。由此,为了完成该过程,开发者170可能需要使用业务逻辑输入模块165(或其它模块)来完成以下的一个或多个:(1)为所添加的、对应于新合同中存在但先前的合同中没有的操作的方法提供适当的业务逻辑和/或方法主体代码;(2)如方法的并且在签名中需要新的或改变行为和/或引用新的和/或改变的类型,对于该方法按需地修改业务逻辑和/或方法主体代码;或(3)可任选地移除因先前存在的操作被从合同中移除而导致不再被映射到操作的方法。
不论是否需要用于被修改的实现160的业务逻辑,用于修改服务实现130以符合第二合同140的输入都可以改变。例如,符合模块150通常需要取web服务实现130作为输入。然而,其它输入可以取决于如何标识改变而变化。例如,来自第二服务合同140的类型类135可以被标识并直接与web服务实现130内的类进行比较。或者,或除此之外,第二服务合同140的骨架代码145可以使用骨架模块142来生成,该代码然后可以与用于第一合同110的骨架代码115进行比较以标识其改变。
当然,用于标识web服务实现130和第二服务合同140之间的改变的其它输入也是可用的并且是此处所构想的。例如,如将在以下更详细描述的,可以有其中需要用户输入或其它参数来确定完成修改的服务实现160所需的各种规范的情况。因此,如图1A所示,各示例实施例提供了允许开发者170定义符合模块150用于生成被修改的服务实现160的其它参数(例如,指定特定绑定的映射)的输入模块147(或输入模块147内的某一自动的机制)。因此,被符合模块150用于标识实现130和第二合同140之间的改变的任何特定输入在此处仅用于说明的目的。
还要注意,实现130的几乎任何部分可以被自动修改或更新以符合第二服务合同140。例如,类属性可能未改变,然而,方法、方法签名、方法属性或其它特性可能已改变。因此,各示例实施例被配置成标识对实现骨架(即,类类型、类属性、方法、方法属性、方法签名(包括名称、类型、参数、业务逻辑等)、数据结构或其它特性)发生的几乎任何改变。由此,所修改的实现130的任何特定部分此处仅用于说明的目的,并且不意味着限制或以其它方式缩小此处各实施例的范围,除非明确要求保护。
如上所述,此处的实施例允许在更新的或修改的实现160中保留方法中诸如用户编写的业务逻辑等部分,这可包括有价值的信息或表示用户可能希望在某一其它上下文中使用的重要工作的结果。例如,在实现130的改变是源自操作被重命名的情况下,所保留的方法主体代码只需被移至新命名的方法。注意,业务逻辑或方法的其它部分的保留可以用任意数量的方式来发生。例如,改变的操作的名称可能不会导致相应方法的重命名。此外,从第一合同110中消除一操作可能会导致属性被注释掉、被移除、或表示该方法不被展示为web服务的操作的其它标记,或者标记先前的方法及其包含的业务逻辑使得其不被移除。
另外,其它实施例也允许在生成修改的实现160的过程期间插入注释。例如,注释可包括诸如改变在什么日期和时间发生和/或什么引起了改变等信息。当然,也可提供其它信息。尽管如此,其它注释还帮助开发者170标识完成整体服务更新活动所需的工作。
为了更完全地理解此处所描述的实施例,图3提供了可用于实施此处所描述的实施例的特定系统的流程图。注意,对特定询问的确定可以按与该图中所示的不同的次序发生。此外,所使用的特定询问也是仅用于说明的目的,并不意味着限制或以其它方式缩小此处所描述的实施例的范围。
图3所示的具体流程图根本上是一差异系统;它从服务合同创建一组新类,然后将该新类与实现中的现有类进行比较,并在需要时作出改变。该流程进而着眼于对服务实现的改变的各方面。例如,首先它修改web服务类上的属性,使得它符合更新的服务合同中的web服务规范。该图然后着眼于每一消息绑定(例如,SOAP)所引用的每一操作,并确保对于一web方法属性存在一匹配方法,并从所有其它方法中移除该web方法属性。它然后着眼于在消息定义中引用的模式类型(例如,XML),并且作为可选择的用户选项,或者创建一组替换的数据串行化类,或者更新现有的类。
如图所示,该系统首先确定web服务实现的web服务绑定名称和/或绑定名称空间是否不同于第二/更新的web服务合同(判定框302)。如果web服务绑定名称和/或绑定名称空间不同(判定框302中的“是”),则该系统自动更新304web服务绑定名称和/或绑定名称空间。然而,注意,服务名称/名称空间通常不应被更新,因为开发者可能已经决定提供在一不同服务名称下的行为,即使它们保留了绑定名称和名称空间。定义行为类型并用于与第二/更新的web服务合同匹配的是绑定名称和名称空间而非服务名称。
例如,假定绑定名称和绑定名称空间从默认值WebService1和http://tempuri.org改为GolfCatalog和http://catalog.org。以下代码修改可以自动在web服务实现中发生:
在符合第二web服务合同之前:
[System.Web.Services.WebServiceBinding(Name=″WebService1″)]
public class WebService1:System.Web.Services.WebService
在自动符合第二web服务合同文档之后:
[System.Web.Services.WebServiceBinding(Name=″GolfCatalog″,Namespace
=″http://catalog.com″)]
public class WebService1:System.Web.Services.WebService
注意,在以上示例中,服务名称没有随着绑定名称和名称空间的更新而改变。
在更新了web服务绑定名称和名称空间之后,该系统然后自动更新306包括旧绑定名称的web服务实现的方法以包括新绑定名称。例如,以下伪代码修改可以在将绑定名称“WebService1”改为“GolfCatalog”之后在web服务实现中自动发生。
在符合第二web服务合同之前:
[System.Web.Services.WebMethod(…)]
[System.Web.Services.Protocols.SoapDocumentMethod(Binding=
″WebService1″)]
public void getCatalog()
在自动符合第二web服务合同文档之后:
[System.Web.Services.WebMethod(…)]
[System.Web.Services.Protocols.SoapDocumentMethod(Binding=
″GolfCatalog″)]
public void getCatalog()
在用新绑定名称更新了方法之后或者如果web服务绑定名称或绑定名称空间并没有不同于第二服务合同(判定框302中的“否”),则该系统对于web服务实现中匹配web服务合同中的操作名称的每一方法更新方法签名和属性以符合第二/更新的服务合同中的操作。对于第二/更新的合同中的每一操作,该系统然后将web服务实现方法与第二/更新的服务合同操作进行比较308。例如,方法名称可以与操作名称进行比较——假设如以下更详细讨论的有一对一的绑定相关。如果存在匹配(判定框316中的“是”),则该系统然后确定该方法是否被展示为web服务操作(判定框310)。如果有一个或多个不被展示为web服务操作的方法(判定框310中的“否”),则该方法通过向非展示方法添加web方法属性来被自动展示312。这适合例如对于使用了其上定义web方法属性并且没有在类本身上定义web方法属性的接口的用户的升级情形。
否则,如果展示匹配方法(判定框310中的“是”,和/或来自框312中新展示的服务方法),则自动更新318展示的web方法的实现方法签名和属性以符合第二/更新的web服务合同。注意,该系统可能没有改变方法/消息名称和web方法属性。
例如,如果第二/更新的web服务合同规定getCatalog操作现在取ProductId作为参数,并返回System.Xml.Xmldocument,则以下更新可自动发生:
示例1
在符合第二web服务合同之前:
[System.Web.Services.WebMethod(EnableSession=true)]
[SoapDocumentMethod(…)]
public void getCatalog()
在自动符合第二web服务合同文档之后:
[System.Web.Services.WebMethod(EnableSession=true)]
[SoapDocumentMethod(…)]
public System.Xml.XmlDocument getCatalog(String ProductId)
示例2
在符合第二web服务合同之前:
[System.Web.Services.WebMethod(MessageName=“getCatalog”,,
EnableSession=true)]
[SoapDocumentMethod(…)]
public void getGolfCatalog()
在自动符合第二web服务合同文档之后:
[System.Web.Services.WebMethod(MessageName=“getCatalog”,,
EnableSession=true)]
[SoapDocumentMethod(…)]
public System.Xml.XmlDocument getGolfCatalog(String ProductId)
该系统还可自动更新web服务实现中的属性。例如,如果第二/更新的web服务合同文档规定主体样式应当是RPC而非Document,则以下更新可发生:
在符合第二web服务合同之前:
[System.Web.Services.WebMethod(EnableSession=true)]
[System.Web.Services.Protocols.SoapDocumentMethod(Binding=
″WebService1″)]
public void getCatalog()
在自动符合第二web服务合同文档之后:
[System.Web.Services.WebMethod(EnableSession=true)]
[System.Web.Services.Protocols.SoapRpcMethod(Binding=″WebService1″)]
public void getCatalog()
注意,方法签名可包括诸如串或整型等原语消息类型,这些在被修改以符合第二/更新的web服务合同文档时也经历改变。更新实现的一种方式可以是简单地替换原语类型。然而,存在其中开发者可能希望保留原语类型的独特功能的情况。因此,各实施例允许该系统向消息添加将不作为串行化的一部分包括的属性,使得它保持方法不被展示。这有助于确保功能不被移除,而是可供其它开发者使用同时不在修改的web服务实现中使用。
返回到判定框316,如果第二/更新的合同中的操作名称不匹配方法名称(判定框316中的“否”),则该系统通过将带有签名的web方法添加到经修改的服务实现(如框326所示)来自动展示剩余的方法(即,更新的合同中的操作和/或原始实现中的方法)。
一旦展示了修改的实现中的所有方法(即,要么退出判定框318,要么退出326),则对修改的实现中的每一方法,该系统确定所展示的方法是否存在于修改的web服务实现中但不在第二/更新的web服务合同文档中(判定框322)。如果展示的方法存在于修改的web服务实现中并且在第二/更新的合同中,在该系统终止325(判定框322中的“否”)。否则,如果展示的操作不存在于修改的web服务实现中但在第二/更新的web服务合同文档中(判定框322中的“是”),则保留web方法的至少一部分。例如,方法、方法属性、方法签名或其它数据结构可被自动注释掉,使得该方法不再作为web服务操作来展示。或者,方法、方法属性、方法签名等可用其它方式移除并储存在别处以供将来的引用。另外,该系统可添加规定何时以及为何该方法不再被展示的附加注释。这确保具有相应方法签名、参数和/或任何特定业务逻辑的web方法不会从web服务实现中移除,而是仅仅不编译。
例如,如果getCatalog操作被自动注释掉,则以下修改发生:在符合第二web服务合同之前:
[System.Web.Services.WebMethod(MessageName=″Catalog″,EnableSession
=true),System.Web.Services.Protocols.SoapDocumentMethod(Binding=
″WebService1″)]
public void getCatalog()
在自动符合第二web服务合同文档之后:
///[7/2/20044:10PM]该WebMethod属性被移除,因为该操作不再符合
WSDL。
///[System.Web.Services.WebMethod(MessageName=″Catalog″,
EnableSession=true),
[System.Web.Services.Protocols.SoapDocumentMethod(Binding=
″WebService1″)]
public void getCatalog()
在某些实施例中,开发者然后可检查修改的web服务实现并且可执行附加修改。例如,当修改的web服务被编译或运行时,可发生一个或多个错误。为补救错误,开发者可如上所述地修改该实现。
如上所述,上述系统可能需要来自用户或其它自动化机制的其它输入参数以便进一步定义在修改的实现中应当展示哪些方法。例如,上述系统假设在实现和合同之间的单个特定的映射绑定对——即,一对一相关。然而,当将合同映射到实现时,合同(例如,WSDL文档)可包括多个绑定(每一绑定定义一组离散的操作)。例如,可以存在其中在一合同内支持多个版本的情况;因此名称或名称空间例如可能包括版本标识符(注意,对名称和/或名称空间的这些改变在对绑定中的任何操作的行为或签名作出任何材料改变时是典型的)。
因此,在不同绑定上可能发生相同名称的操作,因此仅仅操作名称绑定可能是不够的,因为绑定是由名称和名称空间特性来完全定义的——这些是在合同中,并且被记录为实现代码中的属性,因此它们能够相关。在合同中定义了多组操作(绑定)的这一情况下,如果在第一和第二合同之间仅这些组的部分名称(即,或者是名称或者是名称空间)改变,系统因此可能需要附加输入。这一输入可以用或者是在实现修改的执行期间的直接用户输入的形式,或者是作为对于所述执行的参数(可指定映射)的形式来提供。
换言之,上述系统以及以下描述的实施例可能需要在以下上下文中执行:(1)各自有单个绑定的合同和实现(即,一对一相关),在这一情况下合同中的绑定及其操作用于符合实现,而不管名称和/或名称空间如何;(2)合同和/或实现具有多个绑定,并且名称和名称空间必须完全匹配以使符合能够发生(在合同中但不在实现中的任何绑定可被添加到实现,或者在实现中但不在合同中的任何绑定应例如通过将其注释掉来移除);以及(3)已提供了映射指令(通过例如用户输入或其它自动方式),这明确标识了合同中的哪些绑定应被映射到实现中的哪些绑定(任何未映射的绑定可被忽略或如(2)中那样来处理)。然而,注意,如何处理映射和未映射绑定此处仅用于说明的目的,并且不应限制或以其它方式缩小此处所描述的各实施例的范围,除非明确要求保护。
此处所描述的各实施例还可以按照包括功能步骤和/或非功能动作的方法来描述。以下各节中的一部分提供了在实施本发明时可执行的步骤和/或动作的描述。通常,功能步骤按照所实现的结果来描述本发明,而非功能动作则描述了用于达到特定结果的更具体的行动。尽管可用特定的次序来描述或要求保护功能步骤和/或非功能动作,但是本发明不一定要限于这些步骤和/或动作的任何特定的排序或组合。此外,在叙述权利要求中——以及在以下对图2的流程图的描述中——对步骤和/或动作的使用是用于表明对这些术语的期望的特定的使用。
如上所述,图2示出了用于本发明的各示例性实施例的流程图。以下对图2的描述将偶尔参考来自图1A和B以及3的相应元素。尽管可以对来自这些图的特定元素作出参考,但是这些参考仅用于说明的目的,并不意味着限制或以其它方式缩小所描述的实施例的范围,除非明确要求保护。
现在转向图2,示出了用于自动修改web服务实现以符合对web服务合同的改变的方法200的流程图。方法200包括自动修改210web服务实现的一部分的步骤。例如,符合模块150可用于自动修改web服务实现130的一部分。这一修改通常将保留其中包括的方法的一个或多个部分(例如,业务逻辑)。此外,这一修改可包括以下的一个或多个:如果web服务实现绑定名称或名称空间304中的任一个不同于第二web服务合同140,则更新这两者;保留用于未被包括在第二web服务合同文档140中的操作的web方法324;添加用于包括在第二web服务合同中但不在web服务实现中的操作的、具有方法签名和属性的方法326;修改匹配操作的web方法的方法签名318;向方法添加属性使得该方法被展示为操作;和/或对方法移除属性使得该方法不再被展示为操作,但方法的内容被保留。
用于210的步骤包括接收根据第一web服务合同文档构造的web服务实现的动作201。例如,web服务实现130可以由符合模块150接收。web服务实现可以根据第一服务合同文档110来构造。如上所述,第一合同110通常将描述所提供的一个或多个服务的行为。因此,第一描述110特别地描述了所提供的操作、交换的消息的格式以及定义web服务实现130要如何与计算系统100的其它服务通信的其它特性。
用于210的步骤还包括接收定义了对第一web服务合同文档的改变的第二web服务合同文档的动作202。例如,符合模块150可以接收第二web服务合同140,该合同可包括对第一服务合同110的诸部分的改变。这些改变可改变所提供的操作、交换的消息的格式、以及定义web服务实现130要如何与计算系统100的其它服务通信的其它特性。注意,这些改变以使得wb服务实现130不太可能与期望实现第二web服务合同140的服务的端点(例如,客户机)通信的方式来影响web服务实现130的行为。还要注意,第一110和第二140合同都可以是诸如WSDL等某种NPDL。
用于210的步骤还包括标识web服务实现和第二web服务合同之间的改变的动作203。例如,符合模块150或计算系统100的某一其它组件和/或模块可以标识web服务实现130和第二web服务合同140之间的改变。在某些实施例中,对现有web服务实现(例如,web服务实现130)的(诸)部分的改变通过将该服务实现与第二web服务合同文档(例如,第二服务合同文档140)的(诸)部分进行比较来标识。当然,如上所述,此处也构想了其它标识改变的方式。例如,其它实施例可使用基于第二web服务合同140生成的骨架代码145,并且将该代码与web服务实现130或第一web服务合同110进行比较来标识其改变。在任何情况下,一旦标识了改变,符合模块150就可如上所述地生成修改的web服务实现160。
其它实施例还能够使用业务逻辑输入接口或模块165来展示web服务实现160的修改的部分。这允许开发者170执行以下各项中的某一些:为添加到web服务实现130的、对应于第二web服务合同文档140中存在的、但在第一web服务合同文档110中没有的操作的方法提供适当的业务逻辑代码;为其签名或消息类型已被修改以符合第二web服务合同文档140的方法修改现有业务逻辑;以及移除因操作存在于第一web服务合同文档110中、但不在第二web服务合同文档140中而导致的不再被映射到操作的web方法。
本发明可以用其它具体形式来实施而不脱离其精神或本质特征。所描述的实施例在所有方面都被认为是说明性而非限制性的。因此,本发明的范围由所附权利要求书而非以上描述来指示。落入权利要求的等效技术方案的意义和范围之内的所有改变都被包含在其范围之内。