- 1 - © 2004, Mireille Fornarino CORBA Common Object Request Broker Architecture se en pratique avec Orbacus en JA Mireille Blay-Fornarino [email protected] Extraits de JM Geib, C. Gransart, P. Merle http://www.iona.com/products/orbacus_home.htm
Apr 03, 2015
- 1 -© 2004, Mireille Fornarino
CORBA
Common Object Request Broker ArchitectureMise en pratique avec Orbacus en JAVA
Mireille Blay-Fornarino [email protected]
Extraits de JM Geib, C. Gransart, P. Merle
http://www.iona.com/products/orbacus_home.htm
- 3 -© 2004, Mireille Fornarino
Le problème : Intégration des applications Pas de consensus sur les langages de programmation Pas de consensus sur les plate-formes de développement Pas de consensus sur les systèmes d’exploitation Pas de consensus sur les protocoles réseau Pas de consensus sur les formats des données manipulées par les applications
Recherche d’un Consensus pour l’interopérabilité
Consensus pour l’interopérabilité1.1-histoire
« The bad news is that there will never be a single operating system, single programming language, or single network architecture that replaces all that has passed; The good news is that you can still manage to build systems economically in this environment. »
« Model Driven Architecture » by Richard Soley and the OMG Staff Strategy Group
- 4 -© 2004, Mireille Fornarino
CORBA
Common Object Request Broker Architecture : CORBA
Plate-forme client/serveur orientée objets
Un standard pour l’interopérabilité entre objets – Support pour différents langages – Support pour différentes plate-formes (interopérabilité)– Communications au travers du réseau– Des services (Distributed transactions, events, ... )– Guides et modèles de programmation
« CORBA replaces ad-hoc special-purpose mechanisms (such as socket communication) with an open, standardized, scalable, and
portable platform. »
1.2 CORBA?
- 6 -© 2004, Mireille Fornarino
consortium international créé en 1989 but non lucratif regroupement de plus de 460 organismes
• constructeurs (SUN, HP, DEC, IBM, ...)• environnements systèmes (Microsoft, OSF, Novell, ...)• outils et langages (Iona, Object Design, Borland, ...)• produits et BD (Lotus, Oracle, Informix, O2, ...)• industriels (Boeing, Alcatel, Thomson, ...)• institutions et universités (INRIA, NASA, LIFL, W3C)
I.3. OMG
http://www.omg.org
Object Management Group (OMG)
The World’s Best Standardization Process
« In addition to its technologies, OMG has the world’s best standardization process. Executing our process, building consensus as they converge on technical details, OMG members produce each new specification in nine to seventeen months. Proven in the marketplace with the standardization of CORBA, the CORBAservices, Domain Facilities, UML, the MOF, and OMG’s other modeling standards, the process is one of our group’s major assets. »
- 7 -© 2004, Mireille Fornarino
Comité technique détermine la direction de l’architecture et des normes; émet des RFI (Request For Information) pour vérifier la
disponibilité des technologies; émet des RFP (Request For Proposal) pour obtenir des
propositions de spécifications; évalue les propositions et propose une sélection; fait des recommandations au comité directeur sur les choix des
technologies.
Comité directeur prend les décisions finales pour l’adoption des spécifications.
Organisation et procéduresI.3. OMG
- 8 -© 2004, Mireille Fornarino
OMG en résuméL ’OMG prône l ’utilisation d ’une approche basée sur les technologies « objet » (devenu « modèle ») pour offrir une vue unique d ’un système distribué et hétérogène
OMA : pour l ’architecture logicielle OMA = Object Managment Architecture
MDA (Model Driven Architecture)
CORBA : pour le « middleware » techniqueCORBA = Common Object Request Broker Architecture
UML pour la modélisationUML = Unified Modeling language
MOF pour la méta-modélisationMOF = Meta-Object Facility
I.3. OMG
- 9 -© 2004, Mireille Fornarino
ORB
Objet
Coded’implantation
Référenced’objet
Interfaced’objet
RequêteActivation
Le modèle client/serveur orienté objet (1)
Objet Corba
ORB: Object Request Broker : Bus à Objets répartis
Servant
I.4. Client/serveur
- 15
-© 2004, Mireille Fornarino
ORB (2/2)
Composant central du standard CORBA qui gère :
la localisation d’objet la désignation des objets l’empaquetage des paramètres (marshalling) le dépaquetage des paramètres (unmarshalling) l’invocation des méthodes la gestion des exceptions l ’activation automatique et transparente des objets
De plus, il fournit des caractéristiques telles que : la liaison avec « tous » les langages de programmation un système auto-descriptif l ’interopérabilité entre les bus
I.5. OMAORB
- 16
-© 2004, Mireille Fornarino
Bus Corba : fonctions ...
ORB
Clientserveur
Référence -> faire(param1,param2,...)
réseau
010010010110110101111
Marshaling Unmarshaling
faire(param1,param2,...)
Return
Marshaling
10010110110
Return
Unmarshaling
I.5. OMAORB
- 17
-© 2004, Mireille Fornarino
Bus Corba
C++
Souche
Java
Souche
Smalltalk
Souche
Ada
Souche
ORB : Liaison avec « tous » les langages de programmation
I.5. OMAORB
- 18
-© 2004, Mireille Fornarino
OMA
Object Management Architecture
- 19
-© 2004, Mireille Fornarino
Description d’une architecture de Gestion d’Objets • classifiant les objets en fonction de leurs rôles et • définissant les bases des futures spécifications incluant :
une prise en compte des problèmes d’intégration dans des environnements distribués;un modèle d’objets abstrait;l’architecture du modèle de référence;InterOpérabilité entre ORBsun glossaire des termes utilisés
Object Management Architecture
Utiliser des services standardisés à la conception, l’implantation et l’exécution.
I.5. OMA
- 20
-© 2004, Mireille Fornarino
Vue d’un objet dans une application monolithique
Vue d’un objet dans une application d'objets distribués
objetstubs
sqelettes
impl
invocation distante
objet sur clientProxy
objet sur serveurServant
impl = objet implementationLegende
Concepts (1/2)I.5. OMAModèle objet
- 21
-© 2004, Mireille Fornarino
serveur pur
invocation distante
invocation distante
Application 1 Application 2 Application 3
c-obj1
objet client
objet client
s
objet serveur
c-obj2
client pur
objet clientc-obj3
s
objet serveur
invocation distantes
objet serveur
client serveur
obj1 Impl
obj2 Impl
obj3 Impl
Legende :c-obji : objet client obji
s : squeletteobji Impl : objet implementation obji
Concepts (2/2)I.5. OMAModèle objet
- 22
-© 2004, Mireille Fornarino
CO
RB
AArchitecture du modèle de référence
Bus d’objets répartis (O.R.B.)
Licences
Transactions PersistancePropriétés ChangementsEvents
Nommage Vendeur Sécurité Relations Collections Temps Externalisation
InterrogationsCyclede vie Concurrence
Services objet communs (CORBA Services)
Workflow
DataWare IHM
Administration
Utilitaires communs
Finance
Télécom
Santé
Interfacesde domaine
Objetsapplicatifs
Spécifiques
I.5. OMA
- 23
-© 2004, Mireille Fornarino
Processus de développement
- 24
-© 2004, Mireille Fornarino
Le contrat IDL
IDL
Bus CORBA SqueletteIDL
StubIDL
Fournisseurd ’objets
Clientd ’objets
3. IDL3- Le langage IDL
Un « esperanto » pour les objets
Objets Corba
- 25
-© 2004, Mireille Fornarino
Étapes de mise en oeuvre
Spécification interface IDL
Compilation interface IDL
Implantation des objets Corba
Implantation du serveur
Enregistrement du serveur
Implantation du client
Côté client Côté serveurUtilisation du service Nommage
- 26
-© 2004, Mireille Fornarino
Spécification interface IDL (1/2)
Un objet grid est un tableau contenant des valeurs.Les valeurs sont accessibles grâce aux opérateurs get et set qui peuvent être invoqués à distance.
Processus client Processus serveur
Appel de get et set sur l'objet grid distant
objets grid
1- Exemple introductif
- 27
-© 2004, Mireille Fornarino
Spécification interface IDL (2/2)
interface Grid { readonly attribute short height; readonly attribute short width; void set (in short n, in short m, in long value); long get(in short n, in short m); void copyIn(inout Grid g);};
1- Exemple introductif
- 28
-© 2004, Mireille Fornarino
Le langage IDL
Interface Definition Language
langage de spécification d’interfaces, supportant l’héritage
multiple;
indépendant de tout langage de programmation ou
compilateur (langage pivot entre applications);
langage utilisé pour générer les stubs, les squelettes et pour définir
les interfaces du Référentiel d’interface;la correspondance IDL-langage de programmation est fournie
pour les langages C, C++, Java, Smalltalk, Ada, Cobol.
3. IDLDescription
- 29
-© 2004, Mireille Fornarino
Exemple
interface account { readonly attribute float balance; attribute string description; void credit (in float f); void debit (in float f); };interface currentAccount : account { readonly attribute float overdraftLimit; };interface bank { exception reject {string reason;}; account newAccount (in string name)
raises (reject); currentAccount newCurrentAccount (in string name, in float limit)
raises (reject); void deleteAccount (in account a); };
interface attribut
opérations
exception
opérations
3. IDLDescription
- 30
-© 2004, Mireille Fornarino
Eléments IDL
Une spécification IDL définit un ou plusieurs types, constantes, exceptions, interfaces, modules,...
• pragma
• constantes
• types de base au format binaire normalisé
• nouveaux types (typedef, enum, struct, union, array, sequence)
• exceptions
• types de méta-données (TypeCode, any)
3. IDLDescription
- 31
-© 2004, Mireille Fornarino
Eléments IDL
Un module permet de limiter la validité des identificateurs
Interface : ensemble d’opérations et de types =>classe C++
Syntaxe : Interface | [<héritage>] { <interface Body>};
• opération (synchrone ou asynchrone sans résultat)• attribut (possibilité de lecture seule)
Surcharge Interdite
3. IDLDescription
Réutilisation de spécifications existantes (#include)
- 32
-© 2004, Mireille Fornarino
module unService {
typedef unsigned long EntierPositif; typedef sequence<Positif> desEntiersPositifs;
interface Premier {
boolean est_premier ( in EntierPositif nombre);desEntiersPositifs nombres_premiers (in EntierPositif nombre);
};};
module monApplication { interface MonService {
unService::EntierPositif prochainPremier(..);
Exemple
module
définitionsde type
interface
opérations
3. IDLDescription
- 33
-© 2004, Mireille Fornarino
Exemple
// Regroupe les définitions communes à ce service.module date {// Une année est codée par un entier 16 bits.
typedef short Annee; // Ensemble non borné d'années. typedef sequence<Annee> DesAnnees;
enum Mois { // Enumération des mois. Janvier, Fevrier, Mars, Avril, Mai, Juin,Juillet, Aout, Septembre, Octobre, Novembre, Decembre };// Ensemble non borné de mois.
typedef sequence<Mois> DesMois;
// Enumération des jours de la semaine. enum JourDansLaSemaine { Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche };
// Un jour est un entier 16 bits non signé. typedef unsigned short Jour;
struct Date { // Structure pour la notion de date. Jour le_jour; Mois le_mois; Annee l_annee; };// Ensemble non borné de dates.
typedef sequence<Date> DesDates;
// Regroupement de divers formats de dates. union DateMultiFormat// Le discriminant anonyme sert à choisir le format.
switch(unsigned short) { case 0: string chaine; case 1: Jour nombreDeJours; default: Date date; };
exception ErreurInterne {}; exception MauvaiseDate { DateMultiFormat date; };
// Service de traitement sur les dates. 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) raises(MauvaiseDate); };
// Service de conversion de dates. interface Convertisseur { Jour convertirDateVersJourDansAnnee (in Date d) raises(MauvaiseDate); Date convertirChaineVersDate (in string chaine) raises(MauvaiseDate); string convertirDateVersChaine (in Date d) raises(MauvaiseDate);
// L’année courante pour l’opération suivante. attribute Annee annee_courante; Date convertirJourDansAnneeVersDate (in Jour jour);
// L’année de référence des opérations suivantes. readonly attribute Annee base_annee ; Date convertirJourVersDate (in Jour jour); Jour convertirDateVersJour (in Date d) raises(MauvaiseDate);
void obtenirDate(in DateMultiFormat d1,out Date d2) raises(MauvaiseDate); };
// Héritage de spécification. interface ServiceDate : Traitement,Convertisseur {};};
3. IDLDescription
- 34
-© 2004, Mireille Fornarino
Attribut IDL
Définition d’attributinterface account {
readonly attribute float balance;attribute string description;...
};
Equivaut à :float get_balance();string get_description();void set_description(in string s);
3. IDLDescription
- 35
-© 2004, Mireille Fornarino
void op1 (in long input, out long output, inout long both);
interface account;
interface bank { account newAccount (in string name); void deleteAccount (in account old);};
Operations (1/2)
Paramètres nommés et associés à un mode
Opérations bloquantes par défaut
<uneOpération> ::= <modeInvocation> <typeRetour> <identificateur>‘ (‘ <paramètres> ‘ ) ’ <clausesExceptions><clausesContextes>
Client uneBanque
newAccountcalcul
retours
3. IDLDescription
- 36
-© 2004, Mireille Fornarino
Pourquoi différents modes de passage de paramètres ?
in : Données fournies par le client
out : Données retournées par l ’objet
inout : Données clientes modifiées par l ’objet
Répartition
Passage par copie
- 37
-© 2004, Mireille Fornarino
Opérations (2/2)
oneway void notify (in string message);
Opération non bloquante
Pas de paramètre de type out, inout ou d’exceptions
Valeur de retour : void
Pas d ’exceptions déclenchées.
Client uneBanque
notify(«ok »)
méthodefinie
3. IDLDescription
- 38
-© 2004, Mireille Fornarino
Exceptions
exception reject {string reason;}; account newAccount (in string name)
raises (reject);
exception DateErronnee {String raison; };
Des exceptions CORBA standardisées
UNKNOWN NO_PERMISSIONBAD_PARAM NO_IMPLEMENTCOM_FAILURE OBJECT_NOT_EXISTINV_OBJREF ……….
CORBA::Exception
CORBA::UserException
CORBA::SystemException
3. IDLDescription
Gestion explicite de la part du client
- 39
-© 2004, Mireille Fornarino
Définitions circulaires
module Circulaire {interface B;interface A {
void utiliséB(in B unB);}interface B {
void utiliséA(in A unA);}
3. IDLDescription
- 40
-© 2004, Mireille Fornarino
Héritage multiple
interface A { ... }interface B : A { ... }interface C : A { ... }interface D : B, C { ...}
A
B C
D
3. IDLDescription
- 41
-© 2004, Mireille Fornarino
Types de base et autres types
Types de base• short• long• unsigned short• unsigned long• float• double• char• boolean• octet•…...
Types construits• struct• union• enum
Types génériques• array• sequence• string
MétaTypes•any•TypeCode
Types de données dynamiques et auto-descriptifs
3. IDLDescription
- 42
-© 2004, Mireille Fornarino
Type Any
interface PileDeChaines {readonly attribut string sommet;void poser(in string valeur);string retirer();
};
interface PileGénérique {readonly attribut Any sommet;readonly attribut TypeCode typeDesValeurs;void poser(in Any valeur);Any retirer();
};
3. IDLDescription
- 43
-© 2004, Mireille Fornarino
Grid.java
Exemple Compilation interface IDL vers Java
Client
_GridStub.java GridPOA.java
Serveur
Grid_Impl.javaClient.java
Serveur.java
A écrire
Généré
1- Exemple introductif
Grid.idl
Compilateur IDL/Java
Répertoire gridRépertoire grid
Répertoire gridRépertoire grid
I
GridHelper.java
GridHolder.java
jidl … Grid.idl
GridOperations.java
- 44
-© 2004, Mireille Fornarino
• implantation du stubpublic class _GridStub ……. Grid
– envoie de requêtes– invisible par le programmeur– instanciée automatiquement par GridHelper (narrow)– Utilise le DII pour assurer la portabilité du binaire
• implantation du squelettepublic abstract class GridPOA ………. GridOperations
– reçoit et décode des requêtes– doit être héritée par l’implantation
1- Exemple introductif
Les classes Stubs et Squelettes
- 45
-© 2004, Mireille Fornarino
Implémentation du serveur (1)1- Exemple introductif
1. Initialiser le bus CORBA– obtenir l’objet ORB
2. Initialiser l’adaptateur d’objets– obtenir le POA
3. Créer les implantations d’objets
4. Enregistrer les implantations par l’adaptateur
5. Diffuser leurs références– afficher une chaîne codifiant l’IOR
6. Attendre des requêtes venant du bus
7. Destruction du Bus
- 46
-© 2004, Mireille Fornarino
Implémentation du client1- Exemple introductif
1. Initialiser le bus (objet ORB)
2. Créer les souches des objets à utiliser
2.a. obtenir les références d’objet (IOR)
2.b. convertir vers les types nécessaires– narrow contrôle le typage à travers le réseau
3. Réaliser les traitements
• Rem. : éviter l’opérateur bind (2.a + 2.b)– spécifique à chaque produit donc non portable
- 48
-© 2004, Mireille Fornarino
Passage d ’un objet par référence ou par valeur
Processus A Processus B
ObjetréférenceObjet
invocationd ’une méthode
résultat
Processus B
Objet
invocationd ’une méthode
Processus A
référenceObjet
Processus A Processus B
ObjetcopieObjet
Processus B
Objet
invocationd ’une méthode
Processus A
serialized Object
copie
d ’objet créée
- 49
-© 2004, Mireille Fornarino
Le cycle de vie des objets
• Problème– actuellement, 1 grille = 1 serveur– pas de création/destruction d’objets à distance– seulement invocation d’opérations
• Solution– notion de fabrique d’objets– exprimée en OMG-IDL
• C’est un canevas de conception : Design pattern– voir aussi le service LifeCycle
Autres usages de la fabrique :- gestion de droits, load-balancing, polymophisme, …
- 50
-© 2004, Mireille Fornarino
FabriqueGrilleGrille
GrilleGrille
creerGrille
L’implantation de la fabrique
- 51
-© 2004, Mireille Fornarino
L’implantation de la fabrique
FabriqueGrilleGrille
GrilleGrille
detruireGrille
- 52
-© 2004, Mireille Fornarino
Interface IDL d ’une fabrique de Grilles
module grilles {. . .interface Fabrique { Grid newGrid(in short width,in short height);}; };
- 53
-© 2004, Mireille Fornarino
Scénario d ’obtention de la référence du service de nommage
Client ou Serveur ORB
CosNaming::NamingContext
resolve_initial_references ("NameService");
conversion
ajout,retrait,lecture,...
- 55
-© 2004, Mireille Fornarino
Enregistrer un objet
• Opération pour publier un Objet– en général, opération réalisée par le serveur
• Scénario Type1. Créer un objet2. Construire un chemin d ’accès (Name)3. Appeler l ’opération « bind » ou « rebind » avec le chemin et la référence de l ’objet
void bind (in Name n, in Object obj) raises (NotFound, CannotProceed, InvalidName, AlreadyBound);
- 56
-© 2004, Mireille Fornarino
Retrouver un objet
• Opération réalisée par un client ou un serveur• Scénario type :
– construire un chemin d ’accès (Name)– appeler l ’opération « resolve » avec le chemin– convertir la référence obtenue dans le bon type
Object resolve (in Name n)
raises (NotFound, CannotProceed, InvalidName)
- 57
-© 2004, Mireille Fornarino
• Création d’une nouvelle grille et mise à disposition par le service Nommage
– 1. Initialiser le bus CORBA– 2. Obtenir le service Nommage (NS)– 3. Obtenir la fabrique depuis le NS– 4. Créer un répertoire– 5. Enregistrer le répertoire dans le NS
Une application d’administration de la fabrique
- 58
-© 2004, Mireille Fornarino
What is ORBacus? http://www.ooc.com/ob/.
ORBACUS is an Object Request Broker (ORB) that is compliant with the Common Object Request Broker Architecture (CORBA) specification (2.4 + features 3)
• Dynamic Invocation and Dynamic Skeleton Interface
•Dynamic Any
• Interface and Implementation Repository
• Pluggable Protocols
• IDL-to-HTML and IDL-RTF documentation tools
• Includes Naming, Trading, Event, Notify, Property Services,balancing,…
• Full CORBA IDL support
• C++ and Java language mappings
• Simple configuration and bootstrapping
• Portable Object Adapter
• Objects by Value
• Portable Interceptors
• Single- and Multi-threaded
• Active Connection Management
• Fault Tolerant Extensions
- 59
-© 2004, Mireille Fornarino
Conclusion
• CORBA : ça marche et c’est simple• Choisir son langage d’implantation
– C++ : complexe et moins portable– Java : portable et plus lent
• Choisir son bus– 1 bus = 1 bibliothèque– mixer les bus : c’est possible
Expérimentez en TPs !