Chapitre 2 : CORBA
Guillaume Latu
Octobre 2003
Département d'informatique
UFR de Mathématique et Informatique
Université Louis Pasteur – Strasbourg
3.
Réalisation d’une application
3.2 Exemple de code minimal
CORBA en java
3.3 Compilation et Déploiement
4.2 Activation et Adaptateur
d’Objets
8.
Modèle utilisant le POA et un système de délégation
9.
Construction et utilisation dynamiques d’interfaces IDL
10.
Les blocs fonctionnels de CORBA
======================================== CORBA –
Partie I ========================================
Interopérabilité : capacité d’un programme écrit dans un
certain langage à utiliser un programme dans un autre langage.
Problème
récurrent en informatique, par exemple dans les cas suivants :
-
L’interconnexion de systèmes informatiques hétérogènes
-
La réalisation de services web à partir d’applications existantes
-
L’utilisation de plusieurs langages de programmation pour résoudre
différents aspects d’un certain problème
On
souhaiterait :
-
hétérogénéité au niveau des matériels et systèmes
-
Intégrer l’existant produit dans l’entreprise
-
Interopérabilité entre systèmes de différentes entreprises
Ø
Normes communes, standardisation
On
a :
-
Mécanismes de communication de bas niveau
-
Les RPC ne résolvent pas tous les problèmes (intégration,
interopérabilité)
On
va utiliser des plates-formes réparties (middleware) ou intergiciels qui
offrent :
-
L’indépendance entre l’application et le système. Les couches de
communication sont cachées à l’utilisateur, ainsi que les aspects spécifiques
au système. La plate-forme fournie aux applications des interfaces
standardisées.
-
Des services partagés (désignation, localisation, sécurité,
transaction, administration)
Une
plate-forme peut être vue comme un bus « virtuel » qui permet
d’interconnecter plusieurs applications et offre des services
« distribués ».
o
CORBA est un middleware (Common Object Request Broker Architecture).
o
CORBA est issue des travaux de l’OMG (Object Management Group) et est
basé sur la notion d’objet distribué.
o
OMG a proposé une architecture de gestion d’objets repartis OMA (Object
Management Architecture).
o
CORBA utilise des implémentations qui s’appellent des ORB (Object
Request Broker).
o
Le bus virtuel = ORB (il existe des ORB implémentés par plusieurs
entreprises ou équipes).
o
CORBA c’est la spécification du service de communication repartie
orienté objet.
o
Comme RMI : il y a la notion de proxy (représentation locale d’un
objet distant ; il connaît la localisation de l’objet distant et sait
comment communiquer avec lui) et de squelette.
o
CORBA oblige a définir des interfaces (pour les objets distants) avec
le langage IDL (Interface Description Langage). L’interface constitue un
contrat qui permet le développement en toute indépendance, d’un client et d’un
serveur.
Terminologie : un servant c’est un objet qui implémente une
interface IDL.
Déroulement :
i.
Définir le contrat (l’interface IDL) entre le client et le serveur
ii. Projeter l’interface dans
les langages utilisés pour le développement
à génération automatique des classes qui vont
permettre d’interagir avec CORBA.
iii. Implémenter l’interface
à classe de l’objet distant (on hérite d’une
certaine classe définie à l’étape ii)
iv. Développer le serveur
v. Développer le client
vi. Démarrer l’ORB, le service
des noms, le serveur et le client
Remarque : les étapes (iii) et
(iv) se font en parallèle
interface Icarre {
long carre(in long source);
} ;
import
org.omg.CORBA.*;
public class
Icarrelmpl extends _IcarrelmplBase {
public int carre (int
source) {
return source*source;
}
}
import org.omg.CORBA.*;
public class Serveur
{
public static void main(String[] args) {
try {
ORB orb = ORB.init( args, null );
Icarrelmpl myobj = new Icarrelmpl();
String ior = orb.object to_string( myobj );
System.out.println( ior ); orb.run();
}
catch(org.omg.CORBA.SystemException ex ) {
System.err.println( ex );
}
return ;
}
}
import java.io.*;
import
org.omg.CORBA.*;
public class Client {
public static void main( String args[] ) {
int
nombre = 2;
int
res;
try {
ORB orb = ORB.init( args, null );
String ior = args[0];
org.omg.CORBA.Object obj =
orb.string_to_object(args[O]);
Icarre service = IcarreHelper.narrow(obj);
res=service.
carre (nombre);
System.out.println("Res " + res);
}
catch(org.omg.CORBA.SystemException ex ) {
System.err.println( ex );
}
}
}
$ idlj –fall –oldImplBase Icarre.idl
à génération de :
-
Icarre.java (interface en
java)
-
IcarreOperations.java (interface en java)
-
IcarreImplBase.java (squelette)
-
IcarreStub.java (proxy)
-
IcarreHelper.java (pour
lire et ecrire dans un flux (communication client/serveur) et pour
convertir un objet CORBA en type java : cast narrow)
-
IcarreHolder.java
Option de idlj :
-
f <serveur | client | all>
-
oldImplBase (version simplifiée)
$ javac *.java
$ java serveur <IOR> générée
$ java client <IOR>
Remarque :
Une IOR
(Identification Object Request) encode la machine, le port et la
désignation de l’objet distant.
En
IDL : trois modes de passages IN, OUT, INOUT
Les
3 modes de passage ne sont pas disponibles dans tous les langages (en C++ c’est
possible, en java non). Dans les cas où ce n’est pas possible, on utilise des
conteneurs pour des arguments de type OUT, INOUT.
Pour
recevoir une valeur en sortie, le programmeur crée une instance d’une classe
conteneur, et la méthode à distance stocke la valeur de l’objet conteneur.
Les
implantations de CORBA fournissent, pour les types de base des
conteneurs : org.omg.CORBA.IntHolder, org.omg.CORBA.StringHolder, …
Chaque
classe holder contient
-
un champs public « value »
-
un constructeur avec son paramètre (du type convenu)
Les
classes définies à partir d’un fichier IDL à idlj génère un conteneur
pour la classe
< long carre(in long source);
---
> void carre (in long source, out long
resultat); Client.java
< res=service.carre(nombre);
---
> IntHolder resHolder = new IntHolder();
> service.carre(nombre,
resHolder);
> res=resHolder.value;
< public
int carre (int source) {
< return source*source;
---
> public
void carre (int source, IntHolder resultat) {
> resultat.value
= source*source;
Activation : l’activation est une étape qui établie un
lien entre un certain ORB et un objet servant.
Elle
consiste en :
-
l’allocation d’un identificateur
-
la mise en place des structures nécessaires pour rendre l’objet accessible
à distance (squelette)
Auparavant
(dans l’exemple qu’on a vu) on pouvait connecter directement une
implémentation à l’ORB. On utilise un adaptateur portable qui se place entre le
squelette et l’ORB.
But
de l’adaptator :
-
gestion des objets avec définition de politique
-
gestion des références sur les objets
-
utilisation possible de Threads
-
gestionnaire d’une liste d’attente pour les requêtes
-
authentification des clients
< public class Icarrelmpl extends
_IcarrelmplBase {
---
> public class Icarrelmpl extends IcarrePOA {
<
---
> import org.omg.PortableServer.*;
< String ior = orb.object to_string( myobj );
---
> //initialiser
le POA
> POA poa = POAHelper.narrow(
orb.resolve_initial_references( "RootPOA" ));
> poa.the_POAManager().activate();
> org.omg.CORBA.Object poaobj = poa.servant
to_reference( myobj );
> String ior = orb.object to_string( poaobj
);
Supposons que l'on ait une implementation pour un objet de type "Annuaire". Une implementation (accessible a distance avec CORSA) s'appelle "Annuairelmpl". On presente ici le "mainQ" (sans les clauses "try" et "catch") de serveurs et clients qui utilisent cet annuaire accessible a distance.
Serveur 1 (version utilisant directement l'IOR)
//init ORB
ORB orb = ORB.init(
args, null );
Annuairelmpl myobj = new
Annuairelmpl ();
//initialiser le POA
POA poa =
POAHelper.narrow( orb.resolve_initial_references( "RootPOA" ));
poa.the
POAManager().activateo
org.omg.CORBA.Object
poaobj = poa.servant to_reference( myobj );
String ior =
orb.object to string( poaobj );
System.out.println(ior);
orb.run();
Client
1 (version utilisant directement l'IOR)
ORB orb =
ORB.init(new String[O], null ); ior = args[2];
org.omg.CORBA.Object
obj = orb.string_to object(ior);
annuaire =
AnnuaireHelper.narrow(obj);
annuaire.ajouteNom(args[0],args[1]);
========================================
CORBA – Partie II ========================================
Référence d’objet IOR : opération fastidieuse de gestion des IOR, surtout lorsqu’il y a
beaucoup d’objets distants.
- Services de nommage pour
stocker des associations : chaines de caractères à référence d’objet
- Services d’utilité générale : ils en existent beaucoup en CORBA mais l’un de plus important est ²l’annuaire². Un serveur va pouvoir enregistrer une association dans l’annuaire et le client la consulter
(²nom_obj_distant²,ref_obj_distant) à ref_obj_distant est en fait l’IOR
- Il existe un module
CosNaming qui est entièrement défini en langage IDL
(import org.omg.CORBA.CosNaming ;)
- La forme syntaxique des noms manipulés par l’annuaire : il existe une arborescence au sein de l’annuaire.
Ex : /serveurdenom/context1/context2/objetDistant1
à serveurdenom = annuaire
à context1 = repertoire
Chaque contexte (nœud ou
répertoire) peut avoir deux parties dans son nom :
à identité,type (optionnel)
Le service de nommage peut
être distribué entre plusieurs sites même si la racine est sur une certaine
machine.
Utilisation :
Lançons l’annuaire (et même
plus) :
orbd –ORBInitialPort 1050 &
i.
Le serveur obtient une référence sur le contexte de nommage ²Name Service² en contactant la machine qui a lancé ²orbd²
ii. Le serveur créé un chemin
dans l’arborescence qui est de type NameComponent[]
Optionnel : création de contexte (nœud de l’arbre) en utilisant
bindContext ou rebindContext
iii. Le serveur invoque bind ou
rebind depuis le contexte courant pour créer une association entre un nom et
une référence sur un objet (²/first.Context/Iecho.nomservice/² à poaobj)
iv. Le client obtient une
référence sur ²Name Service²
v. Le client un chemin dans
l’arborescence (des contextes)
vi. Le client invoque
l’opération résolve pour récupérer la référence de l’objet distant
vii. Le retour de cette opération
créée localement le proxy pour contacter l’objet distant
----
viii. Eventuellement le client ou
le serveur peuvent désinscrire l’objet au sein du service de nommage -> ²unbind² au niveau du contexte où l’objet était inscrit.
Pour une utilisation
simplifiée de recherche dans l’annuaire pour le client, voir exemple 2b (URL de
type corbaname)
Serveur 2
(version utilisant le service de nommage)
//init ORB
String [] argv = { "-ORBInitialHost",
"localhost", "-ORBInitialPort", "1050" };
ORB orb = ORB.init( argv, null );
Annuairelmpl myobj = new Annuairelmpl ();
//initialiser
le POA
POA poa = POAHelper.narrow(
orb.resolve_initial_references( "RootPOA" ));
poa.the POAManagerO.activateO);
org.omg.CORBA.Object poaobj = poa.servant
to_reference( myobj );
//
trouver le service de nom
org.omg.CORBA.Object
nameServ =
orb.resolve_initial _references("NameService");
org.omg.CosNaming.NamingContextExt rootContext =
org.omg.CosNaming.NamingContextExtHelper.narrow(nameServ);
//
creer un premier contexte
NameComponent[] contextName = new NameComponent[1];
contextName[0] = new
NameComponent("fust","context");
NamingContext contextl = rootContext.new_context(( ;
rootContext.rebind context(contextName,contextl);
NamingContextExt firstsubContext=
NamingContextExtHelper.narrow(contextl);
//
creer un objet dans le contexte
NameComponent[] objectName = new NameComponent[l];
objectName [0] = new NameComponent ("Iecho",
"mon-service") ;
firstsubContext.rebind( objectName , poaobj);
orb.run();
Client 2a
(version utilisant le service de nommage)
String [] argv = { "-ORBlnitialHost",
"localhost", "-ORBlnitialPort", " 1050" } ;
ORB orb = ORB.init(argv, null );
//
trouver le service de nom org.omg.CORBA.Object nameServ =
orb.resolve_initial_references("NameService");
org.omg.CosNaming.NamingContextExt rootContext =
org.omg.CosNaming.NamingContextExtHelper.narrow(nameServ);
//
creer le chemin jusqu'a l'objet
NameComponent[]
contextName = new NameComponent[2];
contextName [0] = new NameComponent
("first" "context") ;
contextName[1]
= new NameComponent("Iecho","mon_service");
String
message = "designation de l'objet : "+rootContext.to_string(contextName);
System.out.println(message);
//
recuperer la reference sur l'objet distant org.omg.CORBA.Object
obj=rootContext.resolve(contextName);
annuaire = AnnuaireHelper.narrow(obj);
annuaire.ajouteNom(args10],args[1]);
ORB orb = ORB.init(new String[0], null );
String reference =
"corbaname::localhost:1050#first.contexUiecho.mon service" ;
org.omg.CORBA.Object obj = orb.string_to_object(reference);
annuaire = AnnuaireHelper.narrow(obj);
annuaire.ajouteNom(args[0],ergs[1]);
En IDL, on va décrire au sein d’une interface la liste
des opérations (méthodes) offertes pour un objet accessible à distance.
o
Une interface IDL est une énumération d’opérations et de définitions de
types ; elle supporte l’héritage multiple.
Ex :
interface
UneInterface : UneInterfaceMere,SecondeIMere {
boolean affiche(in string chaine) ;
} ;
o
Les types de base : boolean, char, octet, short, long , longlong,
double, long double, string
java : long = int = 16 bits
o
La description d’un paramètre de méthode 3 parties :
·
La modification (in, out, inout)
·
Le type
·
Le nom de l’argument
o
Il est possible de définir des attributs d’interfaces : un
attribut est une donée accessible en lecture [readonly] ou lecture/écriture
Ex :
interface
x {
attribute
string nom ;
readonly
attribute long key ;
} ;
public void nom( String value) ;
public String(nom) ;
o
Module à en java donne un package
module : nomModule {
…. des interfaces
…. des définitions
} ;
Une
interface dans un module donnera en Java une classe dont le nom sera :
nomModule.nomInterface
o
L’alias : typedef (comme en C)
Ex : typedef nom_type nom_alias
o
La séquence, le tableau : sequence<type,borne_max> ou
sequence <type>
Ex : typedef
sequence<string,10> dixmots ;
o
Structure
structure nomStructure {
type nomDuMembre ;
} ;
Ex : struct personne { // plongés en Java par une classe
String nom ;
String prenom ;
} ;
Serveur 3 Persitant (le code suivant est a incorporer a celui de
Serveur 2)
Policy[] persistentPolicy = new
Policy[l]; persistentPolicy[0] =
poa.create_lifespan_policy(LifespanPolicyValue.PERSISTENT);
POA persistentPOA = poa.create_POA("childPOA", null,
persistentPolicy );
persistentPOA.the_POAManager)( .activate( );
persistentPOA.activate
object( myobj );
======================================= CORBA – Partie
III =======================================
Certains clients n’ont pas
explicitement besoin d’invoquer des méthodes sur un objet distant. Ces clients
ont besoins d’être prévenus par le serveur d’un évènement ou de données qui
sont disponibles.
Un premier exemple
Le serveur gère un stock d’un
certain matériel. Le client veut être informé d’une modification du stock sur
le serveur.
Un autre exemple :
le serveur de discussion
Le serveur possède un certain
nombre de clients inscrits à ses services. Lorsqu’un client émet un message
vers le serveur, il répercute ce message sur tous les clients.
Première phase d’inscription |
|
Seconde phase : diffusion de
message |
|
Problème
: Le serveur, a la fin, appelle
orb.run()
La dernière instruction du client
est orb.run() avec le mécanisme de callback :
- Appeler
des méthodes sur des évènements qui se reproduisent au clavier (Exemple)
- Utiliser des threads pour distinguer la gestion de
l’interaction avec l’utilisateur, et la gestion des requêtes sur l’ORB (un thread dédié)
HI |
=
HelloImpl |
HCI |
=
HelloCallbackImpl |
1 |
sayHello
(hcbref, « test ») |
2 |
callback
(« test ») à affiche
« test » |
3 |
retour
de fonction sayHello : « HelloWorld » à affiche
« HelloWorld » |
4 |
shutdown()
à le serveur se suicide |
5 |
thread.shutdown()
à le client se suicide |
Exemple de code
JAVA
== Mecanisme de rappel
(Callback) ==
Hello.idl
module
HelloApp {
interface HelloCallback {
void
callback(in
string message);
};
interface Hello {
string sayHello(in
HelloCallback objRef, in string message);
oneway void shutdown();
};
} ;
HelloServeur.java
class
HelloImpl extends HelloPOA {
private ORB orb;
public void
setORB(ORB orb val) {
orb = orb_ val;
}
public String sayHello (HelloCallback objRef, String
message) {
objRef.callback)message);
return "\nHello world !!\n" ;
}
public void
shutdown () {
orb.shutdown(false); }
}
public class HelloServeur {
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null);
Hellolmpl hellolmpl = new
Hellolmpl() ;
hellolmpl.setORB(orb);
// finit POA
POA rootpoa =
POAHelper.narrow(orb.resolve
initial_references("RootPOA"));
rootpoa.the_POAManager().activate))
;
org.omg.CORBA.Object ref =
rootpoa.servant_to
reference(hellolmpl);
Hello href =
HelloHelper.narrow(ref);
// inscription de l'objet
au service de noms
org.omg.CORBA.Object objRef
=
orb.resolve_initial
references("NameService"); NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef); NameComponent path[] = ncRef.to_name("Hello");
ncRef.rebind(path, href);
System, out. println ("HeIloServeur
ready and waiting ...") ;
orb. Run();
}
catch (Exception e) {
System.err.println("ERROR:"
+ e); e.printStackTrace(System.out);
}
System.out.
println("HelloServeurExiting...");
}
}
HelloClient.java
class
HelloCallbacklmpl extends HelloCallbackPOA {
public void callback(String message) {
System.out.println(message);
}
}
class
ThreadRun extends Thread {
private ORB orb;
public ThreadRun(ORB orb) {
this.orb = orb;
}
public void
run() {
try{
orb.runO;
}
catch (Exception e) {
System.out.println("ERROR:"
+ e) ;
e.printStackTrace(System.out);
System.exit(1);
}
}
public void
shutdown () {
orb.shutdown(false);
}
}
public
class HelloClient {
public static void
main(String args[]) {
try{
ORB orb = ORB.init(args,
nuil);
org.omg.CORBA.Object objRef
=
orb.resolve initial
references("NameService"); NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef); String name = "Hello";
// obtenir reference sur l'objet distant
Hello hellolmpl =
HelloHelper.narrow(ncRef.resolve str(name));
// Init POA
POA rootpoa =
POAHelper.narrow
(orb.resolveinitial_references("RootPOA")) ;
rootpoa.the_POAManager().activate()
;
// creer l'objet qui sera appelé depuis le serveur HelloCallbackImpl
helloCallbacklmpl = new HelloCallbacklmpl();
org.omg.CORBA.Object ref =
rootpoa.servant to
reference(helloCallbacklmpl); HelloCallback hcbref =
HelloCallbackHelper.narrow(ref);
// lancer l'ORB dans un
thread
ThreadRun thread = new
ThreadRun(orb);
thread.start() ;
// declenche
la methode sur l'objet distant System.out.println(hellolmpl.sayHello(hcbref,"test"));
// shutdown
hellolmpl.shutdown();
thread.shutdown();
}
catch (Exception e) {
System.out.
println("ERROR:" + e) ;
e.printStackTrace(System.out);
}
}
}
Execution
$
tnameserv -ORBInitialPort 1050 & # commande lancée sur dista(X)
$
java HelloServeur -ORBInitialPort 1050 -ORBInitialHost dista(X)
HelloServeur
affiche : "HelloServeurreadyandwaiting..."
$
java HelloClient -ORBInitialPort 1050 -ORBInitialHost dista(X)
HelloClient
affiche : "test"
HelloClient
affiche : "Helloworld"
HelloServeur
affiche : "HelloServeurExiting..."
Asynchronisme
Par défaut, l’invocation
d’une opération (méthode) est
synchrone. Un client qui appelle une méthode distante doit attendre le retour
de fonction. Ceci n’est pas performant dans différentes situations.
Lesquelles ?
-
si le client doit
réaliser différentes activités concurrentes
-
si le client veut
appeler plusieurs méthodes distantes simultanément sur différents objets
distants
-
si une communauté
de serveurs organisée selon une topologie d’arbre binaire veut diffuser un
message
CORBA fournit le modificateur
« oneway » à utiliser dans les fichiers IDL pour rendre un appel de
méthode asynchrone.
Cela implique :
-
que le type de
retour de la méthode est void
-
que tous les
paramètres soient de type « in »
-
qu’aucune
exception ne doit être levée par la méthode
è L’implémentation va pouvoir hériter d’une autre chose que le
squelette.
En JAVA cela permet de
contourner le problème qu’il n’y a pas d’héritage multiple.
A la mode POA, diagramme de classes :
A la mode POA TIE, diagramme de classes :
code à la mode POA
ICarreImpl.java class ICarreImpl extends ICarrePOA
Serveur.java ICarre
myobj = new ICarreImpl();
poa.servant_to_reference(myobj);
Code à la mode
POA+TIE
ICarreImpl.java class ICarreImpl implements ICarreOperation extends “classe
quelconque »
Serveur.java ICarre
myobj = new IcarreImpl();
Icarre
POATie objtie = new ICarrePOATIE (myobj)
poa.servant_to_reference(objtie)
Inconvénient : un intermédiaire
supplémentaire à modèle moins
performant
======================================== CORBA –
Partie IV ========================================
-
En mode statique, le squelette et le proxy sont générés automatiquement
à partir du contrat IDL.
-
Dans les applications complexes, certaines spécifications peuvent évoluer,
par l’ajout de nouvelle opérations ou par la modification des spécifications.
-
Lorsque l’on désire réaliser un navigateur parmi les objets accessibles
à distance et invoquer des opérations dessus à besoin d’invocations dynamiques
-
Interpréteur de commande destiné à des objets CORBA à invocation dynamique
-
Pour gérer la construction et l’utilisation dynamique d’interface,
CORBA propose des mécanismes :
o
Interface d’invocation dynamique (DII) à côté client
o
Interface de squelette dynamique (DSI) à côté serveur
o
Le référentiel des interfaces : une sorte de base de données
contenant la description d’interfaces d’objets accessibles à distance (IR)
-
Avec ces mécanismes, le client peut invoquer n’importe qu’elle méthode
et sur n’importe quel objet et pas seulement ceux dont il connaît l’interface
IDL
-
Exemple d’utilisation de
1. localisation du serveur qui
héberge l’objet distant
2. identifier l’interface de
l’objet (méthodes, arguments des ces méthodes) à l’aide de l’IR (Interface
Repository)
[on a pas eu besoin de générer le proxy de l’objet
distant]
3. construction dynamique de la
requête à envoyer à l’objet distant
Request req = createRequest (nom_methode, argument)
4. invocation dynamique de la
requête
req.revoke() ;
Remarque :
l’étape 1 est faite de manière statique alors que les autres sont faites dynamiquement
Dynamic Invocation Interface
(Utilisé par un Client)
org.omg.CORBA.Object
ir obj =
orb.resolve-initial references
("InterfaceRepository");
Repository
repos = RepositoryHelper.narrow (ir obj);
org.omg.CORBA.Contained
definition = repos. lookup id("IDL:Iecho:l.0");
org.omg.CORBA.Container conteneur = ContainerHelper.narrow(definition);
System.
out. println ("On a le conteneur de l'interface" i ;
org.omg.CORBA.InterfaceDef
iface=InterfaceDefHelper.narrow(definition);
FulllnterfaceDescription
description = iface.describe interface();
org.omg.CORBA.OperationDescription
[] operations = description.operations;
System.out.
println("Liste des operations:" );
for
(int i = 0; i<operations.length; i++) {
System.out. println("signature" + i + "-emeop:
"
+ operations[i].name +
"(") ;
org.omg.CORBA.ParameterDescription []
seq=operations(i].parameters;
for(int j=0; j<seq.length; j++) {
System.out.println(seq[j] + "");
}
System.out.println( ")" );
}
CORBA est une spécification
d’un service de communication repartie orientée objet. Par conséquent, son
architecture ne précise pas de détails d’implémentation mais seulement un
ensemble de blocs fonctionnels prenant en charge une partie des interactions
-
SII = Static
Invocation Interface : mécanisme de proxy
-
SSI = Static
Skeleton Interface :squelette ORB Core à ensemble de mécanisme de communication (le noyau
n’est pas accessible par le programmeur)
-
Interface
ORB : initialisation de l’ORB, paramétrage, conversion des références
d’objet en chaîne de caractères
-
Les services
d’objets communs sont spécifiés par OMG et ils permettent de retrouver sur le
bus des objets nécessaires aux applications reparties (services de noms, trader
service, service « vendeur ».
D’autres
services qui prennent en charge la vie des objet CORBA :
o
Persistant Object
Service
o
Security Service
o
Object
Transaction Service
-
Coopération
d’objet Event Service (= canal d’événement commun à des objets répartis)
-
OA :
Adaptateur d’Objet : POA
Ce
bloc fonctionnel permet au noyau de déléguer l’execution des requetes. CORBA
vis une grande variété de support d’objet :
o
code JAVA intégré
dans un téléphone
o
objet dans un
processus
o
base de données
o
capteur de
température
o
un fichier
contenant une bibliothèque