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 ClientService 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
ConsumerDriven 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 peuventils 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 peutil 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’entê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
(mediatype Negotiation)
Problème : Comment un webservice peutil 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 peutil ê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'entê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 peutil 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 longrunning 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 longrunning business processes. Identify a web service that will trigger each logical business process. Use callback services to receive additional data for these longrunning
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 entê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 “clientside 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, “clientside 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 peuventils 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ètetelle 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 celuici, 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 celuici puisse jugé des parties à changer pour que le client n’obtienne plus de problèmes.
Liens Web : ConsumerDriven Contract
