Intro CoursCORBA

Planning
Séance1 : 10 Octobre Bouzefrane Introduction Séance9 : 5 décembre Farinone

Communication basée sur XML : Web
Séance2 : 17 Octobre Bouzefrane CORBA services (2)
Séance9 : 12 décembre Bouzefrane
Séance3 : 24 Octobre Farinone Applications réparties à .NET et les Web services
base de Navigateurs web : Servlet/JSP (1) Séance11 : 19 Décembre Farinone
programmation répartie pour
Séance4 : 31 Octobre Farinone Applications réparties à téléphone mobile : Java ME
base de navigateurs web : Servlet/JSP (2)
28 Décembre : Férié
Séance5 : 7 Novembre Farinone Communication 2 Janvier : Férié
basée sur le modèle client serveur : RMI
Séance12 : 9 Janvier Bouzefrane
programmation répartie pour cartes à
Séance6 : 14 Décembre Bouzefrane Communication puce : Java Card RMI
basée sur le modèle client/serveur : .NET Remoting
Séance13 : 16 Janvier Gressier Algo
Séance7 : 21 Novembre Farinone Communication répartie ordres(1)
basée sur les composants : EJB Séance14 : 23 Janvier Gressier Algo
répartie ordres(2)
Séance8 : 28 Novembre Farinone Communication Séance15 : 30 Janvier Gressier Algo
basée sur XML : Web services (1) répartie ordres(3)
CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 1

Les Systèmes et Applications Réparties
et leur Programmation
Samia Bouzefrane
Maître de Conférences
Laboratoire CEDRIC
Conservatoire National des Arts et Métiers
292 rue Saint Martin
75141 Paris Cédex 03
samia.bouzefrane@cnam.fr
http://cedric.cnam.fr/~bouzefra

Notion d’Intergiciel (Middleware)
Intergiciel : une terminologie pour une classe de logiciels systèmes

qui permet d’implanter une approche répartie: exemple CORBA
Fournit une API d’interactions de communication: interactions de

haut niveau pour des applications réparties: exemple invocation
distante de méthode pour des codes objets.
Fournit un ensemble de services utiles pour des applications
s’exécutant en environnement réparti: désignation, cycle de vie,
sécurité, transactionnel, etc.
Fonctionne en univers ouvert (supporte des applications tournant sur
des plate-formes matérielles et logicielles différentes).

Les principales catégories d’Intergiciels
Intergiciels à messages
MOM: Message Oriented Middleware IBM MQSeries,
Microsoft Message Queues Server,DECmessageQ, etc.
Intergiciels de bases de données (ODBC)
Intergiciels à appel de procédure distante (DCE)
Intergiciels à objets répartis (CORBA, JAVA RMI)
Intergiciels à composants (EJB, CCM, Web services)

Intergiciels à Objets Répartis :
Common Object Request Broker Architecture

ou simplement CORBA

De nouveaux besoins
- Développement des réseaux hétérogènes tant sur les architectures que sur
les systèmes
- Intégration de logiciels d’origines diverses
- Accès aux logiciels à l’intérieur et à l’extérieur des sociétés via Internet :
• gestion d’agences ou succursales pour une entreprise
• échange clients et fournisseurs (e-commerce par exemple)

L’hétérogénéité dans les systèmes informatiques distribués
IBM AS/400 Cray

PC Windows Station SUN Station HP

L’évolution des modèles d’architectures distribuées
Modèle Client/serveur
requête
Client Serveur
réponse
Interface Interface
Réseau

L’évolution des modèles d’architectures distribuées
C C C/S C/S
S C/S
Un serveur et Des services et des clients Des objets distribués

des clients distribués

Les mécanismes de l’invocation distribuée
Appelant
Appelant
Souche Décodage résultats

Codage
Codage paramètres
résultats
Réseau
Décodage Squelette
Appelé
paramètres
Appel local
Invocation distribuée Appelé

Motivations pour CORBA
- Construire un environnement dont les spécifications sont standardisées
- s’affranchir des solutions purement propriétaires
- offrir une plate-forme multi-systèmes et multi-langages
Motivations pour l’approche Objet
- l’application modélise directement des objets réels du domaine
- obtenir une architecture logicielle claire et simple
- avoir une conception modulaire (masquage des détails d’implantation)

Quelques Définitions
- CORBA : Common Object Request Broker Architecture

- ORB ou bus logiciel : fournit une infrastructure de communication pour
des objets hétérogènes et distribués
ORB
Objet serveur
Objet serveur BD Objet annuaire d ’impression
Objets : entités identifiées qui fournissent des services

- distribués : pouvant être accédés à distance au travers d’un réseau
- hétérogènes : proviennent de langages et de systèmes différents

Consortium OMG (Object Management Group)
OMG : organisation non commerciale fondée en 1989 (USA)

produit des spécifications
Plus de 1000 membres :

• constructeurs (IBM, SUN, HP, INTEL, …)
• éditeurs (Netscape, MicroSoft, …)
• utilisateurs (Boeing, Alcatel, NASA)
• laboratoires (INRIA, CERN, LIFL)

Consortium OMG
• OMA : Object Management Architecture

architecture générale pour la gestion d’objets distribués
• CORBA : est un des composants de l’OMA
permet aux objets distribués de communiquer
1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001
OMA v1
11 membres 390 Définition de services CORBA
CORBA 1.1 membres CORBA 2.0 CORBA 2.3 CORBA 3
200 membres 2.2

Modèle OMA
Application objects Domain interfaces Common facilities
Info. Task
O1 O2 Dist.
Dev. mngt. mngt.
Simul.
User System
O3 O4 Manuf. Acount. inter. mngt.
Object Request Broker (ORB)
naming event Concur. query time
lifecycle Transac. security licensing Persist.

Modèle OMA
- Bus logiciel (ORB : Object Request Broker)

: infrastructure de communication de l’OMA
- Services COS (Common Object Services ou CORBA services)
: librairies (classes) de services système de base
(service de nommage, sécurité, etc.)
- Facilités (common facilities ou CORBA facilities)
: logiciels pour des traitements courants
(messagerie, service d’impression, etc.)
- Interfaces de domaines (Domain Interfaces)
: logiciels spécialisés pour des domaines d’activités
(imagerie, production pétrolière, etc.)
- Objets d’application (Application Objects)
: applications mises en place par les développeurs

Fournisseurs d’ORB
Commerciaux
• ORBIX IONA www.iona.com
• VisiBroker Inprise www.inprise.com/visibroker/
• ORBacus OOC www.ooc.com
• DSOM IBM www.software.ibm.com/ad/som/
Gratuits
• MICO Univ. Francfort www.mico.org
• JacORB univ. Berlin www.inf.fu-berlin.de/~brose/jacorb
• OmniORB 2 AT&T www.uk.research.att.com/omniORB/
• TAO univ. Washington www.cs.wustl.edu/~schmidt/TAO.html

Vue générale de CORBA
Client
Serveur
Smalltalk
Smalltalk
Cobol
Java
Cobol
C++
Java
C++
Ada
Ada
C
C
Interface IDL
Souche Squelette
Object Request Broker (ORB)

IDL/CORBA
- Nécessité d’un langage de description des interfaces contractuelles pour

les services et requêtes
- IDL (Interface Description Language) : est le langage de description de toutes

les technologies CORBA. Il permet notamment la description des interfaces des
objets distribués.
- Projection des interfaces IDL dans le langage des applicatifs.
- Toutes les technologies CORBA sont décrites en IDL.

Schéma d’utilisation
Interface
IDL Gestionnaire du
Service (Serveur) appelle
Client Implémentation
Compilateur du service
inclut IDL inclut
(Servant)
projection
stub/
squelette
souche
ORB
invocation Raccordement au bus

Invocation statique
- Quand un client invoque une méthode sur l’objet proxy (stub) local,
- l’ORB empaquette les paramètres de l’appel ;
- il les envoie au serveur;
- le serveur les dépaquette ;
- le serveur invoque la méthode sur le servant (objet distant);
- les éventuels paramètres de sortie ou valeurs de retour suivent le chemin
inverse.

Langage IDL
IDL (Interface Definition Language)

• Langage de définition des services proposés par un objet
• Une interface comprend les opérations et les attributs d’un objet
• Langage déclaratif (l’implantation ne se fait pas à ce niveau)
•Mapping : correspondance entre IDL et un langage de programmation

6 mappings normalisés OMG (C, C++, Java, Ada, Cobol, Smalltalk)
d’autres plus exotiques existent (Tcl, Perl, CLOS, Eiffel, Python, Modula).
IDL de CORBA
• orienté objet
• supporte l’héritage
• dédié à la programmation distribuée

Langage IDL
Structure d’un fichier IDL
<types> typedef string Tadresse;

<constantes> const Tadresse adresseCNAM="…";
<exceptions> exception jourFerie{};
<modules> module TP {
<interfaces> interface Etudiant {
<attributs> attribute long age;
<operations> boolean present (in long jour)
raises jourFerie;
}
}
• les modules peuvent être emboîtés les uns dans les autres
• les types, constantes, exceptions peuvent être déclarés à différents niveaux
(globalement, localement à un module, localement à une interface).

Les types de données dans IDL
Types de base : Exemple :

• short, unsigned short (2 octets) typedef long age;
• long, unsigned long (4 octets)
• long long, uns. long long (8) struct personne {
• float (4 octets) string nom;
• double (8), long double (16) long age;
• boolean (TRUE, FALSE) };
• octet (1 octet, transmis tel quel)
• char (1 octet, ISO Latin 1) enum couleur{rouge, vert,
• wchar (2 octets, Unicode) bleu};
• void (type vide)
union carre switch(couleur) {
Types construits : case rouge : short num;
default: char n;
• struct (structures)
};
• enum (énumération)
• union (type discriminé)
string <16> chaine;
• string, wstring (chaîne)
string nom;
• sequence (tableau)
sequence <long> vecteur;
sequence <float, 8> tableau;

Les constantes dans IDL
Des variables typées dont la valeur est fixe

const <type> <ident> = <expr>;
Types autorisés pour les constantes Exemple

• long, unsigned long
• short, unsigned short const long max=255;
• long long, unsigned long long
• float, double, long double const long taille=8;
const long segments=1024/taille;
• boolean
• char, wchar const string usage="Hello";
• string
Opérateurs autorisés
• unaires + - ~
• binaires + - * / % << >> & | ^

Les exceptions dans IDL
Des structures de données qui signalent une situation exceptionnelle

• définies par le programmeur
• levées par le système
Exceptions spécifiées par l’utilisateur

Quelques exceptions système
exception <ident> { <données>* };
OBJECT_NOT_EXIST
BAD_PARAM
Exemple COMM_FAILURE
exception overflow { NO_MEMORY
float limit; ...
};
long exp(in float x)

raises(overflow);

Les modules IDL
Des conteneurs de définitions

Peuvent contenir : types, constantes, exceptions, interfaces, modules
permettent de structurer les applications.
module <ident> { … }
Exemple
module mesAnimaux {
…
module alaVille { …};
module alaCampagne { …};
…
};
Toutes les définitions d’un module sont «visibles» grâce à l’opérateur de
résolution de portée ::
Ex. mesAnimaux::alaVille::...

Les interfaces IDL
Ce sont des points d’accès aux objets CORBA

(identiques aux interfaces de Java ou aux classes abstraites de C++).
• Peuvent contenir : types, constantes, exceptions, attributs, opérations

• Peuvent hériter leur structure d’une ou de plusieurs autres interfaces
• Contiennent des opérations qui prennent des paramètres et retournent un résultat
in : entrée inout : entrée/sortie out : sortie
interface <ident> : <heritage> { …};
Exemple
interface B {
void f (in float T);
};
interface A : B { …}; // utilise B

Les interfaces IDL
En plus des opérations, les interfaces contiennent aussi des Attributs :

• les variables publiques des interfaces (accessibles par tous les clients)
• Peuvent être lus ou écrits par les clients (sauf si déclarés readonly)
• Chaque attribut est associé à deux méthodes (appelées setter/getter)
permettant de le lire et de l’écrire (seulement setter pour readonly)
attribute <type> <ident>;

readonly attribute <type> <ident>;
IDL Langage de programmation
attribute float rayon; float rayon();

void rayon(float value);
readonly attribute long age;
int age();

Développement Java
Développement d’une application client/serveur CORBA/Java
1. Ecrire en IDL les interfaces des objets serveurs

2. Implanter en Java ces interfaces
3. Ecrire le programme Java qui instancie les objets serveurs
4. Ecrire le programme Java qui réalise les appels des objets serveurs
4 1 2 3
Prog. Interface Prog.
client IDL Implantation serveur
Générés par
Souche le compilateur Squelette
statique de langage IDL statique
Adaptateur d ’objets
Noyau de l ’ORB

Projection des types de base
L ’étape 2 nécessite de connaître la traduction (mapping) Java des éléments IDL
IDL Java
[unsigned] short short
[unsigned] long int
[unsigned] long long long
float float
double double
char, wchar char
string, wstring Java.lang.String
boolean boolean
octet byte
any org.omg.CORBA.Any
void void
long double non supporté

Projection des types construits
IDL Java
module package
interface interface
attribute Méthodes setter/getter
opération Méthode Java
struct, enum, union Classes Java

sequence Tableau Java
const static final
Sous-classe de
exception
java.lang.Exception
Rmq. Les constructions IDL qui n’ont pas d’équivalent en Java sont traduites
par des classes

Projection des interfaces
Exemple de correspondance IDL - Java
IDL Java
module M { package M;
interface I {
long meth (in long arg) interface I {
raises (e); int meth ( int arg)
throws e;
attribute float a;
float a();
readonly void a ( float value);
attribute double d; double b();
} }
exception e { … } class e extends Java.lang.Exception
} { ... }

Projection des interfaces
Pour chaque interface IDL, le traducteur IDL vers Java génère

• une interface Java <interface>.java
• une classe pour le squelette <interface>POA.java
• une classe pour la souche _<interface>Stub.java
• une classe dite Helper <interface>Helper.java
• une classe dite Holder <interface>Holder.java
•Une classe dite <interface>Operations.java qui contient les services offerts
La classe <interface>Helper.java permet de :

• lire et écrire des objets implantant cette interface dans un flux (read() et write())
• convertir un objet CORBA en type Java (Cast) : narrow()
• les classes Helper existent déjà également pour les types simples (IntHelper, …)
La classe <interface>Holder.java gère les modes de passage inout

et out (inexistant en Java natif).

Exemple complet/1
Construction d'une interface IDL qui sera partagée par le client et le serveur
// fichier Specification.idl
module ReverseApp
{
interface Reverse
{
string reverseString(in string chaineOrigine);
};
};
Projection en Java sur la machine du serveur :

On peut générer les squelettes avec la commande suivante :
idlj –fall Specification.idl

Exemple complet/2
Un sous-répertoire pour le package ReverseApp est généré : il correspond
au module de même nom.
Les fichiers générés dans le répertoire ReverseApp par le compilateur idlj

sont :
- Reverse.java : interface Java de l'interface IDL dérivant elle-même de
l'interface ReverseOperations, de CORBA.Object et de IDLEntity.
- ReverseHelper.java : Classe qui regroupe des méthodes d'utilisation
(lect/écrit, conversion) des objets distribués;
- ReverseHolder.java : Classe "enveloppe" pour le passage de
paramètres
- ReverseOperations.java : contient toutes les opérations définies dans
l’interface IDL. Dans cet exemple, elle contient la méthode reverseString().
- ReversePOA.java : squelette de l'objet Reverse utilisé pour
implémenter le service.
- _ReverseStub.java : souche de l'objet Reverse utile côté client.

Exemple complet/3
Le fichier Reverse.java généré est le suivant :

package ReverseApp;
/**
* ReverseApp/Reverse.java .
* Generated by the IDL-to-Java compiler (portable), version
"3.2"
* from Reverse.idl
* vendredi 17 octobre 2008 17 h 04 CEST
*/
public interface Reverse extends ReverseOperations,

org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity
{
} // interface Reverse

Exemple complet/4
La projection des méthodes de Reverse se trouve dans l'interface

ReverseOperations.java :
package ReverseApp;
/**
* ReverseApp/ReverseOperations.java .
* Generated by the IDL-to-Java compiler (portable), version
"3.2"
* from Reverse.idl
* vendredi 17 octobre 2008 17 h 04 CEST
*/
public interface ReverseOperations

{
String reverseString (String chaineOrigine);
} // interface ReverseOperations

Ecrire le serveur : Serveur.java /1
import org.omg.CORBA.ORB;
import org.omg.CosNaming.NameComponent;
import org.omg.CosNaming.NamingContextExt;
import org.omg.CosNaming.NamingContextExtHelper;
import org.omg.PortableServer.POA;
import org.omg.PortableServer.POAHelper;
import ReverseApp.*; // contient les souches
public class Serveur {

public static void main(String args[]) {
try { // creer et initialiser l'ORB
ORB orb=ORB.init(args, null);
//obtenir la reference de rootpoa & activer le POAManager

POA rootpoa =
POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();

// Suite du serveur : Serveur.java
// creer une instance du servant

ReverseServant revRef1= new ReverseServant();
//obtenir la reference CORBA du servant

org.omg.CORBA.Object ref1 = rootpoa.servant_to_reference(revRef1);
Reverse href = ReverseHelper.narrow(ref1);
// recuperer le contexte de nommage
org.omg.CORBA.Object objRef=
orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
//bind the Object Reference in Naming

String name1 = "MyReverse";
NameComponent path1[] = ncRef.to_name( name1 );
ncRef.rebind(path1, href);

// Suite du serveur : Serveur.java
System.out.println("ReverseServer est pret et est en attente ...");
// wait for invocations from clients

orb.run();
}
catch(Exception e) {
System.err.println("Erreur : "+e);
e.printStackTrace(System.out);
}
}
} // fin du serveur

C’est dans le servant que l’on écrit le code des opérations définies dans le fichier
IDL :
// le servant hérite du squelette ReversePOA

class Servant extends ReversePOA {
public String reverseString(String chaineOrigine) {
int longueur=chaineOrigine.length();
StringBuffer temp = new StringBuffer (longueur);
for (int i=longueur; i>0; i--) {
temp.append(chaineOrigine.substring(i-1, i));
}
return temp.toString();
}
} // fin de Servant

Compilation du serveur
Machine_serv> ls
Specification.idl Serveur.java ReverseApp/
Machine_serv> ls ReverseApp/
Reverse.java ReverseOperations.java
ReversePOA.java ReverseHelper.java
ReverseHolder.java _ReverseStub.java
Machine_serv> javac Serveur.java ReverseApp/*.java

Machine_serv> ls
Specification.idl Serveur.java Serveur.class
Servant.class ReverseApp/

Écrire le client Client.java/1
import org.omg.CORBA.ORB;
import org.omg.CosNaming.NamingContextExt;
import org.omg.CosNaming.NamingContextExtHelper;
import ReverseApp.*;
public class Client {

public static void main (String args[]) {
try {
// creer et initialiser l'ORB
ORB orb = ORB.init(args, null);
//recuperer le contexte de nommage

org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

Écrire le client ReverseClient.java/2
// demander la reference de l'objet au service de noms

String nom1 = "MyReverse";
Reverse Ref1 = ReverseHelper.narrow (ncRef.resolve_str(nom1));
String P="Paris";
String resultat=Ref1.reverseString(P);
System.out.println("Le mot inverse de " + P +" est :" + resultat);
}
catch(Exception e) {
System.out.println("Erreur : " + e);
e.printStackTrace(System.out);
}
} // fin du main
} // fin de la classe

Qu’il s’agisse du client ou du serveur, la ligne suivante est obligatoire
ORB orb = ORB.init( args, null);
Elle est équivalente à :
Properties props = new Properties ();

props.put("org.omg.CORBA.ORBInitialPort", "900");
props.put("org.omg.CORBA.ORBInitialHost", "localhost");
ORB orb = ORB.init( args, props);

Compilation du client
Machine-cli> ls
Specification.idl
Machine-cli> idlj Specification.idl
Machine-cli> ls
Specification.idl ReverseApp/
Machine-cli> ls ReverseApp/
Reverse.java ReverseOperations.java
_ReverseStub.java ReverseHelper.java
ReverseHolder.java
Machine-cli> javac Client.java ReverseApp/*.java
Machine-cli> ls
Specification.idl Client.java Client.class ReverseApp/
Machine-cli>

Exécution de l’application :
Lancer le service de nommage en lui associant un numéro de port supérieur à 1024.

Pour le lancer sur son numéro de port par défaut (qui est de 900), il faut être root.
Sous Unix :
Machine-serv> tnameserv –ORBInitialPort 1500&
Sous Windows :
Machine-serv> start tnameserv –ORBInitialPort 1500&
Lancer le serveur :
Machine-serv> java Serveur –ORBInitialPort 1500&

Exécution de l’application (suite) :
Lancer le client.
Sous Unix :
Machine-cli> java Client –ORBInitialHost serv.cnam.fr
–ORBInitialPort 1500
La chaine inversee de Paris est : siraP

Machine-cli>

Bibliographie de base (CORBA)
- Cours CORBA, DESS Informatique, C. Bertelle & D. Olivier, Université du Havre, 2001.
-Cours CORBA, Cycle C, Laurence Duchien, CEDRIC-CNAM, 2000.
- Au cœur de CORBA avec Java, J. Daniel, Ed. Vuibert, Nlle Edition, 2002.
- Client/Server Programming with JAVA and CORBA, Robert Orfali & Dan Harkey,
2ème édition, John Wiley & Sons Inc, 1998.
-Tutorial de Java IDL utilisant idlj à partir de JDK1.3:

http://java.sun.com/j2se/1.3/docs/guide/idl/index.html
Technologie Java IDL à Javasoft :

http://java.sun.com/products/jdk/idl/index.html
-le site officiel de l’OMG :
http://www.omg.org

Intro CoursCORBA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro CoursCORBA

Uploaded by

Copyright:

Available Formats

Planning

Séance1 : 10 Octobre Bouzefrane Introduction Séance9 : 5 décembre Farinone

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 1

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 2

Intergiciel : une terminologie pour une classe de logiciels systèmes

Fournit une API d’interactions de communication: interactions de

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 3

Intergiciels de bases de données (ODBC)

Intergiciels à appel de procédure distante (DCE)

Intergiciels à objets répartis (CORBA, JAVA RMI)

Intergiciels à composants (EJB, CCM, Web services)

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 4

Common Object Request Broker Architecture

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 5

- Intégration de logiciels d’origines diverses

- Accès aux logiciels à l’intérieur et à l’extérieur des sociétés via Internet :

• gestion d’agences ou succursales pour une entreprise

• échange clients et fournisseurs (e-commerce par exemple)

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 6

IBM AS/400 Cray

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 7

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 8

Un serveur et Des services et des clients Des objets distribués

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 9

Souche Décodage résultats

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 10

- Construire un environnement dont les spécifications sont standardisées

- s’affranchir des solutions purement propriétaires

- offrir une plate-forme multi-systèmes et multi-langages

Motivations pour l’approche Objet

- l’application modélise directement des objets réels du domaine

- obtenir une architecture logicielle claire et simple

- avoir une conception modulaire (masquage des détails d’implantation)

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 11

- CORBA : Common Object Request Broker Architecture

Objets : entités identifiées qui fournissent des services

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 12

OMG : organisation non commerciale fondée en 1989 (USA)

Plus de 1000 membres :

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 13

• OMA : Object Management Architecture

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 14

Object Request Broker (ORB)

naming event Concur. query time

lifecycle Transac. security licensing Persist.

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 15

- Bus logiciel (ORB : Object Request Broker)

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 16

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 17

Object Request Broker (ORB)

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 18

- Nécessité d’un langage de description des interfaces contractuelles pour

- IDL (Interface Description Language) : est le langage de description de toutes

- Projection des interfaces IDL dans le langage des applicatifs.

- Toutes les technologies CORBA sont décrites en IDL.

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 19

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 20

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 21

IDL (Interface Definition Language)

•Mapping : correspondance entre IDL et un langage de programmation

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 22

<types> typedef string Tadresse;

CNAM - Laboratoire CEDRIC Samia BOUZEFRANE (samia.bouzefrane@cnam.fr) 23

Types de base : Exemple :