NServiceBus and CloudEvents

[johnsimons]

CloudEvents is a specification for describing event data in a common way. CloudEvents seeks to dramatically simplify event declaration and delivery across services, platforms, and beyond.

NServiceBus currently does not natively support CloudEvents.

We are currently capturing requirements in understanding customer needs when it comes to CloudEvents.

Here are some leading questions that we are interested in understanding more:

• Are you looking for better interoperability with native products like Azure EventGrid, AWS EventBridge via transformations or GCP EventArc?
• Are you looking for interoperability with other messaging frameworks like MassTransit or Wolverine?
• What protocol bindings would you use, for example, HTTP, AMQP, MQTT, NATS, or something else?
• Are you using other languages aside from dotnet csharp?
• Are you more interested in sending or receiving CloudEvents?
• Are you already using CloudEvents on your system?

[SeanFeldman]

✋ Azure EventGrid emitted events

[Antoine-DePauw]

Working at a client with 100+ vhosts with active/active RabbitMQ cluster, half the company is using Dapr with cloud events and integration is difficult because of interoperability issues

We are looking for the same convenience as convention based and message metadata as with regular IEvent/IMessage/ICommand but with the cloud event enveloppe, so we can use another app's nuget to easily create handlers for their message types

A pull request was already done for Dapr to support manipulation of message headers and properties which solves half the problem, but using the cloud event envelope for populating these in NServiceBus would increase interoperability a lot

[mauroservienti]

We are working towards introducing envelope support in NServiceBus in #7422 and for CloudEvents in https://github.com/Particular/NServiceBus.Envelope.CloudEvents/pulls.

At the moment, the scope is primarily about receiving CloudEvents, but not sending. @Antoine-DePauw, your integration scenario is a bi-directional one?

[Antoine-DePauw]

Hi @mauroservienti this is a receive only scenario for now but we plan to introduce cloud events for send scenarios as well in short/mid term... always good to support at least two patterns in large companies with autonomous departments.

[mauroservienti]

Thanks for the feedback, @Antoine-DePauw. We are also looking into supporting send scenarios. However, we realized there are plenty of possible permutations when it comes to sending, and we prefer not to delay supporting receiving in the first place.

I'll make sure to also post updates on this issue as we proceed with the implementation.

[Antoine-DePauw]

While many scenarios are indeed possible I think (from what I could grasp during the discussions I had) that the main (most used?) one would be to map the event (class or interface) contract to the "Data" attribute of the cloud event and the headers and properties to the rest of the attributes, based on openness of the cloud event standard...