Add Support for CloudEvents

[jamesward]

CloudEvents a CNCF standard for event payloads just reached 1.0. It'd be great to have out-of-the-box support with Spring Cloud Functions. So we could do:

Function<CloudEvent, CloudEvent> foo()

There is an existing API for the payload, marshaling, unmarshalling, but it doesn't yet support version 1.0 of the spec

		<dependency>
			<groupId>io.cloudevents</groupId>
			<artifactId>cloudevents-api</artifactId>
			<version>0.3.1</version>
		</dependency>

Adding this will make integration with Knative Events easier.

[olegz]

@jamesward I knew sooner or later we'll reconnect ;)

[matzew]

@jamesward the lib now has 1.0 support, see: https://github.com/cloudevents/sdk-java/tree/v1.0.0

[olegz]

@jamesward @matzew It seems to me that all we need to do on out end is introduce a MessageConverter implementation for CloudEvent (which is effectively marshaller/unmarshaller).
I'll take a first crack at it following https://github.com/cloudevents/sdk-java/tree/master/api (unless you have something better, but it would be nice if you can delegate someone to review given my inexperience.

[artembilan]

We have similar idea in Spring Integration: spring-projects/spring-integration#3103

[olegz]

That's cool. So i'll go with my plan and then it's really a question where those converters would live (SI or SCSt).

[trisberg]

@olegz have you started this yet? Playing around with functions that accept a CloudEvent as input and would like to have something that implements a JsonMapper and gives me a CloudEvent back. I'm not using any of the SI or SCSt dependencies, maybe this should live either in SCFn along with the Jackson/Gson Mappers or somewhere else.

[olegz]

@trisberg No, I have not started yet, but as I said earlier it appears all that's needed is MessageConverter which is capable of converting from/to CloudEvents. @jamesward given that one of the drivers in our frameworks to pick the correct MessageConverter is content type (e.g., application/json), is there a known or widely used content type for CloudEvents? Something we can rely on?

[jamesward]

It does look like the latest spec uses some specific Content-Type values:
https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md#3-http-message-mapping

Maybe @duglin can help clarify though.

[duglin]

Hi - yes the CE spec does define a content-type that will help you determine if the incoming message is a CE or not - at least for structured CE mode (meaning the HTTP body is wrapped in a CE structure). However, knowing whether some random message is binary CE or not is harder. To try to address this I just created this: cloudevents/spec#577

[olegz]

@jamesward @duglin I am trying, but it appears based on some of the arguments from the gate-keepers of the Cloud Event SDK that we should not even be using CloudEvent type. That it is an anti pattern to have user code to depend on CloudEvent type.
If that's the case then perhaps be we should further clarify as to what such support for us would even mean.

[meltsufin]

Should CloudEvent be instead converted to Message<T>, which is more idiomatic for Spring?

[olegz]

@meltsufin
Not at all. Spring Message is a central fixture of spring-messaging and will remain as such, plus Message can easily represent the cloud event (if you simply go by the spec) as it already provides a compatible structure.
So, it is really a question of CloudEvent as a type and whether it has any additional value.

In any event, I do envision simple transformation/conversion of Message to/from CloudEvent.

[jamesward]

I guess this comes down to whether the CloudEvent SDK folks see it as a shareable construct. Should APIs ever build on CloudEvent? If not, then yeah we could just marshal CloudEvent payloads into Message (and out). But if that is the case, why is there even a CloudEvent SDK?

[duglin]

@jamesward @duglin I am trying, but it appears based on some of the arguments from the gate-keepers of the Cloud Event SDK that we should not even be using CloudEvent type. That it is an anti pattern to have user code to depend on CloudEvent type.
If that's the case then perhaps be we should further clarify as to what such support for us would even mean.

I've asked if we can discuss this on the SDK call tomorrow (right after the normal CE call, which is from 12-1 ET unless it ends early). Anyone is free to join. See: https://docs.google.com/document/d/1OVF68rpuPK5shIHILK9JOqlZBbfe91RNzQ7u_P7YCDE/edit#

[olegz]

Thank you @duglin I will join. Perhaps @bsideup can do as well

[jamesward]

So it looks like maybe some progress on the cloudevents API side of things?

[olegz]

Indeed @jamesward we now have cleanly defined CloudEvent - https://github.com/cloudevents/sdk-java/tree/master/api/src/main/java/io/cloudevents

[jamesward]

Fantastic! Looks much better. Thanks for working through that!

[olegz]

@jamesward things are finally moving. More to come, keeping it open for now

[olegz]

This has been addressed in spring-cloud-function-context module.
However, this work will be contributed to CNCF java SDK. Once accepted there will be minor dependency change, but given that outside of CloudEventAttributesProvider user generally would not interact with the API, this should not be an issue. In any event, by the time 3.1.0.RELEASE is out it should be settled.

This README contains initial usage documentation and sample instructions.
This will also be donated to CNCF java SDK