© ²2004, mireille fornarino, e.s.s.i. - 1 - common object request broker architecture architecture...

- 1 -© ²2004, Mireille Fornarino, E.S.S.I.

Common Object Request Broker Architecture

Architecture permettant de développer des applications distribuées :

standardisées

dans des environnements hétérogènes indépendants des langages de programmation et des systèmes d’exploitation;

basées sur la technologie objet.

CORBAIII. Corba


ORB (1/2)

ORB : Object Request Broker

Middleware qui gère les relations client/serveur entre les objets

Définition du concept de Middleware : Courtier d’objets (en Français).

Ensemble des logiciels nécessaires pour permettre et organiser la communication et l’échange de messages entre client et serveur.

I.5. OMAORB


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


“Proxies Make Remote Objects Look Local”

• Un proxy est un objet local qui représente un objet distant

– Le proxy est automatiquement créé par l’ORB

• Le proxy a l’interface de l’objet distant

– Si l’objet distant est en C++, et le client est en Java, le proxy sera en Java

CORBA Software Bus

Client Process Server Process

proxy

implementation

I.5. OMAORB


Transparence de localisation des objets

Si un objet invoque une opération sur un autre objet CORBA dans le même processus, certaines implémentations peuvent éviter le passage par le réseau.

Process A Process B

Machine 1 Machine 2

Direct Call

Inter-Process Call

Network Call (IIOP)

I.5. OMAORB


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


Bus Corba

C++

Souche

Java

Souche

Smalltalk

Souche

Ada

Souche

ORB : Liaison avec « tous » les langages de programmation

I.5. OMAORB


Les Services Objet (CORBA Services) :

Fonctionnalités système de bas niveau communes à la majorité

des applications distribuées.

objectif : étendre les fonctions de l ’ORB

interfaces indépendantes des domaines d’application;

spécification par des interfaces IDL;

leurs fonctionnalités peuvent être étendues ou spécialisées par

héritage;

Services objet communsI.5. OMAServices


Services CORBA• Naming

– How are objects found?

• Events– Standardized mechanism for

client notifications.

• LifeCycle– How are objects created, moved,

duplicated and deleted?

• Trader– Find objects that have certain

properties

• Transactions– Distributed 2-phase commit

• Security– Complete distributed security

• Persistent Object– Save objects to databases

• Concurrency– Managing simultaneous access

• Licensing– Managing licensed services

• Externalization– External representation of objects

• Relationship– Manage relationships between

objects that don't know about each other

• Query– Query objects on the network

I.5. OMAServices


Les utilitaires communs (CORBA Facilities) (aussi dits canevas horizontaux):

ensemble de services orientés utilisateur de plus haut niveau fournissant des fonctionnalités utiles dans de nombreuses applications;


leurs fonctionnalités peuvent être étendues ou spécialisées par

héritage;

indépendants des domaines d’application;

Exemples : interface utilisateur, gestion de l ’information,

administration du système et gestion de la tâche.

Utilitaires communsI.5. OMAServices


Collection de composants pour standardiser l ’utilisation des IHM sophistiquées.

gestion du rendu : affichage des fenêtres et des éléments graphiques de dialogue avec l ’utilisateur final.

Gestion des documents composites :Coopération visuelle d’applications distinctes (OPenDoc).

support de l ’utilisateur :aide en ligne, vérificateur de texte, tableur, ….

gestion du bureau

scripts

Utilitaires communs :L ’interface Utilisateur

I.5. OMAServices


Les interfaces ou objets des domaines (CORBA Domains) (aussi dits canevas verticaux, objets métiers):

spécifiques à un domaine d’application (médical, financier, télécommunications, commerce électronique, ...);

spécification d’interfaces IDL;

standardisées par l’OMG;

leurs fonctionnalités peuvent être étendues ou spécialisées par héritage;

Interfaces des domainesI.5. OMAServices


Les Objets applicatifs (CORBA Applications) :


définis par une application de l’utilisateur;

hors du champ de standardisation de l’OMG;

possibilité de standardisation pour des objets émergents.

Objets applicatifsI.5. OMAServices


Services objet communs (SO)

Utilitaires communs (UC)

Interfaces de domaine (ID)

Objets applicatifs (0A)

OA

SOUC

ID

ID

SO UC

UC

SO

Bus d’objets répartis (O.R.B.)

Vers une industrie du composant logiciel

I.5. OMAServices


Noyau de communication

Interface d’Invocation Statique

Interface d’Invocation Dynamique

Interface du bus

SII DII ORB

SSI DSI

OA

Interface de Squelettes Statiques

Interface de Squelettes Dynamiques

Adaptateur d’objet

IR Référentieldes interfaces ImplR Référentiel

des implantations

CORBA : les composantes du bus


pré-compilateur

fichierIDL

Client Implémentation d’objet

DII Stubclient

InterfaceORB

Référentieldes interfaces

Rint

Référentieldes implémentations

Rimp

noyau de l ’Object Request Broker (ORB)

SSI DSI

SII

Adaptateur d’Objet

Architecture générale

Interface de l ’adaptateur


• Projection des descriptions OMG-IDL vers les langages d’implantation des clients et serveurs.

– mode « statique »

• Instanciation sous forme d’objets CORBA des descriptions OMG-IDL dans un référentiel des interfaces commun.

– mode « dynamique »

OMG-IDL : compilation


• Les clients et serveurs implantent des descriptions OMG-IDL communes, statiquement précisées dans la phase de compilation/projection du source IDL.

III. Corbamode statiqueCORBA : le mode statique

Contrat IDL

Bus CORBA SqueletteIDL

StubIDL

Fournisseurd ’objets

Clientd ’objets

• Les souches générées encapsulent l’utilisation du bus, l’activation et la distribution des composants et l’hétérogénéité de l’architecture.


La projection client

FichierOMG-IDL

Cl_a Cl_b Cl_cstubsCompilationvers client

ex : IDL/C++

Référence d’objet

Requête

vers le bus

III. Corbamode statique


La projection serveur

FichierOMG-IDL

Impl_a Impl_b Impl_csquelettes

Compilationvers serveur

ex : IDL/JavaCl_a Cl_b Cl_c

Obj

Requête du bus



Invocation statique

Client Implémentation d’objet

Stubclient

Adaptateur d’Objet

ORB noyau

squelette statique

requête réponse

squelette dynamique



Exemple ORBACUS


• Un « référentiel des interfaces » stocke sous forme d’objets les descriptions d’interfaces OMG-IDL.

• Une API (DII: Dynamic Invocation Interface) permet de construire des requêtes à l’exécution.

• Une API (DSI : Dynamic Skeleton Interface) permet de comprendre des requêtes à l’exécution.

III. Corbamode dynamiqueCORBA : le mode dynamique


Permet la création dynamique de requêtes API (DII) sans passer par des souches pré-générées;

Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat

invokesend_deferred + get_response, poll_responsesend_oneway

wait

invoke

get_response

send-deferredsend_oneWay

Interface d'invocation dynamique (1)III. Corba

mode dynamique


Interface d'invocation dynamique (2)

Utilisation du référentiel des interfaces pour récupérer les informations relatives aux interfaces IDL;

Avantages :- les interfaces peuvent être découvertes dynamiquement;

- code client générique indépendant d'une interface IDL;.

III. Corbamode

dynamique


Etapes1. trouver la référence d ’un objet

2. recherche et interprétation de son interface dans le référentiel des interfaces;

3. obtenir la description de l ’opération à invoquer

4. construction d'un objet requête;construire la liste des arguments à transmettre

5. invocation de la requête

6. traiter les résultats retournés.

(string_to_object)

get_interface -> CORBA::InterfaceDef

lookup_name, describe, …..

create_request, …..

invocation dynamique (3)III. Corba

mode dynamique


Interface de squelette dynamique

• Permet de délivrer une requête à un objet implémentation qui est inconnu lors de la phase de compilation

• Interprète une requête et ses paramètres.

• Analogue au DII mais du côté serveur.

• Utiliser pour créer des ponts entre des ORBs de vendeurs différents.

•Utiliser pour intégrer des applications existantes (legacy application). Les applications peuvent ne pas être conformes aux standard CORBA et peuvent également ne pas être OO.

4. CorbaComposants


Composants du bus


Référentiel d’interfaces

Maintient les informations sur les types, les interfaces etc.....;

Un graphe d ’objets « concepts » d ’IDL : ModuleDef, InterfaceDef, OPerationDef, ..

Par navigation dans ce graphe ou à partir d’une référence d’objet, on peut retrouver le contenu d’une interface, la signature d’une opération, …

Informations pour une interface :• son module• son nom• ses attributs• ses opérations (nom, nom et types des paramètres,

exceptions, contexte)• ses héritages

III. CorbaRéférentiels


Référentiel d’implémentations

. Responsable de l’enregistrement des serveurs dans le système (enregistrement de la commande exécutable).

. Spécifié par une interface IDL.

(( Avec Orbix

• Controlé par la commande putit dans les commandes associées lsit, catit, rmit, chmodit.

• Implémenté par un processus démon.))

III. CorbaRéférentiels


Interfaces de base du BusObject

module CORBA {exception COMM_FAILURE { … };// Autres exceptions systèmes.

interface Object {// Duplique une référence d’objet CORBA.

Object _duplicate();

// Libère une référence d’objet. void _release();

// Teste si une référence ne dénote aucun objet. boolean _is_nil();

// Teste si un objet référencé n’existe plus. boolean _non_existent(); ………………………………………...

III. Corba


Object Adapter : fonctions

Fonctions des Adaptateurs d’objets:

1- Enregistrement des objets implémentation.

2- Génération et interprétation des références d'objets.

3- Activation et désactivation des objets implémentation.

4- Invocation des méthodes à travers les squelettes ou le DSI.

5- Participation à la sécurité

Intermédiaire entre le bus et les implantations possibles des objets

Proxy

Servant

POA

III. CorbaAdaptateur


Interfaces : Portable Object Adapter

Interfaces IDL définies dans le module PortableServer :• POA : Interface principale côté serveur

-quels servants sont instanciés? -Activation/désactivation, destruction des servants-Création de références, …

• POAManager- Contrôle du flot des requêtes vers plusieurs POAs

• Servantnative Servant;

• POA Policies (7 interfaces)• Servant Managers (3 interfaces)

- initialisation paresseuse des servants

• POACurrent• AdapterActivator (Factory d’adaptateurs)



POA

« Pont entre les requêtes arrivants et les objets d’implémentation leur correspondant »

Un POA gère les relations entre les références d’objets, les identificateurs et les servants

Un serveur peut contenir plusieurs POAs

Un POA gère plusieurs servants, tous avec une même politique déterminée par ses « policies » (immuables).

Le RootPOA a un ensemble fixé de Policies, il est toujours présent.

Un servant est associé à un unique POA.



Active Object Map: table des objet actifs via leur ID

Adapter activator: objet qui peut créer un POA sur demande

Object ID: identification de l'objet au sein de l'adaptateur (unique au sein d'un même adaptateur)

POA manager: objet qui contrôle l'état du POA

Policy: objet qui contrôle le comportement d'un POA et de ses objets

rootPOA: chaque ORB (serveur) est créé avec un POA racine qui permet de créer des POA fils.Servant: code qui implante les méthodes d'un objet. Servant Manager: objet gérant l'association servant-objet

Architecture du POA et terminologie


POA manager

• Associé à un POA lors de la création de ce dernier (il ne peut pas être changé)

Les états possibles d’un POA manager :

• Active : routage normale des requêtes

• Holding : Requêtes stockées

• Discarding : Requêtes rejetées avec TRANSIENT

• Inactive : Requêtes rejetées ; les clients peuvent être redirigés vers un serveur différent pour ré-essayer.

ORB POAPOA

ManagerRequête

Servants

Application serveurdispatch



POA Policies

Chaque POA a un ensemble de politiques.Lorsqu'un nouveau POA est créé on peut utiliser les valeurs par défaut

ou les fixer selon les besoins.Un POA n'hérite pas des politiques de son père.

• LifespanPolicy (références transitoires ou persistantes)

• IdAssignmentPolicy (gestion de la clef)

• IdUniquenessPolicy (association servant et objets d’implémentation)

• ImplicitActivationPolicy (activation automatique ou non des servants)

• RequestProcessingPolicy (gestion ID-to-servant)

• ServantRetentionPolicy (gestion mémoire des servants)

• ThreadPolicy



Root POA Policies

Life Span Policy TRANSIENT ( PERSISTANT)

ID Assignment Policy SYSTEM_ID ( USER_ID)

ID Uniqueness Policy UNIQUE_ID ( MULTIPLE_ID)

Servant Retention Policy RETAIN ( PERSISTANT)

Request Processing Policy USE_ACTIVE_OBJECT_MAP_ONLY ( USE_SERVANT_MANAGER )

Implicit Activation Policy IMPLICIT_ACTIVATION

Thread Policy ORB_CTRL_MODEL



• Définition de l ’interface IDL

• Pré-compilation du fichier IDL et Projection vers des langages de programmation.

• Code du serveur :Implantation des interfaces IDLImplantation du serveur

• Implantation des clients

• Installation et configuration des serveurs

• Diffusion et configuration des clients

• Exécution répartie de l’application.

Etapes de mise en œuvre


Interopérabilité

Interopérabilité

Capacité pour un ORB A d'invoquer une opération définieen IDL sur un objet résidant sur un ORB B.L'ORB A et B étant des implémentations de CORBA différentes.

Avant CORBA 2.0, Problème d'interopérabilité entre ORBs.

III. CorbaInteropérabilité


Interopérabilité d’applications avec CORBA

Environnement X

Interopérabilité An A1 ...

Environnement Y

Bn B1 ...

Deux problèmes :1- communication d’applications distribuées au sein d’un même environnement;2- interopérabilité d’applications distribuées entre environnements hétérogènes.

Problème 1

Problème 2Communication

Problème 1

Communication

III. Corba


Environnement X

??...

ORB 1.2 vendeur x

Environnement Y

ORB 1.2 vendeur y

CORBA 1.2 permet de :

• résoudre le problème de communication d’applications distribuées au sein d’un même environnement;

A1

IDL

Binding

An

IDL

Binding

... B1

IDL

Binding

Bn

IDL

Binding

Problème 1 résolu

CommunicationProblème 1 résolu

CommunicationProblème 2

Portabilité d’applications avec CORBA1.2



CORBA 1.2 permet de :

• simplifier le portage d’applications entre environnements hétérogènes grâce au langage IDL, aux standardisations des bindings.

...

Environnement Y

ORB 1.2 vendeur y

A1

IDL

Binding

An

IDL

Binding

... B1

IDL

Binding

Bn

IDL

Binding

Portabilité d’applications avec CORBA 1.2



CORBA 2.0 permet de résoudre le problème d’interopérabilité d’applications distribuées entre des environnements hétérogènes grâce au protocole de communication commun

GIOP (General Inter ORB Protocol).

Environnement X

...

ORB 2.0 vendeur x

Environnement Y

ORB 2.0 vendeur y

A1

IDL

Binding

An

IDL

Binding

... B1

IDL

Binding

Bn

IDL

Binding

GIOP

Interopérabilité

Problème 2 résolu

Interopérabilité d’application avec CORBA 2.0



GIOP et IIOP

GIOP (General Inter-ORB Protocol) spécifie un ensemble de formats pour les messages ainsi qu'une représentation commune des données échangées entre les ORBs. La représentation des données communes est basée sur la spécification CDR (Common Data Representation).

IIOP (Internet Inter-ORB Protocol) est l'implémentation du protocole GIOP basé sur TCP/IP.



IOR

IOR (Interoperable Object Reference) interface OMG IDL : repository IDadresse + port IPclé de format libre (identifie le POA et l’objet dans le POA)Spécifique à l’ORBpossède une forme externe diffusable

chaîne IOR : IOR: ….

III. Corba


Services communs CORBA


Les services communs CORBA

Service de recherche d’objets : pour retrouver un objet Nommage (Naming) : par un nom : service de « pages blanches »Vendeur (Trader) : par des propriétés: service de « pages jaunes

Services concernant la vie des objets : Life Cycle, Property, Relationship, Externalization, Persistent Object, Query, Collection, Versionning, Time, Licencing

Services de sûreté de fonctionnement : Security, Transactions, Concurrence

Services de communications asynchrones: Events, Notification, Messaging

III. CorbaServices


Services Nommage et/ou Vendeur

Bus d’objets répartis CORBA sur Internet (IIOP)

Serveur C++Client Java

Repertoire

Traitement

IOR

Service derecherched’objets

IOR

Les services de recherche d’objets CORBA

III. CorbaServices


Le service de Nommage

Le service de Nommage ou Namming service permet :

d’associer un nom à une référence d’objet CORBA, relativement à un contexte de noms; de retrouver la référence d’objet ainsi que l’objet associé; de naviguer à l'intérieur d’un contexte de noms.

Opérations principalesajouter une association : bind, rebind, ...résoudre une association : resolvedétruire une association : unbindlister le contenu : listdétruire le contexte : destroy

III. CorbaServices


Le contrat IDL du service Nommage

module CosNaming // Le service Nommage.{ typedef string Istring; struct NameComponent { // Un nom d’association. string id; string kind; };

// Un chemin d’accès = une suite de noms. typedef sequence<NameComponent> Name;

interface NamingContext { // Un contexte. enum NotFoundReason { missing_node, not_context, not_object }; exception NotFound {NotFoundReason why; Name rest_of_name;}; exception CannotProceed {NamingContext cxt; Name rest_of_name;}; exception InvalidName { }; exception AlreadyBound { }; exception NotEmpty { };

// Associer un nom à une référence. void bind(in Name n, in Object obj) raises(NotFound, CannotProceed, InvalidName, AlreadyBound);

// Rechercher une association. Object resolve (in Name n) raises(NotFound, CannotProceed, InvalidName);

// Autres opérations : // rebind bind_context rebind_context unbind // new_context bind_new_context // destroy list };};

III. CorbaServices


Comment retrouver la référence du service de nommage ?

C’est un « objet notoire » du bus CORBAde nom NameService

Quelque soit le langage, le scénario esta. opération CORBA::ORB::resolve_initial_referencesb. conversion en CosNaming::NamingContext

// En C++, obtenir la référence du service Nommage.

CORBA_Object_var contextObj = orb->resolve_initial_references ("NameService");

CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(contextObj);

III. CorbaServices


Utilisations du service Nommage

Enregistrer une référencediffusion par un serveur de ses références d’objet• création d’un chemin• opération bind ou rebind

Rechercher une référence(2) création d’un chemin valide(3) opération resolve(4) conversion vers le type nécessaire

CosNaming::Name_var nsNom = new CosNaming_Name(); nsNom->length(1); nsNom[0].id = (const char*) "BNP";//nom du serveur nsNom[0].kind = (const char*) "BANKSERVER";

context->bind (nsNom, bnpServeur);

CORBA::Object_var objRef = context->resolve (nsNom);bankServer_var bnp = bankServer::_narrow (objRef);

III. CorbaServices


Le service Vendeur

Le service vendeur ou Trader service permet : d ’enregistrer des objets auprès de ce service en les caractérisant par un ensemble de propriétés. de retrouver un service en précisant son type et les critères le caractérisant (différentes politiques de recherche possibles)

Opérations principales

découvrir et importer des services : Interface LookUp : query (type de service recherché, contraintes, préférences, politique de recherche, ….)

parcourir les réponses : Interface OfferIterator mise à jour du service Vendeur : Interface Register

export, withdraw…...

III. CorbaServices


Le service de notification d'événements

La plupart des requêtes CORBA se traduisent par l’exécution synchrone d’une opération (le client connaît la référence de l’objet auquel la requête s’adresse et le client ainsi que l’objet doivent être tous deux actifs) et sinon?

Le service d'Evénements ou Event service permet de découpler la communication entre objets.

Mode de communication découplé : lorsque le client et l’objet ne se connaissent pas; lorsque le client et l’objet ne sont pas actifs simultanément.

III. CorbaServices


Communication événementielle

principes de fonctionnement• concepts de base : événements, réactions (traitements associés à l’occurrence d’un événement)

• principe d’attachement : association dynamique entre un nom d’événement et une réaction

• communication anonyme : indépendance entre l’émetteur et les “consommateurs” d’un événement


Un canal d’évènements : notification

Producteur

Producteur

Consommateur

Consommateur

Consommateur

Consommateur

Canal

Producteur actif / Consommateur réactifLe canal diffuse les évènements

Push

Push

PushSupplierPushConsumer

void push(in any data) raises(Disconnected);

III. CorbaServices


Un canal d’évènements : demande

Producteur

Producteur

Consommateur

Consommateur

Consommateur

Consommateur

Canal

Producteur réactif / Consommateur actifLe canal procure les évènements

Pull()

Pull()

demandePullSupplier {

//demande de production d’un événement

any pull() raises(Disconnected);

// présence d’un événement

any try_pull(out boolean has_event) raises(Disconnected);

III. CorbaServices


Un canal d’évènements : file d’évènements

Producteur

Producteur

Consommateur

Consommateur

Consommateur

Consommateur

Canal

Producteur actif / Consommateur actifLe canal gère des files d’évènements

Push()

Pull()

III. CorbaServices


Un canal d’évènements : collecte d’évènements

Producteur

Producteur

Consommateur

Consommateur

Consommateur

Consommateur

Canal

Producteur réactif / Consommateur réactifLe canal est une entité active voire intelligente

Pull()

Push()

III. CorbaServices


Le service de Transaction

Le service de Transaction ou Transaction service permet d’assurer la consistance des traitements en respectant les propriétés ACID (Atomicité, Consistance, Isolation et durabilité) des transactions.

Il permet :

de commencer et de terminer une transaction; de contrôler la propagation d’une transaction;

d’associer plusieurs objets répartis à une seule et même transaction; de coordonner la terminaison d’une transaction (2 phase commit).

III. CorbaServices


Le service de Concurrence

Le service de Concurrence ou Concurrency control service permet de contrôler l’accès à un objet de manière à gérer la cohérence et la consistance des opérations entre cet objet et les objets qu’il accède ou bien qui l’accèdent.

Il permet de créer des verrous répartis et de spécifier le type de verrou crée (lecture, écriture, mise-à-jour etc...).

III. CorbaServices


Le service d’Externalisation

Le service d’Externalisation ou Externalization service permet :

l’externalisation d’un objet, c’est à dire la représentation de l’état de l’objet dans une séquence d’octets (en mémoire, sur disque, sur réseau) transportable, de durée de vie illimitée indépendante de l’environnement (ORB) d’origine.

l’internalisation des données, impliquant la création d’un nouvel objet dans le même environnement ou dans un environnement différent.

III. CorbaServices


Le service Cycle de vie

Le service Cycle de vie ou Life cycle service permet :

de gérer la création, la destruction, la copie et le déplacement des objets du bus;

les objets sont créés par l’intermédiaire d’objets appelés Factories dont la référence est accessible au client;

un objet est détruit, copié ou déplacé à l’aide d’opérations définies dans l’interface de base LifeCycleObject;

III. CorbaServices


Sécurité et temps

Le service de Sécurité (Security) permet de gérer les fonctions suivantes :

authentification autorisation sûreté et intégrité des communications encryptage administration de la sécurité

Le service de Temps (Time) permet la synchronisation périodique

d’horloges dans tous les composants d’un système réparti.

III. CorbaServices


4ème RFP

Le service de Propriétés (Properties) permet d’associer dynamiquement une liste de propriétés à un objet. Il est possible d’ajouter, de supprimer, de modifier et de retrouver toute propriété associée à un objet.

Le service d’interrogations (Query) permet d’exprimer des requêtes sur des ensembles d’objets CORBA.

Le service de License (Licensing) contrôle et gère les rémunérations associées à l’utilisation d’un service objet donné.

III. CorbaServices


5ème RFP

Le service de Gestion des versions (Change Management) permetde gérer l’évolution des versions des interfaces des objets ainsi que de l'adéquation avec leurs implémentations.

Le service d’Annuaire par fonctionnalités (Trader) permet d’associer des fonctionnalités à des objets CORBA. Le client utilise ce service comme l’annuaire des pages jaunes.

Le service de Collection (Collection) permet de créer et de manipulerdes collections d’objets.

III. CorbaServices


Taxonomie des services

Nommage + Annuaire par fonctionnalitésPersistance + ExternalisationCycle de vie + RelationServeur de requêtes + Collections + PropertiesTransaction + ConcurrenceSécurité + LicenseGestionnaire des versionsTimeEvent

III. CorbaServices


Une suite de spécifications• Intégration de Java et l’Internet

– Passage par valeur (Corba 2.3)– Java to IDL : Interopérabilité des objets RMI (2.3)

– (Firewall specification) Mid-2001

– Interopérabilité et service de nommage (2.4)

• Amélioration de la qualité de service

– Asynchronous Messaging (2.4 fin 2000)

– Corba minimum pour les systèmes embarqués

– Temps réel,

• Modèle de composants, langage de script

CORBA 3.0III. Corba


Integration de Java RMI avec CORBA : RMI-IIOP

• RMI est une solution tout-java – Un modèle simple de programmation

– “An immature middleware infrastructure”

• CORBA est un standard pour les objets distribués – Un modèle de programmation pas si simple et non dédié spécifiquement à

Java

– “A mature middleware infrastructure”

• RMI s’exécute via IIOP– Utilisation des spécifications sur le passage par valeur de l’OMG

– Java-to-IDL

– Mais pas de chargement dynamique des stubs


implementation d’un Objet

CORBA

RMI/CORBA via IIOP

RMIclient

RMI stub

ORB

CORBA Squelette

ORB

Réseau via IIOP


Pourquoi CORBA?

• Infrastructure largement adoptée pour la distribution d’objets

• Plate-forme indépendant, il permet l’intégration de systèmes propriétaires

• Langage indépendant : Clients et serveurs peuvent être implémentés dans des langages différents

• CORBA est indépendant d’une compagnie (donc d’Un produit ou d’une architecture)

• De nombreux services

• Fournit un accès multi-langages pour les EJBs.

« CORBA is the only middleware platform that is both vendor- and language-independent. »

« You still need to know what you are doing and CORBA cannot do your thinking for you ».


CORBA …

• Pas d’approche standard du déploiement – (connexion entre IMR et serveurs non standardisé) – Quels services sont disponibles sur le site de déploiement

• Pas de support des idioms de développement des serveurs CORBA– Comment « bootstrapper » les références? (naming, trader, …)– Mise en place de factories gérant le cycle de vie…

• Difficulté pour l’extension des fonctionnalités des objets.– Nécessité d’une construction par composition plutôt que par héritage

• Pas de gestion automatique du cycle de vie des objets.– Qui gère l’activation des objets? Pas de standard IMR…


COMPOSANTS, besoins

• Des unités interchangeables– Spécification de ce qui est offert

– Spécification de ce qui est nécessaire

• Déploiement standardisé semi-automatique

• Génération de code pour la mise en œuvre de certains « services » (D.P.) (Factory, persistance, sécurité, …)


CORBA Component Model (CCM)

• Modèle de composants côté serveur, il étend le modèle Objet CORBA

• Proche des EJB et COM : standardisation de– Services offerts au client : Évènements, Transactions, Sécurité, persistance

– Déploiement

– Interfaces multiples d’un même composant

• Non limité à Java ou Windows : langage indépendant

Intégré à CORBA 3.0 spec


CCM: extensions à CORBA

• Modèle de composants- Extensions IDLs (CIDL) , I.R. et ORB

-Modèle de containeur-Component Implementation Framework (CIF)-Modèle de « packaging » et déploiement-Support aux EJBs et interworking


En cours, … MDA

Over the past decade or more, companies have endured a succession of middleware platforms.

Jon Siegel, OMG Director of Technology Transfer

I think the requirements for business software will continue to evolve faster than the technology solutions and that business developers will continue to have

"programming" jobs for the rest of my career.

Carol Burt, 2AB, Inc., and OMG Architecture Board Member


Références

Client/Server Programming with Java and CORBA - R. Orfali, D. Harkey John Wiley Sons 1997.

CORBA, ActiveX et Java Beans - J. M. Chauvet Eyrolles 1997.

Architecture J2EE, Architecture J2EE, Khin Chhoung LAO, Cnam.

Éléments fondamentaux des systèmes distribués, Karim Khelifi

Distributed Computing and Client-Server Systems, Prentice Hall - Amjad Umar .

Client/Server Computing - Byte Special Report, avril 95.

Systèmes d ’exploitation - Systèmes centralisés - Systèmes distribués, Prentice Hall - Andrew Tanenbaum, 1994

Enterprise JavaBeans Specifications JavaSoft (http://www.javasoft.com/ejb)

CORBA Specifications: Object Management Group (http://www.omg.org)

http://www.ooc.com/ob/training_download.html


Références

Composants CORBA : http://umeet.uninet.edu/conferencias/acsdsevilla/ccm

CORBA Junction: IDL for CORBA 3.0, Extending the relationship between interfaces, http://www-106.ibm.com/developerworks/components/

Client-Serveur, Etude de cas: CORBA – OMG Portable Object Adapter; C. Toinard, ENSERB-3 ième année Informatique

Intégration des Systèmes Clients/Serveurs, André Freyssinet, HTTP://dyade.inrialpes.fr/~freyssin

Cours Technologie Internet: Modèles de programmation Jarle HULAAShttp://cui.unige.ch/tios/co rs/TechInternet.html

Model Driven Architecture by Richard Soley and the OMG Staff Strategy Group

Object Management Group, White Paper

Draft 3.2 – November 27, 2000

© ²2004, mireille fornarino, e.s.s.i. - 1 - common object request broker architecture architecture...

Documents