Draft Recommendation for
Space Data System Practices
Draft Recommended Practice
CCSDS 000.0-R-0
Red Book
November 2010October 2010
DRAFT CCSDS RECOMMENDED PRACTICE FOR MO JAVA MAL API
AUTHORITY
Issue: / Red Book, Issue 1Date: / October 2010
Location: / Not Applicable
(WHEN THIS RECOMMENDED PRACTICE IS FINALIZED, IT WILL CONTAIN THE FOLLOWING STATEMENT OF AUTHORITY:)
This document has been approved for publication by the Management Council of the Consultative Committee for Space Data Systems (CCSDS) and represents the consensus technical agreement of the participating CCSDS Member Agencies. The procedure for review and authorization of CCSDS documents is detailed in the Procedures Manual for the Consultative Committee for Space Data Systems, and the record of Agency participation in the authorization of this document can be obtained from the CCSDS Secretariat at the address below.
This document is published and maintained by:
CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
STATEMENT OF INTENT
(WHEN THIS RECOMMENDED PRACTICE IS FINALIZED, IT WILL CONTAIN THE FOLLOWING STATEMENT OF INTENT:)
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially established by the management of its members. The Committee meets periodically to address data systems problems that are common to all participants, and to formulate sound technical solutions to these problems. Inasmuch as participation in the CCSDS is completely voluntary, the results of Committee actions are termed Recommendations and are not considered binding on any Agency.
This Recommended Practice is issued by, and represents the consensus of, the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary. Endorsement, however, indicates the following understandings:
oWhenever a member establishes a CCSDS-related practice, this practice should be in accord with the relevant Recommended Practice. Establishing such a practice does not preclude other provisions which a member may develop.
oWhenever a member establishes a CCSDS-related practice, that member will provide other CCSDS members with the following information:
--The practice itself.
--The anticipated date of initial operational capability.
--The anticipated duration of operational service.
oSpecific service arrangements shall be made via memoranda of agreement. Neither this Recommended Practice nor any ensuing practice is a substitute for a memorandum of agreement.
No later than five years from its date of issuance, this Recommended Practice will be reviewed by the CCSDS to determine whether it should: (1) remain in effect without change; (2) be changed to reflect the impact of new technologies, new requirements, or new directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Practice is issued, existing CCSDS-related member Practices and implementations are not negated or deemed to be non-CCSDS compatible. It is the responsibility of each member to determine when such Practices or implementations are to be modified. Each member is, however, strongly encouraged to direct planning for its new Practices and implementations towards the later version of the Recommended Practice.
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or modification of this document may occur. This Recommended Practiceis therefore subject to CCSDS document management and change control procedures, which are defined in the Procedures Manual for the Consultative Committee for Space Data Systems. Current versions of CCSDS documents are maintained at the CCSDS Web site:
Questions relating to the contents or status of this document should be addressed to the CCSDS Secretariat at the address indicated on page i.
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
–Agenzia Spaziale Italiana (ASI)/Italy.
–British National Space Centre (BNSC)/United Kingdom.
–Canadian Space Agency (CSA)/Canada.
–Centre National d’Etudes Spatiales (CNES)/France.
–China National Space Administration (CNSA)/People’s Republic of China.
–Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
–European Space Agency (ESA)/Europe.
–Russian Federal Space Agency (RFSA)/Russian Federation.
–Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
–Japan Aerospace Exploration Agency (JAXA)/Japan.
–National Aeronautics and Space Administration (NASA)/USA.
Observer Agencies
–Austrian Space Agency (ASA)/Austria.
–Belgian Federal Science Policy Office (BFSPO)/Belgium.
–Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
–Centro Tecnico Aeroespacial (CTA)/Brazil.
–Chinese Academy of Sciences (CAS)/China.
–Chinese Academy of Space Technology (CAST)/China.
–Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
–Danish National Space Center (DNSC)/Denmark.
–European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe.
–European Telecommunications Satellite Organization (EUTELSAT)/Europe.
–Hellenic National Space Committee (HNSC)/Greece.
–Indian Space Research Organization (ISRO)/India.
–Institute of Space Research (IKI)/Russian Federation.
–KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
–Korea Aerospace Research Institute (KARI)/Korea.
–CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
–Ministry of Communications (MOC)/Israel.
–National Institute of Information and Communications Technology (NICT)/Japan.
–National Oceanic and Atmospheric Administration (NOAA)/USA.
–National Space Organization (NSPO)/Chinese Taipei.
–Naval Center for Space Technology (NCST)/USA.
–Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
–Swedish Space Corporation (SSC)/Sweden.
–United States Geological Survey (USGS)/USA.
PREFACE
This document is a draft CCSDS Recommended Practice. Its ‘Red Book’ status indicates that the CCSDS believes the document to be technically mature and has released it for formal review by appropriate technical organizations. As such, its technical contents are not stable, and several iterations of it may occur in response to comments received during the review process.
Implementers are cautioned not to fabricate any final equipment in accordance with this document’s technical content.
DOCUMENT CONTROL
Document / Title and Issue / Date / StatusCCSDS 000.0-R-0 / MO Java MAL API, Draft Recommended Practice, Issue 1 / October 2010 / Current draft
CONTENTS
SectionPage
1Introduction......
1.1Purpose of this Recommended Practice
1.2Scope
1.3Applicability......
1.4Rationale......
1.5Document Structure
1.6Definitions......
1.7Conventions......
1.8References......
2Overview......
2.1General......
2.2MO service Framework Java mapping
2.3Package names......
2.4API Main interfaces......
2.5Java compliance......
2.6Code template variables......
3MAL API......
3.1MAL package......
3.2Data structures package......
3.3Consumer package......
3.4Provider package......
3.5Broker package......
4Service mapping......
4.1Consumer......
4.2Provider......
4.3Data structures and helper classes......
5Attribute mapping......
6Code example......
6.1Area mapping code......
6.2Service mapping code......
6.3client code......
7Transport SPI......
7.1Classes and interfaces......
8Security SPI......
8.1Classes and Interfaces......
8.2Local authentication implementation......
9Encoding SPI......
9.1Classes and interfaces......
9.2Encoding module implementation......
ANNEX A Definition of ACRONYMS (Informative)......
ANNEX B Informative References (Informative)
Figure
2-1Mission Operations Services Concept Document Set......
2-2Relationship of MO Books......
2-3Overview of Mission Operations Service Framework......
2-4MO Framework Java mapping......
2-5Relationships between the API main interfaces......
4-1Relationships between the API main interfaces......
4-2Relationships between the skeleton classes and interfaces (delegation pattern)......
4-3Relationships between the skeleton classes and interfaces (inheritance pattern)......
4-4Multi-binding service provider......
9-1Generic and specific encoding modules......
Table
2-1API main interfaces......
2-2Variable letter case rules......
3-1MALFactory ‘createMAL’ parameter......
3-2MALFactory ‘registerElementClass’ parameters......
3-3MALFactory ‘lookupElementClass’ parameter......
3-4MALFactory ‘registerArea’ parameter......
3-5MALFactory ‘lookupArea’ parameter......
3-6MALFactory ‘lookupArea’ parameter......
3-7MALFactory ‘lookupOperation’ parameters......
3-8MALService constructor parameters......
3-9MALService ‘setArea’ parameter......
3-10MALService ‘addOperation’ parameter......
3-11MALOperation constructor parameters......
3-12MALOperation ‘getBodyShortName’ parameter......
3-13MALOperation ‘setService’ parameter......
3-14Interaction stages constants......
3-15MAL<Ip>Operation constructor parameters......
3-16Returned elements short names......
3-17MALArea constructor parameters......
3-18MALArea ‘addService’ parameter......
3-19MALArea ‘addService’ parameter......
3-20MALComposite ‘encode’ parameter......
3-21MALComposite ‘decode’ parameter......
3-22MAL::Attribute variables......
3-23MAL::Attributes represented by a specific class......
3-24Default values assigned by the <Attribute> empty constructor......
3-25MALConsumerManager ‘createConsumer’ parameters......
3-26QoS properties......
3-27MALProviderManager ‘createProvider’ parameters......
3-28MALProviderManager ‘deleteProvider’ parameters......
3-29MALProviderManager ‘getPublisher’ parameter......
3-30MALPublisher ‘publish’ parameters......
3-31MALPublisher ‘register’ parameters......
3-32MALPublisher ‘deregister’ parameters......
3-33MALPublisher ‘asyncRegister’ parameters......
3-34MALPublisher ‘asyncRegister’ parameters......
3-35MALBroker creation parameter......
3-36MALBrokerBinding creation parameters......
3-37MALBrokerBinding deletion parameters......
4-1Service mapping variables......
4-2Area classes......
4-3Service classes......
4-4Stub interface methods mapping......
4-5Skeleton handler interface methods mapping......
4-6Enumeration template variables......
4-7List template variables......
4-8Composite template variables......
4-9Service helper template variables......
4-10Service helper class registration template variables......
4-11Area helper template variables......
4-12Area helper class registration template variables......
5-1MAL::Attributes mapped on a Java type......
6-1Directory sample mapping......
7-1MALTransportFactory creation parameter......
7-2MALTransportFactory ‘createTransport’ parameter......
7-3MALTransport ‘createEndPoint’ parameters......
7-4MALTransport ‘deleteEndPoint’ parameter......
7-5MALTransport ‘isSupportedQoSLevel’ parameter......
7-6MALTransport ‘isSupportedInteractionType’ parameter......
7-7MALTransport ‘createBroker’ parameters......
7-8MALTransport ‘deleteBroker’ parameter......
7-9MALEndPoint ‘createMessage’ parameters......
7-10MALEndPoint ‘sendMessage’ parameters......
7-11MALEndPoint ‘sendMessages’ parameters......
7-12MALEndPoint ‘setMessageListener’ parameters......
7-13MALTransmitErrorException constructor parameters......
7-14MALTransmitMultipleErrorException constructor parameters......
8-1MALSecurityManagerFactory ‘createSecurityManager’ parameter......
8-2MALSecurityManager ‘check’ parameter......
9-1ElementStreamFactory creation parameters......
9-2ElementStreamFactory ‘init’ parameters......
9-3ElementStreamFactory ‘createInputStream’ parameter......
9-4ElementStreamFactory ‘createOutputStream’ parameter......
9-5ElementInputStream ‘readElement’ parameter......
9-6ElementOutputStream ‘writeElement’ parameter......
9-7EncodingContext attributes......
CCSDS 000.0-R-0Page 1November 2010
DRAFT CCSDS RECOMMENDED PRACTICE FOR MO JAVA MAL API
1Introduction
1.1Purpose of this Recommended PrRactice
This Proposed Recommendation defines a Java API for the Mission Operations(MO) Message Abstraction Layer (MAL) specified in reference [B1].
1.2Scope
The scope of this Recommended Practice is the definition of all concepts and terms that establish a Java API for consuming and providing MO services on top of the MAL.
1.3Applicability
This Recommended Practice serves as a specificationof a Java API providing all the concepts defined by the MAL, in particular the interaction patterns, the access control and transport interfaces.
1.4Rationale
This Recommended Practice aims at minimizing the set of concepts a Java language programmer must learn to use and implement MO services. Another objective is to maximize the portability of the MO components across various MAL implementations and transport protocols.
1.5Document Structure
This Recommended Practice is organized as follows:
a)section 1 provides purpose and scope, and lists definitions, conventions, and references used throughout the Recommendation;
b)section 2 gives an overview of the API;
c)section 3 defines the API;
d)section 4 defines the mapping of MO services to Java;
e)section 5 defines how the MAL attributes are mapped to Java;
f)section 6 gives an application code example;
g)section 7 defines the transport SPI that represents the MAL transport interface;
h)section 8 defines the security manager SPI that represents the MAL access controlinterface;
i)section 9defines the encoding SPI, an optional set of interfaces that can be used by the transport layer in order to externalize the encoding behavior.
1.6Definitions
Attribute: This term designates either a field of a Java class called “attribute” or the data type “MAL::Attribute” or the interface “Attribute” defined in the Java MAL API.
1.7Conventions
1.7.1Style
Within this Recommended Practice, each formal statement stands in a paragraph by itself and is identified uniquely by a subsection number or by a combination of subsection number and list item number.
1.7.2Notes
Notes are not formally part of this Recommended Practice. They are isolated from the formal statements and are introduced by the word NOTE.
NOTE–This is an example of a note.
1.7.3Use of Capital Letters
Names of interfaces, classes and objects of the Java MAL API are shown with the first letter of each word capitalized.
1.8References
The following documents contain provisions which, through reference in this text, constitute provisions of this Recommended Practice. At the time of publication, the editions indicated were valid. All documents are subject to revision, and users of this Recommended Practice are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Documents.
CCSDS 000.0-R-0Page 1November 2010
DRAFT CCSDS RECOMMENDED PRACTICE FOR MO JAVA MAL API
2Overview
2.1General
This document entitled “MO Java MAL API” is a Recommended Practice. It is not a normative specification. It plays a useful role in application portability, but plays no role in interoperability. It provides a convenient interface specification that translates the abstract service definitions of the MAL and MO Services into a Java specific interface that can be used by programmers. The API must be faithful to the abstract services defined in the specifications and it must, by some means, provide access to the features of the services and all of their options.
The following diagram presents the set of standards documentation proposed in support of the Mission Operations Services Concept. The MO Java MAL API belongs to the language mappings documentation.
Figure 21: Mission Operations Services Concept Document Set
For each programming language there is only required a single mapping of the MAL to that language as the abstract services are defined in terms of the MAL and therefore their language-specific API is derived from the mapping. The same applies to the relevant deployment technologies; there is only required a single specification of the mapping from the MAL to that technology:
Figure 22: Relationship of MO Books
This Recommended Practice defines a mapping from the abstract notation of the MAL to an unambiguous Java API, more specifically:
a)how the specific MAL abstract services are mapped to Java;
b)how any service errors or issues shall be communicated to higher layers;
c)the physical representation of the abstract MAL messages at the interface necessary to constitute the operation templates;
d)the mapping of the message structure rules for Java;
e)the physical representation of the abstract MAL data types in Java.
It does not specify:
a)individual application services, implementations or products;
b)the implementation of entities or interfaces within real systems;
c)the methods or technologies required to acquire data;
d)the management activities required to schedule a service;
e)the representation of any service specific PDUs or operations (this is derived from the Java transform defined in this document)
2.2MO service Framework Java mapping
The CCSDS Spacecraft Monitoring & Control (SM&C) working group has developed a concept for a Mission Operations (MO) Service Framework, which follows the principles of Service Oriented Architectures. It defines two important aspects, the first is a protocol for interaction between two separate entities, and the second is a framework of common services providing functionality common to most uses of the service framework.
Figure 23: Overview of the Mission Operations Service Framework
This Recommended Practice defines a Java mapping of the MO Service Framework that consists of several programming interface levels. Each interface level is qualified either as an API if it is to be used by a MAL application layer or SPI (Service Provider Interface) if it is to be implemented by a MAL extension layer.
The following programming interfaces are defined:
a)MO Services API
b)Java MAL API
c)Security SPI
d)Transport SPI
e)Encoding SPI
Figure 24: MO Framework Java mapping
The Java MAL API consists of five levels:
a)a generic API used by every MAL clients;
b)the data structures and related interfaces;
c)a service consumer API;
d)a service provider API;
e)a broker administration API.
The MAL security access and transport interfaces are defined by:
a)a transport SPI;
b)a security SPI.
The optional encoding interface is defined by the encoding SPI.
2.12.3Package names
The API is comprised of the following packages:
a)org.ccsds.moims.mo.mal: generic API used by every MAL clients;
b)org.ccsds.moims.mo.mal.structures: the data structures and related interfaces;
c)org.ccsds.moims.mo.mal.consumer: service consumer API;
d)org.ccsds.moims.mo.mal.provider: service provider API;
e)org.ccsds.moims.mo.mal.broker: broker administration API.
The transport and security SPI packages are:
a)org.ccsds.moims.mo.mal.transport
b)org.ccsds.moims.mo.mal.security
The encoding SPI package is: org.ccsds.moims.mo.mal.encoding.
2.22.4API Main interfaces
The main interfaces provided by the API are listed in the following table:
Table 21: API main interfaces
API level / Interface name / DescriptionGeneric / MALFactory / A factory of MAL objects.
MAL / A context that enables a client to use the communication functions provided by the MAL.
Consumer / MALConsumerManager / A factory and activator of MALConsumer objects.
MALConsumer / A communication context that enables a client to initiate interaction patterns.
Provider / MALProviderManager / A factory and activator of MALProvider objects.
MALProvider / The execution context of a service provider. It handles all the interaction patterns.It can also initiate a Pub/Sub interaction pattern with a broker as a publisher.
Broker / MALBrokerManager / A factory and activator of MALBroker objects.
MALBroker / The execution context of a shared broker. It handles the interaction pattern Pub/Sub.
The next figure gives an overview of the relationships between the API interfaces:
Figure 25: Relationships between the API main interfaces
2.32.5Java compliance
The API, the transport SPI, and the security SPI and the encoding SPIshall be compliant to CDC 1.0 (Connected Device Configuration) and to CLDC 1.1 (Connected Limited Device Configuration).
2.42.6Code template variables
Some code templates are given throughout this document. Those templates are parameterized with variables.A variable is used by placing its name between the enclosing characters ‘<’ and ‘>’. For example the variable “field name” is used in the following code line:
private Element <field name>;
The names of variables are not case-sensitive: “field name” and “FIELD NAME” designate the same variable.
The letter case of the variable value changes depending on the variable name case and enclosing characters. The following table gives the rules to be applied:
Table 22:Variable letter case rules
Variable name case / Value caseAll the letters in lower case. Example:
<variable name> / No change
First letter in upper case and the other in lower case. Example:
<Variable name> / No change except the first letter in upper case
All the letters in upper case. Example:
<VARIABLE NAME> / Upper case
All the letters in lower case and between an initial and final character ‘!’. Example:
<!variable name!> / Lower case
CCSDS 000.0-R-0Page 1November 2010