Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Api

Api

ProtoGENI API

ProtoGENI API

Although the architecture of ProtoGENI is subject to change, and its implementation is continually undergoing work, we are attempting to define a temporarily stable API to allow the entire federation to test interoperability of independent components. This document describes our intentions for the interface of ProtoGENI as of Software Integration Release 1: it incorporates features designed based on our experience in GENI Spiral One, and will serve as the starting point for our Spiral Two work.

Please note that broad familiarity with GENI control framework architecture in general and how ProtoGENI implements it are essential prerequisites to understanding this information.

Important concepts

Much of the operation of the control framework is carried out by the exchange of specialised data objects. The following pages describe the utility of these objects as well as defining their representations:

  • Certificates are the fundamental mechanism used to establish ProtoGENI's public key infrastructure.
  • Credentials are the means by which proof of privileges are conveyed.
  • Privileges are tightly coupled to individual site policies (so not rigidly controlled by this API), but we have documented our reference implementation policy to serve as an example.
  • The rspec is a data interchange format specifying detailed properties of networked resources. It is used in four major contexts: advertisements, requests, tickets, and manifests.
  • All ProtoGENI objects are named by URNs which obey a number of conventions proposed by the GMOC for GENI identifiers.
  • Each ProtoGENI service is invoked via XMLRPC.

Services

The set of permissible operations on the control framework is described in terms of individual XMLRPC calls, broken up into four categories based on the type of authority providing the service.

  • The clearing house behaves as a central registry co-ordinating the (otherwise loosely coupled) federation.
  • Each component manager is responsible for the allocation, operation and control of one or more networked components. (We generally attempt to treat aggregate managers and component managers interchangably, and point out differences only when the distinction is important.)
  • Slice authorities provide the infrastructure necessary for resource co-ordination and accounting, and perform some of the mediation necessary for slices to operate components provided by many component managers.
  • Our slice embedding service provides a convenient way for users to map their desired resources onto the set of components which are available to them.