Lot 1.1-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 1.1 - 1
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
Sommaire
1
2
3
4
5
6
7
Introduction ........................................................................................................................ 3
Concepts............................................................................................................................. 4
2.1 Composant ..................................................................................................................... 4
2.1.1 Interface et service ................................................................................................. 4
2.1.2 Spécification et contrat........................................................................................... 4
2.1.3 Assemblage et connecteur...................................................................................... 5
2.1.4 Granularité.............................................................................................................. 5
2.1.5 Structure d’accueil ................................................................................................. 6
2.1.6 Différentes catégories de composants.................................................................... 6
2.2 Contrat............................................................................................................................ 6
2.3 Assemblage .................................................................................................................... 7
2.3.1 Langages de description d’architectures ................................................................ 7
2.3.2 Langages de coordination ...................................................................................... 9
Standards .......................................................................................................................... 11
3.1 Outils de spécification/modèles ................................................................................... 11
3.1.1 Le modèle de composant d’UML 2 ..................................................................... 11
3.1.2 ODP...................................................................................................................... 13
3.2 Structures d’accueil...................................................................................................... 15
3.2.1 EJB 2.0 ................................................................................................................. 15
3.2.2 CCM..................................................................................................................... 17
3.2.3 .NET ..................................................................................................................... 19
Conclusion ....................................................................................................................... 20
Annexe ............................................................................................................................. 22
Bibliographie.................................................................................................................... 24
Liens Internet ................................................................................................................... 26
© Projet ACCORD
2/29
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
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é.
2.1.1 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.
2.1.2 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
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.
2.1.3 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.
2.1.4 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
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.
2.1.5 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.
2.1.6 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
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.
2.3.1 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
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.
2.3.1.1 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
2.3.1.2 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.
2.3.1.3 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.
2.3.2 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
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.
2.3.2.1 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.
2.3.2.2 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
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).
3.1.1 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
3.1.1.1 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.
3.1.1.2 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
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.
3.1.1.3 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).
3.1.1.4 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).
3.1.1.5 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.
3.1.2 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
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
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.
3.2.1
EJB 2.0
Container
Création d’une instance du bean
EJBHome
création
Client
Requête d’une méthode du bean
EJBObject
Délégation
de l’appel
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
3.2.1.1 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
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.
3.2.1.2 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.
3.2.2 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
2002. 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
3.2.2.1 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
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.
3.2.2.2 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
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.
3.2.3.1 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
4 Conclusion
Cet état de l’art sur l’« assemblage de composants par contrats » montre l’ampleur et la
complexité du domaine. L’ensemble du cycle de vie de développement du logiciel est
couvert : de l’analyse des besoins indispensable à une bonne définition des composants,
au déploiement et à la configuration des implantations de composants dans des
structures d’accueil variées, en passant par les problèmes de spécification – plus ou
moins formelle -, d’assemblage et de vérification de la cohérence de ces assemblages, et
de projections vers des solutions techniques du marché informatique, où se livre une
concurrence importante. De plus, les concepts sont loin d’avoir une définition adoptée
par tous, à commencer par celle fondatrice de composant.
Les solutions techniques à base de composants sont en pleine émergence. Elles se
trouvent à la convergence de techniques plus matures mais qui ont montré leurs limites
comme les objets, dont les interfaces manquent de symétrie pour former des entités
composables simplement, les ADL qui peinent à décrire des architectures ouvertes et
dynamiques ou les langages de coordination qui nécessitent de lourds mécanismes
d’introspection pour fonctionner. Nombre de solutions techniques apparaissent
s’appuyant chacune sur une infrastructure se voulant standard mais qui, du fait de la
diversité, s’avère spécifique, qui Java (EJB), qui CORBA (CCM), qui .NET.
Le projet ACCORD a pour objectif initial la définition d’un modèle abstrait de
composant et d’assemblage, indépendant de toute infrastructure matérielle et de tout
modèle d’implantation de composant comme EJB, CCM ou .NET. Ce modèle précisera
les notions de composant, interface, assemblage, composition en s’appuyant sur des
spécifications sous forme de contrats. Les relations et les contraintes d’assemblage entre
ces notions feront aussi intégralement partie du modèle abstrait de composant.
Ce projet, bien que n’ayant pas l’objectif de définir un langage de description
d’architecture, s’inspire d’un certain nombre de concepts présents dans les ADL. Citons,
par exemple, dans la définition du modèle abstrait, la possibilité de description
hiérarchique des composants, un travail sur la notion de type, classe et instance comme
dans certains ADL, ou encore la description des interactions de manière explicite, sous
forme de connecteurs. Afin d’en assurer une utilisation industrielle, le modèle abstrait
sera décrit en UML en exploitant et adaptant les modèles de composant proposés dans la
version 2.0. A ce titre, les membres du projet ACCORD souhaitent élaborer des
propositions d’évolution d’UML à l’OMG.
Devant la diversité des solutions techniques « à base de composants », et pour pouvoir
définir des règles de projection du modèle abstrait vers ces solutions existantes, il est
indispensable de disposer d’un outil commun de représentation. Une fois encore, UML
permet d’atteindre cet objectif grâce à l’utilisation de la notion de profil, qui permet
simplement de traduire l’ensemble des entités dépendantes d’une technique particulière
comme EJB ou CCM en UML.
Disposant en UML, d’une part, d’un modèle abstrait de composant qui permettra de
construire des applications par assemblage de composants en respectant les contrats des
composants et des assemblages et, d’autre part, de la description des architectures
cibles, le projet ACCORD s’attachera à définir des règles de projection qui devraient
permettre de déployer les applications ainsi construites sur les infrastructures cibles EJB
et CCM.
© Projet ACCORD
21/29
Notons enfin que l’approche du projet ACCORD repose sur un principe compatible
avec les travaux de l’OMG sur l’Architecture Guidée par les Modèles (MDA, ModelDriven Architecture) ; le modèle abstrait correspond au modèle indépendant des platesformes techniques (PIM, Platform Independent Model) et les techniques de projection
que nous envisageons peuvent être considérées comme des transformations vers des
modèles techniques comme EJB ou CCM, c’est-à-dire des PSM (Platform Specific
Model).
© Projet ACCORD
22/29
5 Annexe
Cette annexe liste quelques projets français ou européens dont les préoccupations sont
proches de celles du projet ACCORD.
RNTL ARCAD (Architecture Répartie extensible pour Composants Adaptables)
Définition de mécanismes de haut niveau pour le déploiement d’applications réparties,
orienté infrastructure.
ARCAD cherche à fournir un environnement pour implanter des composants (à la fois
une abstraction et une extension des plates-formes d’exécution actuelles telles qu’EJB,
CCM, ou autres), tandis qu’ACCORD se propose de définir un cadre pour les
concevoir. Les deux sont d’ailleurs complémentaires, et des réunions d’échange
d’informations sont envisageables.
RNTL MACAO (Aide à la Conception et à l’Audit de modèles pour les
Composants)
Les objectifs du projet sont de proposer une démarche et des outils pour évaluer des
critères permettant de mesurer certaines caractéristiques de composants, telles que la
qualité, l’autonomie, l’adéquation au besoin, etc.
L’idée de MACAO de mesurer certaines caractéristiques sur des composants ne fait pas
l’objet du projet ACCORD. Elle est cependant complémentaire. Par ailleurs MACAO
considère les composants isolément, au contraire d’ACCORD qui cherche à mieux
définir par les contrats les collaborations de composants.
RNRT CASTOR (Conception d’un atelier de création de services pour les platesformes TINA-CORBA-RI)
CASTOR cherche à définir des composants de services pour un domaine particulier.
Le résultat principal d’ACCORD n’est pas la fourniture de composants pour un
domaine (les cas d’étude ne sont là que pour valider et démontrer les idées), mais la
fourniture d’un cadre indépendant du domaine pour aider les architectes à les concevoir.
Un projet similaire à CASTOR pourrait s’appuyer sur les résultats du projet ACCORD.
RNTL COTE (Etude et réalisation de techniques et d’outillage de test unitaire et
de vérification des composants logiciels, s’appuyant sur les outils de modélisation
UML)
COTE cherche à définir des outils pour la validation et le test unitaire de composants.
Le domaine des composants est vaste et pour cette raison, le test de composant ne fait
pas l’objet du projet ACCORD, qui se concentre sur les outils du concepteur et de
l’assembleur. Notons que les contrats pourraient être utilisés comme spécification sur le
test.
RNTL SALOME (Simulation numérique par architecture logicielle en Open
Source et à Méthodologie d’Evolution)
SALOME a pour objectif la réalisation d'une plate-forme applicative en Open Source de
liaison CAO-CALCUL permettant d'interfacer des Solveurs numériques.
La plate-forme est réalisée en utilisant une approche composants et peut être comparée
aux plates-formes standards CCM, EJB et .NET avec une valeur ajoutée due à son
orientation vers le logiciel scientifique. Il est donc envisageable de l'utiliser comme
plate-forme cible d'exécution pour des applications qui auront été conçues grâce à
l'atelier développé dans le cadre du projet ACCORD.
© Projet ACCORD
23/29
IST EASYCOMP (Easy Composition in Next Generation Systems)
EASYCOMP vise la définition d’une « fondation » permettant de diffuser des
composants via le WEB.
L’idée semble très bonne (cf. les Web services), mais il est difficile de voir exactement
quelles sont précisément les ambitions du projet. Apparemment, il ne s’agit pas de
définir un cadre méthodologique, mais plutôt de spécifier le cadre technique (peut-être
en définissant des DTD XML) qui supportera cette diffusion. Il est en particulier
difficile de voir quels concepts seront définis en regard des préoccupations
d’assemblage fiables (présentes dans ACCORD).
IST PECOS (Pervasive Component Systems)
L’idée du projet est de proposer un environnement pour spécifier, composer, tester des
configurations, déployer des systèmes embarqués. Les résultats attendus un modèle de
composants, un référentiel de composants, un outils de composition, et un
environnement d’exécution.
Les idées présentes dans PECOS sont relativement proches de celles d’ACCORD.
Cependant, d’une part PECOS ne traite que de systèmes embarqués, et d’autre part le
projet ne semble pas mettre en avant la notion d’assemblage.
QCCS (Quality Controlled Component-based Software development)
QCCS a pour objectif de proposer une méthodologie et des outils pour construire des
composants en se fondant sur la notion de contrat et sur les mécanisme de la
programmation par aspects.
Comme ACCORD, QCCS semble proposer un cadre méthodologique fondé sur les
contrats, mais à la différence du premier QCCS paraît vouloir appliquer ces concepts à
la seule définition des composants et non aux collaborations. Par ailleurs, ACCORD ne
compte pas s’appuyer sur des techniques de programmation par aspects.
IST COMBINE (COMponent-Based Interoperable Enterprise system
development)
COMBINE est un projet Européen centré sur la définition d'une démarche et d'un
support complet de l'approche par composant, en cohérence avec le standard en
construction "EDOC".
COMBINE ne traite pas de l'assemblage qui est le thème essentiel de ACCORD. Les
études méthodologiques de COMBINE ne sont pas le point focal de ACCORD. Ces
projets sont disjoints et complémentaires.
© Projet ACCORD
24/29
6 Bibliographie
-- composant
[HC01]
[HS00]
[WHS02]
[Szy98]
George T. Heineman, William T. Councill, Component-based software
engineering : Putting the pieces together, AddisonWesley, 2001.
Peter Herzum, Oliver Sims, Business Component Factory – A
Comprehensive Overview of Component-Based Development for the
Enterprise, Wiley Computer Publishing, 2000.
Kurt C. Wallnau, Scott A. Hissam, Robert C. Seacord, Building systems
from commercial components, AddisonWesley, 2002.
Clemens Szyperski, Component Software – Beyond Object-Oriented
Programming, Addison-Wesley, 1998.
-- contrat
[BJPW99]
[LPJ98]
[McH94]
[Mey92]
[WK98]
Antoine Beugnard, Jean-Marc Jézéquel, Noël Plouzeau, Damien Watkins,
Making Components Contract Aware, Computer, July 1999, pp 38-45.
S. Lorcy, N. Plouzeau, and J.-M. Jézéquel, Reifying Quality of Service
Contracts for Distributed Software, Proc. 26th Conf. Tech. OO Systems
(TOOLS USA’98), IEEE Computer Society, Los Alamitos, Ca.,Aug. 1998,
pp. 125-139.
C. McHale, Synchronization in Concurrent, Object-Oriented Languages:
Expressive Power, Genericity and Inheritance, doctoral dissertation, Trinity
College, Dublin, Dept. Computer Science, 1994.
B. Meyer, Applying ‘Design by Contract’, Computer, Oct. 1992, pp. 40-52.
J. Warmer and A. Kleppe, The Object Constraint Language, Addison Wesley
Longman, Reading, Mass., 1998.
-- langages de description d'architecture
[ACN02]
[ADML00]
[DKM93]
[Gar95]
[GMW97]
[GP95]
[Mar01]
J. Aldrich, C. Chambers, D. Notkin, ArchJava: Connecting Software
Architecture to Implementation, ICSE 2002.
Open Group, Architecture Description Markup Language: ADML, 2000,
http://www.opengroup.org/architecture/adml/adml_home.htm
J. Dulay, N. Kramer, J. Magee, Structuring Parallel and Distributed
Programs, IEEE Software Engineering Journal, vol.8(N.2), pp.73-82, Mars
1993.
D. Garlan, An introduction to the Aesop System, School of Computer
Science, Carnegie Mellon University, Juillet 1995.
D. Garlan, R. Monroe, D. Wile, ACME : An Architecture Description
Interchange Language, Computer Science Department, Carnegie Mellon
University, Pittsburg et USC/information science institute, Novembre 1997.
D. Garlan and D.E Perry., Introduction to the Special Issue on Software
Architecture, IEEE Transactions on Software Engineering, 21 (4), April
1995, pp 269-274
R. Marvie, CODeX: proposition pour la description dynamique
d'architectures à base de composants logiciels, Actes de Journées
composants: flexibilité du système au langage, Octobre 2001, Besançon,
France.
© Projet ACCORD
25/29
[MT00]
[MTW96]
[RDTP97]
[SD02]
[SG96]
N. Medvidovic and R. N. Taylor, A Classification and Comparison
Framework for Software Architecture Description Languages, IEEE
Transactions on Software Engineering, Vol 26, no1, pp70-93, Janvier 2000.
N. Medvidovic, R. Taylor, E. Whitehead, Formal Modeling of Software
Architectures at Multiple Levels of Abstraction, Department of Information
and Computer Science, University of California, Irvine, Avril 1996.
Rapide Design Team Program Analysis and Verification Group Computer
Systems Lab Stanford University, Guide to the Rapide 1.0 Language
Reference Manual, Juillet 1997.
J.M. Soucé, L. Duchien, Etat de l’art sur les langages de description
d’architecture, Livrable 1 du projet RNTL ACCORD, 2002.
M. Shaw, D. Garlan, Software Architecture - Perspectives on an Emerging
Discipline, Prentice Hall, 1996.
-- langages de coordination
[AF00]
[AHS93]
[AP98]
[Beu00]
[CG92]
[CD99]
[Gün98]
[MC94]
[Sin92]
A. Andrade, J.L Fiadeiro, Evolution by contract, In ECOOP’00 Workshop on
Object Oriented Architectural Evolution, 2000, Position Paper.
F. Arbab, I. Herman and, P. Spilling ; An Overview of Manifold and its
Implementations. Concurrency: Practice and Experiences 5(1), 1993, pp.664677.
F. Arbab, G.A. Papadopoulos ; Coordination models and languages,
Software Engineering (SEN), SEN-R9834 December 31, 1998.
A.
Beugnard,
Communication
Services
as
Components
for
Telecommunication Applications, 14th European Conference on ObjectOriented Programming (ECOOP’2000), Objects and Patterns in Telecom
Workshop, Sophia Antipolis and Cannes (France), 2000.
N. Carriero, D. Gelernter ; Linda in context. Communication of the ACM 35
(2), 1992 pp. 97-107.
Juan Carlo Cruz, Stéphane Ducasse, Coordinating Open Distributed Systems,
Future Trends in Distributed Computing Systems ’99 FTDCS’99
Manuel Günter, Explicit Connectors for Coordination of Active Objects,
Master Thesis of Faculty of Science, University of Bern 1998
T. W. Malone and K. Crowston, The Interdisciplinary Study of Coordination,
ACM Computing Surveys 26, 1994, pp. 87-119.
B. Singh ; Interconnected Roles (IR): A Coordinated Model. Technical
Report CT–84–92, Microelectronics and Computer Technology Corp.,
Austin, TX, 1992.
-- UML
[CD01]
[DW99]
[EDOC01]
John Cheesman, John Daniels, UML Components – A Simple Process for
Specifying Component-Based Software, Addison-Wesley, 2001.
Desmond Francis D'Souza, Alan Cameron Wills, Objects, Components and
Frameworks with UML – The Catalysis Approach, Addison-Wesley, 1999.
OMG, A UML Profile for Enterprise Distributed Object Computing, Version
0.29, Document OMG, Juin 2001.
© Projet ACCORD
26/29
-- ODP
[ODP95]
[Put01]
ISO/IEC, Information Technology - Open Distributed Processing - Reference
Model, ISO/IEC 10746-1,2,3,4:1995 ou ITU-T X.901,2,3,4, 1995.
Janis R. Putman, Architecting with RM-ODP, Prentice-Hall, 2001.
-- EJB
[EJB01]
Sun Microsystems, Enterprise Java BeansTM Specification, Version 2.0, Sun
Microsystems, Août 2001.
-- CCM
[OMG01]
[MP01]
OMG, CORBA 3.0 New Components Chapters, Object Management Group,
Novembre 2001, OMG ptc/2001-11-03.
R. Marvie and M.-C. Pellegrini, Modèles de composants, un état de l’art,
Numéro spécial de L’Objet, 2001.
-- .NET
[DN01]
Microsoft, Microsoft .net Framework - Guide d'évaluation, Microsoft
Publishing, 2001
© Projet ACCORD
27/29
7 Liens Internet
-- composant
http://www.objenv.com/cetus/top_distributed_objects_components.html
CETUS
Component-Based Software Development / COTS Integration
http://www.sei.cmu.edu/str/descriptions/cbsd.html
Component Software Ressources
http://www.geocities.com/m_a_r_c_h/components.html
Modèles
http://iamwww.unibe.ch/~scg/Research/ComponentModels/
-- contrat
MEYER
TrustedCmp
http://www.eiffel.com/doc/manuals/technology/contract/page.html
http://trusted-components.org/
-- langages de description d'architecture
ACME
Aesop
C2
Darwin
MetaH
Rapide
SADL
UniCon
Wright
http://www.cs.cmu.edu/~acme/
http://www.cs.cmu.edu/afs/cs/project/able/www/aesop/
http://www.ics.uci.edu/pub/arch/
http://www.cs.cmu.edu/~darwin/
http://www.htc.honeywell.com/projects/dssa/dssa_tools.html
http://pavg.stanford.edu/rapide/
http://www.sdl.sri.com/programs/dsa/sadl-main.html
http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/UniCon/
http://www.cs.cmu.edu/~able/wright/
-- langages de coordination
Bookmarks
COOL
LINDA
Manifold
http://grunge.cs.tu-berlin.de/~tolk/coordbook.html
http://www.eil.utoronto.ca/profiles/rune/node7.html
http://www.cs.yale.edu/Linda/linda-lang.html
http://www.ercim.org/publication/Ercim_News/enw35/arbab.html
-- UML
en français
http://uml.free.fr/
UML2 work in progress
http://www.omg.org/techprocess/meetings/schedule/UML_2.0_Superstructur
e_RFP.html
catalysis
http://catalysis.org/
-- ODP
Introduction
http://lamswww.epfl.ch/RM-ODP/Default.htm
-- EJB
BEA WebLogic Server 7.0 http://www.bea.com/products/weblogic/server/index.shtml
Borland AppServer 5.0.1
http://www.borland.com/bes/appserver/
IBM WebSphere Application Server 4.0
http://www.ibm.com/websphere
© Projet ACCORD
28/29
-- CCM
Ressources
Général
K2-CCM
MICO/CCM
OpenCCM
http://corbaweb.lifl.fr/OpenCCM/CCM.html
http://ditec.um.es/~dsevilla/ccm
http://www.iCMGworld.com/
http://www.fpx.de/MicoCCM/
http://corbaweb.lifl.fr/OpenCCM/
-- .NET
Microsoft .NET http://www.microsoft.com/net/, http://msdn.microsoft.com/net et
http://www.gotdotnet.com (site géré par Microsoft)
Article de synthèse intitulé « Applying .Net to Web Services » :
http://www.webtechniques.com/archives/2001/05/jepson
Spécifications complètes soumises à l’ECMA (C#, CLI, base class library)
http://msdn.microsoft.com/net/ecma/site.zip
Portail français sur .NET réunissant de nombreux articles à
http://www.dotnet-fr.org
-- projets
ARCAD
MACAO
CASTOR
SALOME
EASYCOMP
PECOS
QCCS
COMBINE
http://www.industrie.gouv.fr/rntl/FichesA/Arcad.htm
http://www.industrie.gouv.fr/rntl/FichesA/Macao.htm
http://www.telecom.gouv.fr/rnrt/projets/pcastor.htm
http://www.opencascade.org/SALOME/
www.easycomp.org
www.iam.unibe.ch/~pecos
www.qccs.org
http://www.opengroup.org/combine/
© Projet ACCORD
29/29