MIDDLEWARE

1. MIDDLEWARE Le middleware est un logiciel de connexion qui se compose d'un ensemble de services et/ou de milieux de développement d'applications distribuées qui permettent à plusieures entités (processus, objets etc.) résidents sur un ou plusieurs ordinateurs, d'interagir à travers un réseau d'interconnexion en dépit des différences dans les protocoles de communication, architectures des systèmes locaux, systèmes opérationnels etc..

2. middleware Applications Distribuées Services de configuration et administration du système Services d'abstraction coopérative Milieu de développement applicatif Services de communication Infrastructure de communication (exemple TCP/IP) MIDDLEWARE

3. Middleware (support pour la coopération applicative) Applications de base WEB Telnet Email FTP RPC CORBA SNMP Zone des applications Process-to-process Interopérabilité de transport de l'information TCP/IP Host-to-host Infrastructure de transport de l’information 802.1 Bridging e Switching 802.3 802.3u 802.3z CSMA/CD 802.5 FDDI 802.11 X.25 Frame Relay ATM TOKEN RING ISO 9314 Wireless Backbone Réseaux Locaux

4. Middleware: Services Service de Communication. Ce service offre un API qui permet à l'application distribuée d'échanger les informations entre ses composantes résidentes sur des ordinateurs avec des caractéristiques d'hardware et/ou logiciels différentes. Le but de ce service est de cacher les disomogéneité dûs à la représentation des données utilisés par les différents ordinateurs, aux systèmes opérationnels locaux et aux différents réseaux qui constituent l'infrastructure de la plate-forme. Pour les communications on entend des différents paradigmes d'interaction comme des RPC, la messagerie applicative, le modèle publish/subscribe, etc.

5. Middleware: Services Services d'abstraction et coopération. Ces services représentent le coeur du middleware et ils comprennent entre les autres: ·Directory Service ou service de "pages blanches", qu'il pourvoit à l'identification et à la localisation d'entités. Ce service rend les applications au-dessus du middleware indépendantes du sous-système d'acheminement des messages. ·   Security Service, finalisé à la protection des éléments critiques comme les données et les services applicatifs à travers des techniques comme authentification, autorisation et cryptographie. ·  Time Service qui garantisse que tous les clock internes entre client et serveur soient synchronisés dans un acceptable niveau de variance

6. Middleware: Services Services pour les applications. Ces services permettent à une application d'avoir un accès direct, avec le réseau ou avec les services offerts par le middleware. Par exemple un service orienté aux transactions, à l'intérieur d'un middleware, il peut fournir un support pour l’accès transactionnel aux bases de données hétérogènes. Services d'administration du système. • monitorage • configuration • aménagement. Milieu de développement applicatif. • instruments d'aide à l'écriture • debugging • chargement d'applications distribuées aux objets et basées sur processus. • (Interface Definition Langage) pour l'interconnexion entre formulaires écrits en différents langages de programmation et résidents en ordinateurs distincts.

7. Middleware: Objectifs • interopérabilité et connectivité pour applications distribuées sur plate-formes hétérogènes • trait-d'union des applications utilisées à l'intérieur d'une entreprise. Middleware Système Informatif A Système Informatif C

8. Remote Procedure Call Un Appel aux Procédures Distant, RPC transforme l'interaction Client/Serveur dans un appel à la procédure, semblable à celle locale, en cachant au programmateur la plus grande partie des mécanismes implémentés qui la composent, comme: • l'échange de messages, • la localisation du serveur qui fournit le service • les différentes représentations possibles des données des machines impliquées dans l'interaction.

9. RPC Ce déguisement arrive en quatre phases: • À temps d'écriture du code. Les RPC employés/fournis devront etre déclarée par le programmateur explicitement à travers l’ import/export des définitions des interfaces • À temps d'exécution. Chaque machine sur laquelle il est en exécution un programme client et/ou serveur devra avoir un support à temps d’exécution pour les RPC, RPC run-time support, apte à exécuter quelques opérations des RPC comme par exemple la localisation du serveur ou l'enregistrement d'un nouveau service offert par un nouveau serveur. • À temps de compilation. Pendant la compilation pour chaque appel à la procédure distante, des lignes de code sont accrochées au programme originaire (stub). Cettes lignes permettent des opérations standardes sur les données (empaquetage et codage reconnue universellement) et les appels au RPC run-time support; • À temps de liaison. Pendant la liaison le programme source est mis en communication avec le RPC run-time support pour obtenir le code exécutable.

10. RPC Timeline Client Serveur Blocked Request Blocked Computing Reply Blocked

11. Mécanismes pour RPC • Un protocole qui cache les pièges du réseau (perte de paquets et réorganisation des messages) • Un mécanisme pour empaqueter les arguments du côté de l’appelant et pour les dépaqueter du côté de l’appelé

12. RPC CLIENT Serveur résultats Résultats Appel CLIENT STUB SERVEUR STUB dépaquete résultats i résultats dépaquète parametres empaquète empaquète Les résultats RPC Run-Time Support RPC Run-Time Support Kernel du SO local Kernel dul SO local

13. RPC Serveur programme Serveur procédure Serveur stub RPC Interface generateur Header file RPC Specifications run - time support Client stub principale programme Client programme Client

14. Localisation du serveur Méthode Statique. Câbler à l'intérieur du client l'adresse (addresse IP) du serveur. Méthode Dynamique. Le stub du client, pendant qu'il empaquette les données, il envoie en même temps un broadcast et demande l'adresse d'un serveur apte à exécuter le RPC désiré. Le support run-time des RPC de chaque machine répond si le service recherché est fourni par un serveur en exécution.

15. serveur stub client stub 4 3 1 nom serveur 2 Localisation du serveur Name Server. le client à la recherche d'un serveur consulte une entité, nom serveur, qui gère une liste d'associations serveur-services.

16. CLIENT SIDE begin ….. a=0; doppioincr(a,a); writeln (a); ... end SERVER SIDE procedure doppioincr (var x,y: integer) begin ……. x:= x+2; y:= y+3; end Passage des Paramètres Call by Reference – déconseillé Call by Copy/Restore. Copie une variable a, de la part du stub du client, dans le paquet-données (comme si c’était une valeur). La nouvelle valeur de a, rendue par le serveur dans les modèles de retour du RPC, elle sera copiée, du stub du client, dans la cellule de mémoire qu'il contient la variable a. Le résultat: Call by ref, a=“5” Call by copy/restore a= “2” o “3” dépendant de l'implémentation du stub du client

17. Sémantique des RPC “At least once” • Time-out stub du client • Retransmission “At most once” • Time-out stub du client • Code de faute de retour “Exactly once”

18. Middleware: Taxinomie Remote Data Access (RDA). premier exemple de middleware RDA s'interpose entre un client et un serveur d'une base des données RDA se compose d'un protocole basé sur l'envoi de commandes, sous forme de langage Structured-Query-langage (SQL) aux bases de données distantes. Accès direct aux données. RDA a été adopté comme standard international par l’ISO.

19. Middleware: Taxinomie Basés sur Remote Procedure Call (RPCs). • Simplicité de distribution de la logique d'une application • Middleware plus utilisé • les RPC manquent de la flexibilité demandé par des structures dynamiques distribuées (comme les entreprises) pour la gestion de son patrimoine de données et pour le copartage de ses ressources.

20. Middleware: Taxinomie Message-Oriented Middleware (MOM) • Échange des données entre entités distinctes de façon asynchrone • Messagerie applicative genre email. l'activité du receiver n’est pas demandée • Implémentation à travers la gestion des queues de messages • Sender wait-free • MOM est considéré, en général, un bon choix pour connecter des applications distribuées sur réseau géographique. 

21. Middleware: Taxinomie Transaction processing (TP) monitor • milieu intégré et instruments pour gérer en ligne un flux d'applications formé par des flux de transactions. • balancement de charge, gestion des queues de messages associées aux transactions, sauvetage de secours et recouvrement de panne. • TP écrans ne naissent pas comme middleware mais comme systèmes orientés aux bases de données.  

22. Middleware: Taxinomie Distributed object technology (DOT) • Les objets d'une application peuvent être distribués sur un réseau hétérogène, • DOT combine quelques caractéristiques des MOM unis à la technologie aux objets. • DOT ne spécifie pas les mécanismes utilisés pour envoyer questions et recevoir réponses dans l'architecture Client/Serveur. Il utilise des abstractions pour trouver ressources distantes.

23. Structured Query Language/Remote Data Access (SQL/RDA) • RDA (Remote Database Access) est un protocole standard de communication pour l'accès aux bases de données distantes adoptées par l'ISO. • Le standard est formé par deux parties: • Generic RDAANSI/ISO/IEC 9579-1:1993[ISO9579-1]. Il spécifie le modèle générique, le service (basé sur transactions) et le protocole pour la connexion aux bases de données distantes. • SQL Specialization ANSI/ISO/IEC 9579-2:1993[ISO9579-2]. Il spécifie les caractéristiques additionnelles que le protocole doit avoir pour accéder aux données de manière conforme au langage SQL

24. Structured Query Language/Remote Data Access (SQL/RDA) • L'objectif de RDA est celui de recevoir l'interconnexion entre bases de données hétérogènes en cachant les différents formats des données et des langages d'interrogation natifs.

25. Structured Query Language/Remote Data Access (SQL/RDA) • Database gateway. La requête envoyée par le client passe pour la base des données gateway qui la transmet à la convenable base de données distante. Un exemple d'usage de RDA en milieu hétérogène est décrit dans l’illustration 4.3.

26. Structured Query Language/Remote Data Access (SQL/RDA) • RDA utilise des primitives de communication synchrones pour échanger des informations entre les différents membres du système basés sur TCP. • Ils n'existe aucune politique pour la gestion des pannes, pour la subdivision de la charge entre différents serveurs et pour la sécurité. Dans ce dernier cas tout est déféré au système de contrôle des accès de la base de données. • L' interface de service de RDA consiste: • de services pour le contrôle de la connexion entre client et serveur, • de services pour le déplacement des opérations SQL sur les bases de données, • de services pour le déplacement des modèles entre client et serveur, • de services pour le déplacement des résultats du serveur au client et • de services pour le contrôle des transactions. • Les touches SQL sont transmises entre client et serveur comme caractères ASCII. Le contrôle des transactions inclut les opérations de commit à une et à deux phases.

27. Distributed Computing Environment (DCE) • DCE a été proposé par l'Open Software Foundation (OSF) • OSF est né avec le but de fournir un milieu UNIX ouvert, basé sur RPC et libre de l'influence de SUN et AT&T. • DCE c'est une ambiance logiciel intégrée pour le développement et l'exécution d'applications distribuées au-dessus des systèmes opérationnels existants. • IBM, Hewlett-Packard et des autres, ils unissent leurs systèmes opérationnels UNIX propriétaires avec le code de DCE en fournissant à l'utilisateur un paquet unique.

28. Distributed Applications S E C U R I T Y Distributed services, concurrency control, group management ecc. M A N A G E M E N T Distributed File Service Basic System Services (time, name, process services ecc.) DCE RPC and Group Communication Processes and threads Kernel and Transport Services Local Operating System and transport system calls Distributed Computing Environment (DCE) • Threads • RPC • Time Service

29. DCE (threads) • augmenter le parallélisme à l'intérieur d'un processus unique. • Les thread représentent dans une machine UNIX un second niveau de parallélisme après celui lié au processus. • Les thread partagent le même code, les portes de communication et les fichiers ouverts (Process Contre Block) • Un thread est caractérisé par un program-counter un stack-pointer et par un ensemble de registres (Thread Control Block).

30. DCE (threads) • problème de synchronisation entre les thread dans un même processus (dirigé par le programmateur) • Les thread de DCE suivent le standard POSIX et le kernel de DCE il met à disposition de l'utilisateur 54 primitives à travers des librairies (création, destruction et synchronisation). • Le kernel de DCE gère en outre feux et variables de condition. Les feux permettent la synchronisation entre thread. Les feux et les variables de condition permettent la synchronisation entre thread et ressources extérieures.  

31. DCE (Time Service) • Synchronisation entre les clock du système. Un clock a une erreur relative d'une partie sur un million, après une heure il peut avoir commis une faute 3,6msec. Après un jour 86 msec etc. il est clair que si nous voulons maintenir toutes les horloges des ordinateurs dans un écart de 6 msec, nous avons besoin de synchroniser les clock toutes les 2 heures. • Synchronisation avec le temps réel (UTC et GPS). • UTC est fourni par une station radio par pays. Ces stations lancent des signaux de synchronisation aux ondes courtes. Un récepteur peut à ce point resynchroniser son propre horologe selon le signal capté. Cette procédure permet une précision de 2msec théoriquement. En pratique on obtient que l'horloge locale peut se déplacer respect à l'UTC d'environ 10msec. • Global Position System, qui fournit des services de position et d'horaire (en phase avec UTC), on a atteint une précision de microsecondes.

32. DCE (Time Service) • Il existe un intervalle d'incertitude dans lequel sont contenus des événements sur lesquels il n'est pas possible d'établir une priorité temporale certaine. • Le time service fourni par DCE associe à chaque événement (par exemple la fermeture d'un fichier) un intervalle de temps dans lequel celui-ci puisse se passer. • Si deux entractes de temps associés aux deux événements se superposent, il n'est pas possible de définir lequel des deux événements il est arrivé d'abord. • DCE met à disposition une librairie de fonctions, 33, pour obtenir l'entracte de temps courant, pour manipuler entractes pour, comparer entractes etc,

33. DCE (Time Service) • Du point de vue implémentatif: • Chaque client doit recevoir un time clerk (démons) • Existence de Time Serveurs en contact indépendant avec l'UTC • En voulant atteindre un soin de 6msec, l'algorithme de resynchronisation d'un client est le suivant: • Chaques deux heures un time clerk envoie une requête de re-synchronisation aux time serveurs, chacun des time serveurs envoie son entracte de temps courant. • Le time clerck élimine immédiatement les entractes qui ne se superposent pas aux autres. Il calcule l'intersection entre les entractes restantes et il assume qu'UTC soit au centre de cette intersection. • Comment changer l'horaire à l'intérieur de l'ordinateur. • Si l'échange d'horaire impose un retour en arrière, le clock local se bloque jusqu'à ce qu'on ne récupère pas le gap. • Si l'échange d'horaire impose un saut en avant on commande directement la nouvelle valeur du clock.

34. DCE (Directory Service) • Le Directory Service est de type hiérarchique. • Les ressources (fichiers, services, ordinateurs, imprimants etc.) sont structurés en cellules et chaque cellule a son propre Cell Directory Service (CDS) apte à localiser les ressources sur la base d’un nom logique et vice versa. • Chaque ressource a un nom logique et une seule adresse physique à l'intérieur de la cellule. • Pour localiser une ressource hors d’une cellule, le DCE soutient deux mécanismes: • Le Global Directory Service (GDS) pour la localisation des cellules en DCE • Domain Name System (DNS) pour la localisation d'une ressource sur internet.

35. Message-Oriented Middleware • Classe spécifique de middleware qui soutient l'échange de messages dans un milieu d'applications distribuées qui sont message-driven c'est-à-dire l'évolution de l'application est scandée par la transmission et la réception de messages. • Messagerie asynchrone (le serveur ne doit pas être nécessairement en marche): • Queues de messages • Publish/Subscribe

36. Queues de messages • Les messages envoyés par les clients à un serveur restent emmagasiné dans une queue jusqu'à ce que le serveur les prélève de la queue même. • Cela facilite • Implémentation des politiques de priorité • Balancement de la charge (+ serveurs prélèvent messages de la même queue) • Gestion d'applications tolérantes aux pannes • Amélioration des performances (client non blocante)

37. Publish/Subscribe • bus architecture message • Sur le bus s'appuient deux entités: les publisher (ceux qui envoient/publient les messages et les subscriber (ceux qui reçoivent les messages). • Le publisher publie un message avec un certain sujet, ex. "/ football /Italie/équipes/Milan", et ce message atteint tous les subscriber qui sont abonnés à tel sujet. • Un publisher n'est pas obligé de connaître tous ses subscriber et vice versa. • l'ensemble des publisher et des subscriber d'un certain sujet peut changer dynamiquement

38. Publish/Subscribe • Un processus peut être publisher de différents sujets et subscriber d'autres. • Le logiciel qui implémente ce paradigme de communication doit tâcher de ne pas inonder le réseau avec des copies du même message. • Les sujets forment un espace unique et hiérarchique des noms (comme dans un file system) • Le bus message consent des différents niveaux de gestion, de la remise avec certificat à la remise non-fiable. • Si un subscriber est actif à l'arrivée d'un message, un upcall est activé. • Si il n’est pas actif, le message est emmagasiné à l'intérieur d'un router qui va le livrer dès que le subscriber sera actif

39. Mqseries (IBM) • MQseries se base sur un système de queues de messages. • Mqseries est un middleware basé sur une série d'objets. Queue managers, Queues, Namelists, Distribution list. • L'élément clé en Mqseries est la queue manager qui gère l'envoi, la réception et la queue des messages de la part des applications à travers le Message Queue Interface (MQI).  • Les queues sont créées/enlevée par les applications aux appels opportuns à la queue manager. • Il y a deux types de queues, les locales (gérées par la queue manager à laquelle l'application est connexe) et les distantes

40. Mqseries (IBM) • À l'intérieur d'une queue manager les queues peuvent être de deux types, temporaires et persistantes. • Les noms des queues définies par les utilisateurs sont gardés dans un dépôt nommé namelist qui gère l'association nom logique - nom physique. • Donc, quand un utilisateur veut accéder à une queue en connaissant son adresse logique, l'adresse physique est découverte à travers la namelist. • Une application peut envoyer le même message en plusieures queues à travers le mécanisme de distribution list. (émulation du multicast)

41. Tib/Rendezvous • Tib/Rendezvous se base sur un service de communication publish/subscribe très sophistiqué. • Tib/Rendezvous met à disposition: • un primitif request/reply (de type synchrone) • un primitif broadcast request/reply où un message est reçu par plusieurs serveurs, chacun desquels envoie un reply (application repliquation active ou passive).

42. Tib/Rendezvous • Tib/rendezvous fournit deux niveaux de fiabilité sur les remises des messages: remise fiable et remise certifiée • La remise fiable notifie un rapport au publisher en cas de perte d'un message (sans indiquer le message) • Dans le cas de remise certifiée, le rapport révèle le message perdu et les subscriber qui ne l'ont pas reçu. • Les messages envoyés avec remise certifiée sont emmagasinés dans la mémoire de masse du publisher de façon à être successivement prélevé en cas de pannes.

43. Tib/Rendezvous • L'architecture logiciel de TIB/rendezvous est formée d’une série de composants: • Une librairie TIB/rendezvous qui permet à l'application d'utiliser l'API de TIB/Rendezvous. • Un processus caché (démon) TIB/Rendezvous qui reçoit les appels de la librairie et qui gère toutes les communications entre les processus applicatifs (sois distants que résidents sur la même machine) la fragmentation et le rassemblement des paquets et le filtrage basé sur le subject des messages. • Un procédé achemineur caché des messages (TIB/Rendezvous Deamon) qui permet de ne pas envoyer des messages en sous-réseaux où il n‘y est aucun subscriber présent pour ce sujet (autrement les différents sous-réseaux seraient bouchés de messages!) • Les changements des tables des suscriber sont notifiés aux différents TIB/Rendezvous Deamon à travers des périodiques protocoles d'échange de messages.

44. Tib/Rendezvous • L'architecture logiciel de TIB/rendezvous est formé d’une série de composants: • · Cache de Messages (Message Cache) stocke les messages qui passent sur le réseau concernant un certain sujet. Quand un processus exécute le subscribe pour un certain sujet, si le message cache est actif pour ce sujet, il recevra tous les messages présents dans le cache. Cela permet à un processus de recevoir des messages mêmequand il n'est pas en exécution et de gérer des politiques de tolérance aux pannes. • TIB/Rendezvous fault-tolerant serveur. En TIBCO il est possible de définir un groupe de processus qui se coordonnent pour offrir un certain service avec un déterminé degré de tolérance aux pannes. Ce logiciel est apte à gérer réplique passive et réplique active. Le contrôle de la panne utilise la technique d'heartbeats.

45. SmartSocket (Talarian) SmartSockets est un produit de middleware réalisé par Talarian qui offre des communications du type point-à-point, publish/subscribe, synchrones (RPC) et asynchrones pour la coopération du type program-to-program. Les messages sont débranchés à travers un réseau de serveurs RT qui sont, en fait, des routers gérants l'acheminement des messages selon le chemin le plus bref. • Communications rapides grâce à: • Priorité aux messages, • Codification binaire des messages, • Réseau de RT serveur.

46. SmartSocket (Talarian) Communications fiables:          Au niveau de message. SmartSocket offre la possibilité d'emmagasiner dans un fichier, pour un réemploi suivant, un message en quatre moments distincts. Quand le message laisse un programme, quand un message est remis à un programme, quand un message arrive au RT serveur et quand un message laisse un RT serveur. • Au niveau de programme. SmartSocket inclut des instruments pour la gestion de la réplique passive de processus. Donc il est possible d'insérer des redondances sur les RT serveurs qui sont les éléments critiques de l'architecture SmartSocket. Le relèvement des processus détraqués se fait à l’aide de messages spéciaux nommés heartbeats. • Au niveau de connexion. SmartSocket permet d'utiliser des messages keep-alive sur les connexions de façon à en vérifier la véritable capacité opérationnelle.

47. IDL ORB IOR Corba (Common Object Request Broker Architecture) Architecture de base • Middleware orienté aux objets • Un objet CORBA est une entité abstraite qui fournit des services • CORBA introduit différents niveaux de transparence • Transparence de langage • Transparence de communication • Transparence de location

48. Stub Skeleton reply ORB ORB GIOP GIOP request TCP TCP IP IP Accès accès au au réseau réseau Stub Skeleton ORB ORB GIOP GIOP IIOP IIOP TCP TCP IP IP Accés Accès au au rèseau réseau reply request ORB – Object Request Broker • L'ORB est "logiquement" un bus de communication • "Physiquement" chaque processus CORBA a son propre ORB • Chaque invocation CORBA passe pour l'ORB • C'est l'ORB qui gère la communication

49. IOR – Interoperable Object Reference • À chaque objet serveur il est associé un IOR. • L'IOR contient informations d'adressage de l'objet. • Pour invoquer des opérations sur un objet (serveur) le client doit obtenir son IOR. • Au moment de l'invocation, l'ORB lit les informations dans l'IOR et il instaure la connexion avec l'objet • Repository ID: le type IDL de l'objet représenté • Endpoint Info: le couple host:porte • Object Key: identificateur de l'objet