Selon (Rainer Weinreich, et Johannes Sametinger) [WEI 01] un modèle de composant définit un ensemble de standards pour l’implémentation des composants, ces standard concerne l‟appellation (naming), l‟interopérabilité, la personnalisation, la composition, l‟évolution, et le déploiement. Un modèle de composant définit également des standards pour une implémentation de modèle de composant associée, et il définit aussi l’ensemble d’entités logicielles exécutables exigées pour soutenir l’exécution des composants qui se conforment au modèle.
Il existe de nombreux modèles de composants pour différents domaines d’application. Des modèles industriels (EJB (Entreprice Java Beans), CCM (CORBA Component Model), COM (Component Object Model) (voir le chapitre 2) et .NET) mettent en avant la fourniture de services extra-fonctionnels dans des « conteneurs », tels que la sécurité, tout en restant assez limités en termes de concepts d’architecture.
Ce sont en effet des modèles structurellement proches de l’implémentation. Le développeur peut ainsi se consacrer à la logique « métier » plutôt qu’au code « technique ». Certains modèles sont uniquement utilisés pour la conception d’architecture sans support d’exécution (composants UML 2.0). En fin, d’autres modèles, tels que OSGi servent à implémenter des architectures orientées services (Service Oriented Architectures ou SOA).
Les modèles plus académiques ou de recherche s’intéressent à des concepts plus avancés, notamment concernant l’analyse des architectures en termes structurels ou de comportement. Ces modèles sont généralement associé à un langage dédié pour la description des architectures des systèmes : les langages de description d’architecture (Architecture Description Languages ou ADLs).
D’autres modèles reposent sur l’extension d’un langage généraliste de programmation pour y introduire le concept de composant comme entité de première classe (tel que ArchJava avec Java), la description de l’architecture et l’implémentation des composants sont alors mêlées et spécifiées dans le même langage.
1.2.1 Éléments d’un modèle de composant
Dans la construction des systèmes à base des composants logiciels, les composants sont déployés indépendamment et sont sujet à d‟autre composition. Ceci exige des standards pour la communication et l’échange de données entre les composants des différents producteurs [WEI 01].
Une telle interopérabilité est un élément central dans un modèle de composant. Les autres éléments de base d’un modèle de composant sont les standards pour les interfaces, l‟appellation, les métadonnées, la personnalisation, la composition, l‟évolution, et le déploiement (voir le tableau ci-dessous).
Tableau 1.1 Les éléments de base d’un modèle de composant.
Un modèle de composant peut également spécialiser des standards pour décrire les dispositifs spécifiques de domaine exigés pour certaines applications. Par exemple, un système ouvert de traitement distribué exige des standards pour l’invocation à distance de méthode et la sécurité. Les modèles de composants spécifiques au domaine offrent une telle fonctionnalité spéciale dans l’implémentation de modèle de composant [WEI 01].
1.2.2 Interfaces, contrats, et langages de définition d’interface
Le but principal des composants logiciel est la réutilisation de logiciel. Les deux types principaux de réutilisation de composant logiciel sont la réutilisation de boîte blanche et la réutilisation de boîte noire.
La réutilisation de boîte Blanche signifie que la source du composant logiciel est entièrement disponible et peut être étudiée, réutilisée, adaptée, ou modifiée [WEI 01]. Le problème avec la réutilisation de boîte blanche est que les consommateurs de composant dépendent du contenu d’un composant et ils seront affectés défavorablement si les contenus changent.
La réutilisation de boîte Noir est basée sur le principe de cachement de l‟information [WEI 01], qui déclare qu’un composant doit cacher son fonctionnement interne aux autres composants. Les utilisateurs d’un composant peuvent seulement compter sur les interfaces, qui sont des descriptions ou des caractéristiques du comportement de composant.
En utilisant les interfaces, les composants peuvent être changés intérieurement, à condition qu’ils continuent à satisfaire les responsabilités définies par leurs interfaces. Les changements des interfaces sont rendus explicites et les outils, tels que les compilateurs, peuvent statiquement vérifier la compatibilité avec les composants client [WEI 01].
Une interface sert de contrat entre un composant et ses clients [WEI 01]. Elle indique les services qu’un client peut demander d’un composant; le composant doit fournir une implémentation de ces services. Les spécifications d’interface sont un élément central dans un modèle de composant.
Cet dernier définit comment le comportement d’un composant est décrit au moyen des interfaces. Un modèle de composant définit les éléments qui peuvent constituer une interface aussi bien que la signification sémantique de ces éléments. Les éléments bien connus d’une interface sont [WEI 01] : • Noms des opérations
• Leurs paramètres
• Types valides de paramètre
Les interfaces peuvent également inclure les exceptions qui peuvent être déclenchées, les pré-conditions et les post-conditions qui doivent être rencontrés en utilisant les différentes opérations, et les spécifications du comportement prévu d’un composant mettant en application l’interface. Beaucoup de modèles de composants ont un langage de définition d’interface (IDL) pour décrire les interfaces, et leurs éléments en utilisant une notation indépendante de l’implémentation [WEI 01].
Le modèle de composant peut définir un ensemble d’interfaces spécifiques qui doivent être mises en application par les composants qui se conforment à ce modèle. En général, ces interfaces seront utilisées par l’implémentation du modèle de composant pour fournir des services consacrés, prévus par les composants, tels que les transactions ou la sécurité [WEI 01].
1.2.3 l’appellation (Naming)
Le marché global exige des composants et des interfaces uniquement identifiables. Les désaccords nommés (quand deux composants différents ont le même nom) doivent être évités ou au moins devraient être fortement peu probables. Ainsi, un schéma d‟appellation (naming) standardisé est une partie nécessaire d’un modèle de composant. Les deux approches principales pour un schéma d‟appellation sont les identificateurs uniques et les espaces de nom hiérarchiques [WEI 01].
IDs-Unique : Les identificateurs uniques sont produits par les outils consacrés (par exemple, compilateurs) qui utilisent une combinaison de données spécifiques pour garantir l’unicité de chaque identificateur produit. Un exemple des identificateurs uniques sont les identificateurs uniques globales (GUIDs), qui sont utilisés par la famille COM/DCOM/COM+ de Microsoft. Un GUID est un nombre 128-bit qui combine un identificateur d’endroit (par exemple, l’adresse d’une carte Ethernet), le temps de la création, et un nombre aléatoirement généré.
Hierarchical name spaces: Les espaces de nom Hiérarchiques sont garantis pour être uniques si les noms supérieurs sont uniquement inscrits à une autorité d‟appellation globale. La plupart des modèles de composants basés sur Java utilise les espaces de nom hiérarchiques (bien qu’il n’y à aucune autorité d‟appellation globale).
1.2.4 Méta-données
Les méta-données sont des informations sur les interfaces, les composants, et leurs relations. Cette information fournit la base pour l’invocation à distance de méthode et est utilisée par les outils de composition.
Un modèle de composant doit indiquer comment les méta-données sont décrites et comment elles peuvent être obtenues. Les implémentations des modèles de composants doivent fournir les services consacrés permettant aux méta-données d’être recherchées. Il y a beaucoup de manières dont la méta donné peut être fournie, comme l’interface et les dépôts d’implémentation des systèmes basé sur CORBA, comme les bibliothèques de type dans les systèmes basé sur COM, et l’introspection dans les systèmes basé Java [WEI 01].
1.2.5 Interopérabilité
La composition des composants logiciels est possible seulement si les composants de différents fournisseurs peuvent être reliés et peuvent échanger les données. L‟Interopérabilité de composant ou les standards de liaison sont ainsi un élément central de n’importe quel modèle de composant.
Un système d’exploitation exécute des applications dans des espaces des adresses de processus séparés et isolés, mais les composants communiquant peuvent résider dans le même espace.
Si le modèle de composant permet l’implémentation des composants dans différents langages de programmation, les conventions d‟invocation doivent être standardisées au niveau binaire pour assurer l’interopérabilité de ces composants. Même si les implémentations des composants partagent le même langage, la disposition binaire des interfaces et des types de paramètre peut encore être différente [WEI 01].
Un modèle de composant peut également supporter la communication des composants à travers des processus sur le même ordinateur ou sur le réseau. L’interopérabilité à distance est basée sur des appels à distance de méthode RMC (Remote Method Calls) ; une prolongation du concept d’appelle de procédure à distance RPC (Remote Procedure Calls) introduit par Birell et Nelson (En 1984).
Un RMC se compose d’un client appelant une méthode d’un serveur à distance. Au client, un RMC ressemble à l’invocation local de méthode parce que le client appelle réellement une méthode d’objet local (proxy) qui offre la même interface que le proxy de composant à distance.
Le proxy transforme l’invocation de méthode (y compris les paramètres) en format linéaire de réseau (un processus appelé marshalling) et envoie les données à un objet correspondant « stub » sur la machine à distance. Le stub reçoit les données, reconstruit l’invocation (unmarshalling), et expédie la demande d’invocation localement à l’instance de composant pour lequel on l’a prévu. Le proxy et le stub s’appellent stub/skeleton dans les systèmes basés sur CORBA.
Un modèle de composant supporte les composants distribués en définissant les représentations de données communes et la sémantique d’invocation. Les modèles de composants standardisent souvent également les protocoles de réseau utilisés pour la communication entre les différents composants basés sur le même modèle de composant.
Parmi les exemples des spécifications à distance de méthode en trouve le Simple Object Access Protocol (SOAP) pour Windows, les plateformes .NET (msdn.microsojt.com/soap), l’invocation à distance de méthode (RMI) pour les plateformes basées sur Java (java.sun.com/products/jdk/rmi), et le protocole Internet Inter-Orb Protocol (HOP) pour les systèmes basé sur CORBA (www.omg.org).
Un problème d’interopérabilité se produit quand les développeurs essayent de relier ensemble des différents modèles de composants qui supportent des spécifications d‟appelle de méthode à distance incompatibles [WEI 01]. Un modèle de composant devrait explicitement définir comment jeter un pont sur la communication entre les implémentations de différents modèles de composants. Par exemple, la Spécification CORBA (OMG, 1999) décrit comment accéder à des objets COM de Microsoft à travers les environnements CORBA et vice versa.
1.2.6 Personnalisation
Les standards d’interopérabilité et les méta-données concernant les composants et les interfaces fournissent la base pour la personnalisation du composant et la composition. Rainer Weinreich, et Johannes Sametinger [WEI 01] définissent la personnalisation de composant comme la capacité d’un consommateur d’adapter un composant avant son installation ou son utilisation.
Puisque les composants sont généralement traités en mode de boîte noir, indiquant le moins possible de leur implémentation, ils peuvent seulement être adaptés aux besoins du client en utilisant les interfaces de personnalisation clairement définies.
Une interface de personnalisation permet à des outils de personnalisation et de déploiement de modifier les propriétés simples, ou même le comportement complexe, en fournissant des instances d’autres composants comme paramètres aux fonctions de personnalisation [WEI 01]. Les outils de personnalisation peuvent se renseigner sur les interfaces de personnalisation des composants en utilisant les services de méta-données.
1.2.7 Composition
La composition de composants est la combinaison de deux composants logiciels ou plus qui rapporte un nouveau comportement de composant. Selon Rainer Weinreich, et Johannes Sametinger
[WEI 01] un standard de composition de composant supporte la création d’une plus grande structure en reliant les composants et aussi l’insertion ou la substitution des composants dans une structure existante.
Une telle structure est une infrastructure de composant, parfois appelée un cadre de composant (component Framework). Les composants dans une infrastructure de composant agissent l’un sur l’autre, typiquement, par des invocations de méthodes. Les deux types de base d’interactions des composants sont client/server et publish/subscribe [WEI 01].
Les composants peuvent agir en tant que clients, demandant l’information, ou invoquant les méthodes des autres composants. Un composant peut s’enregistrer avec un autre composant ou un autre service employé, et recevoir des notifications des événements prédéfinis. Le modèle de composant doit définir comment concevoir les interfaces pour supporter une telle composition.
Plusieurs approches pour la composition de composant à différents niveaux d’abstraction ont été identifiées [WEI 01]. Les composants peuvent être connectés en utilisant des langages de programmation polyvalents, des langues de script ou de colle (glue), des outils visuels de programmation ou de composition, ou des infrastructures de composants.
L’inconvénient des langages et des outils de composition est que le code de colle doit être écrit ou spécifié graphiquement du début. La réutilisation maximum est réalisée avec les infrastructures de composants conçues pour un domaine spécifique où l’interaction entre les instances des composants est prédéfinie.
La composition avec une infrastructure de composant est une question d’insérer et de substituer des composants conforment aux standards d’interaction définies par l’infrastructure de composant [WEI 01]. Les standards d’interaction indiquent quelles interfaces des composants participants doivent mettre en application et les règles régissant l’interaction de composant.
1.2.8 Support d’évolution
Les systèmes basés composant exigent un support pour l’évolution de système. Les Composants agissant en tant qu’un serveur pour les autres composants doivent être remplacés par des nouvelles versions fournissant une nouvelle fonctionnalité ou une fonctionnalité améliorée [WEI 01].
Une nouvelle version peut non seulement avoir une implémentation différente mais peut fournir des interfaces modifiées ou nouvelles. Les clients existants de tels composants devraient, idéalement, ne pas être affectés ou devraient être affectés le moins possible [WEI 01].
En outre, les vieilles et nouvelles versions d’un composant pourraient devoir co-exister dans le même système. Les règles et les standards pour l’évolution de composant et le versioning sont ainsi une partie particulièrement importante d’un modèle de composant.
1.2.9 Empaquetage et déploiement
Les standards des modèles de composants largement admises, comme les connexions d’Internet de haut-largeur de bande, changeront le déploiement de ce qui s’appelle maintenant le logiciel shrink-wrapped [WEI 01]. Il deviendra inutile d’empaqueter les grands systèmes logiciels et leur documentation pour les vendre.
En plus, pour les implémentations des modèles de composants bien définies, seulement les petits composants seront nécessaires pour construire des applications. Les connexions rapides d’Internet permettront aux consommateurs des composants de télécharger facilement les composants emballés avec la documentation pour développer des systèmes logiciels complets [WEI 01].
Un modèle de composant doit décrire comment les composants sont empaquetés, ainsi, ils peuvent être indépendamment déployés [WEI 01]. Un composant est déployé, c.-à-d., est installé et configuré, dans une infrastructure de composant. Le composant doit être empaqueté avec tout ce que le producteur de composant prévoit qu‟il n’existera pas dans l’infrastructure des composants.
Ceci peut inclure le code de programme, des données de configuration, d’autres composants, et des ressources additionnelles. Une description de déploiement fournit des informations sur le contenu d’un paquet (ou d’un certain nombre de paquets relatifs) et d’autres informations qui sont nécessaires pour la procédure de déploiement. Cette description est utilisée pour installer et configurer un composant correctement.
Le standard de déploiement indique la structure et la sémantique pour les descriptions de déploiement et elle peut définir le format des paquets. De plus, le modèle de composant peut définir des procédures pour le déploiement, y compris l’enregistrement de composant.
Page suivante : 1.3 Implémentations et services des modèles de composants
Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES