Patrons de conception de Web Services [trousse “premiers secours”] Récapitulation Styles d’API de Web Service RPC API Message API Resource API Styles d’interaction Client­Service Requête/Réponse Négociation de type de contenu Gestion de requête et de réponse Service Controller Styles d’implémentation de Service Web Transaction Script Datasource Adapter Operation script Workflow connector Infrastructures de Services Web Service connector Asynchronous Response Handler Idempotent Retry Evolution des Services Web Lecteur tolérant Consumer­Driven Contracts

Récapitulation de la liste Daigneau/ Robonson, 2012

Styles d’API de Web Service RPC API (Remote procedure Call) Problème:  Comment un  client qui  utilise  le protocole  http  peut exécuter des procédures à distance. Contexte: Il est  facile de  communiquer  entre un client et un serveur qui s’exécute sur deux plateformes différentes grâce au protocole HTTP. Forces : Simple à mettre en place Résumé  de  la  solution  :  Une  des  solutions  est  d’envoyer  des  messages  dont  la sémantique est encapsulée pour faire appel aux procédures. Détail  de  la  solution:  Avec  RPC,  le  client  envoie  un  message  à  un  serveur  distant  et bloque  en attendant la réponse. La requêter identifie la procédure à exécuter et contient un certain  nombre  de  paramètres qui sont directement reliés aux paramètres de la procédure distante.  Quand  un  message  arrive  sur  le  serveur,  le  serveur  inspecte  le  message   et invoque  la   procédure  dont  le  nom  est contenu dans  le message et  il  relie  les paramètres du  message  directement  aux  arguments  d’entrée  du  service.

Liens:http://servicedesignpatterns.com/WebServiceAPIStyles/RemoteProcedureCallAP I

Message API Autres noms du patron : Document API Problème:   Comment   les  clients  peuvent­ils  envoyer  des  commandes,  des  notifications,  ou d’autres  informations  à  des  systèmes  distants,  en  utilisant  HTTP,  et  en  évitant  un  couplage direct  des  procédures  distantes  ?  (How  can  clients  send   commands,  notifications,  or  other information to remote systems over HTTP while avoiding direct coupling to remote procedures?) Contexte  :  Dans  certains  cas,  le design du message ne  peut pas être entièrement encadré par le  créateur  du  service.  C’est  par  exemple  le  cas  dans  de  grandes  organisations  ou  dans  des scénarios  où  des  partenaires  commerciaux  échangent  des   données.  Dans  ces  situations,  les développeurs  du  service  ont  besoin  d’une  API  qui  reconnaît  un  ensemble  de  messages   liés, mais qui ne lie pas ces messages à des procédures spécifiques. Forces : Les API de message utilisent souvent des formats standardisés tels que SOAP. Résumé  de  la  solution  :  Définir  des  messages  qui  ne  sont  pas  dérivés  des   signatures  des procédures distantes. Détail  de  la  solution:  Les   messages  peuvent  transporter  de  l’information  sur  des  thèmes spécifiques,  des  tâches  à  exécuter,  et  des  évènements.  Faire  en  sorte  que  le  client  envoie  le message  à  une  URI  désignée.  Une  fois  que  le  message  est reçu  sur le  serveur,  examiner  son contenu pour déterminer la procédure correcte à exécuter.

Liens Web :http://servicedesignpatterns.com/WebServiceAPIStyles/MessageAPI

Resource API Problème:  Comment  un  client peut­il manipuler les données  d’un système distant, en évitant de faire appel aux procédures distantes, et minimisant les besoins d’APIs spécifiques? Contexte:  Souvent, les  webservices  sont basés sur le transfert de messages afin de créer leur propre  API   spécifique.  Le  problème  est  que   cela  conduit  souvent  à  une  prolifération  de  ces messages, basés sur les commandes de bases CRUD. Exemple  :  Considérons,  par  exemple,  un  ensemble   de  services  qui  gèrent  l'entreprise  et  les informations  sur  les  contacts.  Dans ce scénario, le développeur du client devra utiliser plusieurs messages  personnalisés.  Une  API  comme  cela  pourrait  inclure   des  messages  comme "CreateCompany",  "getCompany", et ainsi de suite. Le propriétaire du service aurait également à créer  des  messages  de  réponse  (par  exemple  "CreateCompanyResponse", "GetCompanyResponse",  etc.).  Cela  aura  pour  conséquence  d’alourdir  sa  tâche  (nombreux messages à créer à la main) mais aussi de surcharger le réseau ! Forces  :  Simplifier  le  travail  de  l’utilisateur  en  se  basant  sur  les  normes  définies par  HTTP. En particulier  dans l’approche  REST  qui  est  orientée  ressources,  cela permet d’éviter les doublons en cas de réémission de requêtes Résumé  de  la  solution  :  Attribuez  une  URI  à  toutes  les  procédures,  les instances de données du  domaine,  et  les  fichiers.  Utilisez  alors HTTP  comme  un  protocole d'application complet pour définir  les  comportements  de  services  standards.  Echangez  des  informations  en  profitant  des types de supports standardisés et des codes d’état (quand ils sont disponibles).

  Description : Le client appelle le service en envoyant des requêtes composée par : ­ une méthode (GET, PUT, POST, DELETE) ­ le type de données

­ une URI La  requête et  ses  paramètres  sont  utilisés  par  le  serveur  pour déterminer le service à invoquer. Une  fois  que  le service  a  été  invoqué,  il  peut  traiter la demande du client et renvoie une réponse contenant le type de support requis et/ou le code d'état. Si  on  est  en  REST  les  informations  de  base  (1  personne,  1  verbe,  1  objet)  sont  dans  l’en­tête de la requête, ce qui évite les doublons en cas de réémission. Les  services  orientés  API  ressources  adhèrent  souvent  aux  principes  de  REST.  Cependant, toutes les API de type ressources ne peuvent pas être considérés comme RESTful ! Exemples:

Styles d’interaction Client-Service Requête/Réponse Problème:   (une   phrase  sur  le  problème)  :  Comment  traiter  de  la  manière   la  plus  simple  une requête.  Décrire  le  mécanisme  de  requête/réponse  entre  client  et  serveur (synchrone). (What’s the simplest way for a web service to process a request and provide a result ? ) Contexte:  Le  client  établit  une  connexion  sur  le  serveur  distant,  il  envoit  la  requête,  la  requête est traitée par le serveur et il renvoit la réponse. Forces : : Simple à mettre en place. Résumé  de  la  solution  :  il   y  a  un  ensemble  d’échange  entre   client   et  serveur  (avec  une

opération de traitement). Détail  de la solution: :  le client établit une connexion, le serveur  accepte ou refuse, s’il refuse le processus  se  termine,  s’il  accepte  le  serveur  traite  la  requête  (en  1  thread)  puis  renvoit  la réponse.  La  particularité  se  situe  au  niveau  du  fait  qu’il  s’agit  d’appel  blocant  (mécanisme  de synchronisation).

Autres   facteurs:  Le  schéma  est  très  simpliste  et  n’est  pas  adapté  au   dialogue  relatif  au protocole  http  car  dans  ce  cas  précis,  le  dialogue  entre  client  et  server  génère  plusieurs requêtes (images, fichier css, fichier html...) Lien : http://servicedesignpatterns.com/ClientServiceInteractions/RequestResponse

Négociation de type de contenu (media­type Negotiation) Problème  :  Comment  un  web­service  peut­il  fournir  des  représentations  multiples  des  mêmes ressources  en  minimisant  le  nombre  d’URI  distinctes  pour  cette  ressource  ?  (How  can  a web service   provide  multiple  representations  of  the  same  logical  resource  while  minimizing  the number of distinct URIs for that resource ?) Contexte  :  Les  services  Web  doivent  souvent  tenir  compte  des  préférences  de  types  de médias.   Certains  clients  peuvent,  par  exemple,  préferer   XML  tandis  que  d'autres  favorisent JSON.  Le  propriétaire  du  service  doit  donc trouver un moyen par lequel les préférences peuvent être indiquées. Force : Une seule URL pour plusieurs représentations Résumé  de  la  solution  :  Quand  une  requête  est  reçue,  le  web   service  selectionne  un gestionnaire basé en partie sur les préférences client précisées via le header Accept

Détail  de  la  solution  :  Utiliser  le  Header  HTTP  Accept  pour  préciser  au  serveur  le  type  de représentation que l’on souhaite recevoir Exemples : Accept: text/html, application/xhtml+xml, application/xml;

Lien: http://servicedesignpatterns.com/ClientServiceInteractions/MediaTypeNegotiation

Gestion de requête et de réponse Service Controller Problème:   Comment   le  web  service  correct  peut­il  être  exécuté  sans  avoir   à  maintenir  une analyse complexe et une logique de routage ?

Contexte:  Tous  les  services  web  sont tributaires de mécanismes qui reçoivent des  demandes, d'évaluer  la  signification  de  la  demande,   et  acheminer  les  demandes  aux  procédures   (par exemple,  les  méthodes  de  classe,  gestionnaires   de  requêtes)  qui  mettent  en  œuvre  les comportements  de  service.  Les  concepteurs  de services peuvent centraliser cette logique dans un  Front  Controller.  Ce  modèle  fonctionne  très  bien  si  le  service  correct  peut  être  sélectionné par  simple  analyse  l'URI  demandé.  Malheureusement,  ce  n'est  pas  toujours  le  cas.  La  logique de  routage  peut  devenir  beaucoup  plus  complexe  si  le  service  doit  être  choisi  en  fonction préférés  médias  du  client,  le  message  des  valeurs  d'en­tête  ou  le  contenu  du  message   du corps.  Les  développeurs  pourraient  bénéficier  d'une  approche  déclarative  simple  qui  peut être interprété par un contrôleur frontal. Résumé  de  la  solution  :  Créez  une  classe  qui  identifie  un  ensemble  de  services connexes. Annoter   chaque  méthode  de  classe  (@annotation  sous  java)  avec  routage  d’expression  qui peuvent être interprétés par un contrôleur frontal. Détail  de  la  solution:  (éventuellement  schéma;  signaler  notamment  les   liens  avec  d’autres patterns) :

Liens  :http://servicedesignpatterns.com/RequestAndResponseManagement/ServiceController

Styles d’implémentation de Service Web Transaction Script problème: comment implementer rapide et efficace la partie logique des web service? contexte:  Ecrire  une  logique  personnelle  permettant   l’accès  à  une  base  de  donnée,  la manipulation de fichiers ou d’autres objectifs directement dans la methode du service web. force: simplicité , rapidité, modularité résumé  de  la  solution:  implémenter  une  séparation  et  une  interface  d’accès  entre  la  logique métié du web service et tout ce qui concerne la bdd, les fichiers et d’autres ressources. détails de la solution:

lien:http://www.servicedesignpatterns.com/WebServiceImplementationStyles/TransactionScript

Datasource Adapter autre nom: Adapter Pattern problème:   How   can  a  web  service  provide  access  to  internal  resources  like  database  tables, stored procedures, domain objects, or files with a minimum amount of custom code? force: simplicité d’accès aux données résumé  de  la  solution:  Create  a  web  service  that  uses  a  specialized  Datasource  Provider. Leverage   developer  tools  that  generate  datasource  metadata  and  produce  controllers   that  not only   encapsulate  and  interpret  the  rules  for  request  processing,  but  also  direct  the  actions   of Datasource Providers and Message Formatters. détails de la solution:

lien:  : http://www.servicedesignpatterns.com/WebServiceImplementationStyles/DatasourceAdapter

Operation script probleme:   Comment   un  service  web  peut­il  réutiliser  le  domaine  logique  sans  réutiliser  de code? contexte:  Encapsuler  des  logiques  métier  communes  dans  des   couches  de  domaines  qui existe  en  dehor  du  web  service.  Permet  de  limiter  la  logique  dans  le  web  service  aux algorithmes dirigeant les activités de ces entités. forces: réutilisation, maintenabilité, code propre et lisible, simplicité du code. résumé  de  la  solution:  Transaction  script  peut  parfois  être  trop  complexe  causant   des problèmes  dmaintenabilités. Les  developpeurs de  services  peuvent ameliorer la lisibilité de leurs codes  en  extrayant  le  code  sélectioné  par  fragments   en  dehors  du  web  service  dans  de  plus petites  méthodes.  Cependant  le  problème  de  la  duplicité  du  code  n’est  totalement  résolu  si  les méthodes extraites sont placés dans la même classe que la méthode du web service. détails de la solution:

lien: http://www.servicedesignpatterns.com/WebServiceImplementationStyles/OperationScript

Workflow connector problème:   Comment   les  web  services  peuvent  implémenter  des  processus  complexes  et nécessitant  un  long  temps  d’exécution  ?  (How  can  web  services  be  used  to  support  complex and long­running business processes ?) contexte:  Un  web  service  effectue  de  (très)  lourds  traitements  :  il  reste  dans  la  mémoire  du serveur  tout  le  temps  de  l’opération,  ce  qui  nuis  aux  performances  du  serveur, proportionnellement au nombre d’appels au service. De  plus  si  le  serveur crash, on peu perdre tout ou partie des  données traitées, ainsi que l’état du serveur en cours. force: récupération de l’état du process en cas de crash résumé  de  la  solution:Use  a  workflow  engine  to manage  the  life  cycle  and  execution  of  tasks within  complex  or  long­running  business  processes.  Identify  a  web  service  that  will trigger each logical  business  process.  Use  callback services to receive additional data for these long­running

processes, and forward messages from these callback services to the workflow engine. détails de la solution:

Workflow  engines  govern  entire  workflow  life  cycles  from  process  instantiation  to  termination. They  trigger  task  execution,  and,  for  each  process   instance,   keep  track  of  which  tasks  are executing,  which  are  waiting  or  suspended,  and  which  must  be  resumed  or  restarted.  Many workflow  engines  save the  state  of  tasks  and  variables  to  a database before and after tasks are executed. The  Workflow  Connector  pattern  uses  web  services  as  a means to launch business processes managed   by  workflow  engines.  Developers  designate  a  Trigger  service  that  creates  new process   instances  for  a  given process  definition.  Callback  Services  may  also  be  designated  to receive  additional  data  after  the  process  has  started.  The  workflow  engine  ensures  that  each callback message is routed back to the correct process instance. Liens: http://www.servicedesignpatterns.com/WebServiceImplementationStyles/WorkflowConnector

Infrastructures de Services Web Service connector Problème : Comment ne pas dupliquer du code lorsqu’on utilise un web service particulier. Contexte  Lorsqu’on  utilise  un  web service  dans  son  application  avec  du  REST  avec les  bons en­têes http etc. Forces : S’abstrait de la complexité technique de la technologie employée

Résumé  :   On   crée  une  librairie  qui  sert  de  passerelle  qu’on  utilise  facilement  et  qui  va  se charger  d’ajouter  les  options  et  autre  détails  techniques  spécifiques  à  la  technologie  sans complexifier l’utilisation. Llien : http://www.servicedesignpatterns.com/WebServiceInfrastructures/ServiceConnector

Asynchronous Response Handler Problème:   Comment  envoyer  des  requetes  non  blocantes  au  serveur  (How  can a  client avoid blocking when sending a request? Contexte: Comment eviter les appels bloquants à un webservice  donné, c’est à dire generé des appels asynchrones ( appels non bloquants) Forces : Les  requetes asynchrones vont permettre  au client de realiser des appels non blocants au serveur, permettant au client de realiser d’autres taches en attendant la réponse du serveur Résumé  de  la  solution  :  Le  client envoie  une  requete  à  un  connecteur  (service  ou  proxy),  ce connecteur  prend en charge la requete et l’envoie au serveur final. Le serveur traite la requete, la connexion est maintenue. Dans  certains  cas,  cette approche  peut  etre  combinée avec un autre patron (scrutation, polling) consistant  à  interroger  à  intervalle  regulier  le  service  pour  savoir où il en est dans le traitement, puis   une   fois  le  travail  du  serveur  terminé  le  serveur  renvoie  la  réponse  au  connecteur  qui  la renvoie au client. Détail de la solution: Diagramme de séquence de la solution :

Lien  avec  le  pattern  “Service  Connector”: ce patron prend  en compte la mise en place du patron “Service Connector” qui gère la réponse renvoyée par le service demandé.

Autres   facteurs:  Il   y  a  2  formes  de  ce  patron:  “polling  method”  et  “client­side  callback”.  La différence  entre  les  deux  est  la  manière  pour  le  service  connecteur  de  gérer  la  réponse  du service. Avec le “polling method”, le client est obligé de demander périodiquement au connecteur s’il  a  reçu  la  réponse  du  service.  Avec  l’autre  formes,  “client­side  callback”,  le  connecter s’occupe de notifier le client dès que la réponse est arrivée et ensuite la renvoie au client. Exemples :

Liens : http://servicedesignpatterns.com/WebServiceInfrastructures/AsyncResponseHandler

Idempotent Retry Problème:  How  can  a  client  ensure  that requests  are  delivered  to a web service despite temporary network or server failures? Contexte: Un  client tente de se connecter à un service  mais du fait de la mauvaise qualité de sa connexion internet, il lui est très difficile d’accéder aux ressources souhaitées. Résumé  de  la  solution  :  La  solution  d’un  tel  problème  pourrait  passer  par  l’utilisation d’un  intermédiaire  chargé  de  gérer  les  communications  entre  les  services  et  les  clients mais cette  solution peut paraître trop  lourde  dans bien des cas.  Une  solution à ce type de

problème de  connexion  est tout  simplement  de  laisser  le client réessayer de se connecter jusqu’à ce que le service lui soit accessible dans la limite d’un nombre de tentatives défini. Détail  de  la  solution:  Il  suffit  donc  d’identifier  chaque  requête  de  connexion  avec  un identifiant  propre.  La  requête  est  envoyée  au service qui répond ou non. Si le  service  ne répond pas,  le  client renvoi  cette  requête  jusqu’à  ce que le nombre de demande n’excède pas la  limite imposée ou que la connexion soit établie. Si la limite est atteinte, les requêtes sont tout simplement ignorées.

Liens:  http://www.servicedesignpatterns.com/WebServiceInfrastructures/IdempotentRetry

Evolution des Services Web Lecteur tolérant (Tolerant reader) Problème:  Comment  les   clients  ou  services  peuvent­ils  fonctionner   convenablement  quand certains   contenus  des  messages  ou  des  types  de  médias  qu’ils  reçoivent  sont  inconnus,  ou quand  les  structures  de  données  changent  ?  (How  can  clients  or  services  function  properly when  some  of  the  content  in  the  messages or media types they receive is unknown or when the data structures vary?) Contexte:  Un  client  ou  un  service  s’attend  à  ce  que  des  changements  surviennent  dans  un message ou un type de média Détail  du  problème  :  Service  owners  often  have  to  deal  with  message  variability  as  well.  For example, some  message structures may be owned and  designed by business partners, industry consortium,  or  trade  groups.  In situations  like these, service developers may not be able to keep up  with  client  applications  that  adopt  newer  versions  of  these  messages.  The  service  must therefore be forward compatible and accept client content that it may not fully understand. How  can  clients  continue  to  process  service  responses  when  some  of  the  content  is  unknown

or the data structures vary, and how can services deal with changing client request messages? Résumé  de  la  solution  :  Concevoir  le  client  ou  le  service de façon à n'extraire que ce qui est nécessaire, ignorer le contenu inconnu, et s'attendre à des structures de données variables Détail  de  la  solution  :  Tolerant  Readers  extract  only  what  is  needed  from  a   message  and ignore  the  rest.  Rather  than implementing a strict validation  scheme, they make every attempt to continue  with  message  processing  when  potential  schema  violations  are  detected.  Exceptions are  only  thrown  when  the message structure prevents the  reader from continuing, or the content clearly  violates  business  rules.  Tolerant  Readers  ignore   new  message  items,  the  absence  of optional  items,  and unexpected  data  values  as  long  as  this  information  does  not  provide  critical input to the service logic. Lien : http://servicedesignpatterns.com/WebServiceEvolution/TolerantReader

Consumer-Driven Contracts Problème:   Comment   l’API  d’un  service  web  reflète­t­elle  les  envies   de  ses   clients  tout  en permettant  son  évolution  et  en  évitant  de  géner  le  client  ?. Les  services  répondent  logiquement aux  besoins  des  clients  mais  en  général  ces  besoins  divergent.  Les  services  doivent  évoluer tout en évitant qu’un seul des clients soit confronté à des problèmes au cours de cette opération. Contexte:  Un  service  possède  plusieurs  clients  avec  pour  chacun  des  besoins différents. Les propriétaire  de  service  savent  qui  sont  leurs  clients  et  les  développeurs  du  côté  client  sont capables de communiquer leurs attentes concernant l’API du service au propriétaire. Forces :Faire évoluer un service tout en évitant de géner les clients. Résumé  de la solution : IIl  s’agit  pour le client de faire des tests automatiques qui sont envoyés au fournisseur de service afin de l’aider à modifier son service sans créer de gène. Détail  de  la  solution:  La  solution  à  cette problématique  est  la  suivante.  Quand  le  propriétaire d’un  service  met  à jour l’API de celui­ci, il effectue une batterie de tests avec son service et l’API. De  son  côté  le  client  effectue  des  tests  automatiquement   communiqués  au  propriétaire  du service  afin  que  celui­ci  puisse  jugé  des  parties  à  changer  pour  que  le client n’obtienne plus de problèmes.

Liens Web : Consumer­Driven Contract