Correction possible de l’examen TIW5 - Services Web1) Principles et implémentation des services Web1.1 JSON Rep0: Je pense que c’est possible de parler de services Web lorsqu’on utilise JSON pour échanger des données entre deux applications à travers Internet parce que c’est possible avec REST services. On peut utiliser JSON pour échanger des données de service entre ces applications à travers Internet.Rep0.1: Oui je suis d’accord avec Rep0. En effet, on utilise JSON lorsqu’on veut serialiser les objets et par exemple on ne fait que recuperer des objets des deux côtés(Client/Server). De plus si on utilise AJAX côté client, il est super facil d’utiliser les objets JSON que de parser un document XML. XML et JSON sont utiliser pour la transmission des message entre les services don, pour moi, la représentation des messages est quasi transparent pour les services. Des exemples très simples: on peut demander à un service de repondre sous plusieurs formats(XML, JSON,..); si tu développe une application qui s’interface à LinkedIn par exemple, tu peux demander à ce qu’on te reponde en XML ou JSON. Ref: http://stackoverflow.com/questions/2636245/choosing-between-json-and-xml Rep1: Moi je dirai non JSON c’est pas un service web (il existe 2 sortes de service web SOAP et REST) JSON est un format de donnée utilisé par SOAP et REST.(on parle des messages échangés et non des services ah d’accord! Merci) JERSEY (web service rest en java) et jax ws autorise l’implémentation d’un service en utilisant JSON en tant que format d’échange. Le probleme se pose avec les service type SOAP qui nécessite une définition et dans ce cas on ne peux pas car JSON ne dispose pas de langage de spécification donc on ne peut pas vraiement envoyer un message JSON correspondant à une definition dans une WSDL 1.2 SOAP ou REST1. On souhaite implementer un service de reservation de salles. On sait que chaque reservationdoit être approuvee par un responsable avant d'être effective. Utiliseriez vous une architecture de type SOAP ou REST? Justier votre reponse. Il est possible d'ajouter des hypotheses afin de preciser l'enonce si besoin. Rep0: Je pense que dans ce cas, SOAP est plus préférable que REST parce que on a besoin de garder les informations de reservation de salles du client au serveur de service. Si il y a un problème avec ces informations, on peut vérifier facilement grâce aux informations réservées au serveur. Rep1:ce modele ne nécessite pas un traitement particulier ou profond, ce qui ideal d’utiliser une architecture orienté ressources qui correspond bien au REST. Autrement dit, Rest permet d’effectuer des actions simple sur une ressource (GET, POST, DELETE, PUT) ou CRUD, donc une architecture REST est préférable pour ce genre d’opérations. 2. On considere une application de suivi de travaux dans le cadre d'une entreprise de travauxpublic. Cette application, implementee par un service Web, doit ^etre accessible a la fois

en intranet et en extranet. Les informations d'authentication sont cependant differentesdans les deux cas. Utiliseriez vous une architecture de type SOAP ou REST? Justier votrereponse. Il est possible d'ajouter des hypotheses an de preciser l'enonce si besoin. Rep0: Je pense que dans ce cas, SOAP est plus préférable que REST parce que ce service Web exige l’authentification de facon différente entre l’intranet et l’extranet.Avec SOAP, on peut utiliser l’extension SOAP WS-Security ou SOAP WS-ReliableMessaging pour assurer ces fonctionnalités. Rep1:SOAP est préférable pour effectuer des taches plus pronfondes plus complexe que des opération CRUD et pour des traitement supplémentaires au traitement métier, ce qui est le cas dans notre exemple.Le traitement de controle d’acces est une tache critique et nécissite une configuration régide.1.3 APIsOn considere un service web dont l'implementation n'est pas securisee; en particulier cette implémentation n'effectue aucune verication en termes de contrôles d'acces. On vous demande de concevoir un composant (service ou autre) permettant de securiser l'acces a ce service. On souhaite que ce composant puisse s'adapter a differentes technologies d'authentication et d'autorisation.Donner les technologies/APIs que vous emploieriez et pourquoi.Rep0:Pour moi, on peut utiliser le mecanisme d’authentification vue en TP avec les Handlers. On laisse les services tels que tels et on met en place un handler qui intercepte les messages puis, dans celui-ci, appelé le composant d’authentification. Si l’authenfication à réussi alors on laisse le client accéder au service dans le cas contraire on lui jette un faute si on utilise le protocol SOAP 1.4 ESB ou intercepteurs ?Si on considere que l'implementation d'un service doit se concentrer sur les aspects metier, lesautres aspects (securite, normalisation, etc) doivent être codes separement. Dans le cadre del'utilisation d'un ESB, donner deux raisons d'implementer/de deployer un aspect via un composant de l'ESB et deux raisons de le faire via un intercepteur. Rep0:

ESB: On peut implémenter des services qui permettent l’authentification et ainsi définir une politique de sécurité plus efficace et facile à maintenir dans la mesure ou on peut accéder à ce dernier sans passer par le reseau(internet) d’une part et toujours rester dans le cadre SAAS et donc reutiliser ce servive pour d’autres applications.

Intercepteurs: On peut utiliser les intercepteurs car leur mis en oeuvre est assez facile et on opère directement sur le message ou sur une opération. Pour service ayant plusieurs opérations dont celles-ci ne nécessitent pas toutes une authentification, un intercepteur pourra donc être utilisé plus facilement pour contrôler l’accès à cette action.Rep1 : j’utiliserais ESB si:

● l’aspect est un composant(service) générique et réutilisable indépendant d’une application

● Si les composants gérant les uatres aspects sont nombreux et qu’il y a des interactions nombreuses et complexes => bus est interessant

Intercepteur:● Si l’aspect est spécifique un service● Si je n’ai pas envie de perdre de temps (rapide et simple)

je pense que si l’aspect implementé est un aspect metier (dans les ESB il y a des composant de transformation XSL par exemple ce n’est pas du métier? les aspects non fonctionnel sont par définition non métier ?)===> composant ESBsi la fonctionnalité est transversalle (secondaire) ====>intercepteur2.1Corrélation:le probleme de corrélation réside dans le fait qu’un membre peut enchérir plusieurs fois sur un meme objet. Donc il faut faire la correspondance entre les messages entrants et les message sortants.Autrement dit, comment connaitre que tel réponse concerne tel message.Pour les identifients de corrélation, on peut ajouter des information dans les message et les reponses pour identifier la correspondance. pour ce la par exemple, on peut ajouter dans la réponse un identifiant de participation, la date de participation, l’identifiant de l’objet sur le quel il a participé,...(en tout cas c’est ce que je pense!).