您好,欢迎访问三七文档
当前位置:首页 > 行业资料 > 其它行业文档 > 基于WebService的专家系统集成研究
基于WebService的专家系统集成研究摘要:如何将分散的、异构的多个专家系统集成起来,为用户提供一个通用的平台是专家系统发展的必然趋势。本文提出了一个基于WebService的专家系统集成方案,有效的解决了多个专家系统的知识共享和协同工作等问题。文中主要介绍了基于WebService的专家系统集成方案的整体构架、应用模型以及实施步骤等。关键词:WebService;SOAP;UDDI;专家系统1引言随着计算机应用技术的普遍推广,不同的部门、单位在不同的时期先后建立了各种各样的专家系统,如机械故障诊断系统,农业专家系统以及医疗专家系统等。由于这些专家系统大多数是建立在不同的操作系统、不同的数据库平台之上,并且采用不同的技术实现。从而导致它们只能独立发挥作用,难于实现知识共享以及协同工作,用户也不易找到其需要的服务。如何将这些分散的、异构的专家系统集成起来,为用户提供一个通用的平台成为专家系统发展的必然趋势。近年来不断发展的WebService技术的主要目标就是在现有的各种异构系统的基础上构建一个通用的与平台、语言无关的中间层,各异构系统依靠这个中间层来实现彼此的连接与集成。为此,本文提出了一个基于WebService的专家系统集成方案,旨在解决目前各专家系统独立发挥作用的现状,给用户提供一个通用的专家系统访问平台。采用WebService技术实现应用系统集成与采用其他分布式计算技术(如RMI、DCOM和CORBA)相比,由于Web服务建立在已有的标准Web协议基础上,并利用现有成熟Web实施方案、支撑Web的网络与安全设备等,使得WebService技术具有普适性和简单性等优势。另外,通过基于XML的SOAP协议实现互操作,Web服务避免了不同协议之间的转换。2关键技术简介2.1WebService技术规范WebService的主要目标是提供一个通用的与平台、语言无关的中间层来实现各种异构系统的相互操作和集成。WebService的体系结构如图1所示,主要有3种角色:服务提供者、服务请求者和服务注册代理。服务提供者就是服务的所有者,是部署了Web服务的应用系统,它为用户或其他应用系统提供服务;服务请求者就是服务的使用者;服务注册代理是提供服务注册、查找以及绑定的中介。服务提供者通过服务注册代理发布其所提供的服务。服务注册代理接收服务请求,并查找服务请求者所需的服务,找到以后将其与服务提供者绑定,之后服务请求者便可以调用远程服务。WebService有四个标准协议:XML、SOAP、WSDL和UDDI。⑴可扩展标注语言(XML)。XML是WebService的基础,在WebService的体系结构中扮演了通信基础的角色,作为WebService数据描述和交换的标准。⑵简单对象访问协议(SOAP)。SOAP是WebService通信的标准协议。简单的说就是一个基于XML的、主要通过HTTP协议来支持RPC和信息传递的简单协议。⑶Web服务描述语言(WSDL)。WSDL是基于XML的WebService定义语言,作为连接WebService的接口。WSDL除了描述提供的接口外,还描述了服务的位置,能调用的服务操作以及这些操作的参数和返回值等。⑷通用描述、发现与集成(UDDI)。UDDI协议为WebService提供一种基于XML的服务注册与定位的机制,它通过注册表来维护Web服务,并定义了一套发布和查找服务描述的标准方法。在UDDI注册中心主要有以下4种数据类型成员:businessEntity,描述了服务提供者的信息;businessService和bingdingTemplate,定义了服务的具体实现;tModel,定义了服务的抽象接口。2.2专家系统简介目前,专家系统在各个领域中已经得到广泛应用,并先后构建了许多的应用系统。如农业领域有小麦专家系统、蔬菜专家以及柑桔专家系统等,医疗领域中有肺病诊断、风湿疾病诊断和内科疾病诊断等系统。专家系统是一种智能的计算机程序,它运用知识和推理来解决只有专家才能解决的复杂问题,它结合人工智能技术和具体的领域知识去解决各种实际问题。专家系统的体系结构如图2所示,由知识库、推理机、解释器、综合数据库、知识获取等5个主要部分构成。知识获取是通过专家或知识工程师收集知识,并按某种表示方式存储在知识库中的过程,也可以是自动学习的过程。知识库用来存放专家提供的知识。推理机根据用户提供的信息以及知识库中的知识进行推理,并得出相应的结论。结论需要通过解释器反馈给用户。综合数据库存放用户提供的事实以及推理过程产生的中间数据。3系统方案设计本文旨在提出一个基于WebService技术规范的多专家系统集成解决方案,为现有的以及后续开发的专家系统,设计一个通用的专家系统平台。由该平台定义一套标准的服务接口,并设计一个基于Web的应用集成系统,各专家系统只需实现特定的服务接口,通过部署和注册后即可为其他应用和用户提供服务。用户可以调用该平台的服务接口进行二次开发,也可以直接访问该平台的应用系统。3.1设计思路方案的设计有两个核心步骤:一是在各已有的专家系统上构建一个WebService层,将自身所能提供的服务进行封装,同时部署一个SOAP服务器,以便接收和处理外部SOAP请求,最后把服务发布到UDDI注册中心,以便注册中心查找和绑定服务。二是在服务端和客户端构建一个中间层,在该层设计一个注册中心和一个Web应用服务器。注册中心主要提供服务注册、服务分类、服务查找和服务绑定等功能,Web应用服务器则调用注册中心提供的服务分类、查找和绑定等接口为用户实现一个可视化的多专家系统服务平台。3.2系统体系结构本方案采用分布式计算模式,图3给出了基于WebService的专家系统集成的整体构架,由三个主要部分构成:WebService层、UDDI注册中心和Web应用服务器。①WebService层,它尽可能地利用现有的软件投资和保持原有专家系统的运行,在原有专家系统的基础上构造统一的应用服务层,由WebService层提供专家决策服务。该层主要由服务组件和SOAP服务器组成。服务组件就是编程语言(如java等)实现了WSDL接口的一组程序,SOAP服务器可以接收SOAP请求,并对其做出响应。当SOAP服务器收到SOAP请求时,它将在部署服务的列表中查找SOAP请求所需的服务。若没有查找到所请求的服务,它将请求失败返回给请求端。否则通过XML转换器将SOAP请求转换成本地的服务组件调用。当XML转换器调用了本地组件的方法后,它将方法返回的结果转换成SOAP响应消息。由服务器将消息发送到请求端。②UDDI注册中心,它提供一套注册、分类、查找和绑定服务的标准接口,以便服务端发布其Web服务以及Web应用系统对所有注册的服务进行分类、查找和调用的实现。UDDI就像一个服务仓库,存储了大量分布的服务端信息及其提供的服务信息。businessEntity存储所有服务端的信息,tModel存储所有服务接口信息,由WSDL服务接口描述中的信息生成,businessService和bingdingTem2plate存储服务实现,由WSDL服务实现生成。一个服务端可以实现多个服务接口,一个服务接口可以有多个服务实现。③Web应用服务器,它是整个构架的核心部分,是连接客户端与服务端的桥梁。Web应用服务器为用户提供了一个方便的服务使用平台:一方面,它调用UDDI的分类接口对所有注册的服务按某个标准进行分类。这样,用户根据分类就可以很快的找到需要的服务。另一方面,根据用户给出的关键字,调用UDDI的查找接口,也可找出一组相关的服务供用户选择。当用户选定某一服务时,与该服务的服务端交互是由集成系统来完成。用户只需给出事实或相关信息,由集成系统封装成SOAP消息请求远程服务端,并将接收到的结果反馈给用户。3.3系统应用模型图4显示了使用基于WebService的专家系统集成架构的应用模型。在模型中,用户访问应用服务器,根据分类或给出关键字找到需要的服务,然后由内部应用程序使用UDDI注册中心来获得该服务的技术信息,并且在Intranet上调用该服务。在这个例子里面,Web服务把柑桔专家系统、小麦专家系统和医疗专家系统松散地集成在一起。假设柑桔专家系统提供柑桔病虫害诊断和柑桔品种选择服务,医疗专家系统提供肺病诊断服务,小麦专家系统提供小麦病虫害诊断服务。模型应用流程步骤如下:⑴用户登录应用服务器,进入专家系统的服务分类列表界面。用户可以在分类列表中选定某一服务,也可以给出关键字进行检索相关的服务。如果直接在列表中选定服务,跳到第3步。这里通过给出关键字“病虫害诊断”来检索相关的服务;⑵应用服务器查询UDDI注册中心,获得一组与关键字相关的服务,供用户选择。通过查询发现与“病虫害诊断”相关的服务有“柑桔病虫害诊断”和“小麦病虫害诊断”,这里选定“柑桔病虫害诊断”服务;⑶针对用户选择的服务,应用服务器访问UDDI注册中心查找该Web服务的WSDL绑定信息,包括提供该服务的服务端位置、端口、参数和返回值等。例如可以知道提供“柑桔病虫害诊断”服务的是柑桔专家系统;⑷应用服务器根据WSDL绑定信息生成基于XML的SOAP消息,然后将它发送到服务端请求和绑定服务,之后便可以调用远程服务。在调用远程服务时可能会与用户交互。这整个通信过程都是基于SOAP交互的。例如在调用“柑桔病虫害诊断”服务时需要用户提供发病症状;⑸最后,应用服务器将服务得到的结果反馈给用户。这里“柑桔病虫害诊断”服务根据用户提供的发病症状和柑桔专家系统的本地知识库进行决策,并得出相应的结论和防治方案。该结论和防治方案由应用服务器通过Web界面返回给用户。4系统方案实施方案的实施分为服务端的实施和中间层的实施两个部分。中间层的实施流程如下:①建立UDDIR注册中心,并设计一套统一的服务接口;②建立Web应用服务器,主要是设计与UDDI和服务端交互的Web服务组件以及与用户交互的可视化Web界面(或API接口)。服务端的实施流程:①对于已有的专家系统,只需封装原有系统的功能以实现UDDI提供的服务接口。对于新系统开发,要基于WebServices进行组件化应用系统开发,以实现UDDI提供的服务接口;②将各专家系统实现的Web服务部署到SOAP服务器中,以WebService的形式发布,使其它系统可以通过SOAP进行调用;③将各专家系统部署的服务进行描述,生成服务的描述文档WSDL,并将它们注册到UDDI,以便其它应用系统能够发现和访问这些服务。5系统方案评价本文提出的集成方案可以已有分布的、独立的专家系统和新开发的专家系统组成一个有机的整体,构建一个功能强大、通用的专家系统平台。该平台达到使原有系统增值的目的,而又无需对原有系统做大的改动。通过服务的定义、发布、查询、绑定、调用等机制,实现了一种松散耦合、互操作性好的应用集成框架。方案的优点体现在以下几个方面:⑴知识共享。通过本系统可以访问不同专家系统所具有的领域知识;⑵求解多样性。由于不同的专家系统均具有自身的知识表示和求解方法,因此,对问题的求解方法具有多样性;⑶可靠性高。对同一问题的求解,通过将不同系统得出的结果进行比较,可以提高结论的可靠性;⑷可扩展性好。如果要增加新的Web服务,只需在服务端实现服务接口,并将服务进行部署、注册即可;⑸适用性强,为用户提供一个统一的、方便的和透明的访问平台。用户只需选定服务、提出问题,而无须知道是谁为其提供服务以及是如何实现的。6结论WebService作为一种分布式应用集成技术,正越来越受到专业人员的关注,将WebService技术与专家系统结合具有一定的应用前景。本文提出的基于WebService的专家系统集成方案,能够较好的解决知识共享以及各专家系统协同工作难等问题,同时也为用户提供一个通用的专家平台。本文也只是对分布式专家系统应用集成进行了探索性的研究,还有许多问题有待于解决,如高效的服务管理、安全性以及服务收费等问题。参考文献:[1]李文军,李师贤,等.分布式对象技术[M].北京:机械工
本文标题:基于WebService的专家系统集成研究
链接地址:https://www.777doc.com/doc-2572814 .html