Les services communs CORBA

Transcription

CORBA : suite
- Les services communs
- Les composantes du bus
© 2008, Mireille Fornarino, E.P.U. Nice-Sophia Antipolis
-1-
Services communs CORBA
-2-
III. Corba
Les services communs CORBA
Services
a 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
a Services concernant la vie des objets :
Life Cycle, Property, Relationship, Externalization, Persistent Object,
Query, Collection, Versionning, Time, Licencing
aServices de sûreté de fonctionnement :
Security, Transactions, Concurrence
a Services de communications asynchrones:
Events, Notification, Messaging
-3-
Le contrat IDL
Le contrat IDL du service
duNommage
service Nommage
module CosNaming
III. Corba
Services
{ typedef string Istring;
struct NameComponent {.
string id;
string kind; };
typedef sequence<NameComponent> Name; // Un chemin d’accès = une suite de noms.
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 { };
void bind(in Name n, in Object obj) // Associer un nom à une référence.
raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
Object resolve (in Name n) raises(NotFound, CannotProceed, InvalidName);
// Autres opérations :
rebind
rebind_context
unbind
©//2008,
Mireillebind_context
Fornarino, E.P.U. Nice-Sophia
Antipolis
};
// new_context bind_new_context
// destroy list
-4-
Comment retrouver la référence du service
de nommage ?
III. Corba
Services
C’est un « objet notoire » du bus CORBA de nom NameService
Quelque soit le langage, le scénario est
a. opération CORBA::ORB::resolve_initial_references
b. 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);
-5-
III. Corba
Utilisations du service Nommage
Services
Enregistrer une référence
diffusion par un serveur de ses références d’objet
• création d’un chemin
• opération bind ou rebind
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);
Rechercher une référence
(2) création d’un chemin valide
(3) opération resolve
(4) conversion vers le type nécessaire
CORBA::Object_var objRef = context->resolve (nsNom);
bankServer_var bnp = bankServer::_narrow (objRef);
-6-
Obtenir le service de Nommage en Java
import org.omg.CosNaming.*;
...
//retrouver la référence de l ’objet notoire « NameService »
org.omg.CORBA.Object objRef = null;
try {
objRef = orb.resolve_initial_references ("NameService");
} catch( org.omg.CORBA.ORBPackage.InvalidName e ) {
outils.ARRET ("Le service initial NameService est inconnu");
}
//la convertir en une référence à un objet
//de type CosNaming::NamingContext
NamingContext nsRef = NamingContextHelper.narrow(objRef);
if ( nsRef == null ) {
outils.ARRET ("Le service initial 'NameService' n'est pas
un objet CosNaming::NamingContext");
-7-
Notion de chemin d’accès
-8-
Créer un nom/chemin en Java
import org.omg.CosNaming.*;
//créer un chemin simple
NameComponent[] nsNom = new NameComponent [1];
nsNom[0] = new NameComponent( "grilleA ", "");
//créer un chemin composé
nsNom[0] = new NameComponent( "appli", "");
nsNom[1] = new NameComponent(
"grille ", "");
-9-
Enregistrer un objet
• Opération pour publier un Objet
– en général, opération réalisée par le serveur
• Scénario Type
1. Créer un objet
2. 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);
- 10 -
Enregistrer un objet en Java
//créer un chemin
nsNom[0] = new NameComponent("MONOBJET","");
//enregistrer l ’objet
try {
nsRef.bind (nsNom, uneRefObjet);
} catch (org.omg.CosNaming.NamingContextPackage.NotFound enf) {
. . .
} catch(org.omg.CosNaming.NamingContextPackage.AlreadyBound eab){
. . .
} catch(org.omg.CosNaming.NamingContextPackage.CannotProceed
ecp){
. . .
} catch(org.omg.CosNaming.NamingContextPackage.InvalidName ein) {
. . .
- 11 -
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)
- 12 -
Retrouver un objet en Java
//créer un chemin
nsNom[0] = new NameComponent("MONOBJET","");
//retrouver l ’objet
org.omg.CORBA.Object objRef = null;
try {
objRef = nsRef.resolve (nsNom);
} catch (org.omg.CosNaming.NamingContextPackage.NotFound enf) {
. . .
} catch(org.omg.CosNaming.NamingContextPackage.CannotProceed ecp){
. . .
} catch (org.omg.CosNaming.NamingContextPackage.InvalidName ein) {
. . .
}
//convertir la référence
Grille uneRefObjet = GrilleHelper.narrow (objRef);
- 13 -
III. Corba
Le service de notification d'événements
Services
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é :
9 lorsque le client et l’objet ne se connaissent pas;
9 lorsque le client et l’objet ne sont pas actifs simultanément.
- 14 -
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
- 15 -
III. Corba
Un canal d’évènements
Flot des évènements
Services
Consommateur
Producteur
Consommateur
Producteur
Canal
Consommateur
Consommateur
- 16 -
III. Corba
Un canal d’évènements : notification
Services
PushConsumer
Consommateur
PushSupplier
Push
Producteur
void push(in any data) raises(Disconnected);
Consommateur
Producteur
Push
Canal
Consommateur
Consommateur
Producteur actif / Consommateur réactif
Le canal diffuse les évènements
- 17 -
III. Corba
Un canal d’évènements : demande
Services
Consommateur
Pull()
Producteur
Consommateur
Producteur
Pull()
Canal
Consommateur
PullSupplier {
demande
//demande de production d’un événement
any pull() raises(Disconnected);
Consommateur
// présence d’un événement
any try_pull(out boolean has_event) raises(Disconnected);
Producteur réactif / Consommateur actif
Le canal procure les évènements
- 18 -
III. Corba
Un canal d’évènements : file d’évènements
Services
Consommateur
Pull()
Producteur
Consommateur
Producteur
Push()
Canal
Consommateur
Consommateur
Producteur actif / Consommateur actif
Le canal gère des files d’évènements
- 19 -
Un canal d’évènements : collecte
d’évènements
III. Corba
Services
Consommateur
Push()
Producteur
Consommateur
Producteur
Pull()
Canal
Consommateur
Consommateur
Producteur réactif / Consommateur réactif
Le canal est une entité active voire intelligente
- 20 -
III. Corba
Le service de Transaction
Services
Le service de Transaction 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).
- 21 -
Composantes du bus
- 22 -
CORBA : les composantes du bus
Adaptateur d’objet
Interface du bus
Interface de Squelettes Statiques
Interface d’Invocation Statique
Interface de Squelettes Dynamiques
Interface d’Invocation Dynamique
SSI
SII
DSI
DII
ORB
OA
Noyau de communication
IR
Référentiel
des interfaces
ImplR
Référentiel
des implantations
- 23 -
Architecture générale
fichier
IDL
Client
Implémentation d’objet
pré-compilateur
SSI
DII
SII
Stub
client
DSI
Interface
ORB
Interface de
l ’adaptateur
Adaptateur d’Objet
noyau de l ’Object Request Broker (ORB)
Référentiel
des interfaces
Rint
Référentiel
des implémentations
Rimp
- 24 -
OMG-IDL : compilation
• Projection des descriptions OMG-IDL vers les langages
d’implantation des clients et serveurs.
– mode « statique »
• Instanciation sous forme d’objets CORBA des descriptions OMGIDL dans un référentiel des interfaces commun.
– mode « dynamique »
- 25 -
III. Corba
CORBA : le mode statique
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
Stub
IDL
Contrat
IDL
Bus CORBA
Fournisseur
d ’objets
Squelette
IDL
• 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.
- 26 -
Architecture CORBA
ORB serveur
POA
Référence
d’objet
(IOR)
ORB client
réseau
Requête
Interface
d’objet
Requête
Objet
Corba
POA
id
Activation
Objet
d’implantation
- 27 -
Fichiers générés
•
Interfaces :
– Gestionnaire
– GestionnaireOperations
•
Classes utilitaires :
– GestionnaireHelper : conversion de type, insertion dans un Any, extraction, obtenir le TypeCode
– GestionnaireHolder : gestion du passage des paramètres en mode inout/out
•
Stub : _GestionnaireStub
– envoie de requêtes
– invisible par le programmeur
– instancié automatiquement par GestionnaireHelper (narrow)
•
Skeleton : GestionnairePOA
– reçoit et décode des requêtes
– doit être héritée par l’implantation
- 28 -
Hiérarchie en Java
<<Abstraite>>
org.omg.CORBA.portableObjectImpl
org.omg.PortableServer.Servant
<<Interface>>
étend
GestionnaireOperations
étend
<<Interface>>
Implémente
Gestionnaire
étend
_GestionnaireStub
étend
<<abstract>>
GestionnairePOA
étend
<<Interface>>
Org.omg.CORBA.Object
Gestionnaire_Impl
Standard
Généré
À implémenter
- 29 -
III. Corba
mode statique
La projection client
Fichier
OMG-IDL
Référence d’objet
Requête
stubs
Compilation
vers client
ex : IDL/C++
Cl_a
Cl_b
Cl_c
vers le bus
- 30 -
III. Corba
Stub ou Proxy …..
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 l’ORB.
¾ 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".
- 31 -
Extrait d’un stub
public String say_hello(String _ob_a0)
{
…
if(!this._is_local())
{
org.omg.CORBA.portable.OutputStream out = null;
org.omg.CORBA.portable.InputStream in = null;
try
{
out = _request(“say_hello", true);
out.write_string(_ob_a0);
in = _invoke(out);
String _ob_r = in.read_string();
return _ob_r;
}
- 32 -
III. Corba
mode statique
La projection serveur
Fichier
OMG-IDL
squelettes
Compilation
vers serveur
ex : IDL/Java
Impl_a
Cl_a
Impl_b
Cl_b
Impl_c
Cl_c
Obj
Requête du bus
- 33 -
III. Corba
Squelette statique (skeleton)
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 l’ORB 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 ».
- 34 -
Extrait d’un squelette (HelloServicePOA)(I)
public org.omg.CORBA.portable.OutputStream invoke(
String opName,
org.omg.CORBA.portable.InputStream in,
org.omg.CORBA.portable.ResponseHandler handler)
{
final String[] _ob_names ={ "getClone", "hello"};
…
switch(_ob_index)
{
case 0: // getClone
return _OB_op_getClone(in, handler);
case 1: // hello
return _OB_op_hello(in, handler);
}
throw new org.omg.CORBA.BAD_OPERATION();
}
- 35 -
Extrait d’un squelette (HelloServicePOA)(II)
private org.omg.CORBA.portable.OutputStream
_OB_op_getClone(org.omg.CORBA.portable.InputStream in,
org.omg.CORBA.portable.ResponseHandler
handler)
{
org.omg.CORBA.portable.OutputStream out = null;
String _ob_a0 = in.read_string();
HelloService _ob_r = getClone(_ob_a0);
out = handler.createReply();
HelloServiceHelper.write(out, _ob_r);
return out;
}
- 36 -
- Invocations DynamiquesAdaptateur d’objet
Interface du bus
SSI
SII
DSI
DII
ORB
OA
IR
Référentiel
des interfaces
ImplR
Référentiel
des implantations
- 37 -
III. Corba
CORBA : le mode dynamique
mode dynamique
• 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.
- 38 -
III. Corba
Interface d'invocation dynamique (1)
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
invoke
send_deferred + get_response, poll_response
send_oneway
invoke
wait
send-deferred
send_oneWay
get_response
- 39 -
III. Corba
Interface d'invocation dynamique (2)
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;.
- 40 -
III. Corba
invocation dynamique (3)
9 Etapes
1. trouver la référence d ’un objet
mode dynamique
(string_to_object)
2. recherche et interprétation de son interface dans le référentiel
des interfaces;
get_interface -> CORBA::InterfaceDef
3. obtenir la description de l ’opération à invoquer
lookup_name, describe, …..
4. construction d'un objet requête;
construire la liste des arguments à transmettre
create_request, …..
5. invocation de la requête
6. traiter les résultats retournés.
- 41 -
4. Corba
Interface de squelette dynamique
Composants
• Analogue au DII mais du côté serveur.
• 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.
• 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.
- 42 -
Adaptateur d’objet
Interface du bus
SSI
SII
DSI
DII
ORB
OA
IR
Référentiel
des interfaces
ImplR
Référentiel
des implantations
- 43 -
III. Corba
Référentiel d’interfaces
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 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
- 44 -
III. Corba
Référentiel d’implémentations
Référentiels
. Responsable de l’enregistrement des serveurs dans le système
(enregistrement de la commande exécutable).
. Spécifié par une interface IDL.
- 45 -
Interfaces de base du Bus
Object
III. Corba
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(); ………………………………………...
- 46 -
III. Corba
Object Adapter : fonctions
Adaptateur
Intermédiaire entre le bus et
les implantations possibles des objets
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é
Servant
Proxy
POA
- 47 -
III. Corba
Portable Object Adapter
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)
- 48 -
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
- 49 -
III. Corba
POA
Adaptateur
« Pont entre les requêtes arrivant 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.
- 50 -
III. Corba
POA manager
Adaptateur
• Associé à un POA lors de la création de ce dernier (il ne peut pas être
changé)
Application serveur
dispatch
Requête
ORB
POA
Manager
Servants
POA
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.
- 51 -
III. Corba
Diagramme d’état du POA Manager
Adaptateur
- 52 -
III. Corba
POA Policies
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 d’implémentation)
• ImplicitActivationPolicy (activation automatique ou non des servants)
• RequestProcessingPolicy (gestion ID-to-servant)
• ServantRetentionPolicy (gestion mémoire des servants)
• ThreadPolicy
- 53 -
The seven POA policies are all derived from the CORBA::Policy base interface. Each controls a different
aspect of the implementation of an object. We briefly describe the purpose of each policy here
POA
Policies
• LifespanPolicy : The life span policy
controls
whether a reference is transient or persistent. A transient
reference works only for as long as its POA remains in existence and then become permanently nonfunctional. Therefore, transient references do not survive server shut-down. Persistent references
continue to denote the same object even if the server is shut down and restarted.
• IdAssignmentPolicy : The ID assignment policy controls whether the object ID that is part of the
object key of every reference is created by the ORB or is provided by the application. Transient
references usually use IDs that are created by the ORB, whereas persistent reference usually use IDs
that are provided by the application. The POA maintains a lookup table known as the Active Object
Map (AOM) that associates each object ID with the address of the corresponding servant in memory.
This means that each object ID must uniquely identify a servant; otherwise, the POA could end up with
a single object ID designating two servants simultaneously and would not know which servant to give
the request to.
• IdUniquenessPolicy: The ID uniqueness policy determines how object references are mapped to C++
servants. You can choose to use one servant for each CORBA object that is provided by a server, or you
can choose to incarnate multiple CORBA objects with the same C++ servant.
• ImplicitActivationPolicy : The implicit activation policy determines whether a newly instantiated
servant must be explicitly activated (registered with the ORB) or will be activated automatically when
you first create a reference for the servant. Transient references usually use implicitly activated
servants, whereas persistent references must use explicitly activated servants.
• RequestProcessingPolicy : The request processing policy controls whether the POA maintains the
object ID-to-servant associations for you (either to multiple servants or a single servant). You can also
choose to maintain these associations yourself. Doing so is more work, but provides more powerful
implementation choices.
• ServantRetentionPolicy : The servant retention policy controls whether you keep your servants in
memory at all times or instantiate them on demand, as requests arrive from clients.
• ThreadPolicy :The thread policy controls whether requests are dispatched on a single thread or multiple
© 2008,
Mireille Fornarino, E.P.U. Nice-Sophia Antipolis
threads.
- 54 -
III. Corba
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)
Adaptateur
Request Processing Policy
USE_ACTIVE_OBJECT_MAP_ONLY (≠ USE_SERVANT_MANAGER )
Implicit Activation Policy
IMPLICIT_ACTIVATION
Thread Policy
ORB_CTRL_MODEL
- 55 -
III. Corba
Création de POA
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 CORBA::PolicyList policies;
) raises(AdapterAlreadyExists, InvalidPolicy);
readonly attribute POAManager the_POAManager;
// ...
};
// ...
};
- 56 -
III. Corba
Exemple de création de POA (en C++)
// Initialize ORB and get Root POA
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
PortableServer::POA_var root_poa=PortableServer::POA::_narrow(obj);
assert(!CORBA::is_nil(root_poa));
// Create empty policy list
CORBA::PolicyList policy_list;
// Create Controller POA
PortableServer::POA_var ctrl_poa = root_poa->create_POA(
"Controller", PortableServer::POAManager::_nil(), policy_list);
// Create Thermometer POA as a child of the Controller POA
PortableServer::POA_var thermometer_poa = ctrl_poa->create_POA(
"Thermometers", PortableServer::POAManager::_nil(), policy_list);
// Get the Root POA manager
PortableServer::POAManager_var mgr = root_poa->the_POAManager();
// Create Thermostat POA as a child of the Controller POA
PortableServer::POA_var thermostat_poa = ctrl_poa->create_POA(
"Thermostats", mgr, policy_list);
Adaptateur
Root POA
Controller
Thermometers
Thermostats
- 57 -
III. Corba
Interopérabilité
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.
- 58 -
Interopérabilité d’applications avec
CORBA
III. Corba
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 1
Communication
A1
Problème 2
Interopérabilité
...
An
Environnement X
Communication
B1
...
Bn
Environnement Y
- 59 -
III. Corba
Portabilité d’applications avec CORBA1.2 Interopérabilité
CORBA 1.2 permet de :
• résoudre le problème de communication d’applications distribuées au sein
d’un même environnement;
Problème 1 résolu
Problème 1 résolu
Communication
IDL
A1
Binding
IDL
...
Problème 2
??
Communication
IDL
An
B1
Binding
Binding
IDL
...
Bn
Binding
ORB 1.2 vendeur x
ORB 1.2 vendeur y
Environnement X
Environnement Y
- 60 -
Interopérabilité d’application avec
CORBA 2.0
III. Corba
Interopérabilité
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).
IDL
A1
Binding
IDL
...
An
Problème 2 résolu
Interopérabilité
Binding
ORB 2.0 vendeur x
Environnement X
IDL
B1
Binding
GIOP
IDL
...
Bn
Binding
ORB 2.0 vendeur y
Environnement Y
- 61 -
III. Corba
GIOP et IIOP
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.
- 62 -
III. Corba
IOR
IOR (Interoperable Object Reference)
interface OMG IDL : repository ID
adresse + port IP
clé de format libre (identifie le POA et l’objet dans le POA)
Spécifique à l’ORB
possède une forme externe diffusable
chaîne IOR : IOR: ….
- 63 -
III. Corba
CORBA 3.0
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) (RMI-IIOP)
– (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
- 64 -
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…
- 65 -
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é, …)
COTS, Tests, Fichier d’assemblage, ADL, …
- 66 -
CORBA Component Model (CCM)
• Modèle de composants côté serveur, il étend le modèle Objet CORBA
– Extensions IDLs (CIDL) , I.R. et ORB
– Modèles : Services offerts, requis, puits, sources
– Interfaces multiples d’un même composant
• Modèle de containeur
– Proche des EJB et COM
– Services offerts au client : Évènements, Transactions, Sécurité, persistance
• Modèle de « packaging » et déploiement
• Non limité à Java ou Windows : langage indépendant
- 67 -
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
- 68 -
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
- 69 -
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 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
- 70 -

Les services communs CORBA

Transcription

Documents pareils

La Communauté d`Agglomération Sophia Antipolis

Ordinateurs : Introduction - Sophia Antipolis

Programme définitif avec 1ère page

argeles-sur-mer (66)

Master MANAGEMENT DE PROJETS INNOVANTS 2016-2017

Comparatif des intergiciels présentés

CV SNOUSSI Syrine - 105 Ko

Schéma d`un territoire de l`innovation : le technopôle de Sophia

Stage de danses bulgares de 10 h 30 à 12 h 30 Animé par Maya

170130LuSa_RaquettesLes Rousses