Software Engineering and Middleware A Roadmap

Transcription

1 Software Engineering and Middleware A Roadmap Ecrit par: Dr. Wolfgang Emmerich Présenté par : Mustapha Boushaba Cours : IFT6251

2 Wolfgang Emmerich Enseignant à University College London: Distributed Systems and Security, Advanced Software Engineering, Networks and Applications Programming Intérêts: Distributed Objects and Components Distributed Software Architectures and Middleware Une centaine d articles

3 Plan Introduction Problématiques & Solutions Les Besoins des middlewares Classification des Middlewares Etat d art sur les middlewares Middleware et software engineering Conclusion Remarques

4 Problématique & Solution Problématique Fusion des compagnies Reconstruire tout le système (plus coûteux) Intégration des composants dans un système distribué (moins coûteux). Construction des nouveaux composants dans un minimum de temps. Les compagnies n ont pas forcement la même plate forme logicielle et matériel Besoin d extension (scalability) difficile à devenir (un site peut subir une augmentation de demandes subite) Intégration des composants hérités (legacy component) => besoin de gestion des tolérances aux fautes

5 Problématique & Solution Solution Système distribué vs système centralisé Mais dans un Système distribué on a: Plusieurs points de faille. Diverses communications entre les composants => Problème de sécurité

6 Problématique & Solution Solution Indépendance des plates formes, des systèmes d exploitations, transparence, menaces de sécurité, tolérance aux fautes. Nécessité d un Middleware. Mais quʹest ce qu un middleware?

7 Problématique & Solution Qu est ce qu un middleware? Applications et services Middleware Network operating System Hardware C est la partie intermédiaire entre le système d exploitation et l application

8 Problématique & Solution too expensive and time consuming if application designers have to resolve problems that arise during distributed system construction by directly using network operating system primitives. Component 1 Component n Middleware Network Operating system Hardware Component 1 Component n Middleware Network Operating system Component 1 Component n Middleware Network Operating system Hardware Host 2 Network Component 1 Hardware Component n Middleware Network Operating system Hardware Host n-1 Host 1 Host n Middleware in Distributed System Construction Tout doit se passer comme si l application se déroule en local

9 Les spécifications des middlewares Network Communication Transforme les données complexes: Marshaling/unmarshaling DS2 DS Application: applications utilisant les propriétés d interconnexion Présentation: conversion des données émises/reçues Session: maintien de synchronisation, coordination des communications Transport: gestion de l envoi de données TCP/UDP Réseau: routage des données, recherche du meilleur chemin IP Liaison: contrôle de la couche physique, gestion des erreurs Physique: ce n est que la carte It s too costly, too error prone and too time-consuming to build application on DS1 Solution : laisser au middleware les couches 5 et 6

10 Les spécifications des middlewares Coordination Les composants peuvent s exécuter d une façon concurrentielle Besoin d un mécanisme de synchronisation (soutenu par la couche session) Communication synchrone: Un composant qui demande à un autre d exécuter un service attend la fin de l exécution de ce service avant de poursuivre son déroulement. Communication asynchrone: Un composant qui demande à un autre d exécuter un service, poursuit son propre traitement pendant que le deuxième composant traite sa demande. Besoin de la politique des threads (Simple thread, multithread, thread hybride)

11 Les spécifications des middlewares Coordination Les composants ne peuvent pas être lancés tous àla fois: problème des ressources Besoin des mécanismes: Activation Désactivation

12 Les spécifications des middlewares Reliability (Fiabilité) Détecter et corriger les erreurs: Délivrer des requêtes du client au serveur: Best effort: fait son possible pour acheminer les informations jusqu au destination sans fournir de garantie de performance. At most once: Exécution au plus une fois At least once: Exécution au moins une fois Exactly once: Exécution une et une seule fois

13 Les spécifications des middlewares Scalability Augmenter le nombre de composants sans toucher àl architecture du système Ne peut être respecter que si on respecte: Access transparency (composant local ou distant) Location transparency (location physique du composant) Migration transparency Replication transparency

14 Les spécifications des middlewares Heterogeneity (Hétérogénéité) Il peut être causé par: Hardware OS platforms Programming languages Middleware itself Middleware will have to be interoperable with other implementations of the same middleware or even different types of middleware in order to facilitate distributed system construction

15 Classification des Middlewares En générale 4 catégories Transactionnal middleware Message Oriented Middleware Procedurale Middleware Object and Component Middleware

16 Classification des Middlewares Transactionnal middleware Quelques Notions: Transaction: séquence dʹopérations élémentaires. Elle est exécutée comme une seule opération indivisible. Transaction valide: toutes les opérations sont menées à terme. Transaction invalide, si au moins une des opérations n a pas pu être achevée. Transaction doit avoir les propriétés ACID Qu est ce que les propriétés ACID:

17 Transactionnal middleware Propriétés ACID Atomic: les opérations constituant la transaction forment une unité indivisible Cohérence : les transactions font passer le système d un état cohérent à un autre dans le respect des règles d intégrité Isolée : aucune modification n est visible tant que toutes les opérations n ont pas été réalisées et validées. Durable : Les transactions validées sont conservées même si le système tombe en panne

18 Transactionnal middleware Exemple de transaction Virement bancaire 2 opérations indissociables dans une transaction: Débiter le compte source Créditer le compte client

19 Transactionnal middleware Autre Exemple de transaction Agence de voyage Hôtel Location de voiture Air Canada Réserver voyage: Transaction Coordinateur Net

20 Transactionnal middleware Validation à deux phases Les intervenants: Participant : site qui va exécuter au moins une transaction coordinateur: site qui vas prendre en charge la validation deux phases Deux phases: Préparation Le coordinateur demande à chaque participant de se préparer à valider la transaction Validation Le coordinateur ordonne à tous les participants de valider ou d annuler leur transaction

21 Transactionnal middleware Validation à deux phases Source:

22 Transactionnal middleware Caractéristiques du transactional Middleware Network communication: les composants peuvent résider sur différents sites. Transparence entre client et serveur Coordination Utilise une communication Synchrone et Asynchrone Utilise un système d activation et de désactivation Reliability Middleware doit s assurer que les composants utilisent le système de validation à2 phases. Implémenter le protocole DTP, pour assurer la fiabilité. Pas besoin, si les composants sont basés sur un SGBD

23 Transactionnal middleware protocole DTP proposé par l X/Open, il offre deux interfaces : TX : interface entre le Transaction Manager (TM) et l applicatif. Un API qui permet d invoquer le moniteur transactionnel. XA : interface de la Ressource Manager (RM) directement utilisée par le moniteur transactionnel. Mise en œuvre de protocoles de validation à deux phases (Two Phase Commit) : préparation de toutes les écritures puis écritures des résultats.

24 Transactionnal middleware Caractéristiques Scalability Supporte la répartition de charge Supporte la réplication Heterogeneity Composants sur différents sites. Possibilité d une communication via DTP. Indépendamment de la plate forme.

25 Transactionnal middleware Points forts & Points Faibles Points forts Fiabilité Facilité d intégration avec les bases de données Points faibles Création d une surcharge Marshaling et un marshaling fait manuellement Portabilité réduite (pas de standard pour la définition des services sur les serveurs de composants)

26 Message Oriented Middleware application client serveur application n serveur application 2 Message request Queue d arrivé serveur application 1 Message reply Queue des messages MOM

27 Message Oriented Middleware Caractéristiques Network communication Client envoie une notification d un événement ou requête sous forme de message Un message peut contenir les paramètres des services. Coordination Supporte d une façon naturelle la livraison des messages asynchrone (Système de Queue) Un client peut continuer à s exécuter sans se soucier de l arrivée du résultat.

28 Message Oriented Middleware Reliability (Fiabilité) Tolérance de panne assurée par la Queue: Client envoi àla queue sans se soucier de l activation du composant Livrez au moins une fois le message (at least once) Scalability (Extensibilité) Ne soutient pas l accès transparent: Queue est utilisée même pour les composants locaux. La queue doit être configurée par l administrateur Difficile de coder la queue au niveau du client et serveur.

29 Message Oriented Middleware Heterogeneity MOM n est pas hétérogène Code du marshaling et unmarshaling est laissé à l application

30 Message Oriented Middleware Points forts & Points Faibles Points forts Tolérance de panne Idéal pour la communication de groupes Idéal pour un système de publication/souscription Points faibles Ne supporte que at least once, le même message pourra être délivré plusieurs fois L extensibilité et l hétérogénéité sont limitées Ne supporte pas les propriétés des transactions (ACID) Code du marshaling et unmarshaling est laissé à l application

31 Procedural Middleware Source:

32 Procedural Middleware Architecture simplifiée de RPC client serveur client Server procedure call procedure client stub locate (un)marshal send (receive) Transport Network Transport Sélecteur selects stub server stub (un)marshal receive (send)

33 Procedural Middleware Caractéristiques Network communication Par implémentation du marshaling et unmarshaling Par implémentation du stub, côté client et serveur Coordination RPC supporte une communication synchrone One to One Ne supporte pas les communications asynchrones et les communications multicast Différentes formes pour l activation des composants: Soit toujours actif (au démarrage de l application) Soit à la demande (grâce a Init daemon)

34 Procedural Middleware Reliability RPC est exécuté en at most once Une exception est générée quand il y a erreur au niveau du RPC Ne supporte pas exactly once ni les transactions Scalability Elle est limitée : RPC Windows ou Unix ne supporte pas le mécanisme de réplication. Heterogeneity PM supporte les différents langages de programmation PM supporte les différentes plates formes logicielles et matérielles. Le stubs peut traduire les informations spécifiques au matériel dans une forme standard.

35 Procedural Middleware Points forts & Points Faibles Points forts Marshaling et unmarshaling sont faites d une façon automatique. Points faibles PM n est pas extensible et ne supporte pas bien les tolérances de panne PM n est pas réflexif : un programme RPC ne peut pas retourner un autre programme RPC (solution rapporté par Object and Component Middleware)

36 Object and Component Middleware 3 standards: CORBA : Common Object Request Broker Architecture Java RMI : Remote Method Invocation DCOM : Distributed Component Object Model

37 Object and Component Middleware Architecture CORBA simplifiée ORB : Object Request Broker = IDL (Interface Definition Language) + IIOP (Internet Inter Orb Protocol ) définition dʹinterface localisation et activation de l objet distant communication entre les clients et les objets Source:

38 Object and Component Middleware Structure de CORBA ORB : Transporte les requêtes, activation des objets CORBA services: Fournissent les fonctions nécessaires aux applications (exp : Security, Transaction, Query) CORBA facilities: Utilitaires communs qui répondent plus particulièrement aux besoins des utilisateurs pour la création de logiciels à lʹaide de composants réutilisables IDL: Interface d objets applicatifs qui définissent les objets créés

39 Object and Component Middleware Architecture RMI 1. localisation de l objet distant grâce au registre 2. Stub marshalise les arguments de la méthode 3. Invocation de l objet distant 4. Le skeleton unmarshalise les données reçus puis invoque la méthode localement 5. Le skeleton marshalise les données et les envoies vers le stub (client) 6. Récupération des données par le stub et transmission vers l objet faisant appel à la méthode Source:

40 Object and Component Middleware Caractéristiques Network Communication Supporte les requêtes distribuées Le marshaling est assuré par un stub grâce au IDL Coordination Communication synchrone est utilisée par défaut (l objet client est bloqué jusqu à réception de la réponse) supporte les différentes politiques de threading et d activation CORBA supporte le groupe de communication

41 Caractéristiques Reliability (Fiabilité) At most once (par défaut) Supporte le concept des transactions Scalability Supporte la répartition de charge (load balancing) Réplication est limitée

42 Object and Component Middleware Caractéristiques Heteroginiety CORBA et COM supportent multiple langage de programmation (client et serveur ne sont pas écrits nécessairement dans le même langage) JAVA/RMI utilise la machine virtuelle, ce qui résout l hétérogénéité RMI, CORBA et COM peuvent s interagir

43 Object and Component Middleware Points forts & Points Faibles Points forts Fiabilité Capacité d intégrer les messages et les transactions Points faibles L extension (scalability) est limitée

44 Etat d art Les middlewares actuels Ne sont pas flexible (ne s adaptent pas aux besoins des changements) Ne sont pas assez extensible La réplication n est pas supportée pour accomplir la distribution globale Ne conviennent pas aux réseaux sans fil (mon sujet de recherche)

45 Etat d art Besoins pour le future Flexible Middleware Le composant client n a pas à localiser le serveur d où il obtient les services Trading: localiser les composants par type de service au lieu par nom Utiliser le standard ISO/ODP (comme pages jaunes) Utiliser le MOP (MetaObject Protocol) pour l inspection et l adaptation (cela résout la réflexivité) Combiner les middlewares avec langage de balisage (markup languages)tel que XML

46 Etat d art Besoins pour le future Scalable Middleware Recherche sur les réplications non transparente (projet Globe) Real time Middleware (problème de mémoire et de priorité) TAO: c est un real time CORBA prototype Supporte : prioritédes requêtes définition du scheduling

47 Etat d art Middleware for mobile Computing Problèmes les plus fréquents: Stations injoignables : traité comme exception Bande passante n est pas assez large Solutions: Établir des primitives de coordination Compresser les données pour économiser la bande passante.

48 Etat d art Middleware et Software Engineering Impact du middleware sur le génie logiciel Les middlewares sont conçus pour livrer des avantages immédiats dans la construction des systèmes distribués Les vendeurs des middlewares introduisent systématiquement les résultats de recherche dans leurs produits

49 Middleware et Software Engineering Bien définir la nature des exigences non fonctionnelles du middleware. Besoin des méthodes et outils pour quantifier les exigences non fonctionnelles : Exp: pour une architecture extensible, nous avons besoin de quantifier le temps de réponse voulu, les charges maximales, ou le volume de données attendu. Définir des architectures logicielles qui satisferont des besoins non fonctionnels Exemple développé des middlewares orientés ADL (Architecture Description Languages) Besoin de connaître les facteurs qui influencent le design Temps de latence au niveau du réseau L activation La concurrence dans l environnement distribué Les primitives de synchronisation Solution : on a besoin de définir des notations, méthodes et outils pour le design orienté middleware.

50 Conclusion Au cours de la présentation, nous avons vu : Qu est ce qu un middleware Les besoins pour les middlewares Une classification des middlewares L état d art sur les middlewares Relation Middleware et le génie logiciel

51 Remarques Points forts de l article Qualité technique très bonne l auteur a bien soulevé les problèmes qu on peut rencontrer dans le développement d un middleware Relation entre le middleware et le Génie logiciel bien identifiée Points faibles de l article Oùon est à propos de la sécurité dans les middlewares Oùon est à propos de la Qos dans les middlewares La structuration reste à revoir Besoin plus de détail sur la relation génie logiciel et Middleware

52 Capteur Schéma d un nœud Capteur :Mica2

53