Open Grid Forum

Standards Home

Why Standards?
Developing Standards

Using OGF Standards
Areas and Groups OGF Document Series


OGSA Primer Summary
This page is excerpted from the original page, OGSA Primer.

Overview material



OGSA is a classic middleware architecture designed to fit within a traditional three layer distributed systems model with an access layer, a services layer, and a resources layer.

The access layer provides a means for users to interact with the grid, whether it is via a special-purpose-built application, a Web portal or gateway, a set of APIs, or via integration into the local host operating system.

The services layer provides a standard set of interfaces that implementers of the access layer can depend on, and realize what Notkin termed a “layer of virtual homogeneity�. This is the heart of OGSA – and indeed OGF, specifications and profiles.

The resources or provisioning layer provides the physical or virtual resources that are being manipulated, whether they are computing systems, flat files, relational databases, or virtual organizations. Different vendors or implementers may provide different implementations of the grid services that map to their particular resources.

http://www.ogf.org/OGSA_Primer/three-layer.jpg

GFD.80 The Open Grid Services Architecture, Version 1.5 Obsoletes GFD.30 INFO I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich 2006-09-05

GFD.120 Open Grid Services Architecture® Glossary of Terms Version 1.6 Obsoletes GFD.81 INFO J. Treadwell 2007-12-12.

GFD.141 Independent Software Vendors (ISV) Remote Computing Usage Primer INFO S. Newhouse, A. Grimshaw 2008-10-07. This document describes in detail how OGF specifications can be used to implement high throughput computing use cases. The target auidience is independent software vendors who want to exploit grid resources in their products.

Infrastructure

Infrastructure services are a set of common functionalities required by higher-level services. As OGSA builds on Web services technologies, the Web Services Description Language defines service interfaces. Infrastructure includes standards such as Web Services Resource Framework (WS-RF), WS-Management, and WS-Addressing.

Infrastructure services are concerned with resource naming, communication, and reflection. In OGSA, a resource is a physical or logical entity that supports the use or operation of a computing application or environment. Resources are often stateful and provide a capability or capacity such as servers, networks, memory, applications, and databases. Resources might also handle dynamic entities, such as processes, print jobs, database query results, and virtual organizations.

Naming. Suppose there are two resources, A and B, and that A wishes to interact with B. How does A refer to B? OGSA defines a multilayer naming scheme of addresses, identities, and pathnames.

OGSA uses the WS-Addressing specification for addressing. This specification defines an XML data structure called the end point reference (EPR) that encapsulates the information the client needs to message a service. The EPR includes a network protocol and address, an extensible metadata section to convey information such as security policy, and an opaque section for session/resource identifiers.

The Open Grid Forum’s (OGF’s) WS-Naming Specification specification profiles WS-Addressing to provide identities and name rebinding. An optional EPR metadata element called end point identifier (EPI) is a URI that is unique in space and time. Clients can compare the EPIs contained in two or more EPRs. If the EPIs are the same, the EPRs are said to point to the same entity. The semantics of the underlying service determine sameness. If the EPIs are different, nothing can be inferred.

Name rebinding is the ability to get a new EPR if communication with a web service pointed to by the old EPR fails, for example if the host the web service was running on has failed or become disconnected from the network. The rebinding aspects of WS-Naming EPRs facilitate the implementation of the traditional distributed system transparencies: migration, failure, replication, and so forth. Embedded in an EPR’s metadata element is an optional resolver EPR. A client can call the resolver EPR to acquire a new EPR for the service. For example, suppose there is a client C and service EPR S that contains a resolver EPR R. Suppose S fails or migrates. Subsequent invocations of S by C will fault because S has moved or failed. C can then invoke the resolution function to acquire a new EPR for S, S', that is, S' = S.R.resolve(). This capability is critical for reaching our reliability, availability, and performance objectives.

Reflection and metadata. Reflection here refers to the ability to discover properties or attributes of grid resources or services, for example, the port-types, security mechanisms, and the provenance of data. Examples in use include WSRF-RP 88 and WS-Metadata Exchange. The OGSA WS-RF Base Profile addresses selected WSRF-RP specifications including the operation getResourceProperties, which returns an XML document with the metadata associated with a resource.

GFD.109 WS-Naming Specification P-REC A. Grimshaw, D. Snelling 2007-07-03

GFD.101 Resource Namespace Service Specification P-REC M. Pereira, O. Tatebe, L. Luan, T. Anderson 2007-05-03

WS-RF

WS-Notification

WS-Eventing

Execution Management

Execution management is concerned with describing, starting, and managing the execution of jobs. This is one of the most active areas of OGF work, and OGSA work in particular.

GFD.136 Job Submission Description Language (JSDL) Specification v1.0 P-REC A. Anjomshoaa, F. Brisard, M. Drescher, D. Fellows, A. Ly, S. McGough, D. Pulsipher, A. Savva 2008-07-28 JSDL documents are XML documents that describe a job: the resource requirements such as memory, number and type of CPUs, supported libraries, etc.; the input and output files, where they can be found, file access protocols to be used when staging data in and out; and the parameters to be passed to the application. If the application is not installed for a particular execution environment it must first be installed. Often this is accomplished by staging-in the application as well as the input data files. JSDL files are given to execution services to execute the described job.

GFD.108 OGSA® Basic Execution Service Version 1.0 REC I. Foster, A. Grimshaw, P. Lane, W. Lee, M. Morgan, S. Newhouse, S. Pickles, D. Pulsipher, C. Smith, M. Theimer 2007-08- OGSA-BES is a simple interface for creating new jobs, monitoring them, and managing their lifetime in addition to providing information useful for making scheduling decisions. On top of the JSDL and OGSA-BES specifications the HPC Profile Group inside the OGF has defined a number of specifications and profiles on existing specifications which further aide in interoperability.

D.115 JSDL SPMD Application Extension, Version 1.0 P-REC A. Savva 2007-08-28

GFD.114 HPC Basic Profile, Version 1.0 REC B. Dillaway, M. Humphrey, C. Smith, M. Theimer, G. Wasson 2007-08-28 HPC-BP defines a simplified Application element which can be used inside of JSDL documents to more easily annotate how a sequential application should be run (what the executable is called, what the arguments are for the command line, etc.).

GFD.124 Interoperability Experiences with the High Performance Computing Basic Profile (HPCBP), Version 1.0 EXP G. Wasson 2008-02-21

GFD.135 HPC File Staging Profile, Version 1.0 P-REC G. Wasson, M. Humphrey 2008-06-28

GFD.98 Usage Record - Format Recommendation P-REC R. Mach, R. Lepro-Metz, S. Jackson, L. McGinnis 2007-02-22

Data Management

GFD.121 OGSA® Data Architecture INFO D. Berry, A. Luniewski, M. Antonioletti 2007-12-05

GFD.88 ByteIO OGSA® WSRF Basic Profile Rendering 1.0 P-REC M. Morgan 2007-01-12 GFD.87 ByteIO Specification 1.0 P-REC M. Morgan 2007-01-12

GFD.77 Interoperability Testing for DAIS Working Group Specifications INFO S. Lynden, N. Paton, D. Pearson 2006-09-05

GFD.76 Web Services Data Access and Integration - The Relational Realisation (WS-DAIR) Specification, Version 1.0 P-REC M. Antonioletti, B. Collins, A. Krause, S. Laws, J. Magowan, S. Malaika, N. Paton 2006-09-05

GFD.75 Web Services Data Access and Integration - The XML Realization (WS-DAIX) Specification, Version 1.0 P-REC M. Antonioletti, S. Hastings, A. Krause, S. Langella, S. Lynden, S. Laws, S. Malaika, N. Paton 2006-09-05

GFD.74 Web Services Data Access and Integration - The Core (WS-DAI) Specification, Version 1.0 P-REC M. Antonioletti, M. Atkinson, A. Krause, S. Laws, S. Malaika, N. Paton, D. Pearson, G. Riccardi 2006-09-05

Security

The security of grid infrastructure rests on its ability to protect its assets (information, data, services, etc) from various sources of misuse. Following the Open Systems Interconnect threat model, the types of security threat to which networked resources are vulnerable include disclosure or theft of resources, modification (including destruction) of resources, and resource service interruption. The purpose of a grid security architecture is to define the security services and related mechanisms that can be appropriately applied to mitigate such threats. The goal of these services and mechanisms is to make the costs of unauthorized behavior greater than the potential value of doing so. Without a strong commitment to meaningful security, many potential adopters would be unable to participate because of undue risk and/or legal restrictions.

Grid security architecture is complicated by the reality that participants from different administrative domains will “come to the table� with distinct trust and security infrastructures. This presents challenges for interoperability, even if all resource interfaces and security mechanisms are well-specified by de facto community standards. For example, although the service implementations of a particular application (e.g., a job execution service) may conform to the same interface, each provider is free to choose the security mechanisms that satisfy its particular security requirements. The orthogonality between service interface and security has two important implications: security tokens from one domain may not carry any syntactic or semantic meaning within another, and different peers may require different compositions of secure communication mechanisms (e.g., specific encryption or signature actions).

With site autonomy in mind, OGSA-basedarchitectures are designed with a flexible security architecture in order to support the integration of existing trust infrastructures rather than force users to adopt a new, singular security model. Genesis II provides services and mechanisms to federate and broker existing identity, to provide suitable forms of new identity as necessary, and to configure and discover the secure communication requirements of communicating peers. This is fundamental to realizing the vision of resource sharing in an environment lacking a single source of authority.

WS I Basic Security Profile

WS-Trust

WS-Security

WS-SecurityPolicy

WS-SecureConversation

WS-Secure Addressing Profile

Security Assertion Markup Language (SAML)

eXtensible Access Control Markup Language (XACML)






> login   RSS RSS Contact Webmaster

OGFSM, Open Grid ForumSM, Grid ForumSM, and the OGF Logo are trademarks of OGF