Introduction à l'architecture L'objectif premier d'un système d'information, quel qu'il soit, est de permettre à plusieurs utilisateurs d'accéder aux mêmes informations : pour cela, il faut donc regrouper les informations utilisées par l'entreprise ; en terme technique, cela se traduit par la centralisation des données au sein d'une base de données. Un peu d'histoire... Les Années 90 : Développement des réseaux. L'efficacité et le partage des systèmes d'informations doivent être optimum (concurrence économique, etc.). Le client-serveur se situe dans ce besoin de centralisation (information cohérente, non redondante et accessible) et de décentralisation (conserver la puissance et l'interface des microsordinateurs) Module Client-Serveur 3 Module Client-Serveur 6 Architectures : Client - Serveur Partie 4 : L'architecture n-tiers La couche de persistance - SGBD La couche métier - BPM La couche de présentation IHM Le Design pattern MVC Partie 5 : Les serveurs d'applications Définitions Les services offerts Partie 6 : Les web services L'intégration entre applications - EAI L'architecture orientée services - SOA Module Client-Serveur 2 Un peu d'histoire... Les Années 80 : Parallèlement développement des micros-ordinateurs avec leur puissance de calcul décentralisée et leurs interfaces graphiques conviviales. Le maintien des gros et moyens systèmes avec les micros-ordinateurs ont rendu les communications difficiles et ont créé des désordres dans les systèmes d'informations (redondance,etc.) Module Client-Serveur 5 Architectures : Client - Serveur Partie 1 : Présentation du modèle C/S Introduction à l'architecture Un peu d'histoire Les 4 principes de base du C/S Partie 2 : Le MIDDLEWARE Définition du Middleware Architecture du Middleware Les offres Partie 3 : La Répartition des BDD Définitions des bdd réparties Gestion des transactions Module Client-Serveur 1 Un peu d'histoire... Le client serveur est l'état actuel de l'évolution des architectures informatiques : Avant les Années 80 : Système Centralisé (ordinateur central avec des terminaux passifs de type texte). Les Années 80 : Développement du transactionnel et apparition des SGBD non-propriétaires (indépendants des constructeurs) - SGBD relationnel + SQL Module Client-Serveur 4

Le modèle Client-Serveur Client/Serveur : définition E C R A N CLIENT INTELLIGENCE INTELLIGENCE SERVEUR Est conforme au modèle client-serveur tout processus utilisant des services offerts par un autre processus, et communiquant avec lui à l aide de messages. Répartition judicieuse de la puissance de traitement entre le serveur et les différentes stations inter-connectées. Module Client-Serveur 9 Module Client-Serveur 12 Le modèle réseau local traditionnel E C R A N CLIENT INTELLIGENCE SERVEUR Serveur = Gère le réseau et stocke les bases de données sans les gérées. Client = Les stations effectuent tous les traitements Pourquoi le Client-Serveur? Prise en compte des évolutions technologiques Aspect ouvert et modulaire du Client-serveur. Mais. Réduire les coûts? L'architecture C/S coûte plus cher qu'une architecture centralisée : Postes de travail Réseau local Formation des développeurs (SGBD, Middleware, l'objet et les interfaces graphiques) Techniciens de maintenance réseau et PC Module Client-Serveur 8 Module Client-Serveur 11 Le modèle Multi-Utilisateur centralisé Pourquoi le Client-Serveur? E C R A N CLIENT INTELLIGENCE SERVEUR Contraintes sur l'entreprise Contraintes externes : compétitivité, exigence de la clientèle, produire mieux et plus vite, etc. Contraintes internes : Compression des budgets (limitation des ressources), manque de temps, absorption des technologies nouvelles Serveur = Ordinateur central qui effectue tous les traitements Client = Terminal sans puissance locale de traitement Module Client-Serveur 7 Mieux maîtriser le système d'information Une architecture ouverte C/S bâtie autour d'un moteur relationnel améliore cette maîtrise : présentation naturelle des données, meilleure productivité des développeurs avec le SQL Module Client-Serveur 10

Client/Serveur : définition CLIENT Processus qui demande l'exécution d'une opération par l'envoi d'une demande. SERVEUR Processus qui exécute la demande du client et qui transmet la réponse. REQUÊTE (Request) Message transmis par le client. REPONSE (Reply) Message transmis par le serveur. Module Client-Serveur 15 Les 4 principes de base du C/S Principe 4 : Permettre une séparation physique entre les actions d'un programme liées à l'interaction avec les utilisateurs et les autres actions. Gestion du dialogue par le client (interface) Gestion des données par le serveur Il s'agit d'un modèle de traitement coopératif. Module Client-Serveur 18 Client/Serveur : définition La présence d'un réseau n'est pas obligatoire dans la définition. On peut néanmoins considérer qu'une architecture C/S ne se construit qu'autour d'un réseau. Le terme SERVEUR fait référence à tout processus qui reçoit une demande de service (requête) venant d'un client via un réseau, traite cette demande et renvoie le résultat (réponse) au demandeur (le CLIENT). Les 4 principes de base du C/S Principe 3 : Utiliser au niveau de chaque station (cliente ou serveur) l'ensemble matériel/logiciel le plus adapté. Chaque machine est adaptée à des besoins précis (implique l'hétérogénéité des matériels). Optimisation de l'outil. Diversité des services offerts à l'utilisateur. Minimisation des coûts (le sophistiqué là où il est nécessaire. Module Client-Serveur 14 Module Client-Serveur 17 Client/Serveur : définition Les 4 principes de base du C/S E C R A N CLIENT REQUÊTE Approche Puriste CLIENT REQUÊTE Approche Pragmatique REPONSE SERVEUR REPONSE SERVEUR Principe 1 : Rendre l'architecture matérielle transparente vis à vis des développeurs et des utilisateurs finaux. Principe 2 : Rendre le niveau physique (et logique dans une moindre mesure) des bases de données transparent pour les développeurs et les utilisateurs. Module Client-Serveur 13 Module Client-Serveur 16

Le schéma du Gartner Group Le schéma du Gartner Group Client/Serveur de données Type 4 et 5 : Système popularisé par les SGBDR associés au SQL. Dans ce contexte le serveur gère les données, leur intégrité, la sécurité, etc. Il envoie seulement les données correspondant à la requête (opposition avec le serveur de fichiers). Le client traite ces données pour éventuellement, en retour, mettre à jour la base. Un partie de la base de données pour être sur le client -type 5 Module Client-Serveur 21 Module Client-Serveur 24 Découpage des applications client-serveur La répartition de ces 3 modules variera entre le client et le serveur et sera fonction : Des types d architecture retenus De la capacité des machines De la capacité du réseau Le Gartner Group a proposé les cas de figure suivants : Module Client-Serveur 20 Le schéma du Gartner Group Client/Serveur de Traitements Type 3 : Les données restent centralisées mais les traitements sont répartis entre le client et le serveur. Les applications Web rentrent dans cette catégorie avec : du côté client les scripts intégrés dans les pages HTML, les plug-in et/ou les composants. du côté serveur les divers programmes (accès aux bases de données, ) qui transmettent leurs résultats aux clients Module Client-Serveur 23 Découpage des applications client-serveur Le schéma du Gartner Group On reconnaît traditionnellement dans une application 3 modules : DONNEES TRAITEMENT PRESENTATION Client/Serveur de présentation Type 1 : Représente un système Serveur/terminal classique. Ce dernier présente un écran "calculé" par le serveur. Le type 1 n'est pas un système client/serveur. Type 2 : L'affichage effectué par le client se fait à la suite d'un échange de requêtes avec le serveur (type de fenêtre sa taille, son titre, etc.) X-Windows est le système représentatif du type 2 Module Client-Serveur 19 Module Client-Serveur 22

Ressources indépendantes Utilisation Les ressources ne sont pas dédiées à une utilisation particulière Partage des ressources facilité Définition du middleware L'ensemble des services logiciels construits au-dessus d'un protocole de transport afin de permettre l'échange de requêtes et des réponses associées entre client et serveur de manière transparente. Module Client-Serveur 27 Module Client-Serveur 30 Ressources indépendantes Hébergement Toute plate-forme matérielle peut devenir serveur Tout système d exploitation peut héberger un service Toutes configurations matérielles ou logicielles envisageables Localisation Les ressources peuvent être n importe où sur le réseau Architecture plus modulaire Administration plus complexe Les protocoles L'importance du réseau les placent au premier plan : Définissent le fonctionnement des réseaux Couvrent 3 types de services les services d application les services de transport les services de liaison Respectent le modèle OSI (interconnexion des systèmes ouverts) défini par l ISO Module Client-Serveur 26 Module Client-Serveur 29 Conclusion : partie 1 Modèle client/serveur se caractérise donc par : Des ressources indépendantes, L'importance du dialogue entre le client et le serveur, La place centrale du réseau. Importance du Dialogue Importance accrue des communications Le réseau devient «le centre de gravité du SI» Le réseau devient «la clé de voûte» du modèle client-serveur Complexification du dialogue Dialogue entre systèmes hétérogènes Dialogue à distance Nécessité de couches intermédiaires Pour gérer la complexité Pour rendre «transparent» le dialogue Module Client-Serveur 25 Module Client-Serveur 28

Définition du middleware Une triple transparence : Transparence aux réseaux. Transparence aux serveurs. Transparence aux langages. Les fonctions appelées doivent être aussi indépendantes que possible des langages. Application(s) MIDDLEWARE RESEAU Serveur(s) Module Client-Serveur 33 L'architecture type du Middleware L'IPC (Inter Processus Communication) est l'autre nom du middleware. L'IPC se compose : L'interface API (Application Programming Interface) - Interface de programmation au niveau applicatif. Interface entre un programme et le système qui propose un ensemble de fonctions standards pour accéder à un service local ou distant. Module Client-Serveur 36 Définition du middleware Une triple transparence : Transparence aux réseaux. Transparence aux serveurs. Tous le SGBD (avec leur SQL souvent différents) doivent être accessibles. Application(s) MIDDLEWARE RESEAU Serveur(s) Module Client-Serveur 32 Le Middleware : à quoi ça sert? Avantages Offre des services de «haut niveau» aux applications Rend portable les applications (avec certaines limites) Prend en charge les protocoles de conversion de caractères et d établissement de sessions entre clients et serveurs hétérogènes C est la «glue» qui rend possible le client-serveur C est la boîte à outils pour le développement des applications. Module Client-Serveur 35 Définition du middleware Une triple transparence : Transparence aux réseaux. Tous les types de réseaux doivent être supportés. Pourquoi le Middleware? La complexité du dialogue client/serveur est à l'origine du middleware. Complexité due à la présence : Des Systèmes hétérogènes Des Systèmes propriétaires Du dialogue à distance Application(s) Serveur(s) MIDDLEWARE RESEAU Module Client-Serveur 31 Module Client-Serveur 34

Client serveur et modèle OSI Le dialogue avec session Couche 7 - Couche Application 6 - Présentation Couche 5 - Session Couche 4 - Transport Couche 3 - Réseau Couche 2 - Liaison Couche 1 - Physique API FAP Par Ex : TCP Par Ex : IP Par Ex : CSMA/CD Par Ex : Paire torsadée Dans les dialogues avec session (ou avec connexion). Les échanges d informations sont subordonnés à l ouverture d une «session» par le client vers le serveur. IPC avec connexion : Protocole APPC de l architecture réseau SNA d IBM (Application Programm to Progamm Application) Protocole RDA, basé sur SQL défini par l ISO (Remote Data Access) Module Client-Serveur 39 Module Client-Serveur 42 L'architecture type du Middleware Le dialogue avec session Client Réseau Serveur Application Demande de connexion Requête Résultats Synchronisation Requête Résultats Synchronisation Déconnexion Prise en compte de demande et création d'un contexte Exécution des requêtes et gestion de la synchronisation Fin du contexte Module Client-Serveur 38 Module Client-Serveur 41 L'architecture type du Middleware Client serveur et modèle OSI L'interface FAP (Format And Protocols) - Protocoles de communication et format des données. Ce module assure : la synchronisation entre client et serveur, la reconnaissance du format des données échangées l'appel aux fonctions de transport du réseau. Module Client-Serveur 37 Module Client-Serveur 40

Le dialogue sans connexion : les RPC L offre Middleware» Client Application Appel de la procédure distante Réseau Requête Serveur Prise en compte de la demande Les offres multi-clients, multi-serveurs. Elles permettent aux clients d'accéder en toute transparence à plusieurs bases hétérogènes, situées éventuellement sur des serveurs différents. SEQUELINK : Techgnosis propose une API sur presque toutes les architectures clientes ou serveurs Réception du résultat poursuite de l'exécution Réponse Exécution de la procédure EDA/SQL : Information Builders propose d accéder à tout type de bases de données à partir de plates-formes hétérogènes Module Client-Serveur 45 Module Client-Serveur 48 Le dialogue avec session Les ordres SQL "COMMIT" ou "ROLL BACK" sont des exemples de points de synchronisation. A la suite d'une requête le : COMMIT confirmera la transaction, ROLL BACK l'annulera. Le serveur mettra réellement à jour la base de données qu'à la suite de ces ordres de synchronisation (avant cela les transactions s'appliquent dans le "contexte") L offre Middleware» Les offres Middleware sont variées : Offres propriétaires, Offres d'accès universel aux bases, Offres pour des accès multi-bases Les offres propriétaires aux SGBDR : ORACLE avec Sql*Net SYBASE avec Db-lib Module Client-Serveur 44 Module Client-Serveur 47 Le dialogue avec session Si le serveur accepte la connexion, il crée un contexte propre à chaque application cliente connectée. Le dialogue sans connexion : les RPC Les dialogues sans connexion avec appels de procédures distantes (RPC - Remote Procedure Call). Client et serveur s'échangent des requêtes, des réponses et des points de synchronisation. Le processus client invoque une procédure distante située sur le serveur. Le client a la responsabilité de conduire les phases successives de l'échange Le serveur a la responsabilité de garantir le contexte perçu par le client. Module Client-Serveur 43 La requête contient tous les éléments nécessaires au serveur (nom de la procédure, paramètres, identité du processus). Le message en retour contient toute la réponse. Module Client-Serveur 46

Le Standard ODBC Exemple de Sybase Application API : db-lib (lié au SE - db-lib pour OS2, pour Windows, etc) FAP : net-lib (lié au SE et au réseau) Réseau Application API : ODBC DataBase Driver FAP : net-lib (lié au SE et au réseau) Réseau Définitions On parlera ainsi de : Client de SGBD Répartie Application qui accède aux informations distribuées par les interfaces du SGBD Réparti. Serveur de SGBD Répartie SGBD gérant une base de données locale intégrée dans une base de données répartie D'une façon générale on parlera de SITE (client ou serveur) Module Client-Serveur 51 Module Client-Serveur 54 Le Standard ODBC ODBC (Open DataBase Connectectivity) est présenté en 1992 par Microsoft comme une interface universelle aux bases de données. Il ne s'agit pas d'un middleware à proprement parlé mais d'une API que l'on utilise en lieu et place des API des éditeurs de SGBDR Définitions Base de données répartie Ensemble de bases de données gérées par des sites différents et apparaissant à l'utilisateur comme une base unique. SGBD Réparti (ambiguïté de SGBDR) Système qui gère des collections de BD logiquement reliées, distribuées sur un réseau, en fournissant un mécanisme d'accès qui rend la répartition transparente aux utilisateurs Module Client-Serveur 50 Module Client-Serveur 53 L offre Middleware» Le Standard ODBC DRDA (Distributed Relational Database Architecture) d'ibm pour fédérer les bases IBM (DB2) et non IBM. IDAPI (Integrated Database Application Programming Interface) de Borland en collaboration avec Novell et IBM. Note : Évidemment l'accès multibases permet également l'accès monobase. Module Client-Serveur 49 Module Client-Serveur 52

Conception des BdD Réparties Conception ascendante Dans ce cas une base de données globale fédère des base de données locales afin de créer un ou plusieurs schémas globaux. (Le plus souvent il y refonte des schémas locaux) Base de données Globale La gestion des transactions Validation en deux phases Cette validation est basée sur un principe centralisé. L'exécution de la transaction est contrôlée par un site coordinateur, rôle joué par le client. Base de données locale 1 Base de données locale 2 Base de données locale 3 Les autres sites intéressés par la transaction sont des participants, rôle joué par les sites serveurs. Module Client-Serveur 57 Module Client-Serveur 60 Conception des BdD Réparties Il existe deux types de conception : Conception descendante Conception d'un schéma global Distribution des objets de ce schéma sur les différents sites pour obtenir des schéma locaux Base de données locale 1 Base de données Globale Base de données locale 2 Base de données locale 3 La gestion des transactions Propriétés des transactions ATOMICITE : Une transaction doit effectuer toutes ses mises à jour ou ne rien faire. COHERENCE : La transaction doit faire passer la base de données d'un état cohérent à un autre. ISOLATION : Les résultats d'une transaction ne doivent être visibles aux autres transactions qu'une fois la transaction validée. DURABILITE : Dés qu'une transaction valide ses modifications, le système doit garantir que ces modifications seront conservées en cas de panne. Module Client-Serveur 56 Module Client-Serveur 59 Pourquoi répartir les données? La performance d accès aux bases est limitée Par le nombre d accès disques nécessaires Par le volume de données transmis (débit du réseau) Par le nombre d accès concurrents Les performances peuvent se dégrader rapidement Au-delà de 30 postes clients Pour des consultations très fréquentes ou très importantes Dans le cadre d accès à distance (réseau étendu) Module Client-Serveur 55 Conception des BdD Réparties Les deux cas reviennent à partager, fragmenter la base de données globale entre plusieurs sites. Fragment Un fragment est une sous-table obtenue par sélection de lignes et de colonnes à partir d'une table globale, localisée sur un site unique. (peut correspondre également à la table entière) Module Client-Serveur 58

La gestion des transactions Commentaires : Les bases de données dupliquées Les inconvénients de la duplication Une non-réponse est assimilée à un refus (time out). Le serveur 2 annule la transaction car il ne l'a pas accepté (PREPARE mais pas de OK). Il faut assurer la convergence des copies. Il faut assurer la transparence aux utilisateurs qui ne doivent percevoir qu'une seule copie. Module Client-Serveur 63 Module Client-Serveur 66 La gestion des transactions Serveur 1 Client Coordinateur Serveur 2 PREPARE COMMIT OK ACK ACK OK Validation en deux étapes avec succès PREPARE COMMIT Les bases de données dupliquées Les bases de données dupliquées (ou répliquées) posent donc un problème particulier celui de la MISE A JOUR des bases pour obtenir cette convergence. Les avantages de la duplication Améliorer les performances : L'utilisation de la base la plus proche permet de limiter les transferts et de répartir la charge de travail. Augmenter la disponibilité : en cas de panne en particulier. Utiliser des serveurs plus petits et moins chers. Module Client-Serveur 62 Module Client-Serveur 65 La gestion des transactions Validation en deux phases Le client coordinateur demande aux autres sites (serveurs) s'ils sont prêts à mettre à jour leur base (ordre PREPARE). Si tous les participants répondent positivement (ordre OK) alors le site coordinateur envoie l'ordre COMMIT. Les serveurs envoient un acquittement au coordinateur (ordre ACK). Si l'un des participant répond négativement (ordre KO) alors le site coordinateur envoie l'ordre d'annulation (ordre ABORT). Les bases de données dupliquées La réplication entraîne la création de copies multiples d'une base de données sur plusieurs sites. La duplication peut concerner la base entière, une ou plusieurs tables ou des fragments. A la suite de transactions les copies peuvent diverger à un instant donné mais doivent converger vers un état identique et cohérent à terme. Module Client-Serveur 61 Module Client-Serveur 64

Les bases de données dupliquées Le synchronisme se combine au concept de symétrie qui permet de créer une hiérarchie dans les bases. Dans la réplication SYMETRIQE toutes les bases ont le même degré hiérarchique. Les bases de données dupliquées Exemple de mise à jour symétrique asynchrone Chaque département met régulièrement à jour les données des autres départements. Commercial Copie Maître Dans la réplication ASYMETRIQUE on distingue un site primaire chargé de centraliser les mises à jour. Financier Stocks Copie Maître Copie Maître Module Client-Serveur 69 Module Client-Serveur 72 Les bases de données dupliquées Mise à jour ASYNCHRONE On préfère le plus souvent le mode asynchrone (ou mode différé). Les mises à jour sont effectuées dès que possible ou à des instants fixés. Les bases de données dupliquées Exemple de mise à jour asymétrique synchrone (Diffusion d informations centralisées) Les informations appartiennent au site primaire, qui a le monopole des mises à jour Les données sont diffusées automatiquement vers les sites qui ont un droit de lecture seulement Copie PRIMAIRE Siège Social Cours des devises Copies SECONDAIRES Agence Agence Agence Module Client-Serveur 68 Module Client-Serveur 71 Les bases de données dupliquées Deux types de mise à jour : Mise à jour SYNCHRONE Toute transaction entraîne la mise à jour en temps réel de toutes les copies de la base. Les bases de données dupliquées Exemple de mise à jour asymétrique asynchrone (Consolidation d informations) Les données comptables tenues à jour dans les agences sont dupliquées en lecture seulement vers le siège pour consolidation. Avantage : convergence immédiate Inconvénient : Coûteux en ressources et complexité du système (gestion des reprises sur panne) Module Client-Serveur 67 Mise à jour en fin de journée par exemple Dépôts & Retraits Siège Social Agence Agence Agence Module Client-Serveur 70

SOA : Service Oriented Architecture Aujourd hui : plat de spaghettis «Une vision d un système destinée à traiter toute application comme un fournisseur de services» Tout traitement applicatif est vu comme un service potentiellement utilisable par un client Le client est découplé de l architecture technique du service qu il invoque Serveur Web Base commerciale Progiciel intégré SOA véhicule des Messages et non des objets Pour adapter les technologies hétérogènes, on fait appel à des Connecteurs/Adaptateurs Module Client-Serveur 75 Messagerie Application spécifique X Application spécifique Y Module Client-Serveur 78 Industrialisation d applications Analyse Use Case Modèles UML Développement Architecture/Design Test/Recette Bénéfices du SOA Meilleur retour sur investissement Mobilité du code Séparation des rôles Sécurité accrue Support de clients hétérogènes Plus de réutilisation et de maintenabilité Itération(s) L avenir nous emmène vers un seul et même outil pour remplir toutes ces tâches Module Client-Serveur 74 La clé : l agilité Module Client-Serveur 77 Les bases de données dupliquées Exemple de mise à jour symétrique synchrone Chaque site modifie la donnée PRIX puis diffuse immédiatement la modification. Modification du PRIX Produit Copie Maître Produit Temps réel Copie Maître Produit Copie Maître Module Client-Serveur 73 SOA Service Oriented Architecture «Une vision d un système destinée à traiter toute application comme un fournisseur de services» Tout traitement applicatif est vu comme un service potentiellement utilisable par un client Le client est découplé de l architecture technique du service qu il invoque SOA véhicule des Messages et non des objets Pour adapter les technologies hétérogènes, on fait appel à des Connecteurs/Adaptateurs Module Client-Serveur 76

Niveau d'urbanisation Démarche itérative et incrémentale Basée sur les invariants de l entreprise, cette vue est souvent une cible à atteindre en se basant sur la cartographie, état actuel 1 ère Etape n Etapes Module Client-Serveur 81 Cible Système urbanisé Architecture logicielle * Ilots autonomes Systèmes en région Système EDI fournisseur (*)gestionnaire de flux Hub pour les données Serveurs WEB isolé pour des contraintes de sécurité Architecture technique Serveur Datawharehouse Grand public Serveur client Temps Design Quick & Dirty vs Code évolutif utilise MonFournisseurTrace ; MaClasseCliente { public mamethode1() { MonFournisseur.Trace("ceci") public mamethode2() { MonFournisseur.Trace("cela") public mamethoden() { MonFournisseur.Trace() utilise MonAbstractionTrace MaClasseCliente { public mamethode1() { MonAbstraction.Trace("ceci") public mamethode2() { MonAbstraction.Trace("cela") public mamethoden() { MonAbstration.Trace() Changer de fournisseur de trace revient à modifier exponentiellement le code client : x méthodes * y lignes Module Client-Serveur 84 Urbanisation et cartographie «L urbanisation a pour objectif de faire évoluer le Système d'information et sa composante informatique au même rythme que la stratégie et l'organisation des métiers de l'entreprise» La cartographie permet de déceler les redondances des flux, les doubles saisies, les incohérences applicatives Pourquoi ne pas imaginer plus tard des Design Patterns pour SOA/EAI? (finalement, on monte toujours l abstraction d un niveau) Le Design Un bon Design est toujours la garantie de l évolutivité d une application Trop de Design tue le design Évitez les architectures anti-pattern Faire du Design c est un peu comme faire une recette de cuisine, il faut choisir les bons ingrédients Un bon design est souvent associé à une bonne architecture technique (séparation des couches, n- tiers, etc ) Module Client-Serveur 80 Module Client-Serveur 83 Demain : Architecture urbanisée Client Serveur Web Messagerie Application spécifique X Workflow Processus métier Middleware Asynchrone Base commerciale Progiciel intégré Module Client-Serveur 79 C on n ec t e u r Beaucoup d inconnus Quelle granularité adopter? Comment intégrer un SI boîte noire? lorsqu un seul progiciel prend en charge l ensemble des processus métier (SAP, etc ) Comment urbaniser un SI sans risquer de bloquer son fonctionnement? Où se situe les interfaces graphiques clientes? Quelle méthodologie pour l urbanisation et la cartographie? Langage de modélisation? Le risque n est-il pas de déplacer la complexité du SI au niveau de l EAI? Module Client-Serveur 82

Rappel sur les besoins Tout système d'information nécessite la réalisation de trois groupes de fonctions: La couche de présentation Présentation : le stockage des données, la logique applicative et la présentation des données. La présentation est la partie la plus immédiatement visible pour l'utilisateur. Elle a donc une importance primordiale pour rendre attrayante l'utilisation de l'informatique. Son évolution a été très importante depuis les débuts de l'informatique et des systèmes d information. Module Client-Serveur 87 Module Client-Serveur 90 Architectures multi-couches La couche métier Logique applicative : Historique Anti-patterns d'architecture Patterns d'architecture La logique applicative est la réalisation informatique du mode de fonctionnement de l'entreprise. Cette logique constitue les traitements nécessaires sur l'information afin de la rendre exploitable par chaque utilisateur. Module Client-Serveur 86 Module Client-Serveur 89 Design Quick & Dirty vs Code évolutif utilise MonFournisseurTrace ; MaClasseCliente { public mamethode1() { MonFournisseur.Trace("ceci") public mamethode2() { MonFournisseur.Trace("cela") public mamethoden() { MonFournisseur.Trace() utilise MonAbstractionTrace MaClasseCliente { public mamethode1() { MonAbstraction.Trace("ceci") public mamethode2() { MonAbstraction.Trace("cela") public mamethoden() { MonAbstration.Trace() Changer de fournisseur de trace revient à modifier exponentiellement le code client : x méthodes * y lignes Module Client-Serveur 85 La couche de persistance Stockage et accès aux données : Le système de stockage des données a pour but de conserver une quantité plus ou moins importantes de données de façon structurée. On peut l'utiliser pour cette partie des systèmes (très variés) qui peuvent être : des systèmes de fichiers, des bases de données relationnelles, etc... Module Client-Serveur 88

Architecture à deux niveaux Architecture à trois niveaux Aussi appelée architecture 2-tier, «tier» signifiant rangée en anglais, Elle caractérise les systèmes clients/serveurs pour lesquels : le client demande une ressource (GET), et le serveur la lui fournit directement (OUT), en utilisant ses propres ressources. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir une partie du service. Module Client-Serveur 93 Dans l'architecture à 3 niveaux, appelée architecture 3-tiers, il existe un niveau intermédiaire, c'est une architecture partagée entre : Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface utilisateur (généralement un navigateur web); Le serveur d'application (ou middleware), chargé de fournir les ressources mais faisant appel à un autre serveur; Le serveur de données (ou database server) qui va fournir au serveur d'application les données dont il a besoin. Module Client-Serveur 96 1. Architecture 2-tiers 2. Architecture 3-tiers GET GET GET Ressources OUT OUT OUT Ressources Module Client-Serveur 92 Module Client-Serveur 95 Architectures n-tiers L'architecture à deux niveaux est donc une architecture client/serveur dans laquelle : Constituent une étape importante dans l'évolution des systèmes d'informations le serveur est polyvalent, c'est-à-dire qu'il est capable de fournir directement l'ensemble des ressources demandées par le client. Module Client-Serveur 91 Module Client-Serveur 94

Architecture n-tiers : Client léger : L'origine du terme provient de la limitation du langage HTML, qui ne permet de faire des interfaces relativement pauvres en interactivité, si ce n'est pas le biais du langage javascript, DHTML, XHTML, etc.. Module Client-Serveur 99 Module Client-Serveur 102 Architecture multi-niveaux Client léger : Constat : dans l'architecture à 3 niveaux, chaque serveur (niveaux 2 et 3) effectue une tâche (un service) spécialisée : Un serveur peut donc utiliser les services d'un ou plusieurs autres serveurs afin de fournir son propre service. Par conséquent, l'architecture à trois niveaux est potentiellement une architecture à N niveaux... Le terme «client léger», parfois «client pauvre», en anglais «thin client» par opposition au client lourd, désigne une application accessible via une interface web (en HTML) consultable à l'aide d'un navigateur web, où la totalité de la logique métier est traitée du côté du serveur. Pour ces raisons, le navigateur est parfois appelé client universel. Module Client-Serveur 98 Module Client-Serveur 101 Architecture à trois niveaux Dans l'architecture à trois niveaux, les applications au niveau serveur sont délocalisées, c'est-à-dire, que chaque serveur est spécialisé dans une tâche : serveur web, serveur de base de données. Une plus grande flexibilité/souplesse ; Une sécurité accrue car elle peut être définie à chaque niveau ; De meilleures performances, étant donné le partage des tâches entre les différents serveurs. Module Client-Serveur 97 Client lourd : Le terme «client lourd», en anglais «fat client» ou «heavy client» par opposition au client léger, désigne une application cliente graphique exécutée sur le système d'exploitation de l'utilisateur. Un client lourd possède généralement des capacités de traitement évoluées et peut posséder une interface graphique sophistiquée. Néanmoins, ceci demande un effort de développement et tend à mêler la logique de présentation (l'interface graphique) avec la logique applicative (les traitements). Module Client-Serveur 100

Quels technologies? Responsabilités logiques XML comme format de données standard, J2EE,.Net, PHP comme environnement de dev, Linux/Windows comme système d'exploitation Apache comme serveur web, MySQL, Oracle comme serveur de base de données, HTML, JavaScript, Ajax comme langage de scripts, SOAP, CORBA, DCOM, comme langage de communication, Multi-threading comme technique de répartition de charge entre serveurs. Visualisation Présentation Services Concepts métier Intégration Accès aux données??? Stockage Module Client-Serveur 105 Module Client-Serveur 108 Client riche : Victimes de la mode Il existe des standards permettant de définir une application riche : XAML (extensible Application Markup Language), prononcez «zammel», un standard XML proposé par Microsoft ; XUL, prononcez «zoul», un standard XML proposé par la fondation Mozilla ; Il a existé plusieurs courants architecturaux Client passif - Serveur omniscient Client sexy - Serveur de données, Objets distribués Architectures client léger revisitées (pour le Web) Ces "modes architecturales" Sont structurantes pour les systèmes d'information La transition d'une mode à l'autre est complexe Flex, un standard XML proposé par la société Macromedia Module Client-Serveur 104 Module Client-Serveur 107 Client riche : Un «client riche» est un compromis entre le client léger et le client lourd. L'objectif du client riche est donc de : proposer une interface graphique, décrite avec une grammaire de description basée sur la syntaxe XML, Quels enjeux? Avec des exigences fortes : Robustesse Sécurité Évolutivité obtenir des fonctionnalités similaires à celles d'un client lourd (glisser déposer, onglets, multi fenêtrage, menus déroulants, ). Module Client-Serveur 103 Module Client-Serveur 106

Anti-pattern d architecture Architecture d objets distribués Distribuer les objets du domaine est à proscrire Ils exposeraient des méthodes de granularité trop fine Il ne faut distribuer que des services Synchrones Asynchrones Module Client-Serveur 111 Le risque du non-objet Adopter une approche procédurale Nuit à l évolutivité Tout doit être prévu au moment de la compilation du programme Chaque modification a un impact sur le code Ne facilite pas le lien entre les rôles Techniques (concepteurs/développeurs, architectes techniques) Et fonctionnels (analystes, architectes fonctionnels) L objet est donc incontournable sur de gros projets à spécifications évolutives Module Client-Serveur 114 Architectures multi-niveaux Conception Orientée Objet Le contenu d une couche de responsabilité doit être Orienté Objet Héritage et polymorphisme permettent extensibilité et généralisation Atteindre le même niveau de généricité et de robustesse avec un langage non Objet est très difficile Module Client-Serveur 110 Module Client-Serveur 113 Client Serveur, première Anti-pattern d architecture Les architectures orientées services distribués Ne doivent pas nuire aux performances Doivent renvoyer aux couches de présentation des agrégats de données d une finesse adéquate : des DTO (Data Transfer Object) Faut-il créer un DTO par objet du domaine? Bonnes performances Faible maintenabilité (sauf à les générer) Module Client-Serveur 109 Module Client-Serveur 112

Les web services Application 1 Application 2 Service 1 Message à traiter Message traité Contrat Service Implémentation SOA tactique ou stratégie La mise en place de services web est du domaine tactique, elle est opportuniste. Il existe très peu de sociétés qui ont une vision stratégique SOA. Think big, start small! Service 2 Module Client-Serveur 117 Module Client-Serveur 120 Quelques patterns d'architecture Couplage faible Abstract factory Commande Adaptation, enrichissement Decorateur Persistance Lazy loading «Tissage» de services techniques Proxy, intercepteur Parsing Visiteur (attention au piège du polymorphisme) SOA ou Web Services? Une bonne SOA est une histoire de conception pas de technologie. Il est très facile de construire des services web médiocres. Beaucoup le feront. La technologie Services Web ne fait pas votre architecture. Un bon service doit être «abstrait» : il n est pas lié à une implémentation. Les services web forment un très bon ensemble de spécifications pour construire une SOA : indépendance, sécurité, transaction, orchestration, Module Client-Serveur 116 Module Client-Serveur 119 Design Patterns : enjeux Apprendre les Design Patterns et les appliquer, c est : Apprendre à «bien» concevoir Objet Acquérir des réflexes, gagner du temps Mieux cerner un problème (simplification) Limiter le couplage, augmenter l évolutivité Élever le niveau de langage, faciliter les échanges Les web services SOA n est pas un concept neuf. Les sites centraux utilisaient déjà la notion de services. Module Client-Serveur 115 Module Client-Serveur 118

SOA : Modèle à 5 couches Inconvénients Client Application Objets métiers Entreprise Mapping Physique Interfaces : WEB, C/S, PDA ou encore XML, Le fonctionnel de mes applications Mon métier Lié à ma structure de données SGBD, CICS, LDAP, Surcoût en performances : Certains IDE et technologies permettent de prendre des raccourcis! (triggers, procédures stockées, base de données mémoire ) étudier comment les intégrer dans le multicouche, trancher entre maintenabilité et performances. Module Client-Serveur 123 Module Client-Serveur 126 SOA Fonctionnalités Indépendance vis à vis de la plate-forme Indépendance vis à vis du langage de programmation Découverte dynamique des services Fiabilité Sécurité Gestion des transactions Orchestration des services Possibilité d enregistrer les séquences de messages Possibilité de produire des rapports d audit Routage intelligent des messages Tolérance aux pannes, montée en charge Module Client-Serveur 122 Inconvénients Surcoût de conception : Chaque couche est indépendante, et demande donc une documentation qui définit ses interfaces avec les autres couches Surcoût de réalisation : Pour une fonctionnalité, il faut impacter plusieurs couches, et coder plusieurs éléments (éventuellement par des personnes différentes) Module Client-Serveur 125 Une architecture SOA? SOA : Modèle à 5 couches Garantit des développements industrialisables et des applications maintenables, évolutives,et réutilisables Permet de spécialiser les développeurs Assure le dialogue entre le concepteur et le développeur Détache le fonctionnel du technique Les technologies sont au service de l architecture et pas l inverse. Module Client-Serveur 121 Module Client-Serveur 124

L infrastructure des Services Web Evolution du Web SOAP WSDL UDDI Implémentations Les APIs Java (JAXP, JAX-RPC, JAXM, JAXR, JAXB) Implémentation avec JAX-RPC Apache SOAP, Apache Axis Conclusion HTML HTML HTML, XML HTML, XML Generation 1 Static HTML Generation 2 Web Applications Generation 3 Web Services Module Client-Serveur 129 Module Client-Serveur 132 L infrastructure des Services Web L infrastructure des Services Web SOAP 1.1 Note W3C Simple Object Access Protocol Transporte WSDL 1.0 Note W3C Web Services Description Language Décrit le contrat UDDI 2.0 Microsoft,IBM, HP Universal Description Discovery and Integration Stocke les descriptions de contrat Caractéristiques: Réutilisable Indépendamment de la plate-forme (UNIX, Windows, ) l implémentation (VB, C#, Java, ) l architecture sous-jacente (.NET, J2EE, Axis ) XML 1.0 Recommendation W3C - 1998 extensible Markup Language Module Client-Serveur 128 Module Client-Serveur 131 Implémentations Net, J2EE, Corba, RMI, Propriétaire Client Client Client Client Application Application Composants entreprises Mapping Mapping Connecteurs L infrastructure des Services Web Un service Web est une «unité logique applicative» accessible en utilisant les protocoles standard d Internet Une «librairie» fournissant des données et des services à d autres applications. Un objet métier qui peut être déployé et combiné sur Internet avec une faible dépendance vis-à-vis des technologies et des protocoles. Combine les meilleurs aspects du développement à base de composants et du Web. Données physiques Données physiques Applications existantes Module Client-Serveur 127 Module Client-Serveur 130

Pourquoi faire? Et plus concrètement? Les services Web permettent d interconnecter : Différentes entreprises Différents matériels Différentes applications Différents clients Pas uniquement des butineurs Distribuer et intégrer des logiques métiers Vers le Web sémantique Pas uniquement le Web purement interactif Les services Web sont faiblement couplés Module Client-Serveur 135 Une nouvelle technologie des objets distribués? Invocation distante des services Web : SOAP (~IIOP) Description des services Web : WSDL (~IDL) Enregistrement et découverte de services Web : UDDI (~NameService) Basés sur des standards XML Standards du W3C : XML, SOAP, WSDL Standards industriels : UDDI, ebxml Propriétaires : DISCO, WSDD, WSFL, ASMX, Implémentations actuelles : Microsoft.Net Sun JavaONE : J2EE + Web services (WSDP = JAXP,JAX- RPC,JAXM ) Apache SOAP / Axis, IBM WSTK Oracle, Bea, Iona, Enhydra Module Client-Serveur 138 Le Web 3ème génération Aujourd hui Un site Web fournie des pages HTML - pas de structure - impossible à fusionner avec d autres pages Web service site Web Web service site Web Web service site Demain Un site Web est un composant fournissant des services en XML - structure / sémantique - fusion possible The Firewall File DB Web Server In-house systems Quels objectifs? Remplacer les protocoles actuels (RPC,DCOM,RMI) par une approche entièrement ouverte et interopérable, basée sur la généralisation des serveurs Web avec scripts CGI. Faire interagir des composants hétérogènes, distants, et indépendants avec un protocole standard (SOAP). Dédiés aux applications B2B (Business to Business), EAI (Enterprise Application Integration), P2P (Peer to Peer). Browser Module Client-Serveur 134 Dynamic Pages Module Client-Serveur 137 Exemple Modèle client / serveur XML XML Service Web XML Service Web Web Site XML XML XML Service Web Service Web Client HTML XML Client Module Client-Serveur 133 Module Client-Serveur 136

1: Déploiement du WS 4: Invocation du WS Module Client-Serveur 141 Module Client-Serveur 144 Cycle de vie complet 3: Découverte du WS Etape 1 : Déploiement du service Web Dépendant de la plate-forme (Apache : WSDD) Etape 2 : Enregistrement du service Web WSDL : description du service Référentiels : DISCO (local), UDDI (global) Etape 3 : Découverte du service Web Etape 4 : Invocation du service Web par le client Module Client-Serveur 140 Module Client-Serveur 143 Cycle de vie d utilisation 2 : J ai trouvé! Voici le serveur hébergeant ce service web Annuaire UDDI 2: Enregistrement du WS 1 : Je recherche un service WEB Client 3 : Quel est le format d appel du service que tu proposes? 4 : Voici mon contrat (WSDL) XML XML XML XML 5 : J ai compris comment invoquer ton service et je t envoie un document XML représentant ma requête Contrat Contrat SOAP SOAP Serveur 6 : J ai exécuté ta requête et je te retourne le résultat XML Module Client-Serveur XML 139 Module Client-Serveur 142

Simple Object Access Protocol SOAP a été construit pour pouvoir être aisément porté sur toutes les plates-formes et les technologies Vous pouvez écrire votre 1er appel SOAP en moins d une heure!! Il vous a fallu combien de temps en CORBA, RMI, DCOM? Module Client-Serveur 147 Pourquoi utiliser HTTP? HTTP (HyperText Transfer Protocol) est devenu de facto le protocole de communication de l Internet HTTP est disponible sur toutes les plates-formes très rapidement HTTP est un protocole simple, qui ne requière que peu de support pour fonctionner correctement HTTP est un protocole sans connexion Peu de paquets sont nécessaires pour échanger des informations HTTP offre un niveau de sécurité simple et effectif HTTP est le seul protocole utilisable à travers des Module pare-feu Client-Serveur 150 Simple Object Access Protocol SOAP codifie simplement une pratique existante Utilisation conjointe de XML et HTTP SOAP est un protocole minimal pour appeler des méthodes sur des serveurs, services, composants, objets Ne pas imposer une API ou un runtime Ne pas imposer l utilisation d un ORB (CORBA, DCOM, ) ou d un serveur web particulier (Apache, IIS, ) Ne pas imposer un modèle de programmation Plusieurs modèles peuvent être utilisés conjointement Et ne pas réinventer une nouvelle technologie Module Client-Serveur 146 En résumé SOAP = HTTP + XML Station Browser client universel Application partie -cliente Client HTTP requêtes SOAP (XML) Réponses SOAP (XML) Serveur HTTP Serveur ASP ISAPI Module Client-Serveur 149 CGI Servlets Application partie-serveur Architecture globale Les 3 aspects d un appel SOAP Module Client-Serveur 145 SOAP peut être vu comme un autre RPC Objets Les requêtes contiennent les paramètres IN et INOUT Les réponses contiennent les paramètres INOUT et OUT SOAP peut être vu comme un protocole d échange de message La requête contient un seul message (appel sérialisé d une méthode sur un objet) La réponse contient un seul message (retour sérialisé d un appel de méthode sur un objet) SOAP peut être vu comme un format d échange de documents La requête contient un document XML Le serveur retourne une version transformée Ces vues ne sont pas imposées par le protocole Module Client-Serveur 148

Pourquoi utiliser XML? Eléments de SOAP XML permet une extensibilité aisée par l utilisation d espaces de nommage (namespaces et URIs) XML permet d ajouter du typage et de la structure à des informations L information peut être sauvegardée n importe où sur le Net Les données fournies par de multiples sources peuvent être agrégées en une seule unité Chaque partie à sa propre structure XML Chaque partie peut définir des types spécifiques Module Client-Serveur 153 L enveloppe (enveloppe) Définit la structure du message Les règles d encodage (encoding rules) Définit le mécanisme de sérialisation permettant de construire le message pour chacun des types de données pouvant être échangés Fonctionnement en modèle client / serveur (RPC representation) Définit comment sont représentés les appels de procédure et les réponses Proposer une mise en œuvre sur HTTP (HTTP Extension Framework) RFC 2774 Définir l échange de message SOAP sur HTTP Module Client-Serveur 156 Pourquoi utiliser XML? Exemple de réponse utilisant HTTP Utilise du texte (peut être lu et écrit directement) ATTENTION : le texte est globalement peut lisible et vite complexe pour un humain Construire correctement du texte XML est simple Pas d éléments qui se recouvrent (uniquement des imbrications) Les attributs sont clairement identifiés (dir= in ) Les caractères <, >, & doivent être précédés d un caractère d échappement (ou il faut utiliser CDATA) XML est aujourd hui adopté par tous les acteurs de l Internet : plates-formes, éditeurs, HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env= "http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Module Client-Serveur 152 Module Client-Serveur 155 Fonctionnement d HTTP Exemple de requête utilisant HTTP HTTP utilise un protocole requête/réponse basé sur du texte La première ligne de la requête contient 3 éléments Verbe : POST/GET/HEAD URI : /default.htm Protocole : HTTP/1.0 - HTTP/1.1 La première ligne de la réponse contient 2 éléments État : 200, 402 Phrase : OK, Unauthorized Les lignes suivantes contiennent un nombre arbitraire d entête Le contenu suit une ligne d entête vide Utilisé essentiellement pour les réponses et pour les requêtes POST Module Client-Serveur 151 Demande de cotation à un serveur POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:soap-env= "http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Module Client-Serveur 154

SOAP Message Structure SOAP Message HTTP Headers SOAP Envelope SOAP Header Headers SOAP Body Method Call & Data Le message SOAP Complet Entête standard HTTP et entête SOAP HTTP Enveloppe Entête Entête individuelle Corps qui contient les appels de méthodes SOAP Appel de méthode et description en XML de données Module Client-Serveur 158 SOAP Message Structure SOAP Message HTTP Headers SOAP Envelope SOAP Header Headers SOAP Body Method Call & Data Le message SOAP Complet Entête standard HTTP et entête SOAP HTTP Enveloppe Entête Entête individuelle Corps qui contient les appels de méthodes SOAP Appel de méthode et description en XML de données Module Client-Serveur 157