Semaine 3 Flashcards
Pourquoi des normes?
Les normes permettent d’uniformiser des tâches et de documenter de bonnes pratiques pour un domaine d’application.
Un langage normalisé permet une interopérabilité entre plusieurs outils utilisant ou produisant des artefacts selon des langages bien définis dans des normes.
Exemple: le langage XMI (normalisé par Object Management Group) permet de spécifier des modèles UML que permet d’exporter et d’importer des modèles entre les outils d’édition de modèle UML.
Quelles sont les normes de la SOA?
Normes pour spécifier les contrats entre services et clients + messages de requêtes réponses
- WSDL pour spécifier des contrats et SOAP pour spécifier des messages échangés comme requêtes et réponses,
- Ou
- OpenAPI et JSON ou Yaml.
Normes pour composition de services en applications composites:
- SCA
- BPEL
UDDI pour registre de services
Qu’est-ce que WSDL?
WSDL ( Web Service Definition Language ) offre un langage de description de l’API d’un service et de son exposition. Normalisé par W3C.
WSDL est le standard intégré par les solutions d’intégration comme les Bus de services (ESB)
Permet d’exposer des services ou de les consommer sans imposer une technologie cliente ou serveur.
Voir Semaine 3 Diapo 6 pour schéma.
La description WSDL aide le demandeur de service à déterminer comment demander le service.
Les descriptions de WSDL sont lisibles par les machines, ce qui permet au demandeur de service de générer le code nécessaire pour interagir automatiquement avec un fournisseur de services + validation automatique possible
Ce processus est connu sous le nom de « binding », qu’il soit fait automatiquement ou par le développeur.
Le binding permet d’invoquer le service à l’aide de messages SOAP structurés selon les descriptions WSDL.
Quelle est la structure principale d’un document WSDL?
<definitions>
<types>
data type definitions........
</types>
<message>
definition of the data being communicated....
</message>
<portType>
set of operations......(Appelé “interface” dans une autre version)
</portType>
<binding>
protocol and data format specification....
</binding>
</definitions>
Dans l’exemple suivant, on a:
- une définition de paramètre d’input « term » de type string
- Une définition de parametre de output « value » de type string.
- Une opération avec attribut XML name= getTerm et qui a pour input et output les éléments ci-haut référencés par leurs XML attributs « name » dans la définition de l’opération
- L’opération fait partie d’une interface dont le XML « name » = «glossryTerms »
Exemple :
<message>
<part></part>
</message>
<message>
<part></part>
</message>
<portType>
<operation>
<input></input>
<output></output>
</operation>
</portType>
<binding>
<soap:binding></soap:binding>
<operation>
<soap:operation></soap:operation>
<input></input><soap:body></soap:body></input>
<output><soap:body></soap:body></output>
</operation>
</binding>
Quelle est la différence entre la partie abstraite et la partie concrète d’un API/service selon WSDL?
La partie abstraite d’un service rassemble les données et les opérations du service.
- Les données échangées, leur format, leurs noms, leur structure et leurs contraintes sont exprimés selon une grammaire XML et reposent sur le standard XML Schema.
- Les opérations y sont également formalisées et indiquent les données liées en entrée et en sortie, ainsi que les cas d’exception.
Il est possible d’importer un schéma existant au sein d’un WSDL. Ceci permet de définir les types de paramètres d’opération.
Éléments principaux :
- “Types” pour décrire les types de données utilisés.
- Les développeurs peuvent définir les types de données abstraits dans XML.
- Pas nécessaire si on se limite aux types de base dans XML.
- “Interfaces”: identifie les operations exposées par un API
La partie concrète de l’API indique des informations techniques comme les normes d’encodage et de transport, et les adresses d’invocation du service associé.
Éléments principaux :
- Les interfaces sont abstraites.
- Les interfaces ne peuvent pas être utilisés tant qu’elles ne sont pas liées aux implémentations concrètes nécessaires à l’utilisation des services Web.
- Les « Binding » déterminent la façon dont le message SOAP est traduit en XML, et dictent la forme des messages.
- Comprend de choisir un style-document, ou un style- RPC, pour les interactions; ainsi que de spécifier le protocole de transport pour l’envoie des messages SOAP.
Quels sont les outils WSDL?
L’outillage actuel masque le langage XML associé à un WSDL.
- Les outils d’édition de code source de services ou de schémas XML offrent aussi une interface graphique.
- Ils peuvent également générer le WSDL associé à un service à partir de son code, par exemple une configuration WCF pour la plate-forme .NET ou une interface Java annotée via JAX-WS pour la plate-forme Java
Ex. JDeveloper générant un fichier WSDL d’un
service
Ex. service web avec un fichier asmx et serveur
.net.
Qu’est-ce que SOAP?
SOAP = Simple Object Access Protocol est un protocole de communication sur internet.
Normalisé par W3C pour standardiser la structure d’un message d’invocation de service web décrit en WSDL
SOAP peut être utilisé pour étendre HTTP pour message en XML.
- Fournit le transport de données pour les services Web.
- Il est indépendant de la langue et de la plate-forme
- Échange de documents complets
- Invocation de procédure à distance (RPC)
- Diffusion d’un message
- XML simple qui définit comment l’information est envoyée à travers des réseaux hétérogènes.
Quelle est la structure des messages SOAP?
<?xml version=’‘1.0’’?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=’‘http://www.w3.org/2001/12/soap-envelope’’
SOAP-ENV:encodingStyle=’‘http://www.w3.org/2001/12/soap-encoding’’>
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Qu’est-ce que REST?
Architecture client/serveur REpresentational State Transfer (REST) :
- Client/serveur
- Stateless
- Cache
- Uniform contract
- Layered system
- On-demand code (Plusieurs langages de prog. Selon la demande.)
Un service qui se base sur REST est dit « RESTful service »
REST repose sur le protocole HTTP qui n’offre pas de garantie de livraison ni de sécurité autre que le transport.
Le nommage des objets métiers en REST se fait sous la forme d’une adresse Internet, ou URL.
La formulation d’une requête est un URL concaténé avec « ? » et les paramètres valués, example:
http://www.filerouge.com/api/consommation/Client/1x08?from=2018-02-13&to=2018-02-16
Ceci correspond à l’envoi d’un message sous format JSON indiquant les valeurs de paramètres from = 2018-02-13 et to = 2018-02-16
Un path dans le URL permet d’identifier une resource et de lui acheminer le message.
Ceci fait qu’il faut associer au dit path une implementation d’une operation qui traite le message relié à la resource fournie dans le path; ceci est aussi en fonction des parmètres annexés au URL.
Formaliser une requête à un service RESTful => se conformer à la description du service fournie selon la norme OpenAPI (Nouveau nom de l’IDL: Swagger) dans un fichier au format JSON ou Yaml
OpenAPI dernière version à date: 3.0
Qu’est-ce que la conception d’API avec ‘‘API first’’ vs avec ‘‘service first’’?
« API first » :
- on construit la définition de l’API avec un fichier de description JSON tout d’abord avec un outil comme « Swager Editor ».
- Ensuite l’outil génère une squelette du code du service
- Les outils de conception d’API offrent un ensemble de masques à renseigner pour formaliser une API, ses ressources, ses url, etc.
- Cette démarche et ces outils permettent d’éditer ou de générer une définition JSON OpenAPI de son API sans avoir à maîtriser cet IDL.
- L’en-tête du document OpenAPI définit les informations générales
- L’ensemble des ressources de l’API sont détaillées avec les paramètres et les types d’objets métiers que l’on peut définir une seule fois, les cas de réponses, etc.
« service first » :
Des langages de programmation comme Java et ceux de .Net permettent de générer une
définition d’API depuis le code.
Outils :
- Swagger inspector : pour tester et générer Swagger sepc.
- JDevelopper permet la création de Restful service sans nécessairement générer de fichier description JSON
- Framework « Spring Boot » pour les développeur Java avec une utilisation de l’outil JAX RS et des annotations spécifiques.
- Framework « Eclipse Jersey » qui prend en charge JAX-RS
Qu’est-ce que la norme UDDI?
UDDI : Universal Description, Discovery, and Integration – version 3.0
- Basé XML
- Permet de décrire et découvrir les services comme un cadre indépendant des technologies d’implémentation, à travers le réseau Internet
- Un répertoire :
- stockant information sur les services web écrit en WSDL
- Consultable par message SOAP pour donner accès à la description WSDL
- Sponsorisé par « Organization for the Advancement of Structures Information Standards »
UDDI permet une mise en œuvre de répertoires UDDI basés XML pour découverte automatique de services
Le critère de recherche: nom d’entreprise, emplacement d’entreprise, catégorie
d’entreprise, type de service par nom, identifiant d’entreprise ou URL de découverte.
Exemple : IBM registry
