Architectures à composants

Transcription

1 Interaction requête/réponse Architectures à composants!communication par requête/réponse client requête réponse serveur Gaël Thomas Université Pierre et Marie Curie Master Informatique M2 Spécialité SAR Infrastructure de communication!interaction : 1 requête + 1 réponse!!client : envoie une requête et attend la réponse!!serveur : attend une requête, exécute un traitement et renvoie la réponse!extension : appel de procédure distante!!rpc, RMI, Corba, EJB Master SAR - M2 MDOC - Introduction 2 Interaction par envoie de message!communication par envoie de message client!interaction : par envoie de message!!client : envoie un message Boîte à lettres dépose retire message!asynchrone : n attend pas la réception du message!synchrone : attend la réception et le traitement du message!!serveur : attend des messages et exécute un traitement!exemples : JMS, Scribe, WebSphere MQ.. message Infrastructure de communication autres serveurs serveur Master SAR - M2 MDOC - Introduction 3 Interaction requête/réponse!!envoie d une requête!!traitement de la requête!!envoie de la réponse Interaction requête/réponse Client Trouver le serveur Choix du numéro de requête Sérialisation! Appel de méthode à distance A la charge du développeur id requête + paramètres résultat Serveur Recherche de la méthode à appeler en fonction du numéro de la requête Désérialisation Architectures à Composants 4

2 Appel de procédures distantes Objectifs d un protocole d appel de méthode à distance (par exp: RPC)!!Diminuer le travail de développement des serveurs et des clients! Prise en charge de la sérialisation/désérialisation des arguments! Prise en charge de la conversion appel de méthode en protocole requête/réponse! Plus facile pour un serveur d offrir plusieurs services (méthodes)!!masquer une partie de la répartition! Le client appel une méthode locale! Cet appel est délégué au serveur! La méthode est exécutée par le serveur!!masquer l hétérogénéité entre clients et serveurs! Format pivot pour les données (xdr, sérialisation Java, CDR ) Comment : en générant le code de la délégation de l appel!!une souche d appel est généré pour le client!!un squelette du serveur est générée pour le serveur Architectures à Composants 5 Appel de procédures distantes A la charge du développeur du client!! Trouver le serveur!! Appeler la méthode A la charge du développeur du serveur!! Écrire la méthode Souche Client Trouver le serveur Choix du numéro de requête Sérialisation A la charge du développeur id requête + paramètres résultat Serveur Recherche de la méthode à appeler en fonction du numéro de la requête Désérialisation Architectures à Composants 6 généré Squelette Modèle des objets répartis Mais : appel de méthode inadéquat pour un langage objet!!programmation fondamentalement impérative! Le serveur offre des méthodes, mais il est construit avec des objets! Le client appelle des méthodes, mais il utilise des objets "!Non transparent pour les développeurs!!la notion d objet a été perdue "! Introduction du paradigme des objets répartis!!le serveur fournit un objet avec des méthodes et des champs!!le client utilise un objet représentant l objet serveur localement Notion de mandataire Notion (indépendante) de mandataire (proxy) :!!But : substituer un représentant à la place d un objet qui offre les mêmes fonctionnalités (méthodes)!!intérêt : adapter le code de l objet de manière transparente pour l utilisateur! Répartir le client et le serveur! Réutiliser des objets existants en leur ajoutant du code (avant/après) Principe : le client utilise un mandataire à la place de l objet d origine Transparence pour le client Architectures à Composants Architectures à Composants 8

3 Notion de mandataire Fonctionnement :!!Une classe X implante une interface I!!Le client utilise uniquement les méthodes de l interface I!!Le mandataire doit implanter les méthodes de I Schéma général de fonctionnement : implante Classe Mandataire de X Mandataire de X Interface I est une instance de Délègue l appel implante Classe X Objet X est une instance de Souche Souche Paradigme des objets répartis Paradigme des objets répartis Souche du client = mandataire spécialisé + mécanisme de construction Client Choix du numéro de requête Sérialisation A la charge du développeur généré id requête + paramètres résultat Serveur Recherche de la méthode à appeler en fonction du numéro de la requête Désérialisation Squelette Architectures à Composants Architectures à Composants 10 Construction d applications Construction d une application à objets répartis 1.! Définir l interface de l objet réparti dans un langage L0 (Décrit les fonctionnalités du serveur) 1.! Écrire le serveur dans un langage L1 a.! Développer un objet serveur implantant l interface b.! Écrire le serveur : allouer un objet serveur + exporter cet objet 2.! Écrire le client dans un langage L2 a.! Trouver le serveur b.! Construire un mandataire à partir du serveur Notion de service système Services systèmes dans les systèmes à objets répartis!!services réutilisables dans différents contextes applicatifs! Le contexte applicatif est souvent appelé code métier!!services externes par rapport au code métier! Le code du service n est pas embarqué dans le code métier! En général implantés sous la forme d objets répartis Exemple de services système :!!Service de résolution de noms!!service de persistance!!service de transaction!!service de sécurité (authentification, cryptage ) Architectures à Composants Architectures à Composants 12

4 Notion de service système Services systèmes implicites et explicites Notion de service système Services systèmes implicites et explicites Service système explicite!!appel au service réalisé par le code métier!!pour changer la manière d utiliser un service, il faut changer le code métier "!Accès au code source pour modifier les services systèmes "!Le code métier est peu réutilisable Exemple : le service de résolution de nom de RMI (RMIRegistry) Service système implicite (systèmes à composants)!!appel au service réalisé par le système à objets répartis!!une description des services systèmes externes est utilisée "!Pas d accès au code source pour modifier les services systèmes "!Le code métier est réutilisable Exemple : le service de transport de RMI (JRMP ou IIOP) Object Serveur Système à Objets répartis Service Système 1 Service Système 2 Descripteur des Services système Object Serveur Système à Objets répartis Service Système 1 Service Système Architectures à Composants Architectures à Composants 14 Les systèmes à composants Un composant est une entité logicielle qui!!est accessible via une interface immutable!!est composable avec d autres composants via leurs interfaces!!est exécutée dans un conteneur à composant Un conteneur à composants!!est l environnement d exécution de composant!!offre des mécanismes pour ajouter au composant des services systèmes implicites Il n y a pas de consensus sur la définition d un composant! Attention : le composant est parfois l instance, parfois la définition, parfois l unité de déploiement Les systèmes à composants Vue d ensemble d un conteneur Appel De méthode SGBD Cycle de vie Persistance Déploiement Sécurité Composant Nommage Conteneur à composant Sécurité Déploie Appel De méthode Architectures à Composants Architectures à Composants 16

5 Les systèmes à composants Les systèmes à composants Notion de packaging Construction d une unité de déploiement à partir!!du code du composant!!des fichiers de description des services systèmes utilisés Notion de déploiement Action de déployer!!installation de l unité!!enregistrement du composant auprès des services systèmes!!allocation du composant! Cycle de vie peut allouer à l installation, à la première requête, à chaque requête Enterprise Java Bean (JEE de Sun)!!Composants répartis en Java!!Basé sur RMI Corba Component Model (CCM de l OMG)!!Composants répartis multilangage!!basé sur Corba Web component - servlet/jsp (JEE de Sun)!!Composants centralisé en Java!!Basé sur HTTP/HTML, spécialisé dans la production de code HTML.NET ( COM+, Microsoft)!!Composants répartis avec la CLR (VM de C#,J# )!!S intègre naturellement à windows OSGi (OSGi Alliance)!!Composants centralisés en Java!!Spécialisé pour l embarqué, minimal, largement utilisé comme moteur à plugins Fractal (ObjectWeb)!!Architecture à composant multilangage (Julia = implémentation en Java)!!Spécialisé dans les description d architecture (ADL) Architectures à Composants Architectures à Composants 18 Conclusion Principaux apports des composants!!modularité et réutilisabilité!!masque la complexité des système répartis!!externalisation des services systèmes!!séparation des rôles dans le cycle de développement (développeur, pakageur ou assembleur, déployeur, administrateur )!!Particulièrement utile pour les systèmes à objets répartis Inconvénient :!!Grande redondance des informations! Dans le code et dans les fichiers de description des services systèmes! Compensé par les nombreux outils de génie logiciel existant!!le développeur métier, le déployeur ou le packageur ne se rendent pas forcément compte qu ils utilisent des mécanismes très coûteux Pré-requis du cours Organisation du Cours!!Langage Java - Java Standard Edition (JSE)!!Base de donnée SQL!!Langage HTML!!XML (SAX, DOM)!!Système : thread, sémaphore, entrée/sortie!!réseau : IP, TCP et UDP, socket, HTTP!!Systèmes répartis : appels de procédure distante (RMI), souche, squelette, mandataire Architectures à Composants Master SAR - M2 MDOC - Introduction 20

6 Organisation du Cours Plan du cours Composants Web!!Cours 1 : Introduction - Servlet!!Cours 2 : JSP Nommage et Persistance!!Cours 3 : jndi et jdbc Composants EJB!!Cours 4 et 5 : Enterprise Java Bean Autres Plateformes à Composants!!Cours 6 : OSGi!!Cours 7 : Web Services Plan des TME Composants Web!!TME 1 : servlet!!tme 2 : JSP Connexion aux SGBD!!TME 3 : JDBC dans une servlet Composants EJB!!TME 4 : Session Bean!!TME 5 : Entity Bean Projet = TME 1 à 7 + travail personnel = 40% de la note finale Master SAR - M2 MDOC - Introduction 21