Le Réseau Intelligent : 2 -vers l'architecture long terme SERENITE

Transcription

1 Le Réseau Intelligent : 2 -vers l'architecture long terme SERENITE Jean-Bernard Stéfani Jean-Bernard Stéfani, X 79, ENST 84, est responsable au Centre Paris A du CNET du groupe de recherche sur l'architecture de systèmes répartis. Il est président du groupe de travail traitement réparti ouvert à l'uit-t (ex-ccitt).

2 Le Réseau Intelligent : vers l'arc h i t e c t u re long terme SERENITE ( * ) Le Projet-CNET SERENITE est un exemple de futur Réseau Intelligent. Par rapport au réseau actuel, l'accent est mis sur la flexibilité sous différents aspects : capacité d'évolution en temps réel, prise en compte des impératifs de gestion, large compatibilité avec les applications inform a t i q u e s et les différents terminaux. Le travail d architecture sur le Réseau Intelligent est tout à fait incomplet (voir l article précédent de Roberto Kung), puisque les aspects gestion n ont pas vraiment été approfondis et qu une flexibilité globale est nécessaire au niveau du temps réel, mais aussi au niveau de la gestion du réseau, des applications informatiques et des terminaux. L approche orientée objet est une des voies prometteuses qui est explorée actuellement. D autre part, il est important de définir les mécanismes associés de gestion de données, car celles-ci imposent des contraintes sur les dialogues entre applications (il faut bien s échanger des informations), et qu'il faut assurer u n e cohérence globale au niveau du réseau. Le Projet-CNET SERENITE a donc exploré ces voies et défini une architecture qui se présente comme une spécialisation de l architecture de référence pour systèmes répartis hétérogènes, issue du projet Esprit ISA [3], et actuellement normalisée dans le cadre du modèle de référence ODP (Open Distributed Processing) de l ISO qui utilise une approche orientée objet. Les éléments clefs de l architecture, spécifiques du domaine, incluent la notion de réseau de transfert et les classes d objets de traitement associées, des fonctions de gestion de configuration, et des fonctions de gestion d information (données) réparties. L objectif de cet article est de présenter les éléments de l architecture SERENITE. Pour en faciliter la lecture, certaines parties plus techniques, qui peuvent aider à la compréhension, ont été rajoutées en petits caractères. Caractéristiques de l'architecture Une architecture plus globale est nécessaire pour traiter des aspects gestion du RI, et aussi de l interconnexion aux applications informatiques des opérateurs (telles que la facturation ou l affectation des ressources). Il faut aussi permettre l interconnexion de plusieurs réseaux. Un besoin essentiel est d abord de faciliter l interconnexion des applications (de gestion, informatique...). Par exemple, il faut toujours s interconnecter à une application de facturation, ou à une application de supervision du trafic du réseau. D autre part, il faut assurer une flexibilité de modification ou d introduction de nouvelles applications, à tous les niveaux : que ce soit au niveau temps réel, exemple pour introduire une nouvelle technologie de transport (comme le large bande), que ce soit au niveau de la commande du réseau, exemple pour introduire la mobilité, que ce soit au niveau de la gestion, exemple pour permettre à un usager de modifier certaines données de son service, que ce soit au niveau des applications informatiques, exemple pour facturer un nouveau service, que ce soit enfin au niveau des terminaux, exemple pour présenter à un client avec de la valeur ajoutée les informations fournies par le réseau (statistiques...). (*) Ce texte est basé sur un article publié par l auteur à De Nouvelles Architectures pour les Communications (DNAC 92).

3 La maîtrise de l ensemble de ces applications passe nécessairement par le développement d une architecture de système offrant les caractéristiques suivantes : ouverture : pour permettre la construction de systèmes à bases de composants hétérogènes (machines de traitement, réseaux, protocoles de communications, systèmes d exploitation, langages de programmation, etc.), et de garantir l indépendance vis-à-vis des fournisseurs de ces composants. L ouverture se manifeste par l interopérabilité (ouverture au sens de l OSI) et la portabilité ; variabilité ( scalability ) : pour permettre la construction de systèmes de taille quelconque, depuis des systèmes s appuyant sur un seul réseau de télécommunications (LAN, Local Area Network - MAN, Metropolitan Area Network - WAN, Wide Area Network) jusqu à des systèmes d envergure planétaire; évolutivité : pour permettre l évolution des systèmes au cours du temps, leur adaptation à des environnements différents, à des besoins utilisateurs différents. L évolutivité se manifeste notamment par la programmabilité et l existence de fonctions de reconfiguration dynamique ; fédération : pour permettre la coopération entre systèmes autonomes, gérés par des autorités distinctes, de divers types (administration, sécurité), appliquant des politiques d usage et de gestion différentes ; intégration : pour permettre la construction de systèmes cohérents et administrables comme des tout uniques, sans encourir les coûts requis par des développements ad hoc pour garantir l ouverture. Les divers travaux d architecture en cours au sein de l UIT-T (ex CCITT, organisme de normalisation pour les télécommunications) ne garantissent pas de telles propriétés : l architecture de Réseau Intelligent actuellement proposée à l UIT-T s appuie sur une structure physique donnée et des entités fonctionnelles (par exemple le SCF ou le CCF) liées à des configurations particulières. La première phase de cette architecture ( Capability Set One ) ne prend pas en compte les besoins d intégration d applications différentes comme celles d administration de réseau ou de services. Enfin, les projets de recommandation actuels ne prennent pas en compte des réseaux autres que les réseaux téléphoniques publics ; les travaux sur le réseau de gestion des télécommunications ( TMN ) considèrent simplement la définition de fonctions d administration. Rien n est dit sur la façon dont des applications peuvent être créées, s exécuter et évoluer au cours du temps. D une manière générale, dans les deux cas, rien n est dit sur la manière de garantir une pleine ouverture des systèmes, en garantissant interopérabilité et portabilité des applications. De plus, les conditions d intégration des différents travaux en un tout cohérent sont loin d être claires. Pour le long terme, le projet SERENITE s est de ce fait fixé comme objectif la définition d une architecture de système, intégrable à tout type de réseau de communications, et possédant les propriétés mentionnées ci-dessus. Bases de l'architecture L architecture SERENITE considère le système de télécommunications comme un système réparti ouvert, au sens de l ISO et de l UIT-T [1, 2], et le domaine des télécommunications comme un domaine d application du traitement réparti ouvert ( Open Distributed Processing ODP). Dans le cadre ODP, un système peut être considéré de plusieurs points de vue différents. Dans cet article, l accent est mis sur trois des points de vue ODP : le point de vue information : qui concerne la spécification et la manipulation d éléments, de modèles et de flux d informations. Ce point de vue fournit une vue abstraite (modèle d information) des fonctions et des capacités de traitement de l information d un système réparti ; le point de vue traitement : qui c o n c e r n e la programmation des applications réparties. Ce point de vue fournit un modèle de programmation pour applications réparties (modèle de traitement) : structures d applications, sémantique d exécution et de communication entre composants d application ; le point de vue ingénierie : qui concerne les mécanismes utilisés pour construire un système et les différentes fonctions offertes pour la mise en œuvre des applications réparties. Ce point de vue fournit la spécification d une machine abstraite (modèle d ingénierie) permettant la mise en œuvre du modèle de traitement. [1] Basic Reference Model of Open Distributed Processing - Part 2: Descriptive Model, CD , ISO/IEC, Ottawa, June [2] Basic Reference Model of Open Distributed Processing - Part 3: Prescriptive Model, JTC1/SC21 N 7055, ISO/IEC, Ottawa, June 1992.

4 L ensemble des modèles obtenus à partir de chaque point de vue constitue l architecture proprement dite. Dans ce papier, nous décrivons le modèle d ingénierie et le modèle de traitement de SERENITE et nous présentons quelques pistes concernant le modèle d information. Le modèle d ingénierie et le modèle de traitement apparaissent comme des spécialisations et des extensions des modèles correspondants issus du projet Esprit ISA [3], dont l objectif est la définition d une architecture ODP de référence. Ces différents modèles s appuient sur une notion générique d objet. Un objet est une unité de structure qui encapsule données et comportement. Chaque objet dispose d une ou plusieurs interfaces consistant en un ensemble d opérations. Une opération correspond à un point d entrée : les données encapsulées par un objet ne peuvent être lues ou modifiées par son environnement que par l intermédiaire d une opération. Une application répartie, ou un système, est ainsi considérée comme une collection d objets communiquant par l appel d opérations. Cette notion d objet, et les concepts de base associés, est définie précisément dans [1]. On pourra trouver dans [1] une définition précise des concepts de base (objet, interface, comportement, état, opération), ainsi que la définition d un ensemble de concepts de spécification élémentaires (tels que type, classe, t e m p l a t e, sous-type, instantiation, etc.). Modèle de traitement Le modèle de traitement adopté pour l architecture long terme SERENITE est essentiellement celui développé dans le cadre du projet Esprit ISA [4]. Dans ce modèle de traitement, une application consiste en une collection d objets communicants. Chaque objet dispose d un nombre quelconque d interfaces, éventuellement variable au cours du temps. Une interface dans le modèle est une entité de première classe, définie sous la forme d un ensemble d opérations, et éventuellement de contraintes de comportement associées sur leur invocation. Une interface est une unité de désignation dans ce modèle de traitement. Les références d interfaces sont utilisées comme arguments au cours d invocation d opérations, ou comme paramètres de retour d une invocation d opération. Les opérations sont de deux sortes : les interrogations et les annonces. Une interrogation retourne toujours une terminaison à l objet appelant après une invocation. Une annonce ne retourne jamais de résultat à l objet appelant. Une terminaison comprend un nom de terminaison couplé à un ensemble de paramètres sous la forme de références vers des interfaces. Les objets peuvent participer, en parallèle, à plusieurs activités. Une activité passe d un objet à l autre lors de l invocation par le premier objet d une opération sur une interface désignée du second. Quand une interrogation est invoquée, l activité à laquelle appartient l invocation (activité appelante) continue dans l objet invoqué, et retourne ultérieurement vers l objet appelant. Quand une annonce est invoquée, une nouvelle activité démarre dans l objet appelé, tandis que l activité appelante se poursuit dans l objet appelant. A l intérieur d un objet, une activité peut se scinder en plusieurs sous-activités parallèles. Le modèle offre au programmeur d application transparence d accès et transparence à la localisation : l invocation d opérations s effectue indépendamment de la situation de l objet invoqué. En particulier, l invocation d une opération sur une interface distante possède la même sémantique que l invocation de la même opération sur une interface locale. Le modèle de calcul est fortement typé. Le système de type est équipé d une relation de conformité entre types qui correspond aux conditions minimales à imposer pour garantir l interfonctionnement entre deux objets quand l un d eux est remplacé par un troisième (de type conforme). Le modèle de traitement ISA a été complété par des extensions synchrones pour la programmation de synchronisations temps réel [5]. Modèle d'ingénierie Le modèle d ingénierie de SERENITE est également directement inspiré de celui développé dans le cadre du projet ISA. Il comprend essentiellement deux parties : le réseau de transfert et le système de traitement. Le réseau de transfert consiste en un ensemble de ressources de télécommunications permettant le transport d information de bout en bout entre nœuds terminaux. La notion de réseau de transfert correspond à une abstraction et une formalisation de la notion de réseau de télécommunications. Cette notion de réseau de transfert peut, en principe, être appliquée à tout types de réseaux (réseaux téléphoniques standards, RNIS, RNIS large bande, réseaux de communication de données par paquets, réseaux métropolitains, etc). Le réseau de transfert connecte les utilisateurs du système de télécommunications. Un réseau de transfert peut avoir une topologie et une structure interne quelconque. En particulier, un réseau de transfert peut comprendre plusieurs sous-réseaux. Interconnecté au réseau de transfert, ou construit en utilisant les ressources et les fonctions offertes par le réseau de transfert, on trouve le réseau de transfert noyau. Le réseau de transfert noyau est un réseau de transfert spécialisé, qui assure les communications du système de traitement. [3] ESPRIT Project 2267 (Integrated Systems Architecture) - Advanced Networked Systems Architecture : ANSA Reference Manual release Architecture Projects Management Ltd, Cambridge, UK, November [4] ESPRIT Project 2267 (Integrated Systems Architecture) - Advanced Networked Systems Architecture : The ANSA Computational Model - Architecture Report AR Architecture Projects Management Ltd, Cambridge, UK, August [5] J.-B. Stéfani, L. Hazard, F. Horn : Computational model for distributed multimedia applications based on a synchronous programming language - computer communications, vol. 15 n 2, March 1992.

5 Les fonctions offertes par le réseau de transfert noyau sont en gros é q u i v a l e n t e s à celles offertes par le service de transport OSI (Open Systems Interconnection). Au contraire du service de transport OSI, le réseau de transport noyau doit permettre la communication de données de média de représentation différents (en particulier de média continus tels audio et vidéo) [6]. Le réseau de transfert noyau est une partie intégrante du système de traitement. Le système de traitement proprement dit est un système réparti ouvert. Il comprend un ensemble de sites totalement interconnectés par l intermédiaire du réseau de transfert noyau. Un site représente un ensemble de ressources de traitement de l information (telles que processeurs, périphériques de stockage, matériel de télécommunications, etc.) avec son logiciel de base (système d exploitation, protocoles de communication, base de données, etc.). Sur chaque site s exécute au moins un noyau. L ensemble des noyaux coopérants constitue un environnement réparti intégré, commun à l ensemble des sites, et permettant de mettre en œuvre des applications conformes au modèle de traitement. En d autres termes, l ensemble des noyaux coopérants constitue une machine abstraite pour le modèle de traitement. En particulier, le réseau de noyaux offre transparence d accès et transparence à la localisation comme services répartis de base. Chaque site dispose également d un gestionnaire de site et d un trader (voir aussi le chapitre suivant Environnement de service ). Les gestionnaires de sites offrent des fonctions élémentaires de gestion d objet et de gestion de configuration. Les traders fournissent collectivement un service de pages jaunes généralisé, facilitant la configuration et la reconfiguration dynamiques d applications. D autres services répartis tels que fonctions de sécurité, gestion de transactions ou autres transparences à la répartition (migration, duplication, etc.), peuvent être mis en œuvre au-dessus des nœuds, en fonction des besoins des applications. Cette structure abstraite peut être réalisée et implantée de multiples façons : le réseau de transfert noyau peut être réalisé sous la forme d un réseau de télécommunications classique comme un réseau de communication de données par paquets, le RNIS, ou le réseau de signalisation SS7. Il peut être implanté indifféremment comme un sousréseau du réseau de transfert ou comme un réseau de télécommunications indépendant du réseau de transfert (généralisant ainsi la notion de réseau de signalisation) ; un noyau peut être implanté sur plusieurs types de machines, PC ou mainframe, commutateurs, PABX ou multiplexeurs. Les sites sur lesquels sont implantés les noyaux du système de traitement peuvent ainsi très bien recouvrir l ensemble des processeurs du système (des multiplexeurs et commutateurs jusqu aux machines centrales de gestion). Dans ce modèle, l ensemble des noyaux interconnectés n est pas limité aux seuls équipements de réseau de l opérateur, et peut intégrer des systèmes utilisateurs. Ces derniers peuvent comprendre un ou plusieurs sites exécutant des noyaux connectés via le réseau de transfert noyau. Ce niveau d intégration offre des perspectives intéressantes pour l ouverture des systèmes de télécommunications aux fournisseurs de service tiers, et devrait s avérer très utile pour la mise en œuvre de services hautement interactifs. Spécification du réseau de transfert Le réseau de transfert fournit des services de base de transport d information entre nœuds terminaux. Des services plus complexes peuvent être construits, comme applications réparties s exécutant sur le système de traitement, à partir de ce service de base et des fonctions offertes par les ressources du réseau de transfert. Pour cela, ces fonctions doivent être accessibles des applications du système de traitement sous la forme d objets de traitement. L architecture long terme SERENITE comprend dans ce but un ensemble de classes d objet génériques, permettant la manipulation directe des ressources du réseau de transfert. Les différentes classes identifiées Port : un port est une interface sur un objet de communication (c est-à-dire un objet responsable de l acheminement d information entre deux ou plusieurs autres objets). Les opérations associées à un port permettent de l activer, de le désactiver, de demander un transfert d information, et de recevoir de l information précédemment transmise. Lien : un lien est un objet de communication représentant une fonction élémentaire de transfert d information entre deux nœuds du réseau de transfert (Cf nœud de réseau ci-dessous). Ce concept généralise la notion homonyme dans [7], et peut être utilisé, si besoin, pour représenter la notion de leg dans {IN}. Un lien peut disposer d au moins deux ports. Le nombre de ports d un lien peut varier dynamiquement. Connecteur : un connecteur est un objet de communication à l intérieur d un nœud du réseau de transfert et permettant de connecter deux ou plusieurs ports appartenant à des liens différents. Il s agit là d une généralisation du concept de point de connexion de [7]. Le concept de connecteur permet de modéliser tout type de fonctions de connexion. Un connecteur peut encapsuler également des fonctions d adaptation. Terminateur : un terminateur est un objet de communication à l intérieur d un nœud du réseau de transfert et permettant de connecter des ports appartenant à un ou plusieurs liens avec des ports utilisateur, c est-à-dire des interfaces utilisateur pour l accès aux média transportés par des liens. Le concept de terminateur est similaire aux notions de puits terminal et source terminale (termination sink, termination source) de [7]. Un terminateur peut encapsuler des fonctions d adaptation et des fonctions de terminaison de canal. Canal : un canal est un objet de communication de bout en bout du réseau de transfert. Les ports offerts par un canal sont des ports utilisateur. Un canal est composé de liens, de connecteurs et de terminateurs. Il généralise la notion de trail de [7]. Nœud de réseau : un nœud de réseau (ou nœud) est un objet gestionnaire d un ensemble de ports, de liens, de connecteurs, de terminateurs et de canaux. Il permet de modéliser les fonctions de gestion de configuration offerte dans le réseau de transfert. On peut considérer ce concept comme une abstraction des notions de commutateur ou de terminal. Les opérations associées à un nœud permettent de créer ou de détruire des liens, des connecteurs, des terminateurs, des canaux, et de manipuler les objets créés (par exemple opérations de connexion et de déconnexion), de les composer (par exemple liens) en objets de plus haut niveau (par exemple canaux). La fonction (ou le service) de base du réseau de transfert peut ainsi être décrite comme la fourniture de canaux. en utilisant ces classes d objet, il est ainsi facile de représenter le modèle de contrôle d appel de l ETSI (IN Connection Control Model) [8]. [6] A. Cambell, G. Coulson, F. Garcia, D. Hutchinson : A continuous media transport and orchestration service - Proceedings ACM SIGCOMM 92, Baltimore, USA, August [7] Draft IUT-T Recommendations G.sna1 and G.sna2 on Architectures, Performance and Management of transport networks based on the SDH, Geneva, [8] Intelligent Network: Framework, ETSI TR1-NA6 Report, Heathrow 1991.

6 Contrairement à ce modèle, toutefois, les concepts ci-dessous peuvent s appliquer à tout types de réseaux de télécommunications. Les comportements génériques associés aux différentes classes et leurs types précis sont encore en cours de définition. On pourra néanmoins trouver en appendice, les définitions de types correspondantes. Bien entendu, ces classes génériques doivent être affinées et spécialisées en fonctions des réseaux de transfert effectivement utilisés si l on veut pouvoir utiliser les fonctions spécifiques offertes par ces réseaux. A ce niveau de généricité, ces classes d objet peuvent cependant déjà s utiliser pour la construction de services de Réseau Intelligent indépendants des réseaux sous-jacents. Les différentes classes de base introduites dans cette section peuvent s appliquer récursivement. Par exemple, un lien peut être réalisé par un canal à un plus bas niveau d abstraction, et peut ainsi se décomposer en terminateurs, connecteurs et liens de niveau inférieur. Un nœud de réseau peut de manière similaire se décomposer en nœuds, liens, etc. de niveau inférieur. Si nécessaire, un réseau de transfert entier s abstrait sous la forme d un nœud de réseau unique (Cf discussion du global functional plane dans [9]). Environnement de services Un service dans l architecture SERENITE apparait, comme toute application répartie, comme une collection d objets coopérants. La conception et la réalisation d un service dans l architecture peut donc s appuyer sur l ensemble des services génériques fournis par l infrastructure de système réparti ODP sous-jacente. En particulier, on peut utiliser le trader (une traduction possible en français serait courtier ; en l absence d équivalent officiel, nous conserverons le terme anglo-saxon) pour disposer de fonctions de sélection d interfaces. La mise en place d un service se présente toutefois sous la forme suivante : un ou plusieurs utilisateurs, ayant éventuellement préalablement souscrit au service considéré, demandent la mise en place du service. Cette demande s accompagne en général de la spécification d un ou plusieurs autres utilisateurs, qui interviendront au cours de l exécution du service ; après analyse de la requête, le système configure les ressources nécessaires pour la mise en place du service demandé. Cela peut impliquer la réservation de ressources de communication particulières (par exemple choix de points de diffusion dans un service multi-utilisateurs). Pour permettre l exécution d un tel schéma, on peut s appuyer sur une généralisation de la fonction trader et introduire la notion de gestionnaire de service. Le trader SERENITE continue de jouer essentiellement le même rôle de sélection d interfaces mais l opération de requête (opération import) comporte maintenant deux types de paramètres : des paramètres identifiant la nature du service demandé ; des paramètres identifiant différents rôles liés au service demandé (typiquement, autres interfaces dans le système devant participer au service). Le rôle du trader devient double dans ce schéma : identifier et retourner à l importateur les interfaces susceptibles de remplir les différents rôles demandés ; identifier un gestionnaire de service correspondant au service demandé. L interface d un gestionnaire de service comprend essentiellement les opérations suivantes : enroll : cette opération permet à un objet d indiquer son intention de participer à un service dans un rôle donné ; activate : cette opération permet l activation synchronisée du service, une fois qu un nombre suffisant de rôles est rempli (via invocations de l opération enroll) ; resign : cette opération permet à un objet antérieurement enrôlé de signifier son retrait du service ; terminate : cette opération permet la terminaison synchronisée du service. En général, l activation d un gestionnaire de service va se traduire par différentes actions de gestion de ressources : au niveau du réseau de transfert, plusieurs canaux doivent être établis pour permettre l exécution du service demandé (cas typique d une multiconférence). Les canaux établis dépendront notamment des caractéristiques et de la localisation des différents sites impliqués, ainsi que des besoins requis pour l exécution du service ; au niveau applicatif, la mise en œuvre du service peut nécessiter la réservation de certaines ressources de traitement, par exemple des bases de données ou des fonctions de traitement spécialisées. L ensemble trader, gestionnaire de service constitue un environnement générique pour la mise en place de services. Affiner cet environnement en fonction de grandes classes de services (en spécialisant les gestionnaires de service) devrait permettre de faciliter leur déploiement. Fonctions de gestion de données Les classes d objet introduites dans les sections précédentes doivent être complétées avec des fonctions de gestion de données pour assurer une couverture intégrée des besoins applicatifs dans un système de télécommunications. En effet, de nombreux services de Réseau Intelligent requièrent l accès à des bases de données spécialisées, et les fonctions d administration de système s organisent essentiellement autour de fonctions de gestion de données (Management Information Bases). Les fonctions de gestion de données sont prises en compte dans l architecture en définissant des objets particuliers, appelés conteneurs de données (ou conteneurs en abrégé). Un conteneur de données est une abstraction d un système de gestion de base de données. Un conteneur de données contient des informations organisées selon le modèle d information retenu. Une interface conteneur offre essentiellement les opérations suivantes : query : cette opération permet d accéder aux informations du conteneur. Elle prend comme paramètre une requête exprimée dans le(s) langage(s) de manipulation de données du modèle d information ; update : cette opération permet d effectuer des mises à jour des informations du conteneur. Elle prend comme paramètre des instructions de modification (insertion, suppression, mise à jour) exprimées dans le(s) langage(s) de manipulation de données offerts du modèle d information. [9] Draft IUT-T Q.12xx Intelligent Network Recommendations, Geneva 1991.

7 En l état actuel des choses, le modèle d information de l architecture n est pas entièrement défini. En particulier, langage de définition de données et langage de manipulation de données ne sont pas définis. On dispose néanmoins de quelques pistes les concernant. Le langage de description de données sera orienté objet afin de fournir une modélisation directe du système (lui-même construit selon une base objet). Une première approximation des capacités de description de ce langage est fournie par le modèle de traitement et son système de type : en effet, pour permettre une intégration sans faille entre modèle de traitement et modèle d information, le système de type du langage de définition de données devra avoir comme sous-ensemble le système de type du modèle de traitement. Au-delà, on peut considérer que le langage de définition de données comprendra des constructeurs de collections d objets (comme ensemble, liste, sac, etc.) et des relations entre objets. Dans un premier temps, pour simplifier l architecture, les objets données (i.e. les instances des classes décrites à l aide du langage de définition de données) sont purement passifs : leur comportement est trivial et ne leur permet pas d invoquer des opérations sur d autres objets. En conséquence, un accès à un conteneur de données ne peut entraîner, comme effet de bord, un accès à d autres objets du systèmes. De ce fait, le maintien de la cohérence entre les informations contenues dans un conteneur de données et le reste du système est facilité, mais il reste entièrement à la charge du programmeur d application. Un problème ouvert de l architecture consiste justement à offrir des outils génériques efficaces de maintien de cohérence globale de l information dans le système, conduisant à une intégration et une transparence d accès aux données plus parfaites. Un conteneur de données peut très bien être réparti sur plusieurs sites. D une manière générale, la notion de conteneur de données encapsule des fonctions de gestion de base de données spécifiques, qui peuvent ou non s appuyer sur les différents services répartis offerts par l architecture (par exemple, fonctions de gestion de transactions). En l état actuel de la technologie, ce découplage, même s il est préjudiciable à l intégration, permet une optimisation des réalisations tout en préservant la cohérence de l architecture. En particulier, toutes formes d optimisation sont permises pour la réalisation d un conteneur de données, sans avoir d impact sur le reste de l architecture. On peut ainsi envisager des conteneurs de données de réalisations et de propriétés très diverses, selon les besoins des applications utilisatrices (performances, coûts, résistance aux pannes, etc.). Pour plus d information, le lecteur pourra lire les articles [10, 11]. Conclusion Nous avons esquissé dans ce papier l architecture long terme du projet SERENITE. Le modèle d ingénierie et le modèle de traitement ont été brièvement décrits ; quelques idées de départ pour le modèle d information et la gestion de données ont été suggérées. En l état actuel des choses, des spécifications détaillées de ce qui a été présenté dans ce papier sont disponibles. Mais l architecture est loin d être complète, et plusieurs points nécessitent des travaux supplémentaires : le modèle de traitement n est pas complet. Le modèle ANSA [4] dans sa version actuelle ne permet pas une programmation d applications temps réel (c est-à-dire d applications dans lesquelles apparaissent explicitement des contraintes liées au temps physique), et en particulier ne permet pas l expression de contraintes de qualité de service. Même si des premiers t r a v a u x dans cette direction ont été effectués (Cf [5]), il reste beaucoup à faire ; le modèle d ingénierie, hérité d ANSA, souffre également de certaines déficiences pour la mise en œuvre d applications proprement temps réel. Là encore des travaux sont en cours, notamment au sein d ANSA, pour y remédier ; le modèle d information est pour l instant quasiment inexistant : seules existent quelques pistes de réflexion solides (et quelques contraintes sur la forme que devrait prendre un tel modèle) ; les classes de base pour le réseau de transfert méritent d être validées par application et spécialisation à des réseaux existants, en particulier RNIS large bande, et par utilisation pour la conception d exemples de services. A l heure actuelle, un simulateur réparti a été réalisé, qui a permis de vérifier l utilisation de ces classes sur quelques services simples, mais l expérience en la matière reste limitée. enfin, l environnement de service demande à être affiné. La notion de gestionnaire de service est une notion complexe (en particulier si l on veut considérer la réalisation réparti d un tel gestionnaire) qui demande à être affinée. De plus il faudrait compléter l environnement par des outils d aide semi-automatiques pour la génération de programmes d administration de services à partir de leurs spécifications fonctionnelles. Pour plus d information sur l architecture SERENITE, le lecteur pourra lire les articles [10, 11, 12]. L architecture SERENITE n est pas la seule architecture étudiée. D autres architectures analogues sont en cours de définition. Aussi un consortium mondial appelé TINA (Telecommunication Information Networking Architecture) a été mis en place depuis le début de l année pour définir une architecture unique. Une grande partie des idées de l architecture SERENITE ont été reprises dans TINA. Le lecteur pourra se référer aux articles publiés dans les quatre colloques TINA (en 1990 au Lake Mohonk, Etats-Unis, en 1991 à Chantilly, France, en 1992 à Narita, Japon et en 1993 à l Aquila, Italie) ou en 1992 à ISS92 (Yokohama, Japon). [10] J.-B. Stéfani et Y. Lepetit, SERENITE, TINA 93, L Aquila. [11] F. Dupuy, Y. Lepetit, B. Nicolas, Data management in an ODP-conformant telecommunication information network, TINA 93, L Aquila. [12] G. Brégant, R. Kung, Y. Lepetit et J.-B. Stéfani, The evolution of network: towards more integrated Architecture, ISS 92, Yokohama.