2024-09-25-multiple-protocol-versions

Multiple protocol versions

Decision

We will introduce a protocolVersion concept that will be carried in the current protocol property, that will drive the selection the right protocol version for connector to connector communication.

The protocol convention will be <protocolName>:<protocolVersion>

Rationale

Currently, EDC supports only DSP in the current stable form. As the spec is evolving, we should prepare the EDC for supporting multiple versions in the same EDC runtime. This will enable the communication between two EDC connectors as long as they agree on a common supported version.

Approach

Since we are enriching the protocol property with a version, no additional changes is required in RemoteMessages, TransferProcess and ContractNegotiation.

We will refactor RemoteMessageDispatcherRegistry to:

public interface RemoteMessageDispatcherRegistry {
    /**
     * Registers a dispatcher.
     */
    void register(String protocol, RemoteMessageDispatcher dispatcher);
}

and we will remove the RemoteMessageDispatcher#protocol method.

This will allow us to register a RemoteMessageDispatcher for multiples protocols, which means for example that in the context of DSP we can register the DspHttpRemoteMessageDispatcher for multiple DSP versions while keeping the service injectable.

In the context of DSP implementation a protocol version consists of:

• A set of Transformers for RemoteMessages serialization/deserialization.
• A scoped JSON-LD @context configured in the JsonLd service.
• A set of Controllers for receiving protocol RemoteMessages.

We should provide BOMs for protocol versions and any common logic between versions should be extracted in *-libs.

Transformers

Instead of having a single TypeTransformerRegistry for the dsp-api context, we should have one for each DSP supported version.

JSON-LD @context

Currently, we bind DSP specific namespaces/contexts definition under the scope DSP. We should have multiple configurations for each supported version

Controllers

We already provide versioned controllers, but each version should have its own JerseyJsonLdInterceptor for injecting the right JSON-LD scope. This can be achieved using jakarta.ws.rs.container.DynamicFeature interface.

The protocol + version should be added also in DspRequest for selecting the right RemoteMessages transformers.

Further considerations

We should expose in the Management context an API for fetching the supported versions of a counterParty

We might apply in the future a way to automatically negotiate a common supported version if no version is specified.