O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Eclipse Kapua messaging refactoring proposal

589 visualizações

Publicada em

Kapua messaging refactoring proposal

Publicada em: Tecnologia
  • Entre para ver os comentários

Eclipse Kapua messaging refactoring proposal

  1. 1. Brought to you by Dejan Bosanac and Henryk Konsek Eclipse Kapua Messaging refactoring proposal
  2. 2. Dejan Bosanac - Messaging rock star :) @dejanb @hekonsek
  3. 3. Henryk Konsek - engineer at Red Hat - open source junkie @hekosek@dejanb @hekonsek
  4. 4. ● Kapua messaging now ● How can we make it better? ● Action plan This presentation @dejanb @hekonsek
  5. 5. Kapua messaging now @hekonsek@dejanb @hekonsek
  6. 6. Kapua messaging now @hekonsek@dejanb @hekonsek
  7. 7. Kapua messaging now @hekonsek - Authentication - Apache Shiro state - Connection metrics - Device lifecycle events All combined into a single ActiveMQ broker uber-plugin. @dejanb @hekonsek
  8. 8. Implications @hekonsek - Kapua can be run on ActiveMQ only, as it relies on ActiveMQ uber-plugin - You cannot deploy Kapua services as microservices (single VM limitation), as Shiro context is bound to the broker thread @dejanb @hekonsek
  9. 9. Why is it bad? @hekonsek - Is very challenging to scale Kapua horizontally - Not everybody has to prefer ActiveMQ as messaging layer - Kapua is not PaaS friendly @dejanb @hekonsek
  10. 10. Benefits of new approach @hekonsek - Kapua running on any AMQP 1.0 compliant messaging middleware - Migration to microservices architecture - Scalability - First step for Eclipse Hono integration - Pluggable authentication support - PaaS-enablement (for example running Kapua in Kubernetes/OpenShift will be very easy) @dejanb @hekonsek
  11. 11. How can we make it better? @hekonsek@dejanb @hekonsek
  12. 12. Warning! @hekonsek - Contract of existing MQTT clients (i.e. devices) should be respected - Device should not be aware that it talks to “new” messaging backend - Backward compatibility FTW! @dejanb @hekonsek
  13. 13. Starting point @hekonsek@dejanb @hekonsek
  14. 14. Step #1: Extract messaging @hekonsek - Extract messaging out of the Kapua JVM - Messaging provider must support AMQP, may support MQTT @dejanb @hekonsek
  15. 15. Authentication @hekonsek - It is messaging layer responsibility to perform authentication if needed - Kapua services should support multiple pluggable strategies to resolve user/tenant from authenticated message - Authentication can be optionally delayed and performed on service level (authentication on message level, not connection level) @dejanb @hekonsek
  16. 16. Shiro context binding @hekonsek - Services use Camel + Shiro to hold security context - The same way as Kapua does today, but outside the broker threads and JVM @dejanb @hekonsek
  17. 17. Reference implementation @hekonsek - In reference implementation we can use Artemis broker authentication against KeyCloak (or something else) @dejanb @hekonsek
  18. 18. Step #2: Extract metrics into library @hekonsek - Extract metrics logic into library - You can use it on the service (Camel) level or… - wrap it into msg middleware plugin (for example Artemis plugin)
  19. 19. Step #3: Extract lifecycle into library @hekonsek - the same as for metrics library :) - If you messaging middleware doesn’t allow you to wire library into it you need to compensate events logic in services layer
  20. 20. Action plan @hekonsek@dejanb @hekonsek
  21. 21. How can we do it? @hekonsek - I propose to keep existing broker plugin as it is - Work on the alternative approach in parallel - At some point just drop old plugin, switch to the new architecture and celebrate :) @dejanb @hekonsek
  22. 22. Any volunteers? @hekonsek - Dejan and Henry - We will handle that. Just give us a green light! ;) - Any other volunteers are more than welcome! @dejanb @hekonsek
  23. 23. Henryk Konsek @hekonsek hekonsek@gmail.com @hekonsek Thank you! Dejan Bosanac @dejanb dbosanac@redhat.com @dejanb @hekonsek

×