la même interface.
Influencé par Spring, 2K est un projet mené par l’Université d’Illinois à Urbana-Champaign, qui repose sur une approche à composants et intergiciel [Kon et al. 1999, Román et al. 1999]. Il est consti- tué d’un micronoyau Off++ au-dessus duquel se trouve un ORB réflexif, dynamicTAO, par lequel les applications peuvent charger des composants pour le système. Off++ est un micronoyau orienté objet, réparti et adaptable, chargé d’exporter des ressources (matérielles) distribuées au système 2K. Il est possible de charger du code utilisateur dans le noyau pour améliorer les performances ou mettre à jour du code.
2.9
Conclusion
L’ensemble des choix d’implantation que l’on peut rencontrer lorsque l’on veut concevoir un sys- tème d’exploitation ou une infrastructure logicielle répartie forme un espace de conception illustré à la figure 2.26. Il faut décider si le système et les applications partagent le même domaine de protection comme dans un système à domaine de protection unique, sinon cela signifie l’utilisation d’un noyau. Il faut ensuite décider où s’exécutent les services du système : dans le noyau avec un noyau mono- lithique, dans des processus séparés avec un micronoyau, sous forme de librairie applicative avec un exonoyau. Il faut aussi décider si le noyau est extensible et éventuellement de façon sûre. Dans le cas d’une infrastructure logicielle répartie, il faut décider si le système fournit lui-même les services de communication ou s’ils sont fournis par une couche intergiciel séparée.
nanonoyau uChoices HAL micronoyau L4, QNX Chorus, Mach exonoyau Aegis env. d’exécution C, C++ machine virtuelle Java application Multimédia AIX, Solaris Linux noyau monolithique (extensible) O.R.B. Corba applicatif système d’exploitation intergiciel
système à domaine de protection unique Embarqués DOS, PalmOS ressources matérielles serveurs librairies systèmes application
FIGURE2.26 – Espace de conception
Comme nous l’avons vu dans ce chapitre, toutes les solutions ont des avantages et des inconvé- nients, qui en fonction de l’utilisation, peuvent être plus ou moins marqués. Le tableau 2.1 liste de façon synthétise les avantages et les inconvénients de chaque infrastructure système.
L’objectif principal de l’architecture de système nommée THINK, que nous allons voir dans le chapitre suivant, est de ne pas se limiter à un point de cet espace de conception. En d’autres termes, cette architecture doit être suffisamment flexible pour permettre de nous déplacer dans tout l’espace et
système à noyau micronoyau noyau exonoyau domaine unique monolithique extensible
protectiona − + + +bou −−c . efficacité ++ + −d + . flexibilité +e − + + + reconfiguration + − . . + dynamique simplicité de dév. . − + + .
ades services et du système
bpour les noyaux utilisant des techniques de « sandbox » ou de langage sûr c
si aucune technique de protection n’est utilisée ddû au coût des IPC
e
sous réserve que l’infrastructure le permette
TABLEAU2.1 – Analyse synthétique des infrastructures systèmes
de créer des instances de tous ces systèmes. Une instanciation de THINKse place clairement dans une philosophie de noyau extensible, mais il est possible de faire varier cette instanciation d’un système à domaine unique à un noyau monolithique en passant par un exonoyau. Dans une instanciation particulière, on retrouve les mêmes types de compromis et de caractéristique générales.
Chapitre 3
Architecture logicielle THINK
Ce chapitre présente l’architecture logicielle THINK1. Cette architecture comprend des concepts, des règles et des invariants de structure que l’on va aussi utiliser de manière systématique. Cette architecture clarifie l’organisation des systèmes d’exploitation et des infrastructures logicielles ré- parties. La formalisation de ces concepts permettra à terme de raisonner sur les systèmes. L’objectif de l’architecture est de fournir un cadre logiciel flexible permettant de construire des systèmes à la carte en intégrant uniquement les services requis. Ces services peuvent être soit standards, c’est-à-dire qu’ils sont pris sur étagère, ou spécifiques, c’est-à-dire qu’ils sont développés spécifiquement pour un système.
3.1
Objectifs de l’architecture
L’architecture logicielle THINKpermet de modéliser de façon uniforme les systèmes d’exploita- tion et les infrastructures logicielles réparties. L’architecture doit être suffisamment flexible et offrir des moyens pour couvrir tout l’espace de conception, vu à la figure 2.26, et laisser aux concepteurs de systèmes le choix des compromis satisfaisant aux contraintes des applications cibles, ils pourront pour cela s’aider du tableau 2.1. Un système THINK, c’est-à-dire un système conforme à l’architecture logicielle THINK, possède les caractéristiques suivantes :
• ouvert. Dans un système ouvert, toutes les interfaces sont explicites. Cela autorise l’inter fonc- tionnement et la portabilité des systèmes s’y conformant. Un tel système peut donc être déployé sur des architectures matérielles très hétérogènes.
• intégré. Un système est intégré s’il peut être construit, de façon simple et sans développe- ment ad hoc coûteux, à partir de différents sous-systèmes et différentes ressources. Cela peut comprendre des systèmes avec différentes architectures, différentes ressources et différentes performances.
• flexible. Un système est flexible s’il peut évoluer et s’accommoder, de façon dynamique ou de façon statique, aux changements pouvant survenir sur l’environnement du système.
• modulaire. La modularité est la propriété de bâtir un système par morceau. L’objectif est qu’en cassant un système complexe par morceau, la complexité devient plus facile à gérer. La mo-
1
THink Is Not a Kernel.
dularité est aussi la base de la flexibilité. Les dimensions d’un système modulaire sont non figées.
• administrable. Cette caractéristique permet à une ressource, logicielle ou matérielle, du système d’être observée, contrôlée et gérée en vue de supporter la configuration, la qualité de service et les différentes politiques.
• programmation uniforme. Le modèle de programmation uniforme de l’architecture est exploi- table en centralisé ou en réparti. Ce modèle de programmation uniforme offre la transparence vis-à-vis des problèmes causés par la répartition et facilite la construction d’applications répar- ties.
L’architecture logicielle THINKoffre le support minimum permettant de construire des systèmes ayant ces caractéristiques. Mais ces caractéristiques ne peuvent être obtenues si le concepteur de tout ou partie d’un système respecte les règles proposées par l’architecture. Dans le cas contraire, aucune garantie ne peut être avancée.
3.1.1 Ce qui n’est pas abordé
Un certain nombre de caractéristiques que l’on est en droit d’attendre d’une telle architecture ne sont actuellement pas traitées par l’architecture logicielle THINK. C’est notamment le cas pour les caractéristiques suivantes.
• sécurité. Un système sécurisé permet la protection des données et du système lui-même contre les éventuels accès non autorisés.
• sûreté. Un système est sûr de fonctionnement s’il est tolérant aux pannes qui peuvent survenir dans l’environnement.