Semaine 5 Flashcards
Qu’est-ce que la collaboration entre composants?
Identifier la collaboration entre composants en réponse à une interaction entre acteur et système dite ‘‘événement système’’
Composant = service ou autre composant informatisé du système
Contrainte 1 : Il faut une façade entre application et services => un ou plusieurs services applicatifs pour :
- Coordonner les appels aux services métiers et techniques
- Traitement de gestion métier (processus d’intervention)
Résultat : différents services applicatifs en fonction des terminaux et canaux d’accès. == Correspond au pattern ‘‘Backends for Frontends’’ (BFF)
Contrainte 2 : On a besoin d’expertise métier pour créer/programmer le processus de suivi d’une requête => le service applicatif doit :
1. Avoir recours à un service ‘‘fonctionnel’’ qui permet des traitements selon la logique du métier et l’expertise en ce domaine
2. Appeler le service de gestion de processus métier; ce processus devrait créer l’intervention et envoyer des notifications au client
Quelles sont les règles générales sur la dépendance des services?
- Deux services applicatifs de même niveau ne peuvent s’appeler entre eux, sauf exception.
- Deux services fonctionnels de même niveau ne peuvent s’appeler entre eux, sauf exception.
- Un service applicatif utilise un/des service(s) monde métier de niveau(x) inférieur(s) (service fonctionnel, service monde métier) et un/des service(s) technique(s)
- Un service technique n’appelle par un autre service technique, sauf exception.
- Un service n’appelle par un service d’un niveau supérieur : les appels synchrones se font en cascade, de haut en bas de la hiérarchie.
- Un service qui propage en asynchrone un événement métier ne doit pas faire d’hypothèse sur le(s) service(s) abonné(s). C’est aux abonnés d’interpréter l’événement en fonction de leurs besoins propres.
- Un service doit être utilisé au moins une fois, soit par une application composite, soit par un autre service, sinon son utilité est douteuse.
Quels sont les différents types de services?
Service métier applicatif (SA):
- Granularité : Forte
- Réutilisabilité : Sans objet, un SA est spécifique d’un besoin métier ou d’une application
- Interopérabilité extérieure du SI : Forte, services qui ont vocation à être accessibles de l’extérieur du SI
Service métier fonctionnel (SF) :
- Granularité : Moyenne à forte
- Réutilisabilité : Moyenne (accès à des informations de synthèse) à forte (traitements et simulation tarifs)
- Interopérabilité extérieure du SI : Dépend du contexte
Service monde métier :
- Granularité : Moyenne à forte
- Réutilisabilité : Forte
- Interopérabilité extérieure du SI : Sans objet, ne devrait pas être directement accessible
Service technique :
- Granularité : Moyenne à forte
- Réutilisabilité : Forte
- Interopérabilité extérieure du SI : Sans objet, ne devrait pas être directement accessible
Service légataire :
- Granularité : Forte
- Réutilisabilité : Faible à moyenne (selon la structure de l’existant)
- Interopérabilité extérieure du SI : Sans objet, pas d’ouverture de l’existant extérieur
Qu’est-ce que les anti-patterns?
Anti-pattern ‘‘nano-services’’
- Problème : Trop de services
- Déployer trop de services peut tuer une SOA :
– La complexité du système croît de façon non linéaire avec le nombre de services
– La difficulté de l’intégration et du test de ce système croît en conséquence
– Multiplier le nombre de services, c’est multipler le risque de mitrailleuse à événements
Anti-pattern : « Mitrailleuse à requêtes »
- Syndrome: une application cliente ou un service client répète très fréquemment un appel à un service pour effectuer son propre travail. Il devient une « Mitrailleuse à requêtes »
- Ex. Un service effectue des recherches d’objets, et dès qu’il trouve un objet, il demande à un autre service d’en lire les
détails.
– Solution possible : Inclure l’opération de lecture de détails dans le service de recherche + penser à garder le service lecture de détails s’il est utile pour autres services ou app clients
Anti-pattern : « intégration dans le brouillard »
- Problème: intégration « big bang » qui n’est pas graduelle
- Des moyens de solution envisageables:
– Au cours du développement, créer des simulateurs services « mock » pour les services qui n’ont pas été créés. Ceci permet, à chaque étape de développement, de tester l’intégration graduelle des services déjà créés
– Utiliser des outils comme ELK qui permettent de collecter des informations sur les traces de communication entre services
– Utiliser des techniques d’audit et de test pour différentes configurations (dév. et déploiements)
Anti-pattern: « Le déploiement est un problème »
- Le déploiement est un problème: malgré les tests tous réussis d’une nouvelle version, la mise en opération du système
peut révéler des problèmes qui sont en relation avec le contexte de déploiement des composants du systèmes sur les
machines d’hébergement.
- Solution envisageable:
– Déployer en parallèle la nouvelle et l’ancienne version => différentes instances d’un service sur différents nœuds.
– Avantage des conteneurs
Qu’est-ce qu’une architecture réactive?
Architecture réactive: elle traite et gère continuellement des événements => reçoit, traite, stocke, crée, émet des événements.
Flots d’événements:
- Un service s’abonne à un flot d’événements (év.) => il en reçoit les événements
- Un service peut publier ses év. sur un ou plusieurs flots d’év
Nécessité d’architecture réactive :
Une architecture réactive est nécessaire du moment où le SI commence à gérer des flots d’événements métiers de grains plutôt fin, envoyés en continue, avec une fréquence importante.
Quels sont les différents types de flots d’événements?
Flots de type ‘‘rapide’’ (ou cascade) : tous les événements bruts sont postés dans ce type de flot. Il y a un très fort débit, mais le volume de données par événements est faible. De plus (en général), la perte d’un message ne sera pas un problème si les événements sont émis périodiquement
Flots de type ‘‘rivière’’ : ce sont des flots d’événements ‘‘dérivés’’. Ils sont issus de la consolidation ou la transformation d’événements bruts avec une cible plus restreinte. Le débit est plus faible, mais le volume de données par événement est plus important. En outre, la perte d’un message peut avoir des conséquences si on n’y prend pas garde
Lacs de données : ces larges étendues de données reçoivent les ‘‘rapides’’ et les ‘‘rivières’’; elles contiennent l’historique des informations brutes et les états de synthèse. C’est le premier endroit où aboutissent les événements en terme de stockage
Quelles sont les exigences de systèmes réactifs?
Rapide: face aux utilisateurs finaux
Robuste: niveau de chaque service (autonome) + niveau système entier
Élastique: adaptant ses capacités de traitement et de stockage => surveillance + plusieurs instances du même service
Orienté message et non bloquant : (événements == messages ) + émission d’un message ne doit pas bloquer l’émetteur
Règles de Stonebraker :
1. Il faut décider et répondre vite
2. Pas de repos pour les données : utiliser RAM au lieu de stocker + éviter polling
3. Le réseau n’est pas parfait: Il faut prendre en considération les événements perdus, dédoublés, en retard, etc.
4. Intégrer les données du passé et du présent => meilleur interprétationtraitement des év.
5. Robustesse (data safety and availability) : envisager le redémarrage rapide de services
6. Performance extensible : envisager les cluster de machines et le calcul distribué (ex. base de données distribuées)
7. Utiliser un outil adéquat pour gérer le temps: car un év. est un objet temporel => operateurs de temps requis (ex. traitement des év. en fonction de fenêtre de temps)
Quelles sont les caractéristiques techniques des flots d’événements?
Caractéristiques == attributs caractérisant un événement:
- Temporel (création, émission, réception);
- Périodicité possible;
- Identifiant (de l’émetteur et/ou d’év.)
- Type (alerte, trace, état d’objet);
- Éventuellement une valeur
Un flot d’év. s’apparente à une queue FIFO
- à laquelle accèdent d’une façon non bloquante les émetteurs publiant ainsi que les consommateurs qui souscrivent au flot d’év.
Quels sont les techniques et patterns pour SOA réactive?
Le pattern fondamental « observateur »
- « observateur » : Pattern hérité de l’orienté objet.
- Contexte: comment organiser d’une façon simple la relation entre un flot d’év. d’un côté et ses consommateurs de l’autre?
- Solution:
– « observateur » s’abonne au flot ( « observable »)
– « observable » dresse une liste d’observateur et les notifie chaque fois qu’un év. survient
– « observable » reçoit trois types d’év.: arrivée d’un nouveau message + message d’erreur + message fin du flot. (implémentation « reactive stream de java 9)
Technique de « Tronçonnement » (Pipeline)
- Établir un filtre qui reçoit les événements d’un flots et les transforme selon les besoins pour :
– transformer un débit à haute fréquence d’év. en un débit à une fréquence inférieure mais avec des év. plus riche en information utile.
- Exemple de traitement/transformation:
– Mapping: une valeur vers sa correspondance utile
– Bufferiser: pour usage de tampon
– Scanner: pour compter certains types d’év.
– TimeOut, .., etc.
Le concept de fenêtre temporelle
- Traiter des fenêtre temporelle au lieu d’év. individuels
- Une fenêtre peut être définie :
– En nombre d’événements : prendre les n derniers événements
– Par rapport à une horloge : prendre tous les événements des n dernières secondes
– En termes de ‘‘points d’arrêt’’ : prendre tous les événements entre deux points d’arrêt positionnés dans le flot
Pattern SEDA
- SEDA : Staged Event Driven Architecture
- Contexte : flot d’évènements trop lourd pour subir la transformation par un seul pipline
- Solution: remplacer un pipline par plusieurs piplines ( plusieurs étages); chacun ayant son propre processeur =>
– Plusieurs processus
ou
– déploiement sur plusieurs conteneurs
Pattern LAMBDA
- Contexte : Flot d’événements à un debit très important + besoin de traitement temps réel (à la volée) et de traitement en
batch (traiter une partie de l’historique des données)
- Solution : une architecture à deux branches
– Une pour traitement à la volée
– Une pour traitement en batch
Quels sont les outils utilisés par les patterns?
Un middleware pour implémenter les flots de données sous forme de queue FIFO de messages émis par les sources.
- Ex. Apache Kafka, RxNetty
Un outil de développement de services capables de s’interfacer avec des flots d’événements et traiter des év. Temporels.
- Ex. Un standard Reactive Stream implémenté avec Java 9 qui prend en charge aussi un framework pour microservices
- Un langage orienté flots d’év. Akka
- Outil hébergé dans le Cloud (par exemple : Microsoft Azure Event Hub, Amazon Kinesis, ou Cloudera basé sur Kafka).
