Construction D ApplicationsiR Parties Et Parall Les
Master M2R “Systèmes et Logiciel”Motivations! La répartition est un état de fait pour un nombreimportant d!applicationsConstruction d!Applications Réparties etParallèles" Développement des réseaux (Internet, réseaux sans fil)" Intégration d!applications existantes initialement séparées" Pénétration de l!informatique dans des domaines nouveauxd!application# Intégration d!objets du monde réel (informatique omniprésente(ubiquitous computing))# Intégration entre informatique et télécommunicationsIntroductionSacha Krakowiak! Le parallélisme est la réponse aux besoins croissantsUniversité Joseph FourierProjet Sardes (INRIA et IMAG-LSR)des applications" Puissance de traitement" Gestion de grandes masses de données" Intégration et mise en commun de ressourceshttp://sardes.inrialpes.fr/ krakowia 2005-2006, S. KrakowiakObjectifs du coursContenu du coursNotions de base des systèmes répartisProblèmes de la construction d!applications réparties! Présentation des principes de la construction d!applicationsréparties et parallèlesModèles d!organisation d!applications répartiesPatrons et canevas de base pour le modèle client-serveur" Modèles de programmation" Architectures logicielles des applications et de l!intergiciel (middleware)Systèmes asynchrones, coordination, programmation par événementsExemples de systèmes asynchrones! Trois aspects" Les principaux problèmes abordés par la recherche" Les patrons de conception (design patterns) et canevas logiciels (softwareframeworks) utilisés dans la construction d!applications" Des exemples illustratifs de l!état de l'art (recherche, industrie)Systèmes à composants. Intergiciels à composants. Patrons et canevas debase pour les composants. Exemples de systèmes à composantsSécurité des applications réparties : besoins, techniques, exemples.! Autres cours utilesTechniques d!adaptation. Applications : infrastructures mobiles, gestion de laqualité de service, reconfigurationAdministration d!applications. Concepts et outils. Déploiement, configuration,gestion de ressources, disponibilité. Exemples" Couvrent des aspects fondamentaux" SR - Algorithmique et techniques de base des systèmes répartis (les annéespaires, donc en 2006-2007)" CP - Algorithmique et techniques de base du calcul parallèle (le présentcours, ouvert les années impaires) 2005-2006, S. Krakowiak2Systèmes et applications parallèles sur grappes et grilles3 2005-2006, S. Krakowiak4
Plan de la séance 1Caractéristiques des systèmes répartis (1)! Définition d!un système réparti! Introduction aux applications réparties" Ensemble composé d!éléments reliés par un système decommunication ; les éléments ont des fonctions de traitement(processeurs), de stockage (mémoire), de relation avec le mondeextérieur (capteurs, actionneurs)" Les différents éléments du système ne fonctionnent pasindépendament mais collaborent à une ou plusieurs tâchescommunes. Conséquence : une partie au moins de l!état global dusystème est partagée entre plusieurs éléments (sinon, on aurait unfonctionnement indépendant)" Caractéristiques des systèmes réparties, notion d!intergiciel" Les principaux schémas d!architecture des applications réparties" Les problèmes à résoudre! Patrons et canevas de base pour les applicationsréparties" Proxy, Factory, Wrapper, Adapter, Observer, " Architectures d!intergicielDe manière plus précise : toute expression de la spécification du systèmefait intervenir plusieurs éléments (exemple : préserver un invariant global,mettre des interfaces en correspondance, etc.)! Architectures d!intergiciel pour les objets répartis 2005-2006, S. Krakowiak5Caractéristiques des systèmes répartis (2) 2005-2006, S. Krakowiak6Caractéristiques des systèmes répartis (3)! Difficultés! Propriétés souhaitées" Propriété d!asynchronisme du système de communication (pas de bornesupérieure stricte pour le temps de transmission d!un message" Le système doit pouvoir fonctionner (au moins de façon dégradée) mêmeen cas de défaillance de certains de ses éléments" Le système doit pouvoir résister à des perturbations du système decommunication (perte de messages, déconnexion temporaire,performances dégradées)" Le système doit pouvoir résister à des attaques contre sa sécurité (violationde la confidentialité, de l!intégrité, usage indu de ressources, déni deservice)" Le système doit pouvoir facilement s!adapter pour réagir à deschangements d!environnement ou de conditions d!utilisation" Le système doit préserver ses performances lorsque sa taille croît (nombred'éléments, nombre d!utilisateurs, étendue géographique)# Conséquence : difficulté pour détecter les défaillances" Dynamisme (la composition du système change en permanence)# Conséquences : difficulté pour définir un état global# Difficulté pour administrer le système" Grande taille (nombre de composants, d!utilisateurs, dispersiongéographique)# Conséquence : la capacité de croissance (scalability) est unepropriété importante, mais difficile à réaliserMalgré ces difficultés, des grands systèmes répartis existent et sont largementutilisésle DNS (Domain Name System)le World Wide Web 2005-2006, S. Krakowiak7 2005-2006, S. Krakowiak8
Applications répartiesServices et interfaces! Définition! Distinction entre “système” et “application”" Un système est un ensemble de composants (au sens non technique duterme) qui interagissent" Système : gestion des ressources communes et de l!infrastructure, lié demanière étroite au matériel sous-jacent# Système d!exploitation : gestion de chaque élément# Système de communication : échange d!information entre leséléments# Caractéristiques communes : cachent la complexité du matériel et descommunications, fournissent des services communs de plus hautniveau d!abstraction" Application : réponse à un problème spécifique, fourniture de services àses utilisateurs (qui peuvent être d!autres applications). Utilise les servicesgénéraux fournis par le système" La distinction n!est pas toujours évidente, car certaines applicationspeuvent directement travailler à bas niveau (au contact du matériel).Exemple : systèmes embarqués, réseaux de capteurs" Un service est “un comportement défini par contrat, qui peut êtreimplémenté et fourni par un composant pour être utilisé par un autrecomposant, sur la base exclusive du contrat” (*)! Mise en œuvre" Un service est accessible via une ou plusieurs interfaces" Une interface décrit l!interaction entre client et fournisseur du service# Point de vue opérationnel : définition des opérations et structures dedonnées qui concourent à la réalisation du service# Point de vue contractuel : définition du contrat entre client etfournisseur(*) Bieber and Carpenter, Introduction to Service-Oriented Programming, http://www.openwings.org 2005-2006, S. Krakowiak9 2005-2006, S. KrakowiakDéfinitions d!interfaces (1)contrat10Définitions d!interfaces (2)conformité! Partie “opérationnelle”" Interface Definition Language (IDL)client# Pas de standard, mais s!appuie sur un langage existantfournisseurint. requise IDL CORBA sur C Java et C# définissent leur propre IDL! Partie “contractuelle”int. fournie" La fourniture d!un service met en jeu deux interfaces# Interface requise (côté client)# Interface fournie (côté fournisseur )" Le contrat spécifie la compatibilité (conformité) entre ces interfaces# Au delà de l!interface, chaque partie est une “boîte noire” pour l!autre(principe d!encapsulation)# Conséquence : client ou fournisseur peuvent être remplacés du momentque le composant remplaçant respecte le contrat (est conforme) 2005-2006, S. Krakowiak" Plusieurs niveaux de contrats# Sur la forme : spécification de types - conformité syntaxique# Sur le comportement (1 méthode) : assertions - conformitésémantique# Sur les interactions entre méthodes : synchronisation# Sur les aspects non fonctionnels (performances, etc.) : contrats deQoS11 2005-2006, S. Krakowiak12
L!intergiciel (middleware)Place et interfaces de l!intergiciel! Motivations! L!intergiciel est la couche “du milieu” (Middleware)" Dans un système réparti, même l!interface fournie par les systèmesd!exploitation et de communication est encore trop complexe pourêtre utilisée directement par les applications.APIs haut niveau# Hétérogénéité# Complexité des mécanismes (bas niveau)# Nécessité de gérer (et de masquer, au moins partiellement) larépartitionApplicationIntergiciel! SolutionAPIs bas niveau" Introduire une couche de logiciel intermédiaire (répartie) entre lesniveaux bas (systèmes et communication) et le niveau haut(applications) : c!est itationCommunication" L!intergiciel joue un rôle analogue à celui d!un “super-systèmed!exploitation” pour un système réparti 2005-2006, S. KrakowiakApplicationL!intergiciel est une notion récente (années 90), mais la chose existait avant le mot13 2005-2006, S. KrakowiakFonctions de l!intergiciel14Classes d!intergiciel! Objets répartis! L!intergiciel a quatre fonctions principales" Java RMI, CORBA, DCOM, .NET" Fournir une interface ou API (Applications Programming Interface) de hautniveau aux applications! Composants répartis" Java Beans, Enterprise Java Beans, CCM" Masquer l!hétérogénéité des systèmes matériels et logiciels sous-jacents! Message-Oriented Middleware (MOM)" Rendre la répartition aussi invisible (“transparente”) que possible" Message Queues, Publish-Subscribe" Fournir des services répartis d!usage courant! Coordination! L!intergiciel vise à faciliter la programmation répartie! Intégration d!applications" Développement, évolution, réutilisation des applications" Web Services" Portabilité des applications entre plates-formes! Accès aux données, persistance" Interoperabilité d!applications hétérogènes! Support d!applications mobiles 2005-2006, S. Krakowiak15 2005-2006, S. Krakowiak16
Modèles d!architecture logiciellePrincipaux modèles examinésPlusieurs critères de classificationDéfinition : une description d!un aspect (point de vue, fonction) de l!architectureUsage : compréhension, explication, prévision, preuve, guide pour la réalisation! Selon nature du flot de contrôle" Synchrone (client-serveur)FondementmathématiqueAbstraitUne hiérarchiede modèles" Asynchrone (messages, événements)Objets mathématiques" Mixte! Selon unité d!organisationEntités logiciellesreprésentation non spécifiée" Objets répartis" ComposantsConcret! Structure statique ou dynamiqueAPI génériques" Mobilité des éléments" Reconfiguration,SpécifiqueAPI dans un langageLa majorité des modèles sont concrets ou spécifiques (état de l!art) 2005-2006, S. Krakowiak17 2005-2006, S. KrakowiakProblèmes communs18Principes de conceptionLa construction de systèmes et applications répartis nécessite de résoudre desproblèmes communs! Principe directeur : séparation des préoccupations" Isoler les aspects indépendants (ou faiblement corrélés) et les traiter séparément" Examiner un problème à la fois! Architecture logicielle" Éliminer les interférences" Unités d!organisation, relations" Permettre aux aspects d!évoluer indépendamment! Désignation et liaison! Mise en œuvre! Sécurité" Encapsulation : séparer interface et réalisation (contrat commun)! Tolérance aux fautes" Abstraction : décomposition en niveaux, cacher les détails non pertinents à unniveau donné" Non traité dans ce cours ; traité dans le cours SR" Séparation entre politiques et mécanismes! Qualité de service# Ne pas réimplémenter les mécanismes quand on change de politique# Ne pas “sur-spécifier” les mécanismes" Isolation et expression indépendante des aspects extra-fonctionnels (horsinterface)" En particulier performances, passage à l!échelle! AdministrationCes aspects forment le fil directeur de la suite du cours 2005-2006, S. Krakowiak19 2005-2006, S. Krakowiak20
Patrons de conception (1)Patrons de conception (2)! Définition d!un patron! Définition [dépasse le cadre de la conception de logiciel]" Ensemble de règles (définitions d!éléments , principes de composition, règlesd!usage) permettant de répondre à une classe de besoins spécifiques dans unenvironnement donné.! Propriétés" Un patron est élaboré à partir de l!expérience acquise au cours de la résolutiond!une classe de problèmes apparentés"; il capture des éléments de solutioncommuns" Un patron définit des principes de conception, non des implémentationsspécifiques de ces principes.! Catégories de patrons" Conception : petite échelle, structures usuelles récurrentes dans un contexteparticulier" Architecture : grande échelle, organisation structurelle, définit des sous-systèmes etleurs relations mutuelles" Idiomatiques: constructions propres à un langage" Un patron fournit une aide à la documentation, par ex. en définissant uneterminologie, voire une description formelle (“langage de patrons ”)E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley,1995F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture - vol. 1, Wiley 1996D. Schmidt, M. Stal, H. Rohnert, F. Buschmann. Pattern-Oriented Software Architecture"- vol. 2, Wiley, 2000 2005-2006, S. Krakowiak" Contexte : Situation qui donne lieu à un problème de conception ; doit être aussigénérique que possible (mais éviter l!excès de généralité)" Problème : spécifications, propriétés souhaitées pour la solution; contraintes del!environnement" Solution :# Aspects statiques : composants, relations entre composants; peut être décritpar diagrammes de classe ou de collaboration# Aspects dynamiques : comportement à l!exécution, cycle de vie (création,terminaison, etc.); peut être décrite par des diagrammes de séquence ou d!état21Source: F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture - vol. 1, Wiley 1996 2005-2006, S. Krakowiak22Proxy (Mandataire)Quelques patrons de base! Contexte! Proxy" Applications constituées d!un ensemble d!objets répartis ; un client accède à des servicesfournis par un objet pouvant être distant (le “servant”)" Patron de conception : représentant pour accès à distance! Problème! Factory" Définir un mécanisme d!accès qui évite au client# Le codage “en dur” de l!emplacement du servant dans son code# Une connaissance détaillée des protocoles de communication" Propriétés souhaitables# Accès efficace et sûr# Programmation simple pour le client ; idéalement, pas de différence entre accès local etdistant" Contraintes# Environnement réparti (pas d!espace unique d!adressage)" Patron de conception : création d!objet! Wrapper [Adapter]" Patron de conception : transformation d!interface! Interceptor" Patron d!architecture : adaptation de service! Observer" Patron de base pour l!asynchronisme! Solutions" Utiliser un représentant local du servant sur le site client (isole le client du servant et dusystème de communication)" Garder la même interface pour le représentant et le servant" Définir une structure uniforme de représentant pour faciliter sa génération automatiqueCes patrons sont d!un usage courant dans la construction d!intergicielNombreux exemples dans toute la suite 2005-2006, S. Krakowiak23 2005-2006, S. Krakowiak24
Usage de ProxyFactory (Fabrique)! ContexteClientProxy" Application ensemble d!objets en environnement répartiServant! Problème" Créer dynamiquement des instances multiples d!une classe d!objets" Propriétés souhaitables# Les instances doivent être paramétrables# L!évolution doit être facile (pas de décisions “en dur”)" Contraintes# Environnement réparti (pas d!espace d!adressage unique)service requestpre-processingInterface IInterface Iservice request! Solutions" Abstract Factory : définit une interface et une organisation génériques pour lacréation d!objets ; la création effective est déléguée à des fabriques concrètes quiimplémentent les méthodes de création" Abstract Factory peut être implémentée par Factory Methods (méthode de créationredéfinie dans une sous-classe)" Pour plus de de souplesse, on peut utiliser Factory Factory (le mécanisme decréation lui-même est paramétré)resultpost-processingusually:Remote callresult 2005-2006, S. Krakowiak25 2005-2006, S. KrakowiakUsage de Factory26Un complément à Factory : PoolFactory Factory! Idée : réduire le coût de la gestion de ressources" Technique : réutiliser des exemplaires e degestion dupoolrequest for creationObjectoptionalcreatereturnobject referencePossible delegation fromabstract to concretefactorycréer :si pool non vide"""""sortir une instance du pool"""""nettoyer/initialisersinon"""""créer une nouvelle instancerequest for removaloptional 2005-2006, S. Krakowiak27 2005-2006, S. Krakowiakdétruire :placer l!instancedans le pool28
Utilisation de PoolWrapper (ou Adapter)! Contexte! Gestion de la mémoire" Des clients demandent des services ; des servants fournissent des services ; lesservices sont définis par des interfaces" Pool de zones (plusieurs tailles possibles)" Évite le coût du ramasse-miettes" Évite les copies inutiles (chaînage de zones)! Problème" Réutiliser un servant existant en modifiant son interface et/ou certaines de sesfonctions pour satisfaire les besoins d!un client (ou d!une classe de clients)" Propriétés souhaitables : doit être efficace ; doit être adaptable car les besoinspeuvent changer de façon imprévisible ; doit être réutilisable (générique)" Contraintes :! Gestion des activités" Pool de threads" Évite le coût de la création! Solutions! Gestion de la communication" Le Wrapper isole le servant en interceptant les appels de méthodes versl!interface de celui-ci. Chaque appel est précédé par un prologue et suivi par unépilogue dans le Wrapper" Les paramètres et résultats peuvent être convertis" Pool de connexions! Gestion des composants" Voir plus loin (réalisation des conteneurs) 2005-2006, S. Krakowiak29 2005-2006, S. KrakowiakUsage du Wrapper30Interceptor (Intercepteur)! ContexteClientWrapperServant" Fourniture de services (cadre général)# Client-serveur, pair à pair, hiérarchique# Uni- ou bi-directionnel, synchrone ou asynchroneservice request! Problème" Transformer le service (ajouter de nouvelles fonctions), par différents moyens# Interposer une nouvelle couche de traitement (cf. Wrapper)# Changer (conditionnellement) la destination de l!appel" Contraintes# Les programmes cleient et serveur ne doivent pas être modifiés# Les services peuvent être ajoutés ou supprimés dynamiquementpre-processingInterface I2Interface I1service requestresult! Solutions" Créer des objets d!interposition (statiquement ou dynamiquement). Ces objets# interceptent les appels (et/ou les retours) et insèrent des traitementsspécifiques, éventuellement fondés sur une analyse du contenu# peuvent rediriger l!appel vers une cible différente# peuvent utiliser des appels en retourpost-processingresult 2005-2006, S. Krakowiak31 2005-2006, S. Krakowiak32
Usage d!InterceptorComparaison des patrons de baseSupportingInfrastructureClient! Wrapper vs. Proxy" Wrapper et Proxy ont une structure similaire# Proxy préserve l!interface ; Wrapper transforme l!interface# Proxy utilise (pas toujours) l!accès à distance; Wrapper est en générallocalcreateServantInterceptorcreate! Wrapper vs. Interceptorservice request" Wrapper et Interceptor ont une fonction similaire# Wrapper transforme l!interface# Interceptor transforme la fonction (peut même complètementdétourner l!appel de la cible initiale)Interface IInterface Iuse service! Proxy vs. Interceptorcallback" Proxy est une forme simplifiée d!Interceptor# on peut rajouter un intercepteur à un proxy (smart proxy)result 2005-2006, S. Krakowiak33 2005-2006, S. Krakowiak34Canevas logiciels (Frameworks)Mise en œuvre des patrons de base! Définition! Génération automatique" Un canevas est un “squelette” de programme qui peut être réutilisé (etadapté) pour une famille d!applications" À partir d!une description déclarative" Il met en œuvre un modèle (pas toujours explicite)IDL1IDLproxy" Dans les langages à objets : un canevas comp
Notions de base des syst mes r partis Probl mes de la construction d !applications r parties Mod les d!organisation d!applications r parties Patrons et canevas de base pour le mod le client-serveur Syst mes asynchrones, coordination, programmation par v nements Exemples de syst mes asynchrones Syst ms coposant.ntergicels coposants.
The political parties have been very vocal about political parties not coming within the purview of RTI Act as they claim that it goes against the autonomy of the parties.1 However, political parties act as a link between the citizens and the government and therefore it is a given that the parties must be accountable to the public at large.
does constrain group-centric parties to be somewhat responsive to citizen preferences, but they cede as little policy to voters as possible. Parties mainly push their own agendas and aim to get voters to go along. Despite basic differences between our theory and the standard view of parties, critical tests are hard to identify.
diversity in society; and minimize conflict and con-solidate peace and security. The Institute’s work on political parties takes place under the framework of an institution-wide programme on Political Parties, Participation and Representation and focuses on improving the credibility, effectiveness and delivery capacity of political parties.
PCAOB Release No. 2014-002 June 10, 2014 Page 5 and disclosure of relationships and transactions between the company and its related parties. The standard supersedes the Board's existing standard, AU sec. 334, Related Parties, (the "existing standard"), which has not been substantively updated since it was issued in 1983.10/ Significant Unusual Transactions: The amendments regarding .
Oct 06, 2015 · Convention, yet almost half the nation did not vote (photo by Ava Lowery, Creative Commons) OUTLINE. I. The Logic of Voting —an Irrational Activity . II. Elections without Political Parties? A. Complaints about Parties. B. What Parties Are and How They Differ from Interest Groups. C. Why
D) Contract of Indemnity 3. In a contract of Indemnity there are ----- A) 3 parties and one contract B) 2 parties and 2 contracts C) 3 parties and 3 contracts D) 2 parties and one contract 4. A Contract of Indemnity is ----- A) Vo
Introduction—CHINNEIVAH HAOKIP Rise of political parties in India-pre independence period- SUBODH PRATAP SINGH Political parties-post independence period 1947-67-MONIKA BHUTUNGURU 1967-89-APEKSHA AGRAWAL 1990 ONWARDS- PRATEEK SINGH regional parties-rise and role - NEHA SINGH , MUKUND BIHARI
All material appearing in aliens is the work of individual authors, whose names are listed at the foot of each article. Contributions are not refereed, as this is a newsletter and not an academic journal. Ideas and comments in aliens are not intended in any way to represent the view of IUCN, SSC or the Invasive Species Specialist Group (ISSG) or sponsors, unless specifically stated to the .
