MS.NETGrid OGSI Implementation Design
Overview
Project Title:
MS.NETGrid
Document Title:
MS.NETGrid OGSI Implementation Design Overview
Document Identifier: MS.NETGrid-OGSIDesignOverview-v1.0
Authorship:
Daragh
Byrne
Document History:
Personnel Date Summary Version
EPCC 16th June 2003 EPCC Approved. 1.0
DB 4th June 2003 First Draft. 0.1
DB 13th 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
Contents
Contents... 2 1 Introduction ... 3 2 Design Goals ... 4 3 Design Outline ... 5 3.1 High-level Architecture ... 5 3.2 Service Lifetime... 5 3.3 Maintaining State... 53.4 OGSI Service Container... 7
3.5 Proxy Classes – Example... 8
3.6 Configuration and Service Deployment... 9
3.7 GridServiceSkeleton ... 10 3.8 Factory PortType ... 11 3.9 ServiceData... 12 4 Limitations ... 15 5 Glossary... 16 References ... 18
1 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 (http://www.epcc.ed.ac.uk/~ogsanet). 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.
2 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.
3 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
SOAP Response to client
Service Skeleton Instance
PortType
GridServiceInstanceAspProxy
Request handled by ASP.NET Web Service Selects Service Instance Calls method on Instance
ASP.NET Web Application
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.
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:
client
SOAP Request (Web Service Proxy) Return Result
Service Instance Method Call (Grid Service Instance)
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 http://some_server/Ogsi.Container/services/persistent/CounterServiceFactory.asmx. 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.
ServiceInstanceMapImpl
objectMapHashTable_ : System.Collections.Hashtable GridServiceInstanceRegistry 0 2
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 http://some_server/Ogsi.Container/services/transient/CounterService.asmx. We differentiate between different counter service instances by the use of an instanceId parameter in the queryString of the URL. So:
http://some_service/Ogsi.Container/services/transient/CounterService.asmx?instanceId=insta nce1
and
http://some_service/Ogsi.Container/services/transient/CounterService.asmx?instanceId=insta 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
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
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.
G ri d S e rv i c e I n st a n c e A sp P ro x y se rv i c e I n st a n c e _ : G ri d S e rv i c e S ke l e t o n C a l l M e t h o d () < < v i rt u a l > > I n i t i a l i z e S e rv i c e O b j e c t () G ri d S e rv i c e I n st a n c e P ro x y () C a l l M e t h o d O n P ro v i d e r() < < W e b M e t h o d > > f i n d S e rv i c e D a t a () < < W e b M e t h o d > > re q u e st T e rm i n a t i o n B e f o re () < < W e b M e t h o d > > re q u e st T e rm i n a t i o n A f t e r() < < W e b M e t h o d > > d e st ro y () < < a b st ra c t > > T ra n si e n t G ri d S e rv i c e I n st a n c e A sp P ro x y P e rsi st e n t G ri d S e rv ic e In st a n c e A sp P ro x y
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_; }
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 3.7.
3.6 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. In-line 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.Configuration-provided 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.
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.
GridServiceDeploym entD escriptor
virtualPath_ : string cl assNam e_ : stri ng nam eSpace_ : string isPersistent_ : boolean Cont ainerCon fig
GetListOfP roxyM appings() GetContainerP roperty() 1 * Deploym entDescript o rS ec ti onH andler 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.
G ri d S e rvice S ke le to n
se rvi ceDa ta S e t_ : IS e rvi ce Da ta S e t qu e ryE n g in e _ : IQ u e ryE n g in e <<p ro p e rty>> T e rm i n a ti o n T im e <<p ro p e rty>> S e rvice P a ra m e te rs <<p ro p e rty>> IsDe stro ye d Ca llS ervice M e th o d()
P e rsiste n tG rid S e rvi ce S ke le to n
O g siP or tT yp e At tri b ute O p e ra tio n P ro vi d e rB a se
<<p ro p e r ty>> S e rv ice I n st a n ce = G ri d S e rv ice S ke le t o n
0..*
1 1
0..*
IO p e ra ti o nP ro vid e r
<<p ro p e rty>> S e rvi ce In sta n ce : G rid S e rvi ce S ke le to n
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>
F a ct o ry P o rt T y p e C re a t e S e rv i c e (c re a t i o n P a ra m s : C re a t i o n T y p e ) O p e ra t i o n P r o v i d e rB a s e < < p r o p e r ty >> S e r vi ce I n st a n c e = G ri d S e r vi c e S k e le to n IF a c t o ry C re a to r C re a t e S e rv i c e O b je c t (X m l E l e m e n t p a ra m s, G ri d S e r vi ce S k e l e to n f a c t o ry ) 1 1
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:
ServiceDataSet
servi ce Data Entries_ : Hasht ab le
ServiceDat a name_ : QName callback_ : IServiceDataValuesCallback values_ : Object[] 1 * IServiceDataValuesCallback
<<<<p ro perty>>>> Servi ceDa ta Valu es : Obj ect[ ]
1
0..1
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.
QueryEngine
<<<< property>>>> Se rvice DataSet : ServiceDat aSe t Regi st erEva lua tor()
ExecuteQuery()
IExperssionEvaluator Evaluate()
QueryByServiceDataNames SetB yServi ceDa ta Names De leteByServi ceDa taNa mes
1
4 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.
5 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 [http://www.microsoft.com/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].
Globus – The Globus toolkit. A standard toolkit of Grid software. Version 3 will contain an implementation of OGSI in Java [http://www.globus.org]..
WSDL – The Web Services Description Language [http://www.w3.org/TR/wsdl].
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 [http://jakarta.apache.org].
AXIS – A Web Application running under Tomcat, which provides Web Services functionality. [http://xml.apache.org].
Programming Model – A set of procedures and APIs used to develop an application in a given domain
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 25th 2003.
[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 5thth 2003. http://www.gridforum.org/ogsi-wg.
[Virginia-Impl] – OGSI.NET: An OGSI-compliant Hosting Container for the .NET Framework, Grid Computing Group, University of Virginia. WWW site: http://www.cs.virginia.edu/~humphrey/GCG/ogsi.net.html.
[GTk3] – Globus Toolkit version 3 and OGSI, Available at http://www.globus.org/ogsa [Physiology] – The Physiology of the Grid (Draft 2.9), I. Foster, C. Kesselman, J.Nick, S. Tuecke, Available at http://www.gridforum.org.org/ogsa-wg
[Anatomy] – The Anatomy of the Grid, I. Foster, C. Kesselman, S. Tuecke, Available at http://www.gridforum.org/ogsa-wg
[OGSA-DAI] – Open Grid Service Architecture, Database Access and Integration http://www.ogsadai.org.uk
[WSDL-Spec] Web Services Description Language 1.1, http://www.w3.org/TR/2001/NOTE-wsdl-20010315