Episode goal: show that messaging in Chenile is the same architecture — interface over implementation, one pipeline for every entry point — extended from request/response to events. Demo swapping a transport without touching business code.
Cold open
On camera: “We’ve separated interface from implementation for services, policies and tests. Last stop: messaging. Your code should not know whether an event rides MQTT, Kafka, Azure — or never leaves the JVM.”
The interface
On screen: open
ChenilePub and ChenileSub in chenile-pub-sub. Voiceover: “This is the entire contract a service sees — publish, asyncPublish, publishToOperation, and messageArrived. No broker types anywhere.”publishToOperation
Point at
publishToOperation(service, operationName, …). “Publishing can target a service operation, resolved through the same service registry that carries a service’s policies. Messaging is a first-class entry point, not a side channel.”Lower third
“One interface. Four implementations.” Show the diagram: the interface bar fanning out to MQTT, Kafka, Azure, in-JVM.
Demo — swap the transport
Run a publisher wired to chenile-jvm-pub-sub (no broker) — messages flow in-process. Then change configuration/dependency to chenile-mqtt or chenile-kafka and re-run the same service code against a real broker. “Not one line of business code changed. That’s the abstraction being real.”
The key insight
Voiceover: “Here’s why this matters beyond portability. An inbound message is normalized into a
ChenileExchange and run through the same interception pipeline as an HTTP call. So your security, tenancy, i18n and logging policies apply to events automatically — you never write a second authorization path.”On screen
Animate: message → ChenileExchange → interception pipeline (policies) → the same service operation an HTTP request would hit.
Cloud-edge
Briefly show
cloud-edge-switch: “The same messages route between edge devices and a cloud broker — event originates at the edge, handled centrally with identical logic.”Callback
“Same philosophy as everything else: depend on the interface, choose the implementation by configuration. Chenile is an in-VM message bus that also speaks HTTP.”
Recap card
“Messaging =
chenile-pub-sub interface + swappable transports (mqtt/kafka/azure/jvm). Every message runs the same pipeline, so policies just work.”Companion reading: Messaging: one interface, many transports