====== Implémentation de services ====== ===== Introduction ===== L'objectif de ce TP est d'implémenter des services, de comprendre les différents composants qui entrent en jeu ainsi que ce qui est fait à la place du développeur par les frameworks. A titre d'illustration, on considère un service de commandes en ligne permettant à un client de commander une combinaison de plats et de menus dans un restaurant pour ensuite venir les chercher ou se les faire livrer. Les commandes se feront par l'intermédiaire d'un service SOAP. La description des menus et des plats se fera via des ressources REST. ===== Modalités ===== ==== Rendu ==== Ce TP est à rendre pour le **04/11/2015** **09/11/2015**, à 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 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 [[http://tomusss.univ-lyon1.fr|Tomuss]], dans la case "TIW5 TP3". On fera attention à [[http://mercurial.selenic.com/wiki/Tag|tagger]] la révision correspondant au rendu avec le tag ''TP3''. Il est demandé à ce que les 4 implémentations du service (servlet, @WebServiceProvider et @WebService et code généré), ainsi que le point d'accès REST, 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 SOAP ainsi que pour le point d'accès REST. ===== Métier ===== Le projet [[http://forge.univ-lyon1.fr/projects/inf2018m-2015-base|TIW5-2015 base]]((''hg clone https://forge.univ-lyon1.fr/hg/inf2018m-2015-base'')) contient à présent: * Une implémentation partielle du [[enseignement:tp:sw:donnees:2015|TP1]], complétée avec des classes supplémentaires * Un nouveau module ''services'' contenant un squelette d'application Web pour exposer les services à développer dans ce TP On partira de cette nouvelle base pour ce TP. Il est conseillé de créer un nouveau projet forge pour ce TP, en particulier si votre TP1 diffère trop du nouveau module ''modele''. Prendre en main la nouvelle version du module ''modele''. Créer une classe qui implémente l'interface ''ICommandeService''. La javadoc de l'interface ''ICommandeService'' donne des détails concernant le comportement attendu des différentes méthodes. Il peut être nécessaire d'ajouter des méthodes et/ou des classes pour implémenter les fonctionnalités métier. Ecrire quelques tests unitaires pour vérifier le bon fonctionnement de la classe. Les bases de données utilisées dans les tests unitaires (JUnit) sont en général différentes des bases utilisées lorsqu'on déploie le serveur, par exemple pour les tests fonctionnels (SOAPUI). N'hésitez pas à définir une unité de persistence pour le test (avec par exemple une base H2 en mémoire) et une autre pour le déploiement (en vous inspirant par exemple de la config Spring du service locService) ===== Implémentation en servlet ===== Créer une nouvelle servlet pour implémenter le service ''CommandeService'' du fichier ''commande.wsdl''((module ''services'')). 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. Configurer((ce qui veut dire également ajouter les bonnes dépendances dans le pom)) 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 ''cineservice''. On commentera les différents éléments de configuration (XML, annotations) introduits en expliquant leurs effets. Tester avec SOAPUI((il est possible d'utiliser les tests précédents en changeant le point d'accès)). ===== Implémentation via @WebService ===== Annoter l'interface ''ICommandeService'' et la classe qui l'implémente avec @WebService et configurer CXF pour exposer ce service. Le service ''CommandeService'' de ''commande.wsdl'' doit être correctement implémenté((seul le point d'accès peut changer)). Tester avec SOAPUI((il est possible d'utiliser les tests précédents en changeant le point d'accès)). ===== Génération de code ===== Utiliser le plugin CXF [[http://cxf.apache.org/docs/maven-cxf-codegen-plugin-wsdl-to-java.html|wsdl to java]] pour générer des classes implémentant le service ''CommandeService'' de ''commande.wsdl'' dans le package ''tiw5.restaurants.services.gen''. Implémenter le service en étendant la bonne classe générée et en appelant le composant qui implémente l'interface ''ICommandeService'' et le déployer via CXF. Tester avec SOAPUI((il est possible d'utiliser les tests précédents en changeant le point d'accès)). ===== Ressource REST ===== Consulter le tutoriel [[https://docs.oracle.com/javaee/7/tutorial/jaxrs.htm#GIEPU|JEE sur REST]], puis exposer les menus et les plats (operations CRUD) via CXF en utilisant les annotations JAX-RS ([[https://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-Spring|doc config CXF]]). Tester avec SOAPUI