Release 14.1 (#54)

Bump version to 14.1-SNAPSHOT

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

Add release step for bumping to next development version

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

Add release date for v14.0 in the release notes

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

Vendor W3C XML Schema files instead of downloading them at build time

The generator-interfaces build downloaded XMLSchema.xsd, XMLSchema.dtd, and datatypes.dtd live from www.w3.org on every build to generate the w3c.xsd JAXB classes. These are frozen 2009 standards, and the live fetch made the build non-hermetic and prone to HTTP 429 rate-limiting from W3C (which broke CI).

Commit the three files under src/main/xsd-ref/, point the process-w3c-xsd xjc execution at the local copy, and remove the wagon-maven-plugin download executions.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Fix race condition and silent failures in LazyMessageBody decoding

For a synchronous INVOKE with a registered listener, the same lazily decoded message body is read by two threads: the consumer thread woken by the interaction handler and the dispatcher thread delivering the same message to the listener. decodeMessageBody() was not synchronized and set decodedBody=true before allocating messageParts, so the losing thread saw “already decoded”, read the still-null messageParts, and failed with an NPE far from the cause. The window only opens for a non-empty ACK body, which is why it went unnoticed. Make the method synchronized.

Also stop swallowing decode failures: a NotFoundException left messageParts null and readers would NPE later with no hint of the cause. Rethrow it as MALException like the sibling branch, and make repeated reads after a failed decode fail with a MALException instead of an NPE.

Verified against the NMF e2e testbed (a sync install invoke with a populated ACK reproduced the NPE deterministically on the unfixed code and passes with this fix) and the full MAL testbed suite.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

Restore the log-and-continue handling of NotFoundException on decode

Rethrowing the NotFoundException as MALException changed the behavior of a long-standing path: callers above may push the error back to consumers or brokers that previously carried on after the logged warning. Keep the original swallowing behavior; the repeated-read guard still reports a descriptive MALException instead of an NPE when a previous decode attempt has failed.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

Load consumer.properties only once per JVM

loadConsumerProperties() re-read and re-applied consumer.properties on every call. Consumers such as the CTT invoke it once per connection (via NMFConsumer.init() and retrieveProvidersFromDirectory()), so the file was loaded repeatedly during startup, producing a stream of “Reloading properties: consumer.properties” log lines.

Guard it with a dedicated “ConsumerPropertiesLoadedFlag” so the file is loaded at most once. The flag is deliberately independent from the provider’s “PropertiesLoadedFlag”: an application acting as both a consumer and a provider must still load both property files.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Do not report empty message bodies as failed decodes

The repeated-read guard added in 277f7c8e throws a MALException when a body is read with decodedBody=true but messageParts=null, on the assumption that this only happens after a decode failure. That assumption was wrong: an empty body is passed to the constructor as a null messageParts array, so every argument-less request and every empty acknowledgement hit the guard, and getElementCount() logged it at SEVERE during encoding on both the provider and consumer sides.

Guarantee the invariant “decodedBody == true implies messageParts != null” at both assignment sites:

the constructor coalesces a null messageParts to an empty array;
the swallowed-NotFoundException branch (the tolerated operation-not- found path restored in 07d8f6ec) degrades to an empty body instead of leaving messageParts null.

Empty bodies now encode as zero-part bodies as they did before 277f7c8e, the SEVERE spam is gone, and the guard remains as defensive insurance for a genuinely inconsistent state.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Remove stray blank lines in loadPropertiesFile

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Add release notes for version 14.1

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Bump version to 14.1 for release

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

Co-authored-by: Claude Sonnet 4.6 noreply@anthropic.com

CCSDS MO services - ESA’s Java implementation

CCSDS Mission Operations (MO) services are a set of standard end-to-end services based on a service-oriented architecture defined by the Consultative Committee for Space Data Systems (CCSDS) and it is intended to be used for mission operations of future space missions.

The architecture allows mission operation services to be specified in an implementation and communication agnostic manner. The core of the MO service framework is its Message Abstraction Layer (MAL) which ensures interoperability between mission operation services deployed on different framework implementations. The MO services are specified in compliance to a reference service model, using an abstract service description language, the MAL. This is similar to how Web Services are specified in terms of Web Services Description Language WSDL. For each concrete deployment, the abstract service interface must be bound to the selected software implementation and communication technology.

Standardization of a Mission Operations Service Framework offers a number of potential benefits for the development, deployment and maintenance of mission operations infrastructure:

Increased interoperability between agencies;
Re-usage between missions;
Reduced costs;
Greater flexibility in deployment boundaries;
Increased competition and vendor independence;
Improved long-term maintainability.

The deployment of standardized interoperable interfaces between operating Agencies, the spacecraft and internally on-board would in itself bring a number of benefits. Each organization would be able to develop or integrate their own multi-mission systems that can then be rapidly made compliant with the spacecraft. It does not preclude the reuse of legacy spacecraft, simply requiring an adaptation layer on the ground to support it, rather than many mission-specific bespoke interfaces. In the on-board environment, where software development costs are considerably higher due to platform constraints and reliability requirements, software reuse can bring immense savings.

MO stack

layerImage

List of relevant Links:

Wikipedia page: https://github.com/esa/CCSDS_MO/wiki
Documentation: https://github.com/esa/CCSDS_MO/wiki/Documentation
Service interfaces: https://dmarszk.github.io/MOWebViewer4NMF/
CCSDS website: https://public.ccsds.org/
Online CCSDS Books: https://public.ccsds.org/review/default.aspx
CCSDS Mission Operations services for Newbies: https://github.com/esa/CCSDS_MO/wiki/CCSDS-Mission-Operations-services-for-Newbies
GitHub CCSDS MO services source code: https://github.com/esa/mo-services-java
MO Training material: https://github.com/esa/CCSDS_MO_TRAINING
Online video: https://www.youtube.com/watch?v=XdGeaJE7yEk

Building Prerequisites

Install Java SDK 11 (also works with other Java versions, 1.8 is the oldest version supported - Check GitHub Workflows)
```
sudo apt-get install openjdk-11-jdk
```
Install Apache Maven
```
sudo apt-get install maven
```

Building Instructions

Clone this repository

git clone https://github.com/esa/mo-services-java.git

Build the cloned CCSDS MO Framework project:
```
mvn clean install
```

Testbed

After building the main repository, navigate to the testbeds directory. When building the testbed, an agency profile needs to be provided, e.g. ESA:

mvn clean install -P ESA

This will download and install the required dependencies and execute the tests. After running mvn clean install once, the tests can be executed by running mvn surefire:test -P ESA. Once finished, navigate to the report directory testbed-mal/target/surefire-reports/ and open TestDocument.html to see the test results.

Logs of the test run can be found in the report directory in zzz_CCSDS_[...].txt.

Selective Testing

Running all test procedures usually takes several minutes. However, this is often not necessary during development. The testbed can be configured to only run selected tests as follows.

Navigate to testbeds/testbed-mal/src/main/fitness/FitNesseRoot/MalTests/TestDocument and open content.txt. By adding # at the beginning of a line, the corresponding test will not be executed.

Troubleshooting

shared broker = true tests fail: Even though the framework supports the use of shared brokers, this is rarely used in practice as it brings unnecessary overhead in most of the cases. Errors of this kind are usually results of issues on the transport layer.

Release

The Releases can be found in: Releases

The release notes are available in Release Notes.

More information

More code examples are available under tooling directory.

Bugs Reporting

Bug Reports are directly in the source code repository can be submitted on: Issues

License

The CCSDS MO services are licensed under: European Space Agency Public License (ESA-PL) Weak Copyleft - v2.0