GMIN30F Réutilisation / Composants

Présentation au sujet: "GMIN30F Réutilisation / Composants"— Transcription de la présentation:

1 GMIN30F Réutilisation / Composants
Intervenant : André Morassut

2 Informations légales Ce document est la propriété exclusive de Berger-Levrault, toute reproduction même partielle est interdite sans l’autorisation écrite des services idoines de Berger-Levrault. Le logo Berger-Levrault est la propriété exclusive de Berger-Levrault S.A. Les autres images de cette présentation sont issues de commons.wikimedia.org

3 Structure Contexte industriel
Le contexte « industriel » la perception des notions Convergences et motifs : réutilisabilité et composants Un cas d’expérience : le CORE WEB2 Réutilisation et composants – En pratique Réutilisation « passive » et « active » Composants internes et externes Pratiques actuelles Présentation d’outils représentatifs de l’outillage actuel favorisé par les éditeurs de logiciel

4 seconde partie

5 Projet de développement
Réalisation d’un projet JAVA EE+MAVEN+SPRING Serveur REST sur base JPA Grandes étapes de mise en place : Partie 1 : Mise en place du projet Branchement de MAVEN Mise en place de SPRING Définition d’un service REST « helloworld » Partie 2 : Mise en place de JPA Création des entités métier + DAO + services Branchement des services REST

6 Travaux de programmation
Partie 1 - Webapplication

7 Partie 1 - Webapplication
Focus sur les briques manipulées : MAVEN : voir partie 1 du cours SPRING : « boîte à outils » en lien avec JAVA EE REST : approche architecturale consistant en une ensemble coordonné de contraintes sur l’utilisation d’abstractions (structuration des informations, composants, connecteurs, …) de l’architecture du « world wide web » Serveur JAVA EE : Serveur WEB intégrant des logiques de traitement des cycles de vie d’aspects normés JAVA EE.

8 SPRING

9 SPRING Synthétiquement, SPRING présente des alternatives et des implémentations de normes JAVA EE SPRING présente de multiple facettes : IoC (Injection de dépendances) JPA & transactions : DsL, helpers, etc. Web application : lifecycle, servlets, etc. Security Autres: NoSQL, Social, Cloud, Batch processing, LDAP, Mobile, etc.

10 REST

11 REST REST = REpresentational State Transfer
Créé en 2000, REST s’impose largement en entreprise ces dernières années REST apporte: Un ensemble de contraintes architecturales Une approche d’abstraction Une ouverture technologique Une forte orientation composant Pour ces raisons REST est particulièrement adapté à une vision architecturale modulaire  Voyons les contraintes en détail

12 REST – Contraintes (1/4) Contraintes architecturales:
Client/serveur Sans état (Stateless) Cachable Système en couches Approche d’abstraction Implémentation WWW : Utilisation des « verbes » HTTP Utilisation d’un format de données ouvert : JSON, XML Utilisation des URI Utilisation des Hyperliens

13 REST – Contraintes (2/4) Ouverture technologique
REST peut être implémenté dans toutes les technologies permettant des composantes sous-jacentes (http, json, xml, etc.) Les notions à implémenter : Ressource = élément d’une API REST, c’est une opération unitaire Représentation = donnée structurée représentant une notion manipulée par une interface REST, en entrée ou sortie Message = communication client vers serveur ou inversement, pouvant contenir une ou plusieurs représentations par exemple « Hypermedia state » = opérations disponibles sur un serveur REST à un instant donné

14 REST – Contraintes (3/4) Orientation composant : REST propose une uniformisation des interfaces (contrats) autour de certaines contraintes Identification des ressources & séparation ressource/représentation Chaque ressource est identifiable par requête (utilisation des URI dans une implémentation www) et les représentations manipulées sont conceptuellement séparée des ressources (ainsi, un serveur peut retourner une information en JSON ou XML, celle-ci sera une projection de la représentation interne du serveur qui peut être éventuellement plus riche.) Les représentations permettent la manipulation des ressources  Les représentations retournées par un serveur en réponse à une requête sont suffisantes à un client donné pour qu’il puisse modifier ou supprimer les éléments correspondants

15 REST – Contraintes (4/4) Orientation composant : REST propose une uniformisation des interfaces (contrats) autour de certaines contraintes Messages auto descriptifs Chaque message contient les informations suffisantes pour permettre à un client de savoir comment les traiter. En pratique, c’est l’inclusions d’informations comme : encodage (utf-8, etc.), structuration (xml, json, etc.), gestion de la mise en cache, etc. HATEOAS : « hypermedia as the engine of application state »  Une API REST présentée par un serveur peut être vue comme une machine à état. Un client peut uniquement déclencher des transitions d’états à travers les opérations mises à disposition à un instant donné par le serveur.

16 Serveur JAVA EE

17 Serveur JAVA EE Un serveur JAVA EE (ex: Glassfish, JBOSS AS, etc.) est un serveur d’application implémentant un ensemble de normes JAVA EE. À travers un système de certification, ORACLE estampille un serveur comme « JAVA EE » s’il implémente correctement un ensemble de normes jugées indispensables Quelques serveurs JAVA EE: EE 7 : Glassfish 4, RedHat WildFly 8, … EE 6 : JBOSS AS7, Apache Geronimo 3, Glassfish 3, Websphere 8, …

18 Serveur JAVA EE Un serveur JAVA EE propose typiquement plusieurs moyens de configuration Console dédiée JMX connectors Un serveur JAVA EE permet la gestion des versions des modules qu’il intègre, indépendamment des applications Nous verrons l’intérêt d’un serveur d’application à travers la gestion de deux aspects : Injection de dépendances Gestion des transactions

19 Travaux de programmation
Partie 2 - Webapplication

20 Partie 2 - Webapplication
Focus sur les notions & briques manipulées : Modalités architecturales JAVA EE Applications en couche DAO & « Active record » En lien avec les serveurs d’application Inversion de contrôle : détail de cette notion Gestion des transactions : détail de cette notion JPA : norme JAVA EE de gestion de la persistance Aspects connexes : logging, Unit tests

21 Modalités architecturales
diapo 21 IBM Confidential

22 Modalités architecturales
Les architectures autour de JAVA EE convergent autour de quelques point essentiels Approche en couche Séparation des responsabilités Entités métiers & services essentiellement Stateless (versus stateful) Approche de persistance Par DAO Par « active record » diapo 22 IBM Confidential

23 Modalités architecturales
Détaillons les deux approches de gestion de l’isolation du code de persistance: Approche « Data Access Object » Les DAO sont des objets dédiés à la gestion de la persistance Les objets métiers n’ont aucune « intelligence métier », ce sont de simple conteneurs de données Les DAO intègrent une partie de l’intelligence métier (une couche service est souvent employée pour séparer l’orchestration de la persistance) Généralement, on met en place un objet DAO par objet métier avec extension d’une super classe regroupant les implémentations par défaut diapo 23 IBM Confidential

24 Modalités architecturales
Détaillons les deux approches de gestion de l’isolation du code de persistance: Approche « Active Record » Contrairement à l’approche DAO, le code de persistance est intégré aux objets métier Les objets métiers contiennent l’intelligence du métier Parfois, une couche service est mise en place pour des raisons d’orchestration. Par exemple, on peut avoir besoin de coordonner des objets Personne, Adresse, Ville, etc. pour réaliser une fonctionnalité métier d’enregistrement d’une nouvelle personne. diapo 24 IBM Confidential

25 Architecture Web, Active record
JAVA EE Container ou Spring Client Objets métier (Service) SGBDs Oracle / sql server / … Hibernate diapo 25

26 Architecture Web, approche DAO
JAVA EE Container ou Spring Client Service DAO Objets métier SGBDs Oracle / sql server / … Hibernate diapo 26

27 Modalités architecturales
Comparons les deux approches de gestion de l’isolation du code de persistance: Approche « Data Access Object »  L’approche DAO est particulièrement adaptée aux domaines métiers étendus, multi-sujets. Avantages Inconvénients Séparation des responsabilités Permet de factoriser du code par la superclasse de DAO Simplification des tests par « mock » ou « bouchonnage » Permet de remplacer une implémentation de manière ciblée Adapté à des projets de taille importante Le coût réel des appels en base de données est masqué Prolifération des DAO si le nombre des entités métier est élevé Il faut être vigilant pour ne pas introduire des aspects métiers dans les DAO diapo 27 IBM Confidential

28 Modalités architecturales
Comparons les deux approches de gestion de l’isolation du code de persistance: Approche « Active record »  L’approche Active record est intéressante quand le domaine métier est réduit et traite d’un objectif unique Avantages Inconvénients Simplicité Réduction du nombre de classes Cohérent avec l’approche objet : les entités métiers ne sont pas de simples conteneurs de donnée le domaine métier est peu malléable : si un objet donné doit être utilisé dans plusieurs contextes différents, son code s’en trouvera très complexifié lourdeur des refactorings Difficultés pour les tests diapo 28 IBM Confidential

29 Modalités architecturales
Ces deux approches sont très généralement mises en place de manière STATELESS. Ainsi, les services ne conservent aucun état et ne connaissent pas les sessions de travail des clients. Cela implique que chaque opération exposée par le serveur doit : - permettre d’aller d’un état cohérent du domaine métier à un autre état cohérent - ne pas requérir d’être orchestrée dans un ordre particulier  En réalité, l’aspect STATELESS de l’architecture rapproche l’API exposée par le serveur aux clients de REST. diapo 29 IBM Confidential

30 JAVA EE - Transactions & IOC

31 Injection de dépendances (1/8)
IoC signifie « Inversion of Control » L’inversion de contrôle est permise par l’injection de dépendances Principe de l’inversion des dépendances, permet : Suivre les évolutions techniques tout en épargnant le code métier Réflexion sur couplage fort versus couplage faible par interfaces. Un bon design objet est plus important que les technologies sous-jacentes. Tout code doit être facilement testable. diapo 31 IBM Confidential

32 Différentes dépendances (2/8)
B A utilise B A << I >> A implémente une interface I A B A hérite de B diapo 32 IBM Confidential

33 A B IOC - Conséquences (3/8) Les dépendances ne permettent pas :
D’installer A sans installer B Donc de réutiliser A sans réutiliser B Une modification de B Peut entraîner une modification de A Une recompilation de A Il y a perte de réutilisation et de modularité A B diapo 33 IBM Confidential

34 A B IOC - Conséquences (4/8) Objectifs : Eviter
Rigidité Application difficile à modifier car chaque changement affecte d'autres parties du logiciel Fragilité Une modification entraîne des effets de bords : BUG Immobilité Difficulté de reprendre une partie de l'application car elle ne peut pas être indépendante des autres parties A B diapo 34 IBM Confidential

35 IOC - Direction (5/8) ou  Peut-on choisir le sens d’une dépendance ?
Classe A Classe B Classe A Classe B ou  Peut-on choisir le sens d’une dépendance ? diapo 35 IBM Confidential

36 Inversion de dépendances (6/8)
Situation de départ Classe A Classe B Interface I Ajout d’une interface Classe A Classe B implémente diapo 36 IBM Confidential

37 Injection de dépendance (7/8)
Problématique initiale : pouvoir remplacer l’implémentation utilisée par un composant de manière simple L’injection a pour base la notion d’interface : le composant « utilisateur » se base sur un « contrat » Pattern : ClasseA IClasseB ClasseB implémente setIClasseA() Cible de l’injection diapo 37 IBM Confidential

38 Injection de dépendances (8/8)
Dans le cadre d’un serveur d’application : Via un conteneur JAVA EE (serveur JAVA EE), nous allons pouvoir laisser celui-ci gérer les injections Ainsi, selon la charge, les éléments de paramétrage, etc. le serveur va décider d’instancier, réutiliser, mettre en cache, etc. les ressources déclarées en injection D’autres ressources peuvent être injectées : Data sources Règles de sécurité Etc. Les serveurs peuvent être configurés pour fonctionner en coopération : gestion de la charge, réplications, etc.  Un tel serveur représente une composante importante d’une architecture industrielle, rendant des services qui sont de fait découplés des applications métier (séparation des responsabilités)

39 Gestion des transactions
Notion de transaction : Une transaction permet d’associer un ensemble d’opérations dans une session de travail. Si les exécutions de toutes les opérations se terminent correctement la transaction aboutie Si une des opérations ne se termine pas correctement, la transaction échoue

40 Un exemple La réservation d’un billet de spectacle
4 opérations OK 1- Consultation des places disponibles 2- Réservation de la place 3- Réception du paiement 4- Émission du ticket de réservation Réserver billet 1 opération KO diapo 40

41 Propriétés ACID (1/2) Propriétés fondamentales d’une transaction
Atomic (Atomicité) Les opérations qui constituent une transaction forment une unité indivisible : soit l’ensemble des opérations est mené à terme, soit aucune opération n’est effectuée. Consistent (Cohérence) La base passe d’un état initial cohérent à un état final cohérent, dans le respect des règles d’intégrités référentielles définies sur la base de données. diapo 41

42 Propriétés ACID (2/2) Isolated (Isolation) Durable (Durabilité)
Les mises à jour effectuées au cours de l’exécution d’une transaction restent invisibles aux autres transactions. Durable (Durabilité) Le résultat de la transaction est persisté dans le système, même après l’arrêt de celui-ci. diapo 42

43 JPA, Spring & transactions
Les EJBs (Enterprise Java Bean), comme SPRING, apportent un support pour les transactions programmatiques et déclaratives La gestion des transactions des EJBs peut être couplée avec une implémentation de JTA (Java Transaction API) Spring n’est pas obligatoirement couplé à JTA diapo 43

44 Déclarative vs Programmatique
La gestion programmatique des transactions apporte un meilleur contrôle et une granularité plus fine et plus proche du code La gestion déclarative des transactions permet de garder la logique transactionnelle en dehors de la logique métier diapo 44

45 Transactions programmatiques
Correspond à la gestion des transactions de manière explicite par des instructions spécifiques dans le code métier traitant de la persistance Les transactions sont gérées explicitement par le développeur Exemple : EntityManagerFactory emf = Persistence.createEntityManagerFactory("tp"); EntityManager em = emf.createEntityManager(); em.getTransaction().begin(); em.persist(newInstance); em.getTransaction().commit(); em.close(); emf.close(); diapo 45

46 Transactions déclaratives
Spring comme JAVA EE permet d’utiliser la fonctionnalité des transactions déclaratives sur les POJOs Les transactions déclaratives : Réalisées grâce à une approche AOP Une transaction peut être vue comme un aspect qui intercepte une méthode (Around Advice) Le développeur spécifie par métadonnées (hier xml, aujourd’hui annotations) les caractéristiques du contexte transactionnel nécessaire à chaque méthode Exemple : @Transactional(propagation = Propagation.SUPPORTS, readOnly = true) public void processCode(final String pCode) { // instructions... } diapo 46

47 Les attributs transactionnels
Les transactions déclaratives sont configurées par des attributs transactionnels Ils définissent la politique et les comportements transactionnels des méthodes sur les propagations des transactions sur les niveaux d’isolation Et aussi : sur les optimisations Read-only sur les Timeouts diapo 47

48 Propagation des transactions (1/8)
Sept modes de propagation des transactions sont disponibles : MANDATORY NESTED NEVER NOT_SUPPORTED REQUIRED REQUIRES_NEW SUPPORTS diapo 48

49 Propagation des transactions (2/8)
PROPAGATION_MANDATORY Indique que la méthode doit s’exécuter dans une transaction, une exception est lancée si aucune transaction n’est définie Client Service DAO sans TX X Exception TX1 TX1 PROPAGATION_MANDATORY diapo 49

50 Propagation des transactions (3/8)
PROPAGATION_NESTED Indique que la méthode doit s’exécuter dans une transaction imbriquée si une transaction existante est en cours. La transaction imbriquée peut avoir un Commit ou un RollBack indépendant de la transaction existante. Si aucune transaction existante, se comporte comme PROPAGATION_REQUIRED Client Service DAO sans TX TX1 TX1 TX2 PROPAGATION_NESTED diapo 50

51 Propagation des transactions (4/8)
PROPAGATION_NEVER Indique que la méthode ne doit pas s’exécuter dans un contexte transactionnel, une exception est lancée si une transaction est en cours Client Service DAO sans TX sans TX X TX1 Exception PROPAGATION_NEVER diapo 51

52 Propagation des transactions (5/8)
PROPAGATION_NOT_SUPPORTED Indique que la méthode ne doit pas s’exécuter dans un contexte transactionnel. Si une transaction est en cours, celle ci est suspendue pour la durée d’exécution de la méthode Client Service DAO sans TX sans TX TX1 sans TX PROPAGATION_NOT_SUPPORTED diapo 52

53 Propagation des transactions (6/8)
PROPAGATION_REQUIRED Indique que la méthode doit s’exécuter dans un contexte transactionnel. Si une transaction est en cours, celle ci est utilisée, sinon une nouvelle transaction est initiée. Client Service DAO sans TX TX1 TX1 TX1 PROPAGATION_REQUIRED diapo 53

54 Propagation des transactions (7/8)
PROPAGATION_REQUIRES_NEW Indique que la méthode doit s’exécuter dans son propre contexte transactionnel. Si une transaction est en cours, une nouvelle transaction est initiée et la transaction existante est suspendue pour la durée d’exécution de la méthode Client Service DAO sans TX TX1 TX1 TX2 PROPAGATION_REQUIRES_NEW diapo 54

55 Propagation des transactions (8/8)
PROPAGATION_SUPPORTS Indique que la méthode n’exige pas un contexte transactionnel, mais peut s’exécuter dans une transaction si elle existe Client Service DAO sans TX sans TX TX1 TX1 PROPAGATION_SUPPORTS diapo 55

56 L’isolation des transactions (1/2)
Dans une application d’entreprise, les transactions s’exécutent de manière concurrente sur des données communes La concurrence des actions peut mener aux problèmes suivants : Dirty read Lectures pouvant se produire sur des données non encore "comitées" par une autre transaction. En cas de Rollback les données obtenues sont invalides Nonrepeatable read Se dit d’une transaction qui exécute une même requête plusieurs fois et récupère des données pouvant être différentes. La différence étant due à une autre transaction concurrente mettant ces données à jour diapo 56

57 L’isolation des transactions (2/2)
Phantom reads Se produit lorsqu’une une transaction lit plusieurs lignes, pendant qu’une autre transaction concurrente insert des lignes. Sur une nouvelle requête des nouvelles lignes peuvent apparaitre Dans une situation idéale, les transactions concurrentes sont complètement isolées les une des autres, pour éviter les problèmes cités précédemment Mais l’isolation parfaite affecte les performances Lock des lignes et parfois des tables! Le lock agressif oblige les transactions à s’attendre entre elles Dans certains cas, il peut être intéressant de relâcher les niveaux d’isolation. diapo 57

58 Exemples de niveaux d’isolation
ISOLATION_DEFAULT Utilise le niveau d’isolation par défaut de la base de données. ISOLATION_READ_UNCOMMITTED Permet de lire des données d’autres transactions concurrentes non encore "comitées". Peut engendrer des dirty reads, phantom reads et nonrepeatable reads. ISOLATION_ READ_COMMITTED Permet de lire des données d’autres transactions concurrentes uniquement "comitées". Évite les dirty reads mais pas les phantom reads et nonrepeatable reads. ISOLATION_REPEATABLE_READ Les lectures multiples sur un même champ produisent les mêmes résultats. Évite les dirty reads et les nonrepeatable reads mais pas les phantom reads. ISOLATION _SERIALIZABLE Niveau d’isolation ACID complet, évite les dirty reads, les nonrepeatable reads et les phantom reads. C’est le moins performant des niveaux d’isolation (mis en œuvre de locks plus important). Note : tous ces niveaux d’isolation ne sont pas supportés par toutes les sources de données. diapo 58

59 JAVA EE : JPA

60 JAVA EE : JPA JPA : Java Persistence API
À l’origine, JPA est une API visant à normaliser la gestion de la persistance dans une application JAVA EE face à une base relationnelle. JPA évolue pour intégrer les notions de persistances non-relationnelles (noSQL, etc.) et est de plus en plus couplé à la problématique de la validation (« Bean validation », JSR-303)

61 JAVA EE : JPA Historique : JPA 1.0 : JPA 2.0 : JPA 2.1 :
En 2006 via JSR-220 Périmètre initial JPA 2.0 : En 2009 via JSR-317 Améliorations notables : Criteria, Validation, Mapping extensions, … JPA 2.1 : En 2013 via JSR-338 Améliorations notables : Custom converters, entity graphs, stored procedures, …

62 JAVA EE : JPA JAVA JPA couvre essentiellement trois domaines
API de persistance : dans le package javax.persistence, nous y trouvons notamment des « entity manager », « transaction manager », etc. Cette API permet de cadrer le périmètre de gestion des requêtes, transactions, erreurs courantes, … via des interfaces (contrat). Principales notions : EntityManagerFactory : usine à EntityManager EntityManager : Facade d’accès à une session de persistance EntityTransaction : Interface de manipulation des transactions (commit, rollback, …)

63 JAVA EE : JPA La « session de persistance » est une notion centrale
JAVA JPA couvre essentiellement trois domaines API de persistance : Principales notions : Query : Interface de gestion d’une requête donnée (exécution, mise à jour, etc.) Criteria : Interface alternative de gestion d’une requête donnée FlushMode : Mode de réalisation des opérations en base de données La « session de persistance » est une notion centrale

64 JAVA EE : JPA JAVA JPA couvre essentiellement trois domaines JPQL
Langage de requêtage très proche de SQL : permet de manipuler directement les éléments objets (classes, attributs) avec les mots clef SELECT/FROM/WHERE/… Issu de HQL (langage spécifique HIBERNATE) Fournit des fonctions scalaires indépendantes des moteurs de base de données Métadonnées Objet/Relationnel Annotations permettant de « décorer » les entités persistances Permet de spécifier le mapping @ManyToMany

65 JAVA EE : JPA JAVA EE fournit le cadre (contrats) uniquement via son JDK. Les implémentations peuvent être fournies par d’autres éditeurs. Dans le cas de JPA, ces implémentations sont appelées « JPA PROVIDER » Exemples : Hibernate TopLink OpenJPA … 

66 JAVA EE : JPA Quel que soit l’implémentation retenue pour un projet, le JPA PROVIDER manipulera la notion de « session de persistance » Cette notion permet de connaître, à un instant donné de l’exécution d’un service défini en utilisant JPA, quels sont les objets qui seront affectés par la persistance Le JPA PROVIDER permet une abstraction de la source de données. C’est lui qui choisit notamment quand et comment son modèle mémoire est synchronisé avec la base de données

67 Session de persistance (1/3)
Un JPA Provider tel que Hibernate ne manipule pas directement les POJOs, mais des proxys obtenus par introspection. Les proxys contiennent les propriétés du POJO, ainsi que des informations utilisées par le JPA PROVIDER diapo 67 IBM Confidential

68 Session de persistance (2/3)
La session de persistance est un cache au niveau transactionnel. C'est elle qui contient les proxys. Son cycle de vie est géré par le container (Server JAVA EE typiquement), qui peut se charger aussi de créer la transaction et de la committer ou roll-backer. Un objet en session est persistant : objet qui a été récupéré ou sauvé en base. Un objet qui n'est pas en session est transient. Avant de créer une relation entre un objet persistant et un objet transient, il est nécessaire de rendre ce dernier persistant. diapo 68 IBM Confidential

69 Cycle de vie d’un entity JPA
Session de persistance (3/3) Cycle de vie d’un entity JPA diapo 69 IBM Confidential

70 GMIN30F Réutilisation / Composants
Intervenant : André Morassut