Car Corba

Applications Réparties
CORBA
Atef Ben Ismail
INSAT 2009-2010
OMG (Object Management Group)
Consortium international créé en 1989 par 8 compagnies : 3Com Corporation,

American Airlines, Canon Inc., Data General, Hewlett-Packard, Philips
Telecommunications N.V., Sun Microsystems et Unisys Corporation
En 1998 plus de 800 membres : constructeurs de matériels, développeurs de

logiciels, industriels, monde académique
Son rôle :
• promouvoir la technologie objets répartis
• en produisant des spécifications acceptées par consensus
2 Application Réparties INSAT 2010

OMG: Mission et Objectif
MISSION
Promouvoir la technologie orientée objet dans les systèmes informatiques distribués
Fournir une architecture de base pour l’intégration d’applications distribuées tout en
garantissant la réutilisabilité, l’intéropérabilité et la portabilité.
OBJECTIF
Favoriser l’intéropérabilité et la portabilité d’applications réparties à travers :
– une terminologie unique dans le domaine de l’objet;
– un model de référence commun;
– des interfaces et des protocoles communes.

Principales Spécification de OMG
OMA (Object Management Architecture) (1990)
CORBA (Common Object Request Broker Architecture) (1991 1.0 ; 2001 2.4 ;
2002 3.0)
Services CORBA (COS Common Object Services 1997)
IIOP (Internet Inter-ORB Protocol) (1996)
UML (Unied Modeling Language)(1.0 1997 ; 1.5 2003)
CCM (CORBA Component Model) (3.0 2002)
…
http://www.omg.org/

CORBA
Common Object Request Broker Architecture
Spécifié par l’OMG
CORBA est un standard, pas un produit
Mécanismes par lesquels des objets peuvent envoyer des requêtes et recevoir
des réponses de manière transparente
Intéropérabilité entre différentes applications sur différents environnements

dans différents langages.
Approche orientée objet

OMA (Object Management Architecture)
Description d’une architecture de Gestion Objet définissant les bases des

futures spécifications incluant :
• une prise en compte des problèmes d’intégration dans des environnements distribués;
• les objectifs de l’OMG;
– Un modèle d’objet abstrait
– L’architecture du modèle de référence
• un glossaire des termes utilisés.

Le modèle abstrait d’objets
Modèle définissant la façon de décrire des objets distribués dans des

environnements hétérogènes.
Utilisé dans toutes les technologies conformes à l’OMG (ex : CORBA)
Spécifie une sémantique commune définissant le comportement externe des

objets d’une manière standard (indépendante des langages et des
implémentations).

Définition (1/2)
Client
• Entité capable d’émettre des requêtes vers des objets qui fournissent des services.
• Le client manipule des références vers des objets distants.
Référence objet
• Objet manipulé par le client pour invoquer des services sur un objet distant : objet
implémentation.
• Terme usité : proxy
• Un proxy est un représentant local au client d’un objet distant.
Objet d’impléméentation
• Objet situé sur le serveur qui implémente le code des méthodes des opérations
définies en IDL.

Définition (2/2)
Requête
• Emise par un client pour demander l’exécution d’une opération sur un objet cible.
• La requête contient l’opération à exécuter, l’objet cible et les paramètres éventuels.
Interface
• Description d’un ensemble d’opérations disponibles sur un objet.
• Spécification des interfaces en IDL.
Opération
• Entité identifiable caractérisée par une signature décrivant les paramètres de la
requête et les valeurs de retour.

OMA

Composantes de l'OMA
ORB : transport des requêtes entre objets
Objets services communs : objets systèmes communément utiles, exemple :

impression, aide en ligne, messages d’erreurs
Objets application : objets propres à chaque application non décrits par l'OMG
Objets domaines : objets communs à un domaine d'application :

télécommunication, médecine, nance . . .
Objets service

Objets Service (1/2)
Les spécifications CORBA fixent les IDL des services et les sémantiques
associées :
• désignation : recherche d'un objet CORBA par son nom : pages blanches
• trading : recherche d'un objet CORBA par ses propriétés : pages jaunes
• transactions : permet des traitements transactionnels entre objets répartis :
propriétés ACID
• événements : gère des canaux d'événements utilisés par des objets producteurs et
consommateurs
• notification : extension du service des événements : filtrage des événements
• persistance : stocke et restaure l'état persistant des objets
• cycle de vie : crée, copie, déplace, détruit des objets
• licences : mesure et contrôle l'utilisation des objets
• sécurité : authentifie les clients, contrôle l'accès et chiffre les requêtes
• temps : horloge globale et synchronisation des objets
• propriétés : permet d'associer des pairs (attribut,valeur) à des objets CORBA

Objets Service (2/2)
• interrogations : se base sur les protocoles d'interrogation standards (SQL), permet

l'invocation sur des collections d'objets
• concurrence : gère des accès concurrents à des objets partagés : mécanismes de
verrou
• relations : dénit des objets de relations (entre objets CORBA) pour représenter des
graphes d'objets CORBA
• collection : gère des collections d'objets : ensemble, pile, le, liste, arbre

Vision client d'un objet CORBA
Identifié par une référence d'objet (IOR Interoperable Object Reference)
Supporte une interface dénfinie en IDL CORBA
CORBA assure les transparences suivantes :

• localisation de l'objet,
• serveur qui héberge l'objet,
• implémentation,
• langage d'implémentation,
• support (OS, protocoles réseau).

Vision serveur d'un objet CORBA
une instance de l'implémentation d'un objet CORBA est appelée serviteur

(servant),
un serviteur est hébergé par un serveur d'objets,
un serviteur est relié à un adaptateur d'objets (Portable Object Adaptor).

Composition du Middleware CORBA
les tâches de l’intergiciel ont été partagées entre :

• l'ORB présent sur le client et le serveur
• l'adaptateur d'objet présent uniquement sur le serveur

Objets impliqués dans une requête CORBA

Rôle de l’ORB (Objet Request Broker)
Utilise des Object References uniques pour identifier et localiser des objets
(les clients manipulent des Object References)
CORBA 2.0 spécifie des Interoperable Object References (IOR)
Fait suivre les requêtes jusqu’aux objets

Renvoie les valeurs de retour aux clients
Les services mis en œuvre sont transparents aux clients
Interface ORB : contient les services CORBA de base

• (object_to_string, string_to_object)
L’ORB met en oeuvre pour une référence
• get_interface retourne les méta-données de l’objet
• get_implementation
• is_nil

Rôle de l'adaptateur d'objets (POA)
assure la localisation du serviteur,
assure l'activation du serviteur (si besoin),
attribue la partie locale de la référence d'objet,
transmet la requête au mandataire du serviteur.

CORBA : Modes d’invocation
CORBA prévoie deux modes d'invocation :

• l'invocation statique: souche et squelette sont connus à la compilation,
• l'invocation dynamique: l'interface de l'objet est découverte dynamiquement à
l'exécution.

Cycle de vie d’un Objet CORBA
Objet passager : sa durée de vie est liée à la durée de vie du serveur qui
l'héberge.
Objet persistant : survit à la mort du serveur qui l'héberge

• Son implémentation doit sauvegarder son état en mémoire entre deux incarnations
• Il conserve toujours la même IOR

Cycle de vie d'un objet CORBA persistant

Développement d’une application CORBA
Le développement d’une application Corba nécessite d’effectuer les étapes

suivantes:
Etape 1: Spécifier l’interface IDL du servant

Compiler le fichier d’interface X.idl pour la génération des classes utils au
développement de l’application
Etape 2: Développer le Servant XImpl.java en s’aidant de le traduction
IDLversJava XOperations.java
Etape 3: Développer le Serveur Xserver.java
Etape 4: Développer le Client Xclient.java

CORBA: Cycle de développement

Première application CORBA

Fichiers à écrire
par le concepteur (modèlisation de l'objet) :

l'interface : Imprimante.idl
par le développeur côté serveur :
l' implémentation : ImprimanteImpl.java
le serveur d'objets : ServeurImprimantes.java
par le développeur côté client :
le client : Imprime.java

Le language IDL
Découple l’implémentation de l’objet de son interface
Langage déclaratif, syntaxe proche de C++
Définit des types d’objets en spécifiant leurs interfaces, le nom de leurs

opérations et des paramètres.
Moyen par lequel les clients peuvent obtenir les opérations disponibles sur un
objet.
Traduit vers le langage de mise en oeuvre désiré (C, C++, java, perl, python,
etc)
La compilation d’IDL produit des talons et des squelettes :

• Talon (stub) : fonction locale que le client peut appeler
• Squelette (skeleton) : fonction située sur le serveur effectuant l’appel local à l’objet.

IDL

IDL: Types de Bases et Mapping Java
IDL Java
short short
unsigned short short
long int
unsigned long int
long long long
unsigned long long long
float float
double double
char char
wchar char
boolean boolean
octet byte
string java.lang.String
wstring java.lang.String
any org.omg.CORBA.any
object org.omg.CORBA.Object

Interface IDL?
Interfaces : définissent des opérations naturellement liées

type de l’opération
nom de l’opération
Définit un contrat entre le client et le serveur
Pas d’information sur l’implémentation

Imprimante.idl

Interface IDL
Le langage de définition d'interfaces IDL CORBA créé en 1991 s'inspire de la

syntaxe du langage C.
Chacun des paramètres est tagué avec le mode de passage du paramètre :

in : paramètre emballé en entrée (de l'implémentation),
out : paramètre emballé en sortie (de l'implémentation),
inout : paramètre emballé en entrée et en sortie (de l'implémentation).
Tous les nouveaux types de paramètres (à l’exception des types de base), de
retour et les exceptions doivent être définis dans l'interface IDL de manière à
ce que l'emballage et le déballage soient générés automatiquement.
Le fichier IDL contient des définitions de type et des définitions d'interfaces.

Une interface est définie par la signature de ses opérations.

Génération des Stub et Skeleton (1/3)

Chaque ORB fournit un compilateur d'interfaces vers un langage de

programmation. La compilation peut être faite en deux fois :
1. le développeur côté serveur génère le squelette dans son langage de programmation,
2. le développeur côté client génère la souche dans son langage de programmation.
La compilation génère un certain nombre de fichiers (classes java pour
projection en java). Certains des fichiers sont communs à la souche et au
squelette.
• L'ensemble des fichiers générés côté serveur constitue le squelette.
• L'ensemble des fichiers générés côté serveur constitue la souche.

Exemple de compilation IDL vers java avec JDK :
Un certain nombre de fichiers sont communs à la souche et au squelette (ils sont

en rouge).
$ idlj -fserver -td generated Imprimante.idl
$ ls generated/
Imprimante.java ImprimantePOA.java TacheRefuseeHolder.java
ImprimanteOperations.java TacheRefuseeHelper.java TacheRefusee.java
$ idlj -fclient -td generated Imprimante.idl
$ ls generated/
ImprimanteHelper.java ImprimanteOperations.java TacheRefuseeHolder.java
ImprimanteHolder.java _ImprimanteStub.java TacheRefusee.java
Imprimante.java TacheRefuseeHelper.java

Compilation IDL - java : fichiers générés
Ce fichier est généré uniquement en
mode Tie en ajoutant une option au
compilateur IDL

Arbre d'héritage en Java

_ImprimanteStub : le mandataire client
L'interface IDL génère l'interface ImprimanteOperations
L'interface Imprimante implémente l'interface ImprimanteOperations ET

l'interface de tout objet CORBA
le mandataire _ImprimanteStub implémente Imprimante
le client déclare une référence vers un objet qui implémente Imprimante

public interface ImprimanteOperations
{
short printDocument(...);
}
public interface Imprimante extends ImprimanteOperations,org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity {}
public class _ImprimanteStub extends org.omg.CORBA.portable.ObjectImpl
implements Imprimante { ( ... );}

ImprimantePOA : le mandataire serveur
Le POA intercepte la requête cliente et identifie l’objet quui doit y répondre
public abstract class ImprimantePOA extends org.omg.PortableServer.Servant
implements org.omg.CORBA.portable.InvokeHandler, ImprimanteOperations
public String[] _all_interfaces( org.omg.PortableServer.POA poa, byte[] objectId) { }
public org.omg.CORBA.portable.OutputStream _invoke(String opName,
org.omg.CORBA.portable.InputStream in,
org.omg.CORBA.portable.ResponseHandler handler){ }

Classes Helper
À chaque Interface, type de base et définition de type est associée une classe
Helper qui ne contient que des méthodes statiques
Extraits de la classe Helper générée pour l'interface Imprimante :

Pour insérer un objet dans un Any
public class ImprimanteHelper
Pour extraire un objet dans un Any
{
public static void insert (Any, Imprimante); Pour retourner le type de l’objet
public static Imprimante extract (Any);

Pour retourner l’identifiant de l’objet
public static org.omg.CORBA.TypeCode type();
public static String id () {return "IDL:Imprimante:1.0";}
public static Imprimante read (InputStream);
public static void write (OutputStream, Imprimante)
public static Imprimante narrow (Object)
}
Pour convertir une référence
d’objet vers le type de l’interface

Classes Holder
À chaque Interface, type de base et définition de type est associée une classe
Holder nécessaire pour les paramètres inout et out
Les classes Holder pour les types IDL de base sont définit dans le package
org.omg.CORBA
Extraits de la classe Holder générée pour l'interface Imprimante :

public final class ImprimanteHolder implements org.omg.CORBA.portable.Streamable
{
public Imprimante value;
public ImprimanteHolder();
public ImprimanteHolder(Imprimante);
public void _read (InputStream);
public void _write (OutputStream);
public TypeCode _type ();
}

Mapping Java pour les Interfaces
A une interface IDL correspond une Interface Java

• Avec les mêmes nom et méthodes
• Dérivée de org.omg.CORBA.Object
Produit également les classes stub et skeleton
Deux classes Java supplémentaires sont aussi générées pour chaque interface
• Une classe Helper
• Une classe Holder

Qu’est ce qu’un Module IDL?
Un regroupement de composants distincts
Un espace de nommage IDL
Peuvent être imbriqués

module Imprimante
{
//type declarations …
//constant declarations …
//exception declaration …
module Lazer
{
//declaration
};
};
Les modules IDL sont convertis en packages Java

Qu’est ce qu’une Opération IDL?
Semblable aux méthodes ou aux fonctions membres
Ressemble à des déclarations de méthode Java/C++
Le mode de passage du paramètre doit
être spécifié in, out, inout
interface Imprimante
{
// retour : numéro de tâche
short printDocument ( in string nomFichier, out long nbOctets) raises(TacheRefusee) ;
short printDocument ( in string nomFichier, out long nbOctets, in long nbCopy) raises(TacheRefusee) ;
oneway cancel(in string nomFichier ) raises(TacheRefusee) ;
};
IDL ne supporte pas la surcharge
d’opération. Cette ligne génère une
erreur.
Peut être spécifié asynchrone en utilisant

le mot clé oneway
A chaque opération correspondra une méthode dans l’interface Java

Qu’est ce qu’un Attribut IDL?
Ne définit pas forcément un attribut en mémoire
Interface ImprimanteAdmin {…} Doit être à l’intérieur d’une interface
Signalé par le mot clé attribute
{
attribute boolean etat;
attribute ImprimanteAdmin manager;
readonly attribute long imprimanteID; Peut être un type de base IDL ou une
interface
// …
}; Peut être déclaré readonly
A chaque attribut correspond une ou deux méthodes

public Interface ImprimanteOperations
{ Getter
public boolean etat();

Setter
public void etat(boolean etat);
public int imprimanteID();
// …
Uniquement un Getter est généré
}; quand l’attribut est readonly

Constantes
Une constantes est traduite en une variable Java statique finale ou une interface.
module Imprimante
{
const string BAC_CAPACITY = 500;
interface Lazer public interface BAC_CAPCITY {
public final static java.lang.String value = (java.lang.String)500;
{
}
const long TONER_CAPACITY = 1000;
//…
}; public final static int TONER_CAPACITY = 1000;
};

Exemple plus complet en IDL (1/2)
module GestImpr {
exception TacheRefusee { (...) };
struct Tache {
short no; tableau de longueur variable
string fichier;
};
typedef sequence <Tache> ListeTaches;
typedef Tache TabTaches [10];
enum Etat { arret, marche };
enum SecuritePolitique { normal, protege };
union AdminId switch (SecuritePolitique) {
case normal : string nom ;
case protege : string nom; string motPasse;
};

Exemple plus complet en IDL (2/2)
interface Imprimante {
short printDocument ( in string n, out long t) raises( TacheRefusee) ;
};
interface AdminImprimante {
attribute Etat etat;
};
interface ImprimantePlus : Imprimante, AdminImprimante {
ListeTaches tachesEnCours();
readonly attribute short tacheCour;
oneway void envoiRapide ( in string n);
};
};

Mapping Java des séquences
IDL
typedef sequence<string> StrSeq;
interface XXX {
StrSeq modifier (in StrSeq inStr, out StrSeq outStr);

}
les séquences doivent être dénies par un typedef
la signature java de la méthode modier est la suivante :

String[] modifier(String[] inStr, StrSeqHolder outStr);
le champ value de StrSeqHolder est aussi un String[]

Fichiers IDL
Doivent avoir l’extension .idl
Peuvent contenir la définition de plus d’une interface
Peuvent inclure d’autres fichiers IDL

#include "Session.idl"

Mots Clé IDL
Type de base:
boolean, char, double, float, long, octet, short, string, unsigned, void, wchar, wstring
Types complexes
any, enum, union, sequence, struct, object, exception
Mots clé de déclaration
attribute, module, interface, raises, typedef, valuetype
Modificateurs
in, inout, out, const, oneway, readonly, public private, abstract
Valeurs constantes
FALSE, TRUE
Autres
default, switch, case

IDL Conclusion
IDL n’et pas un langage déclaratid
Les principaux concepts IDL sont

• module, interface, attribut, operation
Le mapping IDL/Java définit les correspondances
• Type de base Type Java + Holder
• Module Package
• Interface 7 classes
• Opération Méthode
• Attribut Accesseur, [Mutateur] (Getter/Setter)
Les paramètres Out et Inout doivent être passés en utilisant les classes Holder
• Que ce soit pour les types de base ou les types complexes

Modes de passage des paramètres
Des données typées,
Des objets CORBA passés par référence,
Des objets valuetype passés par valeur.

Paramètres et retour : données typées
struct Tache
{
short no;
string fichier;
};
(...)
Tache decrireTache (in long numeroTache);
types IDL de base
ou définition de structures en IDL
ce ne sont que des données, pas de code associé

Paramètres et retour : objets par référence
interface Imprimante { (...) }

interface PrinterFactory
{
Imprimante newPrinter (in string name, in string location);
Imprimante findPrinter (in nom) raises (UnknownPrinter)
}
l'appelant récupère une référence sur un objet
il peut ensuite invoquer des opérations à distance sur cet objet

Paramètres et retour : objets par valeur
L'état de l'objet,
et ses méthodes locales sont décrites dans l'IDL dans un valuetype,
lors d'une invocation lorsqu'un paramètre est de type valuetype, l'appelant

récupère une copie locale de l'objet, sur lequel il pourra faire des invocations
locales
un objet spécial de type factory permet la création de l'objet sur la destination
le code de l'objet peut soit :

• être présent sur le client
• être téléchargé via un callback vers le serveur

Objets par valeur, exemple IDL
valuetype TacheV
{
// état de l'objet
private short no;
public string fichier;
// constructeur
// méthodes de l'objet
void afficher();
};
{
(...)
TacheV getTacheCourante();
}

Les différentes exceptions CORBA
En plus des exceptions utilisateurs dénies dans l'IDL, toute opération CORBA
peut générer des exceptions CORBA : :SystemException.
IDL dénit 36 cas d'exceptions CORBA qui peuvent être soulevées par toute
opération (implicitement) :
les plus couramment rencontrées sont les suivantes :

TRANSIENT : le serveur ne peut pas être contacté
OBJECT_NOT_EXIST : le serveur peut être contacté mais pas d'objet associé à cette
référence
COMM_FAILURE : la requête est partie vers le serveur, pas reçu de réponse,
BAD_OPERATION : cette opération n'existe pas
FREE_MEM
NO_PERMISSION
...

Un Exemple complet pour Finir: Agenda
Réaliser un système simple de consultation d’agendas.
Notre agenda permet de stocker un rendez-vous par jour, sur une durée de 31
jours. Un agenda pourra par la suite représenter l’agenda d’un enseignant ou
celui d’une salle, etc.
Dans un premier temps, on souhaite pouvoir :

• Savoir si un jour précis est déjà occupé ou non.
• Connaître le RdV pris à une date précise.

Agenda.idl
#ifndef GL2__IDL
#define GL2__IDL
// Basic type definitions

// In order to simplify the problem, Dates will be represented using a string like MMDDYY
typedef string Date;
typedef string Subject;
interface Agenda
{
// An Agenda has only one operation in the increment
boolean isAvailable(in Date when);
Subject whatDoYouDo(in Date when);
};
#endif

AgendaImpl.java
import org.omg.PortableServer.*;
import java.util.*;
import java.text.*;
class AgendaImpl extends AgendaPOA
{
private Hashtable m_events = new Hashtable();
public AgendaImpl () {
m_events.put(AgendaUtils.formatDate(0), "Project kick off"); //AgendaUtils is a date formatter
m_events.put(AgendaUtils.formatDate(1), "Resource allocation");
m_events.put(AgendaUtils.formatDate(2), "System analysis");
m_events.put(AgendaUtils.formatDate(4), "Prototype development");
m_events.put(AgendaUtils.formatDate(10), "Install prototype");
m_events.put(AgendaUtils.formatDate(12), "Run demo");
System.out.println(m_events);
}
public boolean isAvailable (java.lang.String when) {
// Lookup the event in the events dictionary.
String event = (String) m_events.get(when);
if(event == null) { return true; }
else { return false;}
}
public java.lang.String whatDoYouDo (java.lang.String when) {
return (String) m_events.get(when);
}
} 61 Application Réparties INSAT 2010
Server.java
// Importing ORB classes
import org.omg.PortableServer.*;
public class Server{
public static void main(String[] args)
{
try {
// Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
// Get a reference to the Root POA
POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
// Create policies for our persistent POA
org.omg.CORBA.Policy[] policies = {
rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT)
};
// Create myPOA with the right policie
POA myPOA = rootPOA.create_POA("agenda_poa", rootPOA.the_POAManager(), policies);
// Create the servant
AgendaImpl theAgenda = new AgendaImpl();
// Decide on the ID for the servant
byte[] agendaID = "TheAgenda".getBytes();
// Activate the servant with the ID on myPOA
myPOA.activate_object_with_id(agendaID, theAgenda);
// Activate the POA manager
rootPOA.the_POAManager().activate();
System.out.println(myPOA.servant_to_reference(theAgenda) + " is ready.");
// Wait for incoming request
orb.run();
} catch (Exception e) { e.printStackTrace();}
}
} 62 Application Réparties INSAT 2010
Client.java
public class Client
{
public static void main(String[] args)
{
try {
// Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
// Build the Agenda ID
byte[] agendaID = "TheAgenda".getBytes();
// Locate the Agenda
Agenda myAgenda = AgendaHelper.bind(orb, "/agenda_poa", agendaID);
// Use the Agenda

// Check if available next 30 days and if not display what I do
for(int i = 1; i < 31; i++)
{
String day = AgendaUtils.formatDate(i);
if (! myAgenda.isAvailable(day))
{
System.out.println("[" + day + "] " + myAgenda.whatDoYouDo(day));
}
}
}
catch (Exception e) { e.printStackTrace(); }
}
}

A Suivre …
Programmation d’un POA
Service Corba par la pratique
CallBack
…

www.alcatel-lucent.com
INSAT 2009-2010
65 | A look Forward | January 2010

Car Corba

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Car Corba

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Applications Réparties

Atef Ben Ismail

Consortium international créé en 1989 par 8 compagnies : 3Com Corporation,

En 1998 plus de 800 membres : constructeurs de matériels, développeurs de

2 Application Réparties INSAT 2010

3 Application Réparties INSAT 2010

OMA (Object Management Architecture) (1990)

Services CORBA (COS Common Object Services 1997)

IIOP (Internet Inter-ORB Protocol) (1996)

UML (Unied Modeling Language)(1.0 1997 ; 1.5 2003)

CCM (CORBA Component Model) (3.0 2002)

4 Application Réparties INSAT 2010

Spécifié par l’OMG

CORBA est un standard, pas un produit

Intéropérabilité entre différentes applications sur différents environnements

Approche orientée objet

5 Application Réparties INSAT 2010

Description d’une architecture de Gestion Objet définissant les bases des

6 Application Réparties INSAT 2010

Modèle définissant la façon de décrire des objets distribués dans des

Utilisé dans toutes les technologies conformes à l’OMG (ex : CORBA)

Spécifie une sémantique commune définissant le comportement externe des

7 Application Réparties INSAT 2010

8 Application Réparties INSAT 2010

9 Application Réparties INSAT 2010

10 Application Réparties INSAT 2010

ORB : transport des requêtes entre objets

Objets services communs : objets systèmes communément utiles, exemple :

Objets domaines : objets communs à un domaine d'application :

11 Application Réparties INSAT 2010

12 Application Réparties INSAT 2010

• interrogations : se base sur les protocoles d'interrogation standards (SQL), permet

13 Application Réparties INSAT 2010

Supporte une interface dénfinie en IDL CORBA

CORBA assure les transparences suivantes :

14 Application Réparties INSAT 2010

une instance de l'implémentation d'un objet CORBA est appelée serviteur

un serviteur est hébergé par un serveur d'objets,

un serviteur est relié à un adaptateur d'objets (Portable Object Adaptor).

15 Application Réparties INSAT 2010

les tâches de l’intergiciel ont été partagées entre :

16 Application Réparties INSAT 2010

17 Application Réparties INSAT 2010

CORBA 2.0 spécifie des Interoperable Object References (IOR)

Fait suivre les requêtes jusqu’aux objets

Les services mis en œuvre sont transparents aux clients

Interface ORB : contient les services CORBA de base

18 Application Réparties INSAT 2010

assure l'activation du serviteur (si besoin),

attribue la partie locale de la référence d'objet,

transmet la requête au mandataire du serviteur.

19 Application Réparties INSAT 2010

CORBA prévoie deux modes d'invocation :

20 Application Réparties INSAT 2010

Objet persistant : survit à la mort du serveur qui l'héberge

21 Application Réparties INSAT 2010

22 Application Réparties INSAT 2010

Le développement d’une application Corba nécessite d’effectuer les étapes

Etape 1: Spécifier l’interface IDL du servant

Etape 3: Développer le Serveur Xserver.java

Etape 4: Développer le Client Xclient.java

23 Application Réparties INSAT 2010