基于面向服务中间件的集成化CAPP系统研究

计算机集成制造系统

ComputerIntegratedManufacturingSystems

Vol.15No.5May2009

文章编号:1006-5911(2009)05-0973-09

基于面向服务中间件的集成化CAPP系统研究

徐照旻,蔡　铭,董金祥

(浙江大学计算机学院,浙江　杭州　310027)

摘　要:如何集成单元系统实现信息和功能共享是当前亟待解决的问题。为此,提出了基于面向服务中间件的集成化计算机辅助工艺设计系统,将分布在各类网络中的中间件实例作为异构系统的连接器,支持多种服务发现和调用协议。针对异构网络或系统,采用特定的服务发现和调用协议,从而克服异构系统交互协议的异构性问题,实现多种行业领域计算机辅助工艺设计系统之间,以及计算机辅助工艺设计系统与计算机辅助设计、计算机辅助制造、企业资源计划等异构单元系统的信息与功能集成。

关键词:集成;面向服务中间件;计算机辅助工艺设计;服务发现;服务调用中图分类号:TP391　　　文献标识码:AIntegratedCAPPsystembasedonservice2orientedmiddleware

XUZhao2min,CAIMing,DONGJin2xiang

(CollegeofComputerScience,ZhejiangUniversity,Hangzhou310027,China)

Abstract:Howtointegrateunitsystemtorealizeinformationandfunctionsharewasurgentproblemwhichneededtoberesolvedatpresent.Todealwiththisproblem,service2orientedmiddlewareComputerAidedProcessPlanning(CAPP)systemwasproposedtoserveasheterogeneoussystemsconnectorformiddlewareinstancedistributedinheterogeneousnetworks.Itsupportedmultipleservicediscoveryprotocolsandmultipleserviceinvocationprotocols.Aimingatheterogeneousnetworksandsystems,specificservicediscoveryorinvocationprotocolswereappliedtoo2vercomeheterogeneityexistingamongheterogeneousinteractionprotocols.Itrealizedinformationandfunctioninte2grationforheterogeneousCAPPsystems,CAD,CAM,ERP,etc.

Keywords:integration;service2orientedmiddleware;computeraidedprocessplanning;servicediscovery;serviceinvocation

0　引言

随着企业信息化建设的不断深入,各种信息化单元系统在企业均得到很好的应用,如计算机辅助设计(ComputerAidedDesign,CAD)、计算机辅助制造(ComputerAidedManufacturing,CAM)、产品数据管理(ProductDataManagement,PDM)系统等,但各单元系统之间的信息得不到充分利用,甚

至很多信息需要重新输入,这是企业所不能接受的[1]。集成化是计算机辅助工艺设计(ComputerAidedProcessPlanning,CAPP)发展的必然趋势,

随着制造技术的不断发展,集成的含义不仅包含信息集成和功能集成,还包含多领域规划集成[2]。各主流单元系统采用的信息和功能管理方式不同,要实现支持航空、航天、汽车、船舶等多种行业领域的具有广泛集成能力的集成化CAPP系统,使各单元

收稿日期:2008205215;修订日期:2008209203。Received15May2008;accepted03Sep.2008.

基金项目:国家863计划资助项目(2007AA040502)。Foundationitem:ProjectsupportedbytheNationalHigh2Tech.R&DProgram,China

(No.2007AA040502).

作者简介:徐照旻(1981-),男,江西贵溪人,浙江大学计算机学院博士研究生,主要从事CAPP、软件中间件等的研究。

E2mail:saint_xzm@sohu.com。

974计算机集成制造系统第15卷

系统既能地为自身用户提供服务,又能在系统之间协作,实现系统信息和功能共享,就必须克服信息和功能管理方式的异构性问题,最大限度地重用各系统资源。

面向服务中间件(Service2OrientedMiddleware,SOM)将系统功能分解为较小的自治逻辑单元(即服

务),以屏蔽底层网络环境、计算体系结构、操作系统和编程抽象方式等异构性,从而统一分散在不同网络中的各种计算资源,让应用程序可以在不同平台和通信协议下无缝整合,极大地方便了异构系统的整合,以及应用程序的编写、管理和使用,具有良好的互操作性、可扩展性和可重用性[325]。

本文在面向服务中间件的基础上,构建集成化CAPP系统,通过中间件实例连接异构网络中的异

111　信息集成构单元系统,根据系统资源和主要功能构造中间件服务,并通过引入对多种服务发现和调用协议的支持,克服各系统信息和功能管理方式的异构性问题,从而实现多种行业领域CAPP系统之间,以及CAPP系统与CAD,CAM,PDM等异构单元系统的

集成化CAPP系统的信息集成通过SOM实现信息处理服务,将信息集成功能由各单元系统转移至中间件节点。信息处理服务发挥着类似PDM集成管理模块的作用,负责主动收集和处理各类信息,同时可灵活配置采用不同的信息处理、存储等技术。由信息处理服务抽象出来的具有统一表示格式的资源信息通过中间件节点存储在资源信息库中,以便在不同网络享。目前,为了便于扩展信息资源,笔者开发的集成化CAPP系统采用可扩展标记语

言(eXtensibleMarkupLanguage,XML)数据库保存各类信息。

112　面向服务中间件体系结构

信息与功能集成。1　集成化计算机辅助工艺设计系统结构

如图1所示为基于面向服务中间件的集成化CAPP系统结构示意图。集成化CAPP系统通过本

地SOM实例,协调异构网络内与各单元系统功能对应的服务,SOM节点(部署了中间件实例的网络计算设备)负责连接异构网络,帮助集成化CAPP系统完成服务发现和服务调用,管理协调各单元系统的信息和功能。

各CAPP系统单元与SOM实例结合,通过中间件实例提供的服务发现和调用接口,查找和使用所需服务,实现逻辑功能在分布式网络的扩展。图1中的CAPP系统实例1便可以通过中间件实例的资源管理服务与其他实例协作,共享分布在不同网络内的制造资源信息,并可通过资源管理服务与信息处理服务的协作,获取其他单元系统上的资源信息。CAPP系统单元可以在内部硬编码服务发现和调用逻辑,也可以将服务功能动态展现在系统界面上,充分利用面向服务技术的可扩展性。

集成化CAPP系统中的SOM体系结构如图2所示。其中,服务管理器处于核心地位,负责平台各组成部分的协调和配置;服务开发包的部署由服务部署框架负责,产生的服务对象存放在本地服务库中,本地服务描述的产生则由服务管理器负责,可根据服务发现和调用状况进行调整;服务发现框架负责根据中间件节点的网络状况和系统配置,选择合适的服务发现协议(ServiceDiscoveryProtocol,SDP),发布本地服务描述和接收远程服务描述,发

布的服务描述信息通过服务管理器从本地服务描述缓存中获取,接收到的来自其他节点的远程服务描述则存储在远程服务描述缓存中;服务调用框架则负责根据服务描述中记录的服务调用协议信息,选择相应的服务调用协议,调用远程服务并返回调用结果。

第5期徐照旻等:基于面向服务中间件的集成化CAPP系统研究975

11211　服务描述

述、版本信息或部署时间可以不必存在),是可选项。

以＄开始的内容(如有空格需包含在括号内)为保留的关键字,主要用来定义数据类型和有固定含义的语义词组,如＄(Strictname)是用于表示名称的字符串。图中后面三行是对策略选项的内容解释,用于定义信息中相关内容的数据类型(如＄long表示部署时间应为长整型数据)或应包含的内容(如sharing&cooperative表示服务功能描述中应同时

系统内部采用的通用服务描述作为一类特殊对象存在,用于描述中间件节点提供的各种服务,并通过对象序列化机制由服务发现框架在网络中发布和传播,以便在不同中间件节点之间共享服务信息,实现服务远程调用,方便用户使用所需服务。服务描述主要包括服务端点信息(如访问地址、监听端口等)、服务属性描述(如类型、版本、功能描述、约束条件等)和服务操作描述三部分。服务属性描述采用三元组(属性名,功能描述,属性值),服务操作描述则采用四元组(操作名,功能描述,参数描述,返回结果描述),其中参数描述为三元组(参数名,功能描述,类型)。11212　服务匹配包含词语sharing和cooperative)。

通过语义处理策略可以方便地定义语义描述信息的处理方式,增强了系统的智能化程度、动态可配

置性和兼容性,如图3中的策略,便能够支持客户请求或调用分布在不同中间件节点上的、具有不同版本或在不同时间部署的相同类型服务。出于效率考虑,目前只支持定义比较简单的语义处理规则,如果系统只应用于资源丰富的环境,可以引入语义网或其他本体论技术来定义语义处理策略。

在系统中,服务使用者请求或调用远程服务时,提供的服务和操作描述(与平台内采用的通用服务描述为不同概念)可以是简单的服务和操作名称,也可以是含有语义信息的简单语义描述,客户端中间件实例将分两步,对这些描述信息进行如下匹配处理(类似文献[6]中提到的精确匹配和包含匹配):

(1)把描述信息作为服务或服务操作的标识或名称,直接进行服务操作查找,如果命中,则将服务调用信息传递给服务提供者,调用远程服务操作,否则进行第二步处理。

(2)按照设定的语义匹配策略对描述信息进行简单语义处理,根据处理后得到的信息查找相关服务及操作。

服务及其操作的语义匹配策略定义在策略文件中,可以动态修改,以更新处理策略。图3列出了一个可根据功能、版本或部署时间等服务属性查找服务的语义匹配策略实例,该策略要求服务操作描述信息必须与匹配服务的某一操作名称一致,才能调用该服务操作。语义匹配策略由多个策略选项构成,每个策略选项对应于一个服务属性,小括号中的声明内容说明的是语义描述必须包含的信息(图中示例说明语义描述必须包含服务名),中括号则表示其中声明的内容可以不存在(图中示例说明功能描

2　多服务发现协议支持框架

服务发现是指发现环境中已经存在的设备和服务,并使其能够相互发现、配置和通信[7]。服务发现可以减少集成化CAPP系统相关设备与服务的控制开销,提高其功能可用性和自动化程度,同时还能够减轻系统设计者的工作量,让他们不必努力地尝试预见和编写设备与程序间所有可能的交互方式与状态。服务发现功能通过SDP实现。

目前,主流的SDP(如JINI,UPnP,SSDP等)针对特定网络(有线或无线局域网),彼此之间无法进行交互协作,不利于利用知识共享提高系统资源的利用率。用于发现SDP的高层发现机制是不可行的,该机制自身充满着不确定性[8],多SDP支持可能是实现不同系统间的互操作,以及在异构网络环境中实现高效服务发现的唯一手段[8210]。

通过修改所有客户端与服务端软件来支持多种SDP并不现实,目前协议间的互操作性通常通过加入互操作层进行转换,具体有两种方式:①在透明转换方式中,互操作层位于网络层上,负责在不同协议

976计算机集成制造系统第15卷

间对消息格式进行转换,转换过程对客户端或服务端透明;②在显式转换方式中,互操作层位于协议层之上,为客户端提供统一的服务发现接口,方便对已有的SDP进行扩展[9]。笔者提出的集成化CAPP系统采用后一种方式,通过在中间件的服务发现框架中引入与各SDP对应的执行器,实现服务描述信息在通用格式和协议特定格式间的转换,从而支持多种SDP,以共享异构网络中单元系统的信息和功能,实现异构系统的集成。211　服务发现协议执行器

点不需支持多种SDP,应当允许用户根据自己需要

选择是否支持多种SDP,所以集成化CAPP系统中的部分中间件节点必须通过其他节点的帮助,实现异构网络内的服务发现,这些含有多个网络硬件接口、跨越多个网络为其他节点提供服务的过渡节点称为桥节点(bridgenodes)[12]。图4中,网络A和网络B部分重叠,由节点A连接的CAPP系统1如要访问部署于节点C,且由CAPP系统2提供的CAPP服务,就需要桥节点的帮助,由桥节点提供相关服务描述并实现服务调用传递。

当系统重新配置导致其采用的SDP发生改变时,完全抛弃现有服务信息、重新发现服务是不经济的;另一方面,异构网络环境(如有线和无线局域网)采用的SDP通常不同,要实现服务描述信息在异构网络间的共享,就必须实现不同SDP间服务描述格式的转换。而SDP采用的服务描述信息具有特定格式,由协议自身进行维护。要实现服务信息重用和共享,就必须实现服务描述信息在通用格式与协议特定格式间的转换。基于SOM的集成化CAPP系统内部采用通用的服务描述格式,SDP执行器作为通用格式与协议特定格式间的转换适配器(Adapter)[11]存在于中间件的服务发现框架之中,每个SDP都有一个对应的协议执行器。协议执行器可以由协议提供方提供,也可以由系统程序员编写,所有协议执行器均须符合标准的功能接口(如表1)才能在中间件内使用。

表1　服务发现协议执行器功能接口

接口

booleanisApplicable

(nType)

voidinit(ObjectType)

213　服务发现过程

服务发现过程包含服务发布与请求两部分,与服务相关的服务描述信息必须经由服务发现框架在网络中发布之后,才能为用户所使用。下面仍以图4为例,说明整个服务发现过程。

(1)服务发布过程

在多SDP支持情况下,服务发布过程与采用单个SDP相似,但是服务描述格式在发布过程中可能经历多次转换。假设图4中的CAPP系统2支持屏幕共享协同设计[13];除桥节点外,其他中间件节点均不支持多种SDP;服务开发人员在中间件节点C

中部署屏幕共享服务(包含客户端代码),以支持CAPP系统2接受来自其他系统的参与者。用NC

功能描述

兼容性检查,确认该协议是否能够应用于　某一类型的网络

初始化协议执行器,从传入的网络对象提　取网络接口信息

在一定网络范围内发布服务信息。服务　信息包括服务的标识、类型、属性等在一定网络范围内请求所有种类的服务　信息

在一定网络范围内请求特定种类服务的　信息

关闭协议执行器并释放相关资源

voidadvertise(List)

表示中间件节点C,BN表示桥节点,SDPB表示服务发现协议B,SDFB表示服务发现协议B采用的服

务描述格式(ServiceDescriptionFormat,SDF),GSDF表示集成化CAPP系统内部采用的通用服务

Listrequest()

Listrequest(Type)

voidclose()

描述格式,依次类推,并用三元组(节点,服务发现协议,服务描述格式)表示服务描述信息的发布状态,此时屏幕共享服务描述的发布过程表示如下:(NC,SDPB,GSDF)→(NC,SDPB,SDFB)→(BN,SDPB,SDFB)→(BN,SDPB,GSDF)→(BN,SDPA,SDFA)

212　桥节点

实际应用中,并非所有中间件节点都含有多个网络接口,不少所处网络环境单一或资源有限的节

第5期徐照旻等:基于面向服务中间件的集成化CAPP系统研究977

→(NA,SDPA,SDFA)→(NA,SDPA,GSDF)。

屏幕共享服务描述首先在节点C由通用格式转化为协议B特定格式,然后在桥节点由协议B特定格式转化为通用格式,再由通用格式转化为协议A特定格式,最后节点A将其由协议A特定格式转化为通用格式,之后CAPP系统1才能访问该服务,服务描述转化由SDP执行器实现。而如果中间件节点A能够访问网络B且支持服务发现协议B,则只需经历两次服务描述格式转换,过程为:(NC,SDPB,GSDF)→(NC,SDPB,SDFB)→(NA,SDPB,SDFB)→(NA,SDPB,GSDF)。

支持多种SDP的节点(如图中的桥节点)发布服务时,可以选择是通过所有SDP发布该服务描述,还是选择其中的一个或一些。笔者提出的集成化CAPP系统采用前一种方法,依次通过每个SDP发布服务描述。

(2)服务请求过程

服务描述发布之后,其他系统便能通过附近的中间件节点访问该服务。如果中间件节点只支持单一服务发现协议,则请求过程相对简单。延续上面例子,假设CAPP系统1的开发人员加入对屏幕共享协同设计的支持,想通过系统访问节点C上部署的屏幕共享服务,此时CAPP系统1通过中间件节点A发出服务请求。如果节点A已经获得屏幕共享服务的通用描述,便可以根据服务描述中记录的信息,调用节点C上的服务操作(如客户端代码加载、协同设计信息获取等)。如果节点A尚未获得屏幕共享服务描述,便需通过服务发现协议A向其他节点请求该服务的描述信息,直至描述信息返回为止,其间可能引发多次服务请求。

若节点支持多种SDP,情况则有所不同。例如,若节点A能访问网络B,且支持服务发现协议B,则当CAPP系统1发出服务请求时,节点A可以选择或者同时通过两个SDP请求该服务(并行方式),或者依次采用服务发现协议A和B(循环尝试,只有当采用协议A无法获得服务描述时才采用协议B)。目前,笔者提出的集成化CAPP系统采用后一种循环尝试方式(并行方式会造成功耗和通信量激增[8]),如果当前协议无法满足服务请求,系统将随机选择另一SDP(通过切换SDP执行器实现)作为当前采用的SDP,重新尝试服务请求,直至请求得到满足或彻底失败(所有协议均无法满足用户请求)。

3　多服务调用协议支持框架

服务调用通常需要服务地址、服务契约、服务语义等信息,完整的服务调用框架还涉及到如何调用、调用哪个服务等一系列问题,与服务发现框架紧密相关[14]。服务调用协议(也称为服务交互协议[15])关注“如何调用”服务。不同网络的不同服务适合应用具有不同特点的服务调用协议,而异构的信息化系统内部通常采用异构的交互协议,交互方式取决于系统的编程抽象方式(如远程方法调用(RemoteMethodInvocation,RMI)、远程过程调用(RemotoProcedureCall,RPC)等)[16],使得基于SOM的异构系统集成平台必须支持不同种类的服务调用协议,以适应各系统交互协议的异构性。多服务调用协议支持也能够提升系统对遗留系统的兼容性,充分利用已有的单元系统资源。在现有研究中,文献[17]通过适配器代码的动态加载,实现不同方式的服务调用,从而实现对不同服务调用协议框架的支持;文献[18]则通过中间构件(intermediary)分离客户端与服务端,由中间构件选择同步或异步通信方式并返回服务调用结果。在笔者提出的集成化CAPP系统中,SOM的服务调用框架与服务发现框架相对,起着类似中间构件的作用,由服务调用框架根据服务描述选择服务调用协议,而每个服务调用协议都通过相应服务调用协议执行器实现,从而实现不同系统间的互操作和功能共享。系统服务由开发人员根据单元系统的信息和功能编写,大部分服务描述信息也由开发人员提供,包括服务使用的服务调用协议。311　服务调用框架结构

集成化CAPP系统要求服务调用者(CAPP系统实例或其他应用程序)运行有中间件实例,这样只要中间件实例捕获了其他节点在网络中发布的服务描述,服务调用者便可通过中间件平台提供的统一服务调用接口调用该服务。图5显示了系统中支持多服务调用协议的服务调用框架结构。目前,笔者开发的基于面向服务中间件的集成化CAPP系统(CAPPsystembasedonService2orientedMiddle2ware,SMCAPP)主要支持两类服务调用协议:①针对有线网络基于可靠连接;②针对无线网络基于不可靠的消息传递机制。

978计算机集成制造系统第15卷

具体实现由服务调用框架负责,服务调用协议执行器只需通过系统接口将结果传递给服务调用框架即可。

表2　服务调用协议执行器功能接口

接口

功能描述

初始化协议执行器,分配和记录相

voidinit()

关资源,如用于接收网络连接或消息的端口等

voidfillInAttributes

在指定服务对象中以属性形式记录协议相关信息,如连接监听端口等

根据提供的服务调用描述调用远

服务开发者在服务定义时声明服务采用的服务

调用协议,部署服务时SOM实例将初始化与服务调用协议对应的协议执行器,协议执行器为服务分配与服务调用相关的资源并记录在服务属性中(如采用基于可靠连接的服务调用协议时就需要分配和记录连接监听端口),服务管理器则在生成服务描述时记录服务调用协议及相关资源信息。服务调用者端的中间件实例在调用服务前,根据服务描述中记录的服务调用协议和资源信息,选择并初始化相关服务调用协议(如在基于可靠连接的服务调用协议开始前设定目标服务的连接监听端口),随后便可采用相同的服务调用协议与远程服务进行交互。

该多服务调用协议支持框架的同时支持新服务调用协议的加入。例如,如果服务开发者希望采用基于RMI的服务调用协议,可以按照服务调用框架要求实现通用的服务调用接口,在接口实现中,引入对目录服务的访问。另一方面,也可在框架内引入同类服务调用协议的不同版本,例如同样是基于可靠连接的服务调用协议,可以改变连接的建立方式,由服务调用者提供接收数据的端口参数,以便服务通过主动连接服务调用者来传递数据,这种调用方式可以减少服务端在等待服务连接上的开销。312　服务调用协议执行器

(Service)

voidinvokeRemoteService(InvocationDescription)

程服务操作,服务调用描述包括服务提供者节点信息(包括网络地址、访问端口等)、服务标识、操作名、参数、访问标识等将服务操作的调用结果返回给客voidreturnInvocationResult(NodeInfo,InvocationResult)

户端,协议本身不考虑结果返回方式。第一个参数记录客户端信息,第二个参数记录返回结果

313　服务调用接口

系统通过统一的服务调用接口支持动态服务调

用[14],服务开发时不需在客户端或服务端生成存根代码,能有效降低服务开发和使用的复杂性问题。服务调用者调用服务,需通过统一的服务调用接口提供服务描述、服务操作描述、参数描述、访问标识、结果返回方式等信息,这些信息与服务发现框架中使用的服务描述信息不同,通常只是简单的语义描述(如服务名、服务操作名等,或在名称之后附加一些诸如版本号之类的额外信息),具体格式由中间件节点的语义匹配策略决定(见112节)。SMCAPP中的服务调用接口如图6所示。

与多服务发现协议支持类似,集成化CAPP系统中的多服务调用协议支持采用Adapter模式,通过基于统一功能接口(如表2)的不同服务调用协议执行器实现。服务调用者通过统一的服务调用接口,将调用信息传递给面向服务中间件实例,中间件实例根据传入信息定位具体的服务描述,然后根据服务描述中记录的协议信息选择适当的服务调用协议执行器,将调用信息发送至服务提供者,并接收服务调用结果。中间件实例如何将结果返回给服务调用者,取决于服务调用接口中的结果返回方式参数,

服务调用者可在调用服务时指定访问标识(AccessIdentification,类似文献[19]中的Opera2tionID),服务提供端的中间件实例通过该访问标识创建或获取某一服务上下文,随后的服务调用只要指定同一访问标识,便能在同一个服务上下文中进

第5期徐照旻等:基于面向服务中间件的集成化CAPP系统研究979

行操作。如不指定访问标识,中间件实例将进行无状态服务调用,不会创建服务上下文。

服务调用接口的返回结果由结果返回方式参数决定,中间件实例将根据服务调用者指定的结果返回方式(同步或异步,默认为同步),提供服务调用结果。服务调用者如果选择同步方式,中间件实例将阻塞服务调用者的当前线程,直至服务调用结果返回为止。如果服务调用者选择异步方式,则有两种方式获得服务调用结果:①轮询,由服务调用者通过中间件系统提供的接口,主动向中间件实例查询结果;②通过中间件内部的事件机制,服务调用者在订阅“服务结果返回”事件后继续运行,收到服务返回结果时,中间件实例将通知服务调用者,后者通过中间件实例获取结果,并进行进一步处理。314　服务调用传递

4　实验及分析

411　实验环境

以下两小节的所有实验均在笔者采用Java语言编写的SMCAPP上进行,系统安装在不同配置的PC机或笔记本电脑上。其中,服务发现实验包含有线和无线两种网络环境,服务调用实验只包含无线网络环境,相关实验环境的信息如表3所示。实验中,网络流量监视程序的编写采用了基于Win2Pcap的Jpcap代码库,以捕获网络数据包。

表3　实验环境

典型硬件器材/软件环境

54M无线路由器54M无线网卡

硬件配置/软件版本

TP2LINKTL2WR340G+TP2LINKTL2WN321G+CPU700M,内存256MCPU214G,内存1GCPU双核1186G,内存2GWINDOWSXP,JRE116JDK116,Eclipse31212

JUnit4

GS2CAPP(大天工艺设计与管理系统)

服务器客户端笔记本系统运行环境开发工具测试工具

CAPP系统

在图4描述的由桥节点连接的两个部分重叠的网络中,节点A如需调用节点C提供的服务,就需要借助桥节点进行服务调用传递。节点A通过桥节点获得节点C提供的服务描述,桥节点可能修改服务描述中记录的服务调用协议,所以节点A调用节点C上的服务时,实际上是与桥节点交互,由桥节点作为中介调用节点C上的服务,并将调用结果返回节点A,节点A和桥节点之间采用的服务调用协议(记为SIPAB)与桥节点和节点C之间采用的服务调用协议(记为SIPBC)可能截然不同,整个发现和调用传递过

412　多服务发现协议支持

系统中多SDP支持效率的测试实验分多次进行,中间件节点(部分节点装有CAPP系统实例)由少至多,且一半节点位于有线局域网内(采用基于扁平目录服务的SDP[7]),另一半则位于无线局域网内(采用简单服务发现协议(SimpleServiceDiscov2eryProtocol,SSDP)[20]),不同网络间由桥节点连通。服务发现针对最坏情况,通过当前节点调用网络最远端某节点提供的、与集成化CAPP系统中的屏幕共享协同设计功能对应的屏幕共享服务,以保证服务发现跨越本地网络。服务发现作为SMCAPP额外引入的部分,相关开销在非面向服务

程如图7所示。服务调用传递可能跨越多个网络,借助不止一个桥节点,相对而言效率较低且可靠性较差,适合于调用数据传输量较小的服务。

的CAPP系统中并不存在。

网络数据流量的统计监视服务发现发起节点每秒接收到的网络数据包数量,然后取最大值,监视程序只运行于服务发现发起节点,监视单个网络物理设备。实验结果取多次服务发现请求的平均值,并与单一网络内采用单个SDP时的服务请求结果进行比较(中间件节点全部位于有线局域网时采用基于目录服务的SDP,全部位于无线局域网时采用SSDP),如表4和表5所示。

980计算机集成制造系统第15卷

表4　多服务发现协议情况下服务请求的平均响应时间

节点数

481216202428

413　基于简单语义描述的服务调用

平均响应时间/ms

基于目录服务

14124141331510114185151291515215194

SSDP32140137431561256211770177142

多SDP451424917917451139571666311771183

为了衡量多服务调用协议支持框架的执行效果,笔者在无线网络环境下测试了SMCAPP中基于简单语义描述的服务调用执行效率,并将实验结果与相同环境RMI(采用JavaRMI开发)、公共对象请求代理体系结构(CommonObjectRequestBrokerArchitecture,CORBA)(采用JavaIDL开发)和WebService(采用AXIS2开发)等架构下的服务调用实验结果进行比较。实验中SMCAPP采用基于消息传递机制的服务调用协议(MessagebasedServiceInvocationProtocol,MSIP)。

实验方法类似文献[21],在不同架构下分别实现工艺参数计算(涉及若干变量传输和结果返回,以计算为主)、切削参数选取(主要是参数、参数说明等构成的少量数据块)和屏幕共享服务(涉及屏幕图像信息、鼠标位置信息等大量数据,数据块在传输前进行压缩,传输后解压),发起服务调用到服务结果返回之间的时间间隔作为整个服务调用过程的开销,网络流量则计算服务调用时每秒产生的网络数据包(包括用户数据协议(UserDatagramProtocol,UDP)和传输控制协议(Trans2missionControlProtocol,TCP)两类)数量的最大值。实验结果取多次服务调用的平均值,如表6和表7所示。作为比较,将原CAPP系统(GS2CAPP)相关功能(含数据库访问)在相同实验环境下的执行开销一并列出。

表5　多服务发现协议情况下服务请求产生的网络流量

节点数

481216202428

网络流量/(包/s)

基于目录服务

31292726242523

SSDP595145434241

多SDP

63615945424342

实验结果正如预期所料,由于要相继执行多个SDP,而协议切换简洁快速,开销很小,在实验设定的请求网络最远端服务的最坏情况下,采用多协议时的平均响应时间取决于平均响应时间最长和网络流量最大的协议(SSDP)。实际应用中,服务发现跨越的网络数量有限,采用多服务调用协议不仅能够发现不同网络中的服务,还能够提升服务发现效率,不足的是可能会造成更大的网络流量。

表6　各服务架构下服务调用的执行开销

测试服务工艺参数计算服务

切削参数选取服务屏幕共享服务

GS2CAPP相关功能开销/ms

611381081636129

服务调用效率/ms

SMCAPP21197221283871161

RMI161351714930171

CORBA21181231514956163

WebService85136116712181132

表7　各服务架构下服务调用引起的平均网络流量

测试服务工艺参数计算服务

切削参数选取服务屏幕共享服务

GS2CAPP相关功能开销/(包/s)

11287794

平均网络流量/(包/s)

SMCAPP193103861

RMI1851091029

CORBA170881107

WebService

2613721112

从实验结果可以看出,SMCAPP采用MSIP时的服务调用效率与RMI差距较大,但比CORBA稍好,比WebService好许多;产生的网络流量则与RMI,CORBA相当,比WebService小。目前SMCAPP中的语义匹配策略比较简单,执行速度很快,对结果没

有影响。之所以SMCAPP中的服务调用会比RMI的执行效率差许多,是因为MSIP在传输数据量稍大时需要对原有数据进行分拆和重新组装,如遇消息丢失还需要重发,采用基于可靠连接的服务调用协议时SMCAPP的执行结果就比RMI好。但是SMCAPP

第5期徐照旻等:基于面向服务中间件的集成化CAPP系统研究981

中基于简单语义描述的动态服务调用技术具备良好的灵活性和兼容性,并支持多种服务调用协议,能够更好地整合异构系统,这些优势是RMI等架构所不具备的。

discoveryandinteractioninheterogeneousmobileenviron2ments[J].ACMSIGMOBILEMobileComputingandCommu2nicationsReview,2005,9(1):2214.

[9]　RAVERDYPG,ISSAMYV,CHIBOUTR,etal.Amulti2

protocolapproachtoservicediscoveryandaccessinpervasiveenvironments[C]//Proceedingsofthe3rdAnnualInternation2alConferenceonMobileandUbiquitousSystems:Networking&Services.Washington,D.C.,USA:IEEEComputerSocie2tyPress,2006:129.

[10]　ZACHRIADISS,MASCOLOC,EMMERICHW.Exploi2

tinglogicalmobilityinmobilecomputingmiddleware[C]//Proceedingsofthe22ndInternationalConferenceonDistribu2tedComputingSystemsWorkshops.Washington,D.C.,USA:IEEEComputerSocietyPress,2002:3852386.

[11]　GAMMAE,HELMR,JOHNSONR,etal.Designpat2

terns2elementsofreusableobject2orientedsoftware[M].Bei2jing:ChinaMachinePress,2002.

[12]　GOLDENG.RICHARDIII.Serviceadvertisementanddis2

covery:enablinguniversaldevicecooperation[J].IEEEInter2netComputing,2000,4(5):18226.[13]　XUZ,CAIM,LINL,etal.Screen2sharingtechnologyfor

cooperativeCAPPsysteminanetworkedmanufacturingenvi2ronment[J].LectureNotesinComputerScience,2006,3865:3752383.

[14]　STEVEV.Invocationstyles[J].IEEEInternetComputing,

2003,7(4):83285.

[15]　BROMBERGYD,ISSARNYV.INDISS:interoperabledis2

coverysystemfornetworkedservices[J].LectureNotesinComputerScience,2005,3790:12183.

[16]　DAVIDEB.Middleware[EB/OL].[2003209205].http://

www.eecs.wsu.edu/～bakken/middleware.pdf.

[17]　YUM,TALEB2BENDIABA,REILLYD,etal.Ubiquitous

serviceinteroperationthroughpolyarchicalmiddleware[C]//ProceedingsofIEEE/WICInternationalConferenceonWebIntelligence.Washington,D.C.,USA:IEEE,2003:6622665.

[18]　GIANCARLOT,EUGENIOZ.Client2sideimplementation

ofdynamicasynchronousinvocationsforWebservices[C]//ProceedingsofIEEEInternationalParallelandDistributedSymposium.Washington,D.C.,USA:IEEE,2007:128.

[19]　MARCOB,STEFANOC,MARIOP,etal.Managinga2

synchronousWebservicesinteractions[C]//ProceedingsofIEEEInternationalConferenceonWebServices.Washing2ton,D.C.,USA:IEEE,2004:80287.

[20]　GOLANYY,CAIT,LEACHP,etal.Simpleservicedis2

coveryprotocol/l.0[EB/OL].[1999210228].http://bgp.potaroo.net/ietf/idref/draft2cai2ssdp2v1/.

[21]　GRAYNAB.ComparisonofWebServices,Java2RMI,and

CORBAserviceimplementations[EB/OL].[2008203212].ht2tp://mercury.it.gray.pdf.

swin.

edu.

au/ctg/AWSA04/Papers/

5　结束语

本文提出的SMCAPP以SOM实例作为异构

单元系统之间的连接器,通过引入支持多种SDP的服务发现框架,以及支持多种服务调用协议的服务调用框架,实现了多种行业领域CAPP系统之间,以及CAPP系统与CAD、CAM、企业资源规划(En2terpriseResoursePlanning,ERP)等异构单元系统的信息与功能集成。文中基于简单语义描述的服务匹配方式,实现了灵活的服务发现和调用策略,可以支持相同服务的不同版本。多服务发现和调用协议的支持,使得与不同单元系统对应的信息和功能服务可以在不同网络内共享,提高了资源利用率,增强了集成化CAPP系统的自动化程度和兼容性,但进一步减少服务开发人员的工作量、增强系统的智能化程度仍有待进一步的研究。参考文献:

[1]　CHENYongfu,WANGFeng,ZHULin,etal.Development

trendsandcurrentproblemsonCAPP[J].ComputerEngineer2ingandDesign,2004,25(5):7762781(inChinese).[陈永府,王

　峰,朱　林,等.CAPP发展趋势及面临的问题[J].计算机工程与设计,2004,25(5):7762781.]

[2]　LIHuiyun,LIShuhang.Commentonresearchmethodsofin2

tegratedCAPP[J].JournalofMachineDesign,1999,16(2):426(inChinese).[李惠云,李树杭.集成化CAPP的研究方法评

述[J].机械设计,1999,16(2):426.]

[3]　JOHNC.Middlewaremovestotheforefront[J].Computer,

1999,32(5):17219.

[4]　KURTG.Middlewarechallengesahead[J].Computer,2001,

34(6):24231.

[5]　THOMASE.Serviceorientedarchitecture:concepts,technol2

ogyanddesign[M].Crawfordsville,Indiana,USA:PrenticeHallPTR,2005.

[6]　YANGSJH,LANBCW,CHUNGJY.Anewapproach

forcontextawareSOA[C]//Proceedingsof2005IEEEInter2nationalConferenceone2Technology,e2Commerceande2Serv2ice.Washington,D.C.,USA:IEEE,2005:4382443.

[7]　ZHUF,MUTKAMW,NILM.Servicediscoveryinperva2

sivecomputingenvironments[J].IEEEPervasiveComputing,2005,4(4):81290.

[8]　PAULG,GORDONSB,SAMS.Areflectiveframeworkfor