Implémentation de services

Errata

  • Lire “@return false si la livraison de la commande avait déjà été confirmée” dans le descriptif de la méthode livraisonEffectuee
  • Le projet forge inf2018m-2013-base a été mis à jour avec une nouvelle version de livraison.wsdl pour permettre le chargement dans SOAPUI. A noter que le point d'accès est à modifier après coup.

Modalités

Rendu

Ce TP est à rendre pour le 16/10/2013, à raison d'un rendu par binôme. Le rendu se fera par l'intermédiaire d'un projet forge (on fera attention a bien donner au moin le rôle “reporter” à Emmanuel Coquery et à Lionel Medini) contenant:

  • le projet maven mis à jour par vos soins (sans le répertoire target)
  • un fichier README.txt contenant au moins les noms, prénoms et numéros d'étudiants du binôme/trinôme. Toute autre information à transmettre aux enseignants (e.g. justifications de choix techniques) se fera dans ce fichier.

L'identifiant du projet forge (e la forme pxxxxxx-nomprojet) est à saisir dans Tomuss, dans l'UE Tiw5 WebServices, dans la case FORGE_TP3. On fera attention à tagger la révision correspondant au rendu avec le tag TP3.

Les binômes rendant le TP avant le 10/10/2013 à 23h59 (date de la révision taggée TP3 faisant fois) bénéficieront d'un bonus de 3 points sur la note de ce TP.

Il est demandé à ce que les 4 implémentations du service (servlet, @WebServiceProvider et @WebService et code généré) puissent fonctionner simultanément (sur des URL différentes). Le fichier de test SOAPUI devra comporter des test suites pour les 4 URL points d'accès.

Métier

Le projet TIW5 2013 Base1) contient à présent un nouveau module services. Le module model a été mis à jour. On partira de cette nouvelle base pour ce TP.

Créer une classe qui implémente l'interface ILivraison. A cette occasion, on effectuera les modifications nécessaires au module model (ajout d'entités, de dao, etc). La javadoc de l'interface ILivraison donne des détails concernant le comportement attendu des différentes méthodes.

Ecrire quelques tests unitaires pour vérifier le bon fonctionnement de la classe.

Implémentation en servlet

Créer une nouvelle servlet pour implémenter le service LivraisonService du fichier livraisons.wsdl2). On utilisera SAAJ pour la (dé)sérialisation des messages SOAP. On séparera le traitement en trois classes:

  • La gestion des requêtes HTTP et l'extraction du message SOAP dans la servlet
  • Une classe contrôleur qui:
    • effectuera les conversions XML ↔ objet via JAXB
    • appellera les bonnes méthodes métier
  • La classe écrite précédement pour effectuer le traitement métier.

Tester avec SOAPUI

Implémentation via @WebServiceProvider

Modifier le contrôleur précédent pour qu'il puisse être annoté via @WebServiceProvider. Le choix est laissé libre entre un traitement du message SOAP complet ou un traitement direct au niveau du PAYLOAD. Configurer3) la servlet CXF pour exposer le contrôleur comme une service implémentant le service précédent. On pourra s'inspirer de la configuration du module wine-service. On commentera les différents éléments de configuration (XML, annotations) introduits en expliquant leurs effets.

Tester avec SOAPUI4).

Implémentation via @WebService

Annoter l'interface ILivraison et la classe qui l'implémente avec @WebService et configurer CXF pour exposer ce service. Le service LivraisonService de livraisons.wsdl doit être correctement implémenté5).

Tester avec SOAPUI6).

Génération de code

Utiliser le plugin CXF wsdl to java pour générer des classes implémentant le service LivraisonService de livraisons.wsdl dans le package sw.wine.livraison.gen. Implémenter le service en appelant le composant qui implémente l'interface ILivraison et le déployer via CXF.

Tester avec SOAPUI7).

Stub Client

Créer un client en ligne de commande en utilisant un Stub généré via WSDL to Java.

2)
module services
3)
ce qui veut dire également ajouter les bonnes dépendances dans le pom
4) , 6) , 7)
il est possible d'utiliser les tests précédents en changemant le point d'accès
5)
seul le point d'accès peut changer