A connector is a MicroProfile Reactive Messaging service-provider interface implementation that extends application channels to external messaging providers. It forms the boundary between a reactive message flow and services such as Kafka, RabbitMQ, or JMS, while keeping channel code unchanged. section 9.3 section 9.5.1
In Quarkus, SmallRye Reactive Messaging supplies the connector implementation. Application methods still use @Incoming and @Outgoing; per-channel configuration determines whether messages are pushed to or pulled from a remote provider. Changing that configuration can remap a channel without changing reactive messaging code. section 9.10 section 9.5.1
Configure connectors through standard MicroProfile Reactive Messaging properties:
- Set the connector for each incoming or outgoing channel; a channel used in both directions requires separate directional configuration. section 9.5.2
- Use implementation-defined names such as smallrye-kafka, smallrye-rabbitmq, or smallrye-jms. section 9.5.1
- Add provider connection settings, such as a Kafka production endpoint or JMS queue URL; Dev Services can supply development connections. section 9.5.2 section 9.10
- Remember that unconfigured channels use the in-memory connector by default, and an in-memory channel takes precedence when applicable. section 9.5.2
One reactive pipeline, different brokers
A Billing service can exchange asynchronous messages with a Reservation service through RabbitMQ using AMQP 0-9-1 and communicate with a Rental service through Kafka. The reactive pipeline remains based on @Incoming and @Outgoing, while connector configuration selects each remote provider. section 9.9
Figure 9.7 The connectors architecture
Use the architecture diagram to trace the connector boundary between application channels and remote messaging services. section 9.5.1
