CN101169717A

CN101169717A - 生成和执行网络服务描述语言调用流程实现的方法和系统

Info

Publication number: CN101169717A
Application number: CN200710181152.6A
Authority: CN
Inventors: 迈克尔·A·吉尔菲克斯; 里斯·D·乌尔里克
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2006-10-26
Filing date: 2007-10-12
Publication date: 2008-04-30
Anticipated expiration: 2027-10-12
Also published as: US8214514B2; CN101169717B; US20080104237A1

Abstract

开发工具接收具有SIP/调用流程交互的扩展的网络服务描述语言。该开发工具允许用户选择调用流程中的琐碎的消息交换。该开发工具可自动生成用于所选消息交换的小服务程序，以形成将在集中应用引擎中执行的应用的模板表单。可替换地，开发工具可生成可在解释引擎中解释的应用的模板表单。随后，用户可访问较高级的商业逻辑。将自动生成的小服务程序、或要解释的应用的模板表单配置为：传递到包括最后的消息内容的网络服务信息。

Description

生成和执行网络服务描述语言调用流程实现的方法和系统

技术领域

本申请一般涉及改进的数据处理系统和方法。更具体地，本申请针对于网络服务描述语言调用流程实现的自动生成和自动执行。

背景技术

会话启动协议(SIP)是用来建立多媒体会话的信令协议。SIP是因特网协议(IP)多媒体子系统(IMS)架构中的核心协议。用于JAVA^TM 2平台企业版(J2EE)应用服务器环境的SIP编程模型由SIP小服务程序(servlet)容器组成。应用被构造为小服务程序逻辑，并且，通过容器来处理低级通信。

SIP编程模型利用调用流程的片段，而将其自身提供给关联的小服务程序。典型地，复杂的应用将具有作为其实现的一部分的多个小服务程序，其中，各个小服务程序将处理流程的不同方面。通过在调用流程中的特定点上设置作为消息处理机的另一个小服务程序，来实现小服务程序之间的交递(hand-off)。

已有以可扩展标记语言(XML)格式描述SIP调用流程的很多努力。通常可视化地表示SIP调用流程。调用流程描述SIP请求和HTTP请求的次序。此次序是理想的(idealistic)；事实上，乱序递交可能影响交换。然而，典型地，协议定义可用来推出协议的特定优先规则。可将调用流程划分为片段，每个片段表示调用流程逻辑的小片(snippet)。

超文本传送协议(HTTP)是万维网的基础传输协议中的一个。用于处理网络请求的典型的编程模型是经由HTTP小服务程序编程模型。面向服务的架构(SOA)是软件之间的标准化接口，使得一个程序可利用另一个程序的功能(服务)。典型地，SOA引用网络服务。简单对象访问协议(SOAP)是用于访问网络上的服务的、基于XML的基于消息的协议。SOAP采用XML语法，以在使用HTTP的因特网上来发送文本命令。

集中(converged)应用是在不同协议上通信、以完成单个目的的应用。典型地，每个协议交互包含其自己的会话。集中应用桥接(bridge)两个或更多会话。实现集中应用的一种方式为通过会话相似性(affinity)，其中，相关的SIP和HTTP会话被关联，并存活(live)于特定群集成员中，并且，将属于每个类型的会话的所有请求路由到该特定群集成员。

发明内容

说明性实施例意识到现有技术的缺点，并提供了开发工具，其接收具有SIP/调用流程交互的扩展的网络服务描述语言。该开发工具允许用户选择调用流程中的琐碎的消息交换。该开发工具可自动生成用于所选消息交换的小服务程序，以形成将在集中应用引擎中执行的应用的模板表单(templateform)。可替换地，开发工具可生成可在解释引擎中解释的应用的模板表单。随后，用户可访问(drop in)较高级的商业逻辑。将自动生成的小服务程序、或要解释的应用的模板表单配置为：传递到包括最后的消息内容的网络服务信息。

在一个说明性实施例中，在用于执行具有调用流程交互的集中网络服务应用的数据处理系统中存在一种方法。该方法包括：接收扩展描述语言文档，其描述一个或多个网络服务接口组件，已在其中嵌入了用于一个或多个调用流程片段的调用流程描述，并且，其包括至少一个调用流程绑定。所述至少一个调用流程绑定将交互操作与所述一个或多个调用流程片段中的给定调用流程片段中的绑定点相关联。该方法还包括：从所述一个或多个调用流程片段中选择一个或多个消息交换；自动生成用于一个或多个所选消息交换中的每个的实现，以形成应用模板；为一个或多个网络服务接口组件提供应用模板中的商业逻辑，以形成集中应用；以及执行集中应用。

在一个示例实施例中，该描述语言文档是网络服务描述语言文档。在另一个示例实施例中，所述一个或多个调用流程片段包括一个或多个会话启动协议调用流程片段。

在另一个示例实施例中，从所述一个或多个调用流程片段中选择一个或多个消息交换包括：从用户接收一个或多个消息交换的选择。

在另一个示例实施例中，自动生成用于一个或多个所选消息交换中的每个的实现包括：自动生成一个或多个小服务程序。所述一个或多个小服务程序中的每个对应于所述一个或多个调用流程片段中的一个。

在另一个示例实施例中，所述一个或多个小服务程序包括一个或多个会话启动协议小服务程序。在另一个示例实施例中，执行集中应用包括：在集中应用执行引擎中执行应用模板。在另一个示例实施例中，执行集中应用包括：在解释引擎中解释应用模板。

在另一个说明性实施例中，提供了计算机程序产品，其包括具有计算机可读程序的计算机可用介质。当在计算装置上执行时，该计算机可读程序使该计算装置接收扩展描述语言文档，其描述一个或多个网络服务接口组件，已在其中嵌入了用于一个或多个调用流程片段的调用流程描述，并且，其包括至少一个调用流程绑定。所述至少一个调用流程绑定将交互操作与所述一个或多个调用流程片段中的给定调用流程片段中的绑定点相关联。该计算机可读程序还使该计算装置：从所述一个或多个调用流程片段中选择一个或多个消息交换；自动生成用于一个或多个所选消息交换中的每个的实现，以形成应用模板；为一个或多个网络服务接口组件提供应用模板中的商业逻辑，以形成集中应用；以及执行集中应用。

在另一个示例实施例中，当在计算装置上执行时，该计算机可读程序使该计算装置执行上面关于方法说明性实施例而概述的各个操作、或所述操作的组合。

在另一个说明性实施例中，用于执行具有调用流程交互的集中网络服务应用的数据处理系统包括处理器、以及耦接到该处理器的存储器。该存储器包含指令，当由该处理器执行时，所述指令使该处理器接收扩展描述语言文档，其描述一个或多个网络服务接口组件，已在其中嵌入了用于一个或多个调用流程片段的调用流程描述，并且，其包括至少一个调用流程绑定。所述至少一个调用流程绑定将交互操作与所述一个或多个调用流程片段中的给定调用流程片段中的绑定点相关联。所述指令还使该处理器：从所述一个或多个调用流程片段中选择一个或多个消息交换；自动生成用于一个或多个所选消息交换中的每个的实现，以形成应用模板；为一个或多个网络服务接口组件提供应用模板中的商业逻辑，以形成集中应用；以及执行集中应用。

在另一个示例实施例中，所述指令还使该处理器执行上面关于方法说明性实施例而概述的各个操作、或所述操作的组合。

通过下面对本发明的示例实施例的详细描述，对于本领域的技术人员来说，本发明的这些和其它特征、以及优点将变得清楚。

附图说明

通过参照下面结合附图对说明性实施例的详细描述，将最佳地理解本发明、以及其优选使用模式和其它目的及优点，附图中：

图1绘出了可实现说明性实施例的方面的示例分布式数据处理系统的图示；

图2是可实现说明性实施例的方面的示例数据处理系统的框图；

图3图解了根据示例实施例的示例会话启动协议应用调用流程；

图4A绘出了根据说明性实施例的网络服务描述语言接口绑定；

图4B绘出了根据说明性实施例的使用状态属性的调用流程绑定；

图4C图解了根据示例实施例的使用状态属性的调用流程；

图5图解了根据示例实施例的监听(listening)接口；

图6是图解根据说明性实施例的集中应用集成引擎的框图；

图7是图解根据说明性实施例的集中应用执行引擎的框图；

图8绘出了根据说明性实施例的接口设计工具用户界面；

图9是图解根据说明性实施例的具有扩展的网络服务描述语言的集中应用的操作的流程图；

图10是图解根据说明性实施例的预先存在的集中应用的操作的流程图；

图11是图解根据说明性实施例的新的集中应用的操作的流程图；以及

图12是图解根据说明性实施例的自动生成WSDL调用流程实现的开发环境的操作的流程图。

具体实施方式

下文中描述的说明性实施例提供了用于针对会话启动协议调用流程交互来扩展网络服务描述语言的机制。这样，可在分布式数据处理环境中实现说明性实施例，其中，连同一个或多个数据网络一起利用多个计算装置。因而，下文中，提供图1和2作为可实现说明性实施例的方面的分布式数据处理环境和计算装置的例子。图1和2仅为示例，并且，不意图表明或暗示对可实现说明性实施例的计算装置的类型和/或配置的任何限制。可对图1和2中绘出的计算装置和环境做出很多修改，而不会背离本发明的精神和范围。

现在参照附图，图1绘出了可实现说明性实施例的方面的示例分布式数据处理系统的图示。分布式数据处理系统100可包括：可实现说明性实施例的计算机网络。分布式数据处理系统100包含至少一个网络102，其为用来在分布式数据处理系统100内连接在一起的各种装置和计算机之间提供通信链路的介质。网络102可包括诸如有线、无线通信链路、或光纤线缆的连接。

在所绘出的例子中，服务器104和106连同存储单元108一起连接到网络102。另外，客户机110、112和114也连接到网络102。例如，客户机110、112和114可为个人计算机、网络计算机等。在所绘出的例子中，服务器104可向客户机110、112和114提供诸如引导文件、操作系统映像的数据。在此实例中，在所绘出的例子中，客户机110、112和114是针对服务器104的客户机。分布式数据处理系统100可包括附加的服务器、客户机和未示出的其它装置。

更具体地，分布式数据处理系统100可提供会话启动协议(SIP)应用、以及网络服务应用。服务器104和106可为群集的成员。更具体地，例如服务器104的服务器可运行SIP平台和面向服务的架构集成平台。

说明性实施例扩展了网络服务描述语言(WSDL)，以允许将调用流程XML与接口描述合并。这通过用于将操作与调用流程内的片段或消息点相关联的操作的、附加的WSDL绑定来实现。另外，WSDL的扩展定义了一组交互，该组交互提供用于操作如何与调用流程交互的附加语义(semantics)。这些交互捕获WSDL之间的交互点。这允许在接口设计中的相同的灵活性，包括用于商业逻辑的较粗略的粒度(granularity)，同时，允许调用流程交互点的精细粒度的控制。

在说明性实施例中提出的方法是双向的。所创建的WSDL接口可用于输出(outbound)交互(即，根据调用流程内的某个事件而通过网络服务而启动)、或用于通常的输入(inbound)请求响应。说明性实施例可与现有的WSDL工具一起工作，并且，甚至允许独立于实现的接口/调用流程设计。

在另一个说明性实施例中，使用附加的寿命周期监听器接口，来传达增强的集中网络服务处理引擎和集中WSDL的应用实现之间的不同的绑定点。寿命周期事件对应于绑定交互类型，并包括对触发寿命周期的调用流程中的位置的引用。可针对应用而注册监听器，以便接收用于集中服务实现的寿命周期时间。可以以编程方式注册此监听器，或者，在部署描述符(deploymentdescriptor)内注册此监听器。

给定SIP调用流程定义和具有SIP/调用流程交互的扩展的WSDL，集中应用集成(CAI)引擎向面向服务的应用实践者提供了在新的集中应用集成绿色空间(green space)中重用现有的网络服务集成技术的能力。集中应用集成引擎“捆绑(wrap)”着预先存在的集中网络服务/SIP或仅用于SIP的应用，监听应用特定信令，并且，基于所提供的具有SIP/调用流程扩展的WSDL，产生并接受使用网络服务的交互请求。

给定SIP调用流程定义、具有SIP/调用流程交互的扩展的WSDL、以及集中应用集成引擎，集中应用执行(CAE)引擎大大简化了开发新的集中应用。在开发时，开发者可将SIP调用流程定义分解为一组SIP小服务程序、以及一组网络服务实现。每个调用流程片段可被分解为SIP小服务程序。每个交互可由以JavaBeans^TM作为后援的网络服务提供后援。在运行时间，CAE引擎通过遵循具有SIP/调用流程交互的扩展的WSDL，而将信令“绑结(stitch)”到分解的小服务程序模型上。在适当的绑定点，CAE引擎激活(invoke)监听器回调(callback)接口。作为回调的结果，应用执行其需要的任何处理，并且，随后，使用CAE引擎的支持服务来产生对任何监听服务集成者的输出交互激活。

在另一个说明性实施例中，CAI引擎使用状态格式，其使用来自具有SIP/调用流程扩展的WSDL的XML代表令牌(token)而呈现交互请求/响应内的状态。状态格式提供了用于在调用的完整寿命周期期间操纵调用的非常丰富且有表现力的接口。状态格式可包括：自从最后一次出现交互起的操作的改变、以及执行历史的改变。调用流程改变历史可描述自从最后的输出交互起的附加信令/执行。

对WSDL的接口扩展提供了有关网络实现的实现行为的重要的信息量。该接口还以这样的方式定义了接口的语义：如果将调用流程分段为适当的单元，则可将核心、高级判定逻辑形象化(externalize)为更高级的处理工具。由此，在另一个说明性实施例中，可将每个片段的执行分离或委派到所生成的代码、或解释引擎。在每个绑定点上，将控制传递到外部机制，如处理服务器，以确定接下来要执行哪个片段。可通过包括最后的消息内容(例如，通过SOAP附件(attachment))，而在所生成或解释的应用、以及外部世界之间传递信息。

在另一个说明性实施例中，接口设计工具可包括传统的调用流程设计视图、以及传统的WSDL接口设计视图。调用流程设计视图可允许将调用流程分组为片段或交换、标记片段中的每个消息。随后，该工具允许创建WSDL操作和调用流程之间的映射。可用交互类型来标记该映射。随后，可视化实体对象的输出可为WSDL和调用流程XML文档，其中，包括了附加的绑定，用于捕获交互关系的操作。

在所绘出的例子中，分布式数据处理系统100是具有网络120的因特网，其代表网络和使用传输控制协议/因特网协议(TCP/IP)的协议套件来彼此通信的网关在世界范围的汇集。在因特网的中心是在主节点或主机计算机之间的高速数据通信线的中枢，其由对数据和消息进行路由的几千个商业、政府、教育和其它计算机系统组成。当然，分布式数据处理系统100还可被实现为包括多个不同类型的网络，如内联网、局域网(LAN)或广域网(WAN)等。如上所述，图1意在作为例子，而不是作为对于本发明的不同实施例的架构限定，并且，因此，图1中示出的特定元素不应为被视为针对可实现本发明的说明性实施例的环境的限制

现在，参照图2，示出了可实现本发明的说明性实施例的方面的示例数据处理系统的框图。数据处理系统200是计算机的例子，如图1中的服务器102或客户机112，其中，可布置实现用于说明性实施例的处理的计算机可用代码或指令。

在所绘出的例子中，数据处理系统200采用包括北桥和存储器控制器集线器(NB/MCH)202、以及南桥和输入/输出(I/O)控制器集线器(SB/ICH)204的集线器架构。处理单元206、主存储器208和图形处理器210耦接到NB/MCH202。图形处理器210可通过加速图形端口(AGP)耦接到NB/MCH 202。

在所绘出的例子中，局域网(LAN)适配器212连接到SB/ICH 204。音频适配器216、键盘和鼠标适配器220、调制解调器222、只读存储器(ROM)224、硬盘驱动器(HDD)226、CD-ROM驱动器230、通用串行总线(USB)端口和其它通信端口232、以及PCI/PCIe装置234通过总线238和总线240连接到SB/ICH 204。例如，PCI/PCIe装置可包括以太网适配器、附加卡、以及用于笔记本计算机的PC卡。PCI使用卡总线控制器，而PCIe不使用卡总线控制器。例如，ROM 224可为快闪二进制输入/输出系统(BIOS)。

HDD 226和CD-COM驱动器230通过总线240而连接到SB/ICH 204。例如，HDD 226和CD-COM驱动器230可使用集成驱动电子器件(IDE)或串行高级技术附连(SATA)接口。超级I/O(SIO)装置236可连接到SB/ICH 204。

操作系统在处理单元206上运行。操作系统协调并提供在图2中的数据处理系统200内的各种组件的控制。作为客户机，操作系统可为商业可用的操作系统，例如Microsoft^、Windows XP^(Microsoft和Windows是美国、其它国家或者两者的微软公司的商标)。例如JAVA^TM编程系统的面向对象编程系统可与所述操作系统协作运行，并且，从在数据处理系统200上执行的Java^TM程序或应用提供对操作系统的调用(Java是美国、其它国家、或两者的太阳微系统有限公司(Sun Microsystems，Inc.)的商标)。

作为服务器，例如，数据处理系统200可为运行高级交互执行体(AIX^)操作系统或LINUX^操作系统的IBM^eServer^TM pSeries^计算机系统(eServer、pSeries和AIX是美国、其它国家、或两者的国际商用机器公司的商标，而LINUX是美国、其它国家、或两者的Linus Torvalds的商标)。数据处理系统200可为在处理单元206中包括多个处理器的对称多处理器(SMP)系统。可替换地，可采用单处理器系统。

在例如硬盘驱动器226的存储装置上放置用于操作系统、面向对象编程系统和应用或程序的指令，并且，可将所述指令加载到主存储器208中，以便由处理单元206执行。可由使用计算机可用程序代码的处理单元206来执行用于本发明的说明性实施例的处理，其中，可将所述计算机可用程序代码置于诸如主存储器208、ROM 224的存储器、或者一个或多个外设装置226和230中。

诸如如图2所示的总线238或总线240的总线系统可由一个或多个总线组成。当然，可使用提供在不同组件或附加到组织或架构的装置之间传送数据的任意类型的通信组织或架构来实现总线系统。诸如如图2所示的调制解调器222或网络适配器212的通信单元可包括一个或多个用来发送和接收数据的装置。例如，存储器可为图2中的主存储器208、ROM 224、或例如在NB/MCH 202中发现的高速缓存。

本领域的技术人员将理解，在图1-2中的硬件可取决于实现而改变。除了图1-2所绘出的硬件之外、或者替代图1-2所绘出的硬件，可使用其他内部硬件或外设，如快闪存储器、等同的非易失性存储器、或光盘驱动器等。并且，除了先前提及的SMP系统之外，还可将说明性实施例的处理应用于多处理器数据处理系统，而不会背离本发明的精神和范围。

此外，数据处理系统200可采取多个不同的数据处理系统中的任一个的形式，包括客户机服务器装置、服务器计算装置、视频游戏机、桌上计算机、膝上型计算机、电话或其它通信装置、个人数字助理(PDA)等。在一些说明性例子中，数据处理系统200可为便携式计算装置，其配置有快闪存储器，例如，以便提供用于存储操作系统文件和/或用户生成的数据的非易失性存储器。本质上，数据处理系统200可为任何已知或今后开发的数据处理系统，而无架构限制。

说明性实施例扩展了网络服务描述语言(WSDL)，以允许将调用流程XML与接口描述合并。除了诸如类型、消息类型、端口类型、接口、绑定等的常用的WSDL结构之外，还将WSDL文档与某个调用流程XML相关联。可从另一个XML文档导入此XML，或者，可将此XML直接嵌入到WSDL文档。调用流程描述应用和其它网络元素之间的各种交互。图3图解了根据示例实施例的示例会话启动协议(SIP)应用调用流程。

调用流程还可被划分为片段。对于在图3中绘出的调用流程，可将步骤1-3视为片段1，步骤4-9可为片段2，而“再见(bye)”步骤(未示出)可为片段3。还可使用附加的片段用于调入信令。注意，此调用流程也暗示消息之间的数据流程。对于说明性实施例的实现，可期望注释调用流程，以便还指示数据流程。

在典型的简单对象访问协议(SOAP)网络服务绑定中，每个操作具有关联的用于操作的SOAP绑定。图4A绘出了根据说明性实施例的网络服务描述语言接口绑定。通过使用附加的调用流程绑定，而将该操作合并到SIP调用流程。

图4B绘出了根据说明性实施例的具有调用流程绑定的网络服务描述语言接口绑定。例如调用流程绑定412的调用流程绑定将该操作与调用流程片段中的点、以及消息点相关联。这对操作赋予附加的含义。现在，看到该接口的任何人将具有对在实现中实际进行何种操作、以及其属于哪个交互的更佳的想法。调用流程还可变为实现的契约(contract)。

现在，以两种方式开始应用的执行：通过网络事件(对于某些应用)、或通过取消(kick off)调用流程片段的操作。随后，执行继续，直到下一个绑定点为止，在该点上，要采取的动作取决于绑定交互类型。该交互帮助对该操作提供附加的语义，其可用于确定该操作意味着要被如何使用。现有技术的WSDL接口描述的描述性不足以捕获使用情形。

此途径中的关键使能器(key enabler)是交互的定义。交互描述上下文，其中，该实现预计要出现的方法。定义了下面的交互：

·查询：查询调用流程的状态。针对与WSDL相关联的调用流程而有意义地定义了该状态。这可被用来查询执行流程的当前状态，并能够放置有意义的结果。存在代表状态的几种方式，如关于先前执行的片段、关于协议优先交换等。

·通知：向该通知的实现方指示：应从服务实现发送通知，该通知指示已出现了应用中的点，例如，已完成了调用建立。通知相对于调用流程的执行来说是异步的。

·引导：这暂停调用流程的执行，以调出到外部网络服务终点，以便使用绑定(bound)操作来接收引导。这可为实际的SOAP网络服务激活、或Java^TM绑定。

·规定：这指示该操作将提供有关如何在执行流程内作出判定的描述性规则。可在片段点上评估规定规则，以确定要移入哪个片段。这可在任何时间被调用，如在建立时间。

·动作(Act)：这取消调用流程的片段。随后，此操作可被用来取消调用流程、或发送附加的信令流入，如终止调用。

这些WSDL扩展可被用来提供用于实现的附加接口契约，或可通过网络服务基础结构而被增强。

对调用流程绑定的附加扩展为“状态”属性。可在将绑定与调用流程中的点匹配时使用状态属性。图4C图解了根据示例实施例的使用状态属性的调用流程绑定。图4C中绘出的例子图解了如何通过指定先前的片段而指示状态。可使用更精细的状态指定方案。如果其状态匹配，则仅应用绑定。操作还可具有多个绑定，这有效地将一系列片段与操作关联。

另外，可遵循操作、向和从调用流程实现发送SIP消息，以帮助引导调用流程。可使用的两个机制为SIP消息的XML表示、以及SOAP附件。SOAP附件减小了搭载(piggybacked)的低级SIP消息的成本。

图5图解了根据说明性实施例的监听接口。使用附加的寿命周期监听器来在增强的集中网络服务处理引擎和WSDL的集中应用实现之间传达不同的绑定点。在每次网络服务处理引擎匹配针对WSDL的调用流程执行中的绑定点时，监听器实现得到激活。注意，增强的集中网络服务处理引擎能够看到网络服务和与调用流程相关的请求两者。对于可通过所生成的网络服务绑定来处理的操作，恰好在调用操作之前，仅提供、激活动作的通知。对于输出动作，监听器是必须作出外部调用的仅有的指示器。

针对基于面向服务的架构(SOA)的集成的现有技术的方法对SIP信令一无所知。给定现有的集中网络服务/SIP或仅用于SIP的应用，系统集成者需要在适于处理服务器和SOA编程模型的间隔粒度上与应用交互的能力。针对基于SOA的集中SIP/网络服务应用开发依赖于源自技术惯例之一的工具。因为独立地针对于SIP或网络服务开发而调整(gear)现有技术的应用开发实践，所以，写入良好结构、健壮、可维护等的集中应用是困难的。开发进行所述两者的应用是困难的。

图6是图解根据说明性实施例的集中应用集成引擎的框图。集中应用集成(CAI)引擎620“捆绑(wrap)”着预先存在的集中网络服务/SIP应用622。使用监听器接口624，CAI引擎620监听应用特定的信令，并且，在SOA集成平台630中，基于所提供的具有SIP/调用流程扩展的WSDL，产生并接受使用网络服务的交互请求。

CAI引擎620具有几种优点。SOA实践者可使用现有的平台630、工具、以及技术来与平台集成，这是因为，CAI引擎620向实践者给出集中应用的操作的网络服务友好的视图。在已创建了SIP/调用流程WSDL之后，不需要SIP专门知识。因为CAI引擎620根据调用流程描述而工作，所以，可将CAI引擎620绑缚(bolt)到现有的应用622上，而不需要任何应用级别的改变。任何预先存在的应用信令在其SIP/调用流程WSDL内可具有不同的交互粒度。集成者可基于它们定义的片段，而选择交互的粒度。例如，一个服务约定(engagement)可能需要有关电话呼叫起始和终止的通知交互，而另一个服务约定可能需要有关每一个单个SIP消息的通知交互。

CAI引擎620耗用(consume)具有SIP/调用流程扩展的WSDL，其描述由任意预先存在的集中网络服务/SIP或仅用于SIP的应用(例如，应用622)所使用的信令。CAI引擎620通过使用监听器接口624而监听预先存在的应用622及其客户机之间的信令，其包括所有输入和输出SIP信令、以及网络服务激活。监听器接口624是如上面通过参照图5而描述的那样。当在SIP平台610中的调用流程内出现信令时，CAI引擎620跟踪调用流程片段之间的过渡，并在存储装置626中维持状态信息。

当在SIP平台610中调用流程到达在扩展WSDL内定义的交互(例如，通知或引导)时，CAI引擎620利用相关状态信息而产生用于适当的交互的输出网络服务激活。在任意时刻，CAI引擎620可接收输入网络服务激活，其请求或修改相关的状态信息(例如，查询、规定、动作)。

当CAI引擎620耗用具有SIP/调用流程扩展的WSDL时，其生成SIP小服务程序、以及以JavaBeans^TM作为后援的网络服务实现，例如，所述两者可在WebSphere^集中HTTP/SIP容器中运行。所生成的SIP小服务程序作为简单的记录路由代理(record-routing proxy)而工作。在每个传入(incoming)响应或后续请求上，SIP小服务程序在功能上确保该消息到达SIP协议所命令的目标。网络服务实现用作背对背(back-to-back)/中间人(man-in-the-middle)，并激活原始的网络服务终点。

当网络服务通过所生成的代码而产生请求、或SIP消息流程时，该代码检索适当的会话对象(HttpSession、SipSession、SipApplicationSession)，并更新相关的状态信息，例如，消息内容、消息之间的时间等。

当状态到达具有所定义的通知或引导交互的点时，所生成的小服务程序在标准集成平台630上激活通知或引导网络服务交互请求。通知交互包括调用流程的状态。引导交互包括调用流程的状态，并且，CAI引擎620使用来自集成平台630的响应，以修改其内部状态。

在任意时刻，集成平台630可在CAI引擎620上激活查询交互，CAI引擎620利用当前的调用流程状态来响应。集成平台630还可利用规定的状态信息，而在CAI引擎620上激活规定交互。CAI引擎620将此状态信息存储在存储装置626中，并且，将在接收到为应用绑定或源自应用的相关的初始请求时恢复它。这可采用串行化到数据源的信息的形式，之后查询该信息，并且，在接收到初始请求时将该信息恢复为会话对象。集成平台630可利用规定的状态信息，在CAI引擎620上激活动作交互。CAI引擎620将把动作交互传递到基础(underlying)应用622，并且，必须对该应用编码，以便理解它。可替换地，集成平台630可直接激活应用622所拥有的任意网络服务操作。

图7是图解根据说明性实施例的集中应用执行引擎的框图。给定图6中示出的SIP调用流程定义、具有SIP/调用流程交互的扩展的WSDL、以及集中应用集成(CAI)引擎，集中应用执行(CAE)引擎简化了新的集中应用的开发。在开发时，开发者可将SIP调用流程定义分解为一组SIP小服务程序、以及一组网络服务实现。每个调用流程片段可被分解为SIP小服务程序。查询、规定和动作交互中的每个可由以JavaBeans^TM作为后援的网络服务提供后援。通知和引导操作使用CAE引擎720提供的支持服务，这是因为，从应用的角度来看，它们是输出的。开发者插入到各个小服务程序的逻辑在上面通过参照图5而描述的监听器接口724上生效(capitalize)。

在运行时间，CAE引擎720通过遵循具有SIP/调用流程交互的扩展的WSDL，而将信令“绑结”到分解的小服务程序模型上。在适当的绑定点，CAE引擎720激活监听器回调接口724。例如，当由于调用片段完成而造成在两个SIP小服务程序之间传递控制时，CAE引擎720可激活onNotify。作为回调的结果，应用722执行其需要的任何处理，并且，随后，使用CAE引擎720的支持服务来产生对任何监听服务集成者的输出通知或引导交互激活。

基于应用的意图信令，CAE引擎720提供用于迅速开发集中应用的良好定义的结构。通过使SIP/调用流程被分解为小服务程序，而激励开发者针对一段有用的信令而具有一个小服务程序过程。这减小了产生单块(monolithic)SIP小服务程序的趋势，从而减小了代码复杂度，并使测试和维护容易。因为CAE引擎720在回调期间向应用722提供存储装置726中的上下文(contextual)状态(例如，onNotify、onDirect)，所以，应用开发者不需要将努力投入到维持当前信令状态中。CAE引擎720为开发者而在存储装置726中维持状态，并且，不考虑信令复杂度，而以容易耗用的形式呈现它。在无CAE引擎720的情况下，开发者必须花费时间来开发具有更丰富的功能的相关状态历史逻辑，从而需要更多的开发时间。

因为如同其它类型的信令那样处理网络服务激活、并使用公共接口来描述网络服务激活，所以，开发者不需要投入努力来将网络服务请求历史/细节添加到SIP信令状态中。CAE引擎720以开发者的名义完成了这些。

因为CAE引擎720遵循查询、通知、引导、动作、规定范例，所以，CAE引擎720允许集中应用开发者和集中应用集成者在讨论集中功能性时使用相同的语言。基于CAE的应用免费获得CAI集成点，从而激励利用SOA生态系统(ecosystem)的它们的重用。从外部看，CAE应用看起来正像是CAI引擎捆绑着的非CAE应用。这改善了开发成本的返还，这是因为，组织可更容易地导出允许CAE的应用，用于外部耗用。CAE引擎720是超越CAI引擎的一件增量的工作。

为CAE引擎720构造的工具耗用为新应用722设计的、具有SIP/调用流程扩展的WSDL。该工具基于将SIP/调用流程分解为调用片段，而生成适当的J2EE/SIP实体对象。应用开发者取得那些实体对象，并填入适当的商业逻辑。应用开发者将那些实体对象与CAE特定的部署描述符一起封装。此描述符指示正在使用的具有SIP/调用的WSDL、适当的应用状态模型、以及应在运行时间向CAE引擎720注册的任意监听器。

在运行时间，CAE引擎720作为控制器工作，该控制器截获所有传入信令、来自SIP平台710的SIP信令、或来自集成平台730的网络服务信令。CAE引擎720在激活下属(underling)应用逻辑之前更新其内部状态。

当在SIP平台710中完成调用流程片段时，CAE引擎720自动地引导信令到分解的实现内的适当的SIP小服务程序。当调用流程到达在扩展的WSDL内定义的交互(例如，通知或引导)时，其激活所定义的应用监听器724。该应用可利用来自存储装置726的相关状态信息，而产生对集成平台730的输出网络服务激活，用于适当的交互。对于引导交互，应用722“看到”外部系统的响应，并可相应地更新其状态。在任意时刻，CAE引擎720可接收输入网络服务激活，其请求或修改相关的状态信息(例如，查询、规定、动作)。在预先填入(populate)其知道的信息(例如，自从最后一次出现交互起的信令历史、状态改变)之后，CAE引擎720将这些传递到应用722上，以便处理。

对WSDL的接口扩展提供了有关网络实现的实现行为的重要的信息量。该接口还以这样的方式定义了接口的语义：如果将调用流程分段为适当的单元，则可将核心、高级判定逻辑形象化为更高级的处理工具。可将每个片段的执行委派到所生成的代码、或解释引擎。在每个绑定点上，将控制传递到外部机制，如处理服务器，以确定接下来要执行哪个片段。可通过包括最后的消息内容，而在所生成或解释的应用、以及外部世界之间传递信息。

在生成模式中，在接口内描述的每个调用流程片段将对应于所生成的SIP小服务程序。应能够独立地执行片段，如SIP事务。可选择这些片段，以便暗示并观察(scope)片段之间的数据流。可通过使用例如SIP小服务程序setHandler( )方法的机制，而实现片段之间的交递。

可将三个绑定交互类型应用于此模型：引导、规定、动作。对于引导和规定，可继续执行，直到到达初始绑定点为止，典型地，在片段的结尾。在这样的点上，如果绑定交互为引导，则将进行调出，以确定接下来要执行哪个片段。调出将提供所附连(例如，通过SOAP附件)的最后的SIP消息，并且，到下一个片段的引导还采用将输入消息提供给片段的附连。如果绑定点为规定，那么，将商议所关联的规则，以确定接下来要执行哪个片段。还可使用动作交互，以在对话或新的交互中异步地取消调用流程片段(例如，终止)。

所生成的应用可为集中应用，并且，使用会话相似性来将传入请求引导到正在执行所生成的代码的、群集中的相同的应用服务器。这简化了生成模型，从而允许所生成的代码关注于逻辑，并让应用服务器层处理负载平衡、故障切换(fail-over)等。

在CAI引擎和系统集成者之间发送的状态信息必须足够丰富，同时不加重集成者或集成平台的负担。集成者应当不需要理解SIP的所有细微差别。CAI引擎的目的在于，将SIP理解和复杂度推出集成平台。集成者应当接收尽可能多的信令信息。这允许集成者在他/她理解了SIP信令的情况下去作更明智的事情。集成平台不应在解析/处理信息时遇到性能问题。因为基础应用可高度状态化(stateful)，所以，所提供的信息应帮助集成者“保持其位置(keephis place)”。预先存在的应用已经必须维持该信息的全部。不存在集成平台/集成者还必须维持该信息的需要。

现有技术的解决方案趋向于将基于XML或对象的SIP消息推入集成平台。这迫使集成平台解析/处理SIP消息的表示。在大多时间，该力度级别不是必须的，并且，迫使集成平台支付解析/存储成本是过分的。现有技术的解决方案还将“无状态(stateless)”或几乎无状态的消息传递到集成平台。对于集成者来说，获取任何明智选择需要集成者在本地维持状态历史。这是不需要的实现负担，其将产生(spawn)很多琐碎的变化，并使重用困难。

根据一个说明性实施例，提供状态格式，以便在CAI的引擎的通知、引导、查询、规定和动作操作内使用。该格式使用从具有SIP/调用流程扩展的WSDL得到的XML表示来呈现交互请求/响应内的状态。将此状态格式与通知、引导、查询、规定和动作范例组合，以提供非常丰富/具有表现力的接口，以便在它们的完整的寿命周期期间操纵调用。

对于通知和引导交互，状态格式包括自从最后一次出现通知和引导起的操作参数的改变、以及执行历史的改变(如在调用流程中定义的那样)。调用流程改变历史描述自从最后的输出通知/引导交互起的附加的信令/执行。对于查询交互，状态格式包括自从请求方最后一次激活相同的操作起的操作参数的改变、以及执行历史的改变。例如，查询可包括自从对于相同的调用而发出查询起的所有改变。对于动作和规定交互，状态格式可包括操作参数的改变，但很可能不包括执行历史。

说明性实施例的状态格式使用具有SIP/调用流程扩展的WSDL，作为其状态信息的基础，集成者利用在对预先存在的应用行为建模时取得的相同级别的粒度/抽象(abstraction)来工作。如果需要，则集成者可使用SOAP附件，利用基础信令来工作。这允许集成者向下访问到SIP字节级别(如果需求要求这样的话)。因为惊人(gory)的信令细节作为SOAP附件加载(ride)，所以，不强制SOAP引擎在处理输入通知、引导等交互网络服务请求时解析或理解它们。因为通知、引导和查询状态信息包括自从集成平台最后一次接收到通知、引导和查询请求起的改变历史，所以，集成者具有宽松的时间来实现“仅在X改变了时才做某件事”的行为。

现有技术的工具独立地对待网络服务接口、以及集中应用设计。由于在实现中需要重新考虑(reconcil)两个接口，所以，这增大了集中应用设计的复杂度。根据说明性实施例，接口设计工具包括传统的调用流程设计视图(这样的视图可能使用调用流程内的消息交换的序列图)、以及传统的WSDL接口设计视图。调用流程设计视图可允许将调用流程分组为交换的片段，并还允许标记片段中的每个消息，如唯一号码或字母数字的标记。该工具允许创建者在WSDL操作和调用流程之间映射。可用交互类型来标记该映射。可视化实体对象的输出可为WSDL和调用流程XML文档，其中，包括了附加的绑定，用于捕获交互关系的操作。

图8绘出了根据说明性实施例的接口设计工具用户界面。接口设计工具窗口800包括WSDL接口设计部分802、以及多个调用流程片段设计部分804。例如，开发者可使用橡皮带(rubber-band)工具，而将WSDL元素与调用流程步骤或消息。例如，橡皮带组件806表示“endCall”WSDL组件和片段3中的步骤10之间的映射。还将此映射标记为“动作”交互。

图9是图解根据说明性实施例的具有扩展的网络服务描述语言的集中应用的操作的流程图。将理解，可通过计算机程序指令来实现流程图图示的每块、以及流程图图示中的块的组合。可将这些计算机程序指令提供给处理器、或其它可编程数据处理设备，以产生机器(machine)，使得在处理器或其它可编程数据处理设备上执行的指令创建用于实现在流程图块中指定的功能的部件。还可将这些计算机程序指令存储在计算机可读存储器或存储介质中，其可引导处理器或其它可编程数据处理设备以特定方式起作用，使得在计算机可读存储器或存储介质中存储的指令产生制造产品，其包括实现在流程图块中指定的功能的指令部件。

因而，流程图图示的块支持用于执行所指定的功能的部件的组合、用于执行所指定的功能的步骤的组合、以及用于执行所指定的功能的程序指令。还将理解，可通过基于执行特定功能或步骤的专用硬件的计算机系统、或通过专用硬件和计算机指令的组合，而实现流程图图示的每个块、以及流程图图示中的块的组合。

参照图9，操作开始，并且，开发者将网络服务描述语言(WSDL)结构与调用流程可扩展标记语言(XML)相关联(块902)。开发者使用调用流程绑定，而将具有调用流程片段的WSDL中的操作与消息点合并(块904)。开发者可使用例如图8所示的接口设计工具的接口设计工具，而合并操作。

接下来，根据网络事件、或通过取消调用流程片段的操作，在集中应用集成(CAI)引擎、或集中应用执行(CAE)引擎中，集中应用开始执行(块906)。CAI或CAE引擎确定是否到达了下一个绑定点(块908)。如果未到达下一个绑定点，则CAI或CAE引擎确定是否存在退出条件(块910)。例如，如果应用完成了执行、或服务器关机，则可能存在退出条件。如果不存在退出条件，则操作返回到块908，以确定是否到达了下一个绑定点。如果在块910、存在退出条件，则操作结束。

返回到块908，如果到达了下一个绑定点，那么，CAI或CAE引擎确定交互类型是否为查询(块912)。如果交互类型是查询，则CAI或CAE引擎查询调用流程的状态(块914)。之后，操作返回到块908，以确定是否到达了下一个绑定点。

如果交互类型不是查询，则CAI或CAE引擎确定交互类型是否为通知(块916)。如果交互类型是通知，则CAI或CAE引擎将来自服务实现的通知发送到实现方，该通知指示已出现了应用中的点(块918)。之后，操作返回到块908，以确定是否到达了下一个绑定点。

如果交互类型不是通知，则CAI或CAE引擎确定交互类型是否为引导(块920)。如果交互类型是引导，则CAI或CAE暂停调用流程的执行(块922)，并调出到外部网络服务终点，以使用绑定操作来接收引导(块924)。之后，操作返回到块908，以确定是否到达了下一个绑定点。

如果交互类型不是引导，则CAI或CAE引擎确定交互类型是否为规定(块926)。如果交互类型是规定，则CAI或CAE提供有关如何在执行流程内作出判定的描述性规则(块928)。之后，操作返回到块908，以确定是否到达了下一个绑定点。

如果交互类型不是规定，则交互类型为动作，并且，CAI或CAE引擎取消调用流程的片段(块932)。之后，操作返回到块908，以确定是否到达了下一个绑定点。

图10是图解根据说明性实施例的预先存在的集中应用的操作的流程图。操作开始，并且，开发者在集中应用集成(CAI)引擎中，捆绑预先存在的集中网络服务/SIP或仅用于SIP的应用(块1002)。随后，CAI引擎生成网络服务实现和SIP小服务程序(块1004)。CAI引擎监听应用特定信令(块1006)，，并且，确定是否到达过渡(块1008)。

如果未到达过渡，则操作返回到块1006，以监听应用特定信令。如果在块1008中、到达过渡，则CAI引擎维持状态信息(块1010)。CAI引擎产生或接受使用网络服务的交互请求(块1012)。之后，操作返回到块1006，以监听应用特定信令。

图11是图解根据说明性实施例的新的集中应用的操作的流程图。操作开始，并且，开发者将SIP调用流程定义分解为一组SIP小服务程序、以及一组网络服务实现(块1102)。随后，开发者填充商业逻辑(块1104)，并且，将包括用于集中应用的WSDL、SIP小服务程序、以及网络服务实现的实体对象与集中应用执行(CAE)引擎特定部署描述符一起封装(块1106)。该部署描述符指示正在使用的WSDL+SIP调用流程、适当的应用状态模型、以及应在运行时间向CAE引擎注册的任意监听器。

接下来，在运行时间，CAE引擎耗用用于集中应用的WSDL(块1108)，并且，CAE引擎注册监听器(块1110)。CAE引擎监听应用特定的信令(块1112)，并确定是否到达过渡(块1114)。如果未到达过渡，则操作返回到块1112，以监听应用特定信令。如果在块1114中、到达过渡，则CAE引擎维持状态信息(块1116)。CAE引擎产生或接受使用网络服务的交互请求(块1118)。之后，操作返回到块1112，以监听应用特定信令。

现有技术的创建集中服务的方法需要用于编写SIP小服务程序的基本的网络专门知识。另外，网络服务接口趋向于通过较高级的接口而与应用交互，并且，由此，该实现必须致力于支持抽象。这是耗时的过程，并且，集中服务的创建者必须使用正式的(full fledged)编程环境来产生可通过此抽象而寻址的调用流程逻辑，如SIP小服务程序。

上述说明性实施例的对WSDL的接口扩展提供了有关网络实现的实现行为的重要的信息量。该接口还以这样的方式定义接口的语义：如果将调用流程分段为适当的单元，则可将核心、高级判定逻辑形象化为更高级的处理工具。说明性实施例可通过将每个片段的执行委派到所生成的代码、或解释引擎，而针对此分别(separation)生效。在每个绑定点上，可将控制传递到外部部件，如处理服务器，以确定接下来要执行哪个片段。可通过包括最后的消息内容(例如，通过SOAP附件)，而在所生成或解释的应用、以及外部世界之间传递信息。

图12是图解根据说明性实施例的自动生成WSDL调用流程实现的开发环境的操作的流程图。操作开始，并且，开发工具接收利用SIP/调用流程交互的扩展的WSDL(块1202)。对于调用流程中的特定的窄范围的消息交换，将容易生成实现。由此，根据说明性实施例，开发工具允许用户选择调用流程中的琐碎的消息交换(块1204)。

SIP小服务程序提供了用于与网络通信的基础结构。开发工具可自动生成这些小服务程序，以形成将在集中应用引擎中执行的应用的模板表单(template form)。可替换地，开发工具可生成可在解释引擎中解释的应用的模板表单。

例如，应用的模板表单可为图7中的集中网络服务/SIP应用722。随后，用户可访问(drop in)较高级的商业逻辑(块1208)。之后，操作结束。网络服务为应用提供较高级的控制逻辑，其也被称为商业逻辑。例如，网络服务可确定接下来要执行哪个调用流程片段。将自动生成的SIP小服务程序、或要解释的应用的模板表单配置为：传递到包括最后的消息内容的网络服务信息。在一个示例实施例中，例如，自动生成的代码可使用SOAP附件而传递此信息。

由此，开发工具自动地生成应用的模板表单(块1206)。在生成模式中，在接口内描述的每个调用流程片段对应于所生成的SIP小服务程序。应当独立地执行片段，如SIP事务。考虑以下例子：INVITE(邀请)→100-180→200→OK(初始和重新邀请)、SUBSCRIBE(订购)→OK→NOTIFY(通知)→OK、分支INVITE、NOTIFY→OK、BYE(再见)→OK等。典型地，如在上面的例子中选择的那样，可选择这些片段，以便暗示并观察片段之间的数据流。可通过使用例如SIP小服务程序setHandler()方法的机制，而实现片段之间的交递。

典型地，将三个绑定交互类型应用于此模型：引导、规定、动作。对于引导和规定，将继续执行，直到到达初始绑定点为止，典型地，在片段的结尾。在这样的点上，如果绑定交互为引导，则将进行调出，以确定接下来要执行哪个片段。调出将提供所附连(例如，通过SOAP附件)的最后的SIP消息。到下一个片段的引导还将采用将输入消息提供给片段的附连。如果绑定点为规定，那么，将商议所关联的规则，以确定接下来要执行哪个片段。还可使用动作交互，以在对话或新的交互中异步地取消调用流程片段(例如，终止)。

所生成的应用可为集中应用。应用可使用会话相似性来将传入请求引导到正在执行所生成的代码的、群集中的相同的应用服务器。这简化了生成模型，从而允许所生成的代码关注于逻辑，并允许应用服务器层处理负载平衡、故障切换等。

调用流程实现的解释执行可类似于所生成的方法。可通过例如国际商用机器公司的WebSphere^语音服务器的调用流程引擎，而执行解释实现。

应理解，说明性实施例可采用整体硬件实施例、整体软件实施例或包括硬件和软件元素两者的实施例的形式。在一个示例实施例中，以软件方式实现说明性实施例的机制，其包括但不限于固件、驻留软件、微码等。

此外，说明性实施例可采用可从计算机可用或计算机可读介质访问的计算机软件产品的形式，所述介质提供由计算机或任何指令执行系统使用或者由计算机和任何指令执行系统联合使用的程序代码。为了此描述的目的，计算机可用或计算机可读介质可为任何能够包含、存储、通信、传播或传输该程序的设备，其中由指令执行系统、设备或装置使用、或由指令执行系统、设备或装置联合使用所述代码。

介质可为电、磁、光、电磁、红外、或半导体系统(或者设备或装置)、或传播介质。计算机可读介质的例子包括半导体或固态存储器、磁带、可拆卸计算机盘、随机存取存储器(RAM)、只读存储器(ROM)、固体磁盘和光盘。光盘的当前例子包括致密盘-只读存储器(CD-ROM)、致密盘-读/写(CD-R/W)、以及DVD。

适于存储和/或执行程序代码的数据处理系统将包括直接或通过系统总线而间接耦接到存储元件的至少一个处理器。所述存储元件可包括在程序代码的实际执行期间采用的本地存储器、大容量存储装置、以及提供对于至少一些程序代码的暂时存储以便减小在执行期间必须从大容量存储装置检索代码的次数的高速缓冲存储器。

输入/输出或I/O装置(包括但不限于键盘、显示器、定点装置等)可直接或通过中间I/O控制器而耦接到该系统。网络适配器也可耦接到该系统，使得数据处理系统能够通过中间专用或公共网络而耦接到其它数据处理系统、或到远程打印机或存储装置。调制解调器、有线电视调制解调器、以及以太网卡正是当前可用的网络适配器的类型中的一些。

为了说明和描述已经呈现了本发明的描述，并且不意于以公开的形式穷举或限定本发明。本领域的技术人员将理解，可出现许多修改和改变。为了最佳地解释本发明地原理、实践应用和使得本领域的技术人员能够理解本发明对于具有各种修改的各种实施例适于预期的特定使用，选择并描述了实施例。

Claims

1.一种在用于执行具有调用流程交互的集中网络服务应用的数据处理系统中的方法，该方法包括：

接收扩展描述语言文档，该扩展描述语言文档描述一个或多个网络服务接口组件，已在该扩展描述语言文档嵌入了用于一个或多个调用流程片段的调用流程描述，并且，该扩展描述语言文档包括至少一个调用流程绑定，其中，所述至少一个调用流程绑定将交互操作与所述一个或多个调用流程片段中的给定调用流程片段中的绑定点相关联；

从所述一个或多个调用流程片段中选择一个或多个消息交换；

自动生成用于一个或多个所选消息交换中的每个的实现，以形成应用模板；

为所述一个或多个网络服务接口组件提供所述应用模板中的商业逻辑，以形成集中应用；以及

执行该集中应用。

2.如权利要求1所述的方法，其中，该描述语言文档是网络服务描述语言文档。

3.如权利要求1所述的方法，其中，所述一个或多个调用流程片段包括一个或多个会话启动协议调用流程片段。

4.如权利要求1所述的方法，其中，从所述一个或多个调用流程片段中选择一个或多个消息交换包括：

从用户接收对一个或多个消息交换的选择。

5.如权利要求1所述的方法，其中，自动生成用于一个或多个所选消息交换中的每个的实现包括：

自动生成一个或多个小服务程序，其中，所述一个或多个小服务程序中的每个对应于所述一个或多个调用流程片段中的一个。

6.如权利要求5所述的方法，其中，所述一个或多个小服务程序包括一个或多个会话启动协议小服务程序。

7.如权利要求5所述的方法，其中，执行集中应用包括：

在集中应用执行引擎中执行应用模板。

8.如权利要求1所述的方法，其中，执行集中应用包括：

在解释引擎中解释应用模板。

9.一种用于执行具有调用流程交互的集中网络服务应用的数据处理系统，包括：

处理器；以及

耦接到该处理器的存储器，其中，该存储器包含指令，所述指令在被该处理器执行时使得该处理器：

执行该集中应用。

10.如权利要求9所述的数据处理系统，其中，自动生成用于一个或多个所选消息交换中的每个的实现包括：

11.如权利要求10所述的数据处理系统，其中，执行集中应用包括：

在集中应用执行引擎中执行应用模板。

12.如权利要求9所述的数据处理系统，其中，执行集中应用包括：

在解释引擎中解释应用模板。