Customizable envelope formatting (Integration, standardization, interop)

[ramonsmits]

Describe the feature.

At the moment all transports use a fixed hardcoded formatting/mapping from the TransportOperation from/to the native message type.

It uses the native headers with the serialized message as the body when that is available. Otherwise it will use a transport specific envelope that sometimes can even result in non optimal double serialization. (Serialize the message, serialize it again in the envelope)

Having the ability to configure different envelopes would writing interop between different platforms easier.

By default we could stick with the NServiceBusEnvelopeFormatter for maximum backwards compatibility but we would have additional converters like one that is compatible with the default MassTransit format (headers and body in the native body payload) or with CloudEvents .

By having an API on each transport customers could create custom formatters for niche integrations.

A huge benefit for customers is that they get the benefits of influencing the low-level wire format on the transport but also still benefit from the regular message processing pipeline for handling messaging.

Additional Context

No response

[unixunion]

I need this too, as I need portability between technologies, for which CloudEvent would solve a lot of issues and complexity.