1. Introduction
2. Architecture
Le bus logiciel CORBA
3. Langage IDL
4. Développement Java
Lionel Seinturier
5. Développement C/C++
Université Pierre & Marie Curie 6. Services
7. Concepts avancés
8. Le futur de CORBA
9. Bibliographie
2.2 Modèle OMA • Groupe de vendeurs de matériel, de système, d’applications, de conseils, ...
• ≈ 700 membres (Sunsoft, HP, Compag, IBM, Iona, Alcatel, ...)
2.3 Vue générale de CORBA • Produit des spécifications
2.4 Côté client • OMA (Object Management Architecture)
architecture générale pour la gestion d’objets distribués
2.5 Côté serveur
• CORBA
2.6 Référence d’objet un des composants de l’OMA
permet aux objets distribués de communiquer
2.7 Adapteur d’objet
1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000
2.8 Protocole d’invocation de méthodes
11 membres 390 Définition des services
2.9 Fournisseurs d’ORBs CORBA 1.1 membres
OMA v1 200 membres CORBA 2.0 2.2 CORBA2.3 3.0 ?
• «frameworks» logiciels de plus hauts niveaux que les services • «frameworks» logiciels de plus hauts niveaux que les services
• indépendantes du domaine d’applications • spécialisées pour un domaine d’applications particulier
• également appelées facilités horizontales • également appelées facilités verticales
• 4 facilités • 8 interfaces de domaine
Smalltalk
ref IDL
Cobol
Cobol
C++
Java
Java
Ada
Ada
C
Squelette Squelette
Interface IDL statique dynamique
Souche Souche
statique dynamique Primitives Adaptateur d’objets
Souche Squelette de l’ORB
Noyau de l’ORB
Object Request Broker (ORB)
Référentiel Référentiel
Vocabulaire : souche, squelette, talon sont ici synonymes d’interfaces d’implantation
Ö entités qui préparent et gèrent les appels entre clients et serveurs
Squelette
Serveur Squelette statique Serveur
• symétrique de la souche
• décode les paramètres d’entrée des invocations • un par type d’objet serveur invoquable
Squelette Squelette Squelette Squelette
• prépare les paramètres de sortie et le résultat statique dynamique
• identique aux souches serveurs RPC statique dynamique
Adaptateur d’objets
• généré à la compilation à partir de l’interface IDL Adaptateur d’objets
• le plus simple
IDL:monObjet:1.0 milo.jussieu.fr:1805 OA7, obj_979 • propose 4 modes d’activation des objets
IOR:000000000000001c49444c3a43616c63756c6174726963652f43616c63756c3a312e30000000000300000000000000330001000000
00000e3133322e3232372e36342e3430000b4e00000017383135313337313834312f00114d4d4d4d4d0e4d390d23000000000000000038
000101000000000e3133322e3232372e36342e3430000b4e00000017383135313337313834312f00114d4d4d4d4d0e4d390d2300000000
00000000010000002c0000000000000001000000010000001c00000000050100010000000100010001000101090000000105010001
BOA avec serveur par méthode BOA avec serveur persistant Rq: 3 n’est pas disponible avec un talon statique
O1 O2 O3 O1 O2 O3
Sémantique
Ordonnanceur
1 et 3 : «au plus une fois»
2 : «au mieux» (la réception du message n’est pas garantie)
BOA BOA
• GIOP nécessite un protocole de transport fiable, orienté connexion De nombreux autres sont disponibles
• IIOP (Internet IOP) : implantation de GIOP au-dessus de TCP
voir www.vex.net/~ben/corba/
• Autres implantations de GIOP au-dessus de HTTP, RPC DCE, RPC Sun
ou www.cetus-links.org à la rubrique CORBA
• Associé à un format de d’encodage des données (CDR)
module mesAnimaux {
...
Exemple
module alaVille { ... };
module alaCampagne { ... }; interface Carre : Parallelepipede { ... };
...
}; interface A; // prédéclarée (le compilateur «sait» que
// l’ident. A est associé à une interface
interface B { ... }; // utilise A
Toutes les définitions d’un module sont «visibles» grace à l’opérateur interface A { ... }; // utilise B
de résolution de portée ::
Ex : mesAnimaux::alaVille::...
• Pas de code • Modes de passage de paramètres 4.4 Interfaces (traduction IDL vers Java)
• Pas de pointeur • Sémantique d’appel oneway
• Pas de constructeur • Attributs readonly
4.5 Implantation des interfaces
• Pas de destructeur • Type sequence 4.6 Programme serveur
• Pas de surcharge • Unions nécessitent un discriminant
d’opérations 4.7 Programme client
• Pas de polymorphisme
• ensemble d’objets serveurs remplissant des fonctions courantes • ≡ à un annuaire (pages blanches), DNS, ...
• chaque service est défini par une ou +sieurs interfaces IDL • organisé de façon hiérarchique ( ≡ hiérarchie de fichiers)
• 15 services actuellement
• chaque répertoire est appelé un «contexte de nommage»
• l’opération d’enregistrement d’un objet : une «liaison»
• l’opération de recherche d’un objet : «résolution» de nom
Object Request Broker (ORB)
root
module CosNaming {
interface NamingContext {
void bind( in Name n, in Object o ); // enregistre un nom
void bind_context( in Name n, // enregistre un contexte
in NamingContext nc );
void unbind( in Name n ); // supprime un nom
Object resolve( in Name n ); // résoud un nom
void list( out BindingList bl ); // liste des noms, ctx RootContext : la racine du serveur de nom
} }
Name : le nom de l’objet
La norme prévoit que l’on puisse (en pratique ??) : Kind : une chaîne précisant le «type» de service fournit par l’objet
• fédérer les services de nommage Type : l’interface IDL implantée par l’objet
• les faire intéropérer avec d’autres annuaires (DNS, DCE CDS, OSI X500, NIS+) Host : l’adresse IP et le port servant des requêtes pour l’objet
push pull
Rq : le service de courtage est souvent utilisé conjointement au DII prod. cons. prod. cons.
info. info.
commit
Rq : peu d’ORBs offrent tous ces services
banque A banque B
7.3 Intercepteurs
Les interfaces sont stockées dans le référentiel d’interfaces
7.4 Adaptateur d’objet portable (POA) • base de données des interfaces des serveurs
• une par environnement (groupement logique de machines)
• possibilité de fédérer les référentiels de ≠ environnements
ConstantDef ParameterDef InterfaceDef OperationDef _get_interface interroge le référentiel pour retrouver le descr. de l’interface
invoke est bloquante tant que le résultat n’est pas disponible
• Fournit un squelette générique pour les objets serveurs dont on ne connaît pas • Mécanisme permettant d’intercepter et de modifier les communications
l’interface au moment de la compilation • 2 niveaux d’interceptions : requête et message
• Equivalent côté serveur du DII • Permet d’implanter de façon transparente : filtrage, sécurité, audit, ...
Idée du fonctionnement
Squelette Squelette
• on implante une classe et une méthode qui aiguille les appels entrants
statique dynamique
• cette méthode travaille sur des objets request identiques à ceux du DII Souche Souche
statique dynamique Intercepteur requêtes
Avantages Inconvénients
Intercepteur requêtes Adaptateur d’objets
• plus flexible • plus difficile à manipuler
• interface langages de script (Perl, ...) • pas de vérification de type Intercepteur messages Intercepteur messages
• ponts génériques entre ORB et • plus lent Noyau de l’ORB
autres systèmes (DCE, DCOM, ...)
• Permet d’intercepter les requêtes (appels de méthodes) • Permet d’intercepter les messages IIOP échangés par l’ORB
• Les requêtes sont manipulées comme des requêtes DII • Une requête ne correspond pas nécessairement à un seul message
• On peut ajouter des pré et post actions à la requête • Ne s’appliquent qu’aux invocations distantes
• On peut changer le destinataire de la requête
• Peuvent s’appliquer aux invocations locales et distantes
Interface de l’intercepteur de messages
Depuis CORBA 2.2, le POA remplace le BOA Passage d’objet par valeur
• référence d’objet persistante • permettre le passage d’objets par valeur plutôt que par référence
• meilleure gestion des threads
• +sieurs références possibles pour le même objet ¾ RFP Tolérance aux fautes
• activation implicite des serveurs à partir du référentiel d’implantation ¾ RFP Temps réel
• possibilité d’avoir +sieurs POA dans un même espace d’adressage
• meilleure intégration avec le service de persistance
• J.M. Geib, C. Gransart, P. Merle, CORBA: des concepts à la pratique, InterEditions, 1997
• R. Orfali, D. Harkey, J. Edwards, Instant CORBA, Wiley, 1996
• J. Siegel, CORBA Fundamentals and Programming, Wiley, 1996
• T. Mowbray, R. Zahavi, The Essential CORBA, Wiley, 1995