专利名称：Web服务注册和操作方法
背景技术：
许多协议和标准已被用来推动通过互联网的业务流程。统一描述、发现和集成(UDDI)规范使用可扩展标记语言(XML)文件，定义机制来发布和发现有关“web服务”的信息。术语web服务描述的是由一个公司提供的业务功能，使其它公司、个人、或软件程序能够访问此服务。例如，金融服务公司使用合适的编码交易和依照统一描述、发现和集成(UDDI)标准定义的应用程序接口(API)呼叫，可以使顾客能够获得股票报价。
统一描述、发现和集成(UDDI)定义的“businessEntity”业务实体结构，包括“白页”、“黄页”、和“绿页”部分。“白页”部分包括有关业务的地址信息、联系信息、和已知标识符。“黄页”部分包括基于标准分类的行业类别。“绿页”部分描述业务发布的服务。“businessService业务服务”和“bindingTemplate绑定模板”结构被定义用于“绿页”部分。businessService业务服务结构是一个描述性容器，被用于对一系列的与业务流程或类别服务有关的web服务进行分组。bindingTemplate绑定模板结构提供实际调用服务所需的信息。通常，bindingTemplate绑定模板结构包括指向有关web服务所支持的规范的指针。
用于业务流程的web标准的另一个例子是业务流程建模语言(BPML)。BPML是一种元语言，用于将业务流程描述成，在可扩展的BPML XML结构顶部分层的特定业务流程建模语言。BPML将业务流程描绘成控制流、数据流、和事件流的结合。BPML有许多限制。具体地，BPML受限于必需预先定义一个完整的业务流程。同样，web服务业务流程执行语言(BPEL4WS)是用来调用业务流程的另一种语言。BPEL4WS类似于业务流程建模语言(BPML)，必须预先定义完整的业务流程。
Web服务描述语言(WSDL)是涉及业务流程的另一种web标准。WSDL使用可扩展标记语言(XML)格式将网络服务描述成一个在消息上进行操作的端点集。WSDL是相当限制的一个标准。特别地，WSDL是方便将业务流程交易绑定到具体网络协议和消息网络格式上。WSDL并不是提供一个抽象元模型或一个框架用于整合业务流程。
概述 典型实施例涉及一个智能注册中心用于整合web业务服务。注册中心使得整合服务的基于模型开发成为可能，并提供用于服务建模的实体和用于动态查询标准的词汇。在一个实施例里，智能注册中心提供一个动态的、可扩展的、和充分表达的元模型。元模型被用来定义域模型。域模型是特定业务块或项的模型。例如，使用元模型可以开发旅游行业的域模型。域模型是可以重复使用的，且在配置之后能够被用于许多不同的应用。
在抽象层面，一个域可以根据业务服务提供者、类别定义和服务定义而建模。在一个实施例里，“businessServiceProvider”业务服务提供者结构被用作抽象结构，在有关域内提供有关一种业务实体的元数据。在旅游域内可以定义businessServiceProvider业务服务提供者文档的业务实体的实例包括航空公司、酒店、饭店、租车中介等。在businessServiceProvider业务服务提供者内，categoryDefinition类别定义结构描述分类方案。典型地，对于每个相应的类别项，categoryDefinition类别定义结构可以包括有效数值或有效范围的一个集合。categoryDefinition类别定义结构提供一个查询功能基础。同样，在businessServiceProvider业务服务提供者结构内，serviceDefinition服务定义结构可以抽象地描述特定类型的业务实体可以或必须提供的web界面。通过识别或参考可扩展标记语言(XML)文档或业内参与者同意的其它公开标准，可以定义web界面。
在抽象模型基础上建造，并使一系列应用能够访问元模型和导出实例，便可以实现web服务整合。例如，域建模专家可以利用域建模应用，在智能注册中心上定义域模型XML文档。然后，业务实体可以访问域模型XML文档，通过发布应用发布它们的web服务。业务流程工程师使用业务流程设计应用，可以访问发布了的web服务，实现一个从开始到结束的业务流程。在业务流程的运行时间里，业务流程执行引擎可以使用由其它应用建立的数据结构和文档，为用户或特定的软件实体，调用设定的业务流程。在运行时间上，业务流程可以使用服务定义和注册的合资格的服务提供者，依照设定的业务流程动态地选择服务。
一些典型实施例提供的注册功能不同于已知业务服务注册标准。例如，统一描述、发现和集成(UDDI)很少提供通用业务注册。规范是灵活的，以适应不同的应用需要。结果，UDDI不会阻止同行业内的业务被发布给具有不同信息的UDDI注册。UDDI在发布业务界面上不会强制任何统一的技术界面。相应地，注册业务可以发布任何类型的私有标准。另外，UDDI不会去关联两个相同类型业务。例如，尽管可以定位找到依照UDDI注册的同一类别的业务，但是不能推断每个找到的业务支持相同类的界面。
依照一些典型实施例，通过引入元模型，提供一种语言在域模型上定义“businessEntity”业务实体结构。域模型可以被看作独立的规范集合，能够在服务整合流程的不同阶段被分配到不同的应用中。发布应用可以强制由域模型定义的结构。在设计时，业务流程工程师可以定义具有查询标准(抽象服务)的服务建造模块和具有固定接入点信息(具体服务)的模块。然后，将实际服务捆绑到抽象服务(“具体化”)可以被延迟直到运行时间。简而言之，如果没有域模型，抽象服务的具体化将不可能轻易实现，也不可能有用于有效创建服务的应用工具。
前面已经广义地概括了本发明的特点和技术优越性，以便可以更好地理解后续的本发明的详细说明。本发明的其它特点和技术优越性将在此后说明，它们构成本发明的权利要求的主题。应该理解，这里公开的概念和具体实施例可以很容易地用于修正或设计实现本发明的相同目的的构造的基础。还应认识到，这样的等同结构不脱离所附权利要求定义的本发明范围。本发明的特征的创新点，即指其结构也包括操作方法，以及其它的目的和优点，这些将在后面结合附图的说明中更好地理解。但是还应理解，每个附图是用于说明的目的，不用来限定本发明的范围。
为了更全面地理解本发明，现参考结合附图的下述说明，其中 图1描述依照一个典型实施例的用于抽象建模业务类型的数据结构。
图2描述依照一个典型实施例的用于整合web服务的系统。
图3描述依照一个典型实施例的整合web服务的流程图。
图4描述依照一个典型实施例的执行业务流程脚本的流程图。
图5描述依照一个典型实施例的业务流程脚本。
发明详述 现参考附图，依照一个典型实施例，图1描述元模型100。元模型100包括businessServiceProvider业务服务提供者结构101。本质上，businessServiceProvider业务服务提供者101是一个形成唯一技术签名的定义集，业务实体在相关业务域内依照设定的业务类型进行注册时必须符合该签名。例如，businessServiceProvider业务服务提供者结构101的一个具体例子是旅游域内的航空公司业务实体。在旅游域内注册为航空公司的业务实体可以要求提供一个详细的航班到达时间的界面、一个提供起飞时间的界面、一个预定航班的界面等。
在一些典型实施例里，businessServiceProvider业务服务提供者结构101可以包含0个或多个类别定义和服务定义。为此，可以使用两个子结构，categoryDefinition类别定义结构102和serviceDefinition服务定义结构103。categoryDefinition类别定义结构102可以被用来实现分类方案。在一个实施例里，categoryDefinition类别定义结构102是一个保留多个统一资源标识符(URIs)和定位器数据元素的容器。每个统一资源标识符(URI)可以被作为一个指针指向提供类别信息的技术规范。有可能的是，有关规范可以定义多个类别类型。定位器数据元素可以被用来准确定位规范的相关部分。定位器数据元素的语法可以依照技术规范的类型的不同而不同。serviceDefinition服务定义结构103描述businessServiceProvider业务服务提供者结构101的有关业务实体可以或必须实现的界面。在一个实施例里，serviceDefinition服务定义结构103是一个或多个统一资源标识符(URIs)的一个容器，URIs指向描述web界面的有关技术规范。例如，统一资源标识符(URI)可以指向一个使用web服务描述语言(WSDL)编码的文档。
businessServiceProvider业务服务提供者结构101，categoryDefinition类别定义结构102和serviceDefinition服务定义结构103的实施，不需要依照特定的数据结构或文档而被严格定义。相反，可以在抽象层面上定义结构101-103。通过从严格实施当中对结构101-103进行去藕，可以确认智能注册服务器的高层面运作，而不会影响模型规范的未来扩展。
根据业务类型、分类定义和web服务定义，对业务域进行建模，一些典型实施例可以实现一些已知的web服务标准里没有的功能。例如，UDDI使业务实体提供的web服务注册成为可能。但是，UDDI注册流程是一个开放式机制，任何特定的业务实体能够注册任何类型的web服务，包括它自己专有的web服务。在多个业务实体之间整合web服务是困难的，因为不知道业务伙伴将是否提供合适的web服务，直到业务伙伴完成UDDI注册流程。相反，一些典型实施例可以整合web服务，而不管具体web服务的特定注册。相反，业务域模型提供业务流程设计的基础，由此抽象地描述服务。相应地，可以选择抽象服务，作为调用多个业务伙伴的多种web服务的一个业务流程的建造模块。在执行业务流程的运行时间，可以动态地选择注册的业务实体，来执行设定的抽象服务。
依照一个典型实施例，图2描述支持web服务整合的业务流程系统200。业务流程系统200包括多个客户201，通过网络213通讯连接到智能注册202上，使服务整合成为可能。作为例子，使用合适的计算机平台(具有一个或多个处理器214、储存设备、存储器215、网络硬件216等)和可执行代码或软件，可以实现智能注册中心202。
如图2所示，智能注册中心202包括存储有关业务流程数据的非易失性(non-volatile)储存器203。存储的数据包括域文档204。域文档204最好是描述有关业务块或项的可扩展标记语言(XML)文档。例如，可以建立域文档204，用于旅游行业、消费汽车销售行业、消费数字内容行业等。域文档204最好使用由businessServiceProvider业务服务提供者结构101定义的抽象元模型，根据分类和提供的服务在业务域内定义业务类型。智能注册中心202可以包括由businessServiceProvider业务服务提供者结构101的categoryDefinition类别定义结构102和serviceDefinition服务定义结构103引用的类别文档205和服务文档206。但是，智能注册中心202不需要存储这些文档。另外或者，结构102和103的统一资源标识符(URIs)可以参考存储在其它服务器上的文档。
业务实体文档207使得业务实体可以注册，可以发现它们发布的服务。业务实体文档207可以识别业务实体、地址信息、联系信息等的公司标识符。再者，业务实体文档207可以识别与业务实体相符的businessServiceProvider业务服务提供者结构101。在businessServiceProvider业务服务提供者结构101内，数值范围和可选服务是有可能的。业务实体文档207可以识别与分类信息相关的特定数值。同样，业务实体文档207可以识别由业务实体发布的可选服务。
另外请注意，一些典型实施例不需要在业务实体提供者上强加严格的web服务定义。例如，通过提供适配模块，具有非一致web服务的服务提供者可以使用注册中心202。对这种提供者的专有或非标准界面，适配模块可以执行消息和其它转换功能。相应地，这种提供者的非一致服务可以透明地被应用在注册中心202上。
业务流程文档208根据在服务文档206里识别出的服务定义各个业务流程。另外，通过明确地识别提供服务的业务实体或通过定义分类标准和/或其它合适的标准，可以定义业务流程，在业务流程运行时动态地选择业务实体。
智能注册中心202包括多种应用操作，以促进整合业务服务。例如，智能注册中心202包括域设计应用209，使得域专家能够通过在各个客户201上的软件建立域。域设计应用209可以采用合适的图解控制和其它用户显示元件，使域模型的建造模块形象化，如businessServiceProvider业务服务提供者、categoryDefinition类别定义、和serviceDefinition服务定义结构。域专家可以建立一个文档，描述在各个行业内的业务实体类型、分类方案、和业务实体类型采用的服务。
另外，与categoryDefinition类别定义和serviceDefinition服务定义结构相关的技术规范(如WSDL文档)以URL格式使用唯一的标识符，以便能够在将域模型配置到注册中心202上时查找文档。基于域模型的名字空间以及serviceDefinition服务定义和categoryDefinition类别定义的名字，通过导出唯一的统一资源定位符(URL)路径，域设计应用209可以支持一个自动URL创建算法。另外，域设计应用209可以支持技术规范的语法检查，来验证在域内包括的文档的语法正确性。
当一个业务实体决定披露其服务(“发布”)，业务实体中介可以使用发布应用210查询智能注册202，获得有关设定的业务域和在此域内业务类型的相关信息。用户可以选择域和域内一个或多个businessServiceProvider业务服务提供者结构。然后，与选择的结构相关联的部分规范被提供给此用户。通过提供规范信息来响应用户选择，可以避免下载和管理不必要的数据。
此外，发布应用210呈现一个用户界面适应选择的域模型和businessServiceProvider业务服务提供者。依靠各个businessServiceProvider业务服务提供者，用户界面可以适当地显示类别项对应分类数值。例如，“酒店星级水平”项将仅仅对应在“旅游”域内的“酒店”项。在类别项内，可以提供有效数值或数值范围供用户选择。发布应用210可以获得其它有关信息，如业务名称、业务地址、联系信息。而且，通过用户界面可以识别找到相关的界面。例如，可以将与界面相关联的统一资源定位符(URL)输入到各个项内。在获得相关信息之后，发布应用210建立一个业务实体文档207来编码此信息。
查询界面217可以用来识别那些使用发布应用210已发布其web服务的业务。例如，包括一个或多个查询参数的查询项可以被传送给查询界面217。查询参数可以设定与分类信息相关联的数值或数值范围。例如，对“酒店”businessServiceProvider业务服务提供者，具有“五星”查询参数的查询项可以被递交给查询界面217。查询界面217可以检索业务实体文档207，来寻找满足查询参数的实体。通过传送包含匹配业务实体的文档，查询界面217可以响应接收到的查询项。在业务流程的运行时，来自查询界面217的响应可以用来动态地选择web服务，这些将在以下进行描述。
业务流程工程师可以访问业务流程设计应用211，来识别找到相关的服务定义，作为业务流程的建造模块。例如，旅游中介可以实施一个业务流程，该业务流程使用航空公司、酒店、租车中介等注册服务。
在一个典型实施例里，业务流程设计应用211提供图形符号来表示业务流程。业务流程设计应用211可以包括一个可视业务流程模型器、服务定义编辑器、和业务流程脚本产生器。可视业务流程模型器可以提供图形环境给业务流程工程师，在业务流程内定义建造模块的作业流和次序。服务定义编辑器使业务流程工程师能够定义业务流程选择的服务是否是具体服务(即注册业务实体清楚发布的服务)或抽象服务(即普通描述的服务且不需要识别特定支持业务实体)。如果定义抽象服务，可以采用在运行时随后使用的标准来选择对应抽象服务的具体服务。当完成设计时，业务流程工程师可以使用业务流程脚本产生器来建立业务流程脚本。
可以采用业务流程执行引擎212来执行业务流程。业务流程执行引擎212可以检索找到相应业务流程文档208。业务流程执行引擎212可以处理从用户接收到的信息，作为业务流程的输入。可以应用接收到的信息来查询业务实体文档207，并使用查询界面217识别找到合适的服务。同样，抽象服务设定的标准被用于查询业务实体文档，来识别找到合适的具体服务。使用在业务实体文档207内的编码信息，服务的访问点被定位找到。接着，服务被调用，且合适的信息被传送给此服务。一个调用的服务接收到的信息可以被提供给一个随后调用的服务，来提供一个协调的业务流程流。
尽管图2描述了使用集成式和集中式构造的智能注册中心202，但本发明并不限于此。如果需要的话可以采用分布式构造。例如，域文档204、类别文档205、服务文档206、业务实体文档207、和业务流程文档208可以由分离的服务器保留。同样，应用209-212可以在其它服务器上实施，服务器使用API呼叫或其它合适的功能访问文档204-208。
依照一个典型实施例，图3描述了整合业务服务的流程图。使用来自任意合适的计算机可读媒介的软件代码或可执行指令，可以部分地实施图3的流程图。在步骤301，建立业务域。在步骤302，根据将被业务类型采用的分类数值和web服务，在建立的域内定义业务类型。在步骤303，域定义可以被存储在注册平台(如智能注册中心202)上，来支持查询操作。在步骤304，从业务实体接收信息，在建立的域内将实体注册为一个或多个业务类型。在步骤305，接收到的信息可以被存储在智能注册中心上，使访问信息来发现业务成为可能。在步骤306，接收信息来定义业务流程。使用在建立的域内描述的服务、涉及类别信息和其它有关标准的查询、消息交换、和业务逻辑，来定义业务流程。在步骤307，建立业务流程文档，并将它存储在智能注册中心上。在步骤308，使用存储的文档，执行业务流程。另外，依照设定的选择标准和在运行时提供的选择标准，注册业务实体的动态查询可以用于选择业务服务，以供在业务流程执行期间调用。
在一个实施例里，定义了一种智能业务流程建模语言(iBPML)，使得可以描述业务流程流，而不需要在业务流程创建和部署时确认具体服务。一个iBPML编码的业务流程，根据在web服务和用于处理消息和/或选择web服务的业务逻辑之间的消息交换，来描述业务流程。以这种方式描述业务流程，对涉及两个或多个业务伙伴的复杂业务功能，可以进行服务编制(Service Orchestration)。
在一个实施例里，iBPML采用WSDL 1.1标准和XML schema 1.0标准，来提供由iBPML业务流程使用的数据模型。iBPML也可以包括依照XML协定定义的其它数据结构，来保留业务流程的状态定义，并使得在业务流程执行期间可以进行业务逻辑操作。iBPML可以包括依照XML协定定义的数据结构，使得在多个业务流程之间可以交换消息。因为可以协调多个业务流程，与具有不同粒度级别的唯一数据要求的每个单元一起，嵌套的工作单元可以被激活。另外，通过使用XML协定，从用于实现相关的web服务的支持平台和程序语言，可以独立地描述业务流程。
使用iBPML的业务流程开发使得可以选择不同的服务提供者，对应不同情境或不同需要。在设计时静态查找标准是已知的，且能够在iBPML文档内被直接编码。但是，在运行时，可以找出一些服务提供者满足静态查找标准。可以采用另外的标准，使得在多个服务提供者之间可以动态地选择。可以获得另外的标准，作为输入提供给业务流程，或可以由前面执行的web络服务的结果建立另外的标准。以这种方式的标准动态应用，使得可以灵活执行业务流程，情境感知(context-aware)顾客偏好。
依照一个典型实施例，图4描述了使用iBPML文档编码的业务流程脚本的执行流程图。使用来自任意合适的计算机可读媒介的软件代码或可执行指令，图4的流程图也可以部分实现。在步骤401，开始执行业务流程，可选地输入参数，并被传送给脚本。这些输入参数可以来源于一个用户。例如，通过超链接标记语言(HTML)表单，可以提供图形用户界面给用户，在执行脚本之前获得信息。另外或者，输入参数可以从先前执行脚本的结果获得。在步骤402，为响应在业务流程脚本里的代码，查询注册中心以获得依照查询参数提供web服务的业务实体列表。查询参数可以被静态定义。或者，查询参数可以包括输入参数。在步骤403，依照在业务流程脚本里定义的选择策略，从此列表里选择一个业务实体。在步骤404，可以查询注册中心以获得由业务实体提供的web服务位置。在步骤405，调用业务实体的web服务。有关执行业务流程脚本的其它细节将在图5中讨论。
例如，假设一个旅游中介专门提供“豪华”度假套餐。这个旅游中介可以创建一个业务流程，通过第三方业务实体的web服务做出必要的预订，来提供度假套餐给顾客。为了提供这种套餐，可以建立业务流程脚本，以查询智能注册中心202，在旅游域内查询具有“五星”级别的酒店。因为旅游中介专门提供豪华度假，在业务流程脚本内定义的五星级别标准可以是静态的。为响应查询，可以获得在用户目标范围内的多个酒店列表。业务流程脚本可以定义一个选择策略，应用一个或多个标准从酒店列表里选择一个特定酒店。在选择特定酒店之后，业务流程脚本可以呼叫酒店的web服务，以作出适当的预订。
作为另一个例子，旅游中介可以通过一些机制使顾客能够支付度假套餐。使用超链接标记语言(HTML)表单，可以得到用户作出的选择。此选择可以被传送给业务流程脚本，作为输入参数。由于选择标准不是静态定义的，设定所需支付方法的输入参数被传送给业务流程脚本的查询操作。然后，业务流程脚本可以动态地定位找到一个或多个业务实体提供者以响应用户选择。可以应用选择策略逻辑来选择单个业务实体提供者。可以执行另一个查询，以获得被选业务实体提供者的web服务位置。然后，呼叫web服务来执行支付服务。
依照一个典型实施例，图5描述了业务流程脚本500。在脚本500上，<invoke>调用单元507和508是命令脚本，分别被用来调用“airlinePartner”(航空公司伙伴)和“hotelPartner”(酒店伙伴)的web服务。详细的伙伴信息分别由<partner>伙伴单元503和504描述。
如前所述，某些典型实施例能够将具体和抽象的web服务包含在业务流程脚本里。如业务流程脚本500所示，当选择一个具体服务时，在<invoke>调用单元507里的“abstract”(抽象)属性数值被设定成false(假的)，从而显示一个具体的web服务将被调用。<partner>伙伴单元503的“key”关键属性数值(即“Entity_Key-1”)指向被调用的特定web服务。在<invoke>调用单元508里的抽象属性数值被设定成假的，从而显示在运行时动态地选择被调用的web服务。在<partner>伙伴单元504里不提供任何关键属性，因为将动态地选择web服务。
如业务流程脚本500所示，抽象的“hotelPartner”酒店伙伴服务调用是基于<partner>伙伴单元504里的“categoryContainer”类别容器属性数值。此数值指向存储有标准的<container>容器单元502。业务流程工程师可以明确地定义用于抽象服务的标准。例如，在<assign>赋值单元505里，业务流程脚本500包括“five star”五星级别。也可以定义标准，作为输入提供给业务流程，或可以由先前执行的web服务(如在<assign>赋值单元506里所示)的结果建立。业务流程引擎212从<container>容器单元502获得标准，并传送标准给智能注册中心202。智能注册中心202作出响应，传送对应标准的web服务标识符。
当智能注册中心202识别找到多个web服务时，可以采用选择策略来选择一个web服务以调用。在业务流程脚本500里，在<partner>伙伴单元504里的selectionStrategyContainer选择策略容器属性数值指向含有选择标准的<container>容器单元501。业务流程工程师可以明确地定义选择标准。另外或者，从输入到业务流程可以获得选择标准，或可以建立选择标准作为先前执行web服务的结果。<assign>赋值单元可以用来包括在<container>容器单元501里的标准。
一些典型实施例可以提供多个优点。例如，根据业务服务提供者的类型，可以使用灵活的元模型来建立业务域。另外，建立业务域使得能够以组织有序的方式和最低复杂度地发布web服务。而且，建立业务域使得能够有效率地建立业务流程。此外，一些典型实施例使用业务域模型能够抽象地定义业务流程，并能够在运行时动态地绑定具体服务。
虽然已经详细说明了本发明及其优越性，但应理解，在不脱离所附权利要求定义的本发明的条件下可以做出各种改变，替换和变化。此外，本申请的范围不限定到此处说明书中描述的处理方法，机器，制造，物质构成，手段，方法和步骤等的特定实施例。从说明书可以容易理解，可以利用实质上执行了与这里说明的相应实施例相同功能或实现了相同结果的目前已有的或者将来会开发出的处理方法，机器，制造，物质构成，手段，方法和步骤。因此，所附的权利要求书旨在包括这些处理方法，机器，制造，物质构成，手段，方法或步骤。
权利要求
1.一种方法，包括建立业务域数据结构，识别业务项；为所述业务域数据结构建立业务类型数据结构，在业务项内定义业务类别；为所述业务类型数据结构建立类别定义，提供有关业务类别的描述信息；为所述业务类型数据结构建立web服务定义，识别由业务类别提供的且通过通信网络可以访问的软件界面；和通过经由通信网络可以访问的注册平台，对所述业务域数据结构、业务类型数据结构、类别定义、和web服务定义提供访问进入。
2.根据权利要求1所述的方法，还包括使用一个业务类型数据结构在所述注册平台注册业务实体，显示所述业务实体，作为在一个所述业务类别里的业务。
3.根据权利要求2所述的方法，其中所述的注册包括识别所述业务实体的类别数值。
4.根据权利要求2所述的方法，其中所述的注册包括识别由所述业务实体实施的一个或多个web服务的网络位置。
5.根据权利要求2所述的方法，还包括在所述注册平台上处理查询，来识别依照一个或多个查询参数实现web服务的注册业务实体。
6.根据权利要求5所述的方法，其中所述的处理发生在执行业务流程脚本期间。
7.根据权利要求6所述的方法，还包括为了响应所述注册平台处理的查询，通过业务流程脚本，在识别出的多个业务实体之间进行选择。
8.根据权利要求6所述的方法，还包括从用户接收输入，用于业务流程脚本作为查询参数。
9.一种使用可执行脚本执行业务流程的方法，包括查询注册中心，识别找到提供一个web服务的多个业务实体；使用在所述可执行脚本里嵌入的选择逻辑，从所述多个业务实体中选择一个业务实体；识别找到由所述选择的业务实体提供的所述web服务的一个位置；和调用所述选择的业务实体的所述web服务，至少部分地执行所述业务流程。
10.根据权利要求9所述的方法，其中所述的查询注册中心，提供给所述注册中心的查询参数来自用户的输入信息。
11.根据权利要求9所述的方法，其中所述的查询注册中心，提供的查询参数来自执行另一个业务流程可执行脚本。
12.根据权利要求9所述的方法，其中所述的查询注册中心，提供的查询参数是在所述可执行脚本里被静态编码。
13.根据权利要求9所述的方法，其中所述的查询注册中心，提供的查询参数，可以识别与一种类业务实体定义的分类方案相关联的一个或多个数值。
14.一个注册平台，包括域结构，用于识别业务项；业务类型结构，用于在业务项内定义业务类别；类别定义结构，用于提供有关所述业务类别的描述信息；web服务定义结构，用于识别由所述业务类别提供的界面；和查询界面，用于识别依照所述业务类型结构注册的业务实体。
15.根据权利要求14所述的注册平台，还包括域设计应用，用于建立域结构。
16.根据权利要求14所述的注册平台，还包括发布应用，用于依照所述业务类型结构接受信息以注册业务实体。
17.根据权利要求14所述的注册平台，还包括业务流程设计应用，用于建立业务流程脚本，调用依照所述业务类型结构注册的业务实体的web服务。
18.根据权利要求17所述的注册平台，还包括业务流程执行引擎，用于执行所述业务流程脚本。
19.一个执行业务流程脚本的系统，包括用来查询注册中心以获得业务实体列表的装置，提供web服务来响应在所述业务流程脚本内的脚本单元；用来从所述列表选择业务实体的装置，以响应在所述业务流程脚本里的至少一个选择参数；用来识别找到由所述选择的业务实体提供的所述web服务位置的装置；和用来在执行所述业务流程脚本期间调用所述选择的业务实体的所述web服务的装置。
20.根据权利要求19所述的系统，其中所述的查询装置传送查询参数，所述查询参数来自用户的输入信息，此用户启动执行所述业务流程脚本。
21.根据权利要求19所述的系统，其中所述的业务流程脚本包括一个静态定义的参数，所述参数被提供给所述查询装置。
22.根据权利要求19所述的系统，其中所述的查询装置传送查询参数给所述注册中心，识别与一种类业务实体定义的分类方案相关联的一个或多个数值。
全文摘要
一些典型实施例涉及整合web服务的注册中心。注册中心可以包括对行业或业务领域进行建模的域文档或数据结构。根据多个业务类型或分类，域文档可以定义各个行业。通过分类定义和web服务定义，可以定义每个业务类型或分类。web服务定义是那些注册为属于该业务类型的业务实体可以或必须提供的web服务。另外，一些典型实施例利用注册中心在执行业务流程期间动态地选择web服务。
文档编号G06F9/44GK101065947SQ200580029935
公开日2007年10月31日 申请日期2005年9月7日 优先权日2004年9月7日
发明者沈国峰, 吴志刚 申请人:香港应用科技研究院有限公司