浅谈C++网格服务的开发

　　在web service服务的基础上提出了“网格服务”的概念，它定义了一组接口，这些接口的定义明确并遵守特定的惯例，用于解决服务器发现，动态服务创建、服务生命周期管理、通知等与服务生命周期有关的问题。网格服务标记语言(Grid Service Markup Language, 简称GSML)是一种基于XML的网格应用编程（描述）语言，支持网格环境中用户端的"按需"编程，通过基于可复用组件和事件驱动的方式来描述网格应用灵活多变的处理逻辑和协同工作机制。GSML项目包括GSML语言和相关工具集。

　　GSML语言中的概念 Pipe, Event, EventSet启发自pi演算，通过它们用户能够以统一的异步事件通信机制来描述用户端各种软件组件和网格资源之间的交互关系。GSML相关工具集包括浏览器和编辑器（）。浏览器运行由GSML语言编写的应用程序；编辑器被用来编写GSML程序。GSML的目标是成为一种简单易用的网格编程语言,能够灵活、有效地整合网格资源,而且提供网格 资源、应用和用户进行协同工作的基础设施。

　　C++这个词在中国大陆的程序员圈子中通常被读做“C加加”，而西方的程序员通常读做“C plus plus”，“CPP”。 它是一种使用非常广泛的计算机编程语言。C++是一种静态数据类型检查的，支持多重编程范式的通用程序设计语言。它支持过程化程序设计、数据抽象、面向对象程序设计、制作图标等等泛型程序设计等多种程序设计风格。

　　1  网格体系结构介绍

　　1.1 网格服务标准

　　OGSA(Open Grid Services Architecture)的创建是为了满足网格在分布、异构的动态环境下整合服务的需要。OGSA只定义了架构，没有给出实现。有两种符合OGSA的实现：OGSI(开放式网格服务基础结构，Open Grid Service Infrastructure)和更新的WSRF(网络服务资源框架，Web Service Resource Framework)。OGSI扩展了WSDL（Web Service Definition Language）和XML Schema，使Web Service的状态可以标准化。WSRF是一个符合OGSA标准的实现，用于取代OGSI并统一Web Service和网格服务世界。

　　1.2 网格服务体系结构

　　(1)Globus Toolkit。Globus Toolkit把服务隔绝在网格服务容器（Grid Service Container）中，Globus Toolkit在其中发挥作用并向远程客户端提供服务。容器运行时管理所有服务相关的工作，如服务创建、调用分发和服务销毁。

　　(2)OGSI.NET。OGSI.NET是Microsoft .NET平台上的一个OGSI的实现，由Virginia Grid Computing Group开发。OGSI.NET服务容器的工作机理是通过一个ISAPI过滤器截获Microsoft IIS请求。容器本身被作为一个Windows服务实现。

　　(3)WSRF.NET。WSRF.NET是一个在Microsoft.NET平台上开发符合WSRF规范服务的开发包。这个框架中大量使用了标准的Microsoft程序和工具(如IIS，ASP.NET)。有一个专门的ISAPI过滤器用来更正基于EPR(末端参考，EndpointReference）的消息分发，但是并没有单独的容器来实现，而是用一个静态生成的壳（wrapper）使得网格服务作为标准的ASP.NET网络服务运行。

　　(4)gSOAP。gSOAP是用于创建C/C++网络服务的软件开发包。gSOAP应用于科学计算领域和对时间要求严格的场合，特别经过速度优化。由于加入的层被C++优化过，所以可视为是一种快速、天然的部署C++服务的方法。gSOAP不支持创建OGSI和WSRF服务，因此不能直接作为网格服务的容器。本文将其加入测试，是为和其他体系结构做对比。

　　2  性能对比

　　2.1 测试方法

　　为了测试每种体系结构的性能，创建了一个C++类，其包含两个方法：

　　int Echo(int)：输入一个整数并返回，不做其他处理。

　　int Matrix(int)：输入一个整数k，进行一个矩阵乘法运算，由两个k阶的矩阵相乘，这样每次调用产生一个O(k3)的复杂度运算。返回值是一个整数描述结果的状态。这两个方法产生的数据传输（参数和返回值）是非常小的。这一点保证了调用这两个方法时产生的延迟不是由体系结构部署XML parser时产生的。大多数科学计算程序的调用请求都属于这种少量数据传输的方式。

　　大部分网格架构的测试是通过测量客户端服务调用的等待时间实现的。为达到这个目的，在每一种体系结构下部署了Echo和Matrix方法。测试客户端使用Microsoft.NET平台的C#开发。

　　选择没有负载的服务器测试单纯的服务调用等待时间。客户端每隔50ms调用Echo服务，一共调用100次，平均调用等待时间被记录下来。

　　2.2 测试配置

　　服务器端配置两台相同的PC机。具体配置为：Intel Pentium IV 2.8 MHz CPU，512MB内存，80GB 7200 rpm HDD和100MB以太网卡。

　　每台PC机都重新安装了操作系统。一台运行Redhat Linux（Kernel 2.6.9-5.EL），另一台运行Microsoft Windows XP Service Pack 2。所有的软件包都使用默认安装，没有做任何优化。其结果为默认配置下的结果。

　　客户端使用C#编程。客户端管理程序能够产生多个客户端进程作为分开的线程并且收集每个线程的等待时间，此程序在本文中的所有测试中使用。

　　2.3 测试结果

　　测试Echo方法调用。创建一个服务实例，顺序调用100次Echo。每次调用中间停止50ms，测试结果如图1、图2所示。

　　图1是创建一个服务实例，显示出调用100次Echo的测试结果。Globus Toolkit是网格服务框架中等待时间短的，gSOAP由于只支持Web Service，速度比Globus Toolkit还要快。

　　图2与图1相同，但是包含了OGSI.NET的测试结果。OGSI.NET的调用时间非常长。

　　GT4.0C代表Globus Toolkit4.0下被Java包裹的C服务，GT4.0Java代表Globus Toolkit4.0下的纯Java服务。gSOAP是平均等待时间短的，为3.2ms。网格服务架构中，Globus Toolkit4.0快，为6ms。Java wrapper没有产生明显的性能延迟，C和Java服务有非常接近的测试结果。

　　WSRF.NET 的调用等待时间是23.5ms，OGSI.NET在这项测试中表现非常不好。接下来的测试同样证明了OGSI.NET存在严重的性能缺陷。

　　图3的测试是一个单独的客户端调用100次Echo的结果，每次调用间隔50ms。不同之处在于服务生命期管理功能用于为Echo调用创建服务实例。第二次调用Echo前实例被销毁。从图3可看出，Globus Toolkit的调用时间较之前加倍，WSRF.NET的速度基本没变。

　　测试结果和之前确定的保持一样的层次结构。gSOAP由于不支持网格服务和服务生命期管理，所以没有出现在这次测试中。Globus Toolkit尽管等待时间加倍，但仍然是快的。WSRF.NET的时间不受影响。OGSI.NET的等待时间是778ms。

　　3  结  论

　　测试结果表明，在考虑等待时间和可扩展性的前提下，适合部署C++网格服务的体系结构是加了Java壳的Globus Toolkit4.0。

　　WSRF.NET是一个不错的测试WSRF新标准的平台。但是，它在等待时间上的表现不如Globus。如果这方面要求非常严格，则WSRF.NET不是一个好的选择。

　　OGSI.NET表现出性能问题，等待时间、可扩展性都不好。

　　gSOAP在等待时间和可扩展性方面的表现十分出色。但gSOAP不支持网格服务，所以很难直接比较。如果服务不需要生存期管理、资源、提醒等网格服务的扩展功能并且性能要求很高，则gSOAP可以做为一个不错的部署框架。Globus开发小组在Globus Toolkit 4.0中使用gSOAP作为C++服务支持层。从测试结果中可以看出，在不影响网格服务功能的原则下，极大地提高了网格服务的速度。