Building Large Grids with OGSI.NET: A Guide to Grid Computing in the .NET World

1. OGSI.NET: Building Grids for the .NET World Glenn Wasson Grid Computing Group University of Virginia

2. Building Large Grids • Standards are important • OGSA / OGSI • WS-* • Others? • Grids span many platforms • But typically not Windows

3. Enter .NET • What is .NET? • Runtime (CLR) for many languages • C#, VB, VC++, J#, F#, Perl, Python, Fortran, Cobol, SmallTalk, Pascal, Eiffel, Haskell, Scheme.. • Runtimes for many platforms • Mono runs on Linux, FreeBSD, Solaris, SPARC, PowerPC, StrongArm, and Windows! • Technology for many MS products • ASP.NET, ADO.NET, Web Services

4. .NET’s Relationship to the Grid • Web Services are fundamental building blocks for Grid Services • Easy to build Web Services with MS tools • Infrastructure can be used for Grid Services • Pervasiveness of .NET capable machines • Including handhelds

5. Talk Outline • Introduction of OGSI.NET • Container Operation • Message Flow • Security • Programming Model • Application / Research using OGSI.NET • Future Work

6. OGSI.NET • OGSI-compliant hosting environment • Goals: • Bring OGSI-compliant grid services to .NET & Windows world • Expose MS technology to “the grid” • e.g. ADO.NET

7. OGSI.NET is… • A hosting environment • Container that holds service instances Dispatcher that routes messages to them • Libraries • OGSI port types, Service base class • Attribute-based programming model • Meta-data added to service logic

8. The OGSI.NET Container

9. OGSI.NET Container • Container divided into separate Application Domains (AppDom’s) • Process-style memory protection w/o process • Each service instance has its own AppDom • 1 additional AppDom contains Dispatcher • Dispatcher • Knows how to route requests to services

10. OGSI.NET Container • Each service’s AppDom contains a Grid Service Wrapper (GSW) • GSW provides • Message handlers for serializing/deserializing various message types • Routing requests to methods of service’s port types • SDE storage/retrieval • WSE pipeline • Basically encapsulates service logic with helper code

11. OGSI.NET Request Flow • Client sends request message “to service” • Assume SOAP/HTTP for the moment • IIS receives HTTP request • If begins with container prefix, sends it to ISAPI filter • ISAPI filter “rewrites” request to dispatch into ASP.NET • allows arbitrary service names

12. OGSI.NET Request Flow • ASP.NET HttpHandler sends request to container process • Request received by Dispatcher • Dispatcher routes request into service instance’s AppDom • Service’s GSW selects appropriate message handler

13. OGSI.NET Request Flow • Message Handler processes request • Runs WSE pipeline (examine msg headers) • Deserializes data items • GSW marshals data items and calls requested method • Result sent to message handler for serialization • Could be return values or exceptions • Result message follows reverse path

14. OGSI.NET Security • Web Service Extensions (WSE) pipeline in each AppDom • Digital Signing and Encryption • X509, Kerberos and WindowsIdentity tokens • WS-SecurityPolicy • more later…

15. Programming Grid Services • Goal: Make it as easy as Web Services • Difference between a “Grid Service” and “service logic” is meta-data • Defines how methods and data are exposed • Conditions of exposure (policy) • Programmers annotate their code • C# attributes (can get at runtime) • Other languages (need pre-processing)

16. OGSI.NET Attribute-based Programming • [OGSIPortType] [OGSIPortType(typeof(FactoryPortType))] [OGSIPortType(typeof(NotificationSourcePortType))] [OGSIPortType(typeof(GridServicePortType))] public class FactoryService : GridServiceSkeleton { • [SoapDocumentMethod] [WebMethod] [SoapDocumentMethod("http://gcg.virginia.edu/samples/ counter#subtract", Binding="CounterSOAPBinding")] [return: XmlElement("returnValue")] public int subtract(int value) {

17. Exposing Service Data • [SDE] [SDE ("interface", typeof(XmlQualifiedName), false, MutabilityType.constant, false, "1", "unbounded")] public class GridServicePortType : GridServiceSkeleton {

18. Exposing Service Data • Get and Set handlers for SDEs [SDEGet(“currentTime”)] public ArrayList getTime(OGSIServiceData sde, GridServiceWrapper gsw) { • Member variables as SDEs public class SomeServicePortType : GridServiceSkeleton { SomeServicePortType() { … } [SDE] public int foo;

19. Specifying Service Policy • Initially security policy [Integrity(“require”, “body”, “token1, token2”)] [Confidentiality(“reject”, “header1”, “token3”)] [Message(“require”, “age<30”)] [Token(“token1”, “x509v3”, “subject=Bob Smith, CA=UVA”)] [Token(“token2”, “Kerberosv5ST”)] [Token(“token3”, “SecurityContextToken”, “issuer=http://token.virginia.edu/ mytoken”)] public class Service1 : GridServiceSkeleton { • Other types of policy…

20. Issues in Building an OGSI-Compliant Container • Processing GWSDL (de/serialization) • Wsdl.exe and xsd.exe don’t correctly process the OGSI v1.0 WSDL and data types • Somewhat broken even for WSDL 1.1… • C# doesn’t have faults in its function signature • So you can’t just reflect on the method (attributes needed) • Inter-op with GT3 • OGSI spec compliance not enough • Need similar service semantics • Microsoft’s envisioned usage pattern for tools

21. Grid Services: Heavy or Light? • Not one service per process • Thread pool for the container • Let OS sort it out • Light-weight services • Services without full container under them • More than one service per AppDom • Notification sinks

22. UVa OGSI.NET NAMD Testbed

23. Research with OGSI.NET • Role of hand-held devices in the grid • .NET CF → Grid Services on PocketPC • OGSI.NET clients exist, server-side is future • Policy for Grids • What policies might be particular to grids? • Survivability policy! • Not writing a new policy specification language (i.e. use WS-Policy or other)

24. Future Work • What is next for OGSI? • WSDL 1.2? • Improve service programming model • Policy for grid services • More interesting security work • Services on the device • Globus protocols/GGF standards? • OGSA compliance?