法律状态公告日
法律状态信息
法律状态
2011-05-11
授权
授权
2009-04-29
实质审查的生效
实质审查的生效
2009-03-04
公开
公开
技术领域
本发明涉及互联网领域，特别是涉及一种组合业务处理、组合业务替换、具体业务调用的方法、装置以及组合业务系统。
背景技术
业务组合有静态业务组合和动态业务组合之分。其中，静态业务组合中组合业务逻辑事先指定需要调用的具体业务，即在组合业务逻辑运行前指定业务调用，例如可通过图形或文本编辑界面手工生成组合业务逻辑，并提交业务组合引擎。有的业务组合环境提供了图形化用户界面，让用户使用鼠标拖拉从业务目录中选择合适的业务来构建组合业务逻辑。这种机制不能在运行时动态地选择合适的业务来提供给请求者，特别在业务不可访问时存在严重缺陷。
动态业务组合中组合业务逻辑在运行时指定调用的业务，能解决静态业务组合的一些缺陷。目前动态业务组合主要基于语义技术，可以分为半自动组合和自动组合。所述半自动组合在用户定义组合业务逻辑时提供业务语义上的描述，但用户仍需要事先描述被调用业务之间的执行顺序。所述自动组合则只需要提供一些必要参数，就可以自动生成组合业务逻辑，即自动生成业务的调用顺序，并自动选择合适的业务，一般使用AI planning(人工智能推理)等技术进行自动地选择业务和生成业务组合逻辑。
目前，现有技术提供两种将抽象组合业务逻辑转换为具体组合业务逻辑的实现机制。
一种是先定义业务组合的不同阶段，即设计阶段、业务选择阶段、流程生成阶段和运行阶段。其中，先通过使用语义描述的活动(activity)的模板设计业务组合流程；其次，为每个activity动态选择服务，并生成具体的数据流，重复该步骤直到所有activity都被具体业务替换，再次，根据所有具体业务生成可执行的流程；最后，运行可执行的组合业务逻辑。
另一种将activity替换成具体业务的过程为:用服务的Web本体语言(OWL-S，Ontology Web Language for Service)来描述activity，通过语义描述匹配具体业务，生成商业流程执行语言脚本(BPEL，Business ProcessExecution Language)。主要特点是采用OWL-S来描述业务调用。业务组合引擎遍历组合业务逻辑；当遍历到由OWL-S描述的业务调用时，触发“抽象生成具体”流程；业务组合引擎根据OWL-S的业务描述去动态发现具体的业务；组合引擎将具体业务的调用描述来替换OWL-S的业务调用描述；直到替换所有的OWL-S的业务调用描述后生成BPEL脚本。
因此，由上述过程可知，该过程都需要人为提供业务语义上的描述，且实现过程复杂。都是间接将抽象组合业务逻辑转换成具体组合业务逻辑，而不能直接执行抽象组合业务逻辑的机制。同样，在现有技术中，没有涉及到从具体组合业务逻辑生成抽象组合业务逻辑的机制；也不能解决组合业务逻辑执行过程中所调用服务不能访问时的问题。
发明内容
本发明实施例提供一种组合业务处理、组合业务替换、具体业务调用的方法及装置，解决组合业务逻辑执行时能动态选择具体业务的问题。
本发明实施例解决的另一技术问题为:解决在组合业务执行过程中调用具体业务失败时，动态将具体业务替换成另一种同功能的具体业务的问题。
为解决上述问题，本发明实施例提供一种组合业务处理方法，所述方法包括步骤:
获取组合业务逻辑中业务调用片段描述所对应的具体业务，其中所述业务调用片段为抽象业务调用片段或业务模板的片段；
触发业务替换，请求将所述业务调用片段替换成所获取具体业务的具体业务调用片段；或触发业务调用，请求根据所述具体业务生成服务调用。
本发明实施例还提供一种组合业务替换方法，所述方法包括步骤:
获取组合业务逻辑中具体业务调用片段信息对应的业务模板信息；
用所述模板信息替换所述组合业务逻辑中的具体业务调用片段信息。
本发明实施例再提供一种具体业务调用方法，所述方法包括步骤:
当具体业务调用片段所描述的业务不能提供服务时，获取具体业务调用片段描述对应的业务模板信息；
根据所述业务模板信息查询获得具体业务；
根据所述具体业务生成服务调用。
相应的，本发明实施例提供一种组合业务处理装置，所述装置包括:
获取单元，用于获取所述业务组合逻辑中抽象业务调用片段描述所对应的具体业务；
触发生成单元，用于触发业务组合适配，请求将抽象业务调用片段替换成所获得的具体业务的具体业务调用片段；或用于根据所述具体业务生成服务调用。
本发明实施例还提供一种组合业务替换装置，所述装置包括:
模板信息获取单元，用于在检测到具体组合逻辑中的服务业务调用片段时，获取具体组合逻辑中具体业务描述的业务名对应的业务模板信息；
适配触发单元，用于触发业务组合适配，请求将所述模板信息替换所述具体组合逻辑中的具体业务调用。
本发明实施例再提供一种具体业务调用装置，所述装置包括:
模板信息获取单元，用于在具体服务调用片段不能提供服务时，获取具体业务描述对应的业务模板信息；
具体业务获取单元，用于根据所述业务模板信息向注册中心查询，获得符合业务模板的具体业务；
服务调用生成单元，用于根据所述具体业务生成服务调用。
本发明实施例还提供一种一种组合业务系统，其特征在于，包括:业务注册中心，组合业务子系统，其中，所述注册中心包括:
业务中心，用于存储业务信息；
模板中心，用于存储模板信息，以及业务和业务模板之间的映射关系；
所述组合业务子系统包括:包括组合业务处理装置、组合业务替换装置和具体业务调用装置的一个或多个:其中，
所述组合业务处理装置包括:
获取单元，用于获取所述业务组合逻辑中抽象业务调用片段描述所对应的具体业务；
触发生成单元，用于触发业务组合适配，请求将抽象业务调用片段替换成所获得的具体业务的具体业务调用片段；或用于根据所述具体业务生成服务调用。
所述组合业务替换装置包括:
模板信息获取单元，用于在检测到具体组合逻辑中的服务业务调用片段时，获取具体组合逻辑中具体业务描述的业务名对应的业务模板信息；
适配触发单元，用于触发业务组合适配，请求将所述模板信息替换所述具体组合逻辑中的具体业务调用。
所述具体业务调用装置包括:
模板信息获取单元，用于在具体服务调用片段不能提供服务时，获取具体业务描述对应的业务模板信息；
具体业务获取单元，用于根据所述业务模板信息向注册中心查询，获得符合业务模板的具体业务；
服务调用生成单元，用于根据所述具体业务生成服务调用。
由上述技术方案可知，本发明实施例通过将抽象组合业务逻辑转换成具体组合业务逻辑的机制，实现了动态的业务组合、动态的业务选择。能根据业务抽象描述直接生成服务调用，省去了转换成具体组合业务逻辑的步骤。此外，当组合业务逻辑执行过程中调用的业务不能用时，能动态进行回溯，根据具体业务描述获取相应模板信息，进而动态选择一个合适的业务来替换。解决了所调用的业务不可访问时的动态替换。还能根据具体业务组合逻辑自动生成抽象业务组合逻辑.
附图说明
图1为本发明实施例中组合业务处理的装置的结构示意图；
图2为本发明实施例中组合业务替换的装置的结构示意图；
图3为本发明实施例中具体业务调用的装置的结构示意图；
图4为本发明实施例中组合业务处理方法的流程图；
图5为本发明实施例中业务组合引擎根据抽象描述生成具体描述的流程图；
图6为本发明实施例中业务注册中心的查询过程的流程图；
图7为本发明实施例中组合业务替换方法的流程图；
图8为本发明实施例中具体组合逻辑生成抽象组合逻辑的流程图；
图9为本发明实施例中具体业务调用方法的流程图；
图10为本发明实施例中具体业务替换方法的信令流程图。
具体实施方式
本发明实施例通过抽象业务描述机制以及业务模板机制，不但提供一种将抽象组合业务逻辑转换成具体业务逻辑的机制；还提供一种直接执行抽象组合业务逻辑的机制。同时，还提供抽象组合业务逻辑的自动生成过程，能直接根据具体组合业务逻辑生成抽象组合业务逻辑。当组合业务逻辑执行过程中所调用的业务不能使用时，能动态进行回溯(即替换)，即将具体业务描述转换成模板描述，再根据模板与业务的映射关系动态选择一个合适的具体业务来替换。
本发明实施例在调用具体业务时，需要提供三部分信息:业务(service)、操作(operation)、变量(variable)。其中所述variable可分为输入变量(inputVariable)和输出变量(output Variable)，在本发明实施例中以variable统称，例如在业务处理执行语言脚本BPEL中partner Link、operation、variable指定了相应的service、operation、variable。但BPEL只实现静态的业务组合。在实际应用中，存在动态业务组合的需求，即在业务运行的过程中需要动态的调用合适的业务来满足用户需求。
为了满足动态业务组合的需求，本发明实施例提供一种抽象业务描述机制，该抽象业务描述机制能支持动态的业务组合。所述抽象业务描述机制需要在描述业务调用时不指定具体业务，即不能同时指定service、operation、variable的具体值，但能根据service、operation、variable提供的信息发现合适的业务，将此类动态的业务组合称为基于抽象业务描述的业务组合。若service、operation、variable都没有指定具体值，则称为基于模板的业务组合。
所述抽象业务描述可分为基本标准描述和扩展标准描述(以下缩写为基本描述和扩展描述)。所述基本描述包括:service标准描述、operation标准描述、variable标准描述；而扩展描述则指除service标准描述、operation标准描述、variable标准描述之外的描述，例如服务质量QoS描述。基本描述用于动态业务组合时从业务目录发现符合要求的业务；而扩展描述则用于从发现的业务列表中筛选符合条件的业务。其所述业务描述具体如表1所示:
表1
在抽象业务描述的基本描述中，所述service Criteria可包括多个业务类别的描述信息，例如使用XML描述时可以包括多个属性组(attribute Group)子元素，每个子元素包括两个属性，分别指明了服务的类别以及该类别的值，比如某服务按地域分属于深圳，则其类别为area，其值为shenzhen，描述为<attribute Group category＝＂area＂name＝＂shenzhen＂/>)。所述OperationCriteria包括一个属性name，通过该属性值可以模糊搜索。所述VariableCriteria/inputVariable/outputVariable包括一个属性type，用于表示变量的类型。
在抽象业务描述的扩展描述中，可以含有多个子元素，其中，Qos是一个重要子元素，它又有多个属性，其中包括delaytime等。
在基于抽象描述的动态组合中，具体业务描述中的service、operation、variable中或service、operation、inputVariable、outputVariable中至少有一个值不能指定具体值，此时才需要abstractServiceDescription的基本描述所对应的抽象描述(service、operation、variable、inputVariable、outputVariable分别对应serviceCriteria、operationCriteria、variableCriteria、inputVariableCriteria、outputVariableCriteria)，而没指定具体值的属性由抽象业务描述中的基本描述的相应描述来指定.此外，由扩展描述提供相应的信息辅助发现业务。
对于业务的抽象描述示例如下，其中service与serviceCriteria、operation与operationCriteria、variable与variableCriteria是相对应的，只有在前者值为”##”时才会对应存在后者的扩展描述，即只有在service、serviceCriteria、operation中至少一个为“##”时，才有扩展描述extentionCriteria。如下例所示，描述了一个抽象业务:
<serviceDescription service＝＂##＂operation＝＂##＂variable＝＂##＂>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂categoryName＂name＝＂keywordValue＂/>
</serviceCriteria>
<operationCriteria name＝＂keywordValue＂/>
<variableCriteria type＝＂typeName＂/>
</baseCriteria>
<extentionCriteria>
<qos>
<delaytime unit＝＂timeUnit＂>value</delaytime>
</qos>
</extentionCriteria>
</serviceDescription>
模板由抽象业务描述中的基本描述的相应属性提供描述，每个模板都对应着特定类别的业务，可以直接利用业务描述的serviceCriteria来描述模板类别(category)。模板本身无扩展描述部分，但所述扩展描述部分可以配合模板用来选择具体业务。当然模板具有自己的一些属性，例如模板名等，所述模板的信息包括业务类别、操作、参数等信息。下述示例描述了一个模板:
<templateDescription template＝”templateName”>
<serviceCriteria>
<attributeGroup category＝＂categoryName＂name＝＂keywordValue＂/>
</serviceCriteria>
<operationCriteria name＝＂keywordValue＂/>
<variableCriteriatype＝＂typeName＂/>
</templateDescription>
在基于模板的动态组合中，具体业务描述中的service、operation、variable中或service、operation、inputVariable、outputVariable中全都没指定具体值，可以只提供模板名；或提供模板描述；或将模板名与模板描述一起提供。
例如，基于模板名的业务调用片段描述如下。
<serviceDescription>
<baseCriteria template＝”templateName”/>
<extentionCriteria>
<qos>
<delaytime unit＝＂timeUnit＂>value</delaytime>
</qos>
</extentionCriteria>
</serviceDescription>
例如，基于模板详细描述的业务调用片段描述如下，不需要提供业务描述中的具体业务描述。该模板的详细描述同上例的模板名保持一致。
<serviceDescription>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂categoryName＂name＝＂keywordValue＂/>
</serviceCriteria>
<operationCriteria name＝＂keywordValue＂/>
<variableCriteria type＝＂typeName＂/>
</baseCriteria>
<extentionCriteria>
<qos>
<delaytime unit＝＂timeUnit＂>value</delaytime>
</qos>
</extentionCriteria>
</serviceDescription>
由此可知，模板和业务存在一种映射关系，该映射关系表示该模板所能涵盖的业务，即通过该模板可以动态选择那些与模板具有映射关系的业务。此外，通过业务名也可以查找到一个业务模板。
为了便于本领域技术人员的理解，下面结合附图及实施例对本发明作详细的说明。
请参阅图1，为本发明实施例业务组合处理的装置的结构示意图，用于实现业务组合的功能，能执行具体组合业务和抽象组合业务。所述装置包括:业务组合引擎11、业务发现单元12、业务筛选单元13和组合逻辑适配单元14，其中所述业务组合引擎11又包括:获取单元112和触发生成单元113。优选的，所述业务组合引擎11还可以包括触发单元111。
其中，所述触发单元111，用于触发基于包括模板的业务抽象描述的业务组合逻辑的处理方式，包括触发调用和触发替换；所述获取单元112，用于获取所述业务组合逻辑中抽象业务调用片段描述所对应的具体业务；所述触发生成单元113，用于触发组合业务适配，请求将抽象业务调用片段替换成所获得的具体业务的具体业务调用片段；或用于根据所述具体业务生成服务调用。
所述业务组合引擎11用于辨别具体组合逻辑和抽象组合逻辑；能根据组合逻辑类型执行具体组合逻辑或触发基于抽象描述/模板的动态业务组合；能根据业务组合逻辑中的业务抽象描述或模板信息触发业务发现请求，查询业务目录；能根据业务发现单元12获得的业务触发业务筛选请求，向业务筛选单元13请求筛选请求；能根据业务筛选单元13获得的业务，触发组合逻辑适配，向组合逻辑适配单元14请求将抽象组合逻辑中的抽象描述或模板替换成具体业务。能根据调用的具体业务，获取相应模板信息，可应用于自动生成抽象组合逻辑或调用业务失败时的回溯。
自动生成抽象组合逻辑是指能根据具体组合逻辑生成抽象组合逻辑，使得组合逻辑能动态绑定业务。回溯指在调用业务失败时，能根据该业务获取相应模板信息，并根据该模板获取功能一致的业务。
优选的，所述业务组合引擎11还可以包括:业务调用片段生成单元，用于根据所述替换后的具体业务调用片段生成服务调用。
需要说明的是，所述触发单元111、获取单元112和触发生成单元113可以集成在业务组合引擎中，也可以独立存在。
所述业务发现单元12，与触发单元111相连，用于根据抽象业务描述或模板信息生成业务发现请求，根据所述业务发现请求向业务注册中心进行业务查询，获取到符合要求的业务列表，并将所述业务列表发送给业务组合引擎；
所述业务发现单元12包括:生成子单元、发送子单元、接收子单元和反馈子单元。其中所述生成子单元、用于根据抽象业务描述或模板信息生成业务发现请求；所述发送子单元，用于向业务注册中心发送业务查询信息，所述查询信息包括:查询类型、业务描述和限定条件；或者包括查询类型、模板描述和限定条件；所述接收子单元，用于接收所述业务注册中心反馈符合查询信息的业务列表，所述业务列表包括一个或多个具体业务；所述反馈子单元，用于反馈业务列表。
也就是说，所述业务发现单元12，用于根据抽象组合逻辑中提供的抽象业务描述信息或模板信息，生成业务发现请求，并根据业务发现请求向业务注册中心查询，即在发现符合要求的具体业务列表，并返回给业务组合引擎11(对于根据抽象业务描述信息的发现，可以直接查找业务；也可以先查找模板，再根据模板查找业务)。能根据具体业务信息发现相应模板。
所述业务筛选单元13，用于在接收到业务组合引擎触发的业务筛选时，能根据自身的筛选条件筛选所述业务列表，得到符合筛选条件的业务列表，从所述符合筛选条件的业务列表中选择一个具体业务反馈给所述业务组合引擎11中获取单元112。
所述组合逻辑适配单元14，用于在接收到业务组合引擎11请求的组合逻辑适配时，将抽象业务调用片段替换成所获得的具体业务的具体业务调用片段。也就是说，根据业务组合引擎11提供的一个具体业务，将抽象组合逻辑中该业务的抽象描述或模板替换成具体业务。根据业务组合引擎提供的模板信息将组合逻辑中该业务的具体描述替换成模板。
其中，在本实施例中，所述业务发现单元12向业务注册中心15查询的具体过程为:所述业务注册中心15，用于存储业务信息和业务模板信息。包括:业务中心151和模板中心152。其中，所述业务中心151和模板中心152可以看作是业务注册中心的两个视图，通过映射关系将业务和模板联系在一起，模板中心中有业务唯一标识符与模板标识符对应，而业务中心则有业务唯一标识符同业务信息对应，当然模板中心还有与模板标识符对应的模板信息。其中模板信息至少包括基本信息:业务分类信息、操作和参数；业务信息至少包括基本信息:业务分类信息、操作和参数；还可以包括扩展信息:服务质量QoS等。
所述业务中心151，用于存储业务信息，其中所述业务信息分为两类:原子业务和组合业务。所述原子业务完成的功能不需要调用其它业务；组合业务由组合逻辑描述，调用其它业务配合完成该功能。所述组合业务又可分两类:具体组合业务和抽象组合业务。具体组合业务由具体组合逻辑描述，指定了调用的具体业务；而抽象组合业务由抽象组合逻辑描述，没指定调用的具体业务，但提供了相应的抽象业务描述信息或业务模板信息，通过抽象业务描述信息或业务模板信息来确定所调用的业务。
所述模板中心152，用于存储业务模板信息，以及业务模板和业务的映射信息。业务模板是一种业务的抽象描述方式，一个业务模板可以对应一个或多个业务。
此外，在该实施例中，所述业务发现单元12和业务筛选单元13也可以直接交互，即不通过业务组合引擎11来控制。
还请参阅图2，为本发明实施例中组合业务替换装置的结构示意图，所述装置包括:业务组合引擎21和组合逻辑适配单元23，还可以包括业务发现单元22。为了便于理解，在该图中，还包括业务注册中心24及其模板中心241。所述业务组合引擎21包括:模板信息获取单元211和适配触发单元212。所述组合逻辑适配单元23包括:增加子单元231和删除子单元232。其中，
所述模板信息获取单元211，用于在检测到具体组合逻辑中的服务业务调用片段时，获取具体组合逻辑中具体业务描述的业务名对应的业务模板信息；
所述适配触发单元212，用于触发业务组合适配，请求将所述模板信息替换所述具体组合逻辑中的具体业务调用。
需要说明是，所述模板信息获取单元211和适配触发单元212可以集成在业务组合引擎中，也可以独立存在。
所述组合逻辑适配单元23，用于在接收到适配触发单元请求的组合逻辑适配时，将所述模板信息替换所述具体组合逻辑中的具体业务调用片段。具体包括:增加子单元，用于在具体组合逻辑中的具体业务调用片段中增加业务抽象描述的基本描述部分，并在基本描述部分增加模板名及对应的模板描述；删除子单元，用于在增加子单元添加完成时删除对应的具体业务描述。
所述模板信息获取单元211:用于根据具体业务描述向业务发现单元22触发业务模板查询请求；业务发现单元22，用于根据接收到的模板查询请求向业务注册中心24中的模板中心发送查询信息，所述查信信息包括具体业务描述的业务名，业务发现单元22还包括模板信息接收单元和模板信息反馈单元；模板信息接收单元，用于接收模板中心241反馈所述业务名对应的业务模板信息，所述业务模板信息，包括模板名及模板描述；模板信息反馈单元，用于向业务组合引擎反馈所述业务模板信息。
再请参阅图3，为本发明实施例中业务调用装置的结构示意图，所述装置包括:业务组合引擎31，所述业务组合引擎31包括:模板信息获取单元311、具体业务获取单元312和服务调用生成单元313。所述装置还可以包括业务发现单元32，组合逻辑适配单元33。为了便于描述，该图中还包括业务注册中心34，所述注册中心34包括业务中心341和模板中心342。其中，所述模板信息获取单元311，用于在具体组合逻辑中的服务调用片段不能提供服务时，获取具体组合逻辑中具体业务描述对应的业务模板信息；所述具体业务获取单元312，用于根据所述业务模板信息通过业务发现单元向模板中心查询，获得符合业务模板的具体业务，进而查询业务中心获得具体业务信息；所述服务调用生成单元313，用于根据所述具体业务生成服务调用。
优选的，所述模板信息获取单元311包括:查询请求发送单元、模板信息接收单元和模板信息反馈单元。其中，所述查询请求发送单元，用于根据具体业务描述向业务发现单元发送业务模板查询请求；所述业务发现单元，用于根据所述模板查信请求向模板中心发送业务查询信息，所述业务查询信息包括具体业务调用描述的业务名(即为业务标识符)；所述模板信息接收单元，用于接收模板中心反馈所述业务名对应的业务模板信息，所述业务模板信息，包括模板名及模板描述；所述模板信息反馈单元，用于向业务组合引擎反馈所述业务模板信息。
因此，所述业务组合引擎能支持具体组合逻辑和抽象组合逻辑(包括模板)两种模式。业务组合引擎不但支持抽象组合逻辑自动生成具体组合逻辑，也支持根据抽象描述片段生成服务调用；还支持业务调用失败时动态选择其它业务来替换；还支持具体组合逻辑自动生成抽象组合逻辑。
业务组合引擎支持抽象组合逻辑的直接执行模式和间接执行模式。其中直接执行模式指业务组合引擎能直接执行抽象组合逻辑，不需要先将抽象组合逻辑转换成具体组合逻辑，业务组合引擎检测到抽象描述后直接调用相应服务。间接执行模式指业务组合引擎先将抽象组合逻辑替换成具体组合逻辑，然后再执行具体组合逻辑，调用相应服务。其中，直接执行模式也可以支持生成具体组合逻辑，业务组合引擎检测到抽象描述后先将该处抽象描述替换成具体业务调用然后直接调用业务，不同于间接模式之处在于间接模式需要把抽象组合逻辑中的所有抽象描述替换成具体业务后在运行，而直接模式的这种具体组合逻辑方式生成则不需要等待替换所有的抽象组合逻辑。其中，直接执行模式也支持调用具体业务失败时选择其它业务来提供服务的机制。
业务组合引擎支持根据具体组合逻辑生成抽象组合逻辑的过程。
业务组合引擎能支持具体组合逻辑调用和抽象组合逻辑(包括模板)调用两种模式。业务组合逻辑中由众多业务调用片段组成，每个业务调用片段可以用具体业务描述，也可以用抽象业务描述(包括模板)，把前者称为具体业务调用片段，后者称为抽象业务(包括模板)调用片段。
相应的，本发明实施例还提供一种组合业务处理方法，所述方法的流程图如图4所示，所述方法包括步骤:
步骤401:获取组合业务逻辑中业务调用片段描述所对应的具体业务，其中所述业务调用片段为抽象业务调用片段或业务模板片段；
步骤402:触发业务替换，请求将所述业务调用片段替换成所获得的具体业务的具体业务调用片段；或触发业务调用，请求根据所述具体业务生成服务调用。
在步骤401中，所述获取所述业务组合逻辑中抽象业务调用片段描述所对应的具体业务的过程为:根据所述业务发现请求向业务注册中心进行业务查询，所述业务查询的信息包括:查询类型、业务描述和限定条件；或者包括查询类型、模板描述和限定条件；接收所述业务注册中心反馈符合查询信息的业务列表，所述业务列表包括一个或多个具体业务；选择并反馈业务列表中的一个具体业务。
优选的，所述根据抽象业务调用片段描述生成业务发现请求的过程为:
根据抽象业务调用片段信息中的基本描述信息生成业务模板发现请求，其中，所述基本描述信息包括业务类别、操作信息、参数信息；根据所述业务模板发现请求进行业务模板查询，获得匹配所述基本描述信息的业务模板信息。
优选的，所述根据具体业务生成服务调用的过程中用具体业务替换抽象业务调用片段，包括在生成业务调用前或调用时或调用后进行业务替换。
另外，在替换过程中生成服务调用，具体为:在替换前，根据获得的具体业务生成服务调用；或者在替换后，根据获得的具体业务或替换后的具体业务调用片段生成服务调用；或者在替换的同时，根据获得的具体业务生成服务调用。
所述方法还可以包括:在请求替换前，触发对所述业务列表的筛选，得到符合筛选条件的具体业务。然后可以根据具体业务生成服务调用，还可以根据替换后的具体业务调用片段生成服务调用。其生成服务调用的过程为:触发业务调用，提取所述具体业务中的必要信息，根据所述必要信息生成服务调用；或者，根据所述具体业务调用片段直接生成服务调用，所述必要信息包括:业务地址、业务名、操作或参数。
对于本实施例的具体实现过程详见图5。为本发明实施例中业务组合引擎对抽象组合服务逻辑的间接执行(即根据抽象描述生成具体描述)的流程图。如图5所示，业务组合引擎每检测到抽象描述时，就执行“根据抽象描述生成具体描述”流程，直到所有的抽象描述都替换成具体业务。具体包括步骤:
步骤501:业务组合引擎触发基于抽象描述的业务组合；业务组合引擎检查组合逻辑，若发现组合逻辑中无抽象描述，即具体业务描述的service、operation、variable(或service、operation、inputVariable、outputVariable)都指定了具体值，即表明该组合逻辑是具体组合逻辑，不触发基于抽象描述的业务组合，流程结束。若组合逻辑中某段脚本有抽象描述，即具体业务描述的service、operation、variable(或service、operation、inputVariable、outputVariable)中有一个未指定具体值(例如，可以值为特定值“##”)，即表明该段脚本是抽象描述脚本，则业务组合引擎触发基于抽象描述的业务组合。
步骤502:业务组合引擎注册中心进行业务查信；即业务组合引擎在判断该处脚本是抽象描述后，业务组合引擎触发业务发现单元向业务注册中心进行业务查询，其中查询信息中包括查询类型、业务描述和限定条件；或查询类型、模板描述和限定条件。其中业务描述包括具体业务描述和抽象业务描述的基本描述；限定条件即为抽象业务描述的扩展描述部分；模板描述可为模板名，或为模板的具体描述，即利用抽象业务描述的基本描述部分。查询类型包括根据业务描述查询、根据模板描述查询。
步骤503:业务注册中心反馈查信结果；即业务注册中心根据业务发现单元递交的查询信息进行查询，并返回符合查询条件的业务列表，其具体的查询过程详见图6中的描述。
步骤504:业务发现单元向业务组合引擎反馈业务列表；即业务发现单元将获得的查询结果，即符合查询条件的业务列表，反馈给业务组合引擎。
步骤505:业务组合引擎向业务筛选单元触发筛选流程，将业务列表发送给业务筛选单元。
步骤506:所述业务筛选单元反馈具体业务；即根据自身的筛选条件，筛选业务列表，过滤不符合筛选条件的业务。筛选条件包括业务可达性等，这些筛选条件具有一定的业务无关性，同业务抽象描述的限定条件具有一定互补性。若有多个业务，则随机选择一个业务提供给业务组合引擎。
步骤507:业务组合引擎根据获得的业务触发组合逻辑适配，请求组合逻辑适配单元根据提供的具体业务替换抽象描述。
步骤508:替换抽象描述；即所述组合逻辑适配单元提取业务信息中的必要信息，例如业务名、操作、参数等，将抽象业务描述中的具体业务描述补充完整，同时删除抽象业务描述的基本描述和扩展描述。
在步骤
其中，在步骤503中，所述业务注册中心的查询过程如图6所示，具体包括
步骤:
步骤601:业务注册中心判断根据模板查询还是根据业务抽象描述查询；若抽象描述中提供了模板名或模板信息，则是根据模板查询，则执行步骤602；否则根据业务抽象描述查询，执行步骤606。
步骤602:若查询类型是根据模板查询，则业务注册中心检测是否指定模板名。若指定模板名则执行步骤603，否则执行步骤604。
步骤603:如果模板描述中指定了具体的模板名，则查询模板中心获得该模板相应的业务列表。转610。
步骤604:如果模板描述中没指定具体的模板名，则根据模板描述的service部分(例如类型)查询模板中心，获取相应的模板列表。
步骤605:根据模板描述中的操作以及参数信息过滤模板列表，获得符合模板描述的模板列表，从而获得模板列表中的所有模板相对应的业务列表。然后执行步骤610。
步骤606:若查询类型是根据业务描述查询，则业务注册中心检测是否指定业务名。若指定业务名则执行步骤607，否则执行步骤608。
步骤607:若业务描述中指定了具体的业务名，则直接查找业务中心获得相应的业务列表。然后执行步骤609。
步骤608:若业务描述中没指定具体的业务名，则根据抽象描述中基本描述的service部分(例如业务类型)查询业务中心获得相应的业务列表。
步骤609:根据具体业务描述的操作、参数部分或抽象描述中基本描述的操作、参数部分或其组合，过滤业务列表中不符合条件的。
步骤610:根据限定条件(即业务抽象描述的扩展部分)对获得业务列表进行过滤生成符合查询条件的业务列表；若无限定条件则跳过此过程。
也就是说，所述业务注册过程为:
1、向注册中心请求注册业务，请求消息中包括业务信息以及模板信息，其中业务信息包括业务标识符、业务类别、操作、参数以及QoS等扩展参数等，模板信息包括模板标识符。其中模板信息为可选信息。
2、业务中心接收注册请求后进行业务注册。在业务注册中心添加所述业务信息，在模板中心添加同该模板标识符相对应的映射表中添加业务标识符信息。
所述模板注册的过程为:
1、向注册中心请求注册模板，请求消息中包括模板信息和业务信息，其中模板信息包括模板标识符、业务类别、操作、参数等，业务信息包括业务标识符或标识符列表，其中业务信息可选。
2、模板中心接收注册请求后进行模板注册。在模板注册中心添加所述模板信息，在模板中心添加同该模板标识符相对应的映射表中添加业务标识符信息。
所述通过模板查相应业务信息:
1、向注册中心请求业务信息查询，请求消息中包括模板信息，其中模板信息包括模板标识符等
2、注册中心接收查询请求后，通过模板标识符向模板注册中心的映射表中查询，获得相应的业务标识符列表；
3、通过业务标识符列表向业务注册中心查询，获得业务标识符列表相应的业务信息列表
通过业务查相应模板信息:
1、向注册中心请求模板信息查询，请求消息中包括业务信息，其中业务信息包括业务标识符等
2、注册中心接收查询请求后，通过业务标识符向模板注册中心的映射表中查询，获得相应的模板标识符；
3、通过模板标识符向模板注册中心查询，获得模板标识符相应的模板信息。
另外，本发明实施例还可以根据抽象描述生成服务调用(即直接执行)。即组合服务的执行包括可执行脚本的执行和抽象描述的执行，对于可执行脚本的执行是现有技术，此处不再描述，当组合引擎检测到可执行脚本时就直接调用服务。当可执行脚本和抽象描述都执行完毕时，整个组合服务才执行完毕。组合引擎对抽象组合服务逻辑的直接执行过程同间接执行过程类似，每检测到抽象描述就执行步骤501至步骤506，然后生成服务调用。
在不需要生成具体组合逻辑的情况下，具体包括:图5中的步骤501至506，具体详见上述，在此不再赘述；在执行步骤506后，执行步骤:业务组合引擎触发业务调用。业务组合引擎根据获取的业务提取业务信息中的必要信息，例如业务地址、业务名、操作、参数等，生成服务调用。
此外，本发明实施例为了能满足后续快速执行该组合业务的需求，需要在执行抽象组合逻辑后生成具体组合逻辑，方便将具体组合逻辑作为下次调用该业务时的组合逻辑。在需要生成具体组合逻辑的情况下，具体包括步骤:图5中的步骤501至508，具体详见上述，在此不再赘述；在执行步骤508后或执行步骤508过程中，执行步骤:业务组合引擎触发业务调用。业务组合引擎根据获取的业务提取业务信息中的必要信息，例如业务地址、业务名、操作、参数等，生成服务调用；或者业务组合引擎根据生成的具体组合逻辑片段直接生成服务调用。
相应的，本发明实施例对具体业务的处理流程包括:具体组合逻辑生成抽象组合逻辑流程和回溯。
请参阅图7，本发明实施例中组合业务替换方法的流程图，所述方法包括:
步骤701:获取组合业务逻辑中具体业务调用片段信息对应的业务模板信息；
其中，所述获取的过程为:根据具体业务描述向业务发现单元触发业务模板查询请求；
所述业务发现单元向模板中心发送查询信息，所述查信信息包括具体业务描述的业务名(即业务标识符)；
所述业务发现单元接收模板中心反馈所述业务名对应的业务模板信息，所述业务模板信息，包括模板名及模板描述，并反馈所述业务模板信息
步骤702:用所述模板信息替换所述组合业务逻辑中的具体业务调用片段信息。
其中，在具体组合逻辑中的具体业务调用片段中增加业务抽象描述的基本描述部分，并在基本描述部分增加模板名及对应的模板描述，同时删除对应的具体业务描述。
本实施例的具体实现过程详见图8。如图8所示，为本发明实施例中具体组合逻辑生成抽象组合逻辑的流程图，也就是说，业务组合系统提供抽象组合逻辑的自动生成过程。以下流程描述了将具体组合逻辑中的一个服务调用片段替换成抽象描述(此处是模板描述)的过程。在抽象组合逻辑生成过程中，只要按序替换具体组合逻辑中的一个具体服务调用就生成了一个抽象组合逻辑。业务组合引擎检测到具体组合逻辑中的一个服务调用片段时，触发业务模板替换过程。具体包括:
步骤801:业务组合引擎根据具体组合逻辑中的业务具体描述向业务发现单元触发模板查询请求。
步骤802:业务发现单元根据业务具体描述中的业务名查询模板中心，获得一个业务模板，并抽取模板名以及相应模板描述。
步骤803:模板中心给业务发现单元返回业务模板信息，包括模板名以及相应模板描述。
步骤804:业务发现单元给业务组合引擎返回业务模板信息。
步骤805:业务组合引擎触发组合逻辑适配过程，请求组合逻辑适配单元根据获取的业务模板信息替换具体组合逻辑中的具体业务调用。
步骤806:组合逻辑适配单元在具体组合逻辑的具体业务调用片段中增加业务抽象描述的基本描述部分，并在基本描述部分增加模板名或者增加模板的描述。同时删除相应的具体业务描述，即省略具体业务描述部分的业务名、业务操作、参数信息。
即如下基于模板名的抽象逻辑:
<serviceDescription>
<baseCriteria template＝”templateName”/>
</serviceDescription>
或如下基于详细模板描述的抽象逻辑
<serviceDescription>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂categoryName＂name＝＂keywordValue＂/>
</serviceCriteria>
<operationCriteria name＝＂keywordValue＂/>
<variableCriteria type＝＂typeName＂/>
</baseCriteria>
</serviceDescription>
在执行具体组合逻辑时，会遇到所调用的业务不能提供服务的情况，此时就需要一种回溯机制来保证此时组合逻辑的正常运行，需要寻找一个替换业务来提供服务。但该回溯机制不局限于业务组合中。
还请参阅图9，为本发明实施例中业务替换方法的流程图，所述方法包括:
步骤901:当具体业务调用片段所描述的业务不能提供服务时，获取具体业务调用片段描述对应的业务模板信息；
其中，所述获取具体业务描述的业务名对应的业务模板信息的过程为:根据具体业务描述向业务发现单元触发业务模板查询请求；所述业务发现单元向模板中心发送业务查询信息，所述业务查询信息包括具体业务描述的业务名；所述业务发现单元接收模板中心反馈所述业务名对应的业务模板信息，所述业务模板信息包括:模板名及对应的模板描述，并反馈所述业务模板信息。
步骤902:根据所述业务模板信息查询获得具体业务；
步骤903:根据所述具体业务生成服务调用。
对于本实施例其具体的实现过程详见图10。如图10所示，为本发明实施例中所述回溯(替换)的具体流程图。也就是说，当业务组合引擎检测到一个具体服务调用片段时，若遇到所调用的服务不能提供服务，就触发回溯机制。此处不能提供服务包括业务返回调用失败，或者业务响应超时等，其具体业务替换的过程包括:
步骤1001至步骤1003:业务组合引擎根据具体业务描述向业务发现单元触发模板查询请求，业务发现单元根据业务具体描述获得一个业务模板，其中包括模板名以及相应模板描述。具体同具体组合逻辑生成抽象组合逻辑流程的步骤801至803。
步骤1004:业务发现单元向业务注册中心进行业务查询，其中查询类型为根据模板描述查询；模板信息为模板名或为模板的具体描述；限定条件为空。
步骤1005:业务注册中心根据业务发现单元递交的查询信息进行查询，并返回符合查询条件的业务列表。其业务注册中心具体的查询过程详见图6中步骤601、602、603和步骤610；或者步骤601、602、604、605和610。在此不再赘述。
步骤1006:业务发现单元将获得的查询结果，即业务列表，提供给业务组合引擎。该步骤的实现过程与步骤504相同，在此不再赘述。
步骤1007和1008:业务组合引擎触发业务筛选单元进行业务筛选，获得符合条件的一个业务。该步骤的实现过程与步骤505和506相同，在此不再赘述。
在获得符合条件的业务后，即可进行服务调用。
此外，在本实施例中。步骤1004也可以替换上述步骤中步骤1004和1005。即在经过业务发现单元的模板查询后，模板中心直接获得符合条件的模板，并查询模板中心获得同该模板绑定的业务名；并根据该业务名查询业务中心获取相应的所有业务描述信息。
此外，本发明实施例还提供一种组合业务系统，所述系统包括:业务注册中心，组合业务子系统，其中，所述注册中心包括:
业务中心，用于存储业务信息；
模板中心，用于存储模板信息，以及业务和业务模板之间的映射关系；
所述组合业务子系统包括:包括组合业务处理装置、组合业务替换装置和具体业务调用装置的一个或多个:其中，
所述组合业务处理装置包括:
获取单元，用于获取所述业务组合逻辑中抽象业务调用片段描述所对应的具体业务；
触发生成单元，用于触发业务组合适配，请求将抽象业务调用片段替换成所获得的具体业务的具体业务调用片段；或用于根据所述具体业务生成服务调用。
所述组合业务替换装置包括:
模板信息获取单元，用于在检测到具体组合逻辑中的服务业务调用片段时，获取具体组合逻辑中具体业务描述的业务名对应的业务模板信息；
适配触发单元，用于触发业务组合适配，请求将所述模板信息替换所述具体组合逻辑中的具体业务调用。
所述具体业务调用装置包括:
模板信息获取单元，用于在具体服务调用片段不能提供服务时，获取具体业务描述对应的业务模板信息；
具体业务获取单元，用于根据所述业务模板信息向注册中心查询，获得符合业务模板的具体业务；
服务调用生成单元，用于根据所述具体业务生成服务调用。
优选的，所述组合业务子系统还包括:
业务发现单元，用于根据抽象业务描述或模板信息生成业务发现请求，根据所述业务发现请求向注册中心进行业务查询，获取到符合要求的业务列表，并反馈所述业务列表；
业务筛选单元，用于在接收到业务筛选请求时，筛选所述业务列表，得到符合筛选条件的业务列表，从所述符合筛选条件的业务列表中选择一个具体业务，并反馈所述具体业务；
组合逻辑适配单元，用于在接收到组合逻辑适配请求时，将抽象业务调用片段替换成所获得的具体业务的具体业务调用片段。
其中，所述业务注册中心、组合业务处理装置、组合业务替换装置和具体业务调用装置的具体功能和作用详见上述，在此不再赘述。
为了便于本领域技术人员的进一步理解本发明，下面以基于BPEL的具体实施例来说明。
在描述实施例之前，先介绍一下概念:
BPEL扩展描述:在BPEL中，调用业务时一般需要提供四部分信息:activity、partnerLink(指定了具体的业务，相当于上述的service)、operation、variable(在invoke操作时可有inputVariable和outputVariable两种，在此处合称为variable)，而同业务相关的信息包括partnerLink、operation、variable，示例如下:
<invokepartnerLink＝＂plName＂operation＝＂opName＂
inputVariable＝＂variableName＂outputVariable＝＂variableName＂/>
表示调用一个业务；
<receivepartnerLink＝＂plName＂operation＝＂opName＂
variable＝＂variableName＂/>
表示接收一个业务调用请求；
<reply partnerLink＝＂plName＂operation＝＂opName＂variable＝＂variableName＂
/>
表示回复给一个业务；
在可执行的BPEL脚本中，详细指定了activity、partnerLink、operation、variable，即相当于指定了具体业务调用，是一种静态的业务组合。在实际应用中，存在动态业务组合的需求，即在业务运行的过程中动态地进行业务调用。为满足动态业务组合的需求，需要对现有BPEL进行扩展，使其能支持动态的业务组合。此时就需要在设计流程描述脚本时不能指定具体的业务，即不能同时指定partnerLink、operation、variable的具体值，但能根据partnerLink、operation、variable提供的综合信息以及附加的业务描述信息发现合适的业务，将此类动态的业务组合称为基于BPEL模板的业务组合。
业务描述可分为基本描述和扩展描述。此处的基本描述包括service描述、operation描述、variable描述(variable可分为inputVariable和outputVariable，此处统称为variable)；而扩展描述则指除service、operation、variable之外的描述，例如QoS描述。基本描述用于动态业务组合时从业务目录发现符合要求的业务；而扩展描述则用于从发现的业务中筛选符合条件的业务。
在基于模板的业务组合中，需要扩展现有BPEL语言。Activity的attribute描述相当于上述的concreteServiceDescription，activity的element描述相当于上述的abstractServiceDescription。如表2所示
表2
在基于BPEL模板的动态组合中，partnerLink、operation、variable中或partnerLink、operation、inputVariable、outputVariable中至少有一个属性的值不能指定实际值。对于不能指定实际值的属性用“##”来替代其真实值。对于activity中属性值为“##”的属性，需要在对应baseCriteria的元素中进行描述。
BPEL的activivy中partnerLink指定名称，该partnerLinks名称的声明中指定了partnerLinkType，该partnerLinkType声明中指定了WSDL的portType，而描述所调用的业务真正由protType声明。因此本实施所说partnerLink没指定实际值，实际上指没有指定portType。
对于activity的描述示例如下，其中partnerLink和serviceCriteria、operation和operationCriteria、variable和variableCriteria是相对应的，只有在前者值为”##”时才会对应存在后者的补充描述，只有在partnerLink、serviceCriteria、operation中至少一个为“##”时，才有扩展描述extentionCriteria。该示例表示扩展BPEL的一个服务调用描述。
<activity partnerLink＝＂##＂operation＝＂##＂variable＝＂##＂>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂categoryName＂name＝＂keywordValue＂/>
</serviceCriteria>
<operationCriteria name＝＂keywordValue＂/>
<variableCriteria type＝＂typeName＂/>
</baseCriteria>
<extentionCriteria>
<qos>
<delaytime unit＝＂timeUnit＂>value</delaytime>
</qos>
</extentionCriteria>
</activity>
本发明第一应用实施例:
在业务注册中心的业务中心中有如下业务，由业务名、业务分类、操作、输入、输出、QoS组成。此处用业务名作为业务标识符。如表3所示:
表3
在业务注册中心的模板中心有同业务中心相对应的模板，并描述了业务与模板的映射关系。图表4所示:
表4
假如在BPEL的脚本中，有一处要调用一个天气预报业务，此处假设不提供具体的业务，而只提供业务的抽象描述，而在执行过程中调用具体业务。BPEL脚本如下所示，只提供一个activity作为示例:
<process name＝＂combinationService＂>
表明整个脚本描述了一个名为combinationService的组合业务。
<partnerLinkType name＝＂weatherQueryLT＂>
<plnk:role name＝＂weatherReportService＂portType＝＂##＂/>
<partnerLinkType>
描述伙伴类型，指定被调用的业务，主要通过web service中的porttype来描述。
<partnerLinks>
<partnerLink name＝＂customer＂partnerLinkType＝＂weatherQueryLT＂/>
</partnerLinks>
表明同该组合业务具有伙伴关系的业务，此例中为customer，真实身份由partnerlinks来实现，实际上间接由porttype指定。
<variables>
<variable name＝＂weatherRequest＂messageType＝＂weatherRequestType＂>
<complexType name＝＂weatherRequestType＂>
<element name＝＂address＂type＝＂string＂/>
<element name＝＂time＂type＝＂date＂/>
</complexType>
</variable>
<variable name＝＂weatherResponse＂messageType＝＂weatherResponseType＂>
<complexType name＝＂weatherResponseType＂>
<element name＝＂temperature＂type＝＂string＂/>
<element name＝＂weather＂type＝＂string＂/>
</complexType>
</variable>
</variables>
定义了相关变量。
<sequence>
其中，所述Sequence表明内部是一个流程
<invoke partnerLink＝＂customer＂
operation＝＂query＂
inputVariable＝＂weatherRequest＂
outputVariable＝＂weatherResponse＂>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂area＂name＝＂Shenzhen＂/>
<attributeGroup category＝＂serviceType＂name＝＂WeatherReport＂/>
</serviceCriteria>
</baseCriteria>
<extentionCriteria>
<qos>
<delaytime unit＝＂s＂>6</delaytime>
</qos>
</extentionCriteria>
</invoke>
上述为一个服务调用的描述。
</sequence>
</process>
在经过业务组合引擎处理之后，会生成具体的BPEL脚本，其中业务的抽象描述都被具体描述所替换。BPEL参考如下。
即具体BPEL脚本示例
<process name＝＂combinationService＂
xmlns:sif＝＂http://example.com/SZWeatherReport/interface/＂>
<partnerLinkType name＝＂weatherQueryLT＂>
<role name＝＂weatherReportService＂
portType＝＂sif:shippingServicePT＂/>
<partnerLinkType>
<partnerLinks>
<partnerLink name＝＂customer＂partnerLinkType＝＂weatherQueryLT＂/>
</partnerLinks>
<variables>
<variable name＝＂weatherRequest＂messageType＝＂weatherRequestType＂>
<complexType name＝＂weatherRequestType＂>
<element name＝＂address＂type＝＂string＂/>
<element name＝＂time＂type＝＂date＂/>
</complexType>
</variable>
<variable name＝＂weatherResponse＂messageType＝＂weatherResponseType＂>
<complexType name＝＂weatherResponseType＂>
<element name＝＂temperature＂type＝＂string＂/>
<element name＝＂weather＂type＝＂string＂/>
</complexType>
</variable>
</variables>
<sequence>
<invoke partnerLink＝＂customer＂
operation＝＂query＂
inputVariable＝＂weatherRequest＂
outputVariable＝＂weatherResponse＂>
</invoke>
</sequence>
</process>
本发明第二应用实施例:抽象BPEL生成具体BPEL
假设一位深圳的用户要调用一个组合业务，其中组合业务中调用到一个天气预报业务，该实施例流程描述动态寻找一个天气预报业务、并替换抽象业务描述的过程。其BPEL脚本如上述“抽象BPEL脚本示例”。
业务筛选单元定义如下策略:在同等条件下选择QoS好的业务。
1、业务组合引擎检查BPEL脚本，检测到partnerLink未指定具体值(虽然partnerLink的值为customer，但customer所指定的partnerLinkType为weatherQueryLT，但weatherQueryLT所指定的portType为空。)，即没有指定具体的调用业务，即表明该BPEL脚本是抽象BPEL，业务组合引擎触发基于抽象描述的业务组合。
2、业务组合引擎在判断该处脚本是抽象描述后，根据该处所调用的业务的抽象描述向业务发现单元进行业务查询。抽象描述如下。
<serviceDescription partnerLink＝＂customer＂operation＝＂query＂
inputVariable＝＂weatherRequest＂outputVariable＝＂weatherResponse＂>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂area＂name＝＂Shenzhen＂/>
<attributeGroup category＝＂serviceType＂name＝＂WeatherReport＂/>
</serviceCriteria>
</baseCriteria>
<extentionCriteria>
<qos>
<delaytime unit＝＂s＂>6</delaytime>
</qos>
</extentionCriteria>
<serviceDescription>
业务组合引擎生成的查询信息包括查询类型、业务描述和限定条件。因为抽象描述中提供了具体的操作、参数，所以此处查询类型是根据业务描述查询，而不是根据模板查询(提供模板名或抽象描述中具体业务、操作、参数都没提供，则属于根据模板查询)。
其中具体业务描述除service外，operation、inputVariable、outputVariable都指定具体值，抽取除service外的具体描述如下。
operation＝＂query＂inputVariable＝＂weatherRequest＂outputVariable
＝＂weatherResponse＂
抽象业务描述的基本部分为
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂area＂name＝＂Shenzhen＂/>
<attributeGroup category＝＂serviceType＂name＝＂WeatherReport＂/>
</serviceCriteria>
</baseCriteria>
由上述的基本部分和具体描述部分组成了业务描述。
抽取抽象业务描述的扩展部分作为限定条件，如下:
<extentionCriteria>
<qos>
<delaytime unit＝＂s＂>6</delaytime>
</qos>
</extentionCriteria>
3、业务注册中心根据业务组合引擎提供的查询信息进行查询。由于查询类型为根据业务描述查询，且业务描述中没指定具体的业务名，所以根据抽象描述中基本描述的业务部分查询业务中心。根据范围area是Shenzhen、业务类型serviceType是WeatherReport查询业务注册中心的业务中心，有“问天天气预报”、“深圳天气预报”符合条件。
再根据具体业务描述的操作(operation＝＂query＂)、参数(inputVariable＝＂weatherRequest＂outputVariable＝＂weatherResponse＂)进行业务过滤，两个业务都满足需求。
再根据限定条件的QoS需求进行业务过滤，两个业务都满足需求，生成业务列表，其中包括两个业务:“问天天气预报”、“深圳天气预报”。
业务注册中心返回业务列表给业务发现单元。
4、业务发现单元将获得的查询结果，即业务列表，提供给业务组合引擎。
5、业务组合引擎根据获得的业务列表触发业务筛选，将业务列表传递给业务筛选单元。
6、业务筛选单元根据自身的筛选条件筛选业务列表，过滤不符合条件的业务。由于业务筛选单元定义“在同等条件下选择QoS好的业务”策略，在比较“问天天气预报”和“深圳天气预报”的QoS，发现“深圳天气预报”能提供更好的QoS，于是选择“深圳天气预报”提供给业务组合引擎。
7、业务组合引擎根据获得的“深圳天气预报”触发组合逻辑适配，请求业务适配单元根据提供的具体业务替换抽象描述。
8、组合逻辑适配单元提取业务信息中的必要信息(此处即为portType信息，包括其命名空间)，将抽象业务描述中的具体业务描述补充完整(此处为partnerLinkType中的portType)，同时删除删除抽象业务描述的基本描述和扩展描述。
生成的BPEL脚本如上述“具体BPEL脚本示例”。
本发明第三应用实施例，即根据抽象BPEL生成服务调用
该实施例假设同上，该实施例流程描述动态寻找一个天气预报业务、并生成服务调用的过程。其BPEL脚本如上述“抽象BPEL脚本示例”。
1-6:同“抽象BPEL生成具体BPEL”，省略。
7’:业务组合引擎触发业务调用。业务组合引擎根据获取的业务提取业务信息中的必要信息，例如业务名、业务地址、操作、参数等，生成SOAP调用。SOAP消息示例如下。
<SOAP-ENV:Envelope
xmlns:SOAP-ENV＝＂http://schemas.xmlsoap.org/soap/envelope/＂
SOAP-ENV:encodingStyle＝＂http://schemas.xmlsoap.org/soap/encoding/＂>
<SOAP-ENV:Body>
<SZWeatherReport:Query xmlns:SZWeatherReport＝＂Some-URI＂>
<address>Shenzhen</address>
<time>20070520</time>
</SZWeatherReport:Query>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
若需要在执行抽象BPEL后生成具体组合逻辑，流程如下:
1-8:同“抽象BPEL生成具体BPEL”，省略。
9:业务组合引擎触发业务调用。业务组合引擎根据获取的业务提取业务信息中的必要信息，例如业务地址、业务名、操作、参数等，生成服务调用；或者业务组合引擎根据生成的BPEL片段直接生成服务调用。
本发明第四应用实施例，即具体BPEL生成抽象BPEL
假设有一具体BPEL脚本如上述“具体BPEL脚本示例”，在经过抽象BPEL流程处理后自动生成抽象BPEL脚本。本实施例中将具体的“深圳天气预报”业务替换成“天气预报”模板。
业务组合引擎检测到具体BPEL脚本中的一个服务调用片段时，触发业务模板替换过程。
业务组合引擎根据具体BPEL脚本中的业务具体描述向业务发现单元触发模板查询请求。
相关业务具体描述如下:
<process name＝＂combinationService＂
xmlns:sif＝＂http://example.com/SZWeatherReport/interface/＂>
<partnerLinkType name＝＂weatherQueryLT＂>
<role name＝＂weatherReportService＂
portType＝＂sif:shippingServicePT＂/>
<partnerLinkType>
<partnerLinks>
<partnerLink name＝＂customer＂partnerLinkType＝＂weatherQueryLT＂/>
</partnerLinks>
<invoke partnerLink＝＂customer＂
operation＝＂query＂
inputVariable＝＂weatherRequest＂
outputVariable＝＂weatherResponse＂>
</invoke>
1、业务发现单元从业务具体描述中获取业务名。此处partnerLink为“customer”，但“customer”并不是真正的调用业务；从“customer”获得其partnerLinkType为“weatherQueryLT”；从“weatherQueryLT”获得其相应的portType为“sif:shippingServicePT”；再根据portType的值以及名字空间获取业务描述，从而确定业务名。此处业务名为SZWeatherReport(深圳天气预报)。
2、根据获取的业务名查询模板中心，获得“深圳天气预报”查询业务的一个模板，并抽取模板名以及相应模板描述。模板如下。
<templateDescription template＝”weatherReportTemplate”>
<serviceCriteria>
<attributeGroup category＝＂serviceType＂name＝＂weatherReport＂/>
</serviceCriteria>
<operationCriteria name＝＂Query＂/>
<inputVariableCriteria type＝＂weatherRequest＂/>
<outputVariableCriteria type＝＂weatherResponse＂/>
</templateDescription>
1、模板中心给业务发现单元返回业务模板信息，包括模板名以及相应模板描述。
2、业务发现单元给业务组合引擎返回业务模板信息。
3、业务组合引擎触发组合逻辑适配过程，请求组合逻辑适配单元根据获取的业务模板信息替换具体组合逻辑中的具体业务调用。
4、组合逻辑适配单元在具体组合逻辑的具体业务调用片段中增加业务抽象描述的基本描述部分，由于次数是基于模板的替换，所以基本描述的字段都为空，即portType、operation、inputVariable、outputVariable都用“##”替换；在基本描述部分增加抽象业务的基本描述，用于描述service(即portType)、operation、inputVariable、outputVariable信息，其描述内容由模板信息提供。
生成的抽象BPEL描述如下:
<process name＝＂combinationService＂
xmlns:sif＝＂##＂>
<partnerLinkType name＝＂weatherQueryLT＂>
<role name＝＂weatherReportService＂
portType＝＂sif:##＂/>
<partnerLinkType>
<partnerLinks>
<partnerLink name＝＂customer＂partnerLinkType＝＂weatherQueryLT＂/>
</partnerLinks>
<sequence>
<invoke partnerLink＝＂customer＂
operation＝＂##＂
inputVariable＝＂##＂
outputVariable＝＂##＂>
<baseCriteria>
<serviceCriteria>
<attributeGroup category＝＂serviceType＂name＝＂WeatherReport＂/>
</serviceCriteria>
<operationCriteria name＝＂Query＂/>
<inputVariableCriteria type＝＂weatherRequest＂/>
<outputVariableCriteria type＝＂weatherResponse＂/>
</baseCriteria>
</invoke>
</sequence>
</process>
本本发明第五应用实施例，即回溯的实现过程
在执行具体BPEL时，由于BPEL只能提供静态的业务组合。所以在执行BPEL脚本时可能会存在所调用的业务已失效的情况。本实施例描述在执行BPEL脚本时，调用的“深圳天气预报”业务失效，业务组合引擎提供另外一个业务来调用。假设BPEL脚本为“具体BPEL脚本示例”。具体过程为:
1、业务组合引擎执行具体BPEL中的“深圳天气预报”时，遇到所调用的服务不能提供访问，就触发回溯机制。
2、业务组合引擎根据具体BPEL脚本中的业务具体描述向业务发现单元触发业务查询请求，业务发现单元根据业务具体描述中的业务名查询模板中心，获得该服务相应的一个模板，此处即“天气预报”模板。该步骤的实现过程同具体BPEL生成抽象BPEL步骤2，3，4。
3、模板中心根据“天气预报”模板获得对应的业务，即“问天天气预报”、“广东天气预报”、“深圳天气预报”，并向业务中心获取具体的业务描述，包括业务名、操作、参数以及QoS信息等。在该步骤中，模板中心的业务只是一个引用，没具体的业务描述。
4、业务注册中心给业务发现单元返回业务列表，业务发现单元给业务组合引擎返回业务列表。
5、业务组合引擎向业务筛选单元请求筛选业务，由于“深圳天气预报”不能访问，被过滤；再比较QoS情况，“问天天气预报”优于“广东天气预报”，所以业务筛选单元选择“问天天气预报”来提供服务。
6、业务组合引擎根据业务筛选单元提供的“问天天气预报”生成服务调用。该步骤的实现过程同抽象BPEL生成服务调用步骤7、8、9，在此不再赘述。
由此可见，本发明实施例通过抽象业务描述机制以及业务模板机制，提供了一种将抽象组合业务逻辑转换成具体组合业务逻辑的机制，实现了动态的业务组合、动态的业务选择。
本发明实施例还提供直接执行抽象业务组合逻辑的机制，能根据业务抽象描述直接生成服务调用，省去了转换成具体组合业务逻辑的步骤。同时还提供一种机制在直接执行抽象业务组合逻辑时附带生成具体组合业务逻辑。
本发明实施例还提供抽象组合逻辑的自动生成过程，能直接根据具体业务组合逻辑生成抽象业务组合逻辑，为自动业务组合提供抽象组合业务逻辑。
当执行组合业务逻辑执行过程中调用的业务不能用时，能动态进行回溯，将具体业务描述转换成模板描述，进而动态选择一个合适的业务来替换。解决了所调用的业务不可访问时的动态替换。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
机译： 业务管理系统，业务处理器，业务管理服务器，业务处理方法，业务管理方法，业务处理程序和业务管理程序
机译： 柜台业务处理服务器设备，柜台业务处理系统和柜台业务处理方法
机译： 业务处理系统，业务处理方法和业务处理程序
