OGSI.NET: Building
Grids for the .NET World
Glenn Wasson
Grid Computing Group
University of Virginia
Building Large Grids
► Standards
ƒ
ƒ
ƒ
are important
OGSA / OGSI
WS-*
Others?
► Grids
span many platforms
ƒ But typically not Windows
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
.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
Talk Outline
► Introduction
of OGSI.NET
► Container Operation
► Message Flow
► Security
► Programming Model
► Application / Research using OGSI.NET
► Future Work
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
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
The OGSI.NET Container
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
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
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
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
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
OGSI.NET Security
► Web
Service Extensions (WSE) pipeline in
each AppDom
► Digital
Signing and Encryption
ƒ X509, Kerberos and WindowsIdentity tokens
► WS-SecurityPolicy
ƒ more later…
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)
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)
{
Exposing Service Data
► [SDE]
[SDE ("interface",
typeof(XmlQualifiedName), false,
MutabilityType.constant, false,
"1", "unbounded")]
public class GridServicePortType : GridServiceSkeleton
{
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;
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…
Issues in Building an OGSICompliant 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
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
UVa OGSI.NET NAMD Testbed
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)
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?