Le stub est la partie du
code générée automatiquement par un compilateur IDL
vers un langage de programmation cible. Ce code est utilisé par
le client lors des invocations statiques. Il est le lien entre le client
et l'ORB.
Il traduit :
Le squelette statique (skeleton)
est la partie du code générée automatiquement par
un compilateur IDL vers un
langage de programmation cible. Ce code est utilisé par l'Adaptateur
d'objet lors des invocations statiques. Il est le lien entre l'ORB
et l'objet d'implémentation.
Il reconstitue la requête
du client de façon à invoquer la méthode requise en
langage choisi : opération "unmarshalling".
Il traduit les paramètres de retour en
messages transmissibles sur le réseau : opération "marshalling".
La référence
d'objet est une structure désignant l'objet
CORBA. Elle est contenue dans l'espace mémoire de l'application
cliente et permet à celle-ci de dialoguer avec l'objet distant.
Cette structure contient les informations nécessaires à l'ORB
pour localiser l'objet. Ces informations sont dépendantes du protocole
de transport utilisé. Par exemple, une référence IOR
du protocole IIOP contient le nom de la machine et le port TCP/IP du serveur
où est localisé l'objet (en plus, de l'identifiant global
unique désignant l'interface IDL de l'objet).
L'Adaptateur d'objet (Object Adapter) est une entité qui assiste l'ORB pour délivrer les requêtes aux objets et à leurs activations. D'une manière primordiale, l'Adaptateur d'objet permet d'associer les implantations des objets avec l'ORB. Les adaptateurs d'objets peuvent être spécialisés pour fournir des services pour certains modèles d'implantation d'objet. Tous les adaptateurs doivent fournir les fonctionnalités suivantes :
Le référentiel d'implémentations
est le responsable de l'enregistrement
des serveurs dans le système (enregistrement de la commande exécutable).
Il est contrôlé par la commande putit dans les commandes
associées lsit, catit, rmit. Il est défini
par une interface IDL et il est implémenté par un processus
démon.
L'interface
de l'objet définit un type abstrait d'objets CORBA,
c'est à dire l'ensemble des opérations et attributs de ses
instances. Elle précise la signature de chaque opération.
Celle-ci se définit par l'intermédiaire du langage OMG-IDL.
La requête
est le mécanisme d'invocation d'une opération sur un objet.
Lorsqu'une requête est émise, elle contient la référence
de l'objet destinataire, le nom de l'opération et l'ensemble
des valeurs des paramètres en entrée.
L'ORB ou bus CORBA
achemine les requêtes de l'application
cliente vers l'objet en masquant tous les problèmes d'hétérogénéité
(langages, systèmes d'exploitation, matériels, réseaux).
L'objet CORBA
est le composant logiciel désigné par une référence
et recevant les requêtes émises par les applications clientes.
Cet objet accepte uniquement les requêtes pour les opérations
décrites dans son interface.
Le processus
d'activation est le processus d'association d'un objet d'implantation
à un objet CORBA. Lorsqu'une requête arrive à destination
d'un objet CORBA, le bus active une implantation
et lui transmet la requête. Au cours du temps, un même objet
CORBA peut se voir associer des implantations distinctes. (VOIR BOA)
L'implantation
de l'objet est l'entité codant l'objet CORBA à
un instant donné. Cette entité stocke l'état de l'objet
CORBA et fournit une réalisation pour chaque opération de
l'objet. Au cours du temps, un même objet CORBA peut se voir associer
des implantations différentes.
Le code
d'implantation regroupe les traitements associés
à l'implantation des opérations de l'objet CORBA. Cela peut
être par exemple une classe Java aussi bien qu'un ensemble de fonctions
C.
L'application
serveur est la structure d'accueil des objets d'implantation
et des exécutions des opérations. Cela peut être par
exemple un processus Unix.
GIOP (General Inter-ORB
Protocol) spécifie un ensemble de formats pour les messages ainsi
qu'une représentation commune des données échangées
entre les ORBs. La représentation
des données communes est basée sur la spécification
CDR (Common Data Representation).
IIOP (Internet
Inter-ORB Protocol) est l'implémentation du protocole GIOP basé
sur TCP/IP.
Object Management Group(OMG)
est un consortium international créé en 1989 et regroupant
plus de 850 acteurs du monde informatique : des constructeurs (IBM, Sun),
des producteurs de logiciel (Netscape, Inprise, IONA Tech.), des utilisateurs
(Boeing, Alcatel) et des institutionels et universités (NASA, INRIA,
LIFL). L'objectif de ce groupe est de faire émerger des standards
pour l'intégration d'applications distribuées hétérogènes
à partir des technologies orientées objet. Ainsi les concepts-clés
mis en avant sont la réutilisabilité, l'intéropérabilité
et la portabilité des composants logiciels.
Les services
objet communs (CORBAServices) fournissent sous forme d'objets
CORBA, spécifiés grâce au langage OMG-IDL, les fonctions
nécessaires à la plupart des applications réparties.
Actuellement, l'OMG a défini des services pour
les annuaires (Nommage et Vendeur), le cycle de vie des objets, les relations
entre objets, les évenements, les transactions, la sécurité,
la persistance, etc. Au fur et à mesure des besoins, l'OMG ajoute
de nouveaux services communs.
Le service Nommage
(Naming Service) est l'équivalent des "pages blanches" : les objets
sont désignés par des noms symboliques. Cet annuaire est
matérialisé par un graphe de répertoires de désignation.
Le service Vendeur
(Trader Service) est l'équivalent des "pages jaunes" : les objets
peuvent être recherchés en fonction de leurs caractéristiques.
Le service Cycle
de Vie (Life Cycle Service) décrit des interfaces
pour la création, la copie, le déplacement et la destruction
des objets sur le bus. Il définit pour cela la notion de fabriques
d'objets ("Object Factory).
Le service Propriétés
(Property Service) permet aux utilisateurs d'associer dynamiquement des
valeurs nommées à des objets. Ces propriétés
ne modifient pas l'interface IDL, mais représentent des besoins
spécifiques du client comme par exemple des annotations.
Le service Relations
(Relationship Service) sert à gérer des associations dynamiques
(appartenance, inclusion, référence, auteur, emploi, …) reliant
des objets sur le bus. Il permet aussi de manipuler des graphes d'objets.
Le service
Externalisation (Externalization Service) apporte un mécanisme
standard pour fixer ou extraire des objets du bus. La migration, le passage
par valeur, et la sauvegarde des objets doivent reposer sur ce service.
Le service Persistance
(Persistent Objetc Service) offre des interfaces communes à un mécanisme
permettant de stocker des objets sur un support persistant. Quel que soit
le support utilisé, ce service s'utilise de la même manière
via un "Persistent Object Manager". Un objet persistant doit hériter
de l'interface "Persistent Objetc" et d'un mécanisme d'externalisation.
Le service Interrogations
(Query Service) permet d'interroger les attributs des objets. Il repose
sur les langages standards d'interrogation comme SQL3 ou OQL. L'interface
Query permet de manipuler les requêtes comme des objets
CORBA. Les objets résultats sont mis dans une collection. Le
service peut fédérer des espaces d'objets hétérogènes.
Le service Collections
(Collection Service) permet de manipuler d'une manière uniforme
des objets sous la forme de collections et d'itérateurs. Les structures
de données classiques (listes, piles, tas, …) sont construites par
sous-classement. Ce service est ainsi conçu pour être utilisé
avec le service d'interrogations pour stocker les résultats de requêtes.
Le service Changements
(Versionning Service) permet de gérer et de suivre l'évolution
des différentes versions des objets. Ce service maintient des informations
sur les évolutions des interfaces et des implantations. Cependant,
il n'est pas encore spécifié officiellement.
Le service Sécurité
(Sécurity 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 serveurs
d'authentification,de clients/rôles/droits (et délégation
de droits), d'IIOP sécurisé.
Le service Transactions
(Object Transaction Service) assure l'exécution de traitements transactionnels
impliquant des objets distribués et des bases de données
en fournissant les propriétés ACID.
Le service Concurrence
(Concurrency Service) fournit les mécanismes pour contrôler
et ordonnancer les invocations concurrentes sur les objets. Le mécanisme
proposé est le verrou. Ce service est conçu pour être
utilisé conjointement avec le service Transactions.
Le service Evénements
(Event Service) permet aux objets de produire des événements
asynchrones à destination d'objets consommateurs à travers
des canaux d'événements. Les canaux fournissent deux modes
de fonctionnement. Dans le mode "push ", le producteur a l'initiative de
la production, le consommateur est notifié des événements.
Dans le mode "pull ", le consommateur demande explicitement les événements,
le producteur est alors sollicité.
Le service Notification
(Notification Service) est une extension du service précédent.
Les consommateurs sont uniquement notifiés des événements
les intéressant. Pour cela, ils posent des filtres sur le canal
réduisant ainsi le trafic réseau engendré par la propagation
des événements inintéressants.
Le service Messagerie
(CORBA Messaging [OMG-CM]) définit un nouveau
modèle de communication asynchrone permettant de gérer des
requêtes persistantes lorsque l'objet appelant et l'objet appelé
ne sont pas présents simultanément sur le bus. Cela permet
d'avoir des fonctionnalités proches des MOMs (" Message Oriented
Middleware ").
Le service Temps
(Time Service) fournit des interfaces permettant d'obtenir une horloge
globale sur le bus (Universal Time Object), de mesurer le temps et de synchroniser
les objets.
Le service Licences
(Licensing Service) permet de mesurer et de contrôler l'utilisation
des objets, et cela en vue de facturer les clients et de rémunérer
les fournisseurs.
Les Interfaces de
domaine (Domain Interfaces) définissent des objets
de métiers spécifiques à des secteurs d'activités
comme la finance (e.g. monnaie électronique), la santé (e.g.
dossier médical) et les télécoms (e.g. transport multimédia).
Leur objectif est de pouvoir assurer l'interopérabilité sémantique
entre les systèmes d'informations d'entreprises d'un même
métier : les "Business Object Frameworks" (BOFs).
Les utilitaires
communs (CORBAfacilities) sont des canevas d'objets ("Frameworks")
qui répondent plus particulièrement aux besoins des utilisateurs.
Ils standardisent l'interface utilisateur, la gestion de l'information,
l'administration, le Workflow, etc.
Les objets applicatifs
(Application Objects) sont ceux qui sont spécifiques à une
application répartie et ne sont donc pas standardisés. Toutefois,
dès que le rôle de ces objets apparaît dans plus d'une
application ils peuvent alors rentrer dans une des catégories précédentes
et donc être standardisés par l'OMG.