Feature Request
Currently the DSP message classes (ContractNegotiationRequestMessage, TransferProcessStartMessage, ...) are subclass of RemoteMessage, but in fact they should not, because they are just representing the payload of a DSP message, not the whole envelope with metadata as protocol, counterPartyAddress, policy and so on.
Why Is the Feature Desired?
make all the classes immutable (at the moment there are some setters that could be avoided with the new design), separate responsibilities.
Who will sponsor this feature?
Please @-mention the committer that will sponsor your feature.
Solution Proposal
My proposal would be to create two new classes:
DspIngressMessageDspEgressMessage
both extending RemoteMessage, that will contain the metadata plus the message payload class.
The current DSP message classes won't be extending RemoteMessage, maybe a DspMessagePayload marker interface will be introduced
Feature Request
Currently the DSP message classes (
ContractNegotiationRequestMessage,TransferProcessStartMessage, ...) are subclass ofRemoteMessage, but in fact they should not, because they are just representing the payload of a DSP message, not the whole envelope with metadata asprotocol,counterPartyAddress,policyand so on.Why Is the Feature Desired?
make all the classes immutable (at the moment there are some setters that could be avoided with the new design), separate responsibilities.
Who will sponsor this feature?
Please @-mention the committer that will sponsor your feature.
Solution Proposal
My proposal would be to create two new classes:
DspIngressMessageDspEgressMessageboth extending
RemoteMessage, that will contain the metadata plus the message payload class.The current DSP message classes won't be extending
RemoteMessage, maybe aDspMessagePayloadmarker interface will be introduced