technologie des composants

CBSE: Component Based Software Engineering et CBSD: Component Based Software Development

Technologie des Composants

Cours de Génie Logiciel 2

Définitions

� CBSE (Component based software engineering) ?

� Logiciel = assemblage de composants (éventuellement indépendant)

� CBSE= développement des composants et développement par les composants

� Un composant alors?


Notion de composant

� What is a component ?

� “A binary unit of independent production, acquisition, and

deployment that interact to form a functioning system” - C.

Szyperski, Component Software

� “A component is an independently deliverable package of

operations.” - Texas Instruments Literature

� “A component is just a physical packaging of a society of classes.” - Grady Booch

� “A replaceable unit of development work which

encapsulates design decisions and which will be composed

with other components as part of a larger unit.” - DesmonD’Souza, in Catalysis


Composant� Pas de définitions universel (un peu comme les

objets dans les années 90)

� Composant est fait pour la composition (seul point commun dans leur nature)

� S’appuyer sur les définitions émergentes de l’industrie (il y en a 4 principales)

� Composant= unité de composition, peut être déployé indépendamment et peut être assemblé(est sujet à composition) par une tierce personne [Szyperski]


OT vs CBSE

� “OT is Neither Necessary Nor Sufficient for CBSE”

� OT was a useful and convenient starting point for CBSE

� OT did not express full range of abstractions needed by

CBSE(insufficiency)

� It is possible to realize CBSE without employing OT(non-

necessity)

� CBSE induit des changements dans l’approche de conception des systèmes, de la gestion des projets

et du style d’organisation


Structure d’un Composant

ImplantationInterface (opérations offertes)

Interface (opération requise)


Spécification des composants

Un méta modèle UML pour la spécification sémantique des composants


Interfaces

� Spécification des points d’accès au composant

� Capture la syntaxe des opérations (propriétés

fonctionnelles)

� Utilisation de l’IDL (interface Definition

Language)


CBSD

� Développement des composants

� Construire des composants ouverts à l’intégration

� Role: Développeur de composant

� Développement avec les composants

� Intégrer/assembler des composants pour en faire

une application

� Role: Intégrateur de composants

� Obstacles à surmonter?


Contraintes

� Pour le développeur

� Connaissance insuffisante de l’environnement d’exécution cible

� Pour l’intégrateur

� Mise en œuvre des adaptateurs (« glue »)

� Pb. Evaluer le délai de réalisation de

l’adaptateur p/r à celui du composant!


Développement de composants

� Toujours documenter tous les aspects du composant

� Les fonctionnalités

� Les propriétés (non fonctionnelles/techniques)

� performance,

� Consommation des ressources,

� Limitations et

� Robutesse

� Mettre à disposition un jeu de Test

� Toujours tester le composant dans l’environnement cible


Développement des composants

� Provide source code to help the application developerunderstand the semantics of the component.

� Design the components so that they can be integrated intoexisting component models.

� Describe models in which the component works and describehow to make it work with other models.

� Carefully generalize the components to permit reuse in a varietyof future contexts.

� Note, however, that solving a general rather than a specificproblem requires more work.

� Make sure that the application developers can adapt thecomponent to their requirements. This can be done with sinkinterfaces to which the user adds an interface to the component so that the component can utilize that interface to communicatewith the user.


Organisation et Gestion des Projets

� Evolution de l’architecture des applications� Système centralisé vers des systèmes distribués� Emergence des Technologies de l’Internet

� Inadéquation des modèles de processus traditionnel (modèles de la cascade, itératif, spirales et prototypage)� Identification des composants qui peuvent servir dans le cadre du

produit à developper� Selection des composants compatibles avec le produit cible� Création des composants propriétaires (ceux des fonctionnalités

dont on a pas trouver de composants) � Adaptation des composants sélectionnés à la spécification des

besoins (Wrapping) � Assemblage/déploiement du produit dans le cadre d’un

framework pour composants� Remplacement des composants par de nouvelles versions.


Cycle de CBSD vs modèle de la Cascade


Niveaux d’utilisation

Enterprise Architecture

System Architecture

Application Architecture

Macro Architecture

Micro Architecture

object

Technologiedes composants

TechnologieObjet


Les composants

� Qu’est-ce que c’est ?� module logiciel autonome pouvant être installé sur

différentes plates-formes

� qui exporte différents attributs, propriétés ou méthodes

� qui peut être configuré

� capable de s’auto-décrire

� Intérêt : être des briques de base configurables pour permettre la construction d’une application par composition

� Quelques composants de l’industrie� COM / DCOM, Java Beans,

� Enterprise Java Beans, Composants CORBA


Modèles de composants:caractérisation du composant� Comment coopère un composant

� Ce que fournit le composant (entrées)

� composantes, interfaces, opérations, propriétés

� Ce qu’utilise le composant (dépendances)

� composition et références aux autres composants

� modes de communication des connecteurs (synchrone, asynchrone, flots)

� Propriétés configurables du composant

� Contraintes techniques (QoS)� middleware : placement, sécurité, transaction

� internes : cycle de vie, persistance

� implantation : OS, bibliothèques, version


Modèle de composants:Conteneur et structures d’accueil� Conteneur

� encapsulation d’un composant (et ses composantes)

� prise en charge (masque) les services systèmes

� nommage, sécurité, transaction, persistance ...

� prise en charge partielle des connecteurs

� invocations et événements

� techniquement par interposition (ou délégation)

� Structures d’accueil

� espace d’exécution des conteneurs et des composants

� médiateur entre les conteneurs et les services systèmes


Modèles de composants:Conteneur et structure d’accueil


Modèle de composants: synthèse

� Le modèle gère l’infrastructure� Permet ainsi l’utilisateur de se concentrer sur les besoins

métier

� Offre différents niveau de services aux développeurs (tableau ci-après)

CORBA Services

EJB/J2EECOM+Services d’entreprise

CORBA IIOPRMIDCOMDistribution

CORBA Objects

JavaBeansCOM component

Composant de base

CORBAJavaCOM

L’infrastructure d’accueil

Les middlewares


Contraintes de la distribution(1)

� Protocoles d'accès distants (CORBA, RMI, IIOP…)

� Gestion de la charge,

� Gestion des pannes,

� Persistence, intégration au back-end,

� Gestion des transactions,

� Clustering,

� Redéploiement à chaud,

� Arrêt de serveurs sans interrompre l'application,


Contraintes de la distribution(2)

� Gestion des traces, règlages (tuning and auditing),� Programmation multithread� Problèmes de nommage

� Securité, performances,� Gestion des états

� Cycle de vie des objets� Gestion des ressources (Resource pooling)� Requête

� par message (message-oriented midddleware)

� Par appel de procédure distante (RPC)

� Par invocation de méthodes distantes (Object-orientedmiddleware)


Solution

� Qui s'occupe de tout ceci : le middleware !

� Offre un protocole de communication et un ensemble de services

� Permet que l’on se concentre sur l’application sans s’occuper du reste

� Le middleware peut-il exister en dehors d’un modèle de composants???


Le concept de middleware

� Face aux besoins de solutions informatiques de plus en plus éclatées et de grande échelle, se posent de façon aiguë les problèmes� d’intégration de logiciels divers

� éviter les O(n×n) passerelles

� d’ouverture du système au monde extérieur� appréhender l’économie mondiale

� de conception rapide d’applications portables� logiciel de plus en plus évolutif

� La solution est de faire abstraction des supports matériels et logiciels utilisés, et de se limiter à un mode de coopération unifié entre applications.� Middleware


Middleware

Noeud1 Noeud2 Noeudn

Service de communicat ion

Rôle d’un middleware(1)


Rôle des middlewares(2)

� Middleware ou intergiciel est la couche du «milieu»

� C’est une notion des années 1990 (CORBA, …)

� Un middleware se positionne entre les

applications et les supports matériels et les

moyens de communications, en faisant

abstraction de ceux-ci.

� L ’accès à ces composantes se fait par des API

normalisées et portables


Rôles d’un middleware(3)

� Un middleware propose un mode de

coopération entre applications séparant

interface et implantation, souvent fondé sur le

mode client/serveur et le n-tier

Programme

utilisateur

Serveur de

traitements

Serveur de

données

Interface au

serveur de

traitement

Interface au

serveur de

données


Modèle client/serveur

� Client� Programme d’application faisant l’interface entre

un utilisateur et le noyau de l’application.� Tient compte : des formalismes de l’IU

� de la machine de support

� des logiciels disponibles chez le client

� Serveur� Programme fournissant les services d’une

application en faisant abstraction des formalismes, des logiciels d’utilisation et des machines support.


Exemple de modèle client/serveur

�� MinitelMinitel : le logiciel client (PROM) fait l’édition des requêtes et l’affichage à partir de grilles prédéfinies. Quand existe RAM, les grilles spécifiques d’uneapplication peuvent être téléchargées et rester surle poste Minitel.

�� Bases de Bases de donndonnééeses : Un serveur SQL rend la base interrogeable à distance depuis des machines différentes, des systèmes de fichiers différents, des interprètes SQL différents. L’élaboration, l’édition, la connexion des requêtes, la mise en forme des résultats sont faites par le client.

�� WebWeb : Browsers différents.


Fonction de l’intergiciel

� L’intergiciel a quatre fonctions principales� Fournir une interface ou API (Applications Programming

Interface) de haut niveau aux applications

� Masquer l’hétérogénéité des systèmes matériels et logiciels sous-jacents

� Rendre la répartition aussi invisible (“ transparente”) que possible

� Fournir des services répartis d’usage courant

� L’intergiciel vise à faciliter la programmation répartie� Développement, évolution, réutilisation des applications

� Portabilité des applications entre plates- formes

� Interoperabilité d’applications hétérogènes


Typologie des intergiciels

� Middlewares par files de messagespar files de messages� files de messages entre applications

� DECmessageQ, IBM MQSeries

� Middlewares orientorientééss éévvéénementsnements� bus applicatifs – ToolTalk

� communications anonymes entre agents

� Middlewares par par appelappel de de procprocééduresduresdistantesdistantes� appel de procédures chez le fournisseur

� RPC Sun, OSF DCE


Typologie des intergiciels

� Middlewares orientorientééss objetobjet� CORBA de l’OMG; DCOM de Microsoft

� Middlewares orientorientééss documentsdocuments : Web� orientés navigation hypertexte

� traitement dans le client (applets) et dans le serveur (cgi, servlets)

� Intégration d’applications� Web Services

� Coordination

� Accès aux données, persistance

� Support d’applications mobiles


�� AbstractionAbstraction : l’extérieur d’une application est vu comme un ensemble de files de messages de et vers lesquelles on peutrecevoir et envoyer des messages.

�� CoopCoopéérationration : asynchrone par l'intermédiaire de files de messages gérées par le middleware. Les applications communicantes doivent être d’accord sur le contenu des messages - qui n’est pas géré par le middleware.

Middlewaresauvegarde sauvegarde

réseau

Application A Application B

Interprétation

Middlewares par files de messages


Application 1

Application 4

Application 3

Application 2

�� AbstractionAbstraction : une application peut publier des événements sur

le bus, et s’abonner à des événements.

�� CoopCoopéérationration : asynchrone, anonyme et multiple par diffusion. Un événement peut être reçu par 0, 1 ou n récepteurs. Les

applications doivent se mettre d’accord sur les types

d’événements.

Middlewares sur Bus a Evènements


middlewares par appel de procedures distantes

�� AbstractionAbstraction : une application peut appeler des procédures dansd’autres applications, et fournir des points d’entrée de procéduresaux autres.

�� CoopCoopéérationration : client/serveur synchrone. Les interfaces de procédures sont publiées dans un langage RPC IDL qui permetd’obtenir les souches d’appel et de réception. Il peut y avoir

différentes sémantiques d’appels (sécurité, transactions…)

Client Fournisseur

Middleware /RPC

Proc A

Proc B

Proc A

Proc B


Client Fournisseur

Middleware

IDL

Middlewares Orientés Objets

�� AbstractionAbstraction : une application appelle des services distantsperçus comme des objets, elle peut aussi rendre visible des services décrits par des interfaces orientées objet.

�� CoopCoopéérationration : client/serveur par appel de méthodes distantes. L’objet est l’élément de structuration. Les interfaces d’objets

sont publiées dans un langage IDL.


Schéma de fonctionnement

appel

Site Appelant (Client) Site Appelé (serveur)

Proxy

Retour Biblio.

Communication

Emballage

Envoi(req.,param.)

<attente>

Réception(résultats)

Deballage

Exécution Procédure

Squelette et Dispatcher serveur

Biblio. Communication

déballage

Réception(req.,param.)

envoi(résultats)

emballage

Client Messages

Communication Physique

Communication Logique

LL ’’ARCHITECTURE DE ARCHITECTURE DE LL ’’OMGOMG

CORBA


ApplicationCliente Bus CORBA

Référencede l’objet

Interfacede l’objet

Requête

Objet

CORBAActivation

ApplicationServeur

Etat del’objet

Code d’implantation

Le Modèle objet client/serveur


Le Modèle objet client/serveur

�� Application Application clientecliente : programme qui invoque des objets au travers du bus.

�� RRééfféérencerence de de ll’’objetobjet : structure désignant l’objet CORBA permettant de le localiser.

�� Interface de Interface de ll’’objetobjet : type abstrait de l’objet CORBA définissantles attributs et opérations.

�� RequêteRequête : mécanisme d’invocation de l’objet.

�� ObjetObjet CORBACORBA : composant logiciel cible.

�� ActivationActivation : processus d’association d’un objet d’implantation àun objet CORBA.

�� Implantation dImplantation d’’un un objetobjet : entité codant l’objet CORBA à un instant donné.

�� Code Code dd’’implantationimplantation : traitements associés aux opérations.

�� Application Application serveurserveur : structure d’accueil des objets d’implantationet des exécutions.


Interfacesde domaines

Objetsapplicatifs

Utilitaires communs

Bus d’objets répartis

Services d’objets

communs

Spécifiques etnon standardisés

Santé

Télécoms IHM

Finance

Administration

PersistanceNommage

Data Warehouse

Evénements CollectionsRelations

Workflow

Vendeur

TransactionsInterrogations

Propriétés Concurrence SécuritéExternalisation

Cycle de vie LicencesChangements Temps

L’architecture globale de l’OMG


L’architecture globale de L’OMG

� Le bus à objets répartis (Object Request Broker)

� Les services objets communs (Object Services)

� Les utilitaires communs (Corba Facilities)

� Les interfaces de domaines (Domaine Interfaces)

� Les objets applicatifs (Application Objects)


Caractéristiques du bus d’objets repartis CORBA� Liaison avec « tous » les langages de programmation par

projection d ’un langage commun IDL.

� Transparence des invocations : les requêtes aux objets semblenttoujours être locales, le bus se chargeant de les acheminer « au mieux ».

� Invocations statiques et dynamiques : requêtes compilées ou créées à l ’exécution.

� Système auto-descriptif : les interfaces des objets sont connuesdu bus et aussi accessibles par les programmes (référentiel des interfaces).

� Activation automatique et transparente des objets : les objets nesont en mémoire que s’ils sont utilisés.

� Interopérabilité des bus : à partir de CORBA 2.0, un protocolecommun a été défini (IIOP sur TCP/IP).


Client Fournisseur

DIISII SSI DSI

Interface Bus Interface Bus

Adaptateur d’objets

O R B O R B

Référentiel des interfaces Référentiel des implantations

L’architecture du bus CORBA


L’architecture du bus CORBA

� ORB : noyau de communication

� SII : interface d’invocations statiques

� DII : interface d’invocations dynamiques

� IR : référentiel des interfaces IDL

� Interface du bus : primitives de base

� SSI : interface de squelettes statiques

� DSI : interface de squelettes dynamiques

� BOA : adaptateur d’objets

� ImplR: référentiel des implantations


Éléments d’implantation

� Ces différents blocs sont décrits dans le langage IDL, ce qui les rend accessibles au travers du bus. Cela permet d’homogénéiserles différentes implantations possibles de la norme.

� Il est possible de construire un bus CORBA :� A l’intérieur d’un seul processus utilisation d’IDL pour spécifier� entre processus d’une même machine système d’exploitation

objet (Spring)� entre processus de sites différents par exemple sur Internet avec

IIOP� par fédération du bus CORBA passerelles spécifiques ou

génériques (DSI)� Les IOR pour IIOP doivent contenir :

� l’adresse IP de la machine Internet� un port pour se connecter au serveur� une clé -de format libre- pour désigner l’objet dans le serveur



Objets applicatifs


Interfaces de domaines

Santé

Télécoms

Finance

Utilitaires communs

IHM Administration

Data Warehouse Workflow

Services d’objets

communs

PersistanceNommage Evénements CollectionsRelations Vendeur


LicencesTempsTransactionsInterrogations Cycle de vie Changements

Les services objet communs

� COSS1 : Nommage, Evénement, Persistance, Cycle De Vie

� COSS2 : Transactions, Concurrence, Relations, Externalisation

� COSS3 : Sécurité, Temps

� COSS4 : Interrogations, Licences, Propriétés

� COSS5 : Vendeur, Collections, Changements



Objets applicatifs


Interfaces de domaines

Santé

Télécoms

Finance

Utilitaires communs

IHM Administration

Data Warehouse Workflow

Services d’objets

communs

PersistanceNommage Evénements CollectionsRelations Vendeur


LicencesTempsTransactionsInterrogations Cycle de vie Changements

Utilitaires communs : Interface utilisateur, gestion de l ’information, administration du système, gestion de tâches…

Interfaces de domaine (objets métiers) : santé, télécoms, finances, commerce… Business Object FrameWorks (BOFs)

Les utilitaires communs et les interfaces de domaines


LL ’’ O M G I D LO M G I D L

� INTERFACE DEFINITION LANGUAGE

� Le langage IDL permet d’exprimer sous la forme de

contrats IDL, la coopération entre les fournisseurs et les utilisateurs de services

� en séparant l’interface de l’implantation des objets

� en masquant les divers problèmes liés à l’interopérabilité,

l’hétérogénéité et la localisation de ceux-ci

� Contrat IDL = {interfaces écrites en IDL}

� Interface IDL = {attributs et opérations d’un type d’objet}


� Un contrat IDL isole les clients et les fournisseurs de l’infrastructure logicielle et matérielle les mettant en relation, c’est-à-dire du bus CORBA.

� Les contrats IDL sont projetés en souches IDL dansl’environnement de programmation du client et en squelettes IDL dans l’environnement de programmation du fournisseur.

� Le client invoque localement les souches pour accéder aux objets

� Les souches IDL construisent des requêtes, qui vontêtre transportées par le bus, puis délivrées par celui-ci aux squelettes IDL qui les délégueront aux objets

Contrat

IDL

Bus CORBASouche Squelette

Client Fournisseur

L ’ O M G I D L


Valeurs IDL

Types complexesTypes dynamiques Types d’objets

Types simples

TypeCode

any

Enum

Struct

Union

Array

Sequence

Définis par

l’utilisateur

ShortUShort

LongUlong

LongLongULongLong

FloatDoubleLongDouble

CharWChar

StringWString

BooleanOctet

IDL : un langage fortement type


IDL : UN LANGAGEFORTEMENT TYPE

Le format des types de base est défini par la norme pour régler les problèmes d’hétérogénéité des données.

Nouveauté : les types de métadonnées :

TypeCodeTypeCode : pour stocker la description d’un type.

AnyAny : pour stocker une valeur d’un type et son TypeCode.

Interface PileGénérique {

readonly attribute any sommet;

void empiler (in any valeur);

...

ID

L


interfaceCalendrierFerie: Calendrier {..};

interface Calculatrice {..};

Interface Calendrier_Calculatrice: Calendrier, Calculatrice {..};

Interface CalendrierFerie_Calculatrice: CalendrierFerie_Calculatrice {};

Calendrier

CalendrierFerie_Calculatrice

CalendrierFerieCalendrier_Calculatrice

Calculatrice

I D L : HERITAGE


� Héritage simple et multiple

� Pas de redéfinition ni de surcharge

� Conflits de noms interdits

� Héritage répété sans conflits de noms

� Un objet ne peut implanter qu’une et une

seule interface (pour l’instant)

I D L : HERITAGE


La projection du langage IDL

� Une projection est la traduction dans un langage

d’implantation de spécifications IDL

� Les règles de projection sont normalisées et fixent la

traduction de chaque construction IDL en une ou des

constructions du langage cible.

� C, C++, SmallTalk, Ada, Java et Cobol orienté objet.

Fichier IDL

PrécompilateurIDL vers Java

PrécompilateurIDL vers C++

Client C++

Souches C++

ORB A

Serveur Java

Squelette Java

ORB BIIOP


OMG IDL : CONCLUSION

� Langage simple et complet

�� MAISMAIS� Règles de projections complexes� Pas de passage d’objets par valeur

� Pas de possibilités d’exprimer autre chose que les interfaces.� Sémantiques

� pré/post conditions

� graphes d’objets� ...


LES COMPOSANTES DU LES COMPOSANTES DU BUS CORBABUS CORBA

Les principales composantes nécessaires à la mise en œuvre d’un bus CORBA sont :

• l’interface de base au bus• les adaptateurs d’objets• le référentiel des interfaces• le référentiel des implémentations (non encore normalisé)

Elles sont décrites en IDL dans le module CORBA

Elles complètent le mécanisme d’invocations (SII) et de réception (SSI) statiques (souches et squelette résultat de la compilation IDL).

Un autre mécanisme de coopération client/serveur consiste en interfaces d’invocations (DII) et squelettes (DSI) dynamiques.


L’INTERFACE O R B

Une référence vers un objet de type CORBA::ORB est retourné àl’initialisation du bus.

Elle permet d’obtenir ensuite les premiers objets utiles : les objets

notoires que sont par exemple le service de nommage et le

référentiel des interfaces.

interface ORB {

typedef string ObjectId;typedef sequence<ObjectId>ObjectIdList;

ObjectIdList list_initial_services O;Pbject resolve_initial_references (in ObjectID identifier);};

ID

L


L’INTERFACE O R B

L’interface ORB définit aussi les opérations de conversion référence d’objet chaîne IOR

interface ORB {

string Object_to_string (in Object obj);Object string_to_Object (in string str);

};

ID

L


LES ADAPTATEURS D’OBJETS

� Connaître les implantations utilisées et savoir les activer,

� savoir générer et interpréter des références d ’objets,

� savoir déléguer les demandes d ’opérations vers les objets

BOA : Basic Object AdapterBOA : Basic Object Adapter

LOA : Library Object AdapterLOA : Library Object Adapter

OODA : ObjectOODA : Object--Oriented Database AdapterOriented Database Adapter

POA : Portable Object Adapter (nouveau)POA : Portable Object Adapter (nouveau)

COA : Card Object adapter (LIFL/Gemplus)COA : Card Object adapter (LIFL/Gemplus)

Une implantation d’un objet doit fournir un espace mémoire et un contexte d’exécution. L’activation d’une implantation est réalisée dans le monde CORBA par un adaptateur d’objet.Cela isole le bus des différentes technologies pouvant être employées dans l’implantation des objets.

Un adaptateur d’objet doit :


LE REFERENTIEL DES INTERFACES

� Distribution des interfaces IDL,

� contrôle des graphes d’héritage,

� construction d’outils générateur de code, AGL ou browsers,

� vérification des signatures des opérations,

� fédération de bus CORBA,

� introspection et objets auto-descriptifs.

Toutes les définitions IDL sont conservées dans un référentiel des interfaces structuré comme un ensemble d’objets, eux -mêmes décrits par des interfaces IDL et donc accessibles du bus.

Utilisations :


LE REFERENTIEL DES INTERFACES

CC’’est la ressource la plus volumineuse des implantations CORBAest la ressource la plus volumineuse des implantations CORBA

(+ de 50 % des points d(+ de 50 % des points d ’’entrentréée)e)

La norme CORBA définit les interfaces IDL de consultation,de navigation et de modification du référentiel des interfaces.


LES MECANISMES DYNAMIQUES

Le mLe méécanisme DII (Dynamic Invocation Interface)canisme DII (Dynamic Invocation Interface)Ce mécanisme permet à un client d’invoquer les objets sans utiliser de souches

IDL prégénérées. Pour cela le client va construire dynamiquement les requêtes,

et doit donc découvrir dynamiquement, via l’IR, l’interface des objets.

L ’API DII permet de créer des objets de type Request, et d’y placer la référence

de l’objet cible, le nom de l’opération, la liste des arguments et le résultat.

Nom de l’opération

Request

Référence de l’objet

résultat

nom de l’argument

valeur

any

TypeCode


LES INTERETS DU MECANISME DII

� Le client s ’adapte dynamiquement aux objets qu’il souhaite invoquer. Ceux-ci peuvent donc évoluer sans modifications de clients.

� Possibilité de construire des clients sans connaître les types des objets qu’ils utiliseront. Indispensable pour la navigation dans les bases d’objets découvertes dynamiquement.

� Mécanismes de base pour la création d’IHM, de browsers et de langages interprétés utilisant des objets CORBACORBA.


LES INTERETS DU MECANISME DII

L ’interface DII est une interface complexe.

Des outils nouveaux doivent permettre de masquer

cette complexité au profit d ’une plus large utilisation..



Le mLe méécanisme DSI (Dynamic Skeleton Interface)canisme DSI (Dynamic Skeleton Interface)

Ce mécanisme permet à un serveur de recevoir

des requêtes sans utiliser le squelettes IDL

prégénérés. Il peut donc traiter des requêtes pour n ’importe quel type d ’objets.

LL ’’API DSIAPI DSI permet de récupérer les différentes

composantes d ’une requête.



Le mLe méécanisme DSI canisme DSI fut initialement défini pour permettre la mise en place de passerelles entre bus CORBA. Il est possible de l’utiliser pour implanter dynamiquement des objets dans un serveur.

clientclient

requête Brequête Brequête Arequête A

serveurserveur

passerellepasserelle

IDLIDL IDLIDLDIIDIIDSIDSI


LES SERVICES NORMALISES DE CORBA

� COSS 1 : Nommage, Evénement, Persistance, Cycle de vie.

� COSS 2 : Transactions, Concurrence, Relations, Externalisation.

� COSS 3 : Sécurité, Temps.

� COSS 4 : Interrogations, Licences, Propriétés.

� COSS 5 : Vendeur, Collections, changements.

Common Object Service Specifications COSS


� L’objectif est de permettre de retrouver

dynamiquement les objets nécessaires

(service de « pages blanches »).

� Ce service gère un graphe de contextes de

nommage, chaque contexte étant une liste

d’associations nom symbolique - référence

d’objet.

Service nommage: Name service


CosNaming::Name est la définition IDL des chemins d ’accès dans le graphe de contextes

Un chemin est une séquence de composants

(en IDL : CosNaming::NameComponent)




� Un contexte est défini en IDL par

CosNaming::NamingContext et fournit des

opérations de base telles l ’ajout (bind) ou la

recherche (resolve) d ’une association, ou

encore l ’obtention du contexte dans une liste

définie par

� CosNaming::BindingList et

� CosNaming::Binding.


� Même principe que le service nommage sous

la forme «« pages jaunespages jaunes »»

� Les fournisseurs enregistrent leurs objets

dans ce service en les caractérisant par un

ensemble de propriétés (paires nom-valeur).

Les clients indiquent le type de service désiré

et des critères pour effectuer la recherche.

� Comme pour le service de nommage,il est

possible de fédérer les services Vendeur.

Service vendeur: Trader service


Service évènements: Event Service

� Ce service permet aux objets de produire des

événements asynchrones à destination

d’objets consommateurs, et cela au travers

de canaux d’événements.

� Mode Push :

� le producteur a l’initiative,

� le consommateur est notifié des dépôts.

� Mode Pull :

� le consommateur émet des requêtes de retrait.


Un canal peut être nonnon--typtypéé (any) ou typtypéé (IDL).

Push Pull

Canal d’événement

producteur consommateur

Service évènements: Event Service


Client Serveur

ORB

context

Transaction Service

1-Begin T

3-register

5-propagate

4-End T

2-invoke (c)

Service transactions: Object Transaction

Service (OTS)

� Ce service assure l’exécution de traitements

transactionnels impliquant des objets

distants.


Service securite: Security Service

� Ce service permet d’identifier et d’authentifier

les clients, de chiffrer et de certifier les

communications et de contrôler les

autorisations d’accès.

� Ce service utilise les notions de :

� serveur d’authentification

� clients / rôles / droits (et délégation de droits)

� Secure IIOP (utilisant Kerberos ou SSL)


� Ce service fournit les mécanismes pour contrôler et ordonnancer les invocations concurrentes sur les objets.

� Le mécanisme proposé est le le verrouverrou.� Ce service est conçu pour être utilisé

conjointement avec le service de transactions.

Service concurrence d ’acces: Concurrency

Service


� Ce service décrit des interfaces pour

� la création,

� la copie,

� le déplacement,

� la destruction

des objets du bus.

� Il définit la notion d’Object Object FactoryFactory

Le service cycle de vie Life Cycle

Service


Le service changements (Versionning

Service)

� Ce service permet de gérer et de suivre

l’éévolutionvolution des différentes versions des

objets.

� Ce service maintient des informations sur les

évolutions des interfacesinterfaces et des

implantationsimplantations.


Le service temps (Time Service)

� Ce service fournit des interfaces permettant

� d’obtenir une horloge globale sur le bus (UniversalTime Object)

� de mesurer le temps

� de synchroniser les objets.


Conclusion

� Les Middlewares répondent aux besoins des applications et systèmes � répartis,� hétérogènes,

� ouverts,

� évolutifs.

� Restent les problèmes liés à leur complexité de mise en œuvre

� Ils servent de socle aux infrastructures d’accueil

� L’émergence des modèles de composants a favorisé la diffusion de la technologie.


Bibliographie� Szyperski C. Component software: beyond object-oriented

programming. Addison wesley, reading, Mass., 2nd Edition

� Gamma E. and al. Design Patterns, Elements of reusable Object-Oriented Software. Addison Wesley, Reading, MA, 1995

� Wolfgang Pree. Design Patterns et Architectures logicielles. Viubert, 1998

� Didier DONSEZ. Les Enterprise Java Beans. Cours de GL, Université Joseph Fourier

� Quelques liens

� Java beans-> http://java.sun.com/beans/doc/

� Corba -> www.omg.org

technologie des composants

Documents