Survey of Distributed Objects Middleware JINI, CORBA and HLA.

Présentation au sujet: "Survey of Distributed Objects Middleware JINI, CORBA and HLA."— Transcription de la présentation:

1 Survey of Distributed Objects Middleware JINI, CORBA and HLA.
Simon El-Khoury University of Montreal, Department of Computer science Course :IFT6275 Telematic Professor :Kropf Peter 12/7/2018

2 Overview Middleware JINI CORBA HLA Comparison and Criticisms
Conclusion Les utilisateurs de systèmes d'information ont de plus en plus besoin d'échanger et de partager des informations. Ces informations peuvent être de nature très différentes et sous des formats qui le sont tout autant (fichiers textes, images, messages, données, etc...). Et, plus récemment ces informations peuvent être situées à des endroits différents c'est à dire sur des postes distants, sur des réseaux différents ou encore sur l'Internet. 12/7/2018

3 Middleware CORBA and Jini rt plusieurs autres technology fournit l’interoperabilite entre les applicatios et connectes multiple objets system qui reside dans des machines differents dans les environnements distribués heteregenes est une condition fondamentale dans le commerce électronique CORBA and Jini permet l'interaction entre objets connectes sur plusieurs Reseaux ou bus deployes independamment les uns des autres. On parle d'interoperabilite entre bus. Les utilisateurs de systèmes d'information ont de plus en plus besoin d'échanger et de partager des informations. Ces informations peuvent être de nature très différentes et sous des formats qui le sont tout autant (fichiers textes, images, messages, données, etc...). Et, plus récemment ces informations peuvent être situées à des endroits différents c'est à dire sur des postes distants, sur des réseaux différents ou encore sur l'Internet. 12/7/2018

4 Jini Context Jini est une technologie basée sur Java destiné à facilité l ’interaction entre services matériels ou logiciel dans le contexte d ’un réseau ou ces services apparaissent et disparaître spontanément, par opposition aux systèmes distribuées actuel qui sont souvent statique jini tire avantage de deux aspects de la technologie java : les interfaces et le chargement dynamique de code et comme java est portable c.a.d le meme code java fonctionne sur n ’importe quel operating system et on n` a pas besoin d ’ecrire le code selon la machine et son system d` ’exploitation , ce qui rend jini plus flexible et plus efficace 12/7/2018

5 Key Concepts Services Lookup Services Leasing Transaction Events
12/7/2018

6 Services Services may be added or withdrawn from a Jini federation at any time. Jini provides mechanisms for service registration, lookup, and use. Services communicate by using a service protocol=set of Java interfaces. 12/7/2018

7 Lookup Services Repository of available services
Service objects may be downloaded to a client as required May be federate with other lookup services Lookup service interface provides : Registration, Access, Search, Removal 12/7/2018

8 Discovery and Lookup Protocols
Allow a Jini service (hardware or software) to : Find and join a group of Jini services Advertise capabilities/services Provide required software and attributes 12/7/2018

9 Discovery Protocol 12/7/2018

10 Join Protocol 12/7/2018

11 Lookup Protocol 12/7/2018

12 Client Uses Service 12/7/2018

13 Figure 1. OMG Reference Model Architecture
Overview of CORBA The Common Object Request Broker Architecture (CORBA) est tres general pour l’industry standard CORBA est la spécification d'une architecture orientée objet pour applications. Elle a été définie par l'OMG dans un document publié au mois de novembre 1990. (OMG=object management group, a large non-profit consortium qui inclue les vendeurs majeurs des logiciels Avec CORBA, le client et le serveur sont formellement séparés, on peut alors changer l'un sans changer l'autre. Ainsi le client qui utilise une interface CORBA n'a pas besoin de connaître la façon dont le serveur va exécuter la tâche mais seulement comment faire une requête pour qu'une opération soit effectuée sur un objet.   Dans un environnement classique de client/serveur, il existe une relation de tête-à-tête entre les clients et leurs serveurs. CORBA ajoute un intermédiaire entre le client et le serveur : l'Object Request Broker, ou Broker. Le broker possède " l'intelligence " nécessaire pour mettre en rapport la requête provenant d'un client avec les serveurs qui peuvent y répondre. Overview of CORBA The Common Object Request Broker Architecture (CORBA) [OMG:95a] is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshalling and demarshalling; and operation dispatching. See the OMG Web site for more overview material on CORBA. See my CORBA page for additional information on CORBA, including our tutorials and research on high-performance and real-time ORBs. Results from our research on high-performance and real-time CORBA are freely available for downloading in the open-source TAO ORB. The following figure illustrates the primary components in the OMG Reference Model architecture. Descriptions of these components are available further below. Portions of these descriptions are based on material from [Vinoski]. Figure 1. OMG Reference Model Architecture Object Services -- These are domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain. Two examples of Object Services that fulfill this role are: The Naming Service -- which allows clients to find objects based on names; The Trading Service -- which allows clients to find objects based on their properties. There are also Object Service specifications for lifecycle management, security, transactions, and event notification, as well as many others [OMG:95b]. Common Facilities -- Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications. An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document. Domain Interfaces -- These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains. For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains. Application Interfaces - These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization. 12/7/2018

14 What is CORBA ? CORBA provides a software infrastructure of communication for the distributed applications. Standard CORBA offers a total solution to treat the heterogeneity of the distributed applications. The services objects and the common utilities of CORBA provide a vast range of software components to build distributed applications . 12/7/2018

15 CORBA ORB Architecture
CORBA est la spécification d'une architecture orientée objet pour applications. Elle a été définie par l'OMG dans un document publié au mois de novembre 1990. Avec CORBA, le client et le serveur sont formellement séparés, on peut alors changer l'un sans changer l'autre. Ainsi le client qui utilise une interface CORBA n'a pas besoin de connaître la façon dont le serveur va exécuter la tâche mais seulement comment faire une requête pour qu'une opération soit effectuée sur un objet.   Dans un environnement classique de client/serveur, il existe une relation de tête-à-tête entre les clients et leurs serveurs. CORBA ajoute un intermédiaire entre le client et le serveur : l'Object Request Broker, ou Broker. Le broker possède " l'intelligence " nécessaire pour mettre en rapport la requête provenant d'un client avec les serveurs qui peuvent y répondre. L'apport d'un broker entraîne plusieurs améliorations : Le client et le serveur n'ont plus besoin de se connaître de façon directe. Ils se trouvent grâce au broker. Ainsi seul le broker a besoin de connaître la localisation et les ressources disponibles du client ou du serveur qui se trouvent sur le réseau. Une relation en tête-à-tête entre les clients et leurs serveurs n'est plus requise. Ainsi grâce au broker, plusieurs serveurs peuvent travailler avec un seul client, ou un seul serveur peut travailler avec plusieurs clients. Une application cliente peut localiser et inter-réagir avec un objet ou un serveur durant une transaction. Dans l'environnement classique client/serveur, la requête est prédéfinie alors qu'ici, le client peut invoquer une requête sur un objet durant la transaction. La requête = IDL language interface CORBA sépare le client du serveur en restreignant la communication qui peut exister entre eux par un type de message appelé requête. Chaque interaction dans un système CORBA est : soit un client qui envoie une requête, c'est à dire une invocation. soit un serveur qui répond à une requête. Toutes les requêtes ont la même structure: une indication sur l'opération que doit exécuter le serveur à la demande du client, une référence spécifique à l'objet sur lequel le serveur doit effectuer l'opération, un mécanisme qui doit permettre de retourner un message concernant la réussite ou l'échec de l'opération, une référence optionnelle à un objet de contexte, et des arguments spécifiques à l'opération à effectuer L'IDL, Interface Definition Language Le client et le serveur ont besoin d'informations pour pouvoir travailler sur les mêmes objets. Par exemple, chaque objet doit annoncer les opérations que l'on peut effectuer sur lui. CORBA dispose ces informations dans une interface qui définit les caractéristiques et les comportement de chaque type d'objet, y compris les opérations qu'un serveur peut exécuter sur ces objets. Pour définir une interface, on utilise l' IDL pour coder l'information dans un jeu de définitions d'interfaces. Les développeurs entreposent ces définitions d'interfaces dans des fichiers IDL. Ainsi avant d'écrire une application cliente ou serveur, on doit d'abord définir son ou ses interface(s), c'est à dire créer un fichier IDL. C'est ce fichier qui contient les définitions des interfaces que le client ou le serveur supporte. L'IDL est un langage de définition et non un langage de programmation grâce auquel on définit des interfaces et des structures de données et non des algorithmes. On utilise des fichiers IDL pour générer un code source pour le langage de programmation désiré. On peut donc, par exemple, écrire des applications clientes en LISP et des applications serveurs en C et faire communiquer ce client et ce serveur. Les exceptions CORBA communique des informations sur la réussite ou l'échec d'une opération. Ces informations sont considérées comme des exceptions. Toutes les requêtes doivent contenir un mécanisme qui permet de retourner des exceptions. La syntaxe dépend du langage de programmation utilisé. Une méthode de l'application du serveur peut fournir l'information sur l'exception s'il y a une erreur ou par exemple s'il n'y a pas assez d'arguments dans la requête. Le broker lui-même peut le faire si par exemple l'accès d'un serveur lui est interdit. L'application client peut lire mais ne peut pas modifier une exception. Par défaut, s'il n'y a pas de retour d'exception, l'opération est considérée comme réussie. Par contre s'il y en a une, l'application cliente doit vérifier si l'opération est réussie ou non. 12/7/2018

16 The IDL Language 12/7/2018 Le language Interface Definition Language
Les interfaces ecrites en IDL peuvent etre projetees dans differents langages de programmation. C ’est grace a ce mecanisme de projection que les objets CORBA sont independants de tout langage. Le langage Interface Definition Language est un des éléments clés du bus à objets répartis Corba. En effet, il permet la coopération entre utilisateurs et fournisseurs de services en masquant les problèmes liés à l'intéropérabilité et la localisation des objets. IDL est très similaire à C++ avec les concepts de classes correspondants aux concepts d'une interface le langage IDL n'est pas un langage de programmation mais un langage de description de services orientés objet pour l'environnement CORBA. l'intérêt majeur du langage IDL est de permettre la définition des contrats passés entre les fournisseurs d'objets CORBA et leurs utilisateurs. Les fournisseurs décrivent, grâce au langage IDL, l'ensemble des interfaces des objets qu'ils veulent fournir à leurs clients; ensuite, les clients utilisent ces interfaces IDL pour exploiter à travers leurs programmes les objets ainsi fournis. à travers ce langage standardisé et utilisé de part et d'autre, les divers problèmes d'hétérogénéité et ou d'interopérabilité sont masqués. De plus, les objets ainsi fournis s'utilisent toujours de la même manière à travers leur interface IDL quelles que soient leurs localisations : ils peuvent résider au sein des programmes clients, sur la même machine ou à des milliers de kilomètres sur le réseau Internet. Le langage IDL permet donc d'exprimer des contrats d'une manière totalement indépendante des langages de programmation et des divers compilateurs qui servent à implanter ces composants. La traduction de ces contrats vers les langages de programmation est réalisée automatiquement par des précompilateurs IDL. Ces précompilateurs génèrent du code pour le langage de programmation cible en suivant des règles de projection clairement définies par l`OMG Il est ainsi généré les stubs, les squellet qui doit ensuite être complété par le programmeur, dans le langage de programmation choisi, et est défini les interfaces du référentiel interface. NB : Le stub est la partie du code générée automatiquement par un compilateur IDL vers un langage de programmation cible. Ce code est utilisé par le client lors des invocations statiques. Il est le lien entre le client et l'ORB. Il traduit : les invocations du client en messages transmissibles sur le réseau : opération "marshalling", les messages qui proviennent de l'ORB dans le langage choisi : opération "unmarshalling". Le squelette statique (skeleton) est la partie du code générée automatiquement par un compilateur IDL vers un langage de programmation cible. Ce code est utilisé par l'adapteur d`objet lors des invocations statiques. Il est le lien entre l`ORB et l'objet d'implémentation. Il reconstitue la requête du client de façon à invoquer la méthode requise en langage choisi : opération "unmarshalling". Il traduit les paramètres de retour en messages transmissibles sur le réseau : opération "marshalling". l'Adaptateur d'objet permet d'associer les implantations des objets avec l'ORB. 12/7/2018

17 Interface Example 12/7/2018 Un exemple d ’interface.
Les interfaces IDL ne sont que descriptives. Elles ne permettent aucune implementation. IDL est un routine pour appler les objet de java par example .mais ce idl est pour java 12/7/2018

18 High Level Architecture (HLA)
Functional View of the HLA 12/7/2018

19 Definition of HLA HLA Interface Specification
HLA Object Model Template (OMT) HLA Rules 12/7/2018

20 Run Time Infrastructure (RTI)
Federation management Declaration management Object management Ownership management Time management Data distribution management 12/7/2018

21 Comparison and Criticisms
CORBA Free Programming langage choice no fully standardisation Complicated programming model Jini Java environment Standard dynamic services A simple programming model Le MiddleWare Les utilisateurs de systèmes d'information ont de plus en plus besoin d'échanger et de partager des informations. Ces informations peuvent être de nature très différentes et sous des formats qui le sont tout autant (fichiers textes, images, messages, données, etc...). Et, plus récemment ces informations peuvent être situées à des endroits différents c'est à dire sur des postes distants, sur des réseaux différents ou encore sur l'Internet. La diversité et la spécialisation des supports utilisés sont inversement proportionnelles à la facilité que les utilisateurs ont à se les échanger. De plus il existe des milliers d'applications indépendantes écrites dans des quinzaines de langages différents sur des dizaines de systèmes d'exploitation différents. Ce sont, de ce manque de standards et du besoin vital de communiquer (surtout pour les entreprises) et de ce marché très porteur, que sont nées un nouveau type de suites logicielles: les Middleware. Concrètement, un Middleware est un ensemble de programmes qui isole une application de l'ensemble des processus qui résultent de son lancement sur le système. Un MiddleWare permet la communication entre des clients et des serveurs ayant des structures et une implémentation différentes. Il permet l'échange d'informations dans tous les cas et pour toutes les architectures. Enfin, les MiddleWare doivent fournir un moyen aux clients de trouver leurs serveurs, aux serveurs de trouver leurs clients et en général de trouver n'importe quel objet atteignable. 12/7/2018

22 Comparison and Criticisms
Common Properties Provide Objects Repository Subscription/Publication Model Choosing, monitoring and maintaining the interaction sessions HLA Simulation real Time HLA need to pass a whole data in a near time Integrate HLA with CORBA Le MiddleWare Les utilisateurs de systèmes d'information ont de plus en plus besoin d'échanger et de partager des informations. Ces informations peuvent être de nature très différentes et sous des formats qui le sont tout autant (fichiers textes, images, messages, données, etc...). Et, plus récemment ces informations peuvent être situées à des endroits différents c'est à dire sur des postes distants, sur des réseaux différents ou encore sur l'Internet. La diversité et la spécialisation des supports utilisés sont inversement proportionnelles à la facilité que les utilisateurs ont à se les échanger. De plus il existe des milliers d'applications indépendantes écrites dans des quinzaines de langages différents sur des dizaines de systèmes d'exploitation différents. Ce sont, de ce manque de standards et du besoin vital de communiquer (surtout pour les entreprises) et de ce marché très porteur, que sont nées un nouveau type de suites logicielles: les Middleware. Concrètement, un Middleware est un ensemble de programmes qui isole une application de l'ensemble des processus qui résultent de son lancement sur le système. Un MiddleWare permet la communication entre des clients et des serveurs ayant des structures et une implémentation différentes. Il permet l'échange d'informations dans tous les cas et pour toutes les architectures. Enfin, les MiddleWare doivent fournir un moyen aux clients de trouver leurs serveurs, aux serveurs de trouver leurs clients et en général de trouver n'importe quel objet atteignable. 12/7/2018

23 Conclusion Interoperability Spontaneous Network
Transparent Communication Share and Manage Resources 12/7/2018

24 References Jini : CORBA : HLA : MiddleWare : http://www.jini.org
Core Jini, by Keith Edwards, Prentice-Hall, 1999. CORBA : Inside CORBA, William A. Ruh and Thomas J. Mowbray, Addison-Wesley, 1997. HLA : DMSO High Level Architecture Homepage.URL MiddleWare : 12/7/2018

25 Presented by Simon El-Khoury
THE END Presented by Simon El-Khoury 12/7/2018