网格计算
取消
显示结果 
搜索替代 
您的意思是: 

分享我的技巧 : 基于.NET的开放网格计算——OGSI.NET

mybabys
本科生

分享我的技巧 : 基于.NET的开放网格计算——OGSI.NET

一. OGSI.NET(http://www.cs.virginia.edu/~humphrey/GCG/ogsi.net.html



1.基础架构



OGSI.NET的目标是尽可能地利用Microsoft核心的技术去实现OGSI。对于设计而言,是尽量令架构中的层尽可能“薄”,这样的目的是为了在Microsoft提供了技术的新版本的时候能够很方便地利用上。特别地,是指Web Services security的标准,但是这个标准到目前为止还没有一个公共的实现,微软对其有实现,而其他公司也有。因此,设计者希望微软能够提供一套SDK,即使有升级或变动,也是SDK内部的事,不需要开发人员对这些版本问题感到愁心,这也达到了以上令层尽可能薄的目的。而WSE(Web Services Enhancements)正属于此类SDK。



下面来说说OGSI.NET的基础架构。在设计中,OGSI.NET有一个实体容器容纳了全部的运行在同一台主机上的服务实例。这个容器进程是由一个应用程序域(AppDomains)的集合构成的,之所以提到应用程序域,是因为.NET的这个机制保证了进程内部的内存保护,即使一个AppDomain崩溃了,也完全不会影响到其他的AppDomains。除了每一个服务实例运行在它们的AppDomains中外,还有一个AppDomain负责容器的逻辑(比如调度、消息的处理等等功能)。在这个AppDomains中的对象可称为调度器(Dispatcher)。在现行版本的OGSI.NET中(OGSI.NET 2.0),每个服务都会被放在它自己独立的AppDomain中,为什么这样子做呢?举个例子,假如被同一个factory(OGSA,Open Grid Services Architecture,中定义的创建网格服务的接口)创建的服务都存在于同一个AppDomain中,这样的方式虽然在服务间进行通信显得很有效率,但是假如有一个错误的服务或是一个恶意的服务直接访问了AppDomain中其它服务的内存,付出的却是安全的代价。



当一个客户端向OGSI.NET发送请求的时候,它实际上是向IIS服务器发送信息。为了让网格服务支持随心所欲的名字,OGSI.NET使用了ISAPI过滤器在请求信息进入IIS请求链的前期就把它拦截了。过滤器重写了请求,所以IIS会把它调度给OGSI.NET的ASP.NET HttpHandler。这个HttpHandler调度这个请求给OGSI.NET的容器。容器进程拥有一个线程池,每一个IIS请求都会引起一个线程起执行调度器。调度器会决定哪个服务实例可以取得请求同时将线程的执行转移到合适的AppDomain的对象中。



在AppDomain里面,控制被转移到一个叫做Grid Service Wrapper(GSW)的对象中。一个GSW包括了一个服务的实例,包括它的方法的实现和它的服务数据。GSW维护着服务所支持的port type的一个列表(包括OGSI指定的由OGSI.NET提供的port type,以及自定义的port type。比如GridService port type和NotificationSouce port type等),另外还有序列化器和逆序列化器,这两个是为了满足服务支持多种消息协议(比如SOAP或.NET Remoting)的需要而存在的。GSW执行对每一个特定消息的处理,并逆序列化请求信息,从中得到要调用的方法的名字以及参数,通过请求中的参数还有特定的消息数据(比如SOAP标头数据)来调用方法。当调用返回数据时,GSW再将这些数据序列化成一个二进制array并传回给调度器,调度器再将这个array传给IIS并返回给客户。