Annales

Questions de cours
Activation et passivation dans « Object pool » : respectivement la création d’objets et leur retour au pool après leur utilisation pour être réutilisés ultérieurement.
Application RMI (Remote Method Invocation) : permet à des objets Java de communiquer et d'appeler des méthodes sur des objets distants, situés sur des machines
différentes, en utilisant une infrastructure de communication basée sur des sockets ; donc serveur et client lancés avec l’@IP d’une même machine.
Sharding de cache : divise les données en partitions et les stocke sur différents serveurs de cache en fonction de l'identifiant de chaque donnée.
Paliers d’une stratégie d’urbanisation : structurer et organiser les services et composants d'un système informatique Référentiel de dépendances : décrit explicitement
en couches hiérarchisées, facilitant ainsi l'évolutivité, la modularité et la réutilisation des fonctionnalités. les liens des objets entre eux et avec le conteneur.
Patterns IoC & Contexte : utilisent un conteneur pour gérer la création et l'injection de dépendances dans une application.
Gain de perf avec pattern Object pool : mesure en comparant le temps d'exécution de l'application avec et sans l'utilisation du pool d'objets.
Scalabilité : (1) Dimensions : horizontale (ajout ou suppression de nœuds pour gérer la charge de travail) / verticale (améliorer les perfs et la capacité d’un nœud en ajoutant
ou suppr des ressources) / fonctionnelle (optimisation de l’efficacité et des perfs d’un système en améliorant les fonctionnalités, les algos, les processus internes). (2)Archi
micro-services : modularité et indépendance (fonctionnelle) / évolutivité (horizontale) / résilience (horizontale) / déploiement (horizontale)
APM (Application Performance Metrics) : (1) permet par exemple d’identifier les transactions les plus lentes d'une application web, ainsi que les causes profondes des temps
de réponse lents qui affectent négativement l'expérience utilisateur (2) Apache Bench : pas suffisant pour mesurer la perf globale d’une application car elle se mesure côté
client ; ne permet pas de mesurer la perf des interations entre les composants internes au SI, ni perf des opération asynchrones
PicoContainer : pas d’injection de dépendances par interfaces (il faudrait définir toutes les interfaces), remplacé par injection de dépendance via les constructeurs (méthodes)
Pattern Annuaire & Contexte : pour être générique, un contexte/annuaire ne stocke que des Object donc il faut cast pour utiliser les méthodes
Utilisation handler : cas d’utilisateur qui ne nécessitent pas les en-têtes (ex : validation du payload) ou les CU qui utilisent des informations des en-têtes qui ont été traités
par d’autres handlers auparavant (ex : autorisation)
JAVA EE à Spring : sur Java EE, EJB (type session, entité, message) non conservée sur Spring car trop restrictive, pas extensible / ne correspond plus aux besoins actuels ( ex :
plus besoin d’EJB depuis JPA) ; remplacé par les annotations @Service, @Repository et @Controller, ou fournies par des sous-projets de Spring suivant les préoccupations
Services Angular : pas de fichier .html ou .css comme les composants car pas de responsabilité d’affichage (interface) donc par d’arbre DOM et pas de mise en forme.
Framework OSGI : deux fonctionnalités permises grâce au principe de Design by Contract, le chargement de modules à distance et maj « à chaud » (no reboot)
Langage IDL : utilisé en CORBA, il n’est pas RMI car pas besoin d’un autre langage SOAP & Design by Contract : intérêt, cacher l’implémentation au client (secret
pour décrire les interfaces (Java) industriel)
Mauvaises pratiques microservices : utilisation d’un bus de service dans une Enterprise Integration Patterns : permet de rajouter de la souplesse dans une
architecture microservices, « smart endpoint, dumb pipe », endpoints = métier / démarche de conception car développement des services / handlers séparément et on
pipe = communication les assemble ensuite
Injection de dépendances & Design by Contract : l’injection par constructeur « impose » la forme du composant, tandis que l’injection par interface ou par setter laisse la
liberté de la spécifier.
Pattern Object pool : simplifie la gestion du cycle de vie des objets en évitant leur création et leur Keycloak : un realm sert à séparer données d’identification et de
destruction gestion des accès entre applications
SOAP : message SOAP similaire à une requête ou réponse http car il possède une partie Header et une partie Body
Communication entre services : communication entre services via file de message se distingue des communications REST car pas de requête-réponse (simple envoi de msg)
Déploiement continu : on a besoin des éléments d’architecture suivant, environnement de test et services de supervision pour détection automatique plantage / bugs
Docker & Kubernetes : on choisira de déployer deux containers Docker dans des pods Kubernetes différents pour avoir cycles de vie et impératif de scalabilité différents
Architecture fonctionnelle : on retrouve deux exemples de « quartiers », processus de pilotage, gisements de données, activités opérationnelles…
Implémentation de services (figure 2) : diagramme de séquence JAXB / Servlet / Intercepteur JAX-WS / Classe @WebService / Interface @WebService
Études de cas
Étude de cas 1
- Description : application de gestion des notes d’examen distribuée ; enseignants ont un client web sous forme de SPA qui se connecte à un serveur qui centralise ces
données ; étudiants ont une interface qui leur permet de les consulter. Les services administratifs ont une API qui leur permet d’y connecter leur système.
- Technologies : Spring Boot (application distribuée) / NGINX (équilibrage de charge) / Kubernetes (mise à l’échelle)
- Composants côté serveur : @Controller (gestion requêtes entrantes) / @Service (métier) / @Repository (persistence)
- Optimisation étudiant pour consultation notes : cache côté client (LocalStorage) / optimisation des requêtes à la BD (index)
- Optimisation enseignant pour calculs moyenne : traitement asynchrone (file d’attente – Apache Kafka) / interface utilisateur + interactive
Étude de cas 2
- Description : application pour les vœux d'établissements d'études supérieures ; plusieurs étapes, dont le traitement des vœux par un algorithme centralisé et la
possibilité pour les représentants des établissements de réordonner les vœux ; postulants peuvent consulter leur futur établissement et les services centraux du
Ministère supervisent l'état des opérations.
- Technologies : Spring Boot (microservices, SOA) / Hibernate (persistence) / Azure SQL Database (hautement disponible) / Apache Kafka (synchronisation)
- Optimisation si lycéens entrent vœux tous en même temps : mise en cache / load balancing (plusieurs serveurs) / compression des données / éliminer goulot
étranglement (sharding) / optimisation BD / file d’attente, asynchrone (RabbitMQ)
- Optimisation si représentant consulte la liste des vœux : index de recherche dans BD / pagination / outils monitoring (APM) / cache
SOAP vs REST : REST est recommandé par rapport à SOAP en raison de sa simplicité, de sa performance, de son évolutivité, de sa sécurité et de son intéropérabilité
Bus de message
- Description : implémenter un service synchrone (de type requête-réponse) en faisant appel à un bus de messages (par exemple RabbitMQ ou Kafka).
- Solution : 1. Utiliser des identifiants uniques pour les requêtes et les réponses. / 2. Utiliser des files d'attente ou des topics séparés pour les requêtes et les réponses.
/ 3. Faire en sorte que le client écoute les réponses correspondant à ses requêtes.
- Défi : latence, la gestion des temps d'attente -> piste : Timeout si aucune réponse
Sécurisation de service Cache applicatif
- Description : architecture permettant de sécuriser l'accès à un service - Problème : proposer des actions pour identifier les problèmes de performance malgré
- Technologies : Spring Security (vérification token) / Spring Cloud le cache
Gateway - Solution : outil de profiling / examiner logs (identifier requêtes longues) / tests de charge
Adaptation
- Problème : 2 services avec mêmes fonctionnalités mais schémas XML différents
- Solution : API de conversion de données (XSLT) / protocoles SOAP ou REST (communiquer entre services) / JAXB (convertir objets JAVA en XML vice versa)
Étude de cas 3 Étude de cas
- Description : Système (simplifié) de gestion de l'entretien d'une flotte de trottinettes électriques - Description : partie "Ressources Humaines" du système
proposées à la location ; on se concentre sur le changement de batteries des trottinettes. d'information d'une entreprise de fabrication de pièces
- Architectures microservices : algorithme d’allocation, gestion des données des coursiers, gestion mécaniques.
des données des trottinettes, gestion des tâches de remplacement de batterie, reverse-proxy, bases - Mise à l’échelle : horizontale pour le nombre de requêtes
de données et le nombre de connexions
- Problème de perf / Goulots d’étranglement : algo coûteux / maj infos géolocalisation - Services critiques : authentification et gestion des salaires
- Messages : envoi de position (trottinette, coursier), batterie faible, ajout d’une tâche de et des impôts ; fiabiliser avec de la redondance (cluster avec
changement de batterie pour un coursier. Le diagramme doit indiquer qui envoie et qui reçoit un répartition de charge, duplication données sur plusieurs
message serveurs, sauvegardes régulières) et mesures de
- Solution : réplication des service pour algo d’allcoation / distribution des données surveillances et supervision
 CM1 – Inversion de Contrôle - Conteneurs
Rappels sur les patrons de conceptions : Nom, Problème, Contexte, Forces/Contraintes, Solution
Thèmes abordées
SOA (Service Oriented Architecture) : approche de conception logicielle qui consiste à décomposer les fonctionnalités en services autonomes et interopérable pour
faciliter la maintenance, l’évolution et l’intégration des SI / Microservice : architecture logicielle qui permet de découper une application en plusieurs services autonomes,
indépendants les uns des autres, et communiquant via des API bien définies
IoC
Problème : Réduire les dépendances et la complexité de gestion du cycle de vie des objets | Principe : Utilisation d’un conteneur pour gérer le flot d’exécution d’une app. |
Autres nom : Injection de dépendances / Injection de code | Exemples : Swing, Serveur Web, Conteneurs d’objets (servlet, EJB) | Objectif : meilleure modularité + meilleure
évolutivité
Bibliothèque vs Framework : bibliothèque = fonctions pour app, framework = contrôle flux, invoque méthodes app, IoC. | framework = initialise un ou plusieurs conteneurs,
conteneur communique avec services extérieurs et objets de l'application, objets sont composants de l'application, conteneur instancie, isole, utilise et détruit composants.
Conteneurs
Définition : contient le main de l'application, permet bon fonctionnement des composants, gère cycle de vie, injecte dépendances, isole les composants, communique avec
services extérieurs, filtre les entrées/sorties de l'application, peut séparer les couches de l'application (ex : MVC). | Fonctionnement : Initialisation, instanciation,
configuration, gestion des objets et communication avec des services extérieurs | Types : Légers (Spring, Pico, NanoContainer), Lourds (conteneurs d'EJB), Dynamiques (OSGi)
Instanciation : inversion de contrôle par configuration (statique : XML / annotation) ou inversion de contrôle dynamique | Initialisation : recherche des composants à
instancier, résolution des dépendances à injecter, isolation des composants, contrôle/ordonnancement de l'exécution des composants en fonction de la configuration.
Initialisation : conteneur recherche dans sa config les composants à instancer / résolution d’un référentiel de dépendances (gestion centralisée des dépendances) et
recherche des dépendances à injecter dans chaque composant / isolation des composant à l’aide d’un contexte d’application / contrôle, ordonnancement exécution
composants
Fonctionnement : création (factory) / création + config (builder) / cas particulier gestion des singletons
Injection de dépendances
Objectif : rendre l’inversion de contrôle transparente pour les objets | Fonctionnement : Utilisation d’un référentiel de dépendances et résolution par le conteneur |
Méthode d’injection : par constructeur, par modificateurs (setters), par interface (implémentées par classes concrètes), par proxy
Frameworks
Définition : outil qui contrôle de flot de déroulement de l’application | Composants : Conteneurs d’objets + Contextes applicatifs + MVC + Mécanismes de configuration +
Services annexes (logs, sécurités, transactions…) | Intérêt pour le programmeur : réutilisation de code, modularité, respect des bonnes pratiques, maintenance et évolutivité,
accélération du développement
CM2 – Contexte - Annuaire
Rappel sur l’isolation des composants : Gérer la visibilité, maîtriser et contrôler les communications entre composants, mettre à disposition thématiquement les
dépendances. | Patterns liés : Façades (interface pour un ensemble de fonctionnalités complexes) / indirection (interface et implémentation, délégation), fabrication pure
Contexte
Définition : Un conteneur diminue le couplage entre ses composant en les isolant les uns des autres de l’exterieur | Problème : Les composants ont besoin de communiquer
entre eux et avec l'extérieur. Le framework doit pouvoir contrôler les communications avec et entre les composants. | Principe : Ajout d'un niveau d'indirection entre
conteneur et composants. | Exemple : javax.servlet.ServletContext | Avantages : isolation des composants, contrôle des communications, évite l’anti-pattern « ne pas parler
aux inconnus » | Inconvénients : rajoute un niveau d’indirection (complexité), peut être en contradiction avec la loi de Demeter (least knowledge)
Annuaire
Problème : diminuer le couplage entre les composants, renforcer l’isolation entre les composants | Principe : rajouter un niveau d’indirection qui centralise les références
sur les composants accessibles, sotkce et renvoie les références (en général sous forme de paires clés-valeurs) | Autres noms : Registre (registry), Serveur de noms (Naming
Directory) | Caractéristiques : intégré à Java SE depuis le JDK 1.3, standard utilisé pour de nombreuses technologies (LDAP, DNS, RMI, EJB) / 2 types d’API : API JNDI Client et
API JNDI SPI (Service Provider Interface) | API « client » : utilisation d’un annuaire indépendamment du SPI, accéder à un contexte application initial (lié à l’application) ;
enregistrer un objet (serveur), explorer/modifier la hiérarchie de contextes (client & serveur), retrouver un objet (client)
CM3 – Métaprogrammation
Définition : écriture de programme capables de traiter d’autres programmes comme des données | Approche de la métaprog : utilisation d’APIs pour exposer le
fonctionnement interne d’un programme / exécution dynamique d’expression contenant du code / utiliser un langage pour en programmer un autre | Exemples en Java :
Reflection API, génération automatique de code | Pourquoi générer du code : réutilisation, efficacité, délégation des tâches répétitives
Métaprogrammation par annotations
Annotations : lier des valeurs de configuration aux éléments du code métier | Approche générale : abstraire et isoler les traitements répétitifs, annoter le code métier, utiliser
un mécanisme pour lier le code annoté et les traitements | Annotations en Java : automatisation de traitements sur le code (métaprogrammation)
Annotations en Java : Intégrées depuis Java SE 5 / Préfixées par « @ » / Applicables à différents types d’éléments (packages, classes, interfaces, etc.) / Peuvent être
standard ou non standard | Avantage de la métaprogrammation par annotation : gain de temps / élimination des erreurs de programmation / réduction de la
maintenance des fichiers annexes | Processeurs d’annotations : implémentent les traitements annexes pour chaque annotation / accèdent aux éléments du programme
par introspection | Déclaration d’une annotation : utilisation du mot-clé « interface » précédé par @ / ajout d’attributs avec des méthodes ayant un type de retour et un
nom / qualification avec des méta-annotation standard (ex : @Documented, @Inherit, @Retention, @Target) | Traitement des annotations non standard : réalisation d’un
AnnotationProcessor en dérivant de javax.annotations.AnnationProcessor / implémentation de la méthode process() | Liage des annotations non standard : utilisation de
l’outil Annotation Processing Tool (APT) ou l’API Pluggable Annotation Processing (intégré au compilateur javac depuis JDK 6) / configuration du maven-compiler-plugin
pour une utilisation avec Maven | Outils liés : JavaPoet (généréation de code Java) / Filer (écriture dans la GeneratedSourceDirectory d’un projet Maven)
Programmation Orientée Aspects
Définition : séparation des préoccupation, permet de modulariser et réutiliser des aspects spécifiques / exemples d’application : injection de dépendances, journalisation,
sécurité | Position du problème : gérer les fonctionnalités transverse d’une application (accès aux données, transactions, sécurité) / regrouper le code lié à ces fonctionnalités
et les séparer de la logique métier / avantages : productivité, maintenance, réutilisabilité | Limites du paradigme objet : données encapsulées dans les classes / traitement
similaires sur des données différentes / différentes considérations (aspects) de l’application représentés au même niveau d’abstraction / pollution du modèle métier par les
fonctionnalités transverses | Le paradigme aspect : complémentaire au paradigme objet / une application comporte des classes et des aspects / chaque aspect permet
d’obtenir une « vision » différente de l’application (métier, données, sécurité, etc.)
---- Concepts de base / glossaire ----
tangled code : code embrouillé, code spaghetti | crosscutting concerns : aspects de la programmation qui concernent plusieurs classes et transcendent le modèle objet
(synchronisation, logging, persistance, etc.) | crosscut : ensemble ou sous-ensemble des points de jonction liés à un aspect dans une application | joinpoint : endroit du code
où il est autorisé d’ajouter un aspect (avant, autour de, à la place ou après l’appel d’une fonction) | pointcut : endroit du code métier où est inséré le code de l’aspect, décrit
un ensemble de joinpoints | advice : fragment de code qui sera activé à un certain point de coupe du programme, doit correspondre à une définition de point de coupe |
déclaration inter-types : ajout de nouveau éléments structuraux au code de l’application, extension du comportement d’une classe, modification des relations d’héritage |
weaver : infrastructure pour greffer le code des aspects dans le code des classes, peut avoir lieu à différentes étapes (avant la compilation, durant la compilation, après la
compilation, pendant l’exécution)
Outils orientés aspects : disponibles dans de nombreux langage (Java, C++, PHP, Python, CommonLisp, Ruby, etc.) / outils Java (tisseurs) : AspectJ, Spring, JBoss, Equinox |
POA et méthodes de conceptions : isoler les responsabilités des objets et ajouter des comportements à l’aide d’aspects / utiliser et améliorer les patterns du GoF (Gang of
Four) / Exemple : pattern Observateur, où la notification est un crosscut
Conclusion : la métaprogrammation et le programmation orientée aspect permettent d’améliorer la réutilisation, l’efficacité et la modularité du code / Les annotations en
Java et la POA sont des outils utils pour la conception et le développement de logiciel.
CM4 – Bus de message et patrons d’intégration
Composition de services
Service : peut être vu comme une interface sur des processus métier utilisant à leur tour des services qui réalisent des actions à plus petites échelle / moins complexes |
Pourquoi composer des services ? : Pour la logique applicative complexe, la décentralisation des traitements et la décomposition des processus. | Quelques problématiques :
Transactions longues, instances multiples, concurrence, distribution, gestion des messages | Orchestration vs chorégraphies : l’orchestration consiste en une exécution
centralisée des processus tandis que la chorégraphie implique une collaboration décentralisée entre les processus
Patrons d’intégration
Patrons d’intégration : design patterns spécifiques à l’intégration dans les systèmes d’information, tels que les Queues, les Topics, les canaux persistants, les consommateurs,
les frameworks de transmission de message, la sérialisation et la transmission | Consommateur : synchrone et asynchrone (via callback) | Frameworks : routage, garanties
Pipeline de services
Traitement composite de messages : transformation de contenu, filtrage de messages, routage basé sur les messages, pipeline dynamique, division/agrégation et
réordonnancement de message où chaque étape correspond à un appel de service / 1 appel = 1 service, quand un service a fini il appel le service suivant | Plusieurs types
de transformations : FILTRE / RESTRUCTURATION / ENCAPSULATION / ENRICHISSEMENT | Routage basés sur les message : le contenu du message sert à trouver la
destination (peut être transformé avant) | Routage dynamique : routage basé sur le système (disponibilité des receveurs) | Pipeline dynamique : un petit texte est écris
dans le contenu d’un message pour définir la séquence des étapes de traitement | Bus de services : serveur / cluster permettant d’assurer la communication entre les
différents composants d’un système d’information (hébergement, intégration, routage, connecteur, gestion)
CM5 - Urbanisation
Définition : L'urbanisation est un processus qui vise à organiser et à optimiser l'ensemble des systèmes d'information d'une entreprise ou d'une organisation en alignement
avec ses besoins stratégiques et opérationnels. Il s'agit de définir une architecture d'ensemble cohérente et évolutive, ainsi que des principes d'organisation des différents
composants des systèmes d'information. L'urbanisation permet ainsi de mieux maîtriser les coûts de développement, de maintenance et d'exploitation des systèmes
d'information, tout en garantissant leur performance et leur évolutivité.

En résumé c’est diriger la transformation continue du Système d’Information en vue de le simplifier et garantir sa cohérence. 4 Grandes Étapes :
Définition des objectifs : Stratégie commerciale
►Analyse de l’existant
▪ Lister le patrimoine ▪ Cartographier les différentes couches (métier, fonctionnelle, applicative, ...)
►Identification du SI cible
▪ Impact sur le différentes couches ▪ Prise en compte des contraintes (humaine, matériel, ...) ▪ Définition des livrables
►Mise en évidence de la trajectoire ▪ Planning ▪ Définition des paliers
Architectures
Métier : processus métier / touche à l’orga et aux personnes / meilleur compréhension / dialogue MOA – MOE
Fonctionnelle : on a besoin de quoi ? / cohérent métier / découpage des tâches / présentation hiérarchique
Applicative : base réalisation (techno) / + de valeur et + solution par rapport à l’archi fonctionnelle
Système : avec quoi et où fonctionnent les appli / fait le lien appli-serv / indispensable pour évaluer le coût / apport concret CIBLE FONCTIONNELLE
et structurant

ANNEXES
Figure 2 Archi applicative

Figure 1 Archi métier