Assemblage de composants par contrats. État de l'art et de la standardisation

Transcription

1 Assemblage de composants par contrats État de l'art et de la standardisation Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable Date : Juin 2002 * : Les partenaires du projet ACCORD sont CNAM, EDF R&D, ENST, ENST-Bretagne, France Telecom R&D, INRIA, LIFL et Softeam. Le projet est conjointement financé par les partenaires et par le RNTL (Réseau National des Techniques Logicielles). Projet ACCORD 1/29

2 Sommaire 1 Introduction Concepts Composant Interface et service Spécification et contrat Assemblage et connecteur Granularité Structure d accueil Différentes catégories de composants Contrat Assemblage Langages de description d architectures Langages de coordination Standards Outils de spécification/modèles Le modèle de composant d UML ODP Structures d accueil EJB CCM NET Conclusion Annexe Bibliographie Liens Internet Projet ACCORD 2/29

3 1 Introduction L'origine de l'utilisation de composants logiciels ne fait pas l'unanimité. Certains, comme Ivar Jacobson dans la préface de [HC01], pensent que l'utilisation de composants pour construire des systèmes logiciels n'est pas une idée nouvelle et que nous avons toujours eu affaire à des composants logiciels de différentes sortes. D'autres, comme les auteurs de [WHS02], situent l'utilisation des composants à la fin des années 70 comme une réponse à la deuxième crise du logiciel provoquée par l'introduction à grande échelle des micro-processeurs. Il a fallu alors produire des logiciels de meilleure qualité et de façon plus rapide et moins coûteuse. À cette époque, une nouvelle discipline du génie logiciel émerge : le CBSE (Component-Based Software Engineering). Elle est portée notamment par un centre de recherche créé par le gouvernement fédéral américain et exclusivement dédié au génie logiciel : le SEI (Software Engineering Institute). Il est indéniable que la tendance vers le développement à base de composants s'est imposée depuis une quinzaine d'années, au moins en ce qui concerne les composants techniques disponibles commercialement dans les domaines tels que la gestion de l'information (systèmes de gestion de bases de données, systèmes géographiques, systèmes de gestion de données techniques) et les intergiciels (moniteurs transactionnels, systèmes répartis à objets, messageries inter-applications). Les bénéfices attendus de l'utilisation de composants logiciels sont a priori clairs et trouvent une analogie souvent utilisée dans l'industrie automobile. Il s'agit essentiellement de réduire les coûts de production des logiciels, mais aussi d'en réduire les coûts de maintenance et d'en favoriser la réutilisation. Cette démarche est résumée par Fred Brooks [WHS02], de la société IBM : "buy before build" et "reuse before buy". Néanmoins, cette démarche n'est pas toujours facile à suivre dans la pratique. En effet, l'assemblage des "pièces" logicielles pour constituer une application efficace et facile à utiliser nécessite un travail qui peut s'avérer fastidieux car il met en cause deux parties, dans ce contexte, dissociées : les producteurs et les consommateurs des composants logiciels. De plus, les composants, et plus particulièrement les composants commerciaux, sont souvent complexes (même les experts n'en connaissent pas toutes les capacités fonctionnelles) et instables (ajout fréquent de nouvelles fonctions au composant pour qu'il reste compétitif par rapport à la concurrence). Par ailleurs, selon [WHS02], il existe également un écart indéniable entre théorie et pratique dans les méthodes de conception de systèmes fondés sur les composants. En effet, la plupart des théories s'appuient sur des techniques de spécification de composants logiciels alors que, la plupart du temps, les composants existent déjà. Il semble donc apparaître une contradiction entre d une part une conception architecturale qui permettrait de déterminer précisément comment le système est partitionné en composants, quelles fonctions sont offertes par chaque composant et comment les composants coordonnent leurs activités, et d autre part l'utilisation de composants préexistants qui induirait une perte de contrôle sur ces décisions de conception fondamentales. En réalité, deux classes de problèmes de conception doivent co-exister : les décisions de sélection d'un composant préexistant et les décisions d'optimisation de Projet ACCORD 3/29

4 l'architecture lorsqu'il est possible d'intervenir sur les interfaces des composants. C'est l'articulation entre ces deux points de vue qu'il faut bien maîtriser. Le présent document a été réalisé dans le cadre du projet ACCORD (Assemblage de Composants par Contrats en environnement Ouvert et Réparti). Il est constitué de deux parties correspondant respectivement à un état de l'art et à un état de la standardisation dans le domaine de l'assemblage de composants logiciels par contrats. La première partie présente les principaux concepts manipulés dans le cadre du projet ACCORD - composant, contrat et assemblage successivement dans cet ordre même s'il est, en réalité, difficile de dissocier ces trois notions. La deuxième partie décrit la prise en compte des concepts présentés dans la première partie dans les standards de spécification et de structures d accueil pour composants et assemblages de composants. Ces deux aspects sont importants pour le projet ACCORD qui s intéresse particulièrement aux aspects de spécification mais vise également à faciliter la mise en œuvre opérationnelle sur des plates-formes EJB et CCM. La conclusion contient une synthèse ainsi que les choix de concepts et de standards effectués dans le projet ACCORD. 2 Concepts Les concepts introduits dans cette partie sont loin de posséder une définition consensuelle. Nous présentons donc une liste d idées générales qui sont couramment évoquées dans le contexte des composants logiciels. Nous insisterons en particulier sur les notions d assemblage et de contrat qui sont indissociables de celle de composant. Nous avons souhaité cette partie objective en réservant à la conclusion de proposer les interprétations retenues dans le cadre du projet ACCORD. 2.1 Composant La notion de composant logiciel n a pas encore reçu une définition aussi complète et communément acceptée que celle d objet. Cependant, la communauté scientifique s accorde sur un certain nombre de caractéristiques propres à l approche composant. De manière générale, un composant est un logiciel qui rend un service au moyen d'une ou de plusieurs interfaces externes. Un composant a vocation à être intégré dans plusieurs application. Pour cela, il doit être suffisamment autonome et comporter toutes les informations lui permettant d être assemblé par un tiers, éventuellement avec d autres composants. Un composant réutilisable (composant sur étagère ou COTS) est un code compilé ou binaire et doit renfermer toutes les informations nécessaires à son déploiement dans un environnement donné Interface et service Le service offert par un composant est défini au travers de plusieurs interfaces. Ces interfaces externes sont associées aux différentes facettes de l'activité du composant (interface métier, interface de configuration, de maintenance,...). Par ailleurs, un composant s appuie sur d autres composants pour fonctionner. À cette fin, un composant définit des interfaces requises (les interfaces dont il a besoin dans le cadre de son exécution). Ces interfaces doivent être connectées à des interfaces offertes par d'autres composants Spécification et contrat Dans l optique de réutilisation et d'intégration d un composant logiciel, il est indispensable de comprendre très précisément ce que fait ce composant. Ceci implique d associer au composant des spécifications précises tant fonctionnelles que non- Projet ACCORD 4/29

5 fonctionnelles. Ces spécifications décrivent les services offerts par le composant, mais aussi ceux dont il a besoin pour fonctionner. Elles représentent l ensemble des contraintes que le composant impose à ses utilisateurs, ainsi que celles venant de son environnement qu il s impose de respecter. L'environnement possède des propriétés qui ont une influence sur le fonctionnement du composant. Il peut s agir de propriétés temporelles (vitesse d'exécution), des propriétés sur les modes de panne ou sur les attaques possibles en termes de sécurité. Les spécifications doivent également porter sur les comportements du composant associés à ces traitements non-fonctionnels. Les contraintes d'environnement comportent également le type de plate-forme (matériel, système d'exploitation, architecture réseau, conteneur) dans laquelle le composant doit s'exécuter. Ces spécifications sont, contrairement aux types abstraits algébriques, rarement complètes. Le terme de contrat est de plus en plus utilisé pour décrire les propriétés nécessaires au bon fonctionnement du composant. Une classification de niveaux de contrats est présentée en 2.2. Chaque composant est ainsi spécifié par deux types de contrat : un unique contrat d utilisation qui précise les services qu il offre et qu il requiert ; des contrats d implantation qui décrivent les contraintes et les propriétés requises de l environnement. Les contrats d implantation doivent naturellement satisfaire au contrat d utilisation. En résumé, l existence de spécifications précises permet à une nouvelle application d être construite rapidement par assemblage de composants préexistants mais également de faire face aux évolutions ou aux extensions d une application existante par le remplacement de certains composants Assemblage et connecteur Un composant logiciel est une unité de réutilisation et d'intégration. Il est donc conçu pour fonctionner en coopération avec d autres composants. Pour cela, il faut réaliser l étape de composition ou d assemblage d un ensemble de composants caractérisés essentiellement par leurs interfaces offertes et leurs interfaces requises. La notion de connecteur recouvre l ensemble des moyens nécessaires pour assurer l interaction entre les composants par la connexion des interfaces requises et offertes. Ces moyens peuvent être vus à deux niveaux. La spécification des propriétés des interfaces requises et des interfaces offertes peut être utilisée pour définir les connecteurs sur un plan conceptuel. Dans ce premier cadre, un connecteur est vu comme la spécification d un mode de communication. Dans un second temps, si nécessaire, le connecteur est implanté par un ensemble de moyens logiciels et matériels réels et assure concrètement l'adaptation des propriétés requises aux propriétés offertes (par exemple pour adapter le typage de certains paramètres, pour réaliser un protocole de communication). En termes de séparation des préoccupations, il est souhaitable de ne pas faire apparaître les traitements associés aux fonctions des connecteurs dans les composants mais d en faire des entités bien distinctes Granularité La granularité des entités logicielles concerne leur taille et plus encore leur mode de gestion plus ou moins indépendante. De par son objectif de réutilisation, un composant doit être considéré dès la phase d analyse. L approche objet privilégie des entités logicielles de grain moyen (comme des objets habituels ou des fichiers) ou de grain fin (comme des variables). Bien qu il n existe pas de règles très strictes concernant la granularité d un composant, il est préférable de considérer qu un composant est plutôt Projet ACCORD 5/29

6 une entité logicielle de grain gros. Un composant possède plutôt un volume de code significatif mais surtout il doit pouvoir être déployé et géré indépendamment des autres composants. Ceci amène à lui associer des caractéristiques en propre (caractéristiques de désignation, de protection, de gestion de ressources ) alors que dans les approches objet de grain fin ou de grain moyen ces caractéristiques sont peu ou prou partagées par des ensembles ou grappes d objets Structure d accueil Une fois construits et assemblés, les composants sont déployés. La structure d accueil correspond à l environnement système dans lequel les composants sont installés, instanciés et activés. Il peut s agir d un système d exploitation «généraliste», ou d un environnement dédié à un certain modèle de composant. Dans ce dernier cas, l environnement est appelé généralement structure d accueil. Nous en verrons dans la partie 3.2 quelques exemples standardisés comme EJB ( Enterprise Java Beans ), CCM ( CORBA Component Model ) et.net Différentes catégories de composants Au plan conceptuel, on peut différencier les composants boîte noire et les composants boîte blanche. Les composants boîte blanche sont fournis en code source et sont donc modifiables avant intégration. Les composants boîte noire, à l inverse, sont des codes compilés ou binaires ; leurs fonctionnalités ne sont accessibles qu au moyen de leurs interfaces publiques et ils ne peuvent être modifiés directement. Pour étendre ou redéfinir certaines de leurs fonctionnalités, il est nécessaire d utiliser des adaptateurs. Une solution intermédiaire entre les deux précédentes consiste à considérer des composants boîte grise. Dans ce cas, un sous-ensemble des modalités de fonctionnement d un composant serait ouvert à la modification au moyen d un ensemble de mécanismes prédéfinis. Les composants sur étagères (COTS commercial off the shelf component, Open Market Component) sont des produits qu il est possible d acquérir indépendamment d un service support, d intégration ou autre. Ce sont des composants binaires déployables qui sont basés sur une architecture standard suffisamment répandue pour correspondre à un marché significatif. Les composants peuvent également être considérés plutôt comme des services c est-àdire réutilisables sous la forme installée du composant. Dans ce cas, un environnement d exécution est offert par le fournisseur du composant sur l un de ses serveurs. Dans les deux cas précédents, toute approche composant se doit d offrir un moyen de rechercher et de trouver en ligne des composants sur étagères ou déployés qui conviennent pour construire une application. Un exemple de standard récent pour traiter ce problème est donné par le protocole et la base de données distribuées UDDI des Web Services. Enfin, les composants métier se distinguent des composants non-métier ou système. Les premiers sont développés dans le cadre d une profession ou d une entreprise et satisfont des besoins liés aux activités d un utilisateur. Les seconds sont des composants développés pour résoudre un problème correspondant à un besoin rencontré par un ensemble d applications de métiers différents (composants de communication, de sécurité, de persistance transactionnelle, ). 2.2 Contrat La spécification d un composant se traduit par un ensemble de contrats qui définissent le plus précisément possible ses exigences et ses aptitudes. Nous présentons ici une classification des niveaux de contrat. Projet ACCORD 6/29

7 Les composants promettent d encapsuler des parties de système sans demander à leurs utilisateurs de connaître les détails de leur réalisation. Toutefois, ceci n est possible que si le niveau de description de ce qu est le composant - de ce qu il fait et sous quelles hypothèses - est suffisant. Cette description est, de plus en plus fréquemment, appelé le contrat d utilisation du composant. Lorsqu un composant est assemblé avec d autres, leurs contrats d utilisation sont confrontés, négociés et parfois adaptés pour satisfaire aux différentes hypothèses et contraintes. Cette phase peut être réalisée automatiquement par un compilateur ou manuellement par les concepteurs du système en fonction de la richesse du contrat. Un contrat peut en effet se décomposer en quatre niveaux qui dans la pratique se traduisent par des règles d assemblages de moins en moins automatisables. 1) Le premier niveau assure que l assemblage structurel se déroulera bien. 2) Le deuxième décrit pour chaque service offert les conditions d utilisation et le résultat attendu. 3) Le troisième garantit qu en cas d utilisation concurrente le fonctionnement sera correct. 4) Le quatrième niveau précise les conditions quantitatives d utilisation du composant en termes de qualité de service. Les trois premiers niveaux caractérisent le comportement qualitatif du composant. La plupart des spécifications de composant actuelles (EJB, CCM,.NET) reposent uniquement sur le premier niveau qui assure le typage correct des interfaces offertes et requises (même nom de service, même nombre d arguments, mêmes types, mêmes exceptions, etc.) Certains langages, comme Eiffel, permettent une description des services au niveau deux, en intégrant dans leur syntaxe des préconditions et des postconditions qui décrivent les services. Ces éléments de contrat sont utilisés défensivement à l exécution pour lever des exceptions en cas de rupture de contrat et non pas préventivement par des outils de preuves ou de compilation sophistiqués. Sous réserve d atomicité d exécution des services, le contrat de niveau deux suffit pour garantir le bon fonctionnement du composant. Toutefois, certaines implantations d objet ou de composant incluent du parallélisme et les hypothèses d atomicité ne sont pas toujours garanties. C est le rôle du niveau trois des contrats de décrire les hypothèses de concurrence acceptées par les composants. Enfin, le niveau quatre précise quantitativement le fonctionnement du composant. Le contrat spécifié doit, lors de l assemblage, être confronté aux autres contrats d utilisation pour être accepté tel quel, adapté lors de l assemblage ou mieux encore, négocié et adapté dynamiquement en cours de fonctionnement du système. Ce dernier point s applique au niveau quatre pour de l adaptation de qualité de service, mais aussi aux trois niveaux qualitatifs lors des évolutions du système. Finalement, la même notion de contrat permet de caractériser les contraintes d assemblages des composants (contrat d utilisation ou d usage) mais aussi les dépendances vis-à-vis du système pour la mise en œuvre (contrat d implantation). 2.3 Assemblage Un composant est destiné à être relié avec d autres ; l opération consistant à définir ces relations est l assemblage. Les deux principales approches actuelles sont les langages de description d architectures et les langages de coordination Langages de description d architectures La définition d une architecture logicielle est une étape importante dans la conception d un logiciel. Elle permet d avoir un niveau d abstraction élevé et de disposer de modèles qui s approchent du modèle mental du développeur. Une architecture logicielle Projet ACCORD 7/29

8 décrit l ensemble des composants qui le composent et donne les règles de leur assemblage. Elle permet la conception d applications en se détachant de détails techniques propres à l environnement et en respectant les conditions fixées par les futurs utilisateurs. Elle correspond à l établissement du plan de construction du logiciel. En maîtrisant l architecture conceptuelle, il est alors plus facile de gérer ses éventuelles évolutions. En effet la modification d un plan est plus simple que la modification d un système réalisé. Afin de répondre à ce besoin de description d architecture, de nombreux travaux ont été menés par la communauté scientifique dès le début des années 90. Ces travaux concernent la définition de langages de description d architecture (Architecture Description Languages ou ADL) [SG96] [GP95]. Cette partie a pour objectif de présenter un rapide survol des formalismes proposés. Une version plus détaillée est disponible dans [SD02]. Dans un premier temps, nous définissons les concepts généraux des ADL. Dans un second temps, nous faisons un tour d horizon des différentes propositions Composant, connecteur et configuration Les concepts que nous retrouvons dans les différents langages de description d architecture sont au nombre de trois. Le premier est le composant, le deuxième le connecteur, et le dernier la configuration ou encore la topologie. Ils ont été définis par des spécialistes de l architecture logicielle. Un composant Un composant est une unité de calcul ou de stockage à laquelle est associée une unité d implantation. Il peut être simple ou composé ; on parle alors dans ce dernier cas de composite. Sa taille peut aller de la fonction mathématique à une application complète. Deux parties définissent un composant. Une première partie, dite externe, comprend la description des interfaces fournies et requises par le composant. Elle définit les interactions du composant avec son environnement. La seconde partie correspond à son implantation et permet la description du fonctionnement interne du composant. Cette définition est compatible avec celle donnée en 2.1. Un connecteur Le connecteur correspond à un élément d architecture qui modélise de manière explicite les interactions entre un ou plusieurs composants en définissant les règles qui gouvernent ces interactions. Par exemple, un connecteur peut décrire des interactions simples de type appel de procédure ou accès à une variable partagée, mais aussi des interactions complexes telles que des protocoles d accès à des bases de données avec gestion des transactions, la diffusion d événements asynchrones ou encore l échange de données sous forme de flux. Un connecteur comprend également deux parties. La première correspond à la partie visible du connecteur qui permet la description des rôles des participants à une interaction. La seconde partie correspond à la description de son implantation. Il s agit là de la mise en œuvre du protocole associé à l interaction. Une configuration Composants et connecteurs sont des types pouvant être instanciés et assemblés à partir de leurs interfaces pour former une configuration. On parle aussi de topologie ou de composite. La configuration structurelle de l application correspond à un graphe connexe des composants et des connecteurs formant l application. La configuration comportementale, quant à elle, modélise le comportement en décrivant l évolution des liens entre composants et connecteurs, ainsi que l évolution des propriétés non fonctionnelles comme les propriétés spatio-temporelles ou la qualité de service. Un langage de contraintes accompagne souvent le langage de description d architectures pour décrire les règles de composition. Projet ACCORD 8/29

9 Les principaux ADL Les travaux sur les ADL ont été un domaine très actif et de nombreuses propositions ont émergé [MT00] au milieu des années 90. Ces travaux correspondent à la définition de langages dits déclaratifs. Ils peuvent être classés en deux grandes familles. La première correspond aux langages qui privilégient la description des éléments de l architecture et leur assemblage structurel. Les langages de cette famille sont accompagnés d outils de modélisation, d analyseurs syntaxiques et de générateurs de code. La seconde définit les langages qui se centrent sur la description de la configuration d une architecture et sur la dynamique du système. Les langages de cette famille, en plus de d outils de modélisation et de génération de code, sont associés à des plates-formes d exécution ou de simulation d un système. Chaque ADL a une particularité. Wright [AG97] se distingue par les descriptions comportementales à l aide de CSP, Rapide [RDTP97] par la définition de simulation, Aesop [Gar95] par la description de styles d architecture, C2 [MTW96] par les environnements répartis et évolutifs et Darwin [DKM93] par la description des aspects dynamiques. Ce grand nombre de propositions a amené plusieurs classifications et comparaisons. La plus intéressante reste celle proposée par [MT00] qui fournit un cadre de comparaison pour les ADL actuels et à venir. De plus, plusieurs méta-langages, tels que ACME [GMW97] ou ADML [ADML00] proposent une représentation intermédiaire exploitable par les outils architecturaux des différents ADL. Un vocabulaire commun pour les éléments de la structure a été fixé et permet ainsi le passage d un ADL à l autre Tendances La définition de l architecture est une étape importante dans la conception d un logiciel. Elle doit permettre la réalisation d un produit qui répond aux besoins des utilisateurs, mais qui est également évolutif. Malgré ces deux caractéristiques essentielles, la pratique veut que cette étape soit encore souvent oubliée ou traitée de manière partielle. Même si le besoin est là pour les industriels avec l arrivée des grandes applications réparties, les ADL issus des milieux académiques n ont pas réussi à percer. Il leur est souvent reproché d utiliser des notations formelles difficilement manipulables et d avoir des outils peu exploitables. Actuellement, nous pouvons dire que les recherches sur les ADL changent d orientation. En effet, les ADL sont issus de la communauté des architectes logiciels et définissent une technologie parallèle à celle développée dans le monde objet. Dans ce dernier, il est courant d utiliser UML comme langage de modélisation, même si celui-ci reste pauvre en concepts d architecture. Les deux communautés ne se sont pas concertées pendant plusieurs années, mais aujourd hui, avec l apparition de travaux comme ArchJava [ACN02] ou l intégration de la notion de composant dans UML 2.0, nous assistons à une convergence des deux mondes. De plus, des travaux tels que CODeX [Mar01] ou ArchJava touchent à la définition d architecture sous différents angles tout en étant associés à une plate-forme d exécution à base de composants, ce qui laisse présager un environnement intégrant la définition d architectures et un passage facilité vers une plate-forme d exécution adaptée Langages de coordination Les applications actuelles profitent des systèmes parallèles et distribués pour offrir de meilleures propriétés non-fonctionnelles (passage à l échelle, fiabilité, disponibilité, etc.). Cependant, le développement de telles applications reste complexe et la présence de multiples sites ajoute un nouveau défi : la coordination de la coopération d un grand nombre d activités concurrentes actives. De ce fait, la programmation d un système Projet ACCORD 9/29

10 parallèle ou réparti pourrait être vue comme une combinaison de deux activités distinctes : la partie calcul comprenant un nombre de processus impliqués dans la manipulation des données, et la partie coordination responsable de la partie communication et coopération entre les processus. Cette approche rend les modules plus indépendants, permet l évolution d applications en modifiant seulement les éléments concernés et non en intervenant sur toute l application. Ainsi, elle permet de réutiliser d une part les objets sans la façon dont ils sont coordonnés, et d autre part les entités de coordination sans les objets à coordonner [AP98]. Cette théorie a conduit à la proposition d un grand nombre de modèles de coordination et de leur langage de programmation associé. Avant d en faire un survol, nous allons préciser quelques concepts de base Coordination, modèles et langages La coordination n est en aucun cas limitée à l informatique. Dans [MC94], la coordination est décrite comme un domaine de recherche émergeant avec une concentration interdisciplinaire, jouant un rôle clé dans diverses disciplines telles que l économie, la recherche opérationnelle, la théorie de l organisation et la biologie. En conséquence, il existe plusieurs définitions de ce qu est la coordination. Mais d un point de vue informatique, la coordination est définie des façons suivantes : Une information additionnelle de traitement exécutée lorsque de multiples acteurs connectés ont des buts qu un seul acteur, ayant les mêmes buts, ne peut pas atteindre [MC94], L intégration et l ajustement harmonieux des efforts de travaux individuels à travers la réalisation d un objectif plus large [Sin92], Le processus de construction de programmes en collant ensemble des pièces actives [CG92]. La coordination peut être exprimée en termes de modèles et langages de coordination. Cependant, une différence existe. Un modèle de coordination se définit par «la glu qui relie des activités séparées dans un ensemble» [CG92]. Il est généralement caractérisé par trois éléments : les entités à coordonner, le médium qui définit le lieu où se fait la coordination, et le type de coordination qui est la technique utilisée pour coordonner les entités. Un langage de coordination, par contre, est «l incarnation linguistique d un modèle de coordination» [CG92]. Un modèle de coordination fournit donc la sémantique, alors qu un langage de coordination correspondant fournit une syntaxe pour utiliser le modèle dans une implantation Les principaux langages de coordination Trois approches permettent de classifier les modèles et langages de coordination : les modèles orientés données, les modèles orientés événement et l approche par composant. Les langages orientés données La plupart des modèles appartenant à cette catégorie ont évolué autour de la notion de la mémoire partagée. Dans ces modèles, l activité est centrée autour d un espace de données partagé ; l application est essentiellement concernée par ce qui arrive aux données. Ils offrent généralement un ensemble de primitives à intégrer dans un langage de programmation. Ils sont, de ce fait, dits endogènes car les primitives qui affectent la coordination de chacun des modules sont à l intérieur du module lui-même ce qui mène généralement au mélange des primitives de coordination avec le code de calcul. Ceci tend à éparpiller les primitives de coordination et de communication dans le code source rendant le modèle de coopération et le protocole de communication nébuleux et implicite. Le premier modèle conçu dans cette famille pour représenter la coordination est Linda [CG92]. Il a ensuite inspiré plusieurs autres langages comme ObjectiveLinda. Projet ACCORD 10/29

11 Les langages orientés événement Dans les modèles orientés événement, l activité dans l application est centrée autour des traitements ou des flux de contrôle et souvent la notion de donnée n est plus centrale. L application est décrite comme une collection d activités qui consomment leurs données en entrée et en conséquence produisent, mémorisent et transforment «les nouvelles données» qu elles génèrent par elles-mêmes. Ces modèles sont dits exogènes, c est-à-dire que les primitives qui affectent la coordination de chaque module sont à l extérieur du module lui-même. Ces modèles encouragent le développement des modules de coordination séparément et indépendamment des modules de calcul qu ils sont supposés coordonner. Par conséquent, le résultat de l effort investi dans la conception et le développement du composant de coordination d une application peut se manifester comme un «module de coordination pure» qui peut être plus facile à comprendre et peut aussi être réutilisé dans d autres applications. Le langage de coordination est séparé de celui du calcul. Le langage le plus représentatif dans cette catégorie est Manifold [AHS93]. Une approche qui est différente de l approche orientée événement mais qui s inclurait dans cette catégorie est l approche de [AF00]. Elle propose de séparer la coordination du calcul non pas sous la forme de processus mais sous forme de contrat. Toute la coordination est donc représentée sous forme de contrats ce qui permet, en modifiant cet ensemble de contrats, de faire évoluer les interactions. L approche par composant L approche par composant consiste à avoir un type de composant qui ne s occupe que du calcul et un autre type de composant réutilisable qui s occupe de la coordination des composants de calcul. Ceci ressemble fortement à l approche orientée événement, à la différence que la mise en œuvre de la coordination n est pas nécessairement le résultat d une compilation de la coordination mais qu elle est cachée dans le composant. De ce fait, seules les interfaces des composants apparaissent et la technique utilisée pour la coordination est indifférente. L initiateur de cette approche est le langage Flo/c [Gün98], repris par les composants de communication ou médiums [Beu00] ainsi que par le modèle CoLas [CD99]. 3 Standards Un des attraits d une architecture à composants est la possibilité de construire une application à partir de composants provenant d'origines diverses. Cela suppose la standardisation des éléments nécessaires à un tel assemblage, notamment pour garantir les trois propriétés caractéristiques d un système ouvert : la portabilité, l interopérabilité et l interchangeabilité. Deux grandes orientations de standardisation sont menées : l une concerne les outils de spécification et les modèles, et l autre les infrastructures d accueil. 3.1 Outils de spécification/modèles Dans le domaine des outils de spécification et de modèles utilisables dans une approche composant, nous allons considérer sont le standard Unified Modeling Language (UML) et la norme Open Distributed Processing (ODP) Le modèle de composant d UML 2 Le futur standard UML 2 propose un modèle de composant nettement amélioré par rapport à la version UML 1. Projet ACCORD 11/29

12 Concepts Dans ce paragraphe, nous présentons les traits particuliers des composants en UML 2 et signalons les omissions particulières de ce modèle. Le méta-modèle d UML 2 définit les entités suivantes dans les packages Structure::Components et Structure::Ports. Un composant (component) est une entité instanciable qui interagit avec son environnement par l intermédiaire de ports et qui a une description de ce comportement fondé sur des machines à états. De manière interne, un composant est constitué de parties (parts) et peut inclure des connecteurs internes (pour connecter ensemble des sous-composants). Un port est une entité qui émerge d un composant ; elle se comporte comme un point d interaction du composant avec l environnement. Les interactions peuvent être bi-directionnelles. Un port est typé par une interface. Un port peut être requis (required) pour signifier que l instance du composant doit être connectée à un port correspondant de l environnement (c est-à-dire une autre instance de composant qui fournit le service demandé). Un port qui est non requis offre des services. Ces services offerts peuvent être utilisés ou non selon que le port associé est connecté ou non. Un connecteur (connector) est une entité qui relie des ports d instances de composant. Une interface définit un type. Elle contient un ensemble d opérations et/ou de contraintes. Une interface peut être attachée à un port fourni (provided) ou requis (required). Une partie (part) est un fragment interne d un composant Assemblage Une application ou un composant est constitué de l assemblage d autres composants par l intermédiaire de ports interconnectés. Un connecteur d assemblage (AssemblyConnector) permet d assembler deux instances de composants en connectant un port fourni d un composant au port requis de l autre composant. Un connecteur de délégation (DelegationConnector) permet de connecter un port externe au port d un sous-composant interne. L invocation d un service sur le port externe sera transmise au port interne auquel il est connecté. FIG. 1 Un exemple de connecteur d assemblage (AssemblyConnector) Les composants doivent expliciter leurs besoins ainsi que leurs capacités. La proposition UML 2 définit des moyens d indiquer qu une entité dépend d une autre à l aide de la méta-entité Dependency. Les services d un composant peuvent être invoqués seulement par l intermédiaire des ports de ce composant. Projet ACCORD 12/29

13 De plus, un composant peut décrire les interactions qui doivent se produire sur un port donné en attachant un comportement (par exemple, une machine d états) à ce port. Ceci fournit une sorte de spécification de contrat de niveau 3 sur un port. Les ports peuvent être connectés seulement si leurs spécifications de comportement sont compatibles Evénement La plupart des modèles de composants incluent un mécanisme pour la signalisation d événements entre le composant et son environnement. La proposition UML2 n inclut pas de concepts spécifiques pour la signalisation d événements aux composants mais s appuie sur le concept de Signal déjà existant en UML. Il n y a pas??? de notion d enregistrement en attente d occurrence d événements. Un cas particulier de modèle d événement apparaissant dans certains modèles (par exemple Catalysis) inclut un concept de propriété où une propriété est une partie observable d un état de composant avec un système de notification de changement incorporé. Cette notion de propriété n est pas incluse dans le méta-modèle proposé (mais bien sûr pourrait être définie en utilisant le concept du package Behavior) Flots La proposition UML ne prévoit pas de flots continus qui spécifieraient des propriétés globales (comme la performance) et/ou les items qui circulent dans le flot ne seraient pas observables (au moins à un haut degré d abstraction) Déploiement A un certain moment de son cycle de vie, un composant sera configuré et installé en tant que sous-ensemble d une installation d une application. La notion de composant de UML est indépendante de la plate-forme et des modèles de composants spécifiques. Donc, UML fournit des outils conceptuels pour projeter (mapper) les entités représentant les composants indépendants des plate-formes sur les entités spécifiques aux vendeurs et aux plate-formes. Un Artéfact (Artifact) représente une entité spécifique à une plate-forme (par exemple un fichier d archive contenant du Byte Code Java) Un Nœud (Node) représente une entité capable d héberger une exécution d une instance de composant et de fournir des ressources de calcul et de mémoire ODP Open Distributed Processing est une norme conjointe de l ISO et l ITU dont le but est de structurer les concepts de base des systèmes et applications répartis. Elle vise à être un modèle de référence : plusieurs standards du domaine, et notamment ceux de l OMG, s inspirent et font référence à cette norme. Le modèle de référence de l ODP est décrit en 4 parties : 1-Guide, 2-Fondations, 3-Architecture, et 4-Sémantique Architecturale. La partie 2-Fondations définit les concepts de base tel que objet, interface, action, point de vue, composition, etc La partie 3-Architecture définit un modèle de spécification basé sur une gamme de niveaux d abstraction appelés points de vue. La partie 4-Sémantique Architecturale établit des correspondances entre les concepts définis dans les parties 2 et 3 et les techniques de spécification formelle : SDL, LOTOS et Z. La partie 3 est prescriptive. Elle préconise que les entités à l étude (tout ou partie d un système, d un service ou d une application) soient décrites selon les points de vue de l ODP et qu un contrôle de cohérence soit établi entre les spécifications écrites dans des points de vue différents. Cinq niveaux d abstraction - les cinq points de vue, ont été établis comme pertinents dans ODP. A eux cinq, ils couvrent les différentes phases à considérer dans le développement de systèmes ou applications répartis. Chaque point de Projet ACCORD 13/29

14 vue possède un modèle et un langage. Ce dernier mot est à prendre dans une acception large : un langage de point de vue est un ensemble structuré de concepts utilisables dans le discours sur ce point de vue. Les cinq points de vue d ODP sont : Entreprise, Information, Traitement, Ingénierie et Techniques. Nous les décrivons brièvement ciaprès. Le point de vue Entreprise introduit l entité considérée (objet de l étude) et délimite sa portée, définit ses requis essentiels d un point de vue entrepreneur (par exemple, comment l application envisagée améliore l existant, ou comment le service projeté se démarque par rapport à la concurrence), établit les contraintes légales et administratives qui régissent la mise en service de l entité, identifie les partenaires impliqués dans cette mise en service, et définit les rôles, attentes et obligations de ces partenaires. Le point de vue Information définit, pour l entité considérée, les éléments d information permettant de représenter son état (schéma statique en terminologie ODP), et pour chaque état, les opérations licites et les changements d états produits par ces opérations (schéma dynamique en terminologie ODP). Une spécification selon le point de vue Information est donc une représentation abstraite du système, qui permet de connaître son comportement fonctionnel sans avoir à traiter les problèmes d ingénierie (programmation, ressources de traitements, répartition, pannes, transport,...). Le point de vue Traitement est le pivot de l architecture ODP. Dans ce point de vue l entité considérée prend la forme d une configuration dynamique d'objets répartis communicants. Les objets qui composent ces configurations sont de deux types : objets de base et objets de liaison. Les objets de base communiquent soit par signaux directs soit à travers des objets de liaison. Ces derniers permettent d encapsuler des sémantiques de communication particulières. Le point de vue traitement facilite l'articulation entre les représentations abstraites des besoins (en termes de modèles d'entreprise et d'information) et des implantations sur des machines virtuelles réparties. Le modèle de traitement constitue donc un point de passage naturel et avantageux entre le monde des spécifications abstraites et le monde des implantations réparties. Dans le point de vue Ingénierie, les configurations d objets de traitement sont projetées sur des nœuds de traitement. La communication entre objets est alors matérialisée par des protocoles qui respectent la sémantique définie par les objets de liaison. Les transparences (accès, atomicité, fiabilité, migration, résistance aux pannes), déclarées comme propriétés des configurations de Traitement, sont mises en œuvre par des services fournis dans le modèle d Ingénierie. Par exemple, à chaque objet de base du modèle de traitement, sont associés un stub et un relocator dans le modèle d ingénierie. Le stub réalise la transparence de l accès en jouant le rôle de l objet distant. Le relocator rend transparente la migration de l objet en redirigeant les requêtes qui lui sont destinées vers son nouveau site. Alors que dans le point de vue Ingénierie, le discours porte sur des schémas de solution (par exemple, on dira que la communication sera réalisée par le protocole TCP) c est dans le point de vue Techniques que l on choisira les solutions présentes sur le marché (par exemple la pile TCP de Linux BSD) ou à réaliser en spécifique. Les solutions concrètes relèvent donc du point de vue Techniques. Les autres points de vue agissent comme des spécifications auxquelles le point de vue Techniques doit se conformer. Projet ACCORD 14/29

15 Bien que l ODP n ait pas identifié de notion de Composant, plusieurs concepts d ODP relèvent de la problématique Composant. Par exemple, les objets d ODP (Traitement ou Ingénierie) sont multi-interfaces comme les composants ; les objets de liaison s apparentent aux connecteurs ; les objets Ingénierie sont hébergés dans des structures d accueil : ils sont regroupés dans des clusters le cluster étant l unité de migration et de passivation, les clusters sont regroupés dans des capsules la capsule étant l unité de la ressource traitement. Le modèle ODP reste donc intéressant dans une étude visant la construction d un modèle de composants. 3.2 Structures d accueil Trois efforts de standardisation sont actuellement en cours : les spécifications EJB, CCM et.net. Nous consacrons, dans cette partie, une section à chacune de ces propositions. En particulier, nous esquissons leurs éléments d architecture et leur cycle de vie logiciel. La section «EJB 2.0» présente la version 2.0 de la spécification EJB (Enterprise JavaBeans) provenant de la société Sun Microsystems, qui propose un modèle d'architecture support pour des composants développés dans le langage de programmation Java. La section «CCM» présente le modèle CCM (CORBA Component Model) qui doit être inclus dans la future version 3.0 de la spécification CORBA (Common Object Request Broker Architecture) de l OMG (Object Management Group). La section «.NET» décrit la version en cours de développement du modèle de composants proposé par Microsoft. Elle fait suite aux spécifications de COM (Component Object Model), de DCOM (Distributed COM) et de COM+. L évolution vers.net correspond à une intégration de plus en plus forte de l infrastructure d accueil des composants dans le système d exploitation Windows et la prise en compte unifiée de composants développés dans des langages de programmation différents EJB 2.0 Client Création d une instance du bean Requête d une méthode du bean EJBHome EJBObject création Délégation de l appel Container Bean FIG. 2 - Architecture EJB Le standard EJB propose une architecture de composants pour le développement et le déploiement d applications réparties fondées sur des composants EJB appelés beans [EJB01]. Le standard EJB décrit l architecture et les services qu un composant EJB peut utiliser (de manière transparente) mais ne donne aucun détail sur la manière de mettre en oeuvre ces services. Cette liberté permet aux vendeurs d architectures EJB de se différencier d un point de vue performances ou possibilités offertes, et de fournir des services supplémentaires. Enfin, les composants EJB étant développés en Java, ils profitent de la portabilité de ce langage. Projet ACCORD 15/29

16 Architecture La figure 2 donne une vue simplifiée de l architecture EJB ; elle repose sur deux principes : 1) La fabrique d instance : pour que le client puisse accéder aux méthodes métier du bean, il doit tout d abord récupérer un accès au bean. Cela se fait par l intermédiaire de la classe EJBHome, qui renvoie une référence sur la classe EJBObject, représentant le bean correspondant ; 2) La délégation des requêtes : le client n accède pas directement au bean. Ses requêtes doivent être envoyés à l interface du bean : la classe EJBObject qui délèguera la requête vers le bean. Les trois classes Java (EJBHome, EJBObject et Bean) sont gérées par un conteneur (Container), correspondant à l environnement d exécution du bean. Nous allons maintenant détailler les différentes catégories de bean ainsi que les autres éléments de l'architecture EJB : conteneur, serveur et descripteur de déploiement. Bean session, entité et orienté message Le standard EJB 2.0 définit trois types de bean se différentiant essentiellement par rapport à leur durée de vie. 1) Bean session : ce bean n existe que pour une session demandée par le client. Deux types de bean session existent : Stateless ou sans état : le bean ne maintient pas d informations à la suite des différentes requêtes qui lui sont adressées. Le Conteneur peut alors partager séquentiellement le bean entre plusieurs clients ; Statefull ou avec état : le bean conserve en mémoire l état du client. Chaque instance du bean n appartient alors qu à son client, et ne peut être partagée. 2) Bean entité (entity) : ce bean est une représentation de données persistantes ; il existe tant qu il n a pas été détruit explicitement. Pour récupérer un bean entité, un client peut utiliser la clé primaire du bean donnée lors de la création de ce dernier. L accès au bean peut être partagé entre plusieurs clients. 3) Bean orienté message (message-driven) : ce bean est utilisé lorsque ses méthodes métier doivent être asynchrones ; il est invoqué sur réception d un message du client, en utilisant le service JMS de Java (Java Messaging Service). Bean local ou distant La version 2.0 introduit également la notion de localité du bean. Cette notion ne s applique pas aux beans orientés messages, qui sont de par nature distants. Pour les beans Remote (issus des versions EJB 1.x), le client n a pas besoin de connaître l emplacement du bean. L accès se fait obligatoirement à l aide de Java RMI. Les beans Local sont par contre situés sur la même machine virtuelle que le client (un bean peut alors, à l intérieur d un même Conteneur, faire appel à un autre bean). Une conséquence fondamentale de la notion de localité concerne le passage de paramètres lors d un appel de méthode : pour les EJB Remote, le passage se fait par valeur tandis que, pour les EJB Local, le passage se fait par référence, les arguments étant alors potentiellement partagés entre le client et le bean. La propriété Local ou Remote du bean est choisie lors de la création du bean. Conteneur, serveur et descripteur de déploiement Le rôle principal du conteneur est de gérer les instances des différents beans. Suivant le cas, il prendra en charge un pool d instances (par exemple pour les beans sessions avec état). Le conteneur peut, de plus, proposer différents services aux beans. Le bean Projet ACCORD 16/29

17 s exécute en fait dans un contexte définissant les différentes propriétés du client (son identité, les différents rôles qui lui sont attribués), et l état des services mis en œuvre. L infrastructure d accueil des composants EJB comprend également une entité appelée «EJB server» - ou serveur - qui représente le logiciel support des communications et des services techniques nécessaires à l exécution du composant et à son accès par le réseau. Les deux principaux services développés dans le standard EJB 2.0 concernent la sécurité et les transactions. Un descripteur de déploiement est associé à un composant et permet de décrire ses caractéristiques Cycle de vie Le standard définit quatre rôles principaux : 1) Le fournisseur de bean (Bean Provider) : il crée le bean, et fournit un fichier ejb-jar contenant le code du bean et son descripteur de déploiement. Ce descripteur contient entre autres la description des ressources externes nécessaires pour déployer le bean ; 2) L assembleur d application : il regroupe plusieurs beans pour son application ; 3) Le déployeur (deployer) : il déploie les beans dans un environnement opérationnel (c est-à-dire sur un serveur EJB et un conteneur EJB). Il suit les instructions de l assembleur d application tout en respectant le descripteur de déploiement des beans ; 4) Le fournisseur de serveur EJB, de conteneur EJB : fournit la structure d accueil qui sera utilisée. Le standard n est pas très claire quant au rôle du serveur EJB qui semble confondu avec celui du conteneur CCM La réponse de l OMG aux limites rencontrées dans les modèles à objets est le CORBA Component Model (CCM) modèle de composants qui servira de base au futur standard CORBA 3. La spécification de cette version du standard n est pas encore achevée ; cependant, le chapitre sur le modèle de composants a été finalisé à l OMG en janvier C est donc l un des plus jeunes modèles de composants mais aussi l un des plus riches en comparaison avec d autres modèles (cf [MP01]). Dans un but de compatibilité ascendante, l OMG a défini son modèle de composants comme une extension du modèle objet de CORBA 2. Les composants CORBA représentent donc une spécialisation des objets CORBA tels que nous les connaissons aujourd hui. Projet ACCORD 17/29

18 Architecture FIG. 3 Exemple d une application répartie CCM Les applications visées par les composants CORBA sont des applications réalisées à partir de composants hétérogènes répartis. La figure 3 présente une vue d ensemble de ce que peut être une application à base de composants CORBA. Cette application représente une instance possible d une l application «distributeur de boissons». Cette application met en jeu différents éléments : une prise de courant, une prise d eau, une sonde de température et le distributeur. A cela viennent s ajouter deux éléments simulant un consommateur et un fournisseur de boissons. Cette instance de l application s exécute sur quatre sites distincts (dans le sens machine) et distants les uns des autres. Tout d abord, un site central à notre application, le site qui héberge deux instances de composants distributeurs, un pour les boissons froides et un pour les boissons chaudes. Pour que ces deux instances s exécutent, elles nécessitent un support d exécution. Celui-ci est fourni par un conteneur (container). Un conteneur est un support d exécution générique qui peut accueillir différents types de composants, mais ayant toutefois des caractéristiques systèmes communes (en termes de persistance par exemple). Pour ne pas réduire les capacités d un site d exécution à un ensemble de conteneurs statiquement définis et pour ne pas avoir à instancier tous les conteneurs possibles sur un site, les conteneurs reposent sur des serveurs de conteneurs. Ces serveurs sont matérialisés sous la forme de processus du système d'exploitation hôte et permettent d activer des conteneurs à la demande et selon les besoins. Dans l'exemple, au sein du serveur de conteneurs principal, il y a donc quatre conteneurs qui permettent l exécution de six instances de composants : deux instances de distributeurs, deux instances de prises de courants et deux instances de prises d eau. Comme un conteneur vient d être défini comme un support d exécution générique, pour éviter de réduire les possibilités disponibles lors de l instanciation de composants, une entité appelée maison de composants (home) est utilisée. Une maison est un gestionnaire d instances de composants, s occupant principalement de leur cycle de vie. Les maisons de composants contiennent le code réifiant l instanciation des composants, ce qui apporte une certaine souplesse. En plus de permettre l utilisation d un même type Projet ACCORD 18/29

19 de conteneurs avec différents types de composants, cette approche permet d automatiser le déploiement des applications. En effet, il est possible de choisir des sites d exécution à partir d un ensemble connu, puis d installer une application sur ces sites à partir d un poste d administration. Pour cela, en plus de fournir un environnement d exécution (un serveur de conteneurs), un site doit offrir un service de chargement de code, il est ainsi possible de charger une implantation de composant sur un site distant (ainsi que l implantation de sa maison associée). Une fois les conteneurs instanciés, les implantations de composants et de maisons chargées, les maisons et les composants instanciés, il ne reste plus qu à interconnecter les instances de composants entre elles pour former l application. La connexion entre deux instances de composants se fait au travers de ports, les points de connexion. Pour que deux types de composants puissent être mis en relation, il est requis que ces deux types aient un port fourni et un port requis compatibles. Il existe deux modes de connexion entre les types de composants : un mode synchrone, l invocation de méthodes, et un mode asynchrone, l utilisation d événements. Le modèle de composants CORBA offre une réponse à tous ces besoins Cycle de vie Le CCM est un framework de composants de type serveurs, mais qui, semble-t-il, peut facilement être utilisé du côté client des applications. Le CCM se décompose en deux niveaux : un niveau de base, qui permet essentiellement de transformer en composant des objets CORBA, et un niveau étendu, beaucoup plus riche et intéressant, illustré avec l exemple du distributeur de boissons. Tout comme les EJB de Sun, auxquels correspond la version de base du CCM en Java, le framework CCM repose sur l utilisation de conteneurs pour héberger les instances de composants et faciliter leur déploiement. La spécification du framework CCM [OMG01], qui représente plus de 1000 pages, est découpée en quatre modèles couvrant le cycle de développement et de déploiement des applications à base de composants CORBA. Le modèle abstrait offre aux concepteurs le moyen d exprimer les interfaces (fournies et utilisées) et les propriétés d un type de composant. Pour cela, le langage OMG IDL a été étendu pour prendre en compte les nouveaux concepts introduits dans le CCM, essentiellement la prise en compte des interfaces multiples : les ports. Le modèle abstrait permet aussi de définir les gestionnaires d instances de composants. Le modèle de programmation spécifie le langage CIDL (Component Implementation Definition Language) à utiliser pour définir la structure de l implantation d un type de composant, ainsi que certains de ses aspects non-fonctionnels (persistance, transactions, sécurité). L utilisation de ce langage est associée à un framework, le CIF (Component Implementation Framework), qui définit comment les parties fonctionnelles (programmées) et non-fonctionnelles (décrites en IDL / CIDL et générées) doivent coopérer. Il inclut aussi la manière dont l implantation d un composant interagit avec le conteneur. Le modèle de déploiement définit un processus qui permet d installer une application sur différents sites d exécution de manière simple et automatique. Ce modèle s appuie sur l utilisation de packages de composants, ainsi que de descripteurs OSD (Open Software Description, un vocabulaire XML), les packages étant déployables et composables. Le modèle d exécution définit l environnement d exécution des instances de composants. Le rôle principal des conteneurs est de masquer et prendre en charge les aspects non-fonctionnels des composants qu il n est alors plus nécessaire de programmer. Projet ACCORD 19/29

20 3.2.3.NET Sous l'appellation «.NET», Microsoft regroupe un ensemble de ses produits : platesformes de développement et d'exécution pour applications réparties à base de composants Architecture En termes de plate-forme de développement, avec.net, Microsoft offre le support de plusieurs langages tels que C++, VB.NET ainsi qu'un nouveau langage : C# (C Sharp). C# est très proche du langage Java. Il supporte l'héritage simple, l'implémentation multiple d'interface, les propriétés, la surcharge d'opérateur, les événements. Tous ces langages supportés peuvent être compilés en un code intermédiaire MSIL (Microsoft Intermediate Language). Ce code intermédiaire est exécuté par le CLR (Common Language Runtime).Enfin,.NET met l accent sur la programmation par réutilisation de services (Web Services). Ainsi, WSDL (Web Service Definition Langage) est un format de représentation des interfaces de Service Web en XML. C est la représentation XML des langages IDL (OMG) ou MIDL (Microsoft) de description des interfaces. En termes de plate-forme d'exécution,.net propose une évolution de COM+ «.NET remoting» qui permet la distribution de composants. COM+ est une version avancée de COM qui regroupe l'ensemble des services dédiés au applications réparties de Windows, à savoir : DCOM, MTS et MSMQ. En plus d'agréger ces services, COM+ apporte de nouvelles capacités fonctionnelles comme les «queued components», un mécanisme de gestion des événements (publish/subscribe) ou la répartition de charge (load balancing). DCOM est l'équivalent au niveau de la couche transport du protocole IIOP de CORBA mais pour la plate-forme Windows. MTS (Microsoft Transaction Server) permet le développement, le déploiement et l'exécution de composants répartis fonctionnant sous le contrôle d'un conteneur. MTS offre également des services pour la prise en charge des transactions. MSMQ (Microsoft Message Queue Server) est un middleware de type Message Oriented Middleware qui prend en charge la communication asynchrone point à point entre applications. MSMQ permet la création et l'utilisation d'entités appelées files (queues) par lesquelles les messages sont échangés. MSMQ peut aussi être utilisé dans le cadre de transactions réparties..net supporte trois modèles de composants : 1) «Single Call» : Une instance du composant ne sert qu'une seule requête. Ni l'état du composant ni le contexte des clients ne sont gérés. 2) «Singleton Objects» : Une instance du composant peut servir plusieurs clients simultanément. L'état du composant est partagé par les clients. 3) «Client Activated Objects» : Une instance du composant est activée pour chaque client (mode d'activation très proche de celui d'un composant COM+). Le contexte du client est géré entre ses différents appels. Un assemblage est un regroupement de types (classes, structures, énumérations,...) et de ressources (images, sons, textes...) en un composant déployable. Généralement, un assemblage comporte les 4 éléments suivants : les méta-données qui décrivent l'assemblage, les méta-données qui décrivent chacun des types contenus dans l'assemblage, le code des types sous la forme de MSIL, les ressources. Projet ACCORD 20/29