Closed agoncal closed 1 year ago
We need to think it from serveral layer 1) Message server you are using ( rabbit, kalfka): jar file and configuration file 2) message framework: jms, spring-message: jar file and configuration jms is server independent, but spring-message sometime is server dependent, like 1) in server bus, the annotation ServiceBusListener 2) in rabbitmq, the annothation RabbitListener
We already have a SpringBoot rule on MQ: https://github.com/Azure/windup-rulesets/blob/main/rules/rules-reviewed/azure/springboot/spring-boot-to-azure-mq-config.windup.xml
@brunoborges @showpune as we only have an Active MQ rule for now, shall we create/override rules on:
I think Kafka is a must for the MVP.
PR on its way: https://github.com/Azure/windup-rulesets/pull/114
This rule highlights use of on-premises message queues which will need replaced with Azure alternatives such as Azure Service Bus or Azure Storage Queues. Specific patterns for identifying these vary based on the specific dependencies, but the most common are:
RabbitMQ.Client
namespace which would indicate use of a local RabbitMQ instance.MassTransit.Bus.Factory.CreateUsingRabbitMq
API which also indicates RabbitMQ use.Microsoft.ServiceBus.Messaging
APIs with a connection string of the formsb://<host>/<namespace>
(as opposed tosb://<namespace>.servicebus.windows.net
). This one is a bit nuanced becauseMicrosoft.ServiceBus.Messaging
might be used to connect to either on-premises Service Bus instances or Azure-hosted ones, and only on-premises service bus usage is problematic.These metadata are interesting to both Azure App Service and containerized targets.
Java specific things to review:
Existing WindUp Rules
Existing Azure Documentation
WindUp Discovered Messaging Services
The
connect.windup.groovy
technology rule already checks for:Supported Azure Messaging Services