anchor.diff:  To retrofit the original service into a Quarkus-based application, only a few changes were needed:
   
    * Quarkus right now supports only MariaDB but not MySQL; hence we have included an instance of MariaDB to which the service is writing
  - * The https://javaee.github.io/jsonp/[JSON-P API] used do deserialize incoming JSON messages is not supported yet; so the code has been modified to use the Jackson API which is already is supported by Quarkus
  - * Instead of the Kafka consumer API, the https://github.com/eclipse/microprofile-reactive-messaging[Reactive Messaging API] defined by MicroProfile is used to receive messages from Apache Kafka; as an implementation of that API, the one provided by the https://github.com/smallrye/smallrye-reactive-messaging[SmallRye project] is used.
  -
  -While the first two steps shouldn't be needed eventually, as Quarkus gains support for more technologies and APIs over time,
  + * The https://javaee.github.io/jsonp/[JSON-P API] used do deserialize incoming JSON messages can currently not be used without RESTEasy (see https://github.com/quarkusio/quarkus/issues/1480[issue #1480], which should be fixed soon); so the code has been modified to use the Jackson API instead
  + * Instead of the Kafka consumer API, the https://github.com/eclipse/microprofile-reactive-messaging[Reactive Messaging API] defined by MicroProfile is used to receive messages from Apache Kafka; as an implementation of that API, the one provided by the https://github.com/smallrye/smallrye-reactive-messaging[SmallRye project] is used, which is bundled as a Quarkus extension
  +
  +While the first two steps are mere technicalities,
   the Reactive Messaging API is a nice simplification over the polling loop in the original consumer.
   All that's needed to consume messages from a Kafka topic is to annotate a method with `@Incoming`,
  -and will automatically be invoked when a new message arrives:
  +and it will automatically be invoked when a new message arrives:
   
   [source,java]
   ----
  
positive.code: 
  == Configuration
  
  The application contains two configuration files:
  
   * _application.properties_: the default configuration file of Quarkus applications; contains the definition of a datasource (based on MariaDB) to which the shipment service writes its data
   * _META-INF/microprofile-config.properties_: contains a definition of the Kafka topic from which we consume the outbox events and the Kafka consumer group id
  
  == Execution
  
  
negative.code: you can find the complete https://github.com/debezium/debezium-examples/tree/master/outbox/shipment-service-quarkus[source code] of the implementation in the Debezium examples repo.
  If you got any questions or feedback, please let us know in the comments below;
  looking forward to hearing from you!
  
  _Many thanks to Guillaume Smet for reviewing an earlier version of this post!_
  
  == About Debezium
  
  