Le modèle de programmation CORBA, liens avec l’OS

La norme CORBA s’est, au fil des années, enrichie de très nombreux aspects, comme les communications par événements, ou les mécanismes transactionnels. Nous ne les aborde- rons pas ici et nous nous concentrerons sur le cœur de la norme : les invocations de méthode à distance. Cet aspect utilise un modèle de programmation extrêmement simple, centré autour de la notion de référence d’objet, et de requête : pour utiliser les services d’un objet CORBA, une application cliente doit tout d’abord obtenir une référence sur cet objet, c’est-à- dire une structure opaque pour l’utilisateur qui permettra au bus à objets de contacter l’objet CORBA considéré. Une fois cette référence obtenue, l’application cliente peut l’utiliser pour envoyer des requêtes de service à l’objet CORBA auquel elle correspond. La force de CORBA tient au fait qu’une référence CORBA se manipule syntaxiquement exactement comme une référence locale. Il n’y a pas pour le programmeur de différence entre une invocation locale de méthode et l’envoi d’une requête distante.

Une implémentation CORBA se doit de réaliser ce modèle de programmation en utilisant les services des couches exécutives qui la supportent (pour nous, la couche POSIX). Comme nous l’avons expliqué dans la section 1.2.4 page 15, la norme CORBA n’impose que très peu de contraintes d’implémentation. L’architecture d’un bus à objets CORBA telle qu’elle est prévue par la norme est représentée sur la figure 5.2 page suivante. Le lientet leservant sont des objets du langage d’implémentation considéré. Le cercle marquéIOR(Interoperable Object Reference) dans le lientreprésente la référence CORBA que possède le client sur l’objet CORBA réalisé par leservant. Le lien référence/servant n’est ni univoque ni perma- nent : le servant peut répondre aux requêtes adressées à plusieurs références distinctes. De même, le servant associé à une référence donnée peut changer de manière dynamique, voire même lors de chaque nouvelle invocation1_.

Une invocation de méthode sur une référence CORBA transite par différents modules du bus à objets : la souche réalise la mise à plat (marshalling) de la requête pour son envoi par le réseau. La souche est générée de manière automatique par un compilateur particulier, un compilateur IDL, à partir d’une description de haut niveau de l’interface de l’objet CORBA. Le moteur de l’ORB (réalisé le plus souvent sous forme d’une bibliothèque partagée) se charge ensuite d’utiliser les primitives du système d’exploitation pour faire parvenir la requête mise

1_{On comprend ici que la notion d’« objet CORBA » renvoie à l’abstraction perçue par l’application cliente qui en}

invoque les méthodes, mais ne peut être associée ni à un processus système (un processus peut répondre à plusieurs IOR), ni à un objet du langage d’implémentation qui jouerait en permanence le rôle de cet objet. La notion d’« objet CORBA » est un élément du modèle de programmation de la norme CORBA qui ne peut être relié de manière bijective à aucun élément concret de l’implémentation.

serveur−>method(42) IOR 0 1 moteur de l’ORB système d’exploitation skeleton object adapter moteur de l’ORB système d’exploitation requête distante invocation locale parcours de la requête

client servant application

middleware lowerware noeud A stub (souche) stub (souche) noeud B noeud B

FIG. 5.2 :Vue d’ensemble (simplifiée) d’un bus à objets CORBA

à plat au nœud destinataire (ici le nœud B). Au nœud B, le même processus inversé se répète. L’object adapter (ou POA pour Portable Object Adapter) est chargé de sélectionner le servant auquel la requête doit être délivrée. Le skeleton (ou « scion ») réalise l’invocation effective sur le servant.

Une question d’implémentation essentielle a trait à la manière dont les brins d’exécution fournis par le système d’exploitation sont utilisés dans l’ORB pour réaliser les différentes étapes du traitement des requêtes. La norme CORBA est quasiment muette sur ce point, en ne distinguant que deux modes de concurrence : sérialisé (à tout moment, une seule requête au plus est active dans l’application), et contrôlé par l’ORB. Chaque implémentation est libre d’interpréter ce deuxième mode à sa guise, aucune contrainte n’étant imposée. La plupart des implémentations proposent pour ce deuxième cas un mode de concurrence basé sur une réserve de brins, dont le principe est représenté par un réseau de Petri sur la figure 5.3.

"thread pool" requêtes entrantes en attente requêtes sortantes en attente application ORB système

d'exploitation brins en réserve

requêtes en traitement E S M D A e s {R4;R5} {R2} {R1} {R3} m d a t T

FIG. 5.3 :Modèle générique d’un ORB à réserve de brins (thread pool)

Ce mode de concurrence consiste à créer un nombre pré–fixé de brins d’exécution à l’initialisation du bus à objet pour former une réserve de brins, qui sera utilisée pour traiter

les requêtes (la place T sur la figure 5.3). Lorsqu’une requête arrive (transition e sur la figure 5.3 ; les requêtes R4 et R5 dans la place E viennent d’arriver), et si un brin est disponible dans la réserve, alors la requête est confiée au brin en question, qui prend en charge son exécution. Si aucun brin n’est disponible lors de la réception d’une requête, celle-ci est mise en attente, jusqu’à ce qu’un brin de réserve soit de nouveau libéré. Une fois associée à un brin de la réserve, la requête traverse l’ORB vers le haut (place M de notre figure, pour « montée »), jusqu’à atteindre l’application (place A, cas de la requêteR3) où elle exécute le code prévu par le développeur utilisateur de l’ORB. Après traitement, la requête, toujours « portée » par le brin de la réserve, redescend dans l’ORB (place D sur notre figure, pour « descente »), le brin de réserve est alors libéré, et la réponse à la requête envoyée (place S, transitions t et s).

Notons que ce modèle est très générique, les implémentations réelles pouvant présenter des variantes par rapport à ce cas général. Ainsi les places E et S représentent des étapes où les requêtes sont dans l’ORB mais sont prises en charge par d’autres brins que ceux de la réserve. Or ces places peuvent ne pas exister dans certains ORB, les opérations de réception d’une requête ou d’envoi d’une réponse étant directement effectuées par un brin de la réserve. C’est par exemple le cas dans l’ORB TAO [Schmidt & Cleeland 1999], où ni la place E, ni la place S ne sont présentes. Le bus ORBACUSlui ne contient que la place E.