Principes d'architectures
UML
Concepts :
- Modélisation par périmètre limités
- Itération pour précision
- Méta-modèle : complétude du modèle
- Centrée architecture
- Piloté par les cas d'utilisation
UML
- > Vue logique : définition des éléments
- > Vue composants : implémentation des éléments logiques
- > Vue processus : multi-tâches
- > Vue déploiement : architecture de production
- > Cas d'utilisations
UML
4 + 1
(R)UP
Différences
- Concepts manipulés
- Granularité différentes
- Uses cases multi-application
- Approches asc. vs desc.
Convergences
- Modélisation
- Topologie des problèmes
- Méthodologiques
Principes de conception
Concept de Tiers ou acteurs
1 tiers
Pas très utile...
1 tiers
Un Tiers est une "couche" du système
(applicatif ou logiciel)
Il est toujours spécialisé
Client / Serveur
Client / serveur
Les règles :
- Relation maître (client) / esclave (serveur)
- Même protocole de communication (ex: HTTP)
- Serveur : centralise l'information
- Communication par le biais d'un middleware
Le middleware
Littéralement un intergiciel :
Ensemble de composants logiciels qui assurent l'interface de communication aux données
Le middleware
Souvenir ?
OSI
Le middleware
Trois grandes catégories de middleware :
- - Message oriented Middleware (MoM)
- - Objects Request Broker (ORB)
- - Transactional monitors
("Remote Procedure Calls")
Le middleware
Les niveaux d'abstractions et d'encapsulation de ces composants déterminent :
- - Le coût de réalisation
- - La robustesse
- - L'évolutivité
- - La facilité de mise en oeuvre
Architecture 2 tiers
Ce sont des architectures les plus courantes pour du client/serveur.
Il en existe 2 catégories :
- Type 1 : traitement assuré côté client
- Type 2 : traitement assuré côté serveur
Architecture 2 tiers
Architecture 2 tiers
- Un exemple par la pratique : simple-db
Architecture 2 tiers
Problème : couplage fort
Si je veux changer le middleware ?
Architecture 2 tiers
c'était pas "mieux avant" :
1, 2, 3 !
Architecture 3 tiers
Découpage à 3 niveaux, correspondant aux us des utilisateurs :
- Couche présentation
- Couche métier
- Couche accès aux données
Architecture 3 tiers
Architecture 3 tiers
Client / serveur ?
Architecture N tiers
Si la couche métier est divisée en plusieurs sous-couches, on généralise :
On parle alors de système N-tiers.
Architecture N tiers
- Un exemple par la pratique : Géoserveur
Architectures distribuées
- Plusieurs référentiels de données
- Plusieurs traitements
- Plusieurs présentations
Architectures distribuées
Architectures distribuées
Approche par composants :
- > Notion de "Réusabilité" généralisée au SI.
- > On distribue la donnée ET les traitements
- > L'unité de découpage se rapproche du métier
Architectures distribuées
Ex. de distribution de données :
- Component Object Model (COM):
- > Microsoft - 90s - pour ActiveX
- > Indépendant des languages (VB, C, .NET)
- > Encapsulation dans des objets pour transport
Architectures distribuées
Ex. de distribution de données :
- Simple Object Access Protocol v1.0 (SOAP):
- > Microsoft, IBM - 2000s - orienté HTTP
- > Indépendant des languages...
- > Description d'un modèle de données + messages pour transport
Architectures distribuées
Ex. de distribution de traitements :
- Common Object Request Broker Architecture (CORBA):
- > IBM, Sun, Oracle - 90s - orienté OO
- > Indépendant des languages (Java, C++, .NET...)
- > Composants distants accédé par ORB
Architectures distribuées
Ex. de distribution de traitements :
- Remote Method Invocation (RMI) :
- Sun - 2000s - Java Application servers
Architectures distribuées
RMI : exemple de code serveur
public class HelloImpl extends UnicastRemoteObject implements Hello {
public HelloImpl() {}
public String sayHello() { return "Hello world!"; }
public static void main(String args[]) {
HelloImpl obj = new HelloImpl();
Naming.rebind("HelloServer", obj);
}
}
Architectures distribuées
RMI : exemple de code client
public class HelloClient {
public static void main(String arg[]) {
String message = "blank";
Hello obj = (Hello) Naming.lookup( "rmi://server.address.org:1234/HelloServer");
System.out.prinntln( obj.sayHello() );
}
}
Problématiques de la distribution
Cohérence de l'information :
La valeur sur mon écran est elle réelle ?
Problématiques de la distribution
Concurrence des actions :
Un problème plus large que l'IT...
Problématiques de la distribution
Complexité :
la distribution au sens "large" du terme
Problématiques de la distribution
Exemple des SGBDR - ACID :
- Atomicité
- Cohérence
- Isolation
- Durabilité
Architectures distribuées
Pourquoi distribuer ?
Architectures distribuées
Distribution d'une application
==
mise à l'échelle (scalabilité)
Exemple de systèmes distribués
Stockage dans le réseau
Exemple de systèmes distribués
Calcul parallèle en "Map-Reduce"
- Google Reasearch - http://research.google.com/archive/mapreduce.html
- BIG DATA
Exemple de systèmes distribués
Application de recherche (Géocodeur, Google...)
- > Index de recherche sur la donnée
- > Structure de données type "tableau clef->valeur"
- > Répartir par première lettre sur 4 serveurs différents : partition ?
- > NoSQL vs. SGBDR
Architectures Orientées Services
Composants ?
- > Le composant est une vision "boîte" blanche.
- > L'utilisateur veut juste "utiliser"
Architectures Orientées Services
Composants ?
Architectures Orientées Services
Composants ?
Architectures Orientées Services
=> Approche par services :
- > Unité (noeud) du modèle de distribution
- > Indépendant de la plateforme
- > Interopérables
Architectures Orientées Services
Communication entre services
- > Offre d'opérations : interface.
Publiée sur le réseau.
- > Localisation sur le réseau :
Annuaire de services
- > Communication par messages :
Bus de services
Architectures Orientées Services
Intégration des services :
Architectures Orientées Services
Enterprise Application Integration
- > Chaque service a des Objets Métiers
- > L'EAI : plateforme centralisée et méta-service
- > L'EAI a des Objets Métiers Spécifiques
- > L'EAI connaît les services => pas d'annuaire ext.
- > Connecteur : conversion OM -> OMS
Architectures Orientées Services
Enterprise Application Integration
Architectures Orientées Services
Enterprise Application Integration
- Interfaces : réusabilité et intégration
- Coût initial élevé mais rentabilisation
- Centralisation : métier + mais SPOF !
Architectures Orientées Services
Enterprise Service Bus
- > Découverte dynamique des services
- > Middleware distribué
- > Pas d'OMS : un service du SI doit faire les mappings
- > Orienté MoM
Architectures Orientées Services
Enterprise Service Bus
Architectures Orientées Services
Enterprise Service Bus
- Pas de SPOFs
- Même avantages que l'EAI (hub, interfaces, etc.)
- Coût initial + complexité du messaging
Architectures Orientées Services
Intégration des services :Web
Webservices, micro-services
- > Chaque service est une application Web
- > Le Web comme bus de services : DNS + TCP/IP
- > Interopérable, peu ou pas de SPOFs, couplage faible
Architectures Orientées Services
REST - REpresentational State Transfert
- > Uniform Ressource Locator
- > HTTP : HEAD, GET, POST, PUT, DELETE... (+ caching)
- > Stateless
Architectures Orientées Services
REST - REpresentational State Transfert
Architectures Orientées Services
REST - REpresentational State Transfert
Architectures Micro-services
Le retour aux spaghettis ?
Architectures Micro-services
- > Scalabilité X et Y
- > Découverte et routage dynamique
- > Motifs de résilience ("Pattern breaking")
- > Tout monitorer et mesurer !
- > BDDs distribuées
- > Les 12 facteurs (pas d'Astérix non !)
Récapitulatif
- Client / Serveur
- 3 tiers
- N tiers
- Distribué
- Orienté services
- Micro-services
