CORBA

1
CORBA
III. Corba
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
  dexploitation
• basées sur la technologie objet.

2
ORB (1/2)
I.5. OMA ORB
ORB Object Request Broker Middleware qui gère
les relations client/serveur entre les objets
Définition du concept de Middleware Courtier
dobjets (en Français). Ensemble des logiciels
nécessaires pour permettre et organiser la
communication et léchange de messages entre
client et serveur.
3
ORB (2/2)
I.5. OMA ORB

• Composant central du standard CORBA qui gère
• la localisation dobjet
• la désignation des objets
• lempaquetage des paramètres (marshalling)
• le dépaquetage des paramètres (unmarshalling)
• linvocation 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

4
Proxies Make Remote Objects Look Local
I.5. OMA ORB

• Un proxy est un objet local qui représente un
  objet distant
• Le proxy est automatiquement créé par lORB
• Le proxy a linterface de lobjet distant
• Si lobjet distant est en C, et le client est
  en Java, le proxy sera en Java

Server Process
Client Process
implementation
proxy
CORBA Software Bus
5
Object reference semantics
I.5. OMA ORB
6
Transparence de localisation des objets
I.5. OMA ORB
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.
Machine 1
Machine 2
Direct Call
Inter-Process Call
Network Call (IIOP)
7
Bus Corba fonctions ...
I.5. OMA ORB
Client
serveur
Référence -gt faire(param1,param2,...)
Marshaling
ORB
réseau
8
ORB Liaison avec  tous  les langages de
programmation
I.5. OMA ORB
C
Java
Smalltalk
Ada
Souche
Souche
Souche
Souche
Bus Corba
9
Services objet communs
I.5. OMA Services

• 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
  dapplication
• spécification par des interfaces IDL
• leurs fonctionnalités peuvent être étendues ou
  spécialisées par héritage

10
Services CORBA
I.5. OMA Services

• 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

11
Utilitaires communs
I.5. OMA Services

• 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
• spécification par des interfaces IDL
• leurs fonctionnalités peuvent être étendues ou
  spécialisées par héritage
• indépendants des domaines dapplication
• Exemples interface utilisateur, gestion de
  l information, administration du système et
  gestion de la tâche.

12
Utilitaires communs L interface Utilisateur
I.5. OMA Services

• 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 dapplications distinctes
  (OPenDoc).
• support de l utilisateur
• aide en ligne, vérificateur de texte, tableur, .
• gestion du bureau
• scripts

13
Interfaces des domaines
I.5. OMA Services

• Les interfaces ou objets des domaines (CORBA
  Domains) (aussi dits canevas verticaux, objets
  métiers)
• spécifiques à un domaine dapplication (médical,
  financier, télécommunications, commerce
  électronique, ...)
• spécification dinterfaces IDL
• standardisées par lOMG
• leurs fonctionnalités peuvent être étendues ou
  spécialisées
• par héritage

14
Objets applicatifs
I.5. OMA Services

• Les Objets applicatifs (CORBA Applications)
• spécification par des interfaces IDL
• définis par une application de lutilisateur
• hors du champ de standardisation de lOMG
• possibilité de standardisation pour des objets
  émergents.

15
Vers une industrie du composant logiciel
I.5. OMA Services
Utilitaires communs (UC)
Interfaces de domaine (ID)
Objets applicatifs (0A)
Bus dobjets répartis (O.R.B.)
Services objet communs (SO)
16
Communication inter-ORB
I.5.OMA Interopérabilité
RMI/IIOP
IIOP
IIOP
TCP/IP network
IIOP
17
IIOP CORBA and Interoperability
I.5.OMA Interopérabilité

• CORBA 1.2 provided portability
• An application developed for one ORB can be
  recompiled for another ORB
• CORBA 2.0 provides interoperability through the
  IIOP protocol
• An object on one ORB can communicate with an
  object on another ORB

18
CORBA les composantes du bus
Adaptateur dobjet
Interface du bus
Interface de Squelettes Statiques
Interface dInvocation Statique
Interface de Squelettes Dynamiques
Interface dInvocation Dynamique
Application serveur
Application cliente
SSI
DSI
SII
DII
ORB
OA
Noyau de communication
19
Architecture générale
fichier IDL
Client
Implémentation dobjet
pré-compilateur
SSI
DSI
Interface ORB
Stub client
DII
SII
Interface de l adaptateur
Adaptateur dObjet
noyau de l Object Request Broker (ORB)
Référentiel des interfaces Rint
Référentiel des implémentations Rimp
20
OMG-IDL compilation

• Projection des descriptions OMG-IDL vers les
  langages dimplantation des clients et serveurs.
• mode  statique 
• Instanciation sous forme dobjets CORBA des
  descriptions OMG-IDL dans un référentiel des
  interfaces commun.
• mode  dynamique 

21
CORBA le mode statique
III. Corba mode statique

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

Client d objets
Fournisseur d objets
Stub IDL
Bus CORBA
Squelette IDL

• Les souches générées encapsulent lutilisation
  du bus, lactivation et la distribution des
  composants et lhétérogénéité de larchitecture.

22
La projection client
III. Corba mode statique
Fichier OMG-IDL
23
Stub ou Proxy ..
III. Corba mode statique

• Partie de code générée automatiquement par un
  compilateur IDL vers un langage de programmation
  cible.
• Code utilisé par le client lors des invocations
  statiques.
• Lien entre le client et lORB.
• Traduit les invocations du client en messages
  transmissibles sur le réseau opération
  "marshalling .
• Traduit les messages qui proviennent de l'ORB en
  données compréhensibles du client opération
  "unmarshalling".

24
La projection serveur
III. Corba mode statique
Fichier OMG-IDL
25
Squelette statique (skeleton)
III. Corba mode statique

• Partie de code généré automatiquement par un
  compilateur IDL vers un langage de programmation
  cible.
• Code utilisé par l'Adaptateur d'objet lors des
  invocations statiques.
• Lien entre lORB et l'objet d'implémentation.
• Reconstitue la requête du client de façon à
  invoquer la méthode requise opération
  unmarshalling .
• Traduit les paramètres de retour en messages
  transmissibles sur le réseau opération
  marshalling .

26
Invocation statique
III. Corba mode statique
Client
Implémentation dobjet
réponse
requête
squelette statique
squelette dynamique
Stub client
Adaptateur dObjet
ORB noyau
27
Exemple ORBACUS
28
CORBA le mode dynamique
III. Corba mode dynamique

• Un  référentiel des interfaces  stocke sous
  forme dobjets les descriptions dinterfaces
  OMG-IDL.
• Une API (DII Dynamic Invocation Interface)
  permet de construire des requêtes à lexécution.
• Une API (DSI Dynamic Skeleton Interface) permet
  de comprendre des requêtes à lexécution.

29
Interface d'invocation dynamique (1)
III. Corba 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 dopération, une liste
  de couples valeur - type (au sens de lIR) et une
  structure pour le résultat
• invoke
• send_deferred get_response, poll_response
• send_oneway

invoke
send-deferred
send_oneWay
wait
get_response
30
Interface d'invocation dynamique (2)
III. Corba mode dynamique

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

31
invocation dynamique (3)
III. Corba mode dynamique

• Etapes
• 1. 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 -gt CORBAInterfaceDef
lookup_name, describe, ..
create_request, ..
32
Interface de squelette dynamique
4. Corba Composants

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

33

• Composants du bus

34
Référentiel dinterfaces
III. Corba Référentiels

• 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 dune
  référence dobjet,
• on peut retrouver le contenu dune interface, la
  signature dune 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

35
Référentiel dimplémentations
III. Corba Référentiels

• . Responsable de lenregistrement 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.))

36
Interfaces de base du BusObject
III. Corba
module CORBA exception COMM_FAILURE //
Autres exceptions systèmes. interface Object
// Duplique une référence dobjet CORBA.
Object _duplicate() // Libère une
référence dobjet. void _release() //
Teste si une référence ne dénote aucun objet.
boolean _is_nil() // Teste si un objet
référencé nexiste plus. boolean
_non_existent() ...
37
Object Adapter fonctions
III. Corba Adaptateur
Intermédiaire entre le bus et les implantations
possibles des objets
Fonctions des Adaptateurs dobjets 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é
Servant
Proxy
POA
38
Interfaces Portable Object Adapter
III. Corba Adaptateur

• 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
• Servant
• native Servant
• POA Policies (7 interfaces)
• Servant Managers (3 interfaces)
• - initialisation paresseuse des servants
• POACurrent
• AdapterActivator (Factory dadaptateurs)

39
POA
III. Corba Adaptateur
 Pont entre les requêtes arrivants et les objets
dimplémentation leur correspondant 
Un POA gère les relations entre les références
dobjets, 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.
40
Architecture du POA et terminologie
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
41
POA manager
III. Corba Adaptateur

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

Les états possibles dun 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.
42
Diagramme détat du POA Manager
III. Corba Adaptateur
43
POA Policies
III. Corba Adaptateur

• 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 dimplémentation)
• ImplicitActivationPolicy (activation
  automatique ou non des servants)
• RequestProcessingPolicy (gestion ID-to-servant)
• ServantRetentionPolicy (gestion mémoire des
  servants)
• ThreadPolicy

44
Root POA Policies
III. Corba Adaptateur
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
45
Création de POA
III. Corba Adaptateur
module PortableServer interface
POAManager exception AdapterAlreadyExists
exception InvalidPolicy unsigned short
index interface POA POA
create_POA( in string adapter_name, in
POAManager manager, in CORBAPolicyList
policies ) raises(AdapterAlreadyExists,
InvalidPolicy) readonly attribute POAManager
the_POAManager // ... // ...
46
Exemple de création de POA (en C)
III. Corba Adaptateur
// Initialize ORB and get Root
POA CORBAORB_var orb CORBAORB_init(argc,
argv) CORBAObject_var obj orb-gtresolve_initia
l_references("RootPOA") PortableServerPOA_var
root_poaPortableServerPOA_narrow(obj) assert
(!CORBAis_nil(root_poa)) // Create empty
policy list CORBAPolicyList policy_list //
Create Controller POA PortableServerPOA_var
ctrl_poa root_poa-gtcreate_POA( "Controller",
PortableServerPOAManager_nil(),
policy_list) // Create Thermometer POA as a
child of the Controller POA PortableServerPOA_va
r thermometer_poa ctrl_poa-gtcreate_POA( "Thermo
meters", PortableServerPOAManager_nil(),
policy_list) // Get the Root POA
manager PortableServerPOAManager_var mgr
root_poa-gtthe_POAManager() // Create Thermostat
POA as a child of the Controller
POA PortableServerPOA_var thermostat_poa
ctrl_poa-gtcreate_POA( "Thermostats", mgr,
policy_list)
Root POA
Controller
Thermometers
Thermostats
47
Etapes de mise en œuvre

• Définition de l interface IDL
• Pré-compilation du fichier IDL et Projection
  vers des langages de programmation.
• Code du serveur
• Implantation des interfaces IDL
• Implantation du serveur
• Implantation des clients
• Installation et configuration des serveurs
• Diffusion et configuration des clients
• Exécution répartie de lapplication.

48
Interopérabilité
III. Corba Interopérabilité
Avant CORBA 2.0, Problème d'interopérabilité
entre ORBs.
Interopérabilité
Capacité pour un ORB A d'invoquer une opération
définie en IDL sur un objet résidant sur un ORB
B. L'ORB A et B étant des implémentations de
CORBA différentes.
49
Interopérabilité dapplications avec CORBA
III. Corba
Deux problèmes 1- communication dapplications
distribuées au sein dun même environnement 2-
interopérabilité dapplications distribuées entre
environnements hétérogènes.
Problème 1
Problème 1
Communication
Communication
Problème 2
Interopérabilité
...
...
Environnement X
Environnement Y
50
Portabilité dapplications avec CORBA1.2
III. Corba Interopérabilité

• CORBA 1.2 permet de
• résoudre le problème de communication
  dapplications distribuées au sein dun même
  environnement

Problème 1 résolu
Problème 1 résolu
Communication
Communication
Problème 2
??
...
...
ORB 1.2 vendeur x
ORB 1.2 vendeur y
Environnement Y
51
Portabilité dapplications avec CORBA 1.2
III. Corba Interopérabilité

• CORBA 1.2 permet de
• simplifier le portage dapplications entre
  environnements hétérogènes grâce au langage IDL,
  aux standardisations des bindings.

...
...
ORB 1.2 vendeur y
Environnement Y
52
Interopérabilité dapplication avec CORBA 2.0
III. Corba Interopérabilité
CORBA 2.0 permet de résoudre le problème
dinteropérabilité dapplications distribuées
entre des environnements hétérogènes grâce au
protocole de communication commun GIOP (General
Inter ORB Protocol).
Problème 2 résolu
...
...
Interopérabilité
GIOP
ORB 2.0 vendeur x
ORB 2.0 vendeur y
Environnement Y
53
Solution

• La spécification CORBA 2.0 comporte 4 nouveaux
  éléments
• le cadre architectural définissant
  linteropérabilité entre différents
• ORBs
• la définition de protocoles communs GIOP et
  IIOP
• la définition de protocoles spécifiques à un
  environnement
• ESIOP et DCE/ESIOP
• la définition de passerelles inter-ORB,
  permettant la
• communication entre différentes
  implémentations de CORBA

54
GIOP et IIOP
III. Corba Interopérabilité

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

55
IOR
III. Corba

• IOR (Interoperable Object Reference)
• interface OMG IDL repository ID
• adresse port IP
• clé de format libre (identifie le POA et lobjet
  dans le POA)
• Spécifique à lORB
• possède une forme externe diffusable
• chaîne IOR IOR .

56
Services communs CORBA
57
Les services communs CORBA
III. Corba Services

• Service de recherche dobjets 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

58
Les services communs CORBA historique
III. Corba Services

• 1er RFP 1993 - 1994
• Nommage, Cycle de vie, Notification
  d'événements, Persistance.
• 2ème RFP 1994 - 1995
• Transactions, Concurrence d accès,
  Externalisation, Relations.
• 3ème RFP 1995 - 1996
• Sécurité, Serveur de temps.
• 4ème RFP 1995 - 1996
• Propriétés, License, Serveur de requêtes.
• 5ème RFP 1996 ---
• Annuaire par fonctionnalités, Collection,
  Gestionnaire de versions.

59
Les services de recherche dobjets CORBA
III. Corba Services
Services Nommage et/ou Vendeur
60
Le service de Nommage
III. Corba Services

• Le service de Nommage ou Namming service permet
• dassocier un nom à une référence dobjet CORBA,
  relativement
• à un contexte de noms
• de retrouver la référence dobjet ainsi que
  lobjet associé
• de naviguer à l'intérieur dun contexte de noms.
• Opérations principales
• ajouter une association bind, rebind, ...
• résoudre une association resolve
• détruire une association unbind
• lister le contenu list
• détruire le contexte destroy

61
Le contrat IDL du service Nommage
III. Corba Services
module CosNaming // Le service
Nommage. typedef string Istring struct
NameComponent // Un nom dassociation.
string id string kind // Un
chemin daccès une suite de noms. typedef
sequenceltNameComponentgt 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
62
Comment retrouver la référence du service de
nommage ?
III. Corba Services
Cest un  objet notoire  du bus CORBA de nom
NameService Quelque soit le langage, le scénario
est a. opération CORBAORBresolve_initial_refer
ences b. conversion en CosNamingNamingContext
// En C, obtenir la référence du service
Nommage. CORBA_Object_var contextObj
orb-gtresolve_initial_references
("NameService") CosNamingNamingContext_var
context CosNamingNamingContext_narrow(cont
extObj)
63
Utilisations du service Nommage
III. Corba Services

• Enregistrer une référence
• diffusion par un serveur de ses références
  dobjet
• création dun chemin
• opération bind ou rebind
• Rechercher une référence
• (2) création dun chemin valide
• (3) opération resolve
• (4) conversion vers le type nécessaire

CosNamingName_var nsNom new
CosNaming_Name() nsNom-gtlength(1)
nsNom0.id (const char)  "BNP"//nom du
serveur nsNom0.kind (const char)
 "BANKSERVER"
context-gtbind (nsNom, bnpServeur)
CORBAObject_var objRef context-gtresolve
(nsNom) bankServer_var bnp bankServer_narrow
(objRef)
64
Le service Vendeur
III. Corba Services

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

65
Le service de notification d'événements
III. Corba Services

• La plupart des requêtes CORBA se traduisent par
  lexécution synchrone dune opération (le client
  connaît la référence de lobjet auquel la requête
  sadresse et le client ainsi que lobjet 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 lobjet ne se connaissent
  pas
• lorsque le client et lobjet ne sont pas actifs
  simultanément.

66
Communication événementielleprincipes de
fonctionnement
concepts de base événements, réactions
(traitements associés à loccurrence dun
événement) principe dattachement association
dynamique entre un nom dévénement et une
réaction communication anonyme indépendance
entre lémetteur et les consommateurs dun
événement
67
Un canal dévènements
III. Corba Services
Flot des évènements
Consommateur
Producteur
Consommateur
Producteur
Canal
Consommateur
Consommateur
68
Un canal dévènements notification
III. Corba Services
PushConsumer
PushSupplier
Consommateur
Producteur
Push
void push(in any data) raises(Disconnected)
Consommateur
Producteur
Canal
Push
Consommateur
Consommateur
Producteur actif / Consommateur réactif Le canal
diffuse les évènements
69
Un canal dévènements demande
III. Corba Services
Consommateur
Producteur
Pull()
Consommateur
Producteur
Canal
Pull()
Consommateur
PullSupplier //demande de production dun
événement any pull() raises(Disconnected) //
présence dun événement any try_pull(out boolean
has_event) raises(Disconnected)
demande
Consommateur
Producteur réactif / Consommateur actif Le canal
procure les évènements
70
Un canal dévènements file dévènements
III. Corba Services
Consommateur
Producteur
Pull()
Consommateur
Producteur
Canal
Push()
Consommateur
Consommateur
Producteur actif / Consommateur actif Le canal
gère des files dévènements
71
Un canal dévènements collecte dévènements
III. Corba Services
Consommateur
Producteur
Push()
Consommateur
Producteur
Canal
Pull()
Consommateur
Consommateur
Producteur réactif / Consommateur réactif Le
canal est une entité active voire intelligente
72
Le service de Transaction
III. Corba Services

• Le service de Transaction ou Transaction service
  permet dassurer
• 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 dune transaction
• dassocier plusieurs objets répartis à une seule
  et même transaction
• de coordonner la terminaison dune transaction
  (2 phase commit).

73
Le service de Concurrence
III. Corba Services
Le service de Concurrence ou Concurrency control
service permet de contrôler laccès à un objet
de manière à gérer la cohérence et la
consistance des opérations entre cet objet et
les objets quil accède ou bien qui
laccè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...).
74
Le service dExternalisation
III. Corba Services

• Le service dExternalisation ou Externalization
  service permet
• lexternalisation dun objet, cest à dire la
  représentation de
• létat de lobjet dans une séquence doctets
  (en mémoire,
• sur disque, sur réseau) transportable, de
  durée de vie illimitée
• indépendante de lenvironnement (ORB)
  dorigine.
• linternalisation des données, impliquant la
  création dun nouvel
• objet dans le même environnement ou dans un
  environnement
• différent.

75
Le service Cycle de vie
III. Corba Services

• 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 lintermédiaire
  dobjets appelés Factories
• dont la référence est accessible au client
• un objet est détruit, copié ou déplacé à laide
  dopérations définies
• dans linterface de base LifeCycleObject

76
Le service de Relations
III. Corba Services

• Le service de Relations ou Relationships service
  permet détablir
• dynamiquement des relations entre les objets
  distribués.
• Une relation est définie par un rôle, un degré,
  une cardinalité et des
• attributs.
• Trois niveaux de services
• basique service de base permettant de créer
  les relations et les objets et de naviguer à
  travers la relation, de détruire la relation
• graphes dobjet en relation
• relations spécifiques Containment (1-n) et
  référence (n-m).

77
Sécurité et temps
III. Corba Services

• 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
• dhorloges dans tous les composants dun système
  réparti.

78
4ème RFP
III. Corba Services
Le service de Propriétés (Properties) permet
dassocier dynamiquement une liste de propriétés
à un objet. Il est possible dajouter, de
supprimer, de modifier et de retrouver toute
propriété associée à un objet. Le service
dinterrogations (Query) permet dexprimer des
requêtes sur des ensembles dobjets CORBA. Le
service de License (Licensing) contrôle et gère
les rémunérations associées à lutilisation dun
service objet donné.
79
5ème RFP
III. Corba Services
Le service de Gestion des versions (Change
Management) permet de gérer lévolution des
versions des interfaces des objets ainsi que de
l'adéquation avec leurs implémentations. Le
service dAnnuaire par fonctionnalités (Trader)
permet dassocier des fonctionnalités à des
objets CORBA. Le client utilise ce service comme
lannuaire des pages jaunes. Le service de
Collection (Collection) permet de créer et de
manipuler des collections dobjets.
80
Taxonomie des services
III. Corba Services

• Nommage Annuaire par fonctionnalités
• Persistance Externalisation
• Cycle de vie Relation
• Serveur de requêtes Collections Properties
• Transaction Concurrence
• Sécurité License
• Gestionnaire des versions
• Time
• Event

81
CORBA Services en résumé
III. Corba Services

• 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

• 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
• Interfaced with the XA standard
• Security
• Complete distributed security

82
CORBA 3.0
III. Corba

• Une suite de spécifications
• Intégration de Java et lInternet
• 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

83
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 sexécute via IIOP
• Utilisation des spécifications sur le passage par
  valeur de lOMG
• Java-to-IDL
• Mais pas de chargement dynamique des stubs

84
RMI/CORBA via IIOP
implementation dun Objet CORBA
RMI client
RMI stub
CORBA Squelette
ORB
ORB
Réseau via IIOP
85
Pourquoi CORBA?

• Infrastructure largement adoptée pour la
  distribution dobjets
• Plate-forme indépendant, il permet linté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 dune compagnie (donc dUn
  produit ou dune 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 .
86
CORBA

• Pas dapproche 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 lextension des fonctionnalités
  des objets.
• Nécessité dune construction par composition
  plutôt que par héritage
• Pas de gestion automatique du cycle de vie des
  objets.
• Qui gère lactivation des objets? Pas de standard
  IMR

87
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é, )

88
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 dun même composant
• Non limité à Java ou Windows langage
  indépendant

Intégré à CORBA 3.0 spec
89
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

90
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
91
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, 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

92
Références
Composants CORBA http//umeet.uninet.edu/confere
ncias/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 HULAAS http//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