1 / 58

OGSI on Microsoft .NET

OGSI on Microsoft .NET. Daragh Byrne – EPCC. Purpose. Design Issues High-level Design Programming Model Grid Service Demonstrators. 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

Download Presentation

OGSI on Microsoft .NET

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  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

More Related