Mise à niveau - e

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