Mise à niveau Rentrée 2016 1 Architectures distribuées actuelles ● Architecture orientée service (SOA) – Des composants logiciels qui communiquent de façon synchrone rarement asynchrone via des protocoles réseau dont la couche transport est HTTP. – Format d’échange XML et succédanés – Protocoles RESTful, SOAP et OSGI 2 Architectures distribuées actuelles ● Architecture orientée message (MOM) – Message Oriented Middleware – Des composants logiciels qui communiquent de façon asynchrone via des protocoles réseau dont la couche transport est HTTP. ● – Gestion de file d’attente Deux modes de fonctionnement ● Point à point (un producteur un consommateur) ● Abonnement (un producteur des consommateurs) 3 Architectures distribuées actuelles ● Architecture orientée micro-service – Micro-conteneurs avec des images – Empreinte mémoire plus légère que celle des machines virtuelles classiques – Réseau virtuel (services DHCP, DNS, etc) – Encapsulation d’un seul service par conteneur – Communication inter-service via des API avec les protocoles SOA et/ou MOM – Déploiement dans le Cloud 4 Micro-services : composants distribués Micro-conteneur Micro-conteneur API SOA/MOM Micro-service Micro-service API SOA/MOM HTTP HTTP HTTP Micro-conteneur API SOA/MOM Micro-service 5 Applications WEB avec IHM ● ● Classique – Dialogue avec plusieurs pages WEB – Peu ou pas de comportement côté client Dynamique – Dialogue avec une ou très peu de pages WEB – Enrichissement dynamique au cours du dialogue ● Échanges asynchrones de données (AJAX) – Formats XML ou JSON 6 Application WEB classique Requête 1 HTTP Réponse 1 HTTP Chargement page WEB Navigateur distant (envoi page HTML) Requête 2 HTTP Chargement page Serveur Réponse 2 HTTP (envoi page HTML) etc... 7 Application WEB dynamique Avec du Javascript ou un framework dérivé Requête 1 HTTP Navigateur Distant Comportements événementiels Réponse 1 HTTP Chargement page WEB (envoi page HTML) Requête 2 asynchrone HTTP modification page Serveur Réponse 2 HTTP (envoi de données) etc... 8 Méta-patron MVC et applications WEB ● MVC (Modèle, Vue, Contrôleur) – ● ● Trygve Reenskaug XEROX 1979 MVC2 – Modèle MVC adapté aux applications WEB – Un seul contrôleur – Correspondance (mapping) entre requêtes HTTP et les objets qui les traitent MVC et applications WEB dynamiques – Contrôleurs s’exécutant côté client (navigateur) 9 Vision en couche de l’architecture ● Couches liées aux données – ● Couches liées aux services – ● Service, métier Couches liées à la communication – ● Stockage de données, accès aux données Médiation Couches liées à la présentation – Présentation, adaptation 10 Architecture en couches Présentation Adaptation internet Service Métier Médiation Accès aux données Stockage données 11 Stockage des données ● Solutions de cache ● Solutions SGBD – SGBDOO – SGBDR – SGBDXML – SGBD NoSQL ● – Orientations document, graphe, dictionnaire Annuaire 12 Langages actuelles ● Orientation objet – JAVA (versions SE, EE, ME) – JAVASCRIPT – C# – Python – C++ – PHP 13 Langages actuelles ● ● Orientation fonctionnelle – SCALA – HASKELL Orientation fonctionnelle ajoutée aux langages à objets – JAVA – C# – PHP 14 Éditions JAVA ● JAVA SE – ● JAVA EE – ● Standard Edition Enterprise Edition JAVA ME – Micro Edition 15 Distributions JAVA ● Oracle (version officielle, OpenJDK) ● IBM (J9) ● REDHAT (IcedTea dérivé d’OpenJDK) ● Et bien d’autres... 16 Cycle de vie de JAVA ● ● JCP (Java Community Process) – Communauté d’intérêt pour une technologie – Membres experts – Production de spécifications (JSR) – Implémentation de référence JSR (Java Specification Requests) – Comparable aux RFC – Spécifications d’une technologie JAVA 17 Couches logicielles et technologies JAVA Présentation (JAVA SWING, JAVA-FX, JSF, HTML) Adaptation internet Service (POJO, EJB Session, SERVLET, JSF) Métier (POJO et EJB Entity) Médiation (JAX-WS, JAX-RS, OSGI, RMI, CORBA, etc) Accès aux données Stockage données (JPA, JDO, JDBC, API RESTful ou moteur de recherche, etc) 18 Serveurs d’application JAVA EE ● ● Serveur d’application WEB – Applications WEB avec IHM – Applications services WEB (SOA) Serveur d’application d’entreprise – Applications WEB et SOA – Applications EJB ● Distribution via RMI, CORBA, SOA, MOM, OSGI 19 Modeleurs UML Open Source ● ArgoUML – ● Développé avec JAVA SWING Modelio – Développé avec Eclipse 20 Environnement de développement ● IDE – Eclipse – NetBeans – IntelliJ 21 Environnement de déploiement ● Conteneurs DOCKER – Images hébergées sur DockerHub – Images construites 22 Conception et programmation OO ● ● Concepts premiers – Encapsulation – Spécialisation – Polymorphisme Concepts connexes – Objet – Classe – Identité – Abstraction 23 Conception et programmation OO ● ● Principes – SOLID – Interface segregation – DRY Lois, règles – ● DRY, Demeter, Design by contract Patrons de conception – Design Pattern (E. Gamma, R. Helm, R. Johnson, J. Vlisside) 24 Principes SOLID ● Single Responsability ● Open-Closed ● Liskov substitution ● Dependency Inversion 25 Single responsability ● Single responsability principe – Chaque entité (classe ou méthode) doit avoir une seule responsabilité. – Une classe doit avoir une seule raison d’exister et donc de changer. ● – Une responsabilité est une raison de changer Tous les services d’une classe doivent être étroitement alignés sur sa responsabilité. 26 Open closed ● Open closed principe – Une classe doit être à la fois ouverte à l'extension et fermée à la modification ● L'idée est qu'une fois qu'une classe a été approuvée via des revues de code, des tests unitaires et d'autres procédures de qualification, elle ne doit plus être modifiée mais seulement étendue. 27 Liskov substitution ● Liskov substitution principe – Si S est un sous-type de T, alors tout objet de type T peut être remplacé par un objet de type S sans altérer les propriétés désirables du programme concerné. ● ● Contravariance des arguments de méthode dans le sous-type. Covariance du type de retour dans le sous-type. 28 Dependency inversion ● Dependency inversion principe – Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions. – Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions. 29 Interface segregation ● Interface segregation principe (ISP) – Aucun client ne doit être obligé de dépendre de méthodes qu’il n’utilise pas. 30 Don’t repeat yourself ● DRY principe – Dans un système, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité 31