ISO 20210:2015
(Main)Space data and information transfer systems - Mission Operations Message Abstraction Layer - JAVA API
Space data and information transfer systems - Mission Operations Message Abstraction Layer - JAVA API
ISO 20210:2015 is the definition of all concepts and terms that establish a Java API for consuming and providing MO services on top of the MAL. The MAL Java API is intended to maximize the portability of the MO components across various underlying MAL implementations and transport protocols.
Systèmes de transfert des informations et données spatiales — Couche d'abstraction des messages des opérations de mission — JAVA API
General Information
- Status
- Published
- Publication Date
- 10-Aug-2015
- Technical Committee
- ISO/TC 20/SC 13 - Space data and information transfer systems
- Drafting Committee
- ISO/TC 20/SC 13 - Space data and information transfer systems
- Current Stage
- 9093 - International Standard confirmed
- Start Date
- 14-Nov-2023
- Completion Date
- 13-Dec-2025
Overview
ISO 20210:2015 - Mission Operations Message Abstraction Layer (MAL) - JAVA API defines the Java mapping and API for building and consuming Mission Operations (MO) services on top of the MAL. Published as an ISO adoption of a CCSDS Recommended Practice (CCSDS 523.1‑M‑1), this standard describes the Java classes, interfaces and packaging needed to maximize portability of MO components across different MAL implementations and transport protocols. It targets interoperability in space data and information transfer systems and provides guidance for mapping MO service concepts into a Java API.
Key topics and technical requirements
- MAL Java API mapping: Definitions of how MO service framework concepts are represented in Java (packages, interfaces, classes).
- API structure and packages: Separate packages for MAL core, data structures, consumer, provider and broker functionality; clear roles for each.
- MALContext and factory classes: Context creation, registration and lookup mechanisms for areas, errors and transports (e.g., MALContextFactory).
- Service and operation modeling: Java classes for MALService, MALOperation, MALOperationStage and operation stages to represent interaction patterns and lifecycle.
- Service mapping and stub/skeleton patterns: Guidelines for consumer/provider stubs and skeletons (delegation and inheritance patterns) to enable multi-binding and transport independence.
- Transport API: Abstractions for underlying transport protocols so the same MO components can operate over different network layers.
- Access control and encoding APIs: Interfaces for security/access control and for encoding/decoding message bodies and element factories.
- Data structures and element factories: Definitions and factory classes for MAL data types, including handling of multiple-element bodies.
- Documentation and examples: Annexes include definitions, informative references, security/patent considerations and code examples to support implementation.
Practical applications
- Building portable ground-segment and mission-operations software (telemetry, telecommand, mission planning).
- Implementing middleware and service frameworks for satellite control and space mission operations.
- Enabling interoperability between different agencies, vendors and tools by standardizing the Java interface layer above transport protocols.
- Supporting multi-vendor integrations where the same Java MO component must run over different MAL implementations (e.g., TCP, CCSDS transports).
Who should use ISO 20210:2015
- Space agencies and mission operations centers (NASA, ESA, JAXA, etc.)
- Ground system architects and integrators
- Middleware and software vendors producing MO frameworks, brokers and transport bindings
- Java developers implementing MO services, consumers and providers
Related standards
- CCSDS 523.1‑M‑1 (Mission Operations Message Abstraction Layer - JAVA API) - original Recommended Practice adopted by ISO
- Other Mission Operations (MO) books and CCSDS specifications that define the service concepts and transport bindings
ISO 20210:2015 helps teams standardize the Java layer of mission operations software to improve portability, interoperability and long‑term maintainability of space operations systems.
Frequently Asked Questions
ISO 20210:2015 is a standard published by the International Organization for Standardization (ISO). Its full title is "Space data and information transfer systems - Mission Operations Message Abstraction Layer - JAVA API". This standard covers: ISO 20210:2015 is the definition of all concepts and terms that establish a Java API for consuming and providing MO services on top of the MAL. The MAL Java API is intended to maximize the portability of the MO components across various underlying MAL implementations and transport protocols.
ISO 20210:2015 is the definition of all concepts and terms that establish a Java API for consuming and providing MO services on top of the MAL. The MAL Java API is intended to maximize the portability of the MO components across various underlying MAL implementations and transport protocols.
ISO 20210:2015 is classified under the following ICS (International Classification for Standards) categories: 49.140 - Space systems and operations. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 20210:2015 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 20210
First edition
2015-08-15
Space data and information transfer
systems — Mission Operations
Message Abstraction Layer - JAVA API
Systèmes de transfert des informations et données spatiales — Couche
d’abstraction des messages des opérations de mission — JAVA API
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 20210 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 523.1-M-1, April 2013) and was adopted (without modifications except those stated in clause 2 of this
International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.
Recommendation for Space Data System Practices
MISSION OPERATIONS
MESSAGE
ABSTRACTION LAYER—
JAVA API
RECOMMENDED PRACTICE
CCSDS 523.1-M-1
MAGENTA BOOK
April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
AUTHORITY
Issue: Recommended Practice, Issue 1
Date: April 2013
Location: Washington, DC, USA
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 Organization and Processes for
the Consultative Committee for Space Data Systems (CCSDS A02.1-Y-3), 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
CCSDS 523.1-M-1 Page i April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
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 in
themselves considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
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.
CCSDS 523.1-M-1 Page ii April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Practice is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-3). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 523.1-M-1 Page iii April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– 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.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking
and Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– 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.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 523.1-M-1 Page iv April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
DOCUMENT CONTROL
Document Title Date Status
CCSDS Mission Operations Message April 2013 Current issue
523.1-M-1 Abstraction Layer—JAVA API,
Recommended Practice, Issue 1
CCSDS 523.1-M-1 Page v April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS
Section Page
1 INTRODUCTION . 1-1
1.1 PURPOSE OF THIS RECOMMENDED PRACTICE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-1
1.4 RATIONALE . 1-1
1.5 DOCUMENT STRUCTURE . 1-1
1.6 DEFINITIONS . 1-2
1.7 CONVENTIONS . 1-2
1.8 REFERENCES . 1-4
2 OVERVIEW . 2-1
2.1 GENERAL . 2-1
2.2 MO SERVICE FRAMEWORK JAVA MAPPING . 2-3
2.3 MAPPING FROM MAL DOCUMENT . 2-5
3 MAL API . 3-1
3.1 GENERAL . 3-1
3.2 MAL PACKAGE . 3-3
3.3 DATA STRUCTURES PACKAGE . 3-40
3.4 CONSUMER PACKAGE . 3-58
3.5 PROVIDER PACKAGE . 3-94
3.6 BROKER PACKAGE . 3-134
4 SERVICE MAPPING . 4-1
4.1 OVERVIEW . 4-1
4.2 DEFINITION . 4-1
4.3 CONSUMER . 4-8
4.4 PROVIDER . 4-25
4.5 DATA STRUCTURES . 4-40
4.6 ELEMENT FACTORY CLASSES . 4-50
4.7 MULTIPLE ELEMENT BODY CLASSES . 4-51
4.8 HELPER AND ELEMENT FACTORY CLASSES . 4-53
5 TRANSPORT API . 5-1
5.1 GENERAL . 5-1
5.2 CLASSES AND INTERFACES . 5-1
CCSDS 523.1-M-1 Page vi April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS (continued)
Section Page
6 ACCESS CONTROL API . 6-1
6.1 GENERAL . 6-1
6.2 CLASSES AND INTERFACES . 6-1
7 ENCODING API . 7-1
7.1 OVERVIEW . 7-1
7.2 CLASSES AND INTERFACES . 7-1
ANNEX A DEFINITION OF ACRONYMS (INFORMATIVE) . A-1
ANNEX B INFORMATIVE REFERENCES (INFORMATIVE) .B-1
ANNEX C SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE) . C-1
ANNEX D CODE EXAMPLE (INFORMATIVE) . D-1
Figure
2-1 Mission Operations Services Concept Document Set . 2-1
2-2 Relationship of MO Books . 2-2
2-3 Overview of the Mission Operations Service Framework . 2-3
2-4 MO Framework Java Mapping . 2-4
3-1 Relationships between the API Main Interfaces . 3-2
4-1 Relationships between the Stub Classes and Interfaces . 4-8
4-2 Relationships between the Skeleton Classes and Interfaces (Delegation Pattern) . 4-26
4-3 Relationships between the Skeleton Classes and Interfaces (Inheritance Pattern) . 4-26
4-4 Multi-Binding Service Provider . 4-27
Table
1-1 Variable Value Case Rules . 1-4
3-1 API Main Interfaces . 3-1
3-2 MALContextFactory ‘registerFactoryClass’ Parameter . 3-4
3-3 MALContextFactory ‘deregisterFactoryClass’ Parameter . 3-4
3-4 MALContextFactory ‘createMALContext’ Parameter . 3-6
3-5 MALContextFactory ‘registerArea’ Parameter . 3-6
3-6 MALContextFactory ‘lookupArea’ Parameters . 3-7
3-7 MALContextFactory ‘registerError’ Parameters . 3-8
3-8 MALContextFactory ‘lookupError’ Parameter . 3-8
3-9 MALContext ‘getTransport’ Parameters . 3-11
CCSDS 523.1-M-1 Page vii April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS (continued)
Table Page
3-10 MALService Attributes . 3-12
3-11 MALService Constructor Parameters . 3-13
3-12 MALService ‘setArea’ Parameter . 3-15
3-13 MALService ‘addOperation’ Parameter . 3-15
3-14 MALOperation Attributes . 3-16
3-15 MALOperation Constructor Parameters . 3-16
3-16 MALOperation ‘getOperationStage’ Parameter . 3-18
3-17 MALOperation ‘setService’ Parameter . 3-19
3-18 Interaction Stages Constants . 3-20
3-19 Operation stages . 3-21
3-20 MAL<>Operation Constructor Parameters . 3-21
3-21 MALOperationStage Attributes . 3-23
3-22 MALOperationStage Constructor Parameters . 3-24
3-23 MALOperation ‘setOperation’ Parameter . 3-25
3-24 MALService Attributes . 3-26
3-25 MALArea Constructor Parameters . 3-26
3-26 MALArea ‘addService’ Parameter . 3-27
3-27 MALService Constructor Parameters . 3-28
3-28 MALException Constructor Parameters . 3-30
3-29 MALInteractionException Constructor Parameter . 3-31
3-30 MALElementFactoryRegistry ‘registerElementFactory’ Parameters . 3-32
3-31 MALElementFactoryRegistry ‘lookupElementFactory’ Parameter . 3-33
3-32 MALElementFactoryRegistry ‘deregisterElementFactory’ Parameter . 3-33
3-33 MALEncoder and MALDecoder Variables . 3-34
3-34 MALEncoder ‘encode[Nullable]<>’ Parameter . 3-35
3-35 MALListEncoder ‘createListEncoder’ Parameter . 3-36
3-36 MALListDecoder ‘createListDecoder’ Parameter . 3-36
3-37 MALEncoder ‘encode[Nullable]Element’ Parameter . 3-37
3-38 MALDecoder ‘decode[Nullable]Element’ Parameter . 3-37
3-39 MALEncoder ‘encode[Nullable]Attribute’ Parameter . 3-38
3-40 Element ‘encode’ Parameter . 3-41
3-41 Element ‘decode’ Parameter . 3-42
3-42 Enumeration Constructor Parameter . 3-44
3-43 MAL::Attribute Types Mapped to a Java Type . 3-45
3-44 Union Variables . 3-46
3-45 Union Constructor Parameter . 3-46
3-46 Blob Byte Array Constructor Parameter . 3-49
3-47 Blob URL Constructor Parameter . 3-50
3-48 MAL::Attribute Types Represented by a Specific Class . 3-53
3-49 Initial Value Assigned by the <> Empty Constructor . 3-54
3-50 MALConsumerManager ‘createConsumer’ Parameters . 3-59
CCSDS 523.1-M-1 Page viii April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS (continued)
Table Page
3-51 QoS Properties . 3-60
3-52 MALConsumer ‘send’ Parameters . 3-62
3-53 MALConsumer ‘submit’ Parameters . 3-63
3-54 MALConsumer ‘request’ Parameters . 3-64
3-55 MALConsumer ‘invoke’ Parameters . 3-66
3-56 MALConsumer ‘progress’ Parameters . 3-67
3-57 MALConsumer ‘register’ Parameters . 3-68
3-58 MALConsumer ‘deregister’ Parameters . 3-70
3-59 MALConsumer ‘asyncSubmit’ Parameters . 3-71
3-60 MALConsumer ‘asyncRequest’ Parameters . 3-72
3-61 MALConsumer ‘asyncInvoke’ Parameters . 3-73
3-62 MALConsumer ‘asyncProgress’ Parameters . 3-75
3-63 MALConsumer ‘asyncRegister’ Parameters . 3-76
3-64 MALConsumer ‘asyncDeregister’ Parameters . 3-77
3-65 MALConsumer ‘continueInteraction’ Parameters . 3-78
3-66 MALConsumer ‘setTransmitErrorListener’ Parameter . 3-79
3-67 MALInteractionListener ‘submitAckReceived’ Parameters . 3-81
3-68 MALInteractionListener ‘submitErrorReceived’ Parameters . 3-81
3-69 MALInteractionListener ‘requestResponseReceived’ Parameters . 3-82
3-70 MALInteractionListener ‘requestErrorReceived’ Parameters . 3-83
3-71 MALInteractionListener ‘invokeAckReceived’ Parameters . 3-83
3-72 MALInteractionListener ‘invokeAckErrorReceived’ Parameters . 3-84
3-73 MALInteractionListener ‘invokeResponseReceived’ Parameters . 3-85
3-74 MALInteractionListener ‘invokeResponseErrorReceived’ Parameters . 3-85
3-75 MALInteractionListener ‘progressAckReceived’ Parameters . 3-86
3-76 MALInteractionListener ‘progressAckErrorReceived’ Parameters . 3-87
3-77 MALInteractionListener ‘progressUpdateReceived’ Parameters . 3-87
3-78 MALInteractionListener ‘progressUpdateErrorReceived’ Parameters . 3-88
3-79 MALInteractionListener ‘progressResponseReceived’ Parameters . 3-89
3-80 MALInteractionListener ‘progressResponseErrorReceived’ Parameters . 3-89
3-81 MALInteractionListener ‘registerAckReceived’ Parameters . 3-90
3-82 MALInteractionListener ‘registerErrorReceived’ Parameters . 3-91
3-83 MALInteractionListener ‘notifyReceived’ Parameters . 3-91
3-84 MALInteractionListener ‘notifyErrorReceived’ Parameters . 3-92
3-85 MALInteractionListener ‘deregisterAckReceived’ Parameters . 3-92
3-86 MALProviderManager ‘createProvider’ Parameters . 3-95
3-87 MALProvider ‘createPublisher’ Parameters . 3-99
3-88 MALProvider ‘setTransmitErrorListener’ Parameter . 3-100
3-89 MALInteractionHandler ‘malInitialize’ Parameter . 3-103
3-90 MALInteractionHandler ‘handleSend’ Parameters . 3-103
3-91 MALInteractionHandler ‘handleSubmit’ Parameters . 3-104
CCSDS 523.1-M-1 Page ix April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS (continued)
Table Page
3-92 MALInteractionHandler ‘handleRequest’ Parameters . 3-105
3-93 MALInteractionHandler ‘handleInvoke’ Parameters . 3-105
3-94 MALInteractionHandler ‘handleProgress’ Parameters . 3-106
3-95 MALInteractionHandler ‘malFinalize’ Parameter . 3-107
3-96 MALInteractionHandler ‘get/setQoSProperty’ Parameters . 3-108
3-97 MALSubmit ‘sendError’ Parameter . 3-109
3-98 MALResponse ‘sendResponse’ Parameter . 3-111
3-99 MALResponse ‘sendError’ Parameter . 3-112
3-100 MALInvoke ‘sendAcknowledgement’ Parameters. 3-113
3-101 MALProgress ‘sendUpdate’ Parameter . 3-115
3-102 MALProgress ‘sendUpdateError’ Parameter . 3-116
3-103 MALPublisher ‘publish’ Parameters . 3-117
3-104 MALPublisher ‘register’ Parameters . 3-118
3-105 MALPublisher ‘asyncRegister’ Parameters . 3-120
3-106 MALPublisher ‘asyncDeregister’ Parameter . 3-121
3-107 MALPublishInteractionListener ‘publishRegisterAckReceived’ Parameters . 3-123
3-108 MALPublishInteractionListener ‘publishRegisterErrorReceived’ Parameters . 3-123
3-109 MALPublishInteractionListener ‘publishErrorReceived’ Parameters . 3-124
3-110 MALPublishInteractionListener ‘publishDeregisterAckReceived’ Parameters . 3-125
3-111 MALProviderSet Constructor Parameter . 3-125
3-112 MALProviderSet ‘createPublisherSet’ Parameters . 3-126
3-113 MALProviderSet ‘addProvider’ Parameter . 3-127
3-114 MALProviderSet ‘removeProvider’ Parameter . 3-128
3-115 MALPublisherSet Constructor Parameters . 3-129
3-116 MALPublisherSet ‘createPublisher’ Parameter . 3-129
3-117 MALPublisherSet ‘deletePublisher’ Parameter . 3-130
3-118 MALPublisherSet ‘publish’ Parameters . 3-131
3-119 MALPublisherSet ‘register’ Parameters . 3-131
3-120 MALPublisherSet ‘asyncRegister’ Parameters . 3-132
3-121 MALPublisherSet ‘asyncDeregister’ Parameter . 3-133
3-122 MALBrokerManager ‘createBroker’ Parameter . 3-135
3-123 MALBrokerBinding ‘createBrokerBinding’ Parameters . 3-136
3-124 MALBrokerBinding ‘sendNotify’ Parameters . 3-139
3-125 MALBrokerBinding ‘sendNotifyError’ Parameters . 3-140
3-126 MALBrokerBinding ‘sendPublishError’ Parameters . 3-142
3-127 MALBrokerBinding ‘setTransmitErrorListener’ Parameter . 3-143
3-128 MALBrokerHandler ‘malInitialize’ Parameter . 3-145
3-129 MALBrokerHandler ‘handleRegister’ Parameters . 3-145
3-130 MALBrokerHandler ‘handlePublishRegister’ Parameters . 3-146
3-131 MALBrokerHandler ‘handlePublish’ Parameters . 3-147
3-132 MALBrokerHandler ‘handleDeregister’ Parameters . 3-148
CCSDS 523.1-M-1 Page x April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS (continued)
Table Page
3-133 MALBrokerHandler ‘handlePublishDeregister’ Parameters . 3-148
3-134 MALBrokerHandler ‘malFinalize’ Parameter . 3-149
4-1 Service Mapping Variables . 4-3
4-2 Area Classes . 4-7
4-3 Service Classes . 4-7
4-4 <>Stub Attribute. 4-21
4-5 <> Publisher Attribute . 4-30
4-6 <>Publisher constructor Parameter . 4-30
4-7 <>Publisher ‘publish’ Parameters . 4-31
4-8 Invoke <>Interaction Attribute . 4-32
4-9 Progress <>Interaction Attribute . 4-34
4-10 <>InheritanceSkeleton Attributes . 4-36
4-11 <>DelegationSkeleton Attributes . 4-39
5-1 MALTransportFactory Attributes . 5-1
5-2 MALTransportFactory ‘registerFactoryClass’ Parameters . 5-2
5-3 MALTransportFactory ‘deregisterFactoryClass’ Parameter . 5-2
5-4 MALTransportFactory Constructor Parameter . 5-3
5-5 MALTransportFactory ‘newFactory’Parameter . 5-4
5-6 MALTransportFactory ‘createTransport’ Parameter . 5-5
5-7 MALTransport ‘createEndpoint’ Parameters . 5-6
5-8 MALTransport ‘getEndpoint’ Parameters . 5-7
5-9 MALTransport ‘deleteEndpoint’ Parameter . 5-7
5-10 MALTransport ‘isSupportedQoSLevel’ Parameter . 5-8
5-11 MALTransport ‘isSupportedInteractionType’ Parameter . 5-9
5-12 MALTransport ‘createBroker’ Parameters . 5-10
5-13 MALEndpoint ‘createMessage’ Parameters . 5-15
5-14 MALEndpoint ‘sendMessage’ Parameters . 5-16
5-15 MALEndpoint ‘sendMessages’ Parameters . 5-17
5-16 MALEndpoint ‘setMessageListener’ Parameter . 5-17
5-17 MALMessageBody ‘getBodyElement’ Parameters . 5-20
5-18 MALMessageBody ‘getEncodedBodyElement’ Parameter . 5-20
5-19 MALPublishBody ‘getUpdateLists’ Parameter . 5-23
5-20 MALPublishBody ‘getUpdateList’ Parameter . 5-23
5-21 MALPublishBody ‘getUpdate’ Parameter . 5-24
5-22 MALPublishBody ‘getEncodedUpdate’ Parameter . 5-25
5-23 MALEncodedElement Constructor Parameter . 5-27
5-24 MALMessageListener ‘onMessage’ Parameters . 5-29
5-25 MALMessageListener ‘onMessages’ Parameters . 5-29
5-26 MALMessageListener ‘onInternalError’ Parameters . 5-30
5-27 MALTransmitErrorException Constructor Parameters . 5-30
5-28 MALTransmitMultipleErrorException Constructor Parameter . 5-32
CCSDS 523.1-M-1 Page xi April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
CONTENTS (continued)
Table Page
5-29 MALEncodedElementList Constructor Parameters . 5-33
5-30 MALEncodedBody Constructor Parameter . 5-33
5-31 MALTransmitErrorListener ‘onTransmitError’ Parameters . 5-34
6-1 MALAccessControlFactory ‘registerFactoryClass’ Parameters . 6-2
6-2 MALAccessControlFactory ‘deregisterFactoryClass’ Parameter . 6-2
6-3 MALAccessControlFactory ‘createAccessControl’ Parameter . 6-3
6-4 MALAccessControl ‘check’ Parameter . 6-4
6-5 MALCheckErrorException Constructor Parameters . 6-5
7-1 MALElementStreamFactory ‘registerFactoryClass’ Parameters . 7-2
7-2 MALElementStreamFactory ‘deregisterFactoryClass’ Parameters . 7-3
7-3 MALElementStreamFactory Creation Parameters . 7-3
7-4 MALElementStreamFactory ‘init’ Parameters . 7-5
7-5 MALElementStreamFactory ‘createInputStream’ Parameter . 7-5
7-6 MALElementStreamFactory ‘createOutputStream’ Parameter . 7-6
7-7 MALElementStreamFactory ‘encode’ Parameters . 7-7
7-8 MALElementInputStream ‘readElement’ Parameters . 7-8
7-9 MALElementOutputStream ‘writeElement’ Parameters . 7-9
7-10 MALEncodingContext Attributes . 7-11
C-1 JavaBindingNamespace Initial Values .C-3
CCSDS 523.1-M-1 Page xii April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
1 INTRODUCTION
1.1 PURPOSE OF THIS RECOMMENDED PRACTICE
This Recommended Practice defines a Java API for the Mission Operations (MO) Message
Abstraction Layer (MAL) specified in reference [1].
1.2 SCOPE
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. The
MAL Java API is intended to maximize the portability of the MO components across various
underlying MAL implementations and transport protocols.
1.3 APPLICABILITY
This Recommended Practice serves as a specification of a Java API providing all the
concepts defined by the MAL, in particular the interaction patterns, the access control and
transport interfaces.
The API supports version 1 of the MAL as specified in reference [1].
The API depends on Java 5.
1.4 RATIONALE
The goal of this Recommended Practice is to document how to develop and utilize MAL-based
services using Java (reference [2]).
Another objective is to create a guide for promoting portability between various software
packages implementing the MAL Java API and applications using the MAL Java API.
1.5 DOCUMENT STRUCTURE
This Recommended Practice is organized as follows:
a) section 1 provides purpose and scope, and lists definitions, conventions, and
references used throughout the Recommended Practice;
b) section 2 gives an overview of the API;
c) section 3 defines the MAL API that represents the MAL service interface;
d) section 4 defines how a MAL service specification is mapped to Java;
e) section 5 defines the transport API that represents the MAL transport interface;
CCSDS 523.1-M-1 Page 1-1 April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
f) section 6 defines the access control API that represents the MAL access control
interface;
g) section 7 defines the encoding API, an optional set of interfaces that can be used by
the transport layer in order to externalize the encoding behaviour.
NOTE – Some application code examples are given in annex C.
1.6 DEFINITIONS
Attribute: Either
– a field of a Java class called ‘attribute’,
– the data type MAL::Attribute, or
– the interface Attribute defined in the MAL Java API.
1.7 CONVENTIONS
1.7.1 NOMENCLATURE
The following conventions apply for the normative specifications in this Recommended
Practice:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.7.2 INFORMATIVE TEXT
In the normative sections of this document (sections 3-7), informative text is set off from the
normative specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
CCSDS 523.1-M-1 Page 1-2 April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
1.7.3 USE OF CAPITAL LETTERS
Names of interfaces and classes of the MAL Java API are shown with the first letter of each
word capitalized.
1.7.4 CODE 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 ‘method name’ is used in the following code line:
public void <>()
If a variable contains a list of values, then the values are iterated with the following syntax:
<> … <>
The variable ‘i’ is the iteration index starting from 0.
The variable ‘N’ is the size of the list minus one.
If the list size is zero, then nothing is written in the code template.
If the list size is greater than zero, then the <> part is iterated N times and
the <> part is finally written in the code template.
For example, the variable ‘type’ contains a list of types. A method ‘m’ taking those types as
parameters is declared as follows:
public void m(<> p<>, … <> p<>)
If the list is empty, then the result is:
public void m()
If the list contains one element ‘A’ then the result is:
public void m(A p0)
The names of variables are not case-sensitive: ‘field name’ and ‘FIELD NAME’ designate
the same variable.
CCSDS 523.1-M-1 Page 1-3 April 2013
CCSDS RECOMMENDED PRACTICE FOR MO MAL JAVA API
However, the value of the variable is case sensitive following the rules explained in
table 1-1.
Table 1-1: Variable Value Case Rules
Variable name case Variable value case
All the letters in lower case. Example: No change
<>
First letter in upper case and the other in No change except the first letter in upper case
lower case. Example:
<>
All the letters in upper case. Example: Upper case
<<
...




Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...