Semaine 2 Flashcards
Qu’est-ce que le style SOA 1.0?
Année 2000
Contexte de l’écosystème de l’entreprise : partenaires industriels, fournisseurs, agents commerciaux, autorités de régulation, etc. Ces partenaires veulent brancher leur propre SI sur le SI de l’entreprise.
Le système d’information doit donc ouvrir ses traitements métiers, ce que ne permet pas une architecture monolithique.
Le style SOA 1.0 : Bus de service et niveaux logiciels
Le bus de service assure à un ensemble de services :
- Validation de la requête
- Adaptation de protocole de messagerie
- Routage vers service
- Contrôle d’accès
Premier style SOA ne parvient pas à dépasser complètement ses précurseurs monolithiques, même s’il ouvre les fonctions et processus du SI aux partenaires.
La proposition de services transversaux séduit la DSI (direction du système d’information), mais le métier y adhère plus difficilement.
Les socles d’infrastructure et les standards XML alourdissent l’agilité requise par les projets.
Qu’est-ce que le style SOA 2.0?
Le style SOA 2.0 : les microservices
SOA 2.0 découpe la solution en solutions métiers. Couper le monolithe en silos verticaux.
Il s’agit de confier chaque solution métier complète à une seule équipe autonome qui est chargée de développer l’ensemble des couches IHM + métier + base de données.
Le ‘‘time to market’’ prime sur toute autre considération.
On appelle cette solution métier un microservice.
Ce style impose que chaque microservice soit autonome sur le plan architectural.
Aucun couplage fort avec un autre service n’accède à aucun autre microservice métier de façon synchrone.
Les microservices doivent se synchroniser entre eux via des réplications asynchrones de données ‘‘en temps réel’’ (pas par des batchs nocturnes ni par des bases SQL communes aux services).
Exemple de séparation en microservices ‘‘client’’ et ‘‘gestion de commande’’, et communication asynchrone des mises à jour de nouveaux clients.
L’approche microservices sur le plan architectural est étroitement liée :
- Au mouvement DevOps, ‘‘you built it you run it’’
- À la vogue exponentielle des technologies de virtualisation, comme la technologie des conteneurs, en particulier Docker.
Comment identifier les microservices (style SOA 2.0)?
Une première question se pose alors : comment identifie-t-on un microservice? Sur le plan architectural, un microservice est défini avant tout par les objets métiers qu’il gère. Plus exactement, chaque microservice prend en charge la gestion d’un objet métier racine, par exemple le catalogue produit et l’ensemble des objets métiers qui lui sont plus ou moins étroitement reliés (les brochures de présentation, les promotions en cours, etc.).
Quels sont les avantages du style SOA 2.0?
Couplé à l’approche DevOps,
- Ce style SOA conduit à considérer un microservice comme un véritable produit fini
- L’équipe d’un microservice est solidaire des succès et/ou échecs de maintenance
L’approche asynchrone facilite la résistance aux pics de charge (pas d’attente non nécessaire)
Les microservices fournissent une grande liberté d’évolutivité :
- Chaque microservice est libre d’être modifié et redéployé indépendemment
Quels sont les inconvénients du style SOA 2.0?
Le préfixe ‘‘micro’’ laisse penser qu’un microservice est ‘‘micro’’ en termes de lignes de code, ce qui est faux.
Le libre choix et la prolifération de technologies conduisent à une grande dispersion des efforts à l’echelle d’une DSI et empêche la mutualisation (échange) des connaissances.
Approche en silos va à l’encontre des processus métiers traverses.
Qu’est-ce que le style SOA 3.0?
Le style SOA 3.0 : l’essor des API et des services réactifs
Motivation / contexte :
- Contexte d’utilisation d’équipements (ex. smartphone) favorisant une seule application par un usage.
- On ne veut pas regrouper des interfaces homme machine (IHM) développées par des équipes différentes (comme le prôe l’approche microservice) dans une seule application (difficulté ergonomique et technique).
- L’essor des objets connectés :
- Impose une évolution vers une architecture plus temps réel, réactive aux flots d’événements qui bombardent
l’entreprise de données.
- L’engorgement du SI devient alors une question clé.
Le style SOA 3.0 : Synthèse de SOA 1.0 et 2.0
SOA 3.0 : vise le meilleur des deux mondes SOA 1.0 et 2.0
Le style SOA 3.0 distingue des services back end et des services front end.
- Back end (explication) : reprise de l’approche microservice (SOA 2.0)
- Front end (service applicatif) : gestion d’API adopté dans SOA 1.0
- Gestionnaire d’API (ex. ESB) responsable de contractualisation, publication et surveillance
Composants :
- Un gestionnaire d’API pour les services applicatifs (front end)
- Silots de conteneurs pour service back end y compris ceux traitant les données de l’Internet des objets
Quel est le lien entre le style SOA 3.0 et l’Internet des objets?
L’Internet des objets connectés (IOT) implique l’apparition d’un nouveau type de services SOA 3.0 :
- Les services IMM, pour interface machine-machine
- Services IMM = passerelles entre les multiples objets connectés et la partie du SI qui doit traiter les événements et les
données en provenance de ces objets.
- Les services implémentent une architecture ‘‘réactive’’ :
- Gérer des flots de données continus sans engorger ou bloquer le SI
- Satisfaire des exigences de robustesse et de performance
SOA 3.0 : communication
Une architecture SOA 3.0 face à l’IOT temps réel avec aspect ‘‘réactive’’ :
1. Des communications en mode événementiel (type fire and forget) supplantent le mode requête/réponse plus traditionnel
utilisé dans IHM ou même machines à machines (IMM), par exemple pour les processus automatisés ou les batchs.
2. Des communications en mode asynchrone/push => renverser le mode synchrone/polling bien connu depuis des dizaines
d’années pour la récupération des fichiers échangés entre applications de gestion par exemple.
Nomme quelques caractéristiques (types) des services.
A - Service ‘‘COMMANDE’’ pour utilisateurs finaux, un service applicatif (services front end)
B - Services : Client, catalogue, produit et stock => sont orientés gestion des informations métiers (services back end)
C - Services ‘‘moteur de calcul’’ orienté règles métiers, comme le service Tarificateur et moteur de calcul de taxes
Exemple de composition et d’interopérabilité :
- La granularité (composition de compositions)
- Un état, ou contexte, entre les services, par exemple les lignes de commandes
- Un référentiel des services homologués pour pouvoir choisir entre différents services logistiques de livraison
Quelles sont les caractéristiques techniques des services?
Accès synchrone ou asynchrone?
- Dialogue de type requête-réponse : synchrone, le demandeur de service bloque en attente de la réponse à sa requête
- Dialogue de type publication asynchrone d’événement métier sur un répartiteur de messages : c’est le type de dialogue
permettant à deux microservices de se synchroniser en échangeant non des données, mais des événements sur ces
données, en mode publication/souscription (dialogue de type ‘‘flot d’événement’’ en continu recevable par un service
qui peut répondre par un flot d’événement. Le service est dit réactif)
Service stateless ou service stateful :
- Un service est dit ‘‘avec état’’ lorsqu’il doit garder la trace de ses intéractions passées avec ses clients
- Un service ‘‘sans état’’ est sans mémoire : son client doit lui fournir toutes les informations nécessaires
Client avec ou sans contexte :
- Client sans contexte : à chaque appel, le client fournit au service les données nécessaires, à partir des éléments reçus
d’un utilisateur final. Le client ‘‘n’a pas de mémoireé’’, c’est un passe-plat
- Client avec contexte : le clinet doit conserver un contexte entre deux appels d’un même service. Un contexte peut aussi
être lié au concept de transaction longue (comprenant une intervention manuelle)
En tant que demandeur de service, que faut-il savoir pour émettre une requête?
Il faut connaître un description de chacune des opérations du service.
L’interface : Paramètres en entrée
Réponse == Comparable à signature d’une méthode
Qu’est-ce qu’un contrat?
Le contrat peut être formalisé dans n’importe quel langage respectant un standard interne à l’entreprise ou partagé à l’extérieur, le plus souvent en respectant un standard basé sur ceux du Web (par exemple WSDL basé sur XML ou OpenAPI basé sur JSON).
Le contrat doit être neutre par rapport aux technologies d’implémentation du client ou du pourvoyeur de service.
Sans le contrat, l’émetteur et le receveur de requêtes devraient présupposer qu’ils utilisent, par exemple, le même langage informatique ou du moins des technologies compatibles par nature, et qu’ils sont dans des conditions préétablies de bonne communication pour échanger.
Quel est le lien entre service et messages?
Lorsqu’un consommateur souhaite utiliser (requérir) une opératon d’un service, il transmet un message transportant sa requête.
Le message est transporté sur le réseau via un protocole de communication formalisant et organisant les échanges sur le réseau. En retour, et lorsque cela est nécessaire, le consommateur reçoit un autre message, qui est également transporté via un protocole de communication (généralement le même).
Le faible couplage entre service et messages permet :
- Une plus grande diversité de consommateurs
- Une plus grande diversité de fournisseurs
- Les modifications de l’implémentation du service en maintenant le respect du contrat
Le lien service et messages/contrat permet :
- La garantie de la qualité de son service (ajustement et respect des conditions d’utilisation, facilité de souscription, suivi de l’utilisation, etc.)
- Une fiabilité de transaction (le contrat est explicite, il n’y a donc pas de surprise)
- Un changement possible de fournisseur selon le même contrat
Que contient un contrat ‘‘de base’’?
La signature de l’opération en triplet :
, ,
Les messages doivent aussi transporter des informations métiers, dites sérialisées. Pour cela, le contrat doit aussi préciser la structure et le format de chaque information. (ex. on sérialise les détails d’une réservation en une structure de : date, numéro de vol, départ et destination).
Les opérations sont accessibles via un ou plusieurs protocoles de communication.
Le service est localisé à l’adresse d’une ressource physique donnée, autrement dit, en général, un serveur particulier.
Pour obtenir un service, de même que pour offrire un service, consommateur et pourvoyeur du service doivent respecter ce contrat, c’est-à-dire aussi se conformer à un protocole de communication et échanger des messages entrants et/ou sortants définis par le contrat.
Quel est le lien entre le contrat et la qualité de service?
Niveaux de qualité garantie par le pourvoyeur de service :
- Performance, disponibilité, exactitude
Contraintes et directives à respecter par les utilisateurs.
Un Service Level Agreement (SLA), inclus dans un contrat, comprend :
- Durée de la validité du SLA
- Le nombre de transactions consommables dans une plage de temps
- Les plages d’exclusivité éventuelles
- Débit, et temps de réponse
- Disponibilité du service (et sa mesure)
- Sécurité : limitation d’accès au service
- Le mode de surveillance et d’alerte en cas de problème
- Le mode de résolution de problèmes lors de la remontée de défauts concernant la délivrance du service conformément au SLA ainsi que le temps de prise en compte, les éventuels outils ou infrastructures et les moyens disponibles pour la gestion de tickets
- Coût d’appel, et compensation en cas de défaillance du service
À quoi correspond l’association SLA - Contrat?
Un SLA -> plusieurs contrats
Un contrat -> plusieurs SLAs
