Resource Management Interface Specs Scott Jackson
Release v. 3.0.3 Brett Bode
Kevin Walker
Scalable Systems Software Resource Management and Accounting Protocol (SSSRMAP) Wire Protocol
Status
of this Memo
This is a specification defining a wire level protocol used between Scalable Systems Software components. It is intended that this specification will continue to evolve as these interfaces are implemented and thoroughly tested by time and experience.
Abstract
This document is a specification
describing a connection-oriented XML-based application layer client-server
protocol for the interaction of resource management and accounting software
components developed as part of the
Table
of Contents
2 Conventions Used in this Document
3.1.1 Schema Header and Namespaces
5.1 Message Header Requirements
5.5 Message and Reply Tail
Requirements and Multiple Chunks
5.6.1 Sample SSSRMAP Message Embedded
in HTTP Request
5.6.2 Sample SSSRMAP Reply Embedded in
HTTP Response
7.1.1 The SecurityToken Element
7.2.3 The SignatureValue Element
7.3.1 The EncryptedData Element
7.3.2 The EncryptedKey Element
A major objective of the Scalable Systems Software [SSS] Center is to create a scalable and modular infrastructure for resource management and accounting on terascale clusters including resource scheduling, grid-scheduling, node daemon support, comprehensive usage accounting and user interfaces emphasizing portability to terascale vendor operating systems. Existing resource management and accounting components feature disparate APIs (Application Programming Interfaces) requiring various forms of application coding to interact with other components.
This document proposes a wire level protocol expressed in an XML envelope to be considered as the foundation of a standard for communications between and among resource management and accounting software components. Individual components additionally need to define the particular XML binding necessary to represent the message format for communicating with the component.
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119 [RFC2119].
In order to enforce a consistent capitalization and naming convention across all SSSRMAP specifications “Upper Camel Case” (UCC) and “Lower Camel Case” (LCC) Capitalization styles shall be used. UCC style capitalizes the first character of each word and compounds the name. LCC style capitalizes the first character of each word except the first word. [XML_CONV][FED_XML]
1. SSSRMAP XML Schema and XML instance documents SHALL use the following conventions:
· Element names SHALL be in UCC convention (example: <UpperCamelCaseElement/>.
· Attribute names SHALL be in LCC convention (example: <UpperCamelCaseElement lowerCamelCaseAttribute=”Whatever”/>.
2. General rules for all names are:
· Acronyms SHOULD be avoided, but in cases where they are used, the capitalization SHALL remain (example: XMLSignature).
· Underscores (_), periods (.) and dashes (-) MUST NOT be used (example: use JobId instead of JOB.ID, Job_ID or job-id).
|
SSSRMAP Schema Definitions appear like this |
In case of disagreement between the schema file and this specification, the
schema file takes precedence.
Encoding tells how a message is represented when exchanged. SSSRMAP data exchange messages SHALL be defined in terms of XML schema [XML_SCHEMA].
The header of the schema definition is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<schema
xmlns=”http://www.w3.org/2001/XMLSchema”
xmlns:sssrmap=”http://www.scidac.org/ScalableSystems/SSSRMAP”
targetNamespace=”http://www.scidac.org/ScalableSystems/SSSRMAP”
elementFormDefault="qualified">
SSSRMAP messages and replies are encapsulated in the Envelope element. There are two possibilities for the contents of this element. If the contents are unencrypted, this element MUST contain a Body element and MAY contain a Signature element (refer to the section on Security). If the contents are encrypted, this element MUST contain exactly one EncryptedData element (refer to the section on Security). The Envelope element MAY contain namespace and other xsd-specific information necessary to validate the document against the schema. In addition, it MAY have any of the following attributes which may serve as processing clues to the parser:
· type – A message type providing a hint as to the body contents such as “Request” or “Notification”
· component – A component type such as “QueueManager” or “LocalScheduler”
·
name – A component name such as “OpenPBS” or “
· version – A component version such as “2.2p12” or “3.2.2”
<complexType name="EnvelopeType">
<choice minOccurs=”1” maxOccurs=”1”>
<choice minOccurs=”1” maxOccurs=”2”>
<element ref="sssrmap:Signature" minOccurs="0" maxOccurs="1"/>
<element ref="sssrmap:Body" minOccurs="1" maxOccurs="1"/>
</choice>
<element ref=”sssrmap:EncryptedData” minOccurs=”1” maxOccurs=”1”/>
</choice>
<attribute name="type" type=”string” use="optional"/>
<attribute name="component" type=”string” use="optional"/>
<attribute name="name" type=”string” use="optional"/>
<attribute name="version" type=”string” use="optional"/>
</complexType>
<element name="Envelope" type="sssrmap:EnvelopeType"/>
· SSSRMAP messages and replies are encapsulated in the Body element. This element MUST contain exactly one Request or Response element.
<complexType name="BodyType">
<choice minOccurs="1" maxOccurs="1">
<element ref="sssrmap:Request" minOccurs="0" maxOccurs="1"/> <element ref="sssrmap:Response" minOccurs="0" maxOccurs="1"/>
<any minOccurs="0" maxOccurs="1" namespace="##other"/>
</choice>
</complexType>
<element name="Body" type="sssrmap:BodyType"/>
This protocol will be built over the connection-oriented reliable transport layer TCP/IP. Support for other transport layers could also be considered, but native support for TCP/IP can be found on most terascale clusters and automatically handles issues such as reliability and connectionfullness for the application developer implementing the SSSRMAP protocol.
Framing specifies how the beginning and ending of each message is delimited. Given that the encoding will be expressed as one or more XML documents, clients and servers need to know when an XML document has been fully read in order to be parsed and acted upon.
SSSRMAP uses the HTTP 1.1 [HTTP] protocol for framing. HTTP uses a byte-counting mechanism to delimit the message segments. HTTP chunked encoding is used. This allows for optional support for batched messages, lar