专利名称：避免网格计算应用依赖底层开发工具箱的方法
技术领域：
本发明是一种用于开放的网格环境中，采用控制反转等技术解耦网格上层应用对低层网格工具箱的依赖，从而使上层应用可以基于统一标准的API调用低层服务实现，而无须了解具体的服务实现提供者的技术方案。本技术属于网格计算中间件技术领域。
背景技术：
网格被认为是下一代万维网，它是随着Web技术的发展而出现的一种新兴技术，它较好的适应了Internet的特点，能充分实现资源的共享和任务之间的协作完成。随着国内外网格研究的不断升温，有关网格应用的体系标准逐步制定完善。在2002年的第4界全球网格论坛(Global Grid Forum，GGF)会议上，IBM和Globus协作公共倡议了开放网格服务体系结构(Open Grid Services Architecture，OGSA)这一基于网格的应用的通用标准体系结构。随后GGF组织的OGSI(Open GridServices Infrastructure)工作组制定了实现OGSA中各种概念的OGSI规范为创建、管理和网格服务之间的交互定义了标准的接口、行为。相应地，网格计算应用底层支撑平台也不断推陈出新，Globus Toolkit 3.0(GT3)是第一个基于OGSI1.0标准而实现的用于开发网格应用的工具包。
尽管目前越来越多的组织和机构投入到网格技术的开发中，出现了各种网格应用开发支撑平台，但是基于这些工具箱的网格应用开发存在过程繁琐、对工具箱较为依赖等不足之处。在使用这些平台编写网格应用程序之前，网格计算应用开发者必须先详细了解这些工具箱的使用方法并熟悉相应于不同工具箱的编译、部署、发布等命令和步骤。并且这些工具箱仍处于不断的更新换代之中，一旦变换了不同的开发平台，开发者必需重新花费时间和精力来掌握它的使用方法、命令及步骤。简化网格应用开发和减少其对工具箱的依赖成为影响网格技术广泛使用的重要因素。因此研究一种避免网格计算应用依赖底层开发工具箱的软件具有重要意义。
发明内容
技术问题本发明的目的是提供一种解耦网格上层应用对避免网格计算应用依赖底层开发工具箱的方法，使上层网格计算应用不依赖于具体哪个或者哪几个工具箱，而可以通过标准的接口以统一的方式调用低层工具箱的服务实现，平滑地用新的工具箱代替原来的工具箱，从而达到简化网格应用开发的目的和解决网格应用开发中不同工具箱变换的问题。
技术方案本发明的控制反转器是一种改进性的方法，通过加入一个位于网格上层应用和提供网格支撑平台的低层工具箱之间的中间件而提出。该中间件使用控制反转等技术对低层工具箱进行封装，在上层网格应用调用服务时动态寻找匹配的低层工具箱的服务实现，并完成不同工具箱之间的平滑转换。
在现有的网格上层应用中，由于被调用的服务实现名称写入了服务调用者的代码中，这使得服务调用者和服务提供者产生了紧密联系，在UML中用依赖Dependency表示。为了避免网格应用对工具箱的依赖，必须分割这种依赖，于是我们引入了控制反转Ioc(Inversion of Control)模式。
控制反转是一种组件的协作和组织方式，它解耦调用者和被调用者的联系，分离了接口和具体实现。使用这种模式，可以不管将来具体实现，完全在一个抽象层次进行描述和技术架构，因此，Ioc模式可以为容器、框架之类的软件实现提供了具体的实现手段，属于架构技术中一种重要的模式应用。Ioc模式分为构造注入、设值注入、接口注入等多种类型，它们分别在EJB/J2EE、Avalon、SpringFramework、WebWork/Xwork、PicoContainer、HiveMind等架构中被用于实现调用者和被调用者解耦，达到分离接口与具体实现的目的。对于开放的网格环境中网格服务调用者和服务提供者的解耦，Ioc模式提供了较好的实现手段。
一、体系结构我们把开放网格服务体系由上至下分为应用层、应用封装层、低层服务层和资源层，Ioc封装中间件位于应用封装层。它位于应用层和低层服务层之间，通过对低层服务层的封装，向上层提供访问低层网格服务的统一、标准接口，实现网格服务调用的动态适配，进行接口协调和管理。
低层服务是传统意义上的网格服务层，低层服务主要由Globus、CSF以及SRB等开源的网格计算工具箱提供，与应用封装层的中间件不同，它们是通用的面向系统的中间件。低层服务层提供了核心的网格计算服务能力。随着网格服务体系规范的不断更新完善，势必出现各种各样的网格服务提供者。而用户关心的是怎样更好的使用网格服务来解决问题，因此通过应用封装层解耦上层对这些底层架构的依赖，巧妙地避免了用户直接对低层工具箱进行操作，达到了我们简化网格应用开发的目的。
二、方法流程1.通用网格服务调用流程目前基于Web服务的网格服务是客户端/服务端模式的，图2所示的网格服务调用流程是在客户端已经通过UDDI(Universal Description，Discovery andIntegration)注册器获得网格服务端地址并从服务端得到GWSDL(Grid WSDL)网格服务描述之后，它包括网格客户端与服务端之间的一系列交互step1用户应用程序调用客户端stub，由其将本地调用转换成合适的SOAP请求；step2SOAP请求使用HTTP协议通过网络发送给服务端，网格服务容器接收到SOAP请求后将它交给服务器stub，服务器stub把SOAP请求转换为服务器实现程序能够理解的形式；step3服务器实现部分收到从服务器stub转来的请求后，执行所请求的工作；step4执行请求的结果由服务器stub处理转换为SOAP响应；step5SOAP响应使用HTTP协议通过网络发送回客户端。客户端stub收到SOAP响应并将其转换为客户端应用可以理解的形式；step6最终客户端应用接收到调用网格服务的结果并使用这个结果。
2.传统网格应用开发流程传统的网格应用开发直接基于已有的网格底层支撑平台，这里我们以网格当前的最为成熟的Globus Toolkit网格工具箱为例来说明传统的网格应用开发流程。目前Globus Toolkit的正式版本为GT3(Glbus Toolkit 3)，它遵照了OGSA网格体系架构及核心OGSI标准实现。使用GT3开发网格应用包括服务端的网格服务描述GWSDL、服务实现程序、网格服务部署描述WSDD(Web Service DeploymentDescriptor)文件和客户端的用户应用程序的编写，服务器stub和客户端stub的生成。通过使用GT3来编写网格服务，将其部署到GT3网格服务端并通过客户端完成服务调用的基本执行流程。
下面以实现网格平台上数学运算的MathService网格服务为例阐述网格应用开发流程的主要步骤(1)网格服务器端开发流程step1用Java编写网格服务接口程序，通过Java2WSDL工具将其转换成WSDL格式的服务接口描述文件，再经过DecorateWSDL工具将其修饰成最终的WSDL服务接口描述文件；step2借助工具GSDL2Java由WSDL服务接口描述文件生成Java格式的Stub文件，再通过JAVAC编译成class格式的Stub文件，并打包成Math-stub.jar。这个包将会用于客户端的应用程序编译；step3用Java编写网格服务实现程序，通过JAVAC编译成class格式的服务实现程序，编译过程中需要将step2中的class格式的Stub文件加为classpath。然后将class格式的服务实现程序打包成Math.jar；step4编写WSDD部署描述文件，并将其连同step2生成的Math-stub.jar和step3生成的Math.jar，以及step1得到的WSDL服务接口描述文件一起打包成Math.gar网格档案文件。该文件将用于将MathService服务发布到网格平台；step5运行GT3提供的指令将Math.gar网格档案文件发布到网格平台；step6启动GT3网格服务容器后，允许客户端调用该MathService服务。
(2)网格客户端开发流程step1用Java编写调用网格服务的客户端程序，通过JAVAC编译成class格式的客户端程序，编译过程中需要用到上文step2生成的Math-stub.jar；step2如果所调用的网格服务是需要由工厂创建的服务实例，则需调用GT3所提供的指令请求服务端的工厂创建实例；step3执行step1得到的客户端程序调用网格服务，所调用网格服务的
step4GSH(Grid Service Handler)作为参数提供网格服务端地址以及服务所在的位置；step5若服务器端有相应的网格服务提供，则执行用户的请求，并将结果返回给客户端，若没有该服务或调用出错，则提供一个报错消息。
step6若不需要step2所创建的服务实例，可执行GT3所提供的指令请求销毁该实例。
3.服务调用与平台实现耦合点传统网格应用开发流程的各个部分在网格服务的调用与GT3平台的服务实现之间的耦合点及其与OGSA/OGSI标准的关系如下●网格服务接口程序与GT3平台无耦合，继承了OGSI标准的GridService接口。
●网格服务实现程序与GT3平台耦合，继承了GT3的GridServiceImpl类，该类实现了GridServiceBase和ServiceDataValueCallback接口，其中GridServiceBase接口继承了OGSI标准的GridService接口和其他两个GT3所提供的接口。
●WSDD部署描述文件与GT3平台耦合，baseClassName，handlerClass，factoryCallback，operationProviders等公共参数设定为GT3所提供的实现类。
●调用网格服务的客户端程序与GT3平台耦合，依赖于stub中的ServiceGridLocator，而该类继承了GT3所提供的ServiceLocator类并实现了GT3所提供的GridLocator接口。
●工厂实例的创建指令调用了GT3所提供的CreateService类，该类依赖于GT3所提供的ServiceProperties、GridServiceFactory、OGSIServiceGridLocator等类。同时该类以及GridServiceFactory类都用到了OGSI标准的Factory等接口。
4.服务调用与平台实现耦合剥离为达到避免网格服务应用开发依赖于固定的网格底层支撑平台，须将服务调用和服务实现在这些耦合点剥离，这个工作将由Ioc封装中间件来完成。针对不同的情况，中间件将采取不同的方式处理应用与低层工具箱之间的联系。总体来说，对于与OGSI标准相关的接口，因为用户可以根据现有标准定义的规范接口来调用服务，所以我们应用Ioc的各类模式将调用者与被调用者的联系剥离，并将其封装成符合规范的接口提供给上层应用；而对于标准尚未定义交互接口的耦合，我们根据需要采取有效的方式进行封装适配以达到避免依赖低层工具箱的目的。
对各种耦合的主要处理方法如下●对于网格服务实现程序与GT3的GridServiceImpl类的耦合，采用Ioc的设值注入方法来解耦服务实现程序类改为统一继承中间件中的一个封装类，而该封装类对外公布一个方法setProvider，在网格服务实现程序被调用时由容器把和平台相关的服务实现基类传给它。由于用户在网格服务实现类里声明了它所实现的接口，容器需要从该接口中提取与标准相关的内容，并按照标准为给接口所定义的规范，在平台的服务实现中寻找与标准匹配的实现类。当平台服务实现的接口符合标准，只需要针对各个接口的定义进行简单的匹配就可以得出结果。当平台服务实现的接口不完全符合标准时，将用到下文将要陈述的算法。
●WSDD部署描述文件中baseClassName，handlerClass，factoryCallback，operationProviders等公共参数值与GT3的耦合，采用Ioc的构造注入方法来解耦将这些公共参数值统一设定为中间件的对应封装类，当这些类被创建时，确定对应的与平台相关的类，并为将这些类的实例传给封装类。
●调用网格服务的客户端程序与GT3的ServiceGridLocator耦合，采用面向切面织入编程的AOP方法来解耦客户端程序采用统一的方式来调用网格服务，即调用中间件的客户端调用类。而该类则根据不同的网格平台来处理客户端的请求并将其按照符合平台的格式传送出去。这里的提取的切点是各平台的网格服务调用方法。工厂实例的创建等指令也采取与此相同的方式解耦。
5.标准抽取及匹配算法OGSI定义了最基本的网格服务所必须实现的GridService portType，以及其他可选portType和特定于应用或领域的portType组合。OGSI以Web服务为基础，采用WSDL作为描述公用网格服务接口的机制，遵循XML Schema的语法，呈现为一个ogsi.gwsdl文档。当网格底层支撑平台所提供的服务实现接口不符合该标准，我们需要知道这些服务实现与标准的匹配程度以及对应关系。参考XML Schema的语法结构，根据ogsi.gwsdl将各个规范portType解析成排序有根树(orderedrooted tree)，然后以这些树为样本对每个结点进行匹配。
下面给出具体的匹配算法procedure postorder(T排序有根树)r＝T的根for从左到右遍历r的每个子结点ribeginT(ri)＝以ri为根的子树postorder(T(ri))endifri是偶级结点thenm＝match(ri)ifri是叶thenifri是r最左的子结点thenCr＝0Cr＝Cr+m*μrs....r，riifri是r最右的子结点thenCr＝Cr*μrs....rp，relse Cri＝Cri+m*μrs....r，rielse ifri是r最左的子结点thenCr＝0Cr＝Cr+Cri树根标识为0，其子按从左至右的顺序标识为1、2、3、...，其下的子孙结点以从树根到该结点所经过的结点来标识，如2的最左的子标识为2.1。算法中的μr1.r2....rh，i是r1.r2....rh的第i个子结点的效能系数(effect coefficient)，代表该结点对整棵树匹配的影响效力。最后得到的C0就是整棵portType树的匹配率。计算过程中所得到的中间结果Cr矩阵，可通过设定一个适当的门限值得到该平台所提供的服务接口与标准portType各要素的映射关系。在调用服务时，可以直接参照所得的映射调用匹配的服务。
6.Ioc封装后的网格应用开发流程经过Ioc封装后的网格应用开发流程仍分为编译、打包、发布和调用四个阶段。但是经过中间件的封装，用户需要提交的服务接口程序、服务实现程序、部署描述文档以及服务调用程序都脱离了具体的网格计算底层平台，原来与平台之间的耦合由中间件所提供的统一API替代，实现了调用者与被调用者的联系剥离。从而开发流程前两个阶段服务端的编译和打包和客户端的编译可以完全不依赖于网格工具箱。在开发流程的后两个阶段中，被剥离的依赖将完成按需重新注入●发布阶段由于服务的发布与具体的网格底层平台有关，涉及到不同平台对服务接口描述文档、服务实现类库的路径设置以及服务端的配置修改。因此这个阶段将完成部署描述文档与平台相关内容的重新注入，而其他部分如服务实现仍然保持与平台的不相关性。
●调用阶段在这个阶段所开发的服务应用被调用并执行得到结果，故这个阶段将完成所有的依赖重新注入。按照调用的服务，可以有不同的注入顺序若调用的是需由工厂创建的服务，依次完成注入的是客户端工厂服务实例创建请求，服务实现，客户端服务调用，服务实例撤销请求；若调用的是暂时性的服务，依次完成注入的是客户端服务调用，服务实现。
有益效果本发明方法提出了一种避免网格计算应用开发依赖网格计算底层开发工具箱的新方法，主要用于解决网格计算应用无法脱离平台进行的问题，为简化网格计算应用开发流程提供便利。通过使用本发明提出的方法网格计算应用开发可使用统一的API，避免了开发者熟悉不同网格底层支撑平台的重复劳动和依赖GT3等平台开发网格服务的复杂性。而且本发明使网格计算应用开发的各个阶段尽可能地相互独立，有利于各阶段处理过程的基于ant等工具的简化，可以提高设计方法的简便性和灵活性。避免网格计算应用开发依赖网格计算工具箱具有如下优点
1.开发编程简易本发明旨在简化网格计算应用开发，避免了其对底层工具箱的依赖，很大程度地方便了应用开发者的服务实现程序和部署描述等文档的编写。中间件向上提供了统一的API供用户程序调用和部署参数设置，开发者不必花费时间精力去了解底层工具箱的接口和编程方式，更省去了更换底层工具箱之后的重复性劳动，使网格计算应用的开发简单易行。
2.代码可重用性本发明的中间件主要工作是完成对底层工具箱的封装和适配，对于不同的网格底层平台，只需进行一次对工具箱的预封装就可使用，采用现有的网格工具箱的通用应用模式，可用于多种网格工具箱。基于本发明所提供的API，网格计算应用程序代码无须修改就可提交到不同的网格底层平台上使用，同样有良好的可重用性。
3.标准的可变性XML已成为Web技术主流的信息表示格式，虽然网格的各类标准不断推陈出新，但其表示格式将在较长的时间内保持XML格式。本发明提出的算法不仅可解析XML格式的OGSI标准，同样可以解析将来替代OGSI的新标准，只要这些标准采用的是XML格式的。本发明充分考虑到网格技术的发展趋势，使所提出的方法能有高度的可适应性和灵活性。
4.良好的扩展性参考开放式网格服务体系结构模型和五层沙漏体系结构，本发明以网格应用中间件的形式呈现，其他中间件开发者可以基于本中间件的封装对网格计算进行进一步的开发，体现了良好的可扩展性。
5.为网格开发进一步简化提供支持可以看到基于本发明的通用应用框架中，流程分为四个独立的阶段编译、打包、发布和调用。网格应用开发的前两个流程都完全独立于网格底层平台，而后两个流程也是分步完成依赖注入。用户只需提交服务接口、服务实现、服务调用以及部署描述，后面的过程可以通过借助ant等批处理工具来完成。结合对网格计算应用的解析和代码生成技术，应用开发者可以仅仅提交和普通应用程序一样的服务实现代码，通过处理得到符合要求的服务接口、服务实现、服务调用以及部署描述具体，然后借助图形界面完成编译、打包、部署和调用。因此本发明为网格应用开发的进一步简化提供了较好的支持。
图1是Ioc控制反转器在开放网格服务体系中的层次示意图。图中由上至下分为应用层、应用封装层、低层服务层和资源层，Ioc封装中间件位于应用封装层。
图2是控制反转器的组件结构图。它包含解耦器、流程控制器、运行调配器、封装维护器四个功能组件。其中解耦器包含实现解耦、部属解耦、调用解耦。
图3是通用网格服务调用流程图。图中包括网格服务端与客户端的一系列交互。
图4是基于GT3网格平台的网格应用开发流程图。图中显示了需要编写、处理、编译、打包、部署的各类程序和文件及开发过程。
图5是Ioc封装后的网格应用开发流程图。表示基于本发明的一个通用应用框架。
具体实施例方式
为了方便描述，我们假定有如下应用实例网格应用开发者要开发一个MathService网格服务。该服务在网格服务端提供工厂服务，可响应客户端创建服务实例的请求。创建的服务实例对客户端提交的两个参数进行加、减、乘、除数学计算并返回计算结果。现采用GT3.0.2网格底层平台的服务端与客户端。
则其具体实施方式
为(1)应用开发者编写服务接口程序Math.java声明MathService网格服务所要实现的加、减、乘、除等数学运算操作及其参数及返回值类型；(2)应用开发者编写服务实现程序MathImpl.java声明其基类为中间件所提供的通用网格服务实现封装类，并实现MathPortType接口(该接口将由服务接口程序Math.java生成)；同编写普通接口实现程序一样，开发者在程序体内编写上一步接口程序中声明的所有操作的具体实现代码；(3)应用开发者编写部署描述文档Math.wsdd设定描述MathService网格服务的名称、服务实例的名称、WSDL的路径、服务实例的基类等的参数；公共参数中的baseClassName、handlerClass、factoryCallback、operationProviders分别设定为中间件提供的对应封装类；(4)借助ant完成编译打包将所需要进行的服务接口编译生成、服务实现编译、文档复制等工作以build.xml的形式提交，ant将按照给定顺序处理用户所提交的所有程序和文档，并给出每阶段处理信息的反馈，如无错误将会显示build成功，直接得到需要发布到平台服务端上的Math.gar网格档案文件。
(5)发布到网格计算平台服务端调用本中间件提供的部署解析程序，该程序将自动根据所识别的网格平台处理部署描述文档，针对GT3.0.2平台，它将处理●将部署描述文档中相关参数修改为GT3.0.2的相应实现类；●调用ant和包含GT3.0.2平台发布信息的deploy文档进行服务发布；(6)客户端请求创建工厂服务实例调用本中间件提供的用户请求加装程序，该程序将识别网格平台并根据用户提出的创建工厂服务实例的请求，按照具体的平台向服务端提出格式符合要求的实例创建请求；(7)服务端创建工厂服务实例服务端容器响应客户端请求，创建工厂服务实例所进行的工作如下●容器根据服务接口查找匹配的低层服务提供者，得到GT3.0.2工具箱的服务实现类；●容器依照请求所带的参数(网格服务句柄GSH)查找到已发布在平台服务端的MathService服务工厂类，为其注入GT3.0.2工具箱的服务实现类；●容器创建MathService的实例，将其加入容器实例库，并通知客户端创建成功并告知所创建实例的GSH；(8)客户端调用服务实例进行数学运算调用本中间件提供的用户请求加装程序，该程序将处理用户的调用及相关参数按照具体的平台向服务端提出格式符合要求的服务调用请求，并根据用户的设置与服务端协商好返回结果的格式；(9)服务端执行对服务实例的操作服务端容器接收到客户端的请求，在实例库中查找到对应GSH的实例，调用所请求的操作，并将结果按照约定的格式返回给客户端；(10)客户端得到所请求数学运算操作的结果，全过程结束。
权利要求
1.一种避免网格计算应用依赖底层开发工具箱的方法，其特征在于它将网格应用开发与具体的网格工具箱分离开来，避免网格应用依赖于特定的开发平台；该方法的控制反转器由流程控制器、解耦器、运行调配器、封装维护器组成流程控制器负责网格应用开发主流程，控制其他三个组件对用户提交程序的处理；封装维护器封装网格底层平台，向流程控制器提供统一的调用接口；流程控制器将所需服务的接口作为解耦器的输入，通过解耦获得调用服务所需的解耦类；运行调配器在启动服务调用时被流程控制器启动，对服务调用过程中底层平台所出现的变化进行实时处理，运用这些组件开发网格计算应用的方法具体如下1)启动控制反转器，封装维护器和解耦器解析可用的网格计算底层平台，进行初始的预封装和解耦处理；2)由网格计算应用开发者将可在单机上运行的服务实现、服务接口和服务调用程序提交给控制反转器，流程控制器启动网格服务开发流程；3)流程控制器启动网格服务服务端部署子流程，包括如下步骤a.子流程控制器从解耦器获得网格服务实现的虚接口，改写服务实现程序；b.子流程控制器编译改写后的服务实现程序和开发者所提交的服务接口程序，得到网格服务实现类及服务调用时将使用的stub类；c.子流程控制器请求解耦器进行部署解耦，获取部署描述器公共参数的公共封装类，根据网格计算应用开发者提供的服务实现程序生成网格服务部署描述文件；d.子流程控制器将部署描述文件、改写后的服务实现程序和开发者所提交的服务接口程序打包；e.子流程控制器启动封装维护器，解析部署描述文件中的公共封装类，获得与网格计算底层平台相关的对应类；f.子流程控制器请求解耦器进行实现解耦，根据解析后的部署描述文件将生成的解耦类与网格服务实现类发布到具体的网格计算底层平台；g.子流程控制器通知流程控制器服务端部署成功；4)流程控制器启动网格服务客户端部署子流程，包括如下步骤a.子流程控制器利用上一子流程生成的stub类，编译开发者提交的网格服务调用程序，得到网格服务调用类；b.子流程控制器从封装维护器获取封装后的服务公共操作类，添加网格服务调用的预启动操作；c.子流程控制器请求解耦器对所开发的网格服务进行调用解耦，并将生成的解耦类与网格服务调用类、预启动操作一起提交给网格服务调用方；d.子流程控制器通知流程控制器客户端部署成功；5)流程控制器通知网格计算应用开发者网格服务部署开发成功；6)所开发的网格服务使用者在客户端运行网格服务调用指令要求调用网格服务，执行指令时首先运行服务调用的预启动操作，然后运行服务调用类，通过解耦类得到反转后的服务调用类进行网格服务调用；7)服务端的网格计算平台在接收到客户端的服务调用请求后，查找到对应的网格服务实现类，并运行该服务实现类。服务实现类通过解耦类得到反转后的服务实现类，在调用前要求平台验证所提供的支撑类未变；8)如果网格计算平台确认支撑类未变，服务实现类将直接运行得到调用结果并返回给客户端；如果网格计算平台发现支撑类发生了改变，将启动控制反转器的运行调配器实时寻找可用的支撑类，并向封装维护器请求进行重封装。
全文摘要
避免网格计算应用依赖底层开发工具箱的方法是一种用于开放的网格环境中，采用控制反转等技术解耦网格上层应用对低层网格工具箱的依赖，从而使上层应用可以基于统一标准的API调用低层服务实现，而无须了解具体的服务实现提供者的技术方案。该方案解除了网格服务实现、部署描述和服务调用与网格工具箱的耦合，使网格应用的开发的编译、打包阶段可完全脱离网格工具箱进行，而网格的部署和调用阶段均实现了自动按需注入与平台相关的内容。该方案使网格工具箱对网格应用开发者完全透明，使网格应用开发流程易于简化，与代码生成、图形化界面等技术相结合使用，很大程度上方便了网格应用的开发。
文档编号G06F9/44GK1744037SQ20051009403
公开日2006年3月8日 申请日期2005年8月26日 优先权日2005年8月26日
发明者王汝传, 杨清 申请人:南京邮电大学