Exemple d'application – Implémenter une architecture SOA

En entreprise, il est difficile :

 de commencer à developper une application en java à partir d'un système vierge ou d'une
page blanche et

 encore plus d'être seul à travailler sur le projet.

En général, il s'agit d'un un système composé de dizaines voire de centaines d'applications, qui
s'envoient des messages, communiquent et qui peuvent se trouver dans des serveurs locaux, dans
des serveurs distant ou dans le cloud.
Dans le SI (système d'information) d'une entreprise, chaque application peut avoir son propre
protocole de communication, ses propres formats de messages, etc.
Plusieurs questions peuvent alors se poser :

 Comment créer votre application de façon à ce qu'elle communique parfaitement avec les
autres ?

 Comment concevoir toutes les applications du SI dès le départ pour qu'elles communiquent
toutes via un protocole et un format standard et compris de tous ?

 Comment éviter de réinventer le roue : savoir si certaines fonctionnalités existent déjà dans
d'autres applications ou chercher la possibilité de réutiliser certains composant afin d'éviter
la redondance ?

 Comment savoir à quelle URL ou IP se situe telle ou telle application avec laquelle vous
voulez communiquer ?
Le but de cet exemple est de :

 montrer comment une entreprise peut organiser son SI afin que toutes les applications
communiquent via un seul protocole (SOAP pour le cas de cet exemple)

 apprendre à découper une application en services

 apprendre à créer et tester les services dans le respect des normes SOA

NB : il ne vous est pas demandé de pouvoir créer une architecture SOA à partir de zéro mais plutôt
de pouvoir créer des services qui s'intègrent dans une architecture existante

Phase 1 - Description du SI l'existant

Le SI existant est composé d'un ensemble d'applications communiquant à travers divers adaptateurs
utiilisés pour convertir, traduire et reformater les messages entre applications.
  ERP SAV : est un logiciel propriétaire dont le protocole de communication est JSON via
HTTP et fixé par le constructeur

 Boutique en ligne : CMS dont le protocole de communication est XML via HTTP

 ERP comptabilité : logiciel propriétaire dont le protocole de communication est CSV via
FTP et ficé par le constructeur

 Commande grossiste : web service à developper

Phase 2 – Définition du web service

le descriptif du service « commande grossiste » est le suivant:
◦ Le composant devra recevoir des fichiers CSV par FTP dans lesquels des grossistes
auront dressés la liste des produits à commander et leurs quantités.
◦ Ce fichier est ensuite stocké dans un répertoire. Les grossistes doivent pouvoir le
mettre à jour ou le supprimer tant que la commande n’a pas été traitée.
◦ Le module doit passer à des heures fixes (10h et 16h) pour relever les fichiers et
passer les ordres des commandes.
◦ Il doit ensuite créer un fichier CSV de réponse à mettre dans le même répertoire FTP
et qui contient le suivi des commandes : acceptée, traitée, expédiée, annulée, etc.
◦ Les grossistes reçoivent un email quand leurs commandes passent à certains états :
traitée, annulée.

Etape 1 – définition des fonctionnalités

Les fonctionnalités qui en découlent sont les suivantes :

 Fonction d’upload et de suppression de fichiers de commandes CSV via FTP

 Fonction de validation des fichiers CSV

 Fonction de récupération à heures fixes des commandes

  Fonction de passage des ordres des commandes

 Fonction de suivi des commandes : vérification du statut et mise à jour du CSV de

suivi

 Envoi des emails en fonction des statuts des commandes

Etape 2 - Découpage du composant en web services

Plusieurs solutions sont envisageables dans le découpage d'un composant en web services. En
général, l'on s'appuie sur deux principes pour guider le découpage

 Principe 1 : Le service web doit être IRA (Interesting – Reusable - Atomic)

 Principe 2 : Le service web doit respecter les 8 normes de SOA

On peut donc ainsi dresser une liste de services parmis lesquels:

 Service 1 : Reçoit un fichier en entrée et l’upload dans un répertoire. Il peut également

supprimer un fichier ou le remplacer.

 Service 2 : Reçoit des fichiers dans des formats populaires (CSV, XML, etc.) et les valide.

 Service 3 : Reçoit en entrée un fichier CSV puis place les ordres de commandes ; Reçoit en
entrée une information de mise à jour de commande, puis met à jour le CSV de suivi des
commandes.

 …

 Service n :

Etape 3 – faire communiquer les composants 'Non SOAP' à l'aide d'un ESB
Problème : système incluant plusieurs composants logiciels qui ne communiquent pas via les
mêmes protocoles, qui ne sont pas écrits dans les mêmes langages et qui sont malgré tout
extrêmement dépendants les uns des autres.

Solution : utiliser un ESB (Enterprise Service Bus). L'ESB est un composant central qui se
positionnera comme un interlocuteur unique pour tous les composants du SI.
Ainsi, pour appeler un composant X, Il suffira d'envoyer une requête dans le protocole
choisi (SOAP dans notre cas) à l'ESB. Celui-ci s'occupera ensuite de faire le nécessaire pour
transformer le message et l'adapter avant de le transférer au composant demandé. Il fera ensuite la
même chose pour la réponse avant de la renvoyer.
 Phase 3 – Implémentation du web-service

Etape 1 – Préparation de l'environnement

les outils ci-dessous doivent être installés :

• IntelliJ IDEA : IDE de développement;

• Glassfish 5 : un serveur d'application Java EE;

• Maven : pour la gestion de projets en JAVA

• le JDK Java 8.

• JAX-WS(Java API for XML Web Services ) - est une API de Java qui facilite la création de
web services. Il permet de cacher entièrement la complexité des communications impliquant
SOAP et WSDL.
• Côté web service : Quand un service externe appellera votre web service, il lui
passera un simple fichier XML aux normes SOAP. Sans JAX-WS, l'on devait
récupérer ce fichier et le parser pour essayer de comprendre quelles méthodes on
cherche à invoquer et quels sont les paramètres passés
• Côté client : JAX-WS vous dispense des longs fichiers XML lors de l'appel des
services web. Lorsque vous souhaitez appeler des web services, vous lui donnez
l'emplacement du WSDL du nouveau service auquel vous voulez faire appel et il se
charge de le parser et de créer des classes Java représentant le service en question.
L'appel des classes créées se fait naturellement comme l'appel dune classe en java.
•

Etape 2 – Implémentation d'un web service avec l'approche bottom-up

On désire implémenter un web service qui reçoit les paramètres suivants :

• le prénom de type String ;
 • le sexe de type String (homme/femme) ;

• l' année de naissance de type Integer.

Et retourne une réponse de type String correspondant au prénom et nombre d'années restant à vivre
(on suppose que l'espérance de vie des hommes est de 79 ans et celle des femmes est de 85 ans).
Le code source du web service est donc le suivant :

NB : deux annotations très importantes dans ce code:

• @WebService : cette annotation dit simplement à JAX-WS que cette Classe est à exposer
en tant que web service. Elle peut prendre plusieurs paramètres mais dans ce cas nous avons
choisi de lui en passer un seul ici : serviceNname = "LifeLeft". Ce nom qu'on vient de
donner à ce service servira ensuite pour accéder à notre service via son URL.
• @WebMethod : cette annotation désigne cette méthode comme une méthode à exposer.
Normalement si on ne précise pas cette annotation, toutes les méthodes de la classe seront
exposées. Il est recommandé d'ajouter cette annotation à chaque méthode que vous voulez
exposer, afin d'avoir la liberté d'ajouter d'autres méthodes supplémentaires pour votre usage
interne, sans que celles-ci puissent être appelées par les services extérieurs.

Etape 3 – mise à jour de Maven

La mise à jour de maven (à travvers la mise à jour du fichier pon.xml) vise à ajouter deux plugins à
savoir :
• Le plugin maven-war-plugin qui permettra à Maven de déclencher les bonnes opérations qui
 aboutiront au packaging du service en .war.
• Le plugin maven-compiler-plugin qui est le compilateur Java de Maven.

Le code du fichier pon.xml est le suivant :

Etape 4 – Packager l'application

A partir de l'IDE IntelliJ, effecuer dans l'ordre les actions suivantes :

• Sélectionner View > Tool Windows > Maven Projects

 • Sélectionner à gauche de la fenêtre Maven, puis dérouler Lifecycle et cliquer sur Install.

La commande est exécutée, et l'application est packagée !

Vous devriez avoir un message Maven indiquant le succès de la commande dans l'onglet Run en bas
de la fenêtre.
Il est possible de vérifier la présence de votre service sous le nom lifeleft.war dans le
nouveau dossier Target créé dans votre projet. On peut donc à présent lancer le service SOAP

Etape 5 – Déployer le service sur le serveur Glassfish

Le serveur Glassfish doit être démarré. Pour le vérifier, aller à http://localhost:4848 . Si tel n'est
pas le cas, veuillez le démarrer avant de poursuivre le déploiement

• Cliquer sur Applications dans le panneau de gauche puis cliquer sur Deploy dans la nouvelle
fenêtre.
• Sous « Packaged File to Be Uploaded to the Server » cliquer sur le bouton puis sélectionner
lifeleft.war sur votre ordinateur. Assurez-vous ensuite que Type: Web Application est choisi

Cliquer sur ok.

• Dans la nouvelle fenêtre, cliquer sur Launch en face de votre service.

• Une page avec 2 liens s'ouvre : un lien http et l'autre en https. Sélectionnez le premier (http).
Vous devez tomber sur une page avec le message "Hello World!". Ce message vient du
fichier index.jsp généré par défaut avec votre projet Maven.

• Pour accéder à votre service, ajoutez à votre URL LifeLeft.

http://nomDeVotreOrdinateur.local:8080/lifeleft6252936251939052664/LifeLeft
▪ nomDeVotreOrdinateur peut être remplacé par localhost.

Le clien sur le lien ci-dessous conduit à la page

 Etape 6 – Tester le service

Le service tourne sur le serveur glassfish. Pour le tester, ajoutez ?Tester à votre URL :
http://nomOrdinateur.local:8080/lifeleft6252936251939052664/LifeLeft?Tester
Vous retrouverez alors la méthode précédemment créée avec 3 champs correspondant aux trois
paramètres prénom, sexe et année de naissance.