CN101826987B - 一种基于融合开放网络的混合服务支撑系统及方法 - Google Patents

Abstract

一种基于融合开放网络的混合服务支撑系统和方法，系统设有：基于模板复用的服务生成子系统，面向混合服务的多任务并发执行子系统，服务资源接入子系统和服务管理子系统，其以IP网融合PSTN，2G、2.5G和3G移动网，以及Wi-Fi与Wi-MAX和分组数据网的各种异构网，支持在融合开放网络环境中，提供基于模板复用的服务生成和多任务的并发执行。本发明采用面向服务体系结构SOA，基于模板复用的思想实现快速的服务生成，基于服务总线集成动态流程执行引擎和低延迟事件服务引擎，提供融合网络服务的运行环境，从而实现整合互联网和电信领域的业务能力，达到提供灵活多样的个性化服务和支持多任务并发执行的目的。

Description

一种基于融合开放网络的混合服务支撑系统及方法

技术领域

本发明涉及一种基于融合开放网络的混合服务支撑系统及其工作方法，确切地说，涉及一种包括基于模板复用的服务生成子系统、面向混合服务的多任务并发执行子系统、服务资源接入子系统以及服务管理子系统的混合服务支撑系统及及其工作方法；属于面向服务的电信网和互联网的应用技术领域。

背景技术

随着通信和网络技术的快速发展，传统电信网中各类异构网络的融合，甚至与互联网域以外的网络的融合已经成为网络发展的主流趋势。人们对于服务的需求也逐步呈现出多样化和综合化的趋势。业界一般将不同网络的服务统称为混合服务。在这个背景下，在异构开放的网络和终端上，如何提供一种跨电信网与互联网，支持灵活、可扩展的服务生成及执行的混合服务的支撑系统及其工作方法，已经成为国内外网络界科技人员共同关注和研究的热点课题。

近年来，随着软件新技术的发展，服务已成为开放网络环境下资源封装与抽象的核心概念，通过动态地组合服务，实现资源的灵活聚合成为技术发展的自然思路。面向服务体系架构SOA(Service-Oriented Architecture)能够将应用程序的不同功能单元通过服务之间定义的良好接口和契约联系起来，使用户可以不受限制地重复使用软件，并把各种资源互连起来。支撑SOA的关键是其消息传递架构——企业服务总线ESB。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，是一种在松散耦合的服务和应用之间的标准集成方式。ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，用于完成粗粒度应用(服务)和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。Java业务集成JBI(Java Business Integration)规范定义了一个ESB，以供开发商能方便地利用Java语言实现面向服务的架构。

Web服务是使应用程序能够采用与平台和编程语言都无关的方式实现相互通信的一项技术。W3C对Web服务的定义如下：Web服务是由URI标识的软件系统，其接口和绑定可以通过XML进行定义、描述和发现，Web服务支持通过基于Internet的协议使用基于XML的消息与其它Web服务或软件系统直接交互。Web服务是一个软件接口，它描述了一组操作，可以在网络上通过标准化的XML消息传递来访问这组操作。它使用基于XML语言的协议来描述要执行的操作或与另一个Web服务交换的数据。现在，Web服务技术已经被广泛接受，使得Web服务正在逐步成为Internet网络环境中资源封装的标准形式。随着部署在Internet上的Web服务的不断丰富，这些可被公共访问和集成的Web服务已经构成了一个潜在、巨大的标准组件库。

电信网络的开放性研究一直是业内的热点，特别是在电信市场竞争日益激烈的今天，电信运营商们面临着巨大挑战，他们迫切需要开发出标新立异、形形色色的增值业务来吸引更多用户，以满足用户对电信业务的日益增长需求。电信界Web服务的提出备受各界关注，通过API把电信底层的网络资源开放出来，并以Web服务方式向第三方和业务提供商开放，从而可以利用IP网络中的成熟技术来帮助解决电信网络中诸如运营商之间跨网络访问等问题，而Internet应用程序开发商也可以方便地利用电信网络的资源，提供灵活多样的服务。

基于Web服务的服务组合的方法可以降低系统开发的难度和复杂度，提高系统对复杂多变的业务需求的适应能力。技术人员可以通过对已有Web服务的组合，设计并实现一套完整的解决方案来适应复杂多变的业务需求。在Web服务的服务组合中，通常是通过某种脚本语言来描述最终的组合流程，并在支持该脚本语言的引擎上部署和运行，这种脚本语言被称为服务编排语言。目前，比较成熟的服务编排语言主要有业务流程执行语言BPEL(Business ProcessExecution Language)。它是一种使用XML编写的、用于自动化业务流程的编程语言，又被称作WS-BPEL或BPEL4WS。BPEL广泛用于与Web服务相关的项目开发中，其优点为有可移植性和能有效保护资产。Web服务实现了接口的可重用性，而业务流程执行语言BPEL实现了Web服务的重用性，或者称之为服务流程的可重用性，通过定义BPEL流程，企业可以使用现有的细粒度的Web服务，重新创建符合自己需求的其他粗粒度的服务。目前，对于BPEL脚本的开发，IBM、Oracle和微软等公司都提供了广泛的支持。这些公司都提供了自己开发的BPEL执行引擎和与之配套的BPEL脚本的图形化开发环境。但是，在众多的执行引擎和图形化开发环境中，对于BPEL脚本的复用机制始终缺乏一套灵活完善的解决方案，绝大多数的系统只提供部分支持，且使用起来难度很大。

现在，利用BPEL来实现Web服务间的组合和系统开发，大都是基于特定的行业领域内进行的。而每个行业领域内部，通常都有很多业务的逻辑和功能是可以被重复使用的。但是，这种重复使用的层次和粒度也可能多种多样，因此要想有效复用这些逻辑功能，必然要提供一套灵活性高的复用机制。同时，同一行业领域内部的不同的解决方案之间，对于同样的业务也都会有着自己特有的逻辑设计。这就意味着系统也要给用户足够的自主性，让其对复用的逻辑能够执行自主控制。而且，因系统的复杂性和现实需求的变更等原因，都不可避免地要对现有的BPEL脚本进行新的开发或修改。尤其是在创建新的相关流程时，往往会重复用到以前开发过的BPEL代码段。但是，如果都进行BPEL流程的封装，又势必会造成在流程结构和层次上的复杂性而带来不便。

与此同时，动态流程执行引擎主要执行依据WS-BPEL标准编写的业务流程，调用Web服务，发送和接受消息，处理数据操作以及排除故障。然而在实际应用中，电信Web服务有较高的实时性需求，如要求服务要有高吞吐量和低时延，支持异步交互，如语音信箱、呼叫前转，以及能够有效利用现有的底层通信协议能力。基于JAIN SLEE(JSLEE)规范的低延迟事件引擎能够较好地满足上述服务需求。JAIN是SUN公司领导的一个企业团体的合作项目，其主要目的是定义各种必要的、用于扩展核心JAVA平台的JAVA程序开发接口，它通过将各种复杂的有线、无线和IP网络提供的各种通信接口都统一定义为系列的JAVA工业标准接口，使得各种私有的通信网络能够演变为开放的、标准的网络。JSLEE是JAIN定义的基于JAVA的服务逻辑执行环境SLEE(Service LogicExecution Environment)规范，其是一个分布式的业务组件框架，采用JavaBeans的组件模型和事件驱动机制，为业务组件提供可靠的运行环境。SLEE可以接收各种网络资源的呼叫事件，将这些事件发送到相应的业务逻辑去处理，同时为业务提供监控、统计及管理功能。另外，为实现对混合服务支撑系统的各项公共业务进行统一管理，以构建可运营的支撑系统，还需提供系统公共服务管理功能，主要包括配置管理、故障管理、计费管理、日志管理、监控管理、用户管理等各个方面。

为了研制基于融合开放网络的混合服务支撑系统及其工作方法，申请人已经做了许多前期工作。例如已经成功研发和申请了中国发明专利申请《面向混合网络服务的多任务并发执行系统及方法》(专利申请号200910243593.3)和《面向服务环境中基于模板实现BPEL子流程复用的方法及系统》(专利申请号201010101686.5)。

发明内容

有鉴于此，本发明的目的是提供一个基于融合开放网络的混合服务支撑系统及其工作方法，本发明采用面向服务体系结构SOA，基于模板复用的思想实现快速的服务生成，基于服务总线集成双引擎(动态流程执行引擎和低延迟事件服务引擎)提供融合网络服务的运行环境，从而实现整合互联网和电信领域的业务能力，提供灵活多样的个性化服务和支持多任务并发执行的目的。此外，本发明还提供了相应的服务资源接入子系统与服务管理子系统，分别实现对服务资源的接入和对服务进行统一管理。

为了达到上述发明目的，本发明提供了一种基于融合开放网络的混合服务支撑系统，以IP骨干网作为包括固定电话网PSTN，第二代无线通信网2G和2.5G、第三代移动通信网3G，以及无线网络Wi-Fi与Wi-MAX和分组数据网的各种异构网络融合的基础，用于支持在融合开放网络环境中，提供基于模板复用的服务生成以及多任务的并发执行；其特征在于：该系统至少包括：

基于模板复用的服务生成子系统，用于为业务开发者提供基于粗粒度模板的服务开发方式、BPEL业务流程的验证与测试支持和生成以BPEL脚本形式展现、能运行于所有通用的BPEL执行引擎的服务流程；该子系统设有独立的模板模型，并提供基于模板的BPEL代码的复用方法和一套面向BPEL的业务开发者的、采用拖拽和点击的图形化方式的业务开发环境，能够完成针对BPEL代码的包括服务模板的抽取、封装、拼接和导出生成新业务的复用机制，以降低业务的二次开发难度，提高开发效率；

面向混合服务的多任务并发执行子系统，分别连接服务生成、服务资源接入和服务管理三个子系统，为混合服务提供稳定可靠的业务编排及执行环境；设有三个部件：承载服务生成子系统生成的服务流程、执行依据WS-BPEL标准编写的业务流程、调用Web服务、发送和接受消息、进行数据处理和故障恢复的动态流程执行引擎，基于事件驱动的异步通信调用、处理复杂的网络协议、增加系统对高吞吐量与低延迟电信服务的支持的低延迟事件服务引擎，以及采用包括分布式处理、智能路由与动态数据转化的方法，利用不同协议支持异构应用及服务之间通信的服务总线，该服务总线在动态流程执行引擎及低延迟事件引擎之间传递信息；该多任务并发执行子系统还负责为生成的服务流程提供对应的服务构件块SBB(Service Building Block)，集成接入各种网络资源，同时为服务管理子系统提供相应的管理接口；

服务资源接入子系统，通过多种网关与各个网络运营商的通信网络相连接，将包括Parlay或ParlayX、SMS、MMS、LBS、GIS、SIP和E-Mail的各种协议能力统一封装成Web服务供其他子系统调用，再通过相应协议连接各种应用系统，通过兼容开放的标准协议接口，接入网络运营商授权的各种现有通信业务和实现互通，并提供各种通信业务的协议支持；再通过与智能网相关设备的配合，实现与各种传统话音增值业务和新业务的互通，并与多任务并发执行子系统实现业务的数据交互；

服务管理子系统，分别连接服务生成、多任务并发执行和服务资源接入三个子系统，用于通过浏览器方式，提供各级管理维护人员对所述三个子系统实现协调管理，对该服务支撑系统执行维护操作与提供公共服务支持，并对各系统业务进行统一管理。

为达到上述目的，本发明还提供了一种基于融合开放网络的混合服务支撑系统的工作方法，其特征在于：包括下列操作步骤：

(1)服务生成子系统执行服务的生成及验证，即由服务开发者利用服务生成子系统完成服务流程的开发过程；该步骤(1)进一步包括下述操作内容：

(11)服务模板的抽取：服务开发者利用服务生成子系统，通过基于模板的机制对要重复利用的BPEL片段或服务模板进行有效封装后，保存于模板库；

(12)服务模板的组装：服务开发者设计业务流程时，利用服务生成子系统提供的图形化开发环境，采用拖拽和点击的图形化方式将BPEL流程的开发与模板的拼装融合在一起，即将已生成的服务模板导入到当前的业务流程编辑窗口中，供用户按需使用；使服务开发者能轻松复用已经抽取出来的模板，减少二次开发时间，实现高效开发；

(13)服务模板的导出：在完成基于模板的业务流程的编辑后，服务生成子系统要将此时得到的基于扩展标签完成的包含有模板的业务流程文件，导出为能够在多任务并发执行子系统或任何BPEL执行引擎上运行的标准BPEL文件，并删除以前对BPEL片段增加的封装，完成到BPEL脚本的转换；

(14)服务的验证：在上述三个步骤的执行过程中，服务生成子系统对其分别执行包括BPEL语法验证和模板语义验证的支持，保证服务的正确性；

(2)多任务并发执行子系统完成服务的部署及执行，在服务执行过程中，多任务并发执行子系统要调用服务资源接入子系统所提供的通信能力；

(3)在该支撑系统的整个运行过程中，服务管理子系统负责对上述服务的生成、验证、部署和执行的全部流程执行协调管理，即对整个服务支撑系统的全部运行过程提供公共服务支持，并统一协调管理各个子系统的操作；其中，每个服务的部署进一步包括下述操作内容：

分析该服务的需求和实现该服务所需的各个原子服务；再将实现该服务的各个原子服务部署到低延迟事件服务引擎中；

为实现该服务的多个原子服务编辑一个服务描述文件，并将其打包成一个能够部署到低延迟事件服务引擎的服务单元SU(Service Unit)；

为服务生成子系统生成的BPEL业务控制流程编写一个能部署于动态流程执行引擎的部署描述文件，再将该部署描述文件、编辑好的BPEL控制流程和相应的WSDL文件打包成一个能部署于动态流程执行引擎的服务单元；

为该服务编写一个HTTP绑定组件描述文件，用于接收客户端的客户业务请求，打包成为能够部署于HTTP协议绑定组件的服务单元；

将上述三个步骤分别产生的三个服务单元打包成一个完整的服务集SA(Service Assembly)，该服务集SA包就是整个服务的部署包；再将该部署包部署于多任务并发执行子系统，然后，就能够提供给用户通过客户端调用。

本发明具有以下四方面的创新技术优点：

(一)面向网络融合：本发明把各种承载业务的网络能力封装成Web服务来屏蔽网络和系统的异构性和复杂性，能够有效整合互联网和电信领域的业务能力，提供灵活多样的混合服务。

(二)代码复用，拖拽式业务生成，可定制性强：本发明提供的面向服务的开发环境中运用了基于模板的代码复用思想，其灵活性好，抽取和组合的层次多样，还能很好地控制服务粒度；基于图形化的开发界面能够完成对模板的包括抽象BPEL、实例化拼接、服务组合、规则验证以及文件生成的系列操作，还提供了可拖拽的编辑界面，包括：模板图示、连线、图形的缩小和放大，以及提供鹰眼功能，以及能够根据不同场景对模板库进行基本分类。本发明同时包含了BPEL代码和模板的开发，能有效降低用户的二次开发工作量；用户利用本发明可以用自己的扩展标签来协助开发，并最终转换成可执行的、符合规范的WS-BPEL脚本，以便运行在不同的执行引擎上；该系统能够很好地根据用户需求来生成其所需的模板，具有很高的可定制性。

(三)支持多用户、大规模的多任务并发执行：本发明集成了负载均衡、接纳控制以及基于Actor模型的JAVA并发对象框架技术，其中，负载均衡技术使得本发明系统由单台应用服务器系统提升到应用服务器的机群系统级别，从而极大地提高整个系统的处理能力，为系统的大规模拓展应用提供了坚实基础。接纳控制技术使本发明系统在过载时仍可维持较高的处理量和较好的服务质量，保障系统的稳定性和动态性，使其即使在负载大幅波动时，也具有良好的自适应性。基于Actor模型的JAVA并发对象框架技术使得本发明在业务流程执行时能够处理并发消息，该技术建立在每个过程实例的单个线程基础上，能够避免创建过多的线程，从而减弱因线程调度而对系统性能造成的不利影响。

(四)随需而变，可快速开发业务：本发明是基于SOA的Web服务支撑系统，具有跨平台服务的优点，并且由于业务流程采用松散耦合的方式，其业务开发、处理与业务控制流程是相互分离的，对上而言，各种能力是不同粒度的原子服务的组合，在今后业务的开发、扩展和修改上，该系统能够充分体现其高度的灵活性和宽泛的适应性，大大节省硬件开销所带来的高使用成本和开发时间，而且，基于可重用服务流程的服务模板技术，通过动态配置服务模板，可柔性化地将某项应用重组为其他应用。

综上所述，本发明具有很好的推广应用前景。

附图说明

图1是本发明基于融合开放网络的混合服务支撑系统结构组成示意图。

图2是本发明服务生成子系统结构组成示意图。

图3是本发明面向混合服务的多任务并发执行子系统结构组成示意图。

图4是本发明服务生成子系统基于模板复用的服务生成过程示意图。

图5为本发明系统工作方法中的服务部署的操作流程示意图。

图6为JAVA并发对象框架(VPU)的结构组成示意图。

图7为JAVA并发对象框架的执行操作时序图。

图8为多任务并发执行子系统中规格化消息适配器的消息处理流程图。

图9为多任务并发执行子系统的运行方法的实施例的操作步骤流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图和实施例对本发明作进一步的详细描述，但所举实施例不作为对本发明的限定。

参见图1，介绍本发明基于融合开放网络的服务支撑系统的结构组成，该系统以IP骨干网作为包括固定电话网PSTN，无线通信网2G、2.5G和3G，以及无线网络Wi-Fi与Wi-MAX与分组数据网的各种异构网络的融合基础，用于支持在融合开放网络环境中，提供基于模板复用的服务生成以及多任务的并发执行；其特征在于：该系统至少包括：基于模板复用的服务生成子系统，面向混合服务的多任务并发执行子系统，服务资源接入子系统和服务管理子系统。该系统中的各部件具体功能及与其它部件的交互关系说明如下：

基于模板复用的服务生成子系统，用于为业务开发者提供基于粗粒度模板的服务开发方式、BPEL业务流程的验证与测试支持和生成以BPEL脚本形式展现、能运行于所有通用的BPEL执行引擎的服务流程；该子系统设有独立的模板模型，并提供基于模板的BPEL代码的复用方法和一套面向BPEL的业务开发者的图形化方式的业务开发环境，使得业务开发人员能采用拖拽和点击的图形化方式进行开发，完成针对BPEL代码的包括服务模板的抽取、封装、拼接和导出生成新业务的复用机制，以降低业务的二次开发难度，提高开发效率。该子系统拥有独立的模板模型，定义了一套模板标签来扩展模板的抽取、封装、拼接和导出的实现机制，以使最终得到的仍然是符合WS-BPEL规范的可执行的BPEL文件，因此，该子系统开发的业务流程的最终版本仍然是以BPEL脚本形式展现，也能在所有通用的BPEL执行引擎上运行。

面向混合服务的多任务并发执行子系统，分别连接服务生成、服务资源接入和服务管理三个子系统，为混合服务提供稳定可靠的业务编排及执行环境；设有三个部件(参见图3)：承载服务生成子系统生成的服务流程、执行依据WS-BPEL标准编写的业务流程、调用Web服务、发送和接受消息、进行数据处理和故障恢复的动态流程执行引擎，基于事件驱动的异步通信调用、处理复杂的网络协议、增加系统对高吞吐量与低延迟电信服务的支持的低延迟事件服务引擎，以及采用包括分布式处理、智能路由与动态数据转化的方法，利用不同协议支持异构应用及服务之间通信的服务总线，该服务总线在动态流程执行引擎及低延迟事件引擎之间传递信息；该多任务并发执行子系统还负责为生成的服务流程提供对应的服务构件块SBB，集成接入各种网络资源，同时为服务管理子系统提供相应的管理接口。

服务资源接入子系统，通过多种网关与各个网络运营商的通信网络相连接，将包括Parlay或ParlayX、SMS、MMS、LBS、GIS、SIP和E-Mail的各种协议能力统一封装成Web服务供其他子系统调用，再通过相应协议连接各种应用系统，通过兼容开放的标准协议接口，接入网络运营商授权的各种现有通信业务和实现互通，并提供各种通信业务的协议支持；再通过与智能网相关设备的配合，实现与各种传统话音增值业务和新业务的互通，并与多任务并发执行子系统实现业务的数据交互。该服务资源接入子系统设有下述接入网关：

Parlay/ParlayX网关，分别连接PSTN网、2G、2.5G、3G移动网和下一代网络NGN，用于接入相关网络执行网络运营商授权业务的交互；

短消息服务SMS网关，用于连接移动通信网2G、2.5G和3G，提供短消息类的授权业务；

多媒体消息服务MMS网关，用于连接移动网2G、2.5G和3G，提供多媒体消息类的授权业务；

LBS网关，用于连接移动网2G、2.5G和3G，提供移动终端的定位业务；

GIS网关，用于连接Internet中的地理信息服务，提供地理信息业务；

SIP网关，用于连接3G移动网络、NGN网络、Wi-Fi网络、Wi-MAX网络和因特网，提供基于IP的话务业务；

Mail网关，用于连接Internet中的邮件服务器，与服务资源接入子系统的其它网关共同向用户提供mail提醒和转发业务；

Web服务网关，用于连接Internet，向用户提供web查询及推荐业务；

上述各个网关分别连接多任务并发执行子系统，向多任务并发执行子系统发送业务请求并接收其发来的业务指令。

服务管理子系统，分别连接服务生成、多任务并发执行和服务资源接入三个子系统，用于通过浏览器方式，提供各级管理维护人员对所述三个子系统实现协调管理，对该服务支撑系统执行维护操作与提供公共服务支持，并对各系统业务进行统一管理。该服务管理子系统对本发明服务支撑系统执行维护操作与提供的公共服务支持的具体内容包括：

配置管理，执行包括配置计费数据和对配置数据的管理、系统与各个子系统的操作数据自动备份的功能；

故障管理，执行包括对该服务支撑系统的运行状态的监视和故障监测、故障告警、故障定位、故障日志和故障分析的功能；

安全管理，执行接入认证与鉴权操作，支持分级的管理用户接入方式，以使不同权限的管理用户执行相应的不同操作，还支持多点操作和定时启动命令；

日志管理，执行包括安全日志、日志管理的功能；该安全日志作为安全管理的重要证据，会将所有操作员的关键操作都自动地记录于安全日志；

计费和业务管理，能够支持多种计费方式，以便对短信及数据业务，支持按流量计费和按内容计费；对传统话音服务及视频服务，支持按时间计费。

以上可知，服务管理子系统是协调本发明支撑系统各部件正常工作的控制中枢，也可以采用专设服务器实现上述管理功能。本领域技术人员应当理解，通过现有技术(例如控制芯片或单独的PC等)实行上述服务管理子系统的协调管理的工作是很容易实现的。因该部件不是本发明系统的重点，故不作赘述。

参见图2，具体介绍本发明服务生成子系统的组成结构。该子系统是采用MVC(Model-View-Controller)的设计思路和基于Eclipse插件开发技术，利用EMF(Eclipse Model Framework)和GEF(Graphical Eclipse Framework)实现的。其中EMF用来完成建模工作，GEF用来完成图形化功能。

服务生成子系统是基于行业领域的相关考虑，为服务开发人员设计了一套定制自己所需的BPEL模板，即模板抽取机制；因为在开发BPEL流程，尤其是开发行业领域相关流程时，有不少业务逻辑是类似的或部分类似的。如果能够将这些会被频繁用到的业务逻辑封装成模板，在开发时作为一个整体使用，必然给开发人员带来极大的便利。该子系统设有：模型层、控制层、用户接口UI层和验证层。模型层是整个子系统的基础，提供整个子系统的图形化和各项功能所需要的模型，主要建立了两个基本模型：BPEL模型和模板模型。控制层用于对该子系统中的整个可视化进行控制操作，并且实现了BPEL脚本解析、模板抽取和封装、服务组合和新业务导出的功能。UI层是该子系统的可视介面，主要实现了调色板、编辑窗口、属性视图、大纲视图和向导视图等功能。验证层的功能是在该子系统流程的不同阶段对该子系统中的相关操作进行必要的验证。主要针对三个阶段实施相应的验证：模板抽取、模板组合和模板导出，进而也对该子系统的各个层次的操作执行相应的验证：模型建立、BPEL脚本解析、模板抽取、服务组合和新业务生成等操作。该子系统有良好的灵活性和定制性，能让用户使用该子系统建立自己的模板库，从而将各人感兴趣的BPEL业务逻辑分别封装成模板保存到模板库中。该子系统提供给用户一套完整的模板抽取和封装的功能。这些抽取出来的模板能有效降低用户的开发难度。

参见图3，具体介绍面向混合服务的多任务并发执行子系统的组成结构中的三个主要部件：服务总线，动态流程执行引擎和低延迟事件服务引擎。其中，

提供消息传输路由和执行转发操作的服务总线，用于接收客户端通过HTTP协议承载包含业务请求的SOAP消息，将其转换为规格化消息，转发给后续部件处理；该服务总线设有两个核心功能单元：HTTP绑定组件和规格化消息路由器。HTTP协议绑定组件用于侦听和接收来自客户端的HTTP请求，该组件接收到SOAP消息后，解析并处理HTTP协议请求包，再将该SOAP消息主体封装成规格化消息(该规格化消息是指将包含特定上下文数据的消息转换成服务总线中规格化路由器能理解和通用的表现形式)和设置消息交换的服务端点属性(即将目的服务引擎设定为动态流程执行引擎)后，将业务服务请求消息传递到规格化消息路由器，进而路由到动态流程执行引擎。规格化消息路由器除了用于路由经由HTTP协议绑定组件处理的业务请求消息外，还负责在来自动态流程执行引擎和低延迟事件服务引擎的双引擎之间路由彼此交互的消息，并将其路由到相应的组件进行处理。

动态流程执行引擎相对独立地直接部署于服务总线，用于直接采用规格化消息与服务总线进行交互，并发执行原子服务组合后生成的业务控制流程，监听并接收服务总线转发的包含客户端请求的规格化业务服务消息，创建相应业务控制流程的BPEL业务流程实例并进行处理，并在处理过程中，通过Java并发对象框架实现应用级别的并发，然后生成调用低延迟事件服务引擎中服务能力组件的包含相应业务请求的SOAP消息，再将其发送到服务总线，设置消息交换的服务端点属性，即将目的服务引擎指定为低延迟事件服务引擎，再通过服务总线路由到低延迟事件服务引擎。

动态流程执行引擎设有：流程编译器、流程执行器、抽象流程管理器和BPEL业务流程库。流程编译器负责将BPEL源文件(包括BPEL流程文件、WSDL文件和schema文件)编译成适合于流程执行器执行的文件，输出编译好的文件或源文件中的错误信息列表，其编译生成的BPEL文件是在结构上跟BPEL流程文件类似的对象模型文件，包括BPEL流程中的各种引用(如变量名)，WSDL文件和类型信息，其编译后的文件是流程执行器所需的唯一文件。流程执行器主要用于执行编译后的BPEL流程，包括何时创建新实例，接收的新消息转送到哪个实例，以及给用户提供流程管理API，让用户与执行引擎进行交互。为使该执行引擎可靠运行，由数据访问对象模块提供数据持久性，因此它通过Java并发对象框架实现应用级别的并发机制。抽象流程管理器负责完成流程执行器与外界的交互，主要功能是为流程执行器提供通信通道，将流程执行器直接嵌入到具体的执行环境中，如JBI抽象流程管理器是实现流程执行器与JBI的低延迟事件服务引擎等组件交互。BPEL业务流程库用于存储包括已创建的服务流程实例、实例所等待的消息、每个实例的BPEL变量值、每个实例的BPEL伙伴链接值以及每个服务流程实例在流程执行器中的执行状态等信息。

低延迟事件服务引擎也是相对独立地直接部署在服务总线上，用于直接采用规格化消息与服务总线进行交互，提供动态流程执行引擎调用的相应业务原子服务，该部件基于事件驱动，内部采用服务构件块SBB消息机制，减少事务处理的等待延迟，其工作方式是从服务总线接收包含业务请求的SOAP消息后，扫描该事件状态，将该事件递交到服务能力组件中该事件已注册的对应服务构件块，生成相应业务的原子服务，再与服务资源接入子系统进行交互，调用服务资源接入子系统提供的服务资源。

低延迟事件服务引擎设有三个功能单元：规格化消息适配器、服务能力组件和资源适配器。规格化消息适配器用于接收规格化消息路由器上传的规格化消息，并对其进行解析，将其定义成低延迟事件服务引擎能够识别的类型，再将其发送到服务能力组件；还负责接收从服务能力组件传来的响应，将其封装成规格化消息返回给服务总线。服务能力组件是该引擎的核心单元，用于对动态流程执行引擎所需原子服务进行业务逻辑控制，并为服务构建块提供运行环境，再通过资源适配器与服务资源接入子系统建立连接和交互通信，获取网络服务资源，将服务响应返回给规格化消息适配器。资源适配器用于适配网络资源或JAVA平台环境J2EE资源，将发生变化的资源以事件形式发送到服务能力组件，由服务能力组件将资源事件触发到业务实例进行业务逻辑处理；资源适配器还将底层网络资源抽象成应用程序接口API提供给业务逻辑使用。

下面介绍本发明基于融合开放网络的混合服务支撑系统的工作方法，主要包括下列三个操作步骤：

步骤1、服务生成子系统执行服务的生成及验证，即由服务开发者利用服务生成子系统完成服务流程的开发过程；

步骤2、多任务并发执行子系统完成服务的部署及执行，在服务执行过程中，多任务并发执行子系统要调用服务资源接入子系统所提供的通信能力；

步骤3、在该支撑系统的整个运行过程中，服务管理子系统负责对上述服务的生成、验证、部署和执行的全部流程执行协调管理，即对整个服务支撑系统的全部运行过程提供公共服务支持，并统一协调管理各个子系统的操作。

参见图4，具体描述上述步骤1的操作内容：

(11)抽取服务模板：服务开发者利用服务生成子系统，通过基于模板的机制对要重复利用的BPEL片段或服务模板进行有效封装后，保存于模板库；

在该步骤中，为有效复用BPEL代码，先要完成对BPEL代码段的描述或定义；当服务开发者抽取其准备封装的BPEL代码段后，服务生成子系统自动将其封装为统一形式的模板，通过系统解析，该模板详细记录该被抽取的BPEL代码段的接口信息。所以，服务生成子系统必须先提供一套模板封装的模型定义，用于保存所需信息。

服务生成子系统采用自定义的扩展标签完成对模板的定义，即通过定义模板的模型shema来实现建模过程；对于要被复用的BPEL代码段，可以理解为一个函数中的代码，模板是要给该代码段进行类似函数接口的定义和描述。所以每个模板在给用户使用时，必须声明其中的下述各个接口定义；

<template>保存当前模板的包括命名空间和模板名称的自身信息；

<inputVariable>保存模板中作为输入变量的包括输入消息中的所有输入参数和参数结构，以及每个输入参数用于哪个活动的输入变量各种信息；

<outputVariable>保存模板中作为输出变量的包括输出消息中的所有输出参数和参数结构，以及每个输出参数用于哪个活动的输出变量的各种信息；

<element>说明在变量中定义的具体参数的信息；

<condition>保存模板中作为控制条件的包括该控制条件的内容及其所在的控制活动和抽取时用户增加的注释的相关信息；

<activity>保存在抽取的BPEL代码片段中包含的BPEL活动信息；

<bpelCode>保存模板封装的BPEL代码片段；

<wsdlCode>保存模板封装的BPEL代码片段相关联的WSDL文件信息。

(12)组装服务模板：服务开发者设计业务流程时，利用服务生成子系统提供的图形化开发环境，采用拖拽和点击的图形化方式将BPEL流程的开发与模板的拼装融合在一起，即将已生成的服务模板导入到当前业务流程的编辑窗口中，供用户按需使用；使服务开发者能轻松复用已经抽取出来的模板，减少二次开发时间，实现高效开发。

该步骤包含下述操作内容：当用户打开图形编辑窗口，准备开发一个新的业务流程时，服务生成子系统在提供BPEL代码的基本编辑能力以外，还提供基于模板的流程编辑方式：即自动读入保存在模板库中的各个模板信息，将这些模板导入到当前的业务流程编辑窗口中，以供用户随时选用；这样用户就能方便地复用已经抽取出来的模板，再为所选用的模板定义变量信息和控制条件，同时配合BPEL活动进行模板的控制和补全，就能快速组合开发出用户所需的新的业务流程。已经建立对应的模板库后，就可以模板库中的模板作为起点，配合上BPEL的基本活动和容器活动实现灵活的业务开发方式。

(13)导出服务模板：在用户完成基于模板的业务流程的编辑开发工作后，服务生成子系统要将此时得到的基于扩展标签完成的包含有模板的业务流程文件不是标准的BPEL脚本，无法部署到BPEL执行引擎中运行。该子系统的导出机制能够将包含模板的流程转换为标准的可执行的BPEL文件，并删除以前对BPEL片段增加的封装，从而可以在多任务并发执行子系统或任何BPEL执行引擎上运行。

(14)验证服务生成的全过程：在上述三个步骤的业务流程开发过程中，服务生成子系统对其分别执行包括BPEL语法验证和模板语义验证的支持，保证服务的正确性。该步骤包含以下操作内容：

在抽取服务模板阶段，对作为模板的BPEL文件和相关的WSDL文件进行BPEL语法验证，保证服务模板的抽取是在正确的流程基础上执行的；

在组装服务模板阶段，对当前编辑的服务流程进行BPEL语法验证，同时在编辑过程中进行语义验证；在服务开发者对模板的输入或输出的变量进行匹配时，提醒其完成相应操作；当模板充当流程侧起点时，检验模板中是否有能够创建实例的receive或pick活动。

总之，步骤1的服务生成及验证过程的实质是生成用BPEL描述的服务的流程，通过该流程，使得人们知道对于每个服务，先执行什么操作，后执行什么操作，需要调用哪些原子服务，但是这些服务流程的具体执行要有一个执行环境，该执行环境可以完成对服务流程的部署，原子服务的提供以及能够调用外部的通信资源，这些工作在本发明中是由多任务并发执行子系统来完成，也就是步骤2的操作。

下面具体描述步骤2的下述两个操作内容：

(21)服务的部署：将每个已经完成的服务所涉及的服务流程与原子服务等进行组合，再打包部署到多任务并发执行子系统中，以便在用户的服务请求到达时，该支撑系统能够根据具体请求提供相应的服务。

(22)服务的执行，当用户的服务请求到来时，多任务并发执行子系统根据服务请求的具体内容，为该请求分配匹配的已完成部署的服务流程，再由该服务流程调用相关原子服务和对应的外部通信资源，完成整个服务的执行过程。

这里先介绍服务在被用户请求执行之前，服务部署的具体细节：

本发明多任务并发执行子系统中的基于JBI规范的服务总线可视为一个大容器，要构成一个系统，里面还要部署多个小容器，如动态流程执行引擎和低延迟事件服务引擎。若要执行业务，还要将相应的业务描述进行组合，然后打包部署到服务总线中；以便服务请求到达时，该系统能够根据具体请求提供相应的服务。对于每个特定业务来讲，其业务控制流程由BPEL代码段实现，该业务的原子服务则由低延迟事件服务引擎实现，并由服务总线中的HTTP协议绑定组件监听接收相应的业务请求。

参见图5，说明每个服务的部署的下述操作内容：

步骤A、分析该服务的需求和实现该服务所需的各个原子服务；再将实现该服务的各个原子服务部署到低延迟事件服务引擎中；

步骤B、为实现该服务的多个原子服务编辑一个服务描述文件，并将其打包成一个能够部署到低延迟事件服务引擎的服务单元SU(Service Unit)；

步骤C、为服务生成子系统生成的BPEL业务控制流程编写一个能部署于动态流程执行引擎的部署描述文件，再将该部署描述文件、编辑好的BPEL控制流程和相应的WSDL文件打包成一个能部署于动态流程执行引擎的服务单元；

步骤D、为该服务编写一个HTTP绑定组件描述文件，用于接收客户端的客户业务请求，打包成为能够部署于HTTP协议绑定组件的服务单元；

步骤E、将上述三个步骤分别产生的三个服务单元打包成一个完整的服务集SA(Service Assembly，参见图5所示)，该服务集SA包就是整个服务的部署包；再将该部署包部署于多任务并发执行子系统，然后，就能够提供给用户通过客户端调用。

本发明方法中的步骤3的管理功能主要由服务管理子系统执行，该子系统也是构建可运营的服务支撑平台的重要组成部分，用于执行包括业务服务的计费、认证、鉴权、配置和对用户进行管理等各种运行和维护的功能。因为，前面已经对该子系统的相关功能作了详细说明，这里就不再赘述。

参见图6和图7，介绍动态流程执行引擎中，基于ACTOR并发模型的JAVA并发对象框架及其执行流程。

JAVA并发对象框架的实现是基于ACTOR模型。ACTOR模型是著名的并发计算模型，目前其已成为研制并发面向对象语言的一种重要的基础模型。ACTOR模型的基本特点是：在ACTOR模型中，所有对象都是actor，也就是actor是ACTOR模型的原子单位，消息是actor对象之间通信的唯一方式。

动态流程执行引擎中的JAVA并发对象框架遵循ACTOR模型的基本思想，在JAVA并发对象框架下，所有事物都可以作为一个JAVA并发对象，消息是JAVA并发对象之间通信的唯一方式，所有消息发送都是并行的；JAVA并发对象包括消息输入队列、调度机制、方法、状态，以及收到消息时将采取的动作。

图6所示是JAVA并发对象框架结构组成示意图，在JAVA并发对象框架中，JAVA并发对象执行单元(VPU)是执行JAVA并发对象的地方，VPU主要负责把JAVA并发对象注入到执行队列中，并创建和执行一个JAVA并发对象线程，运行JAVA并发对象；并在该对象运行结束后，立即释放该线程。也就是说，在JAVA并发对象框架下，每个JAVA并发对象都是各自独立的，彼此之间通过消息进行交互，只是在消息到来时，借用一个线程执行，且在执行后立即释放。因此，JAVA并发对象框架无共享、基于消息等特点，使得死锁、状态共享、异步调用等困扰多线程编程的问题不复存在。

参见图7，依据JAVA并发对象框架的操作执行时序，介绍其执行流程：

(1)创建：在动态流程执行引擎中，抽象流程管理器接收到来自服务总线的规格化消息请求，配置和启动流程执行器，流程执行器根据上下文创建JAVA并发对象框架中的并发对象执行单元VPU；

(2)注入：VPU将相关的JAVA并发对象注入到JAVA并发对象执行队列；

(3)出列：JAVA并发对象出执行队列；

(4)创建：JAVA并发对象框架中的VPU创建JAVA并发对象线程；

(5)执行：JAVA并发对象占用该已创建的线程，运行该JAVA并发对象中的方法。

因此，JAVA并发对象框架的并发性的管理是建立于每个过程实例的单个线程基础上，避免了创建过多的线程而带来的线程调度对系统性能的影响，而且线程的分配是在消息到达时进行的，进一步避免了过多线程的使用。

参见图8，介绍本发明中的多任务并发执行子系统的低延迟事件服务引擎中的规格化消息适配器对来自服务总线的消息的处理流程。其处理过程主要包含两个内容：消息解析和事件发送，具体流程如下：

(1)规格化消息适配器接收从服务总线的规格化消息路由器发送来的业务请求规格化消息。

(2)从规格化消息中获取消息载荷，该消息载荷的核心内容是SOAP消息。

(3)解析SOAP消息，从其中取出每个标签对应的值，存储在一个哈希表对象中，并返回该哈希表对象。然后，对基于XML文档格式的SOAP消息的处理就转换为对常用数据类型的哈希表的处理。

(4)从哈希表中获取消息请求服务的服务名，再根据该服务名通过对应的服务方法调用该服务所需的具体事件属性。

(5)找到该事件向服务能力组件传输的上下文通道信息，向服务能力组件转发，从而触发相应的业务处理逻辑。

参见图9，介绍本发明进行的实施试验情况：即以多媒体会议为业务场景，介绍本发明面向混合服务的多任务并发执行子系统中，客户端从发起多媒体会议服务请求到接收到响应的整个消息交互流程的各个操作步骤：

(1)客户端接收到用户输入的发起会议服务请求后，先将该请求传送到服务总线，服务总线上的HTTP绑定组件接收到该会议服务请求消息。

(2)HTTP绑定组件创建消息交换实例，并根据需求将接收到的消息转换成规格化格式直接放入消息交换实例中，设置该消息交换的服务端点属性，然后将该会议服务请求消息传送到规格化消息路由器。

(3)规格化消息路由器接收到会议服务请求消息，解析消息头，寻找目的服务引擎，创建消息流的处理实例，再将该服务请求转发至动态流程执行引擎，由动态流程执行引擎启动和调用该会议服务请求所对应的会议业务逻辑的BPEL服务流程。

(4)会议业务逻辑的BPEL服务流程对该服务请求进行分析处理后，将该调用会议能力组件的请求消息发送到规格化消息路由器。

(5)规格化消息路由器在动态流程执行引擎和低延迟事件服务引擎间建立另一个消息流的处理实例，将该调用会议能力组件的请求消息经由服务总线发送到低延迟事件服务引擎。

(6)低延迟事件服务引擎通过其规格化消息适配器接收到来自服务总线的业务请求后，将业务请求映射到服务能力组件进行处理及响应。

(7)经过会议服务能力组件处理后，该调用服务会议能力组件的请求消息沿着请求路径返回规格化消息路由器，同时，上述步骤建立的消息流的流处理通道也被递交给会议业务逻辑的BPEL业务流程；再通过服务资源接入子系统进行交互，调用服务资源接入子系统的服务资源，由会议服务能力组件执行该服务。

(8)会议业务逻辑的BPEL业务流程将会议能力组件对调用会议能力组件的请求消息的处理及响应结果，重新组合成用户所需的Web服务格式，再次返回到规格化消息路由器，该步骤中的消息沿上述步骤建立的消息流的流处理通道返回到HTTP绑定组件；HTTP绑定组件将接收到的该消息转换形式后，作为会议服务请求消息的响应结果返回。

(9)应用服务器将Web服务格式的会议服务请求消息的响应结果转换成会议请求消息的响应结果后，返回给客户端，并将对会议请求消息的最终响应结果返回递交给用户端。

申请人已经对本发明进行了多次实施仿真试验，试验的数据结果表明，试验是成功的，实现了发明目的。

Claims (8)

1.一种基于融合开放网络的混合服务支撑系统，以IP骨干网作为包括固定电话网PSTN，第二代无线通信网2G和2.5G、第三代移动通信网3G，以及无线网络Wi-Fi与Wi-MAX和分组数据网的各种异构网络融合的基础，用于支持在融合开放网络环境中，提供基于模板复用的服务生成以及多任务的并发执行；其特征在于：该系统至少包括：

基于模板复用的服务生成子系统，用于为业务开发者提供基于粗粒度模板的服务开发方式、BPEL业务流程的验证与测试支持和生成以BPEL脚本形式展现、能运行于所有通用的BPEL执行引擎的服务流程；该子系统设有独立的模板模型，并提供基于模板的BPEL代码的复用方法和一套面向BPEL的业务开发者的、采用拖拽和点击的图形化方式的业务开发环境，能够完成针对BPEL代码的包括服务模板的抽取、封装、拼接和导出生成新业务的复用机制，以降低业务的二次开发难度，提高开发效率；

面向混合服务的多任务并发执行子系统，分别连接服务生成、服务资源接入和服务管理三个子系统，为混合服务提供稳定可靠的业务编排及执行环境；设有三个部件：承载服务生成子系统生成的服务流程、执行依据WS-BPEL标准编写的业务流程、调用Web服务、发送和接受消息、进行数据处理和故障恢复的动态流程执行引擎，基于事件驱动的异步通信调用、处理复杂的网络协议、增加系统对高吞吐量与低延迟电信服务的支持的低延迟事件服务引擎，以及采用包括分布式处理、智能路由与动态数据转化的方法，利用不同协议支持异构应用及服务之间通信的服务总线，该服务总线在动态流程执行引擎及低延迟事件引擎之间传递信息；该多任务并发执行子系统还负责为生成的服务流程提供对应的服务构件块SBB(Service Building Block)，集成接入各种网络资源，同时为服务管理子系统提供相应的管理接口；

服务资源接入子系统，通过多种网关与各个网络运营商的通信网络相连接，将包括Parlay或ParlayX、SMS、MMS、LBS、GIS、SIP和E-Mail的各种协议能力统一封装成Web服务供其他子系统调用，再通过相应协议连接各种应用系统，通过兼容开放的标准协议接口，接入网络运营商授权的各种现有通信业务和实现互通，并提供各种通信业务的协议支持；再通过与智能网相关设备的配合，实现与各种传统话音增值业务和新业务的互通，并与多任务并发执行子系统实现业务的数据交互；

服务管理子系统，分别连接服务生成、多任务并发执行和服务资源接入三个子系统，用于通过浏览器方式，提供各级管理维护人员对所述三个子系统实现协调管理，对该服务支撑系统执行维护操作与提供公共服务支持，并对各系统业务进行统一管理。

2.根据权利要求1所述的系统，其特征在于：所述服务资源接入子系统至少设有下述接入网关：

Parlay/ParlayX网关，分别连接PSTN网、移动通信网2G、2.5G、3G和下一代网络NGN，用于接入相关网络执行网络运营商授权业务的交互；

短消息服务SMS网关，用于连接移动通信网2G、2.5G和3G，提供短消息类的授权业务；

多媒体消息服务MMS网关，用于连接移动通信网2G、2.5G和3G，提供多媒体消息类的授权业务；

LBS网关，用于连接移动通信网2G、2.5G和3G，提供移动终端的定位业务；

GIS网关，用于连接Internet中的地理信息服务，提供地理信息业务；

SIP网关，用于连接3G移动通信网络、NGN网络、Wi-Fi网络、Wi-MAX网络和因特网，提供基于IP的话务业务；

Mail网关，用于连接Internet中的邮件服务器，与服务资源接入子系统的其它网关共同向用户提供mail提醒和转发业务；

Web服务网关，用于连接Internet，向用户提供web查询及推荐业务；

上述各个网关分别连接多任务并发执行子系统，向多任务并发执行子系统发送业务请求并接收其发来的业务指令。

3.根据权利要求1所述的系统，其特征在于：所述服务管理子系统对该服务支撑系统执行维护操作与提供的公共服务支持的具体内容包括：

配置管理，执行包括配置计费数据和对配置数据的管理、系统与各个子系统的操作数据自动备份的功能；

故障管理，执行包括对该服务支撑系统的运行状态的监视和故障监测、故障告警、故障定位、故障日志和故障分析的功能；

安全管理，执行接入认证与鉴权操作，支持分级的管理用户接入方式，以使不同权限的管理用户执行相应的不同操作，还支持多点操作和定时启动命令；

日志管理，执行包括安全日志、日志管理的功能；该安全日志作为安全管理的重要证据，会将所有操作员的关键操作都自动地记录于安全日志；

计费和业务管理，能够支持多种计费方式，以便对短信及数据业务，支持按流量计费和按内容计费；对传统话音服务及视频服务，支持按时间计费。

4.一种基于融合开放网络的混合服务支撑系统的工作方法，其特征在于：包括下列操作步骤：

(1)服务生成子系统执行服务的生成及验证，即由服务开发者利用服务生成子系统完成服务流程的开发过程；该步骤(1)进一步包括下述操作内容：

(11)服务模板的抽取：服务开发者利用服务生成子系统，通过基于模板的机制对要重复利用的BPEL片段或服务模板进行有效封装后，保存于模板库；

(12)服务模板的组装：服务开发者设计业务流程时，利用服务生成子系统提供的图形化开发环境，采用拖拽和点击的图形化方式将BPEL流程的开发与模板的拼装融合在一起，即将已生成的服务模板导入到当前的业务流程编辑窗口中，供用户按需使用；使服务开发者能轻松复用已经抽取出来的模板，减少二次开发时间，实现高效开发；

(13)服务模板的导出：在完成基于模板的业务流程的编辑后，服务生成子系统要将此时得到的基于扩展标签完成的包含有模板的业务流程文件，导出为能够在多任务并发执行子系统或任何BPEL执行引擎上运行的标准BPEL文件，并删除以前对BPEL片段增加的封装，完成到BPEL脚本的转换；

(14)服务的验证：在上述三个步骤的执行过程中，服务生成子系统对其分别执行包括BPEL语法验证和模板语义验证的支持，保证服务的正确性

(2)多任务并发执行子系统完成服务的部署及执行，在服务执行过程中，多任务并发执行子系统要调用服务资源接入子系统所提供的通信能力；

(3)在该支撑系统的整个运行过程中，服务管理子系统负责对上述服务的生成、验证、部署和执行的全部流程执行协调管理，即对整个服务支撑系统的全部运行过程提供公共服务支持，并统一协调管理各个子系统的操作；其中，每个服务的部署进一步包括下述操作内容：

分析该服务的需求和实现该服务所需的各个原子服务；再将实现该服务的各个原子服务部署到低延迟事件服务引擎中；

为实现该服务的多个原子服务编辑一个服务描述文件，并将其打包成一个能够部署到低延迟事件服务引擎的服务单元SU(Service Unit)；

为服务生成子系统生成的BPEL业务控制流程编写一个能部署于动态流程执行引擎的部署描述文件，再将该部署描述文件、编辑好的BPEL控制流程和相应的WSDL文件打包成一个能部署于动态流程执行引擎的服务单元；

为该服务编写一个HTTP绑定组件描述文件，用于接收客户端的客户业务请求，打包成为能够部署于HTTP协议绑定组件的服务单元；

将上述三个步骤分别产生的三个服务单元打包成一个完整的服务集SA(Service Assembly)，该服务集SA包就是整个服务的部署包；再将该部署包部署于多任务并发执行子系统，然后，就能够提供给用户通过客户端调用。

5.根据权利要求4所述的方法，其特征在于：所述步骤(11)中，为有效复用BPEL代码，先要完成对BPEL代码段的描述或定义；当服务开发者抽取其准备封装的BPEL代码段后，该服务生成子系统自动将其封装为统一形式的模板，通过系统解析，该模板详细记录该被抽取的BPEL代码段的接口信息；故服务生成子系统必须先提供一套模板封装的模型定义，以保存所需信息；

该服务生成子系统采用自定义的扩展标签完成对模板的定义，即通过定义模板的模型来实现建模过程；模板给BPEL代码段进行接口定义，每个模板在给用户使用时，必须声明其中下述各个接口的定义；

<template>保存当前模板的包括命名空间和模板名称的自身信息；

<inputVariable>保存模板中作为输入变量的包括输入消息中的所有输入参数和参数结构，以及每个输入参数用于哪个活动的输入变量各种信息；

<outputVariable>保存模板中作为输出变量的包括输出消息中的所有输出参数和参数结构，以及每个输出参数用于哪个活动的输出变量的各种信息；

<element>说明在变量中定义的具体参数的信息；

<condition>保存模板中作为控制条件的包括该控制条件的内容及其所在的控制活动和抽取时用户增加的注释的相关信息；

<activity>保存在抽取的BPEL代码片段中包含的BPEL活动信息；

<bpelCode>保存模板封装的BPEL代码片段；

<wsdlCode>保存模板封装的BPEL代码片段相关联的WSDL文件信息。

6.根据权利要求4所述的方法，其特征在于：所述步骤(12)进一步包含下述操作内容：当用户打开图形编辑窗口，准备开发一个新的业务流程时，服务生成子系统在提供BPEL代码的基本编辑能力以外，还提供基于模板的流程编辑方式：即自动读入保存在模板库中的各个模板信息，将这些模板导入到当前的业务流程编辑窗口中，以供用户随时选用；用户就能轻松地复用已经抽取出来的模板，再为所选用的模板定义相关的变量信息和控制条件，同时配合BPEL活动进行模板的控制和补全，就能够快速组合开发出用户所需的新的业务流程。

7.根据权利要求4所述的方法，其特征在于：所述步骤(14)进一步包含以下操作内容：

在服务模板的抽取阶段，对作为模板的BPEL文件和相关的WSDL文件进行BPEL语法验证，保证服务模板的抽取是在正确的流程基础上执行的；

在服务模板的组装阶段，对当前编辑的服务流程进行BPEL语法的验证，同时在编辑过程中进行语义的验证；在服务开发者对模板的输入或输出的变量进行匹配时，提醒其完成相应操作；当模板充当流程侧起点时，检验模板中是否有能够创建实例的receive或pick活动。

8.根据权利要求4所述的方法，其特征在于：所述步骤(2)进一步包括下述操作内容：

(21)服务的部署：将每个已经完成的服务所涉及的服务流程与原子服务进行组合，再打包部署到多任务并发执行子系统中，以便在用户的服务请求到达时，该支撑系统能够根据具体请求提供相应的服务；

(22)服务的执行，当用户的服务请求到来时，多任务并发执行子系统根据服务请求的具体内容，为该请求分配匹配的已完成部署的服务流程，再由该服务流程调用相关原子服务和对应的外部通信资源，完成整个服务的执行过程。

Images