UF8 - Gestion et intégration des systèmes d`information

Transcription

Plan de la présentation
Les applications réparties
CORBA
Le langage IDL
CORBA par la pratique
UF8 - Gestion et intégration des systèmes
d’information, Middleware
Licence Professionnelle DA2I
—
Claude Duvallet
Université du Havre
Courriel : [email protected]
Année scolaire 2007-2008
Claude Duvallet — 1/99
UF8 - Gestion et intégration des systèmes d’information, Middleware
CORBA
Le langage IDL
Objectifs du cours
Systèmes distribués, applications réparties, objets distribués.
Qu’est qu’un Middleware ?
Les outils : RPC, RMI, EJB, CORBA.
Java RMI fait par Hadhoum Boukachour.
CORBA
Le langage IDL
Sources WEB et supports de cours utilisés
Pascal Molli. Maître de conférences à l’Université Henry
Poincaré.
Roland Balter. ScalAgent Distributed Technologies.
Cyrille Bertelle. Maître de conférences à l’Université du Havre.
Damien Olivier. Maître de conférences à l’Université du Havre.
Éric Leclercq. Université de Bourgogne.
CORBA
Le langage IDL
1
2
CORBA
3
Le langage IDL
4
CORBA
Le langage IDL
Introduction
Problèmes généraux
Modèles d’exécution
Les applications réparties : principes
Application répartie = traitements coopérants sur des données
réparties.
Coopération = communications + synchronisation :
un modèle d’exécution,
une interface de programmation,
des outils de développement.
Différents types de distribution :
Distribution des données : données distribuées, traitement
centralisé.
Distribution du contrôle : données centralisées, contrôle distribué.
Distribution des utilisateurs : données et contrôle centralisés,
utilisateurs distribués.
⇒ une combinaison de tout ça...
CORBA
Le langage IDL
Introduction
Exemples d’applications réparties
Coordination d’activités :
Systèmes à flots de données (« workflow »).
Systèmes à agents.
Communication et partage d’informations :
Bibliothèques virtuelles.
Collecticiels :
Édition coopérative.
Téléconférence.
Ingénierie concourante.
Applications temps réel :
Contrôle de procédés industriels.
Avionique, etc.
Localisation de mobiles.
Toutes les applications qui nécessitent des utilisateurs ou des
données réparties.
CORBA
Le langage IDL
Introduction
Construction d’applications réparties
Conception de l’architecture de l’application.
Programmation des entités logicielles :
Utilisation d’un mécanisme de communication avec un modèle
d’exécution (socket, RMI, RPC, CORBA, etc.).
Programmation en fonction du modèle d’exécution.
Configuration des entités de diverses provenances :
leur permettre de communiquer, d’échanger des données.
leur permettre d’échanger des informations de contrôle.
leur permettre de se comprendre.
Prendre en considération l’installation et le déploiement.
Administration :
Surveillance, maintenance et évolution des applications.
CORBA
Le langage IDL
Introduction
Conception d’un jeu de Morpion (1/2)
Conception suivant une architecture Client/Serveur.
Les échanges entre les clients et le serveur :
le client passe des commandes au serveur.
le serveur notifie au client les changements d’états aux clients
(joueur X a joué en (x,y)).
Choix d’un modèle d’exécution :
appel de procédure distante (RMI).
implémentation de méthodes d’accès au sein du serveur.
implémentation d’un client sous forme d’une applet.
CORBA
Le langage IDL
Introduction
Conception d’un jeu de Morpion (2/2)
Configuration :
mise en place des politiques de sécurité : fichiers de sécurité et
serveur d’authentification.
configuration du serveur Web pour recevoir l’applet.
Déploiement (applet client) :
copie des fichiers ".class".
démarrage de rmiregistry.
démarrage du serveur HTTP.
démarrage du serveur Morpion.
accès distant à la page Morpion.
CORBA
Le langage IDL
Introduction
Schéma général des applications réparties
...
Applications
Middleware
Système de communication
Site A
Site B
Middleware = couche logicielle destinée à :
masquer l’hétérogénéité des machines et des systèmes,
masquer la répartition des données et des traitements,
fournir une API de programmation.
CORBA
Le langage IDL
Introduction
Tolérance aux pannes.
Passage à l’échelle.
Nommage et accès aux applications.
Intégration de l’existant.
Déploiement des applications.
Sécurité et authentification.
Disponibilité de l’application.
CORBA
Le langage IDL
Introduction
Tolérance aux pannes
En anglais : reliability, fault tolerance.
Que se passe-t-il quand :
un serveur participant à l’application tombe en panne.
un serveur envoie des informations erronées.
Un serveur n’est plus atteignable (mais pas en panne) puis le
redevient.
Le respect de l’atomicité dans les applications réparties.
CORBA
Le langage IDL
Introduction
Passage à l’échelle
En anglais : scalability.
Ce qui marche pour un utilisateur, marchera-t-il pour 10 000 ?
Ce qui marche pour un objet, marchera-t-il pour 1 000 000 ?
Ce qui marche pour un site, marchera-t-il pour 1 000 ?
Exemple : les applications de gestion de commerce électronique.
CORBA
Le langage IDL
Introduction
Nommage et accès aux applications
En anglais : naming.
Comment retrouver les objets distants qui sont disponibles ?
Un objet = un identifiant + un état + un comportement.
Dans les applications non réparties, le nommage est géré par le
langage (référence) ou par l’OS (adressage).
Dans les applications réparties, le nommage doit être explicite et
dynamique.
Exemple de nommage dans des applications répartie : DNS,
URL, JNDI, LDAP,...
CORBA
Le langage IDL
Introduction
Intégration de l’existant
En anglais : legacy.
Comment se connecter sur toutes les ressources d’une
entreprise ?
Qu’en est-il de l’interopérabilité des applications ?
Comment construire des transactions réparties ?
CORBA
Le langage IDL
Introduction
Déploiement des applications
Comment installer tous les composants logiciels sur différents
clients et serveurs ?
Lorsque je change un nom de serveur ou que j’en ajoute un,
est-ce que je dois recompiler ? est-ce que je dois redéployer ? ou
est-ce que je peux configurer automatiquement le
redéploiement ?
CORBA
Le langage IDL
Introduction
Sécurité et authentification
Confidentialité.
Intégrité :
Droits d’accès, Pare-Feu.
Authentification :
Identification des applications partenaires.
Non-répudiation.
Messages authentifiés.
Combien de personnes utilisent l’application, qui sont-ils ?
Nécessité de se protéger contre les intrusions.
Nécessité de stocker les accès des clients dans des fichiers
journaux.
CORBA
Le langage IDL
Introduction
Disponibilité d’une application répartie
Exemple : un serveur qui fait de la tolérance aux pannes ne peut
plus assurer d’autres tâches.
Permettre des accès simultanés sur un même objet :
Sérialiser les objets.
Paralléliser les accès.
Appliquer différentes politiques.
Multi-threading.
CORBA
Le langage IDL
Introduction
Les différents modèles d’exécution
Modèle Client-Serveur :
RPC, RMI, CORBA, Servlet,...
Modèle de communication par messages :
MOM : Message Oriented Middleware.
Files de messages.
Modèle de communication par événements.
Modèle à base de composants :
Bean, EJB.
Modèle à base d’agents mobiles :
Agglet, Voyager.
Modèles à mémoires « virtuelles » partagées :
Modèles à espace de tuples.
Modèles à objets dupliqués.
CORBA
Le langage IDL
Introduction
Le modèle Client-Serveur (1/2)
Coté serveur :
Externalisation de services.
Attente de requêtes en provenances de clients puis exécution des
requêtes en séquentiel ou en parallèle.
Interface : Skeleton
reçoit l’appel sous forme de « stream »,
décapsule les paramètres,
demande l’exécution,
renvoi les paramètres (par références) et les résultats.
Coté client :
Émission de requêtes puis attente de la réponse,
Initiateur du dialogue,
Interface : Stub
reçoit l’appel en local,
encapsule les paramètres,
attends les résultats du serveur,
décapsule les résultats,
redonne la main à la fonction appelante.
CORBA
Le langage IDL
Introduction
Le modèle Client-Serveur (2/2)
Client/Serveur « traditionnel » :
RPC.
Client/Serveur « à objets » :
RMI, CORBA, DCOM.
Client/Serveur « de données » :
Requêtes SQL.
Client/Serveur « WEB » :
CGI, Servlet, asp, jsp, php,...
CORBA
Le langage IDL
Introduction
Le modèle de communication par messages
Module de synchronisation :
Communication asynchrone
émission non bloquante,
réception bloquante (attente jusqu’à réception d’un message).
Mode de communication :
Communication directe entre processus (agents).
Communication indirecte (boîtes aux lettres).
Mode de transmission :
Peut-être typé.
Les environnements :
les sockets sous Unix.
la programmation parallèle en MPI, PVM.
les Middlewares à messages (MOM).
la normalisation JMS (Java Messenging Service).
CORBA
Le langage IDL
Introduction
Le modèle de communication par événements
Concepts de bases :
événements, réactions.
Principe d’attachement :
association dynamique entre un type d’évènement et une réaction.
Communication anonyme :
indépendance entre l’émetteur et les « consommateurs » d’un
évènement.
Deux modes : PULL et PUSH
PULL : les clients viennent prendre régulièrement leurs messages.
PUSH : une méthode prédéfinie est attachée à chaque type de
message et elle est appelée automatiquement à chaque
occurrence de l’évènement.
CORBA
Le langage IDL
Introduction
Le modèle à base de composants
Définition d’un composant :
module logiciel autonome et réutilisable.
composable visuellement et donc dynamiquement pour construire
une application.
Beans, EJB, CORBA Component.
Caractéristiques d’un composant :
des entrées/sorties déclarées pour permettre les connexions
entre plusieurs composants.
des propriétés déclarées permettant de configurer le composant.
Composant Java Beans :
Bean = classe + conventions d’écriture :
Entrées : les méthodes publiques.
Propriétés : variables d’instances et accesseurs/modificateurs.
Sorties : les événements émis.
On connecte et on configure des instances.
Les instances sont crées par un BeanContainer (modèle par
composition).
CORBA
Le langage IDL
Introduction
Les composants Beans
Le BeanContainer doit être capable d’interroger les instances
pour :
découvrir les propriétés qui peuvent être manipulées et comment
elles doivent l’être,
découvrir les événements qui doivent être émis,
utiliser l’introspection (au moyen de la classe class).
Conventions d’écriture :
constructeur de la classe sans paramètres,
méthodes commençant par set ou get pour manipuler les
propriétés,
méthodes commençant par add et remove pour manipuler les
événements.
Un bean n’est pas forcément un composant visuel : il remplit une
fonction (entrées/sorties/propriétés).
Un bean peut accéder à un objet distant (RMI, CORBA, etc.), se
connecter à une base de données.
CORBA
Le langage IDL
Introduction
Les Enterprise Java Beans
Un environnement pour la répartition des objets répartis :
un serveur qui gère tous les problèmes de répartitions.
le développement d’objets métiers conforme au modèle de
l’environnement.
Les serveurs d’EJB ou serveurs d’applications : il s’agit d’un
cadre d’exécution pour des composants obéissant à un modèle
(COM ou EJB), c’est-à-dire un ensemble de services permettant
la bonne exécution des composants :
les services de base ;
l’administration, l’exploitation, la sécurité ;
les passerelles vers l’existant ;
la persistance.
Quatre services de base :
accès aux composants,
optimisation de l’accès aux ressources locales et distantes,
gestion transactionnelle,
répartition de charge.
CORBA
Le langage IDL
Introduction
Les modèles par agents mobiles
Code mobile = programme se déplaçant d’un site à un autre sur
le réseau.
Exemple : les applets = programme exécutable inclut dans une
page HTML et qui s’exécute sur le site qui télécharge la page.
Avantage de la mobilité :
efficacité : privilégie les interactions locales,
moins de communications distantes effectuées pour les échanges
de messages,
amène le code aux données plutôt que le contraire,
permet à des clients d’étendre les fonctions d’un serveur pour des
besoins spécifiques.
Les agents mobiles :
entités logicielles permettant de construire des applications
naturellement distribuées,
utilisation de ressources allouées,
autonomie et déplacement sur différents sites d’un réseau.
CORBA
Le langage IDL
Introduction
Modèles à mémoires « virtuelles » partagées (1/2)
Objectifs :
Replacer le programmeur dans les conditions d’un système
centralisé :
utiliser un espace mémoire commun pour les communications,
synchroniser les applications en utilisant des variables partagées.
Avantages :
transparence de la distribution pour le développeur,
efficacité du développement car utilisation des paradigmes usuels
de la programmation concurrente.
Problématique :
Utilisation des outils de développement existants.
Mise en œuvre efficace d’une mémoire partagée distribuée.
CORBA
Le langage IDL
Introduction
Modèles à mémoires « virtuelles » partagées (2/2)
Approches utilisées :
Modèles à espace de tuples :
bases de données relationnelles partagées,
modèle de programmation à la « linda » : dépôt, retrait et
consultation d’objets.
Modèles à objets répartis partagées :
espace d’objets répartis partagés,
interface de programmation : langage à objets « étendus »,
plusieurs modes de réalisation : objets répliqués ou objets à image
unique.
CORBA
Le langage IDL
Introduction
Middleware
Le Middleware conceptualise et réalise les fonctions suivantes :
communications entre les applications réparties,
échanges de données,
facilités de mise en œuvre.
Il résout les problèmes d’intégration et d’interopérabilité :
indépendance entre les applications et le système d’exploitation,
portabilité des applications,
partage des services distribués.
Services d’un Middleware :
communication,
localisation,
gestion transactionelle,
sécurité,
administration.
CORBA
Le langage IDL
La vision globale de l’OMG
Le modèle Client/Serveur
L’architecture globale
Le bus à objets répartis CORBA
Vision globale de la construction d’applications réparties
(1/2)
L’Object Management Group (OMG) est un consortium
international crée en 1989.
But : définir les spécifications d’architectures distribuées et
ouvertes.
Regroupe plus de 850 acteurs du monde informatique :
des constructeurs (HP, IBM, Sun, ...)
des producteurs logiciels (Netscape, Inprise/Borland, IONA, ...)
des utilisateurs (Bœing, Alcatel, ...)
des institutions et des universités
Définition de standards pour l’intégration d’applications
distribuées hétérogènes à partir des technologies orientées
objets.
CORBA
Le langage IDL
Vision globale de la construction d’applications réparties
(2/2)
Les propriétés fondamentales :
la réutilisabilité,
l’interopérabilité,
la portabilité des objets logiciels.
L’élément clef est CORBA (Common Object Request Broker
Architecture) :
C’est un middleware orienté objet.
Plus précisément, c’est un bus à objets répartis qui :
offre un support d’exécution masquant les couches bases du
système réparti (système d’exploitation, processeur et réseau).
prends en charge les communications entre les logiciels formant
les applications réparties hétérogènes.
CORBA
Le langage IDL
Le modèle objet Client/Serveur (1/5)
CORBA propose un modèle de coopération :
Client/Serveur, Abstrait, Orienté objet.
Chaque application peut exporter :
certaines de ses fonctionalités (services),
sous la forme d’objets CORBA : c’est la composante d’abstraction
(structuration) du modèle.
Les interactions entre applications :
au moyen d’invocations à distance des méthodes des objets.
La notion de client/serveur n’intervient qu’uniquement lors de
l’utilisation d’un objet : l’application implantant l’objet est le
serveur, l’application utilisant l’objet est le client.
CORBA
Le langage IDL
Bus CORBA
Interface
de l’objet
Référence
de l’objet
Requête
Objet
CORBA
Code
d’implantation
Activation
Etat
de
l’objet
Application
Serveur
Application
Cliente
CORBA
Le langage IDL
Application cliente :
programme qui invoque les méthodes des objets à travers le bus
CORBA.
Référence de l’objet :
structure désignant l’objet CORBA et contenant l’information
nécessaire pour le localiser sur le bus.
Interface de l’objet :
type abstrait spécifiant l’objet par ses méthodes et ses attributs,
se définit au moyen du langage IDL.
Requête :
le mécanisme d’invocation d’une méthode ou d’un accès à un
attribut de l’objet.
CORBA
Le langage IDL
Bus CORBA :
achemine les requêtes de l’application cliente vers l’objet en
masquant tous les problèmes d’hétérogénéité (langages,
systèmes d’exploitation, matériels, réseaux).
Objet CORBA :
objet logiciel cible (entité virtuelle gérée par le bus CORBA).
Activation :
processus d’association d’un objet d’implantation à un objet
CORBA.
Implantation :
code de l’objet CORBA à un instant donné, gère un état de l’objet
temporaire. Au cours du temps, un même objet CORBA peut-être
associé à des implantations différentes.
CORBA
Le langage IDL
Code d’implantation :
regroupe les traitements associés à l’implantation de l’objet
CORBA. Par exemple, une classe Java ou un ensemble de
fonctions C.
Application serveur :
structure d’accueil des objets d’implantation et des exécutions des
opérations : un processus Unix par exemple.
CORBA
Le langage IDL
L’architecture globale (1/4)
Interfaces
de domaine
Objets
applicatifs
Utilitaires
communs
Télécoms
Télécoms
Spécifiques
Administration
Workflow
Santé
Finance
DataWare
IHM
Bus d’objets répartis
Nommage
Vendeur
Interrogations
Sécurité
Cycle
de vie
Relations
Transations
Collections
Propriétés
Temps
Persistance
Licence
Externalisation
Evénements Changements Concurrence
Services objet communs
CORBA
Le langage IDL
L’OMG propose une vision globale de la construction
d’applications réparties.
Classifier les différents objets qui interviennent dans une
application en fonction de leurs rôles :
Le bus à objets répartis est l’élément fondamental :
assure le transport des requêtes entre tous les objets CORBA,
offre un environnement d’exécution masquant l’hétérogénéité liée
aux langages de programmation, aux systèmes d’exploitation, aux
processeurs et aux protocoles réseaux.
CORBA
Le langage IDL
Les services objets communs (CORBAservices)
Fournissent sous formes d’objets CORBA, spécifiés grâce au
langage IDL, les fonctions systèmes nécessaires à la plupart des
applications réparties.
L’OMG a défini des services pour les annuaires, le cycle de vie
des objets, les relations entre les objets, les événements, les
transactions, la sécurité, la persistance, etc.
Au fur et à mesure des besoins, l’OMG ajoute des nouveaux
services communs.
Les utilitaires communs (CORBAfacilities) :
Ils sont des canevas d’objets ou des cadres d’exécution qui
répondent plus particulièrement aux besoins des utilisateurs.
Ils standardisent l’interface utilisateur, la gestion de l’information,
l’administration, les flots d’information,...
CORBA
Le langage IDL
Les interfaces de domaines (Domain Interfaces) :
Définissent des objets métiers spécifiques à des domaines
d’activité : par exemple la finance, la santé (dossier médical) ou
les télécoms.
Leur objectif est d’assurer l’interopérabilité sémantique entre les
systèmes d’informations d’entreprises d’un même métier
(« Business Object Framework » = BOFs).
Les objets applicatifs (Application Objects) :
Spécifiques à une application, ils ne sont donc pas standardisés.
Toutefois, dès que le rôle de ces objets apparaît dans plus d’une
application, ils peuvent alors rentrer dans une des catégories
précédentes et donc être standardisés par l’OMG.
CORBA
Le langage IDL
Caractéristiques du bus à objets répartis CORBA (1/2)
Le bus CORBA est un intermédiaire à travers lequel les objets
vont pouvoir dialoguer :
Liaison avec les langages de programmation : C, C++, JAVA,
SmallTalk, Ada, COBOL, etc.
Transparences des invocations :
les requêtes aux objets semblent toujours être locales,
le bus CORBA se charge de les acheminer.
Invocation statique et dynamique : deux mécanismes permettent
de soumettre les requêtes aux objets
en statique, les invocations sont contrôlées à la compilation,
en dynamique, les invocations doivent être contrôlées à l’exécution.
CORBA
Le langage IDL
Caractéristiques du bus à objets répartis CORBA (2/2)
Système auto-descriptif :
les interfaces des objets sont connues du bus et sont aussi
accessibles par les programmes par l’intermédiaires d’un
référentiel d’interfaces.
Activation automatique et transparente des objets :
les objets sont en mémoire uniquement s’ils sont utilisés par des
applications clientes.
L’interopérabilité entre bus :
à partir de la norme CORBA 2.0, définition d’un protocole
générique de transport des requêtes (GIOP = General Inter-ORB
Protocol) permettant l’interconnexion de bus CORBA provenant
de fournisseurs différents,
une de ses instanciations est l’Internet Inter-ORB Protocol (IIOP)
fonctionnant au dessus de TCP/IP.
CORBA
Le langage IDL
Les composantes du BUS (1/3)
Fournisseur
Client
SSI
SII
Interface
BUS
DII
DSI
Adaptateur d’Objets OA
Object Request Broker
Référentiel
Interfaces IFR
Référentiel
Implantations ImpIR
CORBA
Le langage IDL
ORB (Object Request Broker) : noyau de transport des requêtes
Intègre au minimum les protocoles de transport GIOP et IIOP.
L’interface du BUS fournit les primitives de base comme
l’initialisation de l’ORB.
SII (Static Interface Invocation) : interface d’invocation statique
permet de soumettre des requêtes contrôlées à la compilation des
programmes.
DII (Dynamic Interface Invocation) : interface d’invocations
dynamiques
permet de construire dynamiquement des requêtes vers n’importe
quel objet CORBA sans générer ou utiliser une interface SSI.
IR (Interface Repository) : référentiel des interfaces
contient une représentation des interfaces OMG-IDL accessibles
par les applications durant l’exécution.
CORBA
Le langage IDL
SSI (Skeleton Static Interface) : interface de squelettes statiques
permettant à l’implantation des objets de recevoir les requêtes qui
leur sont destinées.
générée comme l’interface SII.
DSI (Dynamic Skeleton Interface) : interface de squelettes
dynamiques
permet d’intercepter dynamiquement toute requête sans générer
une interface SSI.
équivalent à DII mais coté serveur.
OA (Object Adapter) : adaptateur d’objets
crée les objets CORBA.
maintient les associations entre les objets CORBA et les
implantations.
réalise l’activation automatique si nécessaire
ImpIR (Implementation Repository) : référentiel des implantations
contient l’information nécessaire à l’implantation.
ce référentiel est spécifique à chaque application CORBA.
CORBA
Le langage IDL
Construction d’un bus CORBA
Différentes approches peuvent être utilisées pour construire un
bus :
1 bus = 1 processus : les objets sont dans le même espace
mémoire que les clients. C’est le cas typique des applications
embarquées.
1 bus = 1 OS : les clients et les fournisseurs sont des processus
différents sur la même machine.
1 bus = 1 réseau : les processus sont sur des sites différents et
les requêtes sont véhiculées à travers le réseau (Internet avec
IIOP).
Fédération de bus CORBA :
Plusieurs bus distincts peuvent être mis ensemble pour former
une fédération.
Les communications entre ces bus peuvent se faire :
soit par le protocole commun IIOP,
soit à travers des passerelles spécifiques ou génériques (Exemple :
DII ←→ DSI).
CORBA
Le langage IDL
Les protocoles réseaux (1/2)
Tout bus à la norme CORBA 2.0 doit fournir les protocoles GIOP
et IIOP.
Le protocole GIOP définit :
une représentation commune des données (CDR ou Common
Data Representation).
un format de références d’objet interopérable (IOR ou
Interoperable Object Reference).
un ensemble de messages de transport des requêtes aux objets
(Request Reply, ...).
GIOP est seulement un protocole générique, IIOP fournit alors
une implantation de GIOP au dessus de TCP/IP.
CORBA
Le langage IDL
Les protocoles réseaux (2/2)
Les IORs utilisés avec IIOP doivent contenir :
le nom complet de l’interface IDL de l’objet,
l’adresse IP de la machine où est localisé l’objet,
le port IP pour se connecter au serveur de l’objet,
une clé pour désigner l’objet dans le serveur : son format est libre
et il est différent pour chaque implantation du bus CORBA.
Un bus CORBA peut utiliser d’autres protocoles de transport des
requêtes aux objets :
il existe des bus multi-protocoles permettant d’avoir simultanément
des communications en IIOP, en UDP-IIOP et en multicast-IIOP.
CORBA
Le langage IDL
Les services communs
Objectif : standardiser les interfaces des
fonctions systèmes indispensables à la
construction et à l’exécution de la majorité
des applications réparties.
CORBA
Le langage IDL
La recherche d’objets
Offrir des mécanismes pour rechercher dynamiquement des
objets sur le BUS (équivalents à des annuaires téléphoniques)
Nommage (Naming Service) est l’équivalent des « pages
blanches » :
les objets sont désignés par des noms symboliques. Cet annuaire
est matérialisé par un graphe de répertoires de désignation.
Vendeur (Trader Service) est l’équivalent des « pages jaunes » :
les objets peuvent être recherchés en fonction de leurs
caractéristiques/fonctionnalités.
CORBA
Le langage IDL
Le cycle de vie des objets (1/4)
Cycle de Vie (Life Cycle Service) :
il décrit des interfaces pour la création, la copie, le déplacement et
la destruction des objets sur le bus,
il définit pour cela la notion unique de fabrique d’objets « Object
Factory ».
Propriétés (Property Service) :
Permet aux utilisateurs d’associer dynamiquement des valeurs
nommées à des objets.
Ces propriétés ne modifient pas l’interface IDL mais représentent
des besoins spécifiques aux clients (annotations ou
méta-données par exemple).
Relations (Relationship Service) :
Sert à gérer des associations dynamiques (appartenance,
inclusion, référence, auteur, etc.) reliant des objets sur le BUS.
CORBA
Le langage IDL
Externalisation (Externalization Service) :
Mécanisme standard pour fixer ou extraire des objets du bus.
Persistance (Persistent Object Service) :
Stocker des objets sur un support persistant.
Quel que soit le support utilisé ce service s’utilise de la même
manière via un « Persistent Object Manager ».
Un objet persistant doit hériter de l’interface « Persistent Object »
et d’un mécanisme d’externalisation.
CORBA
Le langage IDL
Interrogation (Query Service) :
Permet d’interroger les attributs d’un objet.
Repose sur les langages standards d’interrogation (SQL 3 ou
OQL).
L’interface QUERY permet de manipuler les requêtes comme des
objets CORBA.
Les objets résultats sont enregistrés dans une collection.
Collections (Collection Service) :
Permet de manipuler d’une manière uniforme des objets sous la
forme de collections et d’itérateurs.
CORBA
Le langage IDL
Changements (Versionning Service) :
Permet de gérer et de suivre l’évolution des différentes versions
des objets.
Maintient des informations sur les évolutions des interfaces et des
implantations.
Pas encore complètement spécifié officiellement.
CORBA
Le langage IDL
La sécurité
Sécurité (Security Service) :
Permet d’authentifier les clients, de chiffrer et de certifier les
communications.
Minimum = IIOP sur Secure Socket Layer (SSL).
Transactions (Object Transaction Service) :
Assure l’exécution des traitements transactionnels impliquant des
objets distribuées et des bases de données en fournissant les
propriétés ACID (Atomicité, Consistance, Isolation, Durabilité.
Concurrence (Concurrency Service) :
Fournit les mécanismes pour contrôler et ordonnancer les
invocations concurrentes sur les objets.
CORBA
Le langage IDL
Les communications synchrones et asynchrones (1/2)
La coopération des objets CORBA à un mode de communication
client/serveur synchrone.
Il existe des services assurant des communications asynchrones.
Événements (Event Service) :
Permet aux objets de produire des événements asynchrones à
destination d’objets consommateurs au travers de canaux
d’événements.
Les canaux fournissent deux modes de fonctionnement :
mode push : le producteur a l’initiative de la production, le
consommateur est notifié des événements.
mode pull : le consommateur demande explicitement les
événements, le producteur est alors sollicité.
CORBA
Le langage IDL
Les communications synchrones et asynchrones (2/2)
Notification (Notification Service)
Une extension du service précédent :
Les consommateurs sont uniquement notifiés des événements les
intéressant.
Messagerie (CORBA Messaging) :
Modèle de communication asynchrone
Permet de gérer des requêtes persistantes.
Utiles lorsque l’objet appelant et l’objet appelé ne sont pas présents
simultanément sur le bus (mobilité ?).
Cela permet d’avoir des fonctionnalités proches des MOMs
(Message Oriented Middleware).
CORBA
Le langage IDL
Les autres services
Temps (Time Service) :
Fournit des interfaces permettant d’obtenir une horloge globale
sur le bus (Universal Time Object),
Mesurer le temps et de synchroniser les objets.
Licences (Licensing Service) :
Permet de contrôler l’utilisation des objets.
CORBA
Le langage IDL
Les interfaces de domaines
Parallèlement aux services, l’OMG cherche à définir
des canevas d’objets dédiés à des secteurs d’activité
(ou métiers) ou à des besoins applicatifs transverses
à des métiers.
Groupes de travail nommés selon les cas : Working
Groups, Domain Task Forces ou Special Interest
Groups.
CORBA
Le langage IDL
Groupes de travail (1/3)
Business Objects DTF standardise les méthodologies et les
technologies pour la conception d’applications métiers.
Workflow Workgroup travaille sur les outils CORBA pour les
applications de gestion de flux de travail et les activités
coopératives au sein des entreprises.
C4I DSIG fait la promotion de CORBA au sein des organismes et
administrations liés à la défense en jouant un rôle pédagogique.
End User SIG travaille en relation avec les utilisateurs finaux à fin
de déterminer leurs besoins, de connaître leurs expériences.
CORBAmed pour le domaine de la médecine pour permettre
l’interopérabilité entre les acteurs de la santé.
CORBA
Le langage IDL
Life Sciences Research DTF groupe dédié à l’utilisation de
CORBA par les instituts de recherche dans les sciences de la vie.
Electronic Financial Commerce pour les applications de
commerce électronique.
Financial Services DTF domaine de la finance/banque.
Telecom DTF fait la liaison entre le monde CORBA et le monde
des télécommunication.
Internet Platform SIG travaille sur les rapprochements des
technologies CORBA avec les technologies d’Internet.
CORBA
Le langage IDL
Manufacturing DFT tente de combler le fossé entre les
technologies OMG et les besoins des industries.
Realtime SIG réfléchit sur la prise en compte des aspects temps
réel au sein du bus CORBA.
Distributed Simulation SIG adresse les problèmes liés à la
simulation distribuée et à son exécution sur un bus CORBA.
Test SIG doit définir les méthodologies, les outils, et les
protocoles pour automatiser les tests d’applications réparties
CORBA.
Object Model Working Group travaille sur l’unification des
modèles orientés objet en vue de créer un standard plus
généraliste que celui proposé actuellement par CORBA.
UML Revision Task Force travaille sur le langage UML
standardisé par l’OMG (http ://www.omg.org/uml/).
CORBA
Le langage IDL
La notion de contrat
Exemple
Constructions IDL
Limites d’IDL
Projection IDL vers un langage de programmation
Le langage IDL
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
La notion de contrat (1/3)
Le langage OMG-IDL (Interface Definition Language) :
Permet d’exprimer sous la forme de contrats IDL la coopération
entre les fournisseurs et les utilisateurs de services.
Sépare l’interface de l’implantation des objets.
Masque les divers problèmes liés à l’interopérabilité dont
l’hétérogénéité des langages.
Un contrat IDL spécifie les types manipulés pour un ensemble
d’applications réparties :
Les types d’objets (ou interfaces IDL).
Les types de données échangées entre les objets.
Le contrat IDL :
Isole les clients et fournisseurs de l’infrastructure logicielle et
matérielle.
Les met en relation à travers le bus CORBA.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Les contrats IDL sont projetés :
En souches IDL (ou interface d’invocations statiques SII) dans
l’environnement de programmation du client.
En squelettes IDL (ou interface de squelettes statiques SSI) dans
l’environnement de programmation du fournisseur.
Le client invoque localement les souches pour accéder aux
objets.
Les souches construisent des requêtes :
qui vont être transportées par le bus,
puis délivrées par celui-ci aux squelettes qui les délégueront aux
objets.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Client
Contrat
IDL
Souche
Bus CORBA
Serveur
Squelette
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Exemple (1/3)
#pragma prefix "univ-lehavre.fr"
module date {
typedef short Annee;
typedef sequence<Annee> DesAnnees;
enum Mois {
Janvier, Fevrier, Mars, Avril, Mai, Juin,
Juillet, Aout, Septembre, Octobre, Novembre, Decembre
};
typedef sequence<Mois> DesMois;
enum JourDansLaSemaine {
Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche
};
typedef sequence<JourDansLaSemaine> DesJoursDansLaSemaine;
typedef unsigned short Jour;
typedef sequence<Jour> DesJours;
struct Date { Jour le_jour; Mois le_mois; Annee l_annee; };
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Exemple (2/3)
typedef sequence<Date> DesDates;
union DateMultiFormat
switch(unsigned short) {
case 0: string chaine;
case 1: Jour nombreDeJours;
default: Date date;
};
typedef sequence<DateMultiFormat> DesDateMultiFormats;
exception ErreurInterne {};
exception MauvaiseDate { DateMultiFormat date; };
interface Traitement {
boolean verifierDate(in Date d);
JourDansLaSemaine calculerJourDansLaSemaine(in Date d)
raises(ErreurInterne, MauvaiseDate);
long nbJoursEntreDeuxDates(in Date d1, in Date d2)
raises(MauvaiseDate);
void dateSuivante (inout Date d, in Jour nombreJours)
};
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Exemple (3/3)
interface Convertisseur {
Jour convertirDateVersJourDansAnnee(in Date d)
Date convertirChaineVersDate(in string chaine)
string convertirDateVersChaine(in Date d)
attribute Annee annee_courante;
// Fixer l’année courante pour l’opération suivante.
Date convertirJourDansAnneeVersDate(in Jour jour);
readonly attribute Annee base_annee ;
// L’année de référence pour les opérations suivantes.
Date convertirJourVersDate(in Jour jour);
Jour convertirDateVersJour(in Date d)
void obtenirDate (in DateMultiFormat dmf, out Date d)
};
interface ServiceDate~: Traitement, Convertisseur { };
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Bilan sur l’exemple
Le langage IDL permet :
d’exprimer simplement les types de données et d’objets
manipulés par un service CORBA,
indépendamment de tout aspect d’implantation (langages,
systèmes d’exploitation, machines et réseaux) et/ou de répartition.
Le choix des identificateurs de ces types est déterminant pour
une lecture aisée d’une spécification IDL.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Constructions IDL (1/7)
Un pragma permet de fixer les identifiants désignant les
définitions IDL à l’intérieur du référentiel des interfaces.
Les identifiants assurent une désignation unique des définitions
IDL quel que soit le référentiel des interfaces consulté.
Ils sont utilisés pour fédérer des IFR.
La forme la plus utilisée est le pragma prefix qui fixe
l’organisation définissant un contrat IDL en utilisant son nom de
domaine Internet.
Le pragma version permet de définir le numéro de version d’une
spécification IDL.
Un module sert à regrouper des définitions de types qui ont un
intérêt commun.
Permet aussi de limiter les conflits de noms pouvant intervenir
entre plusieurs spécifications.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Les conflits de nom de module sont réglés par le pragma prefix.
Les types de données de base sont :
void, short, unsigned short, long, unsigned long,
long long (64 bits), unsigned long long, float, double,
long double (128 bits), boolean, octet, char, string,
wchar et wstring (format de caractères international) et fixed
pour les nombres à précision fixe.
Le format binaire de ces types est défini par la norme afin de
régler les problèmes d’échanges de données entre
environnements hétérogènes.
Les types de méta-données (TypeCode et any) sont une
composante spécifique à IDL :
Le type TypeCode permet de stocker la description de n’importe
quel type IDL.
Le type any permet de stocker une valeur IDL de n’importe quel
type en conservant son TypeCode.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Ces méta-types permettent de spécifier des contrats IDL
génériques indépendants des types de données manipulés,
Par exemple une pile d’any stocke n’importe quelle valeur.
Une constante se définit par un type simple, un nom et une valeur
évaluable à la compilation
const double PI = 3.1415 ;
Un alias (typedef) permet de créer de nouveaux types :
Par exemple, il est plus clair de spécifier qu’une opération
retourne un Jour plutôt qu’un entier signé.
Une énumération (enum) définit un type discret via un ensemble
d’identificateurs.
Par exemple : énumérer les jours de la semaine plutôt que
d’utiliser un entier.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Une structure (struct) définit une organisation regroupant des
champs :
Cette construction est fortement employée car elle permet de
transférer des structures de données composées entre objets
CORBA.
Une union juxtapose un ensemble de champs, le choix étant
arbitré par un discriminant de type simple (entier, caractère,
booléen ou énumération).
Un tableau (array) sert à transmettre un ensemble de taille fixe
de données homogènes.
Une séquence permet de stocker/transférer un ensemble de
données homogènes dont la taille sera fixée à l’exécution.
Une exception spécifie une structure de données permettant à
une opération :
de signaler les cas d’erreurs ou de problèmes exceptionnels
pouvant survenir lors de son invocation.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Une interface décrit les opérations fournies par un type d’objet
CORBA (Traitement et Convertisseur).
Une interface IDL peut hériter de plusieurs autres interfaces
(ServiceDate).
L’héritage multiple est autorisé :
On parle d’héritage de spécifications.
La seule contrainte imposée est qu’une interface ne peut pas
hériter de deux interfaces qui définissent des opérations de
mêmes noms.
Ce problème doit être résolu manuellement en évitant/éliminant
les conflits de noms.
La surcharge est donc interdite en IDL.
Un objet CORBA ne peut implanter qu’une seule interface IDL.
CORBA 3.0 doit intégrer la notion d’interfaces multiples (Java,
COM).
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Une opération se définit par :
Une signature qui comprend le type du résultat, le nom de
l’opération, la liste des paramètres et la liste des exceptions.
Un paramètre se caractérise par un mode de passage, un type et
un nom formel :
Les modes de passages autorisés sont in, out et inout.
Le résultat et les paramètres peuvent être de n’importe quel type
exprimable en IDL.
Par défaut, l’invocation d’une opération est synchrone,
cependant,
il est possible de spécifier qu’une opération est asynchrone
(oneway),
le résultat est de type void,
tous les paramètres sont en mode in,
aucune exception ne peut être déclenchée.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
CORBA ne spécifie pas complètement l’opération oneway :
l’invocation peut échouer, être exécutée plusieurs fois sans que
l’appelant ou l’appelé en soient informés.
Un attribut exprime une paire d’opérations pour consulter et
modifier une propriété d’un objet :
Il se caractérise par un type et un nom.
On peut spécifier si l’attribut est en lecture seule (readonly) ou
consultation/modification (mode par défaut).
Le terme IDL attribut est trompeur, l’implantation d’un attribut IDL
peut être faite par un traitement quelconque.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Les limites d’IDL (1/2)
Types limités en nombre :
L’utilisateur ne peut pas en ajouter facilement.
L’OMG ne s’interdit pas d’introduire de nouveaux types au fur et à
mesure des besoins :
Les entiers 64 bits, les réels 128 bits, les caractères
internationaux (Unicode) n’étaient pas présents dans les
premières versions de la norme CORBA.
L’impossibilité de spécifier des types intervalles (pratique pour
exprimer des intervalles de temps).
L’impossibilité de sous-typer (d’étendre) la définition d’une
structure ou d’une union.
L’interdiction de conflits de noms à l’intérieur d’un module ou
d’une interface :
implique l’interdiction de surcharger des opérations.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Les limites d’IDL (2/2)
Le passage par valeur de structures de données et non d’objets :
Si l’on veut transférer un graphe d’objets, il faut l’aplatir dans une
séquence de structures (évolutions de CORBA 3.0).
Le langage OMG-IDL ne sert pas à exprimer la sémantique des
objets :
Comme des contraintes, des pré et post conditions sur les
opérations.
Des invariants.
L’expression de la sémantique permettrait :
De tester et valider automatiquement les objets.
De décrire la qualité de service, c’est-à-dire les caractéristiques
d’une implantation.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Projection IDL vers un langage de programmation (1/2)
Projection (mapping, correspondance) est la traduction d’une
spécification IDL dans un langage d’implantation.
Pour permettre la portabilité des applications d’un bus vers un
autre :
les règles de projection sont normalisées,
elles fixent précisément la traduction de chaque construction IDL
en une ou plusieurs constructions du langage cible,
ces règles existent pour les langages C, C++, SmallTalk, Ada,
Java et Cobol orienté objet.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Projection IDL vers un langage de programmation (2/2)
Réalisation de la projection :
La projection est réalisée par un pré-compilateur IDL dépendant
du langage cible et de l’implantation du bus CORBA :
chaque produit CORBA fournit un pré-compilateur IDL pour chacun
des langages supportés.
Le code des applications est alors portable d’un bus à un autre :
Les souches/squelettes générés s’utilisent toujours de la même
manière quel que soit le produit CORBA.
Par contre, le code des souches et des squelettes IDL n’est pas
forcément portable :
il dépend de l’implantation du bus pour lequel ils ont été généré.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Étapes (1/3)
1
Définition du contrat IDL :
définir les objets composants l’application à l’aide d’une
méthodologie orientée objet.
cette modélisation est ensuite traduite sous la forme de contrats
IDL.
2
Pré-compilation du contrat IDL :
les interfaces des objets sont décrites dans des fichiers textes,
le pré-compilateur prend en entrée un tel fichier et opère un
contrôle des définitions IDL,
le pré-compilateur peut aussi charger ces définitions dans le
référentiel des interfaces.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Étapes (2/3)
3
Projection vers les langages de programmation :
le pré-compilateur IDL génère :
le code des souches qui sera utilisé par les applications clientes
des interfaces décrites dans le fichier IDL,
le code des squelettes pour les programmes serveurs implantant
ces types.
4
Implantation des interfaces IDL :
en complétant et/ou en réutilisant le code généré pour les
squelettes, le développeur implante les objets.
5
Implantation des serveurs d’objets :
Le développeur écrit les programmes serveurs qui incluent
l’implantation des objets et les squelettes prégénérés.
Ces programmes contiennent le code pour :
se connecter au bus, instancier les objets racines du serveur,
rendre publiques les références sur ces objets à l’aide par exemple
du service Nommage,
se mettre en attente de requêtes pour ces objets.
Le nombre de programmes serveurs est souvent limité.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Étapes (3/3)
6
Implantation des applications clientes des objets :
Le développeur écrit un ensemble de programmes clients qui
agissent sur les objets.
Ces programmes incluent le code des souches, le code pour l’IHM
et le code spécifique à l’application.
Les clients obtiennent les références des objets serveurs en
consultant le service Nommage.
7
Installation et la configuration des serveurs :
Cette phase consiste à installer dans le référentiel des
implantations les serveurs pour automatiser leur activation lorsque
des requêtes arrivent pour leurs objets.
8
Diffusion et la configuration des clients.
9
Exécution répartie de l’application.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Conclusion
L’interopérabilité entre langages, systèmes d’exploitation,
machines et réseaux.
La portabilité du code : les fragments de code présentés sont
totalement portables d’une implantation du bus à une autre.
Encapsulation de l’existant :
La réutilisation de codes existants (voire même d’applications
complètes) peut être réalisée par encapsulation de ceux-ci dans
des objets CORBA.
Ces objets sont alors utilisables pour bâtir de nouvelles
applications.
CORBA
Le langage IDL
Exemple
Constructions IDL
Limites d’IDL
Perspectives
CORBA 1.0 avait pour objectif l’interopérabilité entre objets
distribués.
CORBA 2.0 avait donc comme objectif principal d’offrir cette
interopérabilité via le protocole GIOP et IIOP.
CORBA 3.0 :
Multiples Interfaces and Composition fournira les mécanismes
permettant à un objet CORBA d’implanter plusieurs interfaces IDL.
Messaging Service définit un nouveau modèle de communication
asynchrone lorsque l’objet appelant et l’objet appelé ne sont pas
présents simultanément sur le bus (via des requêtes persistantes).
Persistent State Service 2.0 sera une spécification simplifiée du
service Persistance.
CORBA Component Model définira un modèle de composants
pour le monde CORBA en s’inspirant par exemple du modèle
JavaBeans.
CORBA
Le langage IDL
CORBA
Le langage IDL
Le programme HelloWorld sans Naming Service (1/6)
Création du fichier IDL :
// Hello.idl
interface Hello {
void sayHello();
};
Compilation/Projection idlj -fallTIE Hello.idl
CORBA
Le langage IDL
Implémentation de l’objet distribué :
// Hello_impl.java
package hello;
public class Hello_impl extends HelloPOA {
public void sayHello (){
System.out.println ("Bonjour le monde !");
}
}
CORBA
Le langage IDL
Implémentation du serveur :
// HelloServer.java
package hello;
public class HelloServer{
public static void main (String args[]){
java.util.Properties props = System.getProperties ();
//props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
//props.put ("org.omg.CORBA.ORBSingletonClass", "com.ooc.CORBA.ORBSingleton");
int status = 0;
org.omg.CORBA.ORB orb = null;
try{
orb = org.omg.CORBA.ORB.init (args,props);
status = run (orb);
}
catch (Exception ex){
ex.printStackTrace ();
status = 1;
}
System.exit (status);
}
CORBA
Le langage IDL
Implémentation du serveur (suite) :
static int run(org.omg.CORBA.ORB orb)
throws org.omg.CORBA.UserException {
org.omg.PortableServer.POA rootPOA = org.omg.PortableServer.POAHelper.narrow(orb.resolve_initia
org.omg.PortableServer.POAManager manager = rootPOA.the_POAManager();
Hello_impl helloImpl = new Hello_impl();
Hello hello = helloImpl._this(orb);
try {
String ref = orb.object_to_string(hello);
String refFile = "Hello.ref";
java.io.PrintWriter out = new java.io.PrintWriter(new java.io.FileOutputStream(refFile));
out.println(ref);
out.close();
}
catch(java.io.IOException ex){
ex.printStackTrace();
return 1;
}
manager.activate();
orb.run();
return 0;
}
}
CORBA
Le langage IDL
Implémentation du client :
// HelloClient.java
package hello;
public class HelloClient {
public static void main(String args[]) {
java.util.Properties props = System.getProperties ();
//props.put ("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
//props.put ("org.omg.CORBA.ORBSingletonClass", "com.ooc.CORBA.ORBSingleton");
int status = 0;
org.omg.CORBA.ORB orb = null;
try{
orb = org.omg.CORBA.ORB.init (args,props);
status = run (orb);
}
catch (Exception ex){
ex.printStackTrace ();
status = 1;
}
System.exit (status);
}
CORBA
Le langage IDL
Implémentation du client (suite) :
static int run(org.omg.CORBA.ORB orb) {
org.omg.CORBA.Object obj = null;
try {
String refFile = "Hello.ref";
java.io.BufferedReader in = new java.io.BufferedReader(new java.io.FileReader(refFile));
String ref = in.readLine();
obj = orb.string_to_object(ref);
}
catch(java.io.IOException ex) {
ex.printStackTrace();
return 1;
}
Hello hello = HelloHelper.narrow(obj);
hello.sayHello();
return 0;
}
}
CORBA
Le langage IDL
Le programme HelloWorld avec Naming Service
Génération du code : idlj -fallTIE -oldImplBase
Hello.idl.
Télécharger le client et le serveur (version avec Naming Service).
Compiler le tout : javac *.java.
Pour tester :
1
Lancer orbd.
2
Lancer java HelloServer.
3
Lancer java HelloClient.
CORBA
Le langage IDL
Utilisation d’un ORB :
ORBacus 4.1.3
CORBA
Le langage IDL
Installation (1/2)
Télécharger les sources à l’adresse :
http ://litis.univ-lehavre.fr/∼duvallet/enseignements-LPRO-DA2I-fr.php#LPRODA2I
Créer un répertoire /usr/local/ORBacus dans lequel vous
décompresserez les sources précédemment téléchargées.
Compilation de la partie C++ et des utilitaires de projection :
1
Placer vous dans le répertoire /usr/local/ORBacus/OB-4.1.3.
2
Lancer l’utilitaire ./runconfig (seul le compilateur doit être
3
4
5
changé pour correspondre à votre version de gcc, la plupart du
temps la version 3.x ou au delà).
Faire un make puis un make install
Si nécessaire ajouter la ligne export PATH=$PATH :/usr/local/bin
Ajouter la ligne /usr/local/lib dans le fichier
/etc/ld.so.conf puis exécuter la commande ldconfig.
CORBA
Le langage IDL
Installation (2/2)
Compilation de la partie JAVA :
1
Placer vous dans le répertoire
/usr/local/ORBacus/JOB-4.1.3.
Faire un make puis un make install
Lancement du naming service :
1
Créer un fichier de configuration ORBacus.conf.
2
Exécuter la commande nameserv -ORBconfig ORBacus.conf
2
CORBA
Le langage IDL
Utilisation du Naming Service
#Fichier ORBacus.conf
#modeles de concurrence
ooc.orb.conc_model=threaded
ooc.orb.oa.conc_model=thread_pool
ooc.orb.oa.thread_pool=5
#Initialisation de services
ooc.service.NameService=corbaloc::localhost:5000/NameService
ooc.service.EventService=corbaloc::localhost:5001/DefaultEventChannel
ooc.service.TradingService=corbaloc::localhost:5002/TradingService

UF8 - Gestion et intégration des systèmes d`information

Transcription

Documents pareils

Le cours - LITIS - Université du Havre

Systèmes répartis : CORBA

atelier 20 atelier 20 - par Jacques LAFORGUE

Aurélien BARO

Télécharger notre plaquette de présentation

Le standard CORBA

«La courbe de tes yeux», de Paul Éluard PDF descarregat de www

client serveur pragma