Les composants

La norme CCM est la seule à avoir un modèle abstrait de composant, avec une représentation claire et précise des relations entre le composant et son environnement (avec notamment la notion des services que fournit ou requiert le composant). Dans la norme EJB, un composant correspond à un Bean, pour lequel seuls les services fournis sont déclarés sous un regroupement de méthodes ; les services requis d'un EJB ne sont pas dénis aussi clairement que pour un composant CCM. L'architecture .NET de Microsoft est bien plus oue quant à la notion de composant : aucune norme n'existe concernant la dénition d'un composant .NET ; d'ailleurs, la littérature technique parle plutôt d'Objet Distant (Remote Object), même si cet objet peut être considéré par l'environnement d'exécution comme du code binaire.

Les spécications décrivent plusieurs types de composants. Généralement, le type de composant résulte d'une combinaison de deux axes : persistance du composant et son état  avec ou sans état. Avec Etat indique que l'état du composant est mémorisé 8_{International Organization for Standardization, Internatiuonal Electronical Commission, Joint} Technical Committee.

entre deux appels de méthodes. La Persistance rend compte que le composant est sauvegardé sur disque pour pouvoir le récupérer après un redémarrage du serveur d'application ; la persistance est en général liée à la notion de Clé primaire, qui est l'identité du composant : elle est obligatoire si le client veut récupérer un composant spécique, et n'a d'utilité que si le composant est persistant.

Les sections suivantes portent sur la spécication des composants et leurs dié- rents types. Pour qu'un composant soit de tel ou tel type, sa classe d'implantation doit dériver d'une classe abstraite décrivant le type de composant recherché.

Les sections 2.3.3 page 23 et 2.3.4 page 30 se consacreront à l'architecture d'accueil et au déploiement des composants (plus précisément à leur descripteur de déploie- ment). 2.3.2.1 Composant CCM emits ...; publishes ...; consumes ...; provides ...; ... }; réceptacle facette component ... { fourni requis attribute ...; attributs uses multiple ...; uses ...;

source d’événements puit d’événements

Fig. 2.1: Un composant Corba

Un composant Corba est communément représenté selon la gure 2.1. Il est décrit en IDL3 (Interface Denition Language pour la version 3 de Corba), et com- porte plusieurs types de ports que l'on peut interconnecter entre eux :

fourni requis

synchrone (interface)

facette réceptacle

ensemble de méthodes implantées

par le composant. ensemble de méthodes requisespar le composant. Deux types existent : les récep- tacles simples sont connectés à une seule référence de facette, tandis que les réceptacles mul- tiples peuvent être connectés à plusieurs références de facette. asynchrone

(eventtype)

puits d'événement source d'événement

consomme des événements. produit des événements.

Deux types existent : diusion un vers un ou un vers n.

Chaque port fourni du composant correspond à l'implantation d'une interface, et a sa propre référence (référence de facette/de puits). Il est de plus possible d'accéder aux attributs du composant pour le congurer.

Trois interfaces (facettes) sont implantées par tous les composants, et permettent d'accéder aux diérents ports proposés par le composant :

 Components::Navigation permet d'accéder aux facettes ;

 Components::Receptacles permet de (dé)connecter les composants entre eux de façon dynamique ;

 Components::Events permet d'accéder aux sources et puits d'événements (avec notamment des opérations de (dés)abonnement à une source d'événements). Quatre catégories de composants existent, selon que l'on considère le mode d'accès (modèle d'utilisation Corba), et l'existence d'une clé primaire :

Modèle d'usage Persistance Avec Etat Clé primaire Catégorie

de composant

Sans état _Non Non _Non Service

Conversationnel Oui Session

Durable Oui Oui Non_Oui Processus_Entité

Les modèles d'usage sont des patrons d'interactions dénis par la norme ; Du- rable veut dire que le composant est persistant. La diérence entre les catégories Processus et Entité est que la persistance de la première est transparente pour le client.

Le type du composant est décrit dans le descripteur de déploiement correspon- dant. La mise en ÷uvre des composants se fait dans n'importe quel langage de pro- grammation, pourvu que la projection de IDL3 vers celui-ci soit dénie.

2.3.2.2 Composant EJB

Les composants de cette section sont appelés Enterprise Java Beans ou plus communément Beans. Chaque composant est en fait une classe Java proposant un ensemble de méthodes. Ainsi, contrairement à CCM, le composant EJB n'a pas de notion de ports ou d'interfaces asynchrones (événements). Les interfaces requises ne sont pas déclarées explicitement, mais si la classe Java fait appel à un autre com- posant EJB, elle doit importer la spécication des interfaces d'accès à ce composant (par le mot-clé import  c'est-à-dire que la classe Java utilise les méthodes d'autres classes, ce que l'on pourrait considérer à la rigueur comme une déclaration d'interface requise).

La spécication des EJB permet d'avoir au total quatre catégories de composants. Ils sont regroupés en trois types :

Entity Bean (Entité). Composant EJB utilisé essentiellement pour l'accès à une base de données. Le Bean Entité peut être utilisé par plusieurs clients à la fois (mais il n'y a pas d'appels en parallèle : le conteneur doit les mettre en séquence). Ce bean possède une identité (ou clé) qui lui ore des possibilités de persistance ;

Session Bean (Session). Composant EJB s'exécutant à la demande d'un unique client (qui ouvre une session avec le composant). Le Bean Session peut utiliser les services de Transaction du serveur EJB, mais n'est pas persistant. Il existe deux types de ce Bean :

Statefull (avec état), pour lequel un seul client à la fois peut avoir une session ouverte ;

Stateless (sans état), pour lequel plusieurs clients peuvent se connecter, mais de façon séquentielle.

Message-Driven Bean. Composant EJB fonctionnant comme consommateur d'évé- nements asynchrones. Il peut utiliser les services de Transaction, et n'est pas persistant. Il ne possède pas d'état. Le Bean Orienté-Messages est le seul à avoir un mode d'appel diérent des autres composants ; ce mode d'appel sera détaillé dans la section 2.3.310_.

2.3.2.3 Composant .NET

Les composants .NET sont appelés Objets Distants (Remote Objects). Ils ont plu- sieurs interfaces spéciques, et peuvent être décrits dans n'importe quel langage. Un mécanisme d'introspection permet de naviguer parmi les services proposés par le com- posant (ce mécanisme est mis en ÷uvre par la bibliothèque System.Reflection de C]). Trois types de composants existent, suivant le mode d'appel et les cas avec/sans état :

Client Activated Objects. Ce composant est activé à l'initiative du client (une seule instance par client). Le composant a un état, et un contexte gérés par l'environnement d'exécution. Le cycle de vie du composant est géré par un système de bail (lease) ;

Server Activated Object. Ce composant est activé à l'initiative du serveur. Une instance peut être partagée entre plusieurs clients. Contrairement au Client Activated Object, il n'y a pas de contexte lié au composant.

Deux types existent :

Single Call, où le composant n'a pas d'état, et ne sert qu'à une seule requête ; Singleton, où le composant a un état. Comme plusieurs clients accèdent à la même instance, cet état est partagé entre les clients ; ce composant est donc utile pour le partage de données entre clients.

Contrairement aux composants CCM et EJB, il n'y a pas de notion de composant persistant. Il n'est pas possible d'avoir une persistance gérée par l'environnement (à la EJB ou CCM) ; mais il est possible, par du code adéquat11_{, de retrouver cette}

spécicité.