Les étapes à suivre :
@Path
@GET
@POST
En utilisant JakartaEE et Spring Boot, votre application sera flexible, conforme à Java SE et modulaire avec JakartaEE.
Par rapport à une API REST standard, les microservices apportent plusieurs avantages, tels que :
Nous verrons cela ultérieurement avec du code pour découvrir les petites différences.
Petite liste rapide :
L’intérêt de cette notion de microservice consiste à faciliter la maintenance et la scalabilité. Cependant, il faut que les interfaces entre les différents microservices de votre application ne génèrent pas de dépendances inutiles !
Voici un microservice de messagerie qui gère les notifications et les messages envoyés à l’utilisateur, tels que les notifications par email lorsqu’une commande est passée par un utilisateur.
Dépendances JakartaEE à notre fichier pom.xml :
<!-- https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-api --> <dependency> <groupId>jakarta.platform</groupId> <artifactId>jakarta.jakartaee-api</artifactId> <version>10.0.0</version> <scope>provided</scope> </dependency>
ou avec Gradle :
// https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-api compileOnly group: 'jakarta.platform', name: 'jakarta.jakartaee-api', version: '10.0.0'
Nous allons utiliser l’interface JakartaEE javax.ejb.Singleton pour garantir qu’une seule instance de notre service soit créée dans l’application. Si vous ne connaissez pas ce design pattern, lisez le cours sur les Design Pattern et Java. Nous allons aussi utiliser l’interface javax.ejb.Startup pour démarrer notre service lorsque l’application se lance !
Vous voyez que nos interfaces sont en fait utilisées sous forme d’annotations avec @ ;)
@
import javax.ejb.Singleton; import javax.ejb.Startup; @Singleton @Startup public class MessagingService { public void sendNotification(String email, String message) { // votre code pour envoyer une notification par email ou SMS si vous avez un opérateur } }
Nous allons écrire un contrôleur REST basique qui appelle notre service de messagerie lorsqu’un utilisateur passe une commande ou bien une autre action selon les fonctionnalités souhaitées. Pour cela, nous utilisons l’annotation javax.ws.rs.POST pour définir notre méthode de contrôleur comme une méthode HTTP POST que vous connaissez à ce stade du développement.
import javax.inject.Inject; import javax.ws.rs.POST; import javax.ws.rs.Path; @Path("/commande") public class CommandeController { @Inject private MessagingService messagingService; @POST public void passerCommande(String email) { // votre code pour enregistrer votre commande ou autre // Envoyez une notification par email ou SMS messagingService.sendNotification(email, "Votre commande a été exécutée avec succès !"); } }
Notre classe MessagingService pourrait ressembler au code ci-dessous :
public class MessagingService { public void sendNotification(String email, String message) { // Implementation de l'envoi de la notification par email // Utilisation d'une bibliothèque telle que JavaMail pour envoyer un email à l'adresse fournie try { // Création de la session Properties properties = new Properties(); properties.put("mail.smtp.host", "smtp.numerosoft.fr"); Session session = Session.getInstance(properties); // Création du message MimeMessage mimeMessage = new MimeMessage(session); mimeMessage.setFrom(new InternetAddress("commandes@numerosoft.fr")); mimeMessage.addRecipient(Message.RecipientType.TO, new InternetAddress(email)); mimeMessage.setSubject("Notification de la commande"); mimeMessage.setText(message); // Envoi du message Transport.send(mimeMessage); } catch (MessagingException e) { e.printStackTrace(); } } }
Vous pouvez déployer votre application sur un serveur d’application et tester le service de messagerie en appelant le contrôleur REST avec une requête POST.
L’objectif étant que ce microservice de messagerie assez simple peut être déployé et géré indépendamment de votre application.
Il n’y a pas de réponse définitive à cette question, car cela dépend de plusieurs facteurs :
En général, si notre application web et notre microservice nécessitent des ressources similaires, il est courant de les déployer sur le même serveur d’application. Cependant, si l’application web et le microservice ont des exigences différentes en matière de ressources, il peut être préférable de les déployer sur des serveurs séparés pour garantir une performance optimale.
Oui, il existe un modèle de déploiement de microservice qui consiste en un ensemble de pratiques, de méthodologies et d’outils utilisés pour déployer, gérer et maintenir les microservices d’une application.
Il définit les étapes à suivre pour déployer les microservices sur différents environnements, tels que les environnements de développement, de test et de production. Il décrit également comment gérer les dépendances entre les microservices, comment les maintenir et les mettre à jour de manière transparente pour les utilisateurs finaux.
Les modèles de déploiement de microservice incluent souvent des techniques telles que :
Bonne question !
En réalité, la création d’un microservice peut sembler simple à première vue, mais en réalité, il y a beaucoup de considérations à prendre en compte pour garantir une implémentation efficace et fiable. Planification et tests indispensables pour garantir qu’il fonctionne bien et s’intègre correctement dans l’architecture globale de votre application, ainsi que les sujets abordés plus haut !
On peut les mesurer tout ceci à l’aide des différents outils et techniques ci-dessous :
Il en existe plusieurs :
Bref, vous n’avez que l’embarras du choix, ensuite, il faut prendre le temps de se documenter, de les découvrir et de les tester, alors bon courage !