Correction possible de lexamen TIW5 - Services Web 1) Principles et implmentation des services Web 1.

1 JSON Rep0: Je pense que cest possible de parler de services Web lorsquon utilise JSON pour changer des donnes entre deux applications travers Internet parce que cest possible avec REST services. On peut utiliser JSON pour changer des donnes de service entre ces applications travers Internet. Rep0.1: Oui je suis daccord avec Rep0. En effet, on utilise JSON lorsquon veut serialiser les objets et par exemple on ne fait que recuperer des objets des deux cts(Client/Server). De plus si on utilise AJAX ct client, il est super facil dutiliser 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 reprsentation des messages est quasi transparent pour les services. Des exemples trs simples: on peut demander un service de repondre sous plusieurs formats(XML, JSON,..); si tu dveloppe une application qui sinterface LinkedIn par exemple, tu peux demander ce quon te reponde en XML ou JSON. Ref: http://stackoverflow.com/questions/2636245/choosing-between-json-and-xml Rep1: Moi je dirai non JSON cest pas un service web (il existe 2 sortes de service web SOAP et REST) JSON est un format de donne utilis par SOAP et REST.(on parle des messages changs et non des services ah daccord! Merci) JERSEY (web service rest en java) et jax ws autorise limplmentation dun service en utilisant JSON en tant que format dchange. Le probleme se pose avec les service type SOAP qui ncessite une dfinition et dans ce cas on ne peux pas car JSON ne dispose pas de langage de spcification donc on ne peut pas vraiement envoyer un message JSON correspondant une definition dans une WSDL 1.2 SOAP ou REST 1. On souhaite implementer un service de reservation de salles. On sait que chaque reservation doit 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 prfrable 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 problme avec ces informations, on peut vrifier facilement grce aux informations rserves au serveur. Rep1:ce modele ne ncessite pas un traitement particulier ou profond, ce qui ideal dutiliser une architecture orient ressources qui correspond bien au REST. Autrement dit, Rest permet deffectuer des actions simple sur une ressource (GET, POST, DELETE, PUT) ou CRUD, donc une architecture REST est prfrable pour ce genre doprations. 2. On considere une application de suivi de travaux dans le cadre d'une entreprise de travaux public. Cette application, implementee par un service Web, doit ^etre accessible a la fois

en intranet et en extranet. Les informations d'authentication sont cependant differentes dans les deux cas. Utiliseriez vous une architecture de type SOAP ou REST? Justier votre reponse. Il est possible d'ajouter des hypotheses an de preciser l'enonce si besoin. Rep0: Je pense que dans ce cas, SOAP est plus prfrable que REST parce que ce service Web exige lauthentification de facon diffrente entre lintranet et lextranet.Avec SOAP, on peut utiliser lextension SOAP WS-Security ou SOAP WS-ReliableMessaging pour assurer ces fonctionnalits. Rep1:SOAP est prfrable pour effectuer des taches plus pronfondes plus complexe que des opration CRUD et pour des traitement supplmentaires au traitement mtier, ce qui est le cas dans notre exemple.Le traitement de controle dacces est une tache critique et ncissite une configuration rgide. 1.3 APIs On considere un service web dont l'implementation n'est pas securisee; en particulier cette implmentation n'effectue aucune verication en termes de contrles 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 dauthentification 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 dauthentification. Si lauthenfication russi alors on laisse le client accder 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, les autres aspects (securite, normalisation, etc) doivent tre codes separement. Dans le cadre de l'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 implmenter des services qui permettent lauthentification et ainsi dfinir une politique de scurit plus efficace et facile maintenir dans la mesure ou on peut accder ce dernier sans passer par le reseau(internet) dune part et toujours rester dans le cadre SAAS et donc reutiliser ce servive pour dautres applications. Intercepteurs: On peut utiliser les intercepteurs car leur mis en oeuvre est assez facile et on opre directement sur le message ou sur une opration. Pour service ayant plusieurs oprations dont celles-ci ne ncessitent pas toutes une authentification, un intercepteur pourra donc tre utilis plus facilement pour contrler laccs cette action. Rep1 : jutiliserais ESB si: laspect est un composant(service) gnrique et rutilisable indpendant dune application

Si les composants grant les uatres aspects sont nombreux et quil y a des interactions nombreuses et complexes => bus est interessant Intercepteur: Si laspect est spcifique un service Si je nai pas envie de perdre de temps (rapide et simple) je pense que si laspect implement est un aspect metier (dans les ESB il y a des composant de transformation XSL par exemple ce nest pas du mtier? les aspects non fonctionnel sont par dfinition non mtier ?)===> composant ESB si la fonctionnalit est transversalle (secondaire) ====>intercepteur 2.1Corrlation: le probleme de corrlation rside dans le fait quun membre peut enchrir 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 rponse concerne tel message. Pour les identifients de corrlation, 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 rponse un identifiant de participation, la date de participation, lidentifiant de lobjet sur le quel il a particip,... (en tout cas cest ce que je pense!).