OGSI on Microsoft .NET

1. 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-related • 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 OgsiContainerclass • Transient created by factory services: • Client-managed services • Service names (Grid Service Handles): • http://localhost/ogsa/services/persistent/Foo.asmx - persistent • http://localhost/ogsa/services/transient/Bar.asmx?instanceId=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. Client-Service Interaction (1/2) 8. C# method return C# Implementation 1. C# method call 7. SOAP response 2. SOAP request 6. Operation Return 4. Grid Service Object Reference 3. Grid Service ID 5. Operation Call C# Implementation Client Proxy HTTP ASP.NET Web Service Proxy (.asmx) OGSI Container Grid Service Grid Service Grid Service

15. Client-Service Interaction (2/2)

16. Operation Call on Transient Service

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

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 • PersistentGridServiceSkeletonfor 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 ServiceParametersHashtable • 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 IPortTypeProviderinstances 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), “http://mydomain.com/NameSpace”, “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 • PortTypeBasegives useful implementation of IPortTypeProvider: • With emptyInitialisemethod 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. PortTypeBaseFeatures • 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 OgsiPortTypeattribute • 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 propertySetValues(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.cspublic 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.cspublic 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: <%@ WebService Class=“HelloService"%>

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 SOAPRpcMethodAttributeon 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: <gridServiceDeploymentDescriptorasmxFileName=“HelloService.asmx”serviceClass=“HelloServiceImpl”assembly=“HelloAssembly”persistence=“persistent”><serviceParameter name=“key” value=“value”/> </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. Factory Services • Used to create service instances representing resources • Client locates factory • Creates service instance • Uses service instance • E.g. Grid Data Service