January 14 th -15 th 2004 OGSI on Microsoft.NET Daragh Byrne – EPCC

2 Purpose  Design Issues  High-level Design  Programming Model  Grid Service Demonstrators

3 OGSI on.NET: Why Bother?  Grid is platform agnostic: –So is OGSI –Should have implementations on all platforms for participation: To help OGSI take off .NET rapidly becoming an important platform: –Microsoft pushing heavily => ubiquitous –Many attractive features for development –Emphasis on Web Services  Good test of.NET features  Challenge!

4 MS.NETGrid-OGSI

5 Design Issues  How do we convert stateless Web Services to stateful Grid Services?  How do factories work?  How do we manage service lifetime? –The destroy, requestTerminationX operations of the GridService portType  What should the client- and server-side programming models look like?  What’s the quickest way of doing this? What can we leverage?

6 Container Design (1/2)  Use IIS/ASP.NET: –Facilitate speed of development: Get Web Services stuff (SOAP, WSDL) for free –Industry-standard Web Services programming model –Maintain integration with existing technology –Pre-existing knowledge of our developers  Utilise.NET class library: –Rich framework for XML programming, serialization etc  Use an object instance to represent a service instance: –Creating service object and loading state every request too costly performance-wise –State loading is complex to implement –Possible threading and persistence issues

7 Container Design (2/2)  Leverage existing work: –Globus Toolkit 3.0 –Virginia OGSI.NET  Carry out design using lessons learned during these projects –Maintain programming model that is familiar to users of these pieces of software

8 Design Omissions  No rich client-side support: –Web Services model used –No GWSDL –Operates fine as Grid Services ARE Web Services!  GSH/GSR support limited –Handles act as references –No virtualisation  Subset of OGSI portTypes implemented: –GridService, Factory Notification in next release  Security: –Although can secure using ASP.NET Web Services Security  No GWSDL support

9 Grid Service Container  Runs as ASP.NET Web Application: –IIS,.NET Framework, all Windows platforms where these are available: Tested on Win2K, XP, Server 2003  Base classes for service developers: –Core portType functionality –ServiceData –Attribute based programming model  No need to worry about behind the scenes: –But better to know!

10 Service Lifetime  Persistent started when container starts: –Server-managed services –Necessary for factories, permanent services –Initialised by OgsiContainer class  Transient created by factory services: –Client-managed services  Service names (Grid Service Handles): – - persistent – someString - transient

11 Client-side View  Client interacts as if it were communicating with a Web Service  Uses normal client-side proxy: –Auto-generated from WSDL in normal manner (using wsdl.exe )  Communicates with server-side Web Service Proxy  Sees the most-derived portType of the service  Makes sense: A Grid Service is a Web Service

12 Grid Service Components  Server Side Proxy –An ASP.NET Web Service –Exposes service operations via ASP.NET  Service portType implementations  Service Skeleton –Reference class from which portType implementations “hang”  MS.NETGrid Web Application connects these components transparently

13 Service Proxy Model  Service proxy is plain Web Service: –Maps stateless Web Service object to stateful Grid Service object –Modified ASP.NET Web Service – new base class –One proxy type corresponds to one or more service instances –Instance of proxy created for each request to the.asmx file –Uses URL information to look up correct service instance on creation –Uses reflection to invoke the service method on that instance –WebMethod attributes on service operations  Why this model? –Get a lot of things for free: SOAP communication, service description (WSDL) Like ASP.NET so familiar.NET programming model –Potential for auto-generation of proxies; contain boiler-plate code

14 C# Implementation ASP.NET Client-Service Interaction (1/2) C# Implementation Client Proxy 8. C# method return 1. C# method call HTTP 2. SOAP request 7. SOAP response OGSI Container Grid Service Web Service Proxy (.asmx) 4. Grid Service Object Reference 3. Grid Service ID 5. Operation Call 6. Operation Return

15 Client-Service Interaction (2/2)

16 Operation Call on Transient Service

17 Component Relationships SomeGridService.asmx SomeGridServiceProxy ServiceDataSet SomeGridService SomePortTypeProviderSomeOtherPortTypeProvider compiled into delegates to Service Implementation

18 UoV OGSI.NET  Differences –Services hosted in dedicated Windows service process rather than IIS –Each service hosted in its own Application Domain for extra security and reliability –Supports flexible messaging processing  Similarities –Similar attribute-based programming models –Both aim for interoperability with Globus 3

19 Programming Model

20 Service Development 1. Development of implementation classes: –Core service logic 2. Development of Web Service proxy: –Provides communication capabilities on server side –Exposes the most-derived portType of the service 3. Deployment: –Use ASP.NET standard configuration file to link proxy and implementation information

21 Service Functionality  Service is defined by the portType(s) it implements  First step in service development is to define the interface for your service: –What portTypes it implements –The semantics of the portTypes –No need to write formal description (WSDL) as this will be auto- generated from the proxy implementation by ASP.NET: Contrast with Globus 3.0

22 Programming Model 1.Service Implementation class(es): –GridServiceSkeleton -derived –PersistentGridServiceSkeleton -derived for persistent services –Use PortType Providers to represent portTypes 2. Proxy class: –Inherits from GridServiceInstanceAspProxy (which derives from System.Web.Services.WebService ) –Communications layer –Represents most-derived portType –Can aggregate portTypes but hidden behind most-derived 3. Deployment descriptor: –Web.config (ASP.NET configuration file)

23 Programming Process 1. Write service implementation classes: –Service base class (responsible for storing state) –Any helper classes, integration classes etc 2. Write proxy: –These can be generated from tooling – when tooling exists! –Simple in structure (boiler-plate code) 3. Deploy service: –Edit an XML file ( Web.config )

24 Implementing the Service Functionality

25 Developing a Service Implementation  Inherit from: –GridServiceSkeleton –OR –PersistentGridServiceSkeleton for persistent services  Hello Service: public class MyHelloServiceImpl : PersistentGridServiceSkeleton { }

26 GridServiceSkeleton (1/2)  Implements GridService portType functionality: –findServiceData, setServiceData, requestTerminationBefore, requestTerminationAfter, destroy  InstanceServiceDataSet property: –ServiceDataSet for the live running service instance –Use the ServiceDataSet, ServiceData APIs to manipulate this  ServiceParameters property: –General purpose Hashtable –Loaded with configuration data from configuration file when service is initialised  PortTypeProviders –Hashtable containing references to implementations of portTypes

27 GridServiceSkeleton (2/2)  PostCreate method: public abstract class GridServiceSkeleton { public virtual void PostCreate() { } }  Can be used for resource acquisition, serviceData initialisation, other initialisation: –Called by the container or factory when service instance is created –Store useful items in ServiceParameters Hashtable  Only for things used by all portTypes of a service

28 Implementing PortType Operations  Option 1: Implement operations on GridServiceSkeleton -derived class directly: –Recommended when only one portType is required –Quick, convenient but not very modular –You did this with the first Grid Service you wrote  Option 2: Use IPortTypeProvider implementations: –Modularise portType implementations –Allows use of OgsiPortType attributes: Associate the operation provider with a service class –Runtime can map requests to IPortTypeProvider instances via the PortTypeProvider property of GridServiceSkeleton

29 HelloPortType – Option 1 public class MyHelloServiceImpl : PersistentGridServiceSkeleton { int i = 0; // sayHello is an operation on some portType public string sayHello(string name) { return “Hello, “ + name + “ “ + (++i); } }

30 HelloPortType – Option 2 public class HelloPortType : PortTypeBase { int i = 0; public string sayHello(string name) { return “Hello, “ + name + “ “ + (++i); } public override void Initialise() { } }... // declare service, attach portType using attribute [OgsiPortType(typeof(HelloPortType), “ “HelloPortType”] public class HelloServiceImpl : GridServiceSkeleton { }

31 Option 2  IPortTypeProvider.cs public interface IPortTypeProvider { GridServiceSkeleton ServiceInstance { get; set; } void Initialise(); }  Provides: –Access to service instance –Custom initialisation code: Use Initialise() instead of PostCreate() when using portType providers –Attach to service with OgsiPortTypeAttribute –PortTypeBase gives useful implementation of IPortTypeProvider: With empty Initialise method for overriding Used in cases where portType does not need to inherit from base class

32 How PortType Providers Work  Attributes and reflection!  On instantiation of GridServiceSkeleton : –Reflects upon itself to get its own OgsiPortType attribute collection –Uses the information in this collection’s members to instantiate operation provider implementations: From the ProviderType property of OgsiPortType attribute (gives the type of the IPortTypeProvider implementation) –Stores instances in PortTypeProviders Hashtable –Methods can then be called on these instances

33 PortTypeProviders and GridServiceSkeletons

34 PortTypeBase Features  Can do initialisation using the Initialise method of IPortTypeProvider /PortTypeBase: –E.g. add portType specific serviceData to the serviceData set on ServiceInstance –Called by GridServiceSkeleton after provider is instantiated  Clean programming model: –Attributes are a very.NET way of doing things –Can add existing operation providers to new services easily and cleanly using OgsiPortType attribute –Potentially used by tooling when generating proxies/documentation

35 Cleanup  GridServiceSkeleton.OnDispose()  PortTypeBase.OnDispose() –Called by container when service is destroyed –Use to free any resources e.g. File handles, Database connections

36 Break 10 minutes – Any questions?

37 Working with ServiceData  A serviceData element is named like any XML element (namespace, elementName)  A serviceData element is represented by an instance of the Ogsi.ServiceData.ServiceData type  ServiceDataSet type represents the entire collection of serviceData for a service instance –GridServiceSkeleton.InstanceServiceData

38 ServiceData API  ServiceDataSet : Create(XmlQualifiedName name); Add(ServiceData data); Contains(XmlQualifiedName name); Delete(XmlQualifiedName name);  ServiceData : –Contains System.Object(s): GetValues() Value property SetValues(object [ ]) Callback property for dynamic generation: Use instances of IServiceDataValuesCallback Service Data exposes state, not necessarily holds it!

39 Using ServiceData APIs  Obtain reference to the instance’s ServiceDataSet: –On portType: this.ServiceInstance.InstanceServiceDataSet –On GridServiceSkeleton e.g. in PostCreate() this.InstanceServiceDataSet –Use this to create and add new SDEs

40 Implementing the Service Proxy

41 Service Proxies  Implementation needs an interface to clients: –GridServiceSkeleton, operation providers no good on their own: They are just objects –Need way to speak to the world  GridServiceInstanceAspProxy: –Based on the System.Web.Services.WebService class used by ASP.NET –Provides means for ASP.NET to call out to implementations

42 Inheritance Model // HelloService.cs public class HelloService : PersistentGridServiceInstanceAspProxy { [WebMethod] // Any other ASP.NET attributes public string SayHello(string name) { object [] args = { name }; return (string) CallMethod(“SayHello”, args); } } –GridServiceInstanceAspProxy constructor gives reference to service instance object via container –CallMethod invokes on service instance object

43 PortType Provider Model // HelloService.cs public class HelloService : PersistentGridServiceInstanceAspProxy { [WebMethod] // Any other ASP.NET attributes public string SayHello(string name) { object [] args = { name }; return (string) CallMethodOnPortType(“Type.Of.Provider”, “SayHello”, args); } }

44 Completing the Proxy  Write proxy class  Write.asmx file: –References proxy type:

45 Annotating the Proxy  Can add namespace and calling style information using ASP.NET attributes  e.g. can specify SOAP message encoding styles (RPC, Document) using SOAPDocumentMethodAttribute or SOAPRpcMethodAttribute on WebMethods of the proxy class  Can add default namespace information to service by using WebService attribute on proxy class  Fine-grained control of communication possible in this way

46 Deploying the Service

47 Deployment Descriptors  In Web.config : –gridContainer.config/gridServiceDeployment element –Add gridServiceDeploymentDescriptor :  Specifies: –“ serviceClassName ” attribute: service skeleton class –“ assembly ”: service and proxy assembly –“ asmxFileName ”:.asmx file for proxy –“ persistence ”: transient or persistent

48 Working with Service Parameters in Code  Can access in, e.g. Initialise() method of portTypes public void Initialise() { this.someLocalVariable = Convert.ToInt32( this.ServiceInstance.ServiceParameters[“myParam”] ); }

49 Final Deployment  Copy assembly to bin/ directory of Web application  Copy.asmx file to: –services/persistent directory –services/transient for transient service  Proxy generation and deployment can be automated: –Use reflection on service class –Haven’t done this yet

50 Grid Service Demonstrators

51 Demonstrators  Available with the source distribution: –Examples to help you  Basic GridService: –Implements GridService portType –Persistent and transient services available, with factory  Counter Service: –Implements simple count functionality –Has own graphical client –Demonstrates the use of serviceData and factory by client –Let’s examine some of the source

52 OGSA-DAI  OGSA-DAI – Grid Data Service SQL Server Client GDS-Perform GDS-Response

53 Interoperability  Standards based, so in theory good –Have demonstrated.NET clients talking to Java (Globus) servers –Have demonstrated Java clients talking to our.NET server –Worth further work and not guaranteed problem free by the current implementation