Middlewares Orientés Objet - universite.jejemaes.netuniversite.jejemaes.net/MA_1/SysDis/Cours/slides07-corbam.pdf · @ Vincent Englebert - FUNDP 2 Bibliographie Les documents de

@ Vincent Englebert - FUNDP 1

Middlewares Orientés Objet


Bibliographie

� Les documents de l'OMG voir le site du cours

� le document de référence de Corba

� le document de mapping IDL – Java

� le document de référence pour le Naming Service

� le document de référence pour le Trading Service

� le document de référence pour l'Object Transaction Service

� @Book{tanenbaum02-ds,

� author = {Andrew S. Tanenbaum, Maarten van Steen},

� title = {Distributed Systems: Principles and Paradig ms},

� publisher = prentice,

� year = 2002,

� isbn = 0130888931

� }


Plan

� Introduction� Interface Description Language (IDL)� Architecture

� Présentation globale� Le bus CORBA� Intéropérabilité entre bus CORBA� Le protocole GIOP

� CDR� GIOP� IIOP

� L’adaptateur d’objet (POA)

� Procédure de Déploiement d’une Application / Exemple.� Passage par Valeur� Localisation d’Objets Distribués� Négociation de Services� Gestion du Cycle de Vie


Introduction

� L'OMG (Object Management Group) � http://www.omg.org

� toutes les spécifications sont accessibles en ligne

� organisation fondée en 1989� regroupe plus de 800 sociétés membres (privé/public)� produits

� UML 2.0� Unified Modeling Language� Langage de modélisation

� MOF � Meta-Object Facility� Méta-modèle

� CORBA 3.0� Common Object Request Broker Architecture� CCM


Motivation

� CORBA peut être considéré comme une architecture de référence qui permet de comprendre d'autres technologies comme� les web-services� RMI� DCOM� .NET� etc etc


Là où on ne l'attend pas…

� [July 13, 2005] PrismTech Achieves Major Technical B reakthrough Porting a C++ CORBA(R) ORB to a Digital Signal Processor (DSP)

� WASHINGTON --(Business Wire)-- July 13, 2005 -- Allowing more Real-time and Embedded Applications Developers to Reap the Benefits of CORBA Technology

Today at the OMG(TM)'s Real-time and Embedded Systems Workshop, PrismTech a leading provider of productivity tools and middleware, announced it had achieved a major technical breakthrough by porting its OpenFusion e*ORB SDR C++ edition product to a Digital Signal Processor (DSP).

Digital Signal Processing is a key technology fuelling innovative, high growth applications for many of today's fast growing markets such as digital wireless, broadband access, digital audio, high-resolution imaging and digital motor control. DSP is unique because it processes data in real-time making it perfect for applications that cannot tolerate any delays.

Running CORBA middleware on a DSP achieves flexibility and simplifies integration by exposing the services offered by the DSP far more widely than is possible with any other technology. Any application where a DSP is integrated with external systems of any kind benefits from the simplified integration and enhanced flexibility provided by CORBA.

Traditional thinking suggested that due to the nature of its highly restricted environment that it was not possible to run a C++ ORB on a DSP.

Now PrismTech has been able to achieve a major breakthrough by porting its OpenFusion e*ORB C++ edition to a DSP. This has been achieved through the unique micro-kernal architecture of the C++ ORB combined with footprint optimization.

"One example of the significant benefits that can be gained from hosting OpenFusion e*ORB SDR C++ edition on a DSP is in software defined radio (SDR) development," said Andrew Foster, Product Manager, PrismTech. "Efficiently hosting a C++ ORB on a DSP is a major move forward in standardizing the interfaces in a SDRs signal processing chain and improving waveform portability. The fact that a C++ CORBA component can be hosted on a DSP means that a unified C++ language binding can now be used across GPPs and DSPs, something that was previously impossible."

OpenFusion e*ORB SDR is available for the Texas Instruments C64x family of DSPs.

� About PrismTech

Founded in 1992, with offices in the USA and Europe, PrismTech is a privately held software products company. PrismTech serves international Fortune 500 customers in the telecommunications, data communications, defense and aerospace sectors. PrismTech is an acknowledged leader in productivity tools and middleware, with solutions ranging from wide-scale integration to embedded real-time systems, supporting applications from operations support systems (OSS) through to software-defined radio (SDR). For additional information about PrismTech, visit the web site at http://www.prismtech.com.

CORBA is a registered trademark of the Object Management Group, Inc in the U.S. and other countries. OpenFusion and e*ORB SDR are trademarks of PrismTech. All other trademarks are the property of their respective owners.

http://www.tmcnet.com/usubmit/2005/jul/1162959.htm


La vision

� Le système est perçu comme un ensemble d'objets et d'applications"utilisatrices".

� Ces objets peuvent être répartis � dans des applications différentes� développées avec des langages différents� sur des machines hôtes différentes, géographiquement éloignées� avec des systèmes d'exploitation différents� communicant avec des protocoles réseaux différents� et intégrés à différents environnements de déploiement

� serveur de sécurité� serveur transactionnel� serveur de bases de données� …

� Conceptuellement , ces objets sont rendus interopérables (ils peuvent s'appeler l'un l'autre ou être utilisés par d'autres applications utilisatrices) grâce à un "bus" de communication: l'ORB.


Firew

allF

irewall

Objets répartis

UNIX

NT

MACOS

W-CE

Java

C++

Cobol

LispC++

Smalltalk

Firew

all


Objets répartis

NT


CORBA

� Object Request Broker (ORB)� l’ORB est un bus qui permet de répartir des objets distribués et de les rendre interoperables.

� Object Services� un ensemble de services généraux au dessus de l’ORB

� naming� event� persistent object service� life-cycle� concurrency

� externalization� relationship� transaction� query property� time

� Common Facilities� modèles d’applications qui résolvent des problèmes communs à de nombreuses

architectures distribuées� administration système� gestion des utilisateurs� gestion des tâches

� Corba Domains� médecine, transport, simulation, banques, BD génomiques, ...

� security� trader� collection� versioning� licence

� notification

Site du cours: suivre Corba / OMG


Le langage IDL(Interface Description Language)


Exemples d’hétérogénéité sémantique

� Template � généricité� record� arrays� union� type constructor

� list� interface� virtual class� héritage (simple/multiple)� overriding� dynamic typing

� IDL (Interface Description Language) est un language de description d’objets distribués neutre.� Module, objet, méthode, héritage, …� indépendant des langages de programmation et des architectures

� L’OMG définit des règles strictes de mapping d’IDL vers les langages de programmation. Exemples:� héritage multiple vers Java� méthode vers C, COBOL� héritage vers C, COBOL� int vers COBOL� etc.


L’Objet distribué en CORBA

� Un objet distribué en CORBA est perçu comme une entité offrant un certain nombre de services accessibles à distance.

module NASA {typedef unsigned long Delai;typedef sequence<Delai> SequenceBooster;

interface engin {attribute string comment;readonly attribute string nom_engin;void decoller( in Delai d);boolean statusDecollage( in string reservoire,

out long niv_Hydrogene, inout Delai t);

};interface fusee: engin {

oneway void setSequenceBoost( in SequenceBooster boost);};

};

Définition d’objet

méthodeopération

Attribut d’état

Appeloneway (asynchrone)

entrée/sortie/entrée-sortie

Type de données

héritage


Utilisation d’IDL

C++ COBOLJava

BUS CORBA

IDLIdl2c++ idl2java idl2cobol

1. Modélisation par un diagramme de classes des composants répartis que l'on va trouver dans le système d'informations distribué

2. Chaque classe définira un contrat proposant les services offerts par chaque objet distribué de cette classe à ses clients potentiels.a) applicationsb) objets répartis

3. Chaque classe sera traduite en IDL et deviendra une "interface" corba4. La compilation de l'IDL produira un framework dans des langages cible que chaque

responsable informatique pourra étendre pour fournir une implémentation.


� Commentaires/* ceci est un commentaire */// ceci aussi

� Identificateurid :: = lettre caractere*caractere ::= lettre | chiffre |'_’lettre::='a’ ..'z’'A’ ..'Z’chiffre::='0’ ..'9’

� Interface� le langage IDL permet de spécifier de manière abstraite les services rendus par un objet distant

indépendamment de son implémentation et de la sémantique du langage dans lequel il a été implémenté

� Un module contient � des définitions de constantes� des types de données� des interfaces� des exceptions� d’autres modules

� Un identificateur à une portée locale au module/interface qui le contient� Un module est un espace ouvert qu’il est possible de compléter a posteriori.

� Il structure les définitions de données permettant ainsi d’éviter des conflits de nom module Fortis { module CGER { interface customer … } module Generale { interface customer … } }

� Un identificateur peut être référencé dans un module comme suit:Math::Trigo::PI : l’identificateur PI dans le module Trigo dans le module Math


� IDL est un langage fortement typé� Types scalaires

short entier 16 bits signéunsigned short idem non signélong entier 32 bits signéunsigned long idem non signélong long entier 64 bits signésunsigned long long idem non signéfloat nombre flottant 32 bits IEEEdouble nombre flottant 64 bits IEEElong double nombre flottant 128 bitsboolean booléen TRUE et FALSEoctet octet 8 bitschar caractère 8 bits ISO latin-1wchar caractère au format international (unicode)string chaîne de caractèreswstring chaîne de caractères au format international

� Octet: ne subit aucune modification sur le bus CORBA.� String: non borné, mais string<80> est autorisé

� Constantesdéclaration ::= const identificateur '=’ expressionconst string UneChaine = « Namur, ville capitale » ;

const double PI= 3 + 0.1415 ;

const char accept=‘y’ ;

const long TAILLE=20 ;


� Définitions de typedéfinition-de-type ::= typedef type identificateurtypedef unsigned short Jour

� Types complexes� énumérations

� énumeration ::= enum identificateur' {‘ identificateur {' ,’ identificateur }*' }’� enum PersonneID { etudiant, enseignant, etranger };

� structures� structure ::= struct identificateur' {‘ { champ } +' }’� champ ::= type identificateur' ;’� struct Adresse { string rue; long numero; string ville ; };

� unions� union TypePersonne switch (PersonneID) {

case etudiant: long numero_carte;case enseignant: string numero_securite_sociale;case etranger: wstring nom_prenom_pays;

};

� tableaux� tableau ::= type dimension { dimension } *� dimension ::=' [‘ cst_entier_positif' ]’� typedef float[TAILLE][TAILLE] Matrice;

� séquences� séquence::= sequence ' <‘ type' >’

| sequence ' <‘ type' ,’ cst_entier_positif' >’� Si une borne est précisée, elle mentionne le nombre maximal d’éléments que l’on peut stocker dans une

séquence. La taille de la séquence est disponible à l’exécution.� sequence list_adresse < Adresse , 3 > ;


� Interface� Une interface est une description d’un ensemble d’opérations qu’un client peut solliciter d’un

objet. Le langage IDL permet de décrire syntaxiquement les interfaces.� Une interface peut hériter d’autres interfaces� Une interface peut posséder

� des attributs (attribute ) � des exceptions (exception )� des opérations� des constantes (const )� des déclarations de types (typedef )

� Attributs� attribut ::= [ readonly ] attribute type identificateur {' ,’ identificateur }*� Une déclaration d’attribut est équivalente à la déclaration de méthodes d’accès:

readonly attribute String name;

� String __get_name();

� void __set_name(in String name); /* si pas readonly */

� Exceptions� un type d’exception se définit comme une structure à la différence du mot clef exception à la

place de struct.� Ce type d’information est utilisé pour retourner une information lorsqu’un problème survient à

l’exécution d’une opération.� exception division_par_zero { long numerateur; }

� Une interface est considérée comme un type et dès lors, il est permis d’utiliser une interface comme type de résultat, de paramètre, ou d’attribut.


� Opérationopération ::= [ oneway ] op_type identificateur paramètres [ raise_exp ] [ context_expr ]op_type ::= type | voidraise_exp ::=raises ' (‘ identificateur {' ,’ identificateur }*' )’context_exp ::= non abordé dans ce coursparamètres ::=' (‘ paramètre*' )’paramètre ::= [ in | out | inout ] type identificateur

� si une opération est oneway� l’invocation de cette méthode est réalisée de manière asynchrone� pas de paramètres out ou inout� pas d’exception� sémantique besteffort, l’opération sera exécutée 0 ou 1 fois (exemple: panne de

réseau).� La présence d’une clause raises signifie que l’exécution peut lever une exception, dans ce

cas, les paramètres out et inout sont indéterminés.� Outre les exceptions définies par l’utilisateur, des exceptions système peuvent aussi être

levées.� La surcharge est interdite, un nom = 1! Opération

� Héritage� Un sous-type possède l’ensemble des caractéristiques figurant

dans les super-types. � Il ne peut y avoir de conflit de nom.� La structure en diamant ne pose pas de problème.

� Tous les objets supportant une interface CORBA héritent implicitement de l’interface CORBA::Object.

Interface A

Interface B Interface C

Interface D


� local : certaines interfaces peuvent être déclarées locales. Ceci signifie permet de décrire des objets non distribués avec l’IDL. L’OMG définit ainsi l’architecture interne de chaque application avec l’IDL.

� Le passage par valeur� IDL permet de définir des types d'objets dont les instances sont passées

par valeur dans les appels distants plutôt que par référence (dans le cas des interfaces).

� Ce point est présenté dans la suite de l'exposé.


CORBA/IDL C++ Javashort CORBA::Short shortunsigned short CORBA::Ushort shortlong CORBA::Long intunsigned long CORBA::Ulong intlong long CORBA::LongLong longunsigned long long CORBA::ULongLong longfloat CORBA::Float floatdouble CORBA::Double doublelong double CORBA::LongDouble not yet definedboolean CORBA::Boolean booleanoctet CORBA::Octet bytechar CORBA::Char char

Règles de mapping


Règles de mapping

CORBA/IDL C++ Javamodule namespace packagetype élémentaire définition de type type élémentaireconstante constante attribut constantdéfinition de type typedef classeénumération enum classestructure structure classeunion classe classetableau tableau tableauséquence classe tableauinterface classe interfaceréférence d'objet instance instanceattribut 1/2 fonctions 1/2 fonctionsopération fonction fonctioninvocation appel -> appel .passage de paramètres val/&/* valeur/Holderexception classe classe


Architecture


Client IDLStubClient

IDLStubClient

IDLStub

ORB

Dynamic Invocation

Client IDLStub

ORB API

Client• Object• Process• DBMS

� Stub/ Static Invocation Interface (SII)C’est le résultat de la projection des descriptions IDL dans un langage de programmation donné. Le stub est le proxy qui représente un objet distant, et par lequel l’application cliente pourra émettre ses requêtes. Le stub emballe les requêtes, déballe les résultats, et procède aux appels nécessaires à l’ORB pour envoyer la requête.Un objet distant peut posséder plusieurs stubs selon le langage utilisé pour implémenter l’application cliente (COBOL/C++/Java/…).

� Dynamic Invocation Interface (DII)Permet de construire des requêtes dynamiquement. Ce mécanisme est plus complexe. Il permet néanmoins d’écrire des applications clientes qui découvrent leur contexte (la nature des composants distribués qui les entourent) au moment de l’exécution.Exemple: browser, compilateur, administration, ...

� ORB CoreIl assure le transport des invocations entre les objets. Cette couche utilise le protocole IIOP pour communiquer avec des objets sur des machines différentes.L’ORB est caché de l’utilisateur et seules quelques fonctions élémentaires sont accessibles.


� Dynamic Skeleton Interface (DSI)Ce composant répond aux requêtes émanant des clients. Cette couche peut répondre à des requêtes sans que le skeleton statique ne soit disponible.Exemple

- smalltalk: ce langage peut créer de nouveaux types d’objets distribués dynamiquement

- bridge inter-ORB

� Static Skeleton InterfaceChaque type d’objet sur le serveur peut avoir un skeleton (généré à partir de la description IDL) qui déballe les requêtes et emballe les résultats.

ORB


IDLStubClient

IDLStubDynamicSkeleton

StaticSkeleton

ORB API

Server• Object• Process• DBMS

Object Adapter

Object

Interface

ObjectAdapterInterface

� Object Adaptergénération et interprétation des références d’objetsinvocation des méthodessécurité des invocationsdés/activation des objetsenregistrement des objets


ORB

InterfaceRepository

ImplementationRepository

� Interface Repository (IR)L’IR est un service qui fournit des objets persistants qui représentent l’information définie par les spécifications IDL et qui sont disponibles au moment de l’exécution.L’IR est utilisé par les compilateurs IDL pour effectuer du type checking, et par toutes les applications qui découvrent leur environnement au moment de l’exécution (Browser, administration, …)L’IR est standardisé par l’OMG.

� Implementation RepositoryCe repository est spécifique à chaque constructeur d’ORB.


CORBA::Object

� Tous les objets supportant une interface CORBA héritent implicitement de l’interface CORBA::Object qui est standardisée.

interface Object {ImplementationDef get_implementation ();InterfaceDef get_interface ();boolean is_nil();Object duplicate ();void release ();boolean is_a (in string logical_type_id);boolean non_existent();boolean is_equivalent (in Object other_object);unsigned long hash(in unsigned long maximum);Status create_request (in Context ctx,

in Identifier operation,in NVList arg_list,inout NamedValue result,out Request request,in Flags req_flags );

Policy get_policy(in PolicyType policy_type);DomainManagersList get_domain_managers();

};


Exemple

� Établir une plateforme de communication entre des courtiers en assurances et des compagnies d’assurance.� Les courtiers peuvent disposer de matériels hétérogènes� Les assurances peuvent disposer de serveurs différents� Les assurances offrent des services communs mais peuvent aussi se

différencier en offrant des services supplémentaires.

� BUS Corba� Objets: compagnies d’assurance� Objets: les courtiers� Objets: les clients des compagnies


Stubcompagnie

Zurich

ORB

Dynamic Invocation

StubAssuré

ORB API

Courtier en assurances

DynamicSkeleton

skeletoncompagnie

AXAORB API

AXA Assurance Serveur

ObjectAdapter

ORB

Stubcompagnie

AXA

skeletonAssuré

Exemple 1

Stubcompagnie


DynamicSkeleton

skeletonCompagnie

ZurichORB API

Zurich Assurance Serveur

ObjectAdapter

skeletonAssuré

ORB


module MediateurAssurance {typedef string<80> T_police;exception PasEnregistre { string motif; };interface Assure {

readonly attribute string nom;readonly attribute string prenom;readonly attribute string adresse;

}interface Compagnie {

readonly attribute string nom_compagnie;readonly attribute string adresse;Assure get_client(in string nom, in string prenom) r aises PasEnregistre;float eval_prime(in short bonus_malus, in short pui ssance);void annule_contrat(in T_police num_police) raises PasEnregistre;

}module AXA {

interface CompagnieAssur : Compagnie {oneway void demande_nvelle_police (

in string nom;in string prenom;in string courtier;in string adresse_client );

};};module ZURICH {

interface CompagnieAssur : Compagnie {boolean demande_nvelle_police (

in string nom;in string prenom;in string courtier;in string adresse_client;in short bonus_malus );

};};

};


P

«interface»ZURICH_compagnie

demande_nvelle_police

«interface»AXA_Compagnie

«oneway» demande_nvelle_police

«interface»Compagnie

«readonly» nom«readonly» adresseget_clienteval_primeannule_contrat


ORB

ORBORB

IDLStubClient

IDLStubIDLStubClient


IDLStubDII StubORBAPI



IDLStubClient

IDLStubDSIStaticSkel.

ORBAPI


OA

IDLStubClient



IDLStubDII StubORB API



IDLStubClient


ORB API


OA

IDLStubClient






IDLStubClient


ORBAPI


OA

ORB

ORB

IDLStubClient






IDLStubClient


ORBAPI


OA


CompagnieStub

CompagnieZurich

InvocationDynamic Invocation

StubAssuré

ORB APICompagnieStub

CompagnieAXA

DynamicSkeleton

Carte deVisite

ORB API ObjectAdapter

Agenda

Exemple 2

ORB

ApplicationCourtier en assurances


Le Bus CORBA

� L’OMG définit les services rendus par le bus (ORB), pas son implémentation. Cela permet des solutions à des problèmes spécifiques.� Bus Processus

Le client et les objets sont dans un espace d’adressage unique (i.e. processus). � Temps de réponse minimal� Interopérabilité → portabilité (langages, OS, constructeurs)� Embedded systems: permet une meilleurs portabilité des composants sur des matériels très

spécifiques.

� Bus Système d’exploitationLa communication se fait entre processus sur une même machine.Hypothèses de simplification (format des données, erreur de transmission, …)� Gnome/Orbit (slide suivant)

� Bus ServeurLes requêtes sont adressées à un (ou plusieurs) serveur(s) qui distribue(nt) les requêtes vers les objets distants.Gestion centralisée du BUS (écoute, auditing, …)

� Bus RéseauImplantation la plus courante. � Orbix, Tao, Orbacus, eOrb, Mico, OpenOrb, Jacorb, Omniorb, jonathan, quelques dizaines

de distribution …



local interface ORB {typedef string ObjectId;typedef sequence <ObjectId> ObjectIdList;string object_to_string (in Object obj );Object string_to_object (in string str);

// Dynamic Invocation related operationsvoid create_list (in long count, out NVList new_list );void create_operation_list (in OperationDef oper, out NVList new_list);void get_default_context (out Context ctx);void send_multiple_requests_oneway(in RequestSeq req);void send_multiple_requests_deferred(in RequestSeq req);boolean poll_next_response();void get_next_response(out Request req);

// Service information operationsboolean get_service_information (in ServiceType service_type,

out ServiceInformation service_information);ObjectIdList list_initial_services ();

// Initial reference operationObject resolve_initial_references (in ObjectId identifier) raises (InvalidName);

// Thread related operationsboolean work_pending( );void perform_work();void run();void shutdown(in boolean wait_for_completion);void destroy();

// Policy related operationsPolicy create_policy(in PolicyType type, in any val ) raises (PolicyError);

};


Le protocole GIOP

� L’OMG a défini un protocole générique réseau à usage général nommé GIOP.

� indépendance % des couches de transport sous-jacentes

� simplicité de son implémentation

� spécification générique

� faible coût de son utilisation (efficacité)

� GIOP définit:

1. Représentation commune des données (Common Data Representation)i.e. représentation physique des types IDL

2. Référence d’objets interopérables (IOR: Interoperable Object Reference) représentation standardisée des références d’objets distants

3. Pré-requis sur la couche de transportExemple: les messages émis doivent être reçus dans le même ordre qu’à l’émission.

4. Format des messagesExemple: appel de méthode, exception, …

� GIOP peut être considéré comme un véhicule pour transporter des données qui ont été définies avec le CDR. GIOP définit huit types de véhicules (i.e. messages).

� GIOP ne définit pas l'IOR avec précision et délègue cette responsabilité aux protocoles concrets.


A. Le format CDR

� Ce format spécifie un format de données pour représenter tous les types élémentaires IDL sous la forme d’une suite d’octets transportables par les couches de communication.� Alignement des bytes� Ordre des bytes

� CDR ne fait pas d’encodage à la source, le récepteur effectue le décodage à la réception uniquement si son format de données internes est différent de celui de l’émetteur.�Le nombre de conversions est donc réduit.


Exemple d’alignement

� Alignment of Data ItemsDevelopers who undertake the migration to the 64-bit operating environment will discover that a small set of issues tend to recur most frequently, on both Win64* and Linux* platforms.

One of these is the alignment of data items – their location in memory in relation to addresses that are multiples of four, eight or 16 bytes. Under the 16-bit Intel architecture, data alignment had little effect on performance, and its use was entirely optional. Under IA-32, aligning data correctly can be an important optimization, although its use is still optional with a very few exceptions, where correct alignment is mandatory. The 64-bit environment, however, imposes more-stringent requirements on data items. Misaligned objects cause program exceptions. For an item to be aligned properly, it must fulfill the requirements imposed by 64-bit Intel architecture (discussed shortly), plus those of the linker used to build the application.

The fundamental rule of data alignment is that the safest (and most widely supported) approach relies on what Intel terms "the natural boundaries." Those are the ones that occur when you round up the size of a data item to the next largest size of two, four, eight or 16 bytes. For example, a 10-byte float should be aligned on a 16-byte address, whereas 64-bit integers should be aligned to an eight-byte address. Because this is a 64-bit architecture, pointer sizes are all eight bytes wide, and so they too should align on eight-byte boundaries.

It is recommended that all structures larger than 16 bytes align on 16-byte boundaries. In general, for the best performance, align data as follows:

Align 8-bit data at any address

Align 16-bit data to be contained within an aligned four-byte word

Align 32-bit data so that its base address is a multiple of four

Align 64-bit data so that its base address is a multiple of eight

Align 80-bit data so that its base address is a multiple of sixteen

Align 128-bit data so that its base address is a multiple of sixteen

A 64-byte or greater data structure or array should be aligned so that its base address is a multiple of 64. Sorting data in decreasing size order is one heuristic for assisting with natural alignment. As long as 16-byte boundaries (and cache lines) are never crossed, natural alignment is not strictly necessary, although it is an easy way to enforce adherence to general alignment recommendations.

Aligning data correctly within structures can cause data bloat (due to the padding necessary to place fields correctly), so where necessary and possible, it is useful to reorganize structures so that fields that require the widest alignment are first in the structure. More on solving this problem appears in the article, "Preparing Code for the IA-64 Architecture (Code Clean).«

http://www.intel.com/cd/ids/developer/asmo-na/eng/170533.htm?prn=Y


� Caractéristiques� Les valeurs IDL ont une longueur déterminée par leur type dans le flux

(size=1,2,4,8 bytes).� Big-endian ou little-endian : pas de conversion

� Decimal(305 419 896)= big-endian(0x12 0x34 0x56 0x78 ) = little-endian(0x78 0x56 0x34 0x12 )

� little-endian: Intel, � big-endian: sparc, 68000

� Les valeurs sont alignées sur des multiples de leur taille� [ boolean=True , long=132 , short=56 , char=‘Q’ , long long=234.663 ]� [ 0x01 0x00 0x00 0x00 0x84 0x00 0x38 0x51 0x00 0x00 0x00 0x00 0x00

0x03 0x94 0xA7 ]� [ 0 :0x01 0x20 0x20 0x20

4 :0x00 0x00 0x00 0x848 :0x00 0x3810:0x51 0x20 0x20 0x20 0x20 0x2016:0x00 0x00 0x00 0x00 0x00 0x03 0x94 0xA7 ]

� Le récepteur doit connaître la nature des valeurs afin de les lire → typage statique

� Question: Quels avantages pourrait-on avoir si le type de chaque donnée (et donnée agrégée) était véhiculé avec les données ?


� little-endian adj. Describes a computer architecture in which, within a given 16- or 32-bit word, bytes at lower addresses have lower significance (the word is stored `little-end-first'). The PDP-11 and VAX families of computers and Intel microprocessors and a lot of communications and networking hardware are little-endian. The term is sometimes used to describe the ordering of units other than bytes; most often, bits within a byte.

� big-endian adj. Describes a computer architecture in which, within a given multi-byte numeric representation, the most significant byte has the lowest address (the word is stored `big-end-first'). Most processors, including the IBM 370 family, the PDP-10, the Motorola microprocessor families, and most of the various RISC designs are big-endian. Big-endian byte order is also sometimes called `network order'.

Source: http://info.astrian.net/jargon/terms/


B. Interoperable Object Request / IOR

1. Numéro de version du protocole transport utilisé sur le serveur2. L'adresse du serveur resp. % au protocole spécifié ci-dessus3. une suite d'octets identifiant l'objet sur le serveur


C. Hypothèses sur la couche transport

� connection-oriented� fiable

� ordre des paquets respecté� pas d'erreurs dans les paquets� pas de paquets perdus� pas de paquets dupliqués

� la couche transport doit pouvoir être perçue comme une suite de bytes� pas de limitation sur la taille du message transféré� impose de transférer un message de GIOP à la couche transport en un bloc contigu

en mémoire vive: exemple fichier vidéo de +Mb� GIOP 1.1 permet de fragmenter des messages GIOP, la couche GIOP est donc

capable de réassembler les sous-messages.

� La couche transport doit aviser la couche supérieure d’une perte de connexion� l’entité distante ne répond pas → récupérer la connexion pour une autre entité

(polling limité de connexions)

� Le mode opératoire est imposé (calqué sur le modèle TCP-IP).



D. Les messages GIOP

Type de message Émetteur Tag Version de GIOPRequest Client 0 1.0, 1.1, 1.2Reply Serveur 1 1.0, 1.1, 1.2CancelRequest Client 2 1.0, 1.1, 1.2LocateRequest Client 3 1.0, 1.1, 1.2LocateReply Server 4 1.0, 1.1, 1.2CloseConnection Server 5 1.0, 1.1, 1.2MessageError Client & Serveur 6 1.0, 1.1, 1.2Fragment Client & Serveur 7 1.1, 1.2

Magic number GIOP Version Flags(endian;more) Tag Size

4 bytes 2 bytes 1 byte 1 byte 4 bytes

� Magic number: « GIOP »� GIOP Version: exemple, version 1.2� Flags: 8 bits.

Little/big endian; more=cfr. Fragment Ce message est suivi d’un autre message� Tag: type du message� Size: taille du message

Message Header:



� RequestCe message encode les invocations d’opération et les accesseurs. Le message est constitué de:� IOR de l’objet distant� nom de l’opération� paramètres (in,inout)

� ReplyMessage envoyé par le serveur en réponse à une requête. Ce message contient les réponses à la requête (paramètres out et inout) ou l’exception si un problème est apparu lors de l’exécution de la requête.

� CancelRequestMessage envoyé par un client à un serveur pour l’informer qu’il n’attend plus après sa réponse.

� LocateRequestMessage « blanc » envoyé à un objet identifié par un IOR pour tester sa validité (~ping)

� LocateReplyMessage envoyé en réponse à un LocateReply par un serveur. (vrai ou faux)

� CloseConnectionLe serveur informe un client qu’il ne répondra plus aux requêtes (en cours et à venir). Le client ne doit donc plus attendre après une réponse.

� MessageErrorLe récepteur n’a pas compris un message précédent (mauvais magic number, mauvaise version, erreur interne au bus, …).

� FragmentMessage utilisé pour véhiculer des fragments d’un autre message trop important pour la couche transport.Si flag more=1, alors d'autres messages du type fragment vont suivre jusqu'à ce que flag more=0.


Request


Reply

� LOCATION_FORWARD.

The server asks the client to send the request to another object. Its IOR is placed in the body of the message.

� LOCATION_FORWARD_PERM = deprecated

� NEEDS_ADDRESSING_MODE

Ask the client to send the request again with another configuration (see reference manual)


Cancel & LocateRequest & LocateReply


Spécialisation de GIOP: IIOP

GIOP

TCP-IPIIOP

...OSIIPX

IIOP: Internet Inter-ORB ProtocolMise en œuvre du protocole GIOP avec TCP-IP.Une distribution CORBA conforme doit offrir ce protocole.

D’autres protocoles existent indépendamment de GIOP. Par exemple, pour l’architecture DCE, le protocole ESIOP définit un mapping des données IDL en termes du langage de définition de données défini par DCE. Néanmoins, une telle architecture doit supporter le passage de requêtes ORB2ORB.

� Référence IOR pour IIOP:� numéro de version IIOP� adresse IP de la machine

(symbolique ou #. #. #. #)� port sur lequel le serveur écoute� identifiant de l’objet sur le serveur.


Interopérabilité entre Bus CORBA

� Motivations� L’OMG définit l’interface du Bus plutôt que son implémentation. � ≠ constructeurs peuvent faire des choix d’implémentations incompatibles.

� Protocoles différents� ≠ niveaux de sécurité (secured sockets)

� Domaines : garantit la « non interopérabilité »� accroître l’autonomie d’un système en l’isolant au sein d’un ORB distinct des

autres� finance / personnel / mécanique� développement / test / production

� un même ORB ou des ORB de constructeurs différents� Des passerelles sont néanmoins indispensables

� Néanmoins la plupart des Bus sont intéropérables entre eux.


� Inter-ORB Bridge (Half-Bridge)� même CPU (cfr. exemple)� deux CPUs avec un protocole commun

DSI DII DSI DII

Half Bridge Half Bridge

� Inter-ORB protocols: GIOP & IIOP� traduction des requêtes vers un format standard et commun

I love you! Te quiero!

Bridge


L’Adaptateur d’objets: POA

ORB


IDLStubClient

IDLStubDynamicSkeleton

StaticSkeleton

ORB API


Object Adapter

Object

Interface

ObjectAdapterInterface

L’adaptateur d’objet est le mécanisme qui connecte une requête en utilisant la référence d’objet qui se trouve à l’intérieur de la requête avec le servant(processus,programme,thread, …) qui représente l’activité de l’objet référencé.

Le servant est l’entité qui implante une interface décrite par le langage IDL.

Des requêtes envoyées à des objets différents (IOR≠) peuvent être servies par un même servant.


� Fichier IDL = Collection d’interfaces

Fichier IDL

IDL2xxx xxx=java, cpp, cobol, …

fichier STUBdans le langage cible


fichier SKELETONdans le langage cible



Applicationutilisatrice d’une interface

Applicationhôte d’objets

call

MonServant

« GenServant » isa

iof

« Proxy »


iof

produces

used byused by

POA::Servant


RootPOA

Default servant

POA 1

Object id

Object id

Object id

Object id

Object id

Object id

Active Object Map

Default servant

Object id

Object id

Object id

Object id

Object id

Object id

Active Object Map

POA 2

Object id

Object id

Active Object Map

Default servant

Policy

Policy

Policy

ServantManager

ServantManager

POA Manager

manages


� Il existe un POA remarquable: « RootPOA »� Un POA peut être le père de plusieurs POA� Un POA est responsable de Servants� Un POA associe des « object ID » à des Servants

� < « DEXIA » , new BanqueImplementation(« DEXIA », « BXL ») >� < « Crédit Lyon. » , new BanqueImplementation(« LYON », « Paris ») >

� Un "objet distribué" est référencé sur le serveur par la séquence des POA Ids et l’Object ID.� cette information se retrouve donc dans l’IOR !

� Un POA peut posséder un ServantManager qu’il invoque lorsqu’il doit traiter une requête contenant un Object ID auquel aucun de ses Servants n’est associé.local Interface ServantManager {

Servant incarnate (in ObjectId oid, in POA adapter) ;}

� Un contexte peut être associé à chaque POA qui influence son comportement:� L’Object ID peut il être assigné automatiquement à un servant lors de son enregistrement dans le POA

par le POA ou l'utilisateur doit-il donner explicitement l'object-id (exemple: primary-key d'une table SQL)?

� Un servant peut il posséder plusieurs Object ID ?� Plusieurs Threads peuvent ils accéder au POA simultanément ?� Les Objects Ids sont ils persistants ?


Default servant


� CORBA fait une distinction entre « transient IOR » et « persistent IOR » (cfr. Lifespan policy du POA).� Transient IOR : une référence IOR est valide tant que le servant de l'autre côté est

actif. Dès que le servant est tué (panne, kill, …), l'IOR désigne un objet qui n'existe plus!� L'exception OBJECT_NOT_EXISTest renvoyée au client.

� Un magic number est généré dans l'IOR de sorte que même si l'on redémarre le serveur, il y ait peu de chance que l'IOR désigne un nouveau servant qui n'a plus rien à voir avec celui qui a disparu.

� Persistent IOR� la période de validité de cet IOR est indépendante de la période d'activité du servant� « persistent » ne signifie pas que l'état de l'objet est persistant !

� C'est au moment où l'on enregistre un objet auprès du POA que l'on précise la nature de la référence que le POA va construire.


Le gestionnaire de POAs

� Le POA Manager peut gérer simultanément plusieurs POA dont il contrôle l’état de traitement.

� Le gestionnaire de POA possède quatre états:

Inactif

Actif

Suspendu

Rejet

Create_POA

Discard_requests

Hold_requestsactivate

Discard_requests

activate

deactivate

deactivate

destroy

� Actif . Toutes les requêtes destinées à un POA lui sont transférées. Le POA les empilera et les traitera selon sa "policy".

� Inactif . État temporaire avant la destruction d’un POA. Les requêtes sont rejetées.

� Suspendu . Empile les requêtes dans une file d’attente du POA cible.

� Rejet . Toutes les requêtes sont rejetées en masse.

@ Vincent Englebert - FUNDP 62@jacorb



Les servants sont créés à la volée et placés dans la table du POA. Ils pourront être désalloués par la suite (opération deactivate du POAManager par exemple)


Les servants sont créés à la volée mais à la seule fin d’exécuter une et une seule requête.

preinvoke est appelé pour créer le servant, postinvoke est invoqué pour libérer le servant.

La définition des ces deux opérations sont à charge du programmeur


� Cette architecture permet de� De gérer des objets persistants

� le ServantManager peut charger une donnée d’une BD et associer un nouveau servant.

� D’avoir des politiques différentes dans un même serveur� persistant/éphémère� single thread/multi thread� transactionnel ou non� ...

� Quelques cas d’utilisation:� Activation explicite du servant pour chaque objet� Un seul servant pour tous les objets.

� Tous les objets ont le même type � exemple Ligne SQL� module purement fonctionnel (i.e. sans état)

� Le même servant traite des requêtes destinées à des objets implémentant des interfaces différentes.

� Activation à la demande pour la durée d’exécution d’une méthode� stateless object (fonctionnalité sans état, exemple: factorielle(n) )


Procédure de déploiement

module Business {

interface Compte;

interface Banque {Compte creer_compte(in string Nom);void ajout_interet(in Compte cpt);

};

interface Compte {readonly attribute string Nom;attribute string Adresse;readonly attribute long Solde;void credit(in long somme);void debit(in long somme);

};

};

Business.idl

banque


RootPOA

Default servant

POA 1

Object id

Object id

Object id

Object id

Object id

Object id

Active Object Map

Default servant

Object id

Object id

Object id

Object id

Object id

Object id

Active Object Map

POA 2

Object id

Object id

Active Object Map

Default servant

Policy

Policy

Policy

ServantManager

ServantManager

POA Manager

manages


import java.io.*;import Business.*;

public class Serveur {private static void printReference(String reference){

try {FileOutputStream file=new FileOutputStream("ObjectId");PrintStream pfile=new PrintStream(file);pfile.println(reference);file.close();

}catch (IOException ex){

System.out.println("Impossible de creer le fichier ObjectID");}

}

public static void main (String args[]){try {

org.omg.CORBA.ORB orb=org.omg.CORBA.ORB.init(args,null);org.omg.CORBA.Object objetPOA=orb.resolve_initial_references("RootPOA");org.omg.PortableServer.POA rootPOA=org.omg.PortableServer.POAHelper.narrow(objetPOA);BanqueImpl banque=new BanqueImpl();byte[] objectId=rootPOA.activate_object(banque);org.omg.CORBA.Object obj=rootPOA.id_to_reference( objectId);String reference=orb.object_to_string(obj);printReference(reference);rootPOA.the_POAManager().activate();System.out.println("Le serveur est pret...");orb.run();

}catch (org.omg.CORBA.ORBPackage.InvalidName e){...}catch (org.omg.PortableServer.POAPackage.WrongPolicy e){...}catch (org.omg.PortableServer.POAPackage.ObjectNotActive e){...}catch (Exception e){...}

}}

Serveur.java


public class CompteImpl extends Business.ComptePOA {private String nom;private int solde;private String adresse;

CompteImpl (String nom){this.nom=nom;solde=0;adresse="<adresse inconnue>";

}// Nom read attributepublic java.lang.String Nom () {return nom; }

// Adresse read attributepublic java.lang.String Adresse () {return adresse; }

// Adresse write attributepublic void Adresse( java.lang.String value ) { adresse=value; }

// Solde read attributepublic int Solde (){return solde; }

// Operation creditpublic void credit (int somme) {solde=solde+somme; }

// Operation debitpublic void debit (int somme) {solde=solde-somme; }

}

CompteImpl.java


//// Interface implementation definition : Banque//public class BanqueImpl extends Business.BanquePOA {

private final static float taux= (float) 1.04;

// Operation creer_comptepublic Business.Compte creer_compte (java.lang.String Nom) {

try {CompteImpl cpt=new CompteImpl(Nom);byte[] id=_poa().activate_object(cpt);Object obj= _poa().id_to_reference(id);

return Business.CompteHelper.narrow(obj);

}catch (Exception e){

e.printStackTrace();System.exit(0);

}return null;

}

// Operation ajout_interetpublic void ajout_interet (Business.Compte cpt) {

try {cpt.credit((int)(cpt.Solde()*taux-cpt.Solde()));



}}

}

défini par le mapping IDL-Java


//// Interface implementation definition : Banque//public class BanqueImpl extends Business.BanquePOA {

private final static float taux= (float) 1.04;

// Operation creer_comptepublic Business.Compte creer_compte (java.lang.String Nom) {

try {CompteImpl cpt=new CompteImpl(Nom);byte[] id=_poa().activate_object(cpt);Object obj= _poa().id_to_reference(id);

return Business.CompteHelper.narrow(obj);



}return null;

}

// Operation ajout_interetpublic void ajout_interet (Business.Compte cpt) {

try {org.omg.PortableServer.Servant servant=_poa().reference_to_servant(cpt);CompteImpl compte=(CompteImpl)servant;compte.credit((int)(compte.Solde()*taux-compte.Sold e()));



}}

}

BanqueImpl.java

défini par le mapping IDL-Java

optimisation, différence entre référenceinteropérable et objet local


import java.io.*;import Business.*;

public class Client {/** Creates new Client */public Client() { }

private static String getReference(){try {

FileInputStream file=new FileInputStream("ObjectId" );InputStreamReader input=new InputStreamReader(file) ;BufferedReader reader=new BufferedReader(input);return reader.readLine();

}catch (IOException e){ e.printStackTrace(); }return "";

}

public static void main (String args[]) {try {

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);String reference=getReference();org.omg.CORBA.Object object=orb.string_to_object(reference);Business.Banque banque=Business.BanqueHelper.narrow(object);Business.Compte compte=banque.creer_compte("Englebert");compte.credit(100);banque.ajout_interet(compte);System.out.println(compte.Solde());

}catch (Exception e){ e.printStackTrace(); }

}

}

Client.java


Passage par valeur en Corba.

Par défaut, les objets corba sont passés par adresse à l'exception des valeurs élémentaires (string, long, …). Néanmoins, il est possible de passer des « objets » par valeur depuis CORBA 3.0.

Généralement, le passage des arguments est une caractéristique des paramètres des opérations. Exemple:C++: void f(Client c, Facture& f);Pascal: procedure f(c: Client; var f: Facture)

En Corba, cette caractéristique est attachée au type et non à l'argument. Exemple:IDL: void f(Client c,FactureValue f)

Les types qui sont passés par valeur sont des « valuetype » (en lieu et place de « interface »).


idl2java

valuetype Bouchon {private long code;private Emetteur emetteur;public string route;public string heure;public string commentaire;void confirmer(in string commentaire);void dementir(in string commentaire);factory initialiser(in long code, in Emetteur emetteur, in string route,

in string heure, in string commentaire);};

abstract class Bouchon {attributes & operations

}

interface CORBA.portable.StreamableValue

interface BouchonValueFactory {bouchon initialiser(…)

interface CORBA.portable.ValueFactory

implements extends


public interface ValueFactory {java.io.Serializable read_value(org.omg.CORBA.portable.InputStream stream);

};

public class ValueFactoryExample implements org.omg.CORBA.portable.ValueFactory {

/*** This function is used by the ORB to unmarshal a value type.* * We need to create a new value type and call the _read value of * this value type to unmarshal it.*/

public java.io.Serializable read_value( org.omg.CORBA.portable.InputStream is ) {// 1. We create a new value type

MessageValueImpl value = new MessageValueImpl();

// 2. Now, we unmarshal this value ((org.omg.CORBA_2_3.portable.InputStream)is).read_value( ( java.io.Serializable ) value );

// 3. Then, we return the unmarshalled valuereturn value;

}}


abstract class Bouchon {attributes & operations

}

interface CORBA.portable.StreamableValue

interface BouchonValueFactory {bouchon initialiser(…)

interface CORBA.portable.ValueFactory

implements extends

class RtbfBouchon {// définition des opérations

}

class RtbfBouchonFactory {// définition de bouchon initialiser(…):bouchon initialiser(args … ){

…return new RtbfBouchon(…);

}

extends implements


interface Emetteur {void confirmer(in long code, in string commentaire);void dementir(in long code, in string commentaire);Bouchon get_info();

};

RtbfEmetteuremetteur_BXL

RtbfBouchonFactoryfabrique_SPA007

AdvCarSystautoradio

RtbfBouchoncopy of n7

RtbfBouchonn7


Serveur Factory Client Factory

x:avaluetype

init

requête

x':avaluetype

ORB

t:repository Id(avaluetype); m:CDR(x)

m? quel est le factory de t

x'


� mode dynamique� L'héritage est étendu aux value types et aux interfaces indifféremment:

hérite de interface value typeinterface plusieurs nonvalue type non 1

� Un value type peut "supporter" une interface. � le value type doit définir toutes les opérations spécifiées dans l'interface� par un mécanisme de délégation, on peut mettre en œuvre un mode de

passage par valeur et par adresse pour un même objet.


interface Exemple {void print();

}

valuetype ExempleVal supports Exemple {void printLocal();

}interface ExempleVal extends Exemple

class ExempleImpl implements Exemple {private Exemple clone;ExempleImpl(Exemple autre){

clone=autre;}public void print(){

clone.print();}

}

interface Exemple

idl2java

idl2java

class ExempleValImpl implements ExempleVal {public void print(){

System.out.println("Je suis içi");}

}

implements

extends

implements

les relations d'héritage et d'implémentation ont été simplifiées pour des raisons d'ordre

pédagogiques et peuvent nepas respecter les règles officielles de mapping.

Lorsqu'un client demande un résultat,le serveur peut décider de le lui renvoyerpar valeur ou par adresse selon le contexte.


interface ExempleVal extends Exemple

class ExempleImpl implements Exemple {

}

interface Exemple

class ExempleValImpl implements ExempleVal {

}

implements

extends

implements

par valeurpar valeur

par référence


� le passage par valeur permet de « délocaliser » des appels d'opération. Ainsi des appels (client-serveur) deviennent (client-client).

� Le passage par valeur implique que l'argument est à l'abri de toute modification qui serait opérée sur le site d’origine de l’objet.

� le passage par valeur/adresse est déterminé par le type des arguments et non par le mode des paramètres.

� les factories d'objets peuvent être distincts d'un hôte à un autre.� Le passage par valeur permet de mettre en œuvre des politiques avancées

de gestion comme:� Transformation d'invocations (client-serveur) en invocation (client-client) avec

post-synchronisation.� diminution du nombre de requêtes distantes

� Permet d'améliorer l'indépendance d'un client vis-à-vis des objets distants en cas de faible QoS du réseau ou du serveur

� bornes touristiques� hôtes mobiles� communications orientées connexion (modem)


Le repository d'interfaces


CORBA::Object

� Tous les objets supportant une interface CORBA héritent implicitement de l’interface CORBA::Object qui est standardisée.

pseudo interface Object {ImplementationDef get_implementation ();InterfaceDef get_interface ();boolean is_nil();Object duplicate ();void release ();boolean is_a (in string logical_type_id);boolean non_existent();boolean is_equivalent (in Object other_object);unsigned long hash(in unsigned long maximum);Status create_request (in Context ctx,

in Identifier operation,in NVList arg_list,inout NamedValue result,out Request request,in Flags req_flags );

Policy get_policy(in PolicyType policy_type);DomainManagersList get_domain_managers();

};


� Le repository d'interfaces contient une description des interfaces, modules, … définis dans le système. Chaque fois qu'un nouveau type de composant est inséré dans le système, le repository d'interfaces doit être mis à jour afin de pouvoir le décrire.

� Il en est de même lorsque l'on met à jour la définition d'un composant.� Exemple:

interface Client { attribute string name;

};

interface Client { attribute string name;attribute string address ;

};

� chaque interface du repository est étiqueté d'un numéro de version� « IDL:MediateurAssurance/AXA/AXA_compagnie:1.1 » (repository Id)

� Le repository d'interfaces contient une version de chaque interface. Des composants de « même type » peuvent donc coexister dans le système tout en ayant des versions d'interface différentes.� Le système peut donc évoluer en douceur


interface Client { attribute string name;

};

interface Client { attribute string name;attribute string address ;

};

ORB

« IDL:.../AXA_compagnie:1.0 » « IDL:.../AXA_compagnie:1 .1 »



Localisation d’Objets Distribués

� Inventaire des objets distribués [QUOI/OÙ]: « répertoire ».� Accroître la transparence de la localisation des différents composants.� Le répertoire des objets distribués de CORBA est lui-même un objet

distribué qui propose ses services à d’autres objets distribués.� Afin de structurer et d’optimiser les accès au bottin, les objets sont

arrangés en hiérarchie.

DollarAndCo

Banque

Assurance

Prêt

Compte

Courant

Dépôt

gestion

gestion

CalculInteret

incendie

vol


module CosNaming {typedef string Istring;struct NameComponent { Istring id; Istring kind; };typedef sequence <NameComponent> Name;enum BindingType {nobject, ncontext};struct Binding {

Name binding_name;BindingType binding_type;

};typedef sequence <Binding> BindingList;interface BindingIterator;

interface NamingContext {enum NotFoundReason { missing_node, not_context, no t_object};exception NotFound { NotFoundReason why; Name rest_ of_name; };exception CannotProceed { NamingContext cxt; Name r est_of_name; };exception InvalidName{};exception AlreadyBound {};exception NotEmpty{};void bind(in Name n, in Object obj) raises(NotFound, CannotP roceed, InvalidName, AlreadyBound);void rebind(in Name n, in Object obj)raises(NotFound, CannotPr oceed, InvalidName);void bind_context(in Name n, in NamingContext nc) r aises(NotFound, CannotProceed, InvalidName, Already Bound);void rebind_context(in Name n, in NamingContext nc) raises(NotFound, CannotProceed, InvalidName);Object resolve (in Name n) raises(NotFound, CannotProceed, Invalid Name);void unbind(in Name n) raises(NotFound, CannotProceed, Invalid Name);NamingContext new_context();NamingContext bind_new_context(in Name n) raises(No tFound, AlreadyBound, CannotProceed, InvalidName);void destroy( ) raises(NotEmpty);void list (in unsigned long how_many,out BindingLis t bl, out BindingIterator bi);

};

interface BindingIterator {boolean next_one(out Binding b);boolean next_n(in unsigned long how_many, out Bindi ngList bl);void destroy();

};};


high availability !stable ��

accès fréquents et cruciaux , mais les données peuvent être cachées


Techniques de résolution

� Résolution récursive (Corba Naming Service)� Object resolve(in Name n)

Contexte.resolve(<c1,c2,…,cn>)=(Contexte.resolve(<c 1>)).resolve(<c2,…, cn>)

� void bind (in Name n, in Object id)Contexte.Bind(<c1,c2,…,cn>,object)=Contexte.resolve(<c 1,…,cn-1>).bind(<cn>,object)

� Mais aussi� rebind� unbind� list(…)

@tanenbaum


Techniques de résolution

� Résolution itérative� Object resolve(in Name n)

Contexte.resolve(<c1,c2,…,cn>)

� NamingContext current=Contexte;for (string S in <c1,c2,…,cn-1>) do {

current=current.resolve( S);}return current.resolve(cn) ;

@tanenbaum


Comparaison

� Itérative� les serveurs sont moins chargés- (mais) plus de gestion sur le client

� le client doit posséder du code spécifique (librairie) pour itérer sur les serveurs

- le client doit pouvoir accéder à plusieurs serveurs

� pas de problème sur un intranet� avec des firewalls, il peut être difficile de

joindre des serveurs que l'on découvre dynamiquement.

- la seule façon de l'optimiser est d'installer un cache sur le client. Mais on a un cache pour chaque client

- utiliser un serveur de nom proxy qui factorisera et cachera les requêtes

- problème des incohérences: comment distinguer les noms stables et les noms instables

- les communications se font toujours client ↔ serveur, a priori sur de longues distances.

� Récursive- la méthode récursive surcharge les

serveurs� un serveur est responsable de résoudre

C1� il est aussi responsable de la résolution de

<C2,…,CN>� les serveurs dans la couche globale ne

peuvent pas supporter la charge induite par la méthode récursive

� le client ne discute qu'avec un seul serveur de noms

� plus élégante � la résolution incombe complètement au

serveur de nom� le serveur sert de façade à une complexité

arbitraire

� les messages échangés sont de proches en proches (on peut l'espérer)

@tanenbaum


résolution récursive de <nl,vu,cs,ftp> avec caching et résultats étendus

@tanenbaum

information stockée dans le répertoire avant la mis e en cache


� Les répertoires fournis dans les packages ne sont généralement pas prévus pour gérer de grandes quantités d’information� Répertorier les « grands » composants: oui� répertorier les clients (i.e. dupont) d’une banque: certainement pas.� Un répertoire n’est pas conçu pour remplacer une base de données classique

� Les services d’un répertoire sont assez simples: possibilité d’implémenter son propre service de répertoire compatible avec l’interface CORBA au dessus de SQL par exemple.

� Le répertoire est un composant vital, colonne vertébrale du système :� tolérant aux pannes� persistant� efficace

� Il est probable que les clients feront de nombreux accès au répertoire:� rapprocher le répertoire des clients (même réseau, même machine)� multiplier les répertoires

� par domaine (assurance,banque,gestion, …)

� Il est important de gérer l’information du répertoire� conventions, guidelines, consensus, … sur les règles de nommage

� Le répertoire permet de délocaliser un composant:� < banque.assurance, objet_namur > � < banque.assurance, objet_BXL >

� De par son rôle crucial, le répertoire est une donnée sensible sur le plan de la sécurité� rien n’est prévu dans CORBA sur ce plan (cfr. service de sécurité)� qui peut modifier, qui peut consulter, ...


� L’ORB offre une opération pour obtenir le répertoire principal (root)

module CORBA {interface ORB {

[…]typedef string ObjectId;typedef sequence <ObjectId> ObjectIdList;exception InvalidName{};ObjectIdList list_initial_services();Object resolve_initial_references( in ObjectId identifier) raises(InvalidName);

};};

Mais comment l’ORB peut-il connaître l’adresse du n aming service ?


Référencer un IOR sous format textuel

URL Corba:CORBALOC

corbaloc://{[ version du protocole @ ] nom de machine [ :numéro de port ]}/ clef de l'objet{ } plusieurs fois ♦♦♦♦ [ ] optionel ♦♦♦♦ protocole par défaut: 1.0 ♦♦♦♦ port par défaut: 9999Si plusieurs adresses, l'objet doit se trouver sur l'une des adresses (séparées par un ;)

Exemple:corbaloc://iiop: 1.2 @fiatlux.info.fundp.ac.be : 4315 / NameService

IORReprésentation hexadécimale de l'IOR.IOR: suite de bytesIOR:000000000000001849444C3A427573696E6573732F42616E7175653A312E300000000001000000000000006C0001020000000019666961746C75782E696E666F2E66756E64702E61632E626500000E4200000014004F4F0120B87FB7E8000000504F41FEE27CF18A00000001000000010000002400000000100204E400000003000100010001000F00010020000101090000000100010100

CORBANAME

référence un objet par son entrée dans un Naming Service (indirection…)Exemple: corbaname:iiop: 1.2 @fiatlux.info.fundp.ac.be : 4315 / universite.fundp/GestionInscriptions

Autres

ftp: , http: , file: fichier où se trouve un IOR


Négociations de services

� Le concept de répertoire offre une description très statique et très simple du domaine applicatif.

� Le concept de trading permet de répondre à des questions plus complexes sur la localisation de composants distribués

� Principe

Fournisseur Négociateur Demandeur

Je peux imprimer

Qui peut imprimer ?

Imprime !

� Naming=Pages Blanches; Trading=Pages jaunes


� Un trader décrit un (des) objet en terme d’un ensemble de services qu’il peut rendre.

� Exemple: service impression {interface Imprimante;mandatory readonly property string Type;mandatory property boolean is_busy;readonly property boolean is_fast;property long quality;property long cost_per_page;

};

� Les services sont représentés par une interface que l’objet fournisseur supporte.

� Les services sont décrits par des attributs� mandatory/optional

Cette propriété n’est pas obligatoire pour décrire le service� readonly or not

Le fournisseur peut modifier a postériori la valeur de cette propriété.Le négociateur doit consulter le fournisseur chaque fois qu’il souhaite connaître la valeur de cette propriété

� Le demandeur interroge le négociateur afin d’obtenir la référence d’un fournisseur qui répond à sa demande.


interface ImprimanteMatricielle;Type=« matricielle »;is_busy=true;is_fast=true;quality=5;cost_per_page=1;

interface ImprimanteHPCLType=« InkJet »;is_busy=false;is_fast=false;quality=8;cost_per_page=3;

impressionQuery: not is_busy and quality>=4pref: min cost_per_page

Hergé GregFranquin

interface ImprimantePSType=« PS »;is_busy=false;is_fast=true;quality=10;cost_per_page=1;

[ Franquin, Greg ]


Fédération de traders

QUERY

Local/if_no_local/always

Local/if_no_local/always

� Les traders peuvent s’organiser en communauté pour répondre à une question.� Le trader délègue la requête

auprès d’autres traders et fusionne les résultats avant de les présenter au demandeur.

� Les liens sont orientés et seul le trader origine connaît le trader cible du lien.

� Problème de circularité dans l’émission de la requête:� réponses multiples� non-terminaison

� Configuration dynamique� Configuration transitive� Disposition optimale des

traders� efficacité� par domaine

� proximité géographique

� département / thème

� couverture exhaustive des domaines par fédération


interface

CosTrading::ImportAttributesCosTrading::ImportAttributesCosTrading::ImportAttributesCosTrading::ImportAttributes

+def_search_card:unsigned long

+max_search_card:unsigned long

+def_match_card:unsigned long

+max_match_card:unsigned long

+def_return_card:unsigned long

+max_return_card:unsigned long

+max_list:unsigned long

+def_hop_count:unsigned long

+max_hop_count:unsigned long

+def_follow_policy:FollowOption

+max_follow_policy:FollowOption

enum

CosTrading::FollowOptionCosTrading::FollowOptionCosTrading::FollowOptionCosTrading::FollowOption

local_only:

if_no_local:

always:

interface

CosTrading::SupportAttributesCosTrading::SupportAttributesCosTrading::SupportAttributesCosTrading::SupportAttributes

+supports_modifiable_properties:boolean

+supports_dynamic_properties:boolean

+supports_proxy_offers:boolean

+type_repos:TypeRepository

exception

CosTrading::PropertyTypeMism...CosTrading::PropertyTypeMism...CosTrading::PropertyTypeMism...CosTrading::PropertyTypeMism...

type:ServiceTypeName

prop:Property

struct

CosTrading::PropertyCosTrading::PropertyCosTrading::PropertyCosTrading::Property

name:PropertyName

value:PropertyValue

interface

CosTrading::LinkCosTrading::LinkCosTrading::LinkCosTrading::Link

+add_link:void

+remove_link:void

+describe_link:LinkInfo

+list_links:LinkNameSeq

+modify_link:void

LinkInfo

IllegalLinkName

UnknownLinkName

DuplicateLinkName

DefaultFollowTooPermissive

LimitingFollowTooPermissive

interface

CosTrading::RegisterCosTrading::RegisterCosTrading::RegisterCosTrading::Register

+export:OfferId

+withdraw:void

+describe:OfferInfo

+modify:void

+withdraw_using_constraint:void

+resolve:Register

OfferInfo

InvalidObjectRef

UnknownPropertyName

InterfaceTypeMismatch

ProxyOfferId

MandatoryProperty

ReadonlyProperty

NoMatchingOffers

IllegalTraderName

UnknownTraderName

RegisterNotSupported

interface

CosTrading::ProxyCosTrading::ProxyCosTrading::ProxyCosTrading::Proxy

+export_proxy:OfferId

+withdraw_proxy:void

+describe_proxy:ProxyInfo

ProxyInfo

IllegalRecipe

NotProxyOfferId

interface

CosTrading::LookupCosTrading::LookupCosTrading::LookupCosTrading::Lookup

+query:void

HowManyProps

SpecifiedProps

IllegalPreference

IllegalPolicyName

PolicyTypeMismatch

InvalidPolicyValue

interface

CosTrading::LinkAttributesCosTrading::LinkAttributesCosTrading::LinkAttributesCosTrading::LinkAttributes

+max_link_follow_policy:FollowOption

interface

CosTrading::AdminCosTrading::AdminCosTrading::AdminCosTrading::Admin

+request_id_stem:OctetSeq

+set_def_search_card:unsigned long

+set_max_search_card:unsigned long

+set_def_match_card:unsigned long

+set_max_match_card:unsigned long

+set_def_return_card:unsigned long

+set_max_return_card:unsigned long

+set_max_list:unsigned long

+set_supports_modifiable_properties:boolean

+set_supports_dynamic_properties:boolean

+set_supports_proxy_offers:boolean

+set_def_hop_count:unsigned long

+set_max_hop_count:unsigned long

+set_def_follow_policy:FollowOption

+set_max_follow_policy:FollowOption

+set_max_link_follow_policy:FollowOption

+set_type_repos:TypeRepository

+set_request_id_stem:OctetSeq

+list_offers:void

+list_proxies:void

interface

CosTrading::OfferIdIteratorCosTrading::OfferIdIteratorCosTrading::OfferIdIteratorCosTrading::OfferIdIterator

+max_left:unsigned long

+next_n:boolean

+destroy:void

interface

CosTrading::OfferIteratorCosTrading::OfferIteratorCosTrading::OfferIteratorCosTrading::OfferIterator

+max_left:unsigned long

+next_n:boolean

+destroy:void

interface

CosTradingDynamic::DynamicPropEvalCosTradingDynamic::DynamicPropEvalCosTradingDynamic::DynamicPropEvalCosTradingDynamic::DynamicPropEval

+evalDP:any

interface

CosTradingRepos::ServiceTypeRepositoryCosTradingRepos::ServiceTypeRepositoryCosTradingRepos::ServiceTypeRepositoryCosTradingRepos::ServiceTypeRepository

+incarnation:IncarnationNumber

+add_type:IncarnationNumber

+remove_type:void

+list_types:ServiceTypeNameSeq

+describe_type:TypeStruct

+fully_describe_type:TypeStruct

+mask_type:void

+unmask_type:void

PropertyMode

PropStruct

IncarnationNumber

TypeStruct

ListOption

SpecifiedServiceTypes

ServiceTypeExists

InterfaceTypeMismatch

HasSubTypes

AlreadyMasked

NotMasked

ValueTypeRedefinition

DuplicateServiceTypeName

interface

CosTrading::TraderComponentsCosTrading::TraderComponentsCosTrading::TraderComponentsCosTrading::TraderComponents

+lookup_if:Lookup

+register_if:Register

+link_if:Link

+proxy_if:Proxy

+admin_if:Admin




Documents

Middlewares Orientés Objet - universite.jejemaes.netuniversite.jejemaes.net/MA_1/SysDis/Cours/slides07-corbam.pdf · @ Vincent Englebert - FUNDP 2 Bibliographie Les documents de