MS.NETGrid OGSI Implementation Design Overview

Transcription

1 MS.NETGrid OGSI Implementation Design Overview Project Title: Document Title: Document Identifier: Authorship: MS.NETGrid MS.NETGrid OGSI Implementation Design Overview MS.NETGrid-OGSIDesignOverview-v1.0 Daragh Byrne Document History: Personnel Date Summary Version EPCC 16 th June 2003 EPCC Approved. 1.0 DB 4 th June 2003 First Draft. 0.1 DB 13 th June 2003 Revisions after feedback 0.2 Approval List: EPCC: Project Leader, Technical Staff, Technical Reviewers, Coach Mike Jackson, Daragh Byrne, Ally Hume, Ali Anjomshoaa, Dave Berry, Neil Chue Hong Approval List: Microsoft Research Limited: Managing Director, University Relations x 3 Andrew Herbert, Fabien Petitcolas, Van Eden, Dan Fay Copyright 2003 The University of Edinburgh. All rights reserved.

2 MS.NETGrid-OGSIDesignOverview-v1.0 2 Contents Contents Introduction Design Goals Design Outline High-level Architecture Service Lifetime Maintaining State OGSI Service Container Proxy Classes Example Configuration and Service Deployment GridServiceSkeleton Factory PortType ServiceData Limitations Glossary References... 18

3 MS.NETGrid-OGSIDesignOverview-v Introduction MS.NETGrid is a project to demonstrate the relevance of the Microsoft.NET suite of technologies to e-science and Grid computing. The project is described in [MS.NETGrid- Proj-Def] and on the project WWW site ( One of the deliverables of the project is an implementation of the Open Grid Services Infrastructure [OGSI-Spec]. The purpose of this document is to: 1. State the design goals with respect to our OGSI implementation. 2. Outline the high-level components of the design and implementation.

4 MS.NETGrid-OGSIDesignOverview-v Design Goals The MS.NETGrid project is concerned with demonstrating the applicability of Microsoft.NET to Grid services to the e-science community. Thus, a core goal of the design was to exploit as many relevant.net capabilities as is possible and sensible. Since Grid services are essentially an extension of Web Services, a key design goal was to exploit the Web Services functionality provided by.net, particularly ASP.NET, as far as possible. Additional design goals were as follows: To provide an implementation that exhibits a representation of the key aspects of OGSI, namely porttypes, service state and service data, and lifetime management. To support SOAP over HTTP as our communications protocol, offering no explicit support for other methods of invocation at this time. To aim for interoperability where appropriate and to make it clear what support we provide for interoperability. To keep in mind performance-related issues during design, implementation and testing and to be prepared to identify the areas of our design and implementation that are performance-critical and options for improving these. To utilize any features of the target technology that contributed to rapid development time, as development was scheduled to occur over a short timescale.

5 MS.NETGrid-OGSIDesignOverview-v Design Outline Our design was inspired by features from both the Globus Toolkit 3 implementation of OGSI [GTk3] and the design of OGSI.NET described in [Virginia-Impl]. However, we decided that it was best to exploit existing technology as much as possible to cut down the development time. A distinguishing feature of our design is in the use of ASP.NET to intercept and serialize incoming HTTP/SOAP messages, and mimicking the service deployment model it provides. This results in an implementation that could be regarded as lightweight in some ways, but still satisfies the goals of the project. 3.1 High-level Architecture Our container has the following high-level architecture: HTTP Request, SOAP Message ASP.NET Web Application GridServiceInstanceAspProxy Request handled by ASP.NET Web Service Service Skeleton Instance SOAP Response to client Selects Service Instance Calls method on Instance PortType As can be seen, we implement our OGSI container as an ASP.NET Web Application. Within this application are components for dealing with service instance management, managing communication with clients, providing OGSI porttype-related functionality, and allowing developers to deploy services. The following sections discuss the design in more detail. 3.2 Service Lifetime Our container allows two types of service lifetime. The first, known as transient service lifetime, applies to service instances which are spawned by other services, for example factory services. The service instance lives until its termination time has passed, when it then will no longer respond to operation invocation requests. The second is known as persistent lifetime. In this case, the service instance is initialised when the container starts up and lives as long as the containing Web Application. Container-created (persistent) services are necessary to bootstrap essential services such as factories. 3.3 Maintaining State Consuming an XML Web Service entails sending a SOAP message to a network endpoint somewhere. At the endpoint, the message is interpreted, for example by AXIS functionality [AXIS] in Globus Toolkit 3, or ASP.NET. The Web Service exposes a number of operations, and one of these is invoked, based on the content of the SOAP message. An object is instantiated, and the method called, with any de-serialized objects as parameters. Once the processing has been carried out, any return values are serialized into a SOAP message and sent back to the client. The processing object is destroyed, or left to be garbage collected.

6 MS.NETGrid-OGSIDesignOverview-v1.0 6 Essentially a traditional Web Service can be said to be inherently stateless. A stateful Grid Service necessitates that a service object be maintained, so that the next call by the client is handled (conceptually) by the same object instance. We can do this either by Storing references to service objects and mapping client requests to objects directly Creating a new object for each call, and maintaining state between calls using some persistent storage e.g. serializing the object out to disk between calls. The first of these options was preferable as it avoided the overhead of saving and loading state data in response to each client request. The problem then becomes that of making transient ASP.NET Web Services act like persistent Grid Services. The solution we use is as follows: 1. A service instance is represented by an instance of a class derived from a GridServiceSkeleton class. A reference to each instance is stored in a registry in the container. 2. Communication with the service instance is handled by a Web-Service proxy. We provide a GridServiceInstanceAspProxy class (and derived classes), from which service proxies must derive. The proxies are located in.asmx files like normal ASP.NET Web Services. The proxy for a service class contains methods that map directly to the service methods. These methods correspond to the porttype operations exposed by the Grid service. 3. Clients interact directly with the proxies as if they were a normal Web Service. 4. A new instance of this proxy is created for every service invocation request as normal. Upon creation, the proxy uses information contained in the request to obtain a reference to the GridServiceSkeleton instance that is supposed to deal with that request. 5. The proxy uses the request information to call a specific method on the service instance using reflection. 6. The result is returned by the proxy and automatically serialized back to the client by ASP.NET The following diagram illustrates the process: Return Result client Map Request to Instance (HttpApplication) Service Instance Method Call (Grid Service Instance) SOAP Request (Web Service Proxy)

7 MS.NETGrid-OGSIDesignOverview-v1.0 7 For every persistent service instance, there must be one unique proxy. For example, say we have a factory for a service CounterService. The proxy for this factory could be located at Note that under this scheme CounterServiceFactory1.asmx and CounterServiceFactory2.asmx would be proxies for two different persistent instances. Persistent service instances are identified in the container by the virtual path to the.asmx file. For every class of transient service, e.g. CounterService, there will be one proxy file. Thus, all CounterServices would be represented by the proxy located at We differentiate between different counter service instances by the use of an instanceid parameter in the querystring of the URL. So: nce1 and nce2 represent communication endpoints for two different CounterService instances accessed via the same.asmx proxy. 3.4 OGSI Service Container The following diagram describes the container part of our ASP.NET Web Application. The main class involved is Ogsi.Core.Container.OgsiContainer. This class provides static methods for registering and deregistering service instances, as well as looking them up based on an identifier. OgsiContainer <<property>> containerregistry_ : GridServiceInstanceRegistry <<static>> RegisterTransientService() <<static>> RegisterPersistentService() <<static>> DeregisterTransientService() <<static>> DeregisterPersistentService() <<static>> GetTransientInstanceById() <<static>> GetPersistentInstanceByVirtualPath() <<static>> InitializePersistentServices() IServiceInstanceMap <<property>> [] : GridServiceSkeleton GridServiceInstanceRegistry 0 2 ServiceInstanceMapImpl objectmaphashtable_ : System.Collections.Hashtable This class is used to record information on the persistent and transient Grid services currently residing under the ASP.NET application. The container is the means by which the proxy classes look up service instance references. It is also used by factory services to internally

8 MS.NETGrid-OGSIDesignOverview-v1.0 8 register the new transient service instances that they create. OgsiContainer uses an instance of GridServiceInstanceRegistry, which has at its core a pair of synchronised hashtables. The hashtables are synchronised to avoid threading issues that can arise from the simultaneous arrival of multiple service requests OgsiContainer also contains a method called InitializePersistentServices(). This method starts any persistent services deployed in the container using information in the ASP.NET Web.config configuration file. It is called once when the Web Application starts up, via the Application_Start() event handler in the Ogsi.Container.Global class. This Global class is the HttpApplication-derived class that comes free with every ASP.NET Web Application and is located in the root directory of the distribution. 3.5 Proxy Classes Example Service operation requests are intercepted by ASP.NET Web Services, which effectively act as proxies to the Grid Service instances. These proxies are located in.asmx files under the ASP.NET virtual directory. The proxy Web Service is a sub-class of a class called GridServiceInstanceAspProxy, which handles service persistence and delegates method calls to the appropriate service instance. The following class diagram illustrates the proxy classes. <<abstract>> GridServiceInstanceAspProxy serviceinstance_ : GridServiceSkeleton CallM ethod() <<virtual>> InitializeServiceO bject() GridServiceInstanceProxy() CallM ethodonprovider() <<WebM ethod>> findservicedata() <<WebM ethod>> requestterm inationbefore() <<WebM ethod>> requestterm inationafter() <<WebM ethod>> destroy() TransientGridServiceInstanceAspProxy PersistentGridSe rvicein stanceasp Pro xy To illustrate the principle, we here define a simple counter service and its proxy. The service class looks like: public class MyCounterService : GridServiceSkeleton { private int count_ = 0; } public int Increment(int amount) { count_ += amount; return count_; }

9 MS.NETGrid-OGSIDesignOverview-v1.0 9 The associated proxy class in MyCounterService.asmx would look like: public class MyCounterServiceProxy { [WebMethod] public int Increment(int amount) { object [] args = { amount }; object result = CallMethod( Increment, args); return (int) result; } } The CallMethodOnProvider() method is similar to CallMethod() but does not call the method directly on MyCounterService. Instead it calls the method of a provider associated with the class as explained in section Configuration and Service Deployment Service deployment is managed using the.net Framework configuration utilities. We define a gridcontainer.config element in the ASP.NET Web.config configuration file as follows. Inline comments describe the use and meaning of the XML attributes and elements. <config> <gridcontainer.config> <containerproperties> <add key= propertyname value= value /> </containerproperties> <gridservicedeployment> <gridservicedeploymentdescriptor asmxproxyfilename= MyProxy.asmx <!--name of the proxy file -- > serviceclass= Some.Full.ClassName <!-- fully qualified class name for this service --> assembly= ServiceAssemblyName <!-- Note no.dll at the end --> persistence= persistent transient > <!-- whether this is persistent or transient --> <serviceparameter name= param1 value= value1 /> <!-- arbitrary parameters -->... </gridservicedeploymentdescriptor>... </gridservicedeployment> </gridcontainer.config> </config> The containerproperties element is handled using the ASP.NET System.Configurationprovided NameValueSectionHandler. The gridservicedeployment element is handled by our custom-written Ogsi.Container.Configuration.DeploymentDescriptorSectionHandler class. Configuration is handled in our Ogsi.Container.Configuration.ContainerConfig class. This, in turn, uses the.net-provided System.Configuration.ConfigurationSetting class to process Web.Config. Container properties in the containerproperties element are properties we wish to be easily

10 MS.NETGrid-OGSIDesignOverview-v configurable. Items of interest in this element include the local domain name and the application virtual directory. GridServiceDeploymentDescriptors are used to map between proxies and service classes. The serviceparameter child nodes are used to pass service specific information to the created service instances in an application specific way. These parameters are then available to the service instance via its ServiceParameters collection. Cont ainercon fig GetListOfProxyMappings() GetContainerProperty() 1 * GridServiceDeploymentD escriptor virtualpath_ : string classname_ : string namespace_ : string ispersistent_ : boolean DeploymentDescripto rsectionhandler Create() 3.7 GridServiceSkeleton GridServiceSkeleton and its sub-class PersistentGridServiceSkeleton are the core classes from the point of view of the service developer. The developer inherits from one of these depending on whether they wish to create a persistent or transient service. Methods on this sub-class correspond to service operations, and each will have a corresponding proxy method as described above. OgsiPortT ypeattribute 0..* OperationProviderBase <<property>> ServiceInstance = GridServiceSkeleton 0..* 1 GridServiceSkeleton servicedataset_ : IServiceDataSet queryengine_ : IQueryEngine <<property>> TerminationTime <<property>> ServiceParameters <<property>> IsDestroyed 1 IOperationProvider <<property>> ServiceInstance : GridServiceSkeleton CallServiceMethod() PersistentGridServiceSkeleton The core class created by the service developer must either contain methods corresponding to

11 MS.NETGrid-OGSIDesignOverview-v the operations provided by all the porttypes aggregated by the service. However some of these methods can be omitted if the service developer specifies a so-called provider which provides the methods associated with some porttype. This is done via the use of OgsiPortType attributes. The service author does this as follows within the class: [OgsiPortType(typeof(SomeOperationProvider))] [OgsiPortType(typeof(SomeOtherProvider))] public class MyService : GridServiceSkeleton { //Other methods go here optionally, or are provided by //providers } In the proxy methods for the porttype, the providers are called using the CallMethodOnProvider() method, with the full name of the provider type as a parameter: public int SomeProvidedMethod() { return (int) CallMethodOnProvider( Full.Class.Name.Of.SomeOperationProvider, null); } The OperationProviderBase class and IOperationProvider interface are provided as a convenience to developers. Should a porttype operation provider wish to access the ServiceDataSet, ServiceParameters etc associated with the GridServiceSkeleton from which they hang, they may extend or implement one of these. On instantiation by the container or factory, the provider will be set with a reference to the service instance. 3.8 Factory PortType The factory was designed to be used via the OgsiPortType attribute mechanism described above. The Factory porttype class has one method, CreateService(). We have designed the factory so that the service object creation is done by an instance of a class that implements the IFactoryCreator interface. This is intended to make the factory as generic as possible. The creator is specified in the deployment descriptor for the factory: <gridservicedeploymentdescriptor asmxfilename= MyServiceFactory.asmx serviceclass= Ogsi.Demo.Basic.BasicGridServiceFactory assembly= Ogsi.Container persistence= persistent > <serviceparameter name= creationprovider value= Full.Provider.Type, ProviderAssembly /> </gridservicedeploymentdescriptor> This parameter must be supplied for any service that uses the Factory porttype.

12 MS.NETGrid-OGSIDesignOverview-v Ope rationproviderbase <<property>> ServiceInstance = Grid ServiceSkele ton Fa ctoryportt ype CreateService(creationParam s : CreationType) 1 1 IF a c t o ry C re a to r CreateServiceOb ject(xm lelem ent param s, GridServiceSkele ton factory) The IFactoryCreator implementation class is used to create a GridServiceSkeleton-derived class and perform any application-specific initialisation required on it. 3.9 ServiceData ServiceData are essentially collections of XML elements associated with a service instance. The.NET Framework Class Library provides significant scope for the management of servicedata, offering classes for both XML handling and dealing with collections. The requirements associated with servicedata are: Providing a description of the servicedataset associated with a Grid Service. Providing a collection of servicedata on a running service instance. Allowing the values of servicedata to be obtained. Providing an API that allows the developer to add and modify servicedata elements. Allow flexible querying and updating of servicedata values in accordance with [OGSI-Spec]. We supply a number of classes and interfaces that deal with servicedata. Essentially we provide a stripped-down clone of the [GTk3] servicedata library. The classes that deal with aggregating servicedata elements and providing servicedata values are illustrated in the following diagram:

13 MS.NETGrid-OGSIDesignOverview-v ServiceDataSet servicedataentries_ : Hashtable 1 * ServiceData name_ : QName callback_ : IServiceDataValuesCallback values_ : Object[] IServiceDataValuesCallback <<<<p ro perty>>>> Servi ceda ta Valu es : Obj ect[] The servicedata class represents a single servicedata element, which may have zero or more values. ServiceData elements are identified by an XML Qualified Name. Values may be set by hand using the Values property. Alternatively, the Callback property can be set to point to an instance of an implementation of the Ogsi.ServiceData.IServiceDataValuesCallback interface. This provides a property, ServiceDataValues, which allows the user to customise how the values are obtained. This can support the construction of service data only when it is explicitly required as a consequence of a client request. The following diagram illustrates the query/update mechanism provided. Every ServiceDataSet has a QueryEngine, which contains a collection of instances of IExpressionEvaluator implementations. These IExpressionEvaluator instances are registered by the XML Qualified Name of the expression they are intended to handle. When the ExecuteQuery method of QueryEngine is called, the name of the element is investigated and the relevant expression evaluator is asked to do the evaluation. We provide expression evaluators to cover the minimum required by [OGSI-Spec]. The QueryByServiceDataNames evaluator, for example, deals with expressions with root element ogsi:findbyservicedatanames, as per the specification.

14 MS.NETGrid-OGSIDesignOverview-v QueryEngine <<<<property>>>> ServiceDataSet : ServiceDataSet Regi stereva lua tor() ExecuteQuery() 1 0..* IExperssionEvaluator Evaluate() QueryByServiceDataNames SetB yservi ceda ta Names De letebyservi ceda tana mes

15 MS.NETGrid-OGSIDesignOverview-v Limitations The limitations of our design are as follows: Our container does not allow for strongly named assemblies yet. Assemblies must be placed in the bin directory of the container application directory. We have made no explicit allowance for security. Fault handling is not done in a consistent manner. When an exception is thrown, it appears to the client as a SOAPException. We do not yet allow for accurate service description via the?wsdl query string convention. There are limitations relating to: o Service data and service data descriptions. At the moment, the returned WSDL document is the document generated by ASP.NET for the service proxy class. This is pure WSDL1.1 and does not contain information about servicedata o Multiple or aggregated porttypes all operations are aggregated and appear to belong to one porttype which is equivalent to the most-derived porttype which corresponds to a Grid service itself. Only support for the GridService and Factory porttypes are provided. ServiceData and certain operation message XML does not match the OGSI specification exactly. Persistence of service state between container restarts is not supported. Our design does not support arbitrary service names.

16 MS.NETGrid-OGSIDesignOverview-v Glossary For convenience of reference we include the following glossary..net The Microsoft.NET platform, including the.net SDK (Software Development Kit), associated development tools such as Visual Studio.NET [ and the Common Language Runtime. Common Language Runtime a runtime environment that executes Microsoft Intermediate Language (MSIL). MSIL The.NET bytecode, a low-level assembler-like language executed by the Common Language Runtime. Managed code Code that runs on the.net CLR. IIS Microsoft Internet Information Server, a web server offering communication over a variety of internet protocols. ISAPI An Application Programming Interface (API) that allows applications to use the network services provided by IIS. Commonly used to provide HTTP filters that respond to all HTTP requests on the server. AppDomain.NET allows the partitioning of a single Operating System process into a number of AppDomains, which are essentially memory safe areas within the process. If the code in an AppDomain crashes, other AppDomains within the process are unaffected. This concept has some performance advantages as using AppDomains avoids the overheads associated with starting a new process..net Remoting The mechanism by which.net allows Remote Procedure Call (RPC) between AppDomains and between remote machines. ASP Active Server Pages, a Microsoft technology that works in conjunction with IIS to host Web Applications. ASP.NET The.NET version of ASP, with extensions for Web Services and Enterprise Applications. C# - Pronounced C-Sharp, a new Microsoft programming language that takes advantage of.net platform features. Assembly A collection of managed code, which may form an executable or a library, and may be distributed across a number of physical files. Assemblies facilitate the separation of logical and physical resources. OGSA The Open Grid Services Architecture, which is a set of proposed architectures and protocols for Grid computing [Anatomy]. OGSI The Open Grid Services Infrastructure, a specification of behaviours and properties of Grid Services [Physiology, OGSI-Spec]. OGSA-DAI OGSA Data Access and Integration, Grid Services framework for seamless access and integration of data using the OGSA paradigm [OGSA-DAI].

17 MS.NETGrid-OGSIDesignOverview-v Globus The Globus toolkit. A standard toolkit of Grid software. Version 3 will contain an implementation of OGSI in Java [ WSDL The Web Services Description Language [ Web Services Refers to network-enabled software capabilities accessed using common Internet protocols such as HTTP and SOAP and described using WSDL. Grid Services Web Services conforming to the OGSI specification. Grid Service Instance A network accessible instance of an OGSI-compliant service. PortType A set of operations supported by a Web or Grid Service. ServiceData An XML-based mechanism that allows a client to query the state of a service instance in a flexible and extensible manner. ServiceDataElement A particular element of servicedata, identified by a name and a value Tomcat A container for Java-based Web Applications [ AXIS A Web Application running under Tomcat, which provides Web Services functionality. [ Programming Model A set of procedures and APIs used to develop an application in a given domain

18 MS.NETGrid-OGSIDesignOverview-v References Documents referenced in the text, and other related documents, include the following. [MS.NETGrid-Proj-Def] Project Definition for a Collaboration Between Microsoft and EPCC (MS.NetGrid-ProjDef-V2.0), M. Jackson, EPCC, April 25 th [OGSI-Spec] Open Grid Services Infrastructure (Draft 29), S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. Snelling, P. Vanderbilt, April 5th th [Virginia-Impl] OGSI.NET: An OGSI-compliant Hosting Container for the.net Framework, Grid Computing Group, University of Virginia. WWW site: [GTk3] Globus Toolkit version 3 and OGSI, Available at [Physiology] The Physiology of the Grid (Draft 2.9), I. Foster, C. Kesselman, J.Nick, S. Tuecke, Available at [Anatomy] The Anatomy of the Grid, I. Foster, C. Kesselman, S. Tuecke, Available at [OGSA-DAI] Open Grid Service Architecture, Database Access and Integration [WSDL-Spec] Web Services Description Language 1.1, [AXIS] The Apache Axis SOAP Engine,