近年来，随着互联网技术的不断发展，网络上聚集了越来越多的资源，不仅包括丰富的计算、存储等物理资源，还有大量的软件、服务资源，且资源的数目和类型也日益增长，为基于服务的网络软件开发提供了重要的基础。同时，简单对象访问协议(Simple Object Access Protocol；简称：SOAP)、网络服务描述语言(Web Services Description Language；简称：WSDL)、统一描述发现和集成(Universal Description Discovery and Integration；简称：UDDI)和业务流程执行语言(Business Process Execution Language；简称：BPEL)等标准的制定，进一步促进了网络(web)服务技术及面向服务的软件结构(Service-Oriented Architecture；简称：SOA)的快速发展，使得异构信息、异构平台的共享与集成成为可能，基于服务的分布式应用系统开发成为一个重要的方向。
Web服务技术可以用于解决了不同的平台/系统之间应用的整合问题，为跨组织边界的业务流程的自动化提供技术基础，但由于服务的提供者分工越来越细，并且为了保证重用性和可维护性等，一般不将复杂的业务逻辑封装到单个的Web服务中。为了满足用户多样性的需求，实现完整的业务功能，把分布的独立的Web服务组合起来，形成具有增值价值的服务，称为服务组合技术，是一种构建网络化软件的重要方法。服务组合技术基于服务组合的网络软件开发，按照需求(功能和非功能需求)集成不同服务供应商提供的软件服务实体，这些服务实体可以位于不同的管理域，具有异构性、自治性和动态性等特点，例如：服务运行在不同系统平台之上，具有不同的自治策略如访问控制、事务处理策略等)，服务的状态和性质动态变化等；同时，网络应用的多样性和复杂性增加，许多应用不仅对软件核心功能需求增多，而且对非功能的需求(如可靠性、可信性和可用性等)也越来越高。因此，对组合服务系统的构造、部署、管理、演化等机制，都提出了诸多挑战。
目前，存在不同的可用于Web服务组合的工作流语言如网络服务流程的语言(Web Services Flow Language；简称：WSFL)及业务流程执行语言(Business Process Execution Language；简称：BPEL)等，这些语言大都定义两种类型的活动：基本活动，结构活动。其中组合主要基于结构活动，包括：顺序活动，一系列服务按顺序执行的活动；选择活动，允许从一组分支中只选择一个分支来执行的活动；循环活动，定义服务循环执行的活动；并行活动，指明一组服务并行执行的活动。
基于交互协议的web服务组合将服务间外部交互和服务内部逻辑分离，通过协议进行服务的编排，使协作各方自然根据领域内的标准协议进行交互。通过描述参与的协议和在其中扮演的角色可以准确的刻画服务的外部交互行为，避免交互行为的不一致而导致服务组合失败。协议强调业务交互的基本特征而不涉及实现细节，并且通过协议计算，即简单、通用的协议构件经过一系列的组合计算生成个性化的、复杂的交互过程，各个服务可以在协议——角色框架内调整交互行为，从而方便的从业务逻辑映射到不同的物理实现。
Web服务编排描述语言(Web Services Choreography DescriptionLanguage；简称：WS-CDL)是面向服务间协作会话的服务组合描述语言，通过假定不同的合作伙伴间通过对等的模式进行协作交互，以全局的方式刻画服务间的消息交互。WS-CDL与Web服务的业务流程执行语言(BusinessProcess Execution Language For Web Services；简称：BPEL4WS)可以互补，先使用WS-CDL进行全局的建模，再映射为单方的BPEL4WS进行描述和执行。以协议作为基本计算单元研究服务间交互可以有效提高服务组合的复用性和灵活性，可以首先给出一个通用的、适合于任何情况的协议，然后根据不同的情况配置成符合特定需求的协议。可以通过协议的复用来构造复杂的业务过程，但是仍然需要预先确定协议的组合结构，特别是面对企业间协作的动态的、复杂的业务过程，需要研究协议组合如何能够在保证行为一致性的前提下进行组合服务的优化问题。
基于协议的服务组合需要集成不同服务者提供的软件服务实体，这些服务实体具有异构性、自治性和动态性等特点，运行于不同的系统平台，位于不同的管理域内，采用不同的业务策略，并且服务的状态和性质不断变化，容易出现故障，可信性水平低。

本发明提供一种基于协议的服务组合系统和方法，用以解决现有技术容易出现故障，可信性水平低中的缺陷，实现对系统中的服务进行故障检测，提高基于协议的服务组合系统的可信性水平。
本发明提供一种基于协议的服务组合系统，包括：组合服务运行环境、服务总线、服务信息管理器、服务监测系统和优化管理器；
所述组合服务运行环境通过所述服务总线与客户端交互，用于承载所述用户端的各个服务的运行、管理和监控；
所述服务监测系统，用于监测所述组合服务运行环境中的服务，将监测结果反馈给所述优化管理器和服务信息管理器；
所述优化管理器，用于根据设置的优化管理策略，对所述服务监测系统的监测结果进行优化调整；
所述服务信息管理器，用于根据所述服务监测系统的监测结果对所述服务总线和所述组合服务运行环境进行管理。
本发明还提供一种基于协议的服务组合方法，包括：
监测器监测组合服务运行环境中的服务，将监测结果反馈给优化管理器；
所述优化管理器根据设置的优化管理策略，对所述监测器的监测结果进行优化调整。
本发明提供的基于协议的服务组合系统和方法，采用服务监测系统监测组合服务运行环境中的服务，将监测结果反馈给优化管理器，优化管理器根据设置的优化管理策略，对监测结果进行优化调整，可以提高基于协议的服务组合系统的可信性水平。
附图说明
为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明基于协议的服务组合系统实施例的结构示意图；
图2为本发明基于协议的服务组合系统实施例中服务监测系统的结构示意图；
图3为本发明基于协议的服务组合系统实施例中监测器的结构示意图；
图4为本发明基于协议的服务组合方法实施例的流程图；
图5为本发明基于协议的服务组合方法实施例中监测修复过程的示意图。

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明基于协议的服务组合系统实施例的结构示意图，如图1所示，该基于协议的服务组合系统包括：组合服务运行环境11、服务总线13、服务信息管理器14、服务监测系统15和优化管理器16；
其中，组合服务运行环境11通过服务总线13与客户端交互，用于承载所述用户端的各个服务的运行、管理和监控；
服务监测系统15，用于监测组合服务运行环境11中的服务，将监测结果反馈给优化管理器16和服务信息管理器14；
优化管理器16，用于根据设置的优化管理策略，对服务监测系统15的监测结果进行优化调整；
服务信息管理器14，用于根据服务监测系统15的监测结果对服务总线13和组合服务运行环境11进行管理。
在基于协议的服务组合系统中，服务例如：构件服务、组合服务可以被看作黑盒，不能访问服务的源码，了解服务的内部结构或私有策略，但各业务域内的设计类似商业伙伴流程(Partner Interface Processes；PIPs)协议，存储在协议规则库中，其中构件服务是组合服务中的成员服务。本发明中的基于协议的服务组合系统主要包括组合服务运行环境11、服务总线13、服务信息管理器14、服务监测系统15和优化管理器16等，分别为Web服务和服务组合提供部署、执行及监测管理等功能的环境支持。
其中，组合服务运行环境11为组合服务提供运行、管理和监控环境，承载用户端的各个服务的运行、管理和监控，支持资源协调、服务优化调度和服务组合流程调试，并支持Web服务自治和群组机制；同时，为进一步提高效率，保证组合服务可靠执行，基于协议的服务组合系统支持故障恢复和流程状态的完整性保护。组合服务运行环境11具体可以包括传输协议层、消息处理层、服务调用层、服务适配器和组合服务执行引擎构成。其中，传输协议层提供服务提供者和消费者之间消息交换的机制，保证传输协议的透明性，支持HTTP、HTTPS、SMTP和FTP等传输协议。消息处理层提供消息处理机制，包括简单对象访问协议(Simple Object Access Protocol；简称：SOAP)消息解析、可靠消息处理和寻址处理等处理过程。服务调用层提供通过服务请求、选择服务及其相应操作，支持服务的部署，服务上下文管理；同时，服务调用层还提供基于服务质量(Quality of Service；简称：QoS)的服务选择功能，保证优先级高的请求优先执行。服务适配器提供服务请求到已部署的服务中操作的匹配，根据服务部署时提供的信息可以选择合适的服务适配器执行服务适配过程，基于协议的服务组合系统可以支持Java、CORBA、C++适配及资源适配等；同时，系统服务支持资源的创建、查找和调用过程，并可以通过通知管理器对资源状态改变进行通知管理，通过群组管理器对资源进行群组管理。组合服务运行环境构建在系统服务之上，提供管理、存储、事件、监测、安全、日志等服务的保证，组合服务执行引擎可以包括冗余服务管理器和规则解析管理器，其中，规则解析管理器可以对组合服务的规则进行解析和管理。
服务监测系统15主要对部署在Web服务的组合服务运行环境11中的构件服务和组合服务，通过系统提供的接口进行监测。优化管理器16可以通过管理接口获取各种服务质量特性和交互信息，分析并根据其内置的管理策略对各组合服务流程和选择的服务做出适当调整，使组合服务具备一定的自优化能力。此外，基于协议的服务组合系统还可以包括：开发工具，为服务组合提供工具支持，包括服务组合建模工具和服务组合构造工具；访问工具即客户端，例如：Web服务的Java客户端、AJAX客户端和信息门户等，提供不同语言和访问模式(例如：B/S和C/S)对组合服务运行环境11和服务总线13的访问能力；此外，基于协议的服务组合系统网络应用层的软件平台可以支持电子政务、电子商务、智能交通等网络应用。
在基于协议的服务组合系统中，根据协议规则库中公布的协议规约确定服务间的交互，通过协议规则库中的协议组合生成组合服务，可以通过服务监测系统15访问被监测的服务间的交互消息，检查消息载荷，然后采用协议规则库中规则对应的状态集合进行规则匹配，判断组合服务运行环境11中各个服务是否出现故障。如果出现组合服务发生失效，则根据协议规则库中的协议规约和协议的组合过程，可以确定组合服务的消息交互序列，然后建立故障树；通过基于历史统计信息形成的组合服务中的构件服务和协议的失效的概率，可以计算不同服务可能引发故障的概率大小，然后按概率顺序监测找到引发失效的构件服务，优化管理器16对引发失效的构件服务进行处理和恢复。
图2为本发明基于协议的服务组合系统实施例中服务监测系统的结构示意图，如图2所示，服务监测系统可以包括全局监测器21、至少一个中间层监测器22和至少一个本地监测器23；相关的中间层监测器22之间建立有邻居关系；
其中，全局监测器21，用于存储各个所述中间层监测器22的信息；
中间层监测器22，用于保存同一类别的各个本地监测器23的信息；
本地监测器23，用于监测归属于本地监测器23的各个服务，将监测结果反馈给优化管理器和服务信息管理器。
在基于协议的服务组合系统的组合服务运行环境下运营大量组合服务时，如果采用单独的监控器，在负载增加时，可能出现延迟增大，影响性能等问题。因此，本发明中的服务监测系统可以为分布式多层监测器的结构如图2所示，服务监测系统可以分为三层：顶层为全局监测层，实现为一个全局监测器，全局监测器21不接受普通业务服务质量属性和交互关系的监测，用于存储各个中间层监测器22的信息例如：记录各中间层监测器22的名称、类别、入口点等信息，以减轻全局监测服务的负担。中间监测层中的中间层监测器22按照全球行业分类标准(Global Industry ClassificationStandard；简称：GICS)分类建立，一个中间层监测器22监测一类或几类行业的服务20，如图2中，中间层监测器221同时监测运输类服务和消费类服务。每个中间层监测器都可以作为特殊的Web服务注册于全局监测器21，以方便管理；同时相关的中间层监测器按GICS分类建立邻居关系，如图2中，中间层监测器221和中间层监测器222都监测运输类服务，可以构成邻居关系。各个服务的监测信息交互可以在中间层监测器完成，不需全局监测器参与，可减少全局监测的负担，减少全局监测器失效带来的影响。底层为本地监测层，一个服务注册于本地监测器23对应的服务信息管理器后，归属该本地监测器23，服务信息管理器负责管理、维护注册于本地监测器23上各个服务的服务信息，本地监测器23则根据注册信息监测服务属性和挖掘各个服务间依赖关系的变化，并将监测结果反馈给优化管理器和服务信息管理器，对失效的服务进行优化调整。在图2中，实线箭头表示消息交互关系，如中间层监测器与全局监测器交换信息，而底层的本地监测器监测发布于特定注册库上的服务；中间层和底层虚线表示监测器间邻居关系。
图3为本发明基于协议的服务组合系统实施例中监测器的结构示意图，如图3所示，本发明中的所有监测器例如：全局监测器、中间层监测器或本地监测器的结构可以包括：服务监测装置31和规则解析管理装置32；其中，服务监测装置31包括消息探测模块311、状态维护模块312和规则匹配引擎313；规则解析管理装置32包括规则管理模块321和规则解析模块322；
其中，消息探测模块311，用于监测归属的各个服务间的消息交互，将接收到的消息发送给所述状态维护模块312；
状态维护模块312，用于从规则匹配引擎313获取所述消息对应的服务在当前状态下的规则对应的期望事件；根据消息与事件的映射关系，获取所述服务在当前状态下的触发事件，若所述触发事件与所述期望事件相符，则对所述服务执行所述触发事件，并对所述服务的当前状态进行状态转换；
规则匹配引擎313，用于从规则解析模块322中获取所述服务在当前状态下的规则对应的期望事件，将所述服务在当前状态下的规则对应的期望事件发送给所述状态维护模块；
规则解析模块322，用于通过规则管理模块321从系统的协议规则库中解析得到消息对应的服务在当前状态下的规则对应的期望事件，并将所述服务在当前状态下的规则对应的期望事件发送给规则匹配引擎313。
进一步地，规则解析模块322可以包括：存储器41、模式匹配单元42和推理引擎43；
其中，模式匹配单元42，用于根据状态模式匹配得到所述服务在当前状态下的规则，将所述服务在当前状态下的规则发送至存储器41保存；
存储器41，用于保存所述服务在当前状态下的规则；
推理引擎43，用于确定所述服务在当前状态下需要被激活的规则，所述需要被激活的规则包括所述服务的当前状态、触发事件和相应的状态变量。
再进一步地，规则管理模块可以包括：用户接口44、规则管理单元45和监测相关单元46；
其中，用户接口44，用于将接收的用户指令发送给规则管理单元45；
规则管理单元45，用于根据所述用户指令对所述协议规则库中的各个与所述服务组合监测设备相关的规则进行创建、修改、分类、删除和查询展示；
监测相关单元46，用于获取所述协议规则库中与所述服务组合监测设备相关的规则。
具体地，每个监测器主要包括消息探测模块311、状态维护模块312和规则匹配引擎313，还可以包括协议规则库314，其中协议规则库314也可以存储在监测器的外部。监测器中的消息探测模块311探测通信信道和服务提供节点，收集服务间的交互消息，可以支持主动和被动两种模式。在主动模式下，服务主动发送消息摘要或状态变化信息给监测器的消息探测模块311；被动模式下，消息探测模块311探测交换的数据包或探测信息，目前很多交换机支持数据拷贝的转发。消息探测模块311接到消息后，将消息转发到状态维护模块312。状态维护模块312在配置时预先装载了一系列的事件定义(如：消息与事件的映射关系)。由于规则匹配引擎313和状态维护模块312连接，运行时，状态维护模块312从消息探测模块311获得消息，映射到一个触发事件上，并将该消息对应的服务的当前状态发送给规则匹配引擎313。规则匹配引擎313根据服务当前状态和输入事件可以确定匹配的协议规则库，根据服务当前状态通过规则解析管理装置32从状态转换表中获取当前状态对应的期望事件，其中，服务的状态集合和被监测的服务的状态转换表保存在协议数据库例如：一个哈希表中，规则匹配引擎313以状态名为索引在哈希表中进行匹配，查找到当前状态下的期望事件并发送给状态维护模块312。状态维护模块312判断触发状态与期望事件是否符合，即是否发生了期望事件，如果是则从规则匹配引擎313中获取期望时间对应的状态转换的信息即下一状态，根据期望事件对应的状态转换的信息触发适当的状态转换。
规则解析管理装置32规则解析管理的实现主要包括规则管理模块321和规则解析模块322规则管理器和规则解析器两部分，主要涉及服务监测规则、服务冗余管理及服务组合优化管理等规则。规则管理模块321可以规则管理器提供图形化用户接口，支持规则的创建、修改、分类、删除和查询展示等管理功能。规则管理模块321规则管理器负责决定一个规则是否和某个监测器匹配，主要包括用户接口44、规则管理单元45和监测相关单元46。规则管理模块321还可以规则管理器将协议规则库分为三类：监测器无关的规则；和与单个监测器相关的本地规则，不需被其它的监控器看到；与和监控器以及上层监测器相关的全局规则。规则解析模块322主要包括存储器41、模式匹配单元42和推理引擎43，其中存储器41保存规则匹配引擎313操作所需要的数据例如：服务在当前状态下的规则，模式匹配单元42确定此次规则匹配使用协议规则库中的哪些规则，以及当前状态下需要传送给存储器的规则，推理引擎43则可以用于确定当前状态需要被激活的规则。每个规则可以通过当前状态、引入输入事件和相应的状态变量来描述。规则可以目前是由管理者手工创建的，也可以由设备自动生成，在服务组合构造阶段导入协议规则库。协议规则库中包含的规则用RuleML表示。RuleML是一种与开发者无关的、基于可扩展标记语言(Extensible Markup Language；简称：XML)的规则标记语言。例如：用RuleML表示的一个规则包含若干个原子部分，其结论部分以标签表示，前提部分用标签表示。在系统实现中，根据RuleML语言，用指向具体的成员服务的操作，用、等表示不同常量和变量。
组合服务运行中一方面通过服务状态和质量监测，防止组合服务失效，可以实时监测正在运行的服务的运行状况，定期检测备用服务的状态。根据实际需求，选择各种策略，例如选择检测时间间隔、确定如何恢复服务的失效等。确定引发失效的构件服务后，开发工具中的服务组合构造工具更新影响BPEL文档或重新构造流程。此外，服务信息管理器收集、综合这些服务反馈信息后，根据要求如：发布/订阅机制，通知监测器的相关部件实施相应的动作。关于备用服务的状态，对于业务功能重要的关键服务，可设置较高的检测频率；而对于不重要或不愿多支付费用的服务，可设置较低的检测频率。
本实施例采用服务监测系统监测组合服务运行环境中的服务，将监测结果反馈给优化管理器，优化管理器根据设置的优化管理策略，对监测结果进行优化调整，通过基于协议及其组合机制的在线故障诊断机制，当故障出现时，根据协议规约和规则对交互行为进行监测，计算判定可能引发故障的操作和服务，通过组合服务的在线诊断和动态恢复提高组合服务的可信性，可以提高基于协议的服务组合系统的可信性水平，降低不可信情况的发生。
图4为本发明基于协议的服务组合方法实施例的流程图，如图4所示，该基于协议的服务组合方法包括：
步骤401、监测器监测组合服务运行环境中的服务，将监测结果反馈给优化管理器；
在基于协议的服务组合系统中，服务例如：构件服务、组合服务可以被看作黑盒，不能访问服务的源码，了解服务的内部结构或私有策略，但是协议规约对监控器来说是可用的，各业务域内设计类似PIPs的协议，存储在协议规则库中。根据协议规则库中公布的协议及服务声明支持的协议，监测器访问被监测的服务间的交互消息，检查消息载荷，然后采用状态集合来进行规则匹配，保存状态相关消息。
基于协议的服务组合系统主要包括组合服务运行环境、服务总线、服务信息管理器、服务监测系统和优化管理器等。其中，监测器包括：服务监测装置和规则解析管理装置；所述服务监测装置包括消息探测模块、状态维护模块和规则匹配引擎。所述规则解析模块包括：存储器、模式匹配单元和推理引擎；所述规则管理模块包括：用户接口、规则管理单元和监测相关单元。
进一步地，步骤401具体可以包括：
步骤4011、消息探测模块监测归属于所述监测器的各个服务间的消息交互，将接收到的消息发送给所述状态维护模块；
步骤4012、状态维护模块从所述规则匹配引擎获取所述消息对应的服务在当前状态下的规则对应的期望事件；根据消息与事件的映射关系，获取所述服务在当前状态下的触发事件，若所述触发事件与所述期望事件相符，则对所述服务执行所述触发事件，并对所述服务的当前状态进行状态转换；
步骤4013、规则匹配引擎从所述规则解析模块中获取所述服务在当前状态下的规则对应的期望事件，将所述服务在当前状态下的规则对应的期望事件发送给所述状态维护模块；
步骤4014、规则解析模块通过所述规则管理模块从系统的协议规则库中解析得到消息对应的服务在当前状态下的规则对应的期望事件，并将所述服务在当前状态下的规则对应的期望事件发送给所述规则匹配引擎。
其中，步骤4014具体可以包括以下步骤：
模式匹配单元根据状态模式匹配得到所述服务在当前状态下的规则，将所述服务在当前状态下的规则发送至所述存储器保存；
推理引擎确定所述服务在当前状态下需要被激活的规则，所述需要被激活的规则包括所述服务的当前状态、触发事件和相应的状态变量。
此外，该基于协议的服务组合方法还可以包括以下步骤：
所述用户接口将接收的用户指令发送给所述规则管理单元；
所述规则管理单元根据所述用户指令对所述协议规则库中的与所述服务组合监测设备相关的各个规则进行创建、修改、分类、删除和查询展示；
所述监测相关单元获取所述协议规则库中与所述服务组合监测设备相关的规则。
步骤402、优化管理器根据设置的优化管理策略，对所述监测器的监测结果进行优化调整。
监测器是基于一系列规则实现的，每个监测器主要可以包括消息探测模块、状态维护模块和规则匹配引擎，还可以包括协议规则库，其中协议规则库也可以存储在监测器的外部；消息探测模块负责监测服务间的消息交互，通过交换机或路由器的支持，探测服务间交互的消息。状态维护模块根据事先确定的事件和消息的映射关系，例如：事件描述了接收或发送特定的消息，则在接收到某些消息后触发相应的事件，根据规则匹配引擎解析的规则完成状态转换。协议规则库中可以存储状态转换表，状态转换表包括状态转换的规则，主要描述当前状态、触发事件和相应状态变量，规则可以由监测管理者手工创建或由设备自动生成，在服务组合构造阶段导入协议规则库。
在监测器的监测过程中可能发现某个服务失效，则失效的服务为故障服务，监测器需要对引发故障服务的原因进行诊断，具体方法包括：
若所述监测结果包括故障服务，则根据状态转换表监测与所述故障服务有交互的构件服务；
根据所述故障服务生成故障树，所述故障树的根节点为所述故障服务；
根据所述故障树，采用诊断算法判断与所述故障服务有交互的构件服务中引发所述故障服务失效的概率；
按照与所述故障服务有交互的构件服务失效的概率从大到小的顺序，从与所述故障服务有交互的构件服务中选取可用服务分别进行替换。
图5为本发明基于协议的服务组合方法实施例中监测修复过程的示意图，如图5所示，当监测器监测到某个服务失效后，监测器51根据协议规则库57中的状态转换表检查哪些构件服务和该失效的故障服务有过交互，然后触发诊断算法判断所有与故障服务有交互的构件服务引发故障服务失效的概率，具体包括：以故障服务为根节点的生成故障诊断树52，采用故障树生成算法构造故障诊断树；根据生成故障诊断树计算失效概率53，即计算可能引发失效的与故障服务有交互的所有构件服务的概率；然后，处理计算结果54，按照计算结果中与故障服务有交互的构件服务的概率从大到小的顺序，选择与故障服务有交互的构件服务中可用服务分别进行替换，更新组合服务55。同时，对可能出错的与故障服务有交互的构件服务进行在线或离线测试，监测出引发失效的与故障服务有交互的构件服务后，记入监测结果数据库，并相应调整服务质量属性信息，进行错误记录和更新，并发送至服务信息管理器50进行保存。
在基于协议的服务组合方法中，故障诊断算法的输入信息可以包括初始构造的组合服务、数据依赖、协议规约、服务监测策略；输出信息可以包括更新后的组合服务、更新后的数据依赖和协议依赖。具体的故障诊断算法如：Protocol Based Service Failure Diagnosis Algorithm的代码可以为如下的示例：
Input：initial composite service，data dependencies，protocolspecification，service monitoring policies.
Output：updated composite service，dependencies
L1.Initial()；//Initialization；
L2.cs←cs0；//choose composite service to be monitored；
L3.for all(si，oj)
L4.Dd(si，oj，datak)←(sm，on，datak)；
L5.Dp(si，oj，messagek)←(sm，on，messagek)；
L6.end for  //set the data and protocol dependencies；
L7.Read MSi，FRi ()；
L8.Monitor and Calculate Pk(si，oj)and Pk(si，pj，sk)；
L9.Repeat
L10.While failures monitored；
L11.Query IOP&IOS，some log on for new；//Query failure historyand probability of protocols and services；
L12.Generate the failure diagnosis tree with the failure servicebeing the root；
L13.Calculate the Probability of correlative operation base ondata and protocol dependencies；
L14.Sort the operations by the probability of failure；
L15.for all corresponding(si，oj)，do
L16.Test the message and operations；
L17.Search new services replace the service cause failure；
L18.Select(cs，fc，pc，qc)；//following function，protocol andQoS constraint，select candidate services through HAF[3，8]or otherservice selecting algorithm；
L19.Handle the operation of failure service；
L20.Construct new business process cs’；
L21.cs←cs’；
L22.Execute cs；
L23.until cs is terminated
上述故障诊断算法的代码的含义如下：首先，初始化，获取服务之间的数据和消息交互依赖关系(L1-L6行)，根据监测和诊断策略，监测、计算不同构件服务和协议的失效概率(L7-L8行)；如果发现构件服务失效，查询故障服务相关的协议和服务失效的历史和概率(L11行)；根据交互协议规约检查之前和其交互的服务，构建以故障服务为根的故障诊断树，给故障服务直接发送消息，将故障服务作为故障诊断树的深度为“1”的节点，深度依次累加(L13行)；按照故障诊断树，计算从最低层服务到根节点的故障服务的路径的可靠度，按可靠度从低到高对各路径排序，诊断测试可靠度最低的路径，切换故障服务更新流程(L14-L19行)；重新在线构造新的组合服务，更新组合服务后重新执行(L20-L23行)。
本实施例采用监测器监测组合服务运行环境中的服务，将监测结果反馈给优化管理器，优化管理器根据设置的优化管理策略，对监测结果进行优化调整，通过基于协议及其组合机制的在线故障诊断机制，当故障出现时，根据协议规约和规则对交互行为进行监测，计算判定可能引发故障的操作和服务，通过组合服务的在线诊断和动态恢复提高组合服务的可信性，可以提高基于协议的服务组合系统的可信性水平，降低不可信情况的发生。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。