Consider to support CloudEvents: HeaderMappers, Transformers, MessageConverters etc.
See more info about Java SDK: https://github.com/cloudevents/sdk-java
Also see relevant JIRA for complete story: https://jira.spring.io/browse/INT-948
I see a few open questions here:
- There are a couple of possible mappings from CloudEvent to Message, e.g.,
attributesnatural maps to message headers anddata(plusextensions?) to payload. Or the CE could be the simply be the payload. In this case the Message headers are independent. - Converting from Message to CE raises related questions.
- The sdk supports 3 spec versions. The official spec only includes v1. What is the status of CE versions and which ones should SI support?
I think we need to support both variants:
- Natural mapping of headers and data into a
Messageincoming CE. - A transparent conversion into a CE from message.
On the producer side we indeed can support CE as a payload, but I wonder if all the channel adapters should be fixed for this. Or it would be better just to make end-users to place a CEtoMessageTransformer (or Converter) (or serializer since we are going to send byte[]) before sending CE into the target protocol.
Doesn't look like it worth to chase all the protocol binders since we simply can map a CE instance (or message headers + payload) to an expected CE network structure in one transformer/converter/serializer place.
I'm not familiar with spec versions, but let's implement first of all what is supported by Java SDK!
Thank you for feedback, @dturanski !
I'm not familiar with spec versions, but let's implement first of all what is supported by Java SDK! That's my point. The Java SDK implements 3 versions, e.g., io.cloudevents.v1.CloudEventImpl, io.cloudevents.v02.CloudEventImpl, io.cloudevents.v03.CloudEventImpl. The only documentation I can find on this is https://github.com/cloudevents/spec which only mentions v1.0 but if we depend on the SDK, all versions are available.
Oh! I see what you mean. So, if it is something new for us, we should rely on the latest version! You should adapt from the old version by yourself. Or we can implement adapters on demand...
Re https://jira.spring.io/browse/INT-948. I'm not sure if CE really helps because the real payload is a member of CE T data. The consumer and producer still both need to be aware of the type. spring-tuple, basically a map with type conversion had a similar goals. In any case, I would not standardize on CE for all channel adapters, providing support is OK.