© 2004, Mireille Fornarino - 1 - CORBA Common Object Request Broker Architecture Mise en pratique avec Orbacus en JAVA Mireille Blay-Fornarino blay@essi.fr.

Common Object Request Broker ArchitectureMise en pratique avec Orbacus en JAVA

Mireille Blay-Fornarino blay@essi.fr

Extraits de JM Geib, C. Gransart, P. Merle

http://www.iona.com/products/orbacus_home.htm

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

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?

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. »

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

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

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

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

Bus Corba : fonctions ...

Clientserveur

Référence -> faire(param1,param2,...)

réseau

010010010110110101111

Marshaling Unmarshaling

faire(param1,param2,...)

Return

Marshaling

10010110110

Return

Unmarshaling

I.5. OMAORB

Bus Corba

Souche

Smalltalk

Souche

ORB : Liaison avec « tous » les langages de programmation

I.5. OMAORB

Object Management Architecture

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

Vue d’un objet dans une application monolithique

Vue d’un objet dans une application d'objets distribués

objetstubs

sqelettes

invocation distante

objet sur clientProxy

objet sur serveurServant

impl = objet implementationLegende

Concepts (1/2)I.5. OMAModèle objet

serveur pur

invocation distante

Application 1 Application 2 Application 3

c-obj1

objet client

objet serveur

c-obj2

client pur

objet clientc-obj3

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

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

Processus de développement

Le contrat IDL

Bus CORBA SqueletteIDL

StubIDL

Fournisseurd ’objets

Clientd ’objets

3. IDL3- Le langage IDL

Un « esperanto » pour les objets

Objets Corba

É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

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

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);};

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

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

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

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)

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

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

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

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

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

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

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

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

Héritage multiple

interface A { ... }interface B : A { ... }interface C : A { ... }interface D : B, C { ...}

3. IDLDescription

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

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

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é

Grid.idl

Compilateur IDL/Java

Répertoire gridRépertoire grid

GridHelper.java

GridHolder.java

jidl … Grid.idl

GridOperations.java

• 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

Les classes Stubs et Squelettes

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

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

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

Processus A

référenceObjet

Processus A Processus B

ObjetcopieObjet

Processus B

Processus A

serialized Object

d ’objet créée

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, …

FabriqueGrilleGrille

GrilleGrille

creerGrille

L’implantation de la fabrique

FabriqueGrilleGrille

GrilleGrille

detruireGrille

Interface IDL d ’une fabrique de Grilles

module grilles {. . .interface Fabrique { Grid newGrid(in short width,in short height);}; };

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,...

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);

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)

• 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

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

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 !

© 2004, Mireille Fornarino - 1 - CORBA Common Object Request Broker Architecture Mise en pratique avec Orbacus en JAVA Mireille Blay-Fornarino blay@essi.fr.

corba et

standardization of corba

programmation corba

adoption corba

conclusion corba

mireille fornarino

objet corba orb

loma publication corba

Documents

© 2006, Occello Audrey, PolytechNice. - 1 - Module SI2...

TEXT BOOKS *Baker, Blay et al Torts Law in Principle LBC...

Jornadas Antonio Blay

Pilar Blay Thermozero

4. blay dominic restoration_degradedforestghanasmall

1 Antonio Blay Energia Personal

Model Driven orchestration Composition Master...

Confidencies Blay 1

. - 1 - Module SI4 Applications réparties Questions...

Pragmatic Programming -...

Blay...

Antonio Blay - Los Yogas

Lectura Rapida - Antonio Blay

Blay. Primers Freds

1 Mireille Blay-Fornarino – 2007/2008 EPU département SI,...

LECTURA RAPIDA Antonio Blay