Queue Manager Selection

MuleSoft is out

Here you can find the consolidated requirement list for the message broker:

1. Total Cost Of Ownership:  the TCO of a message broker is all the setup costs like the purchase price of licenses, installation and integration cost, including the rework of applications plus the cost of operating and maintaining that message broker over its lifespan. 
2. Integrability: The effort required to integrate a chosen technology/platform within those that are already present.  One key requirement here is to be supported by NServiceBus.  Many teams and applications use NServicebus and it’s the best-supported and adopted messaging library inside the .Net community.  Riziv has invested in licenses for NServiceBus and it offers many interesting functionalities for administration and monitoring.  Choosing a message broker supported by NServiceBus will avoid rework in the existing applications and benefit in terms of the learning curve, adoption, cognitive load, and efficiency of developers.
3. Supportability: how well can we support the message broker. How well can it be supported by our  internal (I&O) and external (Smalls) hosting providers?  How easy can we contract commercial support?    Does the tool include management UI, command line tools and API’s.  What is the quality of the documentation?
4. Al-least once delivery:  Achieving exactly-once delivery in case of failure of communication has proven to be impossible.  The message broker should be able to exactly once except in case of very exceptional communication problems and should in all scenarios guarantee at-least once delivery.
5. Performance: performance of a message broker is evaluated based on major factors like throughput, latency and total time taken by the transaction.
6. Maturity: is the message broker used for long enough that most of its first faults and inherent problems have been removed or reduced?
7. Scalability: How much performance gains can we achieve by increasing the resources of 1 node and horizontally by increasing the number of nodes. As we want to have a single message broker shared across Riziv and many institutions scalability is important.
8. Multitenancy: We want to share our message broker across institutions.  How well can connections, queues, user permissions, policies, and resources be segregated and managed by logical groups of entities. 
9. FaultTolerance: How well does the solution cope with failures and eventually recovers from it (e.g. loss of communication, loss of storage …).
10. Cloud Integrability: How well does the solution integrate in a public cloud/hybrid  environment (more specific Azure Cloud for Riziv). Is it available as a PaaS solution? Does it use the underlying cloud service (message bus, storage, monitoring)?
11. Messaging protocol support: Does the message broker support standard messaging protocols?

Architecture Review board : 06/12/2022

On va continuer comme cela a été décidé. On va avancer en parallèle sur le RabbitMQ et l’exploration de la solution ASB.


Lorsqu’on aura une vue sur l’initiation (effort/coût, timing) des 2 solutions, l’équipe plate-forme procédera à une réévaluation et reviendra si nécessaire information le ReviewBoard.