III. Common Object Service Specification 1▲
Avant de détailler les services du COSS I à proprement dit, décrivons l'architecture générale d'un ObjectService. Un service est caractérisé par les interfaces qu'il fournit et par les objets qui fournissent ces interfaces. Un service peut impliquer un seul objet (par exemple un timer), plusieurs objets qui fournissent le même type d'interface (par exemple des objets threads) ou plusieurs objets qui fournissent des types d'interfaces distincts qui héritent d'un type d'interface de service (par exemple tout objet fournissant le service Cycle de Vie).
Chaque ObjectService fournit son service à un jeu d'utilisateurs qui sont typiquement des applications ou des Common Facilities, mais qui peuvent aussi être d'autres ObjectServices (cf. Fig 3).
III-A. Naming Service▲
Le service de nommage fournit le principal mécanisme à travers lequel la plupart des objets d'un système basé-ORB situent les objets qu'ils veulent utiliser. Pour cela, il utilise des noms. Un nom est une séquence ordonnée de composants. Chaque composant sauf le dernier nomme un contexte, le dernier dénote les objets liés par le nom. Un composant est composé de deux attributs :
- Attribut identifier: identifiant
- Attribut kind: type du composant
Un contexte est un jeu de liens noms-objets dans lequel chaque nom est unique.
Le service de nommage permet :
- De lier un nom à un objet, ceci dans un contexte de nommage
- De résoudre un nom, i.e., déterminer l'objet associé au nom dans un contexte donné
Les implémentations de ce service peuvent être spécifiques à une application ou bien basées sur une variété de systèmes de nommage actuellement disponibles, ceci grâce à la généralité du modèle utilisé et car les noms sont traités dans leur forme structurelle.
Puisque les valeurs des attributs des noms ne sont ni assignées ni interprétée par ce service, les logiciels de plus haut niveau n'ont pas de contraintes en terme de politique sur l'utilisation ou la gestion de ces valeurs.
Par l'utilisation de bibliothèques de noms, la manipulation des noms est simplifiée, et les noms peuvent être indépendants de la représentation, permettant ainsi à cette représentation d'évoluer sans requérir de changements du côté client.
La localisation d'applications est facilitée par l'indépendance des noms au niveau syntaxique et par la présence de l'attribut kind.
III-B. Event Service▲
Dans CORBA, l'invocation standard d'une méthode consiste en une exécution synchrone d'une opération fournie par un objet. Or, pour la plupart des applications, un modèle de communication plus découplé entre objets est nécessaire. L'OMG a donc défini un jeu d'interfaces event service qui permet la communication asynchrone entre objets. Le modèle de l'OMG est basé sur le paradigme publish/subscribe.
Le service évènement définit deux rôles pour les objets: producteur et consommateur. Les producteurs fournissent les données évènement, les consommateurs consomment ces données. La communication de ces données entre producteurs et consommateurs se fait par les requêtes CORBA standards. Les producteurs peuvent générer des évènements sans connaitre les identités des consommateurs. De même, les consommateurs peuvent recevoir des évènements sans connaitre les identités des producteurs.
Il existe deux approches pour initier la communication d'évènements :
- Le modèle push: il permet à un producteur d'initier le transfert des données évènements vers le consommateur. Le producteur a donc l'initiative.
- Le modèle pull: il permet à un consommateur de solliciter des données évènements d'un producteur. Le consommateur a donc l'initiative.
La communication elle-même peut être soit générique soit typée:
- Communication générique: toute communication se fait au moyen d'opérations push et pull génériques qui prennent un seul paramètre englobant toutes les données évènements.
- Communication typée: toute communication se fait via des opérations définies en IDL.
Ce service définit également des objets event channel. Un event channel est un objet qui permet à de multiples producteurs de communiquer avec de multiples consommateurs, et ce de manière asynchrone. Un event channel est à la fois un producteur et un consommateur d'évènements; c'est un objet CORBA standard et donc la communication avec un event channel se fait par les requêtes CORBA standards. De plus, l'interface event channel peut être sous-typée pour supporter des facultés étendues. Les interfaces producteur et consommateur étant symétriques, on peut chainer des event channel (pour supporter par exemple divers modèles de filtrage des évènements).
Ce service fournit des capacités basiques qui peuvent être configurées ensemble de façon flexible et puissante, il supporte :
- Evènements asynchrones (découplés en producteurs et consommateurs)
- Evènements fan-in
- Evènements fan-out
- Acheminement fiable d'évènements (par des implémentations appropriées d'event channel.)
Un serveur centralisé n'est pas nécessaire, ce service ne dépend d'aucun service global. De plus, les interfaces de ce service autorisent différentes qualités de service, pour différents niveaux de fiabilité et permettent des extensions futures pour des fonctionnalités additionnelles. Elles peuvent être implémentées et utilisées dans différents environnements (qu'ils supportent le multithreading ou pas). Les producteurs,consommateurs et event channel étant des objets, on peut tirer des avantages des optimisations de performance fournies par les implémentations des ORB pour les objets locaux ou éloignés.
III-C. LifeCycle Service▲
Le service cycle de vie définit les services et les conventions nécessaires à la création, la destruction, la copie et au déplacement des objets. Puisque les environnements basés sur CORBA supportent des objets distribués, ce service autorise les clients à exécuter ces opérations sur des objets situés dans différents endroits.
Le modèle client pour la création d'objets est défini en termes d'objets factory. Un factory est un objet qui crée un autre objet. Ce n'est pas un objet spécial, il a des interfaces IDL bien définies et des implémentations dans un langage de programmation. Il n'y a pas d'interface standard pour un factory, cependant ce service définit également une interface pour un factory générique, ceci permet la définition de services de création standard. Les opérations remove, copy et move sont définies dans une interface LifeCycleObject.
- Creation: La plupart des paramètres fournis à un opérateur create seront dépendants de l'implémentation, une signature IDL standardisée et universelle pour la création n'est donc pas possible. Les signatures IDL pour la création seront définies pour différentes sortes d'objets factory mais elles seront spécifiques au type, à l'implémentation et au mécanisme de stockage persistant de l'objet devant être crée.
- Deletion: Un opérateur remove est défini pour tout objet supportant l'interface LifeCycleObject. Ce modèle pour la suppression supporte tout paradigme pour garantir l'intégrité référentielle. Le service décrit un support pour les deux paradigmes les plus communs, basés sur les relations de référence et de contenu. Un seul type de suppression est autorisé, une opération différente devra être utilisée pour archiver un objet.