Migrer des applications JMS (Java Message Service) 2.0 existantes d’Apache ActiveMQ vers Azure Service Bus
Cet article explique comment modifier une application Java Message Service (JMS) 2.0 qui interagit avec un répartiteur JMS afin qu’elle interagisse avec Azure Service Bus à la place. En particulier, l’article traite de la migration à partir d’Apache ActiveMQ ou d’Amazon MQ.
Azure Service Bus prend en charge les charges de travail de la plateforme Java 2, Édition Entreprise et Spring qui utilisent l’API JMS 2.0 sur AMQP (Advanced Message Queueing Protocol).
Avant de commencer
Différences entre Azure Service Bus et Apache ActiveMQ
Azure Service Bus et Apache ActiveMQ sont tous deux des répartiteurs de messages, qui fonctionnent en tant que fournisseurs JMS avec lesquels les applications clientes échangent des messages. Ils activent tous les deux la sémantique point-à-point avec des files d’attente et la sémantique de publication-abonnement avec des rubriques et des abonnements.
Même dans ce cas, il existe des différences entre les deux, comme le montre le tableau suivant :
| Category | ActiveMQ | Azure Service Bus |
|---|---|---|
| Hiérarchisation des applications | Monolithe en cluster | À deux niveaux (passerelle + back-end) |
| Prise en charge de protocole |
|
AMQP |
| Mode de provisionnement |
|
Plateforme managée en tant que service (PaaS) |
| Taille des messages | Configurable par le client | 100 Mo (niveau Premium) |
| Haute disponibilité | Managée par le client | Managée par la plateforme |
| Récupération d'urgence | Managée par le client | Managée par la plateforme |
Fonctionnalités prises en charge et non prises en charge actuellement
Le tableau suivant présente les fonctionnalités Java Message Service (JMS) actuellement prises en charge par Azure Service Bus. Il présente également des fonctionnalités non prises en charge.
| Fonctionnalité | API | Statut |
|---|---|---|
| Files d’attente |
|
Pris en charge |
| Rubriques |
|
Pris en charge |
| Files d’attente temporaires |
|
Pris en charge |
| Rubriques temporaires |
|
Pris en charge |
| Producteur de messages / JMSProducer |
|
Pris en charge |
| Explorateurs de files d'attente |
|
Pris en charge |
| Consommateur de messages/ JMSConsumer |
noLocal n'est actuellement pas pris en charge |
Pris en charge |
| Abonnements durables partagés |
|
Pris en charge |
| Abonnements durables non partagés |
noLocal n'est actuellement pas pris en charge et doit être défini sur false |
Pris en charge |
| Abonnements non durables partagés |
|
Pris en charge |
| Abonnements non durables non partagés |
noLocal n'est actuellement pas pris en charge et doit être défini sur false |
Pris en charge |
| Sélecteurs de messages | dépend du consommateur créé | Pris en charge |
| Délai de livraison (messages planifiés) |
|
Pris en charge |
| Message créé |
|
Pris en charge |
| Transactions entre entités |
|
Pris en charge |
| Transactions distribuées | Non pris en charge |
Considérations
La nature à deux niveaux d’Azure Service Bus offre différentes fonctionnalités de continuité d’activité (haute disponibilité et reprise d’activité). Toutefois, certaines considérations sont à prendre en compte quand vous utilisez des fonctionnalités JMS.
Mises à niveau de service
En cas de mises à niveau et de redémarrages de Service Bus, les files d’attente ou les rubriques temporaires sont supprimées. Si votre application est sensible à la perte de données dans les files d’attente ou les rubriques temporaires, n’utilisez pas de files d’attente ou de rubriques temporaires. Utilisez à la place des files d’attente, des rubriques et des abonnements durables.
Migration des données
Dans le cadre de la migration et de la modification de vos applications clientes pour qu’elles interagissent avec Azure Service Bus, les données conservées dans ActiveMQ ne sont pas migrées vers Service Bus. Une application personnalisée peut vous être nécessaire pour vider les files d’attente, les rubriques et les abonnements ActiveMQ, puis relire les messages dans les files d’attente, les rubriques et les abonnements de Service Bus.
Authentification et autorisation
Le contrôle d’accès en fonction du rôle Azure (Azure RBAC) soutenu par Microsoft Entra ID est le mécanisme d’authentification à privilégier pour Service Bus. Pour activer le contrôle d’accès en fonction du rôle, suivez les étapes décrites dans le guide du développeur Azure Service Bus JMS 2.0.
Prémigration
Vérification de la version
Vous utilisez les composants et versions suivants lors de l’écriture des applications JMS :
| Composant | Version |
|---|---|
| API JMS (Java Message Service) | 1.1 ou ultérieure |
| Protocole AMQP | 1.0 |
Vérifier que les ports AMQP sont ouverts
Service Bus prend en charge la communication par le biais du protocole AMQP. À cet effet, activez la communication sur les ports 5671 (AMQP) et 443 (TCP). Selon l’emplacement où les applications clientes sont hébergées, vous pouvez avoir besoin d’un ticket de support pour autoriser la communication sur ces ports.
Important
Service Bus prend uniquement en charge le protocole AMQP 1.0.
Élaborer des configurations d’entreprise
Service Bus offre différentes fonctionnalités de haute disponibilité et de sécurité de l’entreprise. Pour plus d'informations, consultez les pages suivantes :
- Points de terminaison de service de réseau virtuel
- Pare-feu
- Chiffrement côté service avec clé gérée par le client (BYOK)
- Points de terminaison privés
- Authentification et autorisation
Supervision, alertes et suivi
Pour chaque espace de noms Service Bus, vous publiez des métriques sur Azure Monitor. Vous pouvez utiliser ces métriques à des fins d’alerte et de mise à l’échelle dynamique des ressources allouées à l’espace de noms.
Pour plus d’informations sur les différentes métriques et sur la configuration d’alertes sur celles-ci, consultez Métriques Service Bus dans Azure Monitor. Vous pouvez également consulter les articles sur le suivi côté client des opérations de données et la journalisation opérationnelle/des diagnostics pour les opérations de gestion.
Métriques - New Relic
Vous pouvez établir une correspondance entre les métriques ActiveMQ et les métriques Azure Service Bus. Consultez les informations suivantes sur le site New Relic :
Notes
New Relic n’offre pas d’intégration fluide et directe à ActiveMQ, mais des métriques sont disponibles pour Amazon MQ. Amazon MQ étant dérivé d’ActiveMQ, le tableau suivant mappe les métriques New Relic d’AmazonMQ à Azure Service Bus.
| Regroupement des métriques | Métrique Amazon MQ/ActiveMQ | Métrique Azure Service Bus |
|---|---|---|
| Service Broker | CpuUtilization |
CPUXNS |
| Service Broker | MemoryUsage |
WSXNS |
| Service Broker | CurrentConnectionsCount |
activeConnections |
| Service Broker | EstablishedConnectionsCount |
activeConnections + connectionsClosed |
| Service Broker | InactiveDurableTopicSubscribersCount |
Utiliser les métriques des abonnements |
| Service Broker | TotalMessageCount |
Utiliser le niveau file d’attente/rubrique/abonnement activeMessages |
| File d’attente/Rubrique | EnqueueCount |
incomingMessages |
| File d’attente/Rubrique | DequeueCount |
outgoingMessages |
| File d'attente | QueueSize |
sizeBytes |
Migration
Pour migrer votre application JMS 2.0 existante afin d’interagir avec Service Bus, suivez les étapes décrites dans les sections suivantes.
Exporter la topologie à partir d’ActiveMQ et créer les entités dans Service Bus (facultatif)
Pour que les applications clientes puissent se connecter de façon fluide à Service Bus, migrez la topologie (y compris les files d’attente, les rubriques et les abonnements) d’Apache ActiveMQ vers Service Bus.
Notes
Pour les applications JMS, vous créez les files d’attente, les rubriques et les abonnements en tant qu’opération d’exécution. La plupart des fournisseurs JMS (courtiers de messages) vous donnent la possibilité de les créer au moment de l’exécution. C’est pourquoi cette étape d’exportation est considérée comme facultative. Pour être sûr que votre application dispose des autorisations nécessaires pour créer la topologie au moment de l’exécution, utilisez la chaîne de connexion avec les autorisations Manage SAS.
Pour ce faire :
- Utilisez les outils en ligne de commande ActiveMQ pour exporter la topologie.
- Recréez la même topologie à l’aide d’un modèle Azure Resource Manager.
- Exécutez le modèle Azure Resource Manager.
Importer la dépendance Maven pour l’implémentation JMS Service Bus
Pour garantir une connectivité fluide avec Service Bus, ajoutez le package azure-servicebus-jms en tant que dépendance au fichier Maven pom.xml, comme suit :
<dependencies>
...
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>azure-servicebus-jms</artifactId>
</dependency>
...
</dependencies>
Modifications de configuration du serveur d’applications
Cette partie est personnalisée pour le serveur d’applications qui héberge vos applications clientes se connectant à ActiveMQ.
Applications Spring
Mettre à jour le fichier application.properties
Si vous utilisez une application Spring Boot pour vous connecter à ActiveMQ, supprimez les propriétés spécifiques à ActiveMQ du fichier application.properties.
spring.activemq.broker-url=<ACTIVEMQ BROKER URL>
spring.activemq.user=<ACTIVEMQ USERNAME>
spring.activemq.password=<ACTIVEMQ PASSWORD>
Ensuite, ajoutez les propriétés propres à Service Bus au fichier application.properties.
azure.servicebus.connection-string=Endpoint=myEndpoint;SharedAccessKeyName=mySharedAccessKeyName;SharedAccessKey=mySharedAccessKey
Remplacer ActiveMQConnectionFactory par ServiceBusJmsConnectionFactory
L’étape suivante consiste à remplacer l’instance de ActiveMQConnectionFactory par ServiceBusJmsConnectionFactory.
Notes
Les modifications de code réelles sont propres à l’application et à la façon dont les dépendances sont gérées, mais l’exemple suivant fournit des conseils sur ce qui doit être changé.
Auparavant, vous deviez instancier un objet d’ActiveMQConnectionFactory, comme suit :
String BROKER_URL = "<URL of the hosted ActiveMQ broker>";
ConnectionFactory factory = new ActiveMQConnectionFactory(BROKER_URL);
Connection connection = factory.createConnection();
connection.start();
À présent, vous instanciez un objet de ServiceBusJmsConnectionFactory, comme suit :
ServiceBusJmsConnectionFactorySettings settings = new ServiceBusJmsConnectionFactorySettings();
String SERVICE_BUS_CONNECTION_STRING = "<Service Bus Connection string>";
ConnectionFactory factory = new ServiceBusJmsConnectionFactory(SERVICE_BUS_CONNECTION_STRING, settings);
Connection connection = factory.createConnection();
connection.start();
Postmigration
Maintenant que vous avez modifié l’application pour qu’elle commence à envoyer et à recevoir des messages de Service Bus, vous devez vérifier qu’elle fonctionne comme prévu. Quand cette opération est terminée, vous pouvez affiner et moderniser votre pile d’application.
Étapes suivantes
Utilisez Spring Boot Starter pour Azure Service Bus JMS afin de bénéficier d’une intégration fluide à Service Bus.
Pour plus d’informations sur la messagerie Service Bus et JMS, consultez :