Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
UNIVERSITE PARIS 6 - PIERRE ET MARIE CURIE
U.F.R DE SCIENCES
THESE DE DOCTORAT DE L’UNIVERSITE PARIS 6
Spécialité :
Réseaux Informatiques
présentée par
Tuan Loc NGUYEN
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITE PARIS 6
Sujet de la thèse
Archises - Nouvelle Architecture pour la Création de Services à valeur ajoutée
dans la Téléphonie sur IP
Soutenue le 9 septembre 2004, devant le jury composé de :
Francine KRIEF Rapporteur Professeur à l’Université Bordeaux 1 Bernard COULETTE Rapporteur Professeur à l’Université Toulouse 2 Guy PUJOLLE Directeur de thèse Professeur à l’Université Paris 6 Jean-Marc GEIB Examinateur Professeur à l’Université de Lille 1 Dominique GAÏTI Examinateur Professeur à l’Université de Troyes Alix MUNIER Examinateur Professeur à l’Université Paris 12
UNIVERSITE PARIS 6 - PIERRE ET MARIE CURIE U.F.R DE SCIENCES
THESE DE DOCTORAT DE L’UNIVERSITE PARIS 6
Spécialité :
Réseaux Informatiques
présentée par
Tuan Loc NGUYEN
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITE PARIS 6
Sujet de la thèse
Archises - Nouvelle Architecture pour la Création de Services à valeur ajoutée
dans la Téléphonie sur IP
Soutenue le 9 septembre 2004, devant le jury composé de :
Francine KRIEF Rapporteur Professeur à l’Université Bordeaux 1 Bernard COULETTE Rapporteur Professeur à l’Université Toulouse 2 Guy PUJOLLE Directeur de thèse Professeur à l’Université Paris 6 Jean-Marc GEIB Examinateur Professeur à l’Université de Lille 1 Dominique GAÏTI Examinateur Professeur à l’Université de Troyes Alix MUNIER Examinateur Professeur à l’Université Paris 12
Ne baissez pas les bras
Quand parfois rien ne veut s’arranger Quand la route, pénible, continue de monter Quand les fonds sont en baisse, les dettes amoncelées Quand vous voulez sourire et que vous soupirez Quand tout vous presse et que vous êtes surmenés Faites une pause, mais ne baissez pas les bras. La vie est surprenante avec ses volte-face Chacun de nous un jour l’a constaté Maints échecs en succès ont été transformés Celui qui est en tête est parfois dépassé Ne baissez pas les bras, bien que l’allure soit lente Un petit vent nouveau peut vous faire triompher. Le but est bien souvent à portée de la main De l’homme fatigué, affaibli et chancelant Il arrive au vainqueur parfois de renoncer, Alors que la victoire est au bout du chemin C’est après qu’il comprend mais hélas trop tard, Combien il était près de la couronne d’or ? Le succès, c’est l’échec qui change soudain de cap Et contourne très loin les nuages du doute Et nul ne peut rien dire si le but se rapproche. Il peut être tout près alors qu’il semble loin Plongez dans la bagarre lors que vous êtes en tête Et lorsque tout va mal ne baissez pas les bras. [Auteur inconnu]
A mon père, Ton Ba Nguyen, ma mère, Thi Phuoc Truong,
mon frère, Tuan Anh Nguyen.
1
REMERCIEMENTS D’abord, je tiens à remercier mes parents de m’avoir énormément encouragé et soutenu pendant la réalisation de cette thèse. Je tiens à remercier mon professeur Monsieur Guy Pujolle de m’avoir accueilli dans son équipe de recherche, d’avoir dirigé mes travaux de recherche avec patience et intérêt mes travaux. Egalement, Monsieur Hongloc Nguyen, qui fut mon responsable au début de ma thèse à Matra Nortel Communications et Madame Odile Fernandez de sa gentillesse et de m’avoir encadré dans son équipe R&D à EADS-Télécom. Je tiens à remercier sincèrement Madame Francine Krief, Professeur à l’Université Bordeaux 1 et Monsieur Bernard Coulette, Professeur à l’Université Toulouse 2 le Mirail, d’avoir accepté d’être rapporteurs. J’en suis très honoré. J’adresse mes remerciement à Madame Alix Munier, Professeur à l’Université Paris 6, à Madame Dominique Gaïti, Professeur à l’Université de Troyes, à Monsieur Jean-Marc Geib, Professeur à l’Université de Lille 1 pour avoir accepté d’être membre de mon jury de thèse et tous les bons conseils qu’ils m’ont donnés. Je voudrais également remercier mes collègues, mes amis du Lip6 et d’EADS-Télécom R&D pour leur accueil chaleureux, l’ambiance amicale et aussi d’être resté avec moi, si tard, de nombreuses soirées. Je tiens à remercier plus particulièrement Phong Nhien Hung Tran, Bao Tran Tran, Hai Quan Nguyen, Gilbert Sawma, Jocelyne Elias, Tony Tite, Khi Van Thai, Morsi Berguiga pour leurs nombreux conseils et pour leur soutien. Enfin, je suis très heureux d’avoir bien accompli ce travail aujourd’hui. Un grand merci pour tous.
Résumé 3
Résumé Archises (Architecture of Intelligent Semantic Services) : Nouvelle Architecture pour la Création de Services à valeur ajoutée dans la Téléphonie sur IP.
Ce travail propose d’explorer une architecture intitulée Archises (Architecture of Intelligent Semantic Services) : l'architecture d'intermédiation intelligente. Ce nouveau concept s’inspire du concept d'intermédiation et des architectures « intelligentes » venant du monde d’Internet et des Télécommunications. Le concept d’intermédiation préconise la fédération des services qui permettra d’ajouter de la valeur en combinant différents services fournis par les producteurs. Le niveau d'intermédiation permettra également aux terminaux de différents types d'accéder à divers types de services. Les architectures intelligentes préconisent la séparation de la logique de services et du traitement de services. Cette séparation permet le développement de nouveaux services sans être obligé de modifier et de mettre à jour les codes dans ces systèmes de plus en plus complexes.
Les principales recherches dans Archises vont du réseau intelligent des systèmes de télécommunications à l’architecture Web Services en passant par les techniques classiques d’assemblage de composants : interfaces de programmation, contraintes architecturales, protocoles et fonctions, objets et composants réutilisables, interactions entre des composants.
Plus particulièrement, Archises permet de créer rapidement de nouveaux services à valeur ajoutée dans la téléphonie sur IP, un des domaines importants de l’informatique du futur. En fait, la téléphonie sur IP n'est pas moins chère, ni meilleure, ni différente de la téléphonie classique. Donc l’arrivée de la téléphonie IP sur le marché est un défi difficilement surmontable. L'une des solutions pour résoudre ce problème est de combiner le service téléphonique IP avec d'autres services classiques du monde IP, tels que le Web, la messagerie électronique … Le nombre de services à valeur ajoutée dans la téléphonie sur IP résultant de cette combinaison peut croître de manière exponentielle grâce à l'application du nouveau concept de réseau intelligent d'intermédiation Archises.
La recherche dans le domaine du logiciel est concentrée sur la méthodologie de conception et sur la conception du logiciel. La recherche dans le domaine des réseaux s’est basée sur la communication entre des systèmes et la gestion des performances des communications. Archises est donc une jonction entre deux mondes : logiciel et réseau.
Résumé 5
Abstract Architecture of Intelligent Semantic Services (Archises) : New Architecture for Service Creation in the Telephony over IP.
What will the Internet look like in the future? How will one program or one service interact with one another ? How will a new service in the network be rapidly created? That why we propose a new architecture Archises (Architecture of Intelligent Semantic Services). Its goal is to explore the new concept of intelligent intermediation networking resulting from the integration of the Internet intermediation concept and the intelligent network concept of the telecommunications world. The intelligence of service occurs in the heart of the traditional telecommunications networks and the advancement of the Internet intermediation involves the displacement of the intelligence at the edge of the network. This new architecture of services will be progressively validated and refined by the experimentation of a prototype developed all along this thesis.
Archises proposes to realize a prototype, which allows to refine the intermediation services architecture, by integrating the more representative servers of the Internet of the future, such as SIP telephony server, LDAP directory, Web server, DBMS. Archises is motivated by the desire to create and evaluate the architectural design of network-based application software through principled use of the telecommunications intelligent network, the Web Services architecture and the classical techniques of service assembly like architectural constraints, protocols, functions, objects and reusable composants, the interaction among theses composants.
More particularly, Archises can create new value-added services in the IP telephony, one of the important domains in the future. It is neither cheaper nor better than the classical telephony, but its difference is to combine the IP telephony service with the other services in the IP world like Web, email, messenger … to create the value-added services.
This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate on system behavior. Networking is concentrated in the communication between systems and improving the performance of communication techniques. Archises is the junction of software and networking. The main objective of Archises is the simplification of development of value-added services in any network. End-users do not care about technology. Value is in services.
Table des matières 7
TABLE DES MATIÈRES
« Comment créer les services meilleurs aux tarifs les plus bas avec des exigences de qualité de service toujours plus grandes »
REMERCIEMENTS................................................................................................. 1
Résumé ........................................................................................................................ 3
Abstract....................................................................................................................... 5
TABLE DES MATIÈRES ........................................................................................ 7
TABLE DES FIGURES.......................................................................................... 13
Chapitre 1 : Introduction générale............................................................ 15
1.1 Contexte de création rapide de nouveaux services............................................................15
1.2 Notre approche - la naissance Archises ..............................................................................17
Chapitre 2 : Etat de l’art.................................................................................. 21
2.1 Concept d’Intermédiation....................................................................................................21 2.1.1 Objectif de l’intermédiaire .................................................................................................21 2.1.2 Avantages et inconvénients du concept d’intermédiation.................................................23 2.1.3 Intermédiaire vers infomédiaire (cyber-intermédiaire) .....................................................24
2.1.3.1 Présentation d’infomédiaire .....................................................................................24 2.1.3.2 Théorie économique: nouveaux coûts de transaction et nouveaux intermédiaires 25
2.1.4 Intelligence dans l’Intermédiation (modèle OSI)..............................................................30 2.1.5 Intermédiation dans la littérature .......................................................................................31
2.1.5.1 Concept Portail de Yahoo!.......................................................................................31 2.1.5.2 Cocoon......................................................................................................................33
2.1.5.2.1 Présentation Cocoon ...........................................................................................33 2.1.5.2.2 Objectif de Cocoon .............................................................................................34 2.1.5.2.3 Avantages de Cocoon : .......................................................................................34 2.1.5.2.4 Inconvénients de Cocoon....................................................................................35 2.1.5.2.5 Conclusion...........................................................................................................35
2.1.5.3 Concept de BEA (Quick Silver, Liquid computing)...............................................35
8 Table des matières
2.1.5.4 Hub d’information (système des compagnies aériennes) ....................................... 36 2.1.6 Conclusion du concept d'Intermédiation ........................................................................... 37
2.2 Composant & Réseau Intelligent ........................................................................................ 39 2.2.1 Réseau intelligent & recommandation Q12xx (UIT-T).................................................... 39 2.2.2 Le modèle de réseau intelligent : ....................................................................................... 41 2.2.3 Réseau Intelligent & Composant....................................................................................... 43
2.2.3.1 Composant SIB (Service Independent Building Block) ......................................... 43 2.2.3.2 Les 14 SIBs de base dans le réseau intelligent........................................................ 44 2.2.3.3 Le processus d’assemblage des SIBs ...................................................................... 44 2.2.3.4 Evaluation de SIB .................................................................................................... 45
2.2.4 Conclusion de réseau intelligent........................................................................................ 47
2.3 Assemblage de composant ................................................................................................... 49 2.3.1 Définition de composant.................................................................................................... 49 2.3.2 Composant & Programmation en langage modulaire (Basic) .......................................... 54
2.3.2.1 Description de programmation modulaire............................................................... 54 2.3.2.2 Module (composant) = interfaces + corps + initialisation (variables).................... 55
2.3.3 Composant & Programmation en langage fonctionnel (C, Pascal) .................................. 56 2.3.3.1 Description de la Programmation en langage fonctionnel...................................... 56 2.3.3.2 Composant (service)=objets-nom+messages.......................................................... 57
2.3.4 Composant & Programmation orientée objet (C , Java)++ ................................................. 57 2.3.4.1 Rappel du langage d’objet : ..................................................................................... 57 2.3.4.2 service (composants )=objets-nom+messages ........................................................ 58
2.3.5 Composant & Programmation orientée composant (C#).................................................. 59 2.3.5.1 Composant vs Objet................................................................................................. 59 2.3.5.2 service (composants)=components+scripts+glues.................................................. 60 2.3.5.3 Composant dans la programmation orientée composant vs composant dans la programmation orientée objet...................................................................................................... 60
2.3.6 Composant & Web Services (.NET, J2EE) ...................................................................... 61 2.3.6.1 Description Web Services........................................................................................ 61 2.3.6.2 Web Services (composants)=http+composant =SOAP + composant + WSDL ....64
2.3.7 Transformation & composant............................................................................................ 64 2.3.7.1 Définition de transformation.................................................................................... 64 2.3.7.2 Feuille de style XSLT.............................................................................................. 65 2.3.7.3 Evaluation de XSLT ................................................................................................ 66
2.3.8 Conclusion sur l’assemblage de composant...................................................................... 66
2.4 Architectures intelligentes pour la création de services ................................................... 68 2.4.1 Framework .NET 2.x de Microsoft ................................................................................... 68
2.4.1.1 Evolution de système opération & présentation de Framework .NET................... 68 2.4.1.2 Pourquoi le framework.NET ?................................................................................. 69 2.4.1.3 Moteur d’assemblage « Commun Runtime Language » ........................................ 69
2.4.1.3.1 Définition du moteur Visual Studio.NET CLR ................................................. 69 2.4.1.3.2 MSIL (Microsoft Intermediate Language)......................................................... 70 2.4.1.3.3 Architecture.NET................................................................................................ 71 2.4.1.3.4 Assemblage de composants dans .NET.............................................................. 71
2.4.1.4 Conclusion de .NET................................................................................................. 73 2.4.2 JAIN-Sun (Java Advanced Intelligent Network) – un modèle appliqué de réseau intelligent........................................................................................................................................... 74 2.4.3 CTI (Couplage Téléphonie Informatique)......................................................................... 75 2.4.4 Conclusion sur les architectures intelligentes ................................................................... 77
Table des matières 9
Chapitre 3 : Architecture Archises............................................................. 79
3.1 Architecture n-tiers d’Archises ...........................................................................................79
3.2 Architecture Archises détaillée............................................................................................81 3.2.1 Présentation ........................................................................................................................81 3.2.2 Connecteur (virtual application) ........................................................................................84 3.2.3 Transformateur & enrichissement .....................................................................................84
3.2.3.1 Mécanisme de transformation Archises ..................................................................84 3.2.3.2 Langage de transformation de service .....................................................................85
3.2.4 Déclencheur (ou triggering)...............................................................................................86 3.2.5 Moteur d’assemblage d’Archises ......................................................................................88 3.2.6 Adapter à tout type de terminal..........................................................................................91
3.3 Environnement de Création de Services ............................................................................93 3.3.1 Le besoin d’un environnement de création de services dans Archises.............................93 3.3.2 Les acteurs dans le processus de création de services.......................................................93 3.3.3 RSCE – environnement de création rapide de nouveaux services....................................94 3.3.4 Langage SCDL (Service Creation Description Language) de création de services.........96 3.3.5 Les mécanismes d’Archises écrits en SCDL...................................................................101
3.3.5.1 SCDL dans le mécanisme de transformation ........................................................101 3.3.5.2 SCDL dans le mécanisme de déclenchement........................................................104
3.4 Services à valeur ajoutée dans Archises ...........................................................................105
3.5 Fonctionnement des mécanismes dans Archises .............................................................114
3.6 Conclusion............................................................................................................................123
Chapitre 4 : Implémentation pour valider Archises ......................................... 126
4.1 Veilles technologies..............................................................................................................127 4.1.1 SIP Session Initiation Protocol [wSIP]............................................................................127
4.1.1.1 Présentation SIP .....................................................................................................127 4.1.1.2 Principe de fonctionnement de SIP........................................................................128 4.1.1.3 Conclusion de SIP..................................................................................................130
4.1.2 XML (méta-langage) & Web Services............................................................................131 4.1.2.1 Introduction XML..................................................................................................131 4.1.2.2 Pourquoi XML a-t-il été choisi comme le langage de base dans des mécanismes de base d’Archises ?........................................................................................................................132
4.1.3 LDAP................................................................................................................................132 4.1.3.1 Présentation LDAP ................................................................................................132 4.1.3.2 Création de nouveaux services avec LDAP ..........................................................133 4.1.3.3 Conclusion de LDAP .............................................................................................134
4.1.4 Langage PML (Phone Markup Language)......................................................................135
4.2 Implémentation pour valider Archises.............................................................................136 4.2.1 Transformation de services ..............................................................................................136
4.2.1.1 Objectif ...................................................................................................................136 4.2.1.2 Contexte de l’implémentation................................................................................136 4.2.1.3 Architecture de l’implémentation du connecteur LDAP ......................................136 4.2.1.4 Agent LDAP...........................................................................................................138
4.2.1.4.1 Opération BIND................................................................................................138
10 Table des matières
4.2.1.4.2 Opération UNBIND..........................................................................................139 4.2.1.4.3 Opération SEARCH..........................................................................................139
4.2.1.5 Agent services LDAP ............................................................................................140 4.2.1.6 Formatage d'un écran pour l'affichage...................................................................142
4.2.1.6.1 Ajout de l'intrusion............................................................................................143 4.2.1.6.2 Transformation en message XML....................................................................144 4.2.1.6.3 Transformation en écran logique......................................................................144 4.2.1.6.4 Transformation d'affichage...............................................................................145 4.2.1.6.5 Traduction des labels ........................................................................................146
4.2.1.7 Traitement d'un message ascendant ......................................................................146 4.2.1.8 Exemple de la recherche d'un abonné ...................................................................147
4.2.2 Création de services d’Archises ......................................................................................148 4.2.2.1 Objectif...................................................................................................................148 4.2.2.2 Mécanisme de fonctionnement..............................................................................148 4.2.2.3 Mise en œuvre de la fonction.................................................................................149 4.2.2.4 Plate-forme de test .................................................................................................150 4.2.2.5 Exemple : fichiers PML utilisés pour les testes ....................................................151
4.3 Conclusion............................................................................................................................152
Chapitre 5 : Architecture généralisée .......................................................153
5.1 Définition des termes ..........................................................................................................153 5.1.1 Composant .......................................................................................................................153
5.1.1.1 Composant classique..............................................................................................154 5.1.1.2 Composant d’Archises...........................................................................................154
5.1.2 Assembleur (glue)............................................................................................................155 5.1.3 Déclencheur (triggering-script) .......................................................................................156 5.1.4 Adaptateur ........................................................................................................................157 5.1.5 Architecture (framework de test).....................................................................................157
5.2 Service d’Archises...............................................................................................................158 5.2.1 Service..............................................................................................................................158 5.2.2 Service intelligent ............................................................................................................159
5.2.2.1 Intelligence.............................................................................................................159 5.2.2.2 Service intelligent ..................................................................................................159
5.3 Service intelligent avec sémantique d’Archises...............................................................160 5.3.1 Sémantique.......................................................................................................................160 5.3.2 Service intelligent avec sémantique ................................................................................160 5.3.3 Service d’Archises - “Intelligent Semantic Service” ......................................................161
5.4 Conclusion............................................................................................................................162 5.4.1 Archises = inter-services + intra-services........................................................................162 5.4.2 Service = composant(s) + architecture + [assembleur(s)] + [adaptateur(s)] + [(déclencheur(s)] .............................................................................................................................163
Chapitre 6 : Conclusion et Perspectives ...................................................164
6.1 Conclusion............................................................................................................................164
6.2 Evaluation ............................................................................................................................165
Table des matières 11
6.3 Perspectives..........................................................................................................................165 6.3.1 Voitures intelligentes en réseau .......................................................................................166 6.3.2 Domaine de gestion dans les réseaux ..............................................................................168 6.3.3 Archises appliquée dans le réseau de capteurs ................................................................168
Bibliographie .......................................................................................................... 170
Articles.................................................................................................................................................170
Brevets .................................................................................................................................................174
Ouvrages .............................................................................................................................................174
RFC......................................................................................................................................................175
Web......................................................................................................................................................176
Thèses ..................................................................................................................................................179
Acronymes .............................................................................................................. 180
Annexe A : grammaire du langage SCDL.......................................................... 184
Annexe B (4.2.1) : recherche d’un abonné.......................................................... 191
Annexe C (4.2.2) : fichiers PML utilisés pour les tests ...................................... 205
12 Mots-clés
Mots-clés : Composant, service à valeur ajoutée, création de services, XML, architecture, réseau intelligent, Archises, intermédiation, téléphonie sur IP.
Key words : Composant, value-added service, service creation, XML, architecture, intelligent network, Archises, intermediation, telephony over IP.
Table des figures 13
TABLE DES FIGURES Numéro Page Figure 1 : Service partout … ..................................................................................................16 Figure 2 : Revenu des services à valeur ajoutée dans ToIP...................................................18 Figure 3 : Concept d’Intermédiation ......................................................................................22 Figure 4 : Service à valeur ajoutée dans l’Intermédiation .....................................................23 Figure 5 : Cyber-intermédiaire ...............................................................................................26 Figure 6 : Intelligence dans l’Intermédiation .........................................................................31 Figure 7 : Service à valeur ajoutée dans Intermédiation........................................................31 Figure 8 : My Yahoo! .............................................................................................................32 Figure 9 : Cocoon....................................................................................................................33 Figure 10 : Liquid Computing................................................................................................35 Figure 11 : Hub d’information ...............................................................................................37 Figure 12 : Réseau classique vs réseau intelligent.................................................................40 Figure 13 : Modèle de réseau intelligent................................................................................42 Figure 14 : Composant SIB ....................................................................................................44 Figure 15 : Processus d’assemblage des SIBs .......................................................................45 Figure 16 : Services dans le réseau intelligent .......................................................................47 Figure 17 : Assemblage de composants dans le réseau intelligent........................................48 Figure 18 : Comparaison les types de composant..................................................................49 Figure 19 : Chaîne d’assemblage dans littérature ..................................................................50 Figure 20 : Composant dans la machine à laver ....................................................................53 Figure 21 : Objet vs composant..............................................................................................59 Figure 22 : Web Services........................................................................................................62 Figure 23 : Web Services – SOAP - UDDI ...........................................................................63 Figure 24 : Modèles de services .............................................................................................63 Figure 25 : XSLT....................................................................................................................64 Figure 26 : Prix minimum et bon design pour composant ....................................................67 Figure 27 : Evolution des langages et l’OS............................................................................68 Figure 28 : Intelligence dans l’évolution des technologies ...................................................69 Figure 29 : Architecture .NET & CLR...................................................................................70 Figure 30 : MSIL & assemblage de composants en .NET ....................................................71 Figure 31 : Assemblage de composants dans .NET ..............................................................72 Figure 32 : JAIN .....................................................................................................................74 Figure 33 : CTI........................................................................................................................75 Figure 34 : Intelligence dans l’architecture x-tiers ................................................................80 Figure 35 : Architecture Archises...........................................................................................82 Figure 36 : Connecteur d’Archises.........................................................................................84 Figure 37 : Moteur d’intégration d’Archises .........................................................................85 Figure 38 : Transformation dans Archises .............................................................................86 Figure 39 : Mécanisme de déclenchement (triggering) d’Archises ......................................87 Figure 40 : Mécanisme de déclenchement (triggering) d’Archises ......................................87 Figure 41 : Assemblage des fonctions d’Archises.................................................................88
14 Table des figures
Figure 42 : Moteur d’assemblage et d’intégration d’Archises ..............................................89 Figure 43 : Adaptation à tout type de terminal d’Archises ...................................................91 Figure 44 : Adaptation à tout type de terminal d’Archises ...................................................91 Figure 45 : Terminal très simple ............................................................................................92 Figure 46 : Créateur de service...............................................................................................94 Figure 47 : Création de services.............................................................................................94 Figure 48 : Processus de création de services........................................................................95 Figure 49 : Rapid Service Creation Environment..................................................................96 Figure 50 : Schéma pour le langage SCDL .........................................................................100 Figure 51 : SCDL..................................................................................................................101 Figure 52 : Mécanisme de déclenchement...........................................................................104 Figure 53 : Architecture Archises ........................................................................................107 Figure 54 : « Portal Manager » d’Archises..........................................................................110 Figure 55 : Adaptation à tout type de terminal ....................................................................120 Figure 56 : Transformation...................................................................................................124 Figure 57 : « Triggering » ....................................................................................................124 Figure 58 : « Triggering » ....................................................................................................125 Figure 59 : SIP ......................................................................................................................128 Figure 60 : Fonctionnement de SIP......................................................................................129 Figure 61 : Les codes de messages SIP................................................................................129 Figure 62 : Transaction de SIP.............................................................................................130 Figure 63 : LDAP .................................................................................................................133 Figure 64 : Fonctionnement de LDAP.................................................................................133 Figure 65 : LDAP d’Archises...............................................................................................137 Figure 66 : Transformation d’Archises................................................................................142 Figure 67 : Agrégation de services dans Archises...............................................................143 Figure 68 : Plate-forme de l’implémentation du concept d’Archises .................................149 Figure 69 : Configuration matérielle de la plate-forme de validation d’Archises ..............151 Figure 70 : Composant .........................................................................................................154 Figure 71 : Composant d’Archises.......................................................................................155 Figure 72 : Assembleur (glue)..............................................................................................156 Figure 73 : Service d’Archises .............................................................................................158 Figure 74 : Chaîne d’assemblage d’Archises ......................................................................159 Figure 75 : Service intelligent avec sémantique ..................................................................160 Figure 76 : « Intelligent Semantic Service » d’Archises .....................................................161 Figure 77 : Intra-services et inter-services d’Archises ........................................................162 Figure 78 : Perspective d’Archises.........................................................................................165 Figure 79 : Un modèle de voiture intelligente de demain (Microsoft) ...............................166 Figure 80 : Evolution dans les voitures .................................................................................167 Figure 81 : Voitures intelligentes en réseau.........................................................................167 Figure 82 : La gestion dans le réseau téléphonique.............................................................168 Figure 83 : Capteurs (Sensor)...............................................................................................168 Figure 84 : Archises pour le réseau de capteurs ..................................................................169 Figure 85 : Service à valeur ajoutée d’Archises ..................................................................204
1.1 Contexte de création rapide de nouveaux services 15
Chapitre 1 :
Introduction générale 1.1 Contexte de création rapide de nouveaux
services Dans le passé, quand un client demandait un nouveau service, l’opérateur de
réseaux devait demander à l’équipementier de réseaux (ou de services) de fournir de
nouveaux paramètres dans les réseaux ou de créer ou de modifier leur système pour
pouvoir satisfaire à cette demande. Du coup, le temps nécessaire pour avoir un
nouveau service était trop long car l’équipementier devait changer le comportement
du système. De plus, les opérateurs dépendaient fortement de leurs fournisseurs car
ils sont seuls à être capables de modifier les réseaux. En principe, le délai d’attente
pour introduire un nouveau service était trop long (de trois à cinq ans) et ne
permettait pas à l’opérateur de réagir rapidement (de trois à six mois) pour proposer
un nouveau service dans le contexte fortement concurrentiel du marché
actuel. Evidemment, le fournisseur se trouvait dans une position forte permettant de
facturer très cher les services demandés.
L’environnement de services des opérateurs de télécommunications est aujourd’hui
particulièrement complexe avec l’intégration de services très divers provenant du
monde d’Internet (figure 1). Cette complexité provient du mariage entre les
télécommunications et l’informatique. Le réseau intelligent autour du réseau
téléphonique classique a longtemps été le vecteur de cette intégration et a permis un
certain succès à ce mariage avec l’arrivée de services comme la carte prépayée ou le
numéro vert. Cependant, il faut noter que la modification ou la création d’un
nouveau service nécessittait la modification de tous les nœuds du réseau qui sont
des commutateurs très complexes et difficilement programmables. D’ailleurs, les
fournisseurs de services ont toujours tendance à développer des services
propriétaires suivant leurs propres normes. Ces contraintes rendent les
16 Chapitre 1 : Introduction générale
modifications et la création de nouveaux services difficiles et très longues (dix huit
mois pour modifier les paramètres d’un service ou trois ans pour en créer un
nouveau). Ces délais sont bien évidemment incompatibles avec les délai de mise sur
le marché de ces services compte tenu du caractère très concurrentiel du marché des
télécommunications. De plus, ces services sont très coûteux du fait de la complexité
et du nombre de commutateurs à modifier dans le réseau.
Figure 1 : Service partout …
Au cours des années 90, l'Europe occupait une position forte dans le secteur des
télécommunications mais la généralisation d'Internet a introduit une rupture sans
précédent, avec une redistribution des rôles et une modification de la chaîne de
valeur. En particulier, nous allons assister à l'ère des services toujours meilleurs
aux tarifs les plus bas avec les exigences de qualité de service les plus grandes. Il
faut donc rechercher des moyens rapides et économiquement rentables pour
satisfaire à cette demande. Face à la forte concurrence du marché, il faut faire vite
avec les moyens simples [wONE].
1.2 La naissance Archises 17
1.2 Notre approche - la naissance Archises C'est dans ce contexte que nous essayons de proposer une architecture s’appelant
Archises (Architecture of Intelligent Semantic Services). Archises permet
d’explorer une nouvelle architecture de services : l'architecture d'intermédiation
intelligente. Ce nouveau concept s’inspire du concept d'intermédiation et des
architectures «intelligentes» venant du monde d’Internet et des
télécommunications.
Le concept d’intermédiation préconise la fédération des services, qui permet
d’ajouter de la valeur en combinant différents services fournis par les producteurs.
Le niveau d'intermédiation permet également à des terminaux de différents types
d'accéder à différents types de services. Les architectures intelligentes telles que
.NET de Microsoft [wDotNET], le CTI [aChouCTI] et JAIN de Sun [wJain]
préconisent la séparation de la logique de services et du traitement de services. Elles
permettent le développement de nouveaux services sans être obligé de modifier et
mettre à jour le système qui est de plus en plus complexe.
Archises est une architecture neutre, ouverte, basée sur les standards et sur des
composants réutilisables. Elle a pour but de créer de nouveaux services aux tarifs
les plus bas avec des exigences de qualité de service les plus grandes. L’objectif à
long terme d’Archises est de placer l’intelligence dans la couche applicative du
modèle OSI.
Archises consiste à étudier et à proposer une nouvelle méthode de création rapide
de nouveaux services notamment dans la téléphonie sur IP. La recherche dans le
domaine du logiciel est concentrée sur la méthodologie de conception et la
conception du logiciel. La recherche dans le domaine des réseaux s’est basée sur la
communication entre des systèmes et la gestion des performances des
communications. Archises est donc une jonction entre deux mondes : logiciel et
réseau. Les principales recherches menées dans Archises vont du réseau intelligent
des systèmes de télécommunications à l’architecture Web Services en passant par
18 Chapitre 1 : Introduction générale
les techniques classiques d’assemblage de composants : interfaces de
programmation, contraintes architecturales, protocoles et fonctions, objets et
composants réutilisables, interactions entre des composants.
Ce concept d’Archises est expérimenté dans le contexte d’un projet de recherche
entre l’Université Paris 6 et EADS-Télécom. Il a pour but de valider Archises
dans le contexte de la téléphonie sur IP. Nous avons utilisé Archises pour créer de
nouveaux services dans la téléphonie sur IP (ToIP), un domaine était encore
nouveau lorsque nous avons mené ce travail. La figure 2 illustre le pourcentage de
revenu des services à valeur ajoutée dans la téléphonie sur IP qui tient une part très
importante dans le revenu global de le ToIP.
Figure 2 : Revenu des services à valeur ajoutée dans ToIP
(Source: Gartner/Dataquest/Bhwani Shankar/ Voice on the Net/ 03/2000)
Archises permet de créer rapidement de nouveaux services, ce qui donne la valeur
ajoutée dans la téléphonie sur IP. En fait, la téléphonie sur IP n'est pas moins chère,
ni meilleure, ni différente de la téléphonie classique, donc l’arrivée de la téléphonie
sur IP sur le marché est un défi difficilement surmontable. L'une des solutions pour
résoudre ce problème est de combiner le service téléphonique IP avec d'autres
1.2 La naissance Archises 19
services classiques du monde IP, tels que le Web, la messagerie électronique, … Le
nombre de services à valeur ajoutée et ses revenus résultant de cette combinaison
peut croître de manière exponentielle grâce à l'application du nouveau concept de
réseau intelligent d'intermédiation Archises.
Pour résumer, cette thèse contribue à la recherche l’architecture Archises pour
créer de nouveaux services à valeur ajoutée dans les réseaux. En plus, il
contribue le framework d’Archises implémenté dans la téléphonie sur IP pour
valider le concept d’Archises via des composants réutilisables et des contraintes
d’architecture. Enfin, ce travail permet d’élargir le concept d’Archises pour devenir
une architecture « universelle » dans le futur afin de résoudre d’autres problèmes
dans le domaine des réseaux.
La présente thèse est organisée en six chapitres :
Le chapitre 2 présente l’état de l’art en passant par les techniques d'intermédiation,
les techniques d’assemblage de composants puis les architectures intelligentes.
Celles-ci ont pour but de créer de nouveaux services de manière plus rapide.
Dans ce chapitre, on compare les différentes techniques comme les composants du
réseau intelligent, les composants dans la programmation modulaire, les
composants dans la programmation fonctionnelle, les composants dans la
programmation orientée objet et finalement les composants du nouveau
paradigme Web Services [wWebServices] [aFron]. Plus spécifiquement, une partie
de ce chapitre est consacrée à l’environnement de création de services en passant
par des modèles connus existants tels que SCE (Service Creation Environment) du
réseau intelligent, le modèle JAIN de SUN, le modèle dotNet de Microsoft et le CTI
et aussi le langage de lien SCDL [aNGUYEN ICCCN02] permettant de créer
rapidement de nouveaux services.
Le chapitre 3 décrit l’architecture Archises (Architecture of Intelligent Semantic
Services) que nous avons définie et réalisée pour résoudre le problème de la
20 Chapitre 1 : Introduction générale
création de nouveaux services. Ceci est aussi un framework pour pouvoir tester les
nouveaux services à valeur ajoutée.
Le chapitre 4 illustre notre framework d’Archises par une étude sur un cas réel.
Cette étude de cas a été fournie par Nortel Networks via une plate-forme de création
de services dans la téléphonie sur IP pour déployer de nouveaux services. Elle vise
à valider le concept d’Archises en montrant qu’il marche et que c’est un concept
très utile et ouvert. Ceci est réalisé au travers de deux implémentations : la première
montre comment enrichir l’information XML à partir d’une source donnée et la
deuxième montre comment assembler les services à valeur ajoutée via un serveur
Web, un téléphone IP et un serveur Archises.
Le chapitre 5 essaie d’élargir le contexte de création de services du concept
d’Archises en ouvrant une équation plus générale pour créer n’importe quel
service dans le futur que l’on appelle « l’équation universelle » :
Service = composant(s) + architecture + [assembleur(s)] + [adaptateur(s)] +
[déclencheur(s)]
Le chapitre 6 présente notre conclusion et nos perspectives. Nous présentons les
avantages apportés par notre approche dans le domaine de la création de nouveaux
services à valeur ajoutée. Ce chapitre ouvre un nouveau contexte pour appliquer le
concept d’Archises dans d’autres domaines de recherche en Informatique : les
voitures intelligentes en réseau, la gestion dans les réseaux, le réseau de capteurs.
2.1 Concept d’Intermédiation 21
Chapitre 2 : Etat de l’art
2.1 Concept d’Intermédiation 2.1.1 Objectif de l’intermédiaire
La préoccupation historique de l'espèce humaine est la recherche de l'énergie, que
ce soit l'alimentation, les matières premières ou les moyens de transport.
Aujourd'hui, on observe un basculement de la préoccupation principale des humains
vers l'information. C'est la nouvelle économie : « la Net économie » [aKart].
Aux prémices d’Internet, la Net économie a conçu le phénomène de
dé-intermédiation traditionnelle entre l'offre et la demande. Les consommateurs
accédaient directement aux fournisseurs ou les fournisseurs avaient des relations
directes avec des autres fournisseurs.
Avec le temps, les informations disponibles se multiplient ; la nouvelle Net
économie apparaît [oMesserchmitt 03] dans laquelle les consommateurs et les
fournisseurs n'interagissent plus directement mais plutôt à travers un niveau
d'intermédiation, [aBerrett] qui permet de produire une valeur ajoutée en combinant
les différents services proposés par les fournisseurs [wInFutur]. La figure 3 montre
le concept d’Intermédiation.
Le nouveau concept d’intermédiaire en information permet aux fournisseurs de
capter les informations, de les gérer, de leur donner un maximum de valeur ajoutée
et de fidéliser et développer une clientèle en lui offrant des prestations de plus en
plus larges et de plus en plus sophistiquées. Les nouveaux services seront ainsi
réalisés de plus en plus vite et coûteront de moins en moins cher.
On s’aperçoit que les intermédiaires peuvent créer la valeur ajoutée de différentes
manières : en mettant à disposition de nouvelles informations, en mettant en valeur
22 Chapitre 2 : Etat de l’art
cette information, en assemblant différentes informations. Au début du siècle, la
voiture s'est développée grâce à une approche de masse : la même voiture pour tous,
au meilleur prix. Au fur et à mesure que le marché est devenu mature, l'industrie
automobile est passée d'une logique de produit de masse à une logique de
personnalisation de masse.
Figure 3 : Concept d’Intermédiation
Le progrès des technologies de l'information a été un des principaux moteurs de
cette évolution. Dans l'Internet, cette évolution est clairement visible et la capacité à
personnaliser la relation avec un utilisateur deviendra un critère de plus en plus
déterminant de différentiation entre services concurrents. Si aujourd'hui, la logique
dominante est celle du marché de masse : prix peu cher que possible, produit quasi-
unique, on observe déjà que l’intermédiation est orientée vers l'apparition d'une
certaine personnalisation tels que My Yahoo!, MyAOL. Le concept
d'intermédiation aujourd’hui ne permet pas à un terminal très simple de fonctionner
facilement de différentes manières comme téléphoner, consulter des services
2.1 Concept d’Intermédiation 23
spécialisés comme la météo, naviguer sur le Web ou sur le WAP et de recevoir les
notifications de la messagerie, de l'agent boursier ou du système d'alarme de la
maison.
2.1.2 Avantages et inconvénients du concept d’intermédiation
Le concept d’intermédiation permet de créer rapidement le service à valeur
ajoutée [oMesserchmitt 03]. De plus, il permet de gagner du temps pour développer
de nouveaux services grâce à la sélection de l’information et de regrouper les
différents acteurs du même secteur.
La figure 4 illustre une définition de service à valeur ajoutée dans le concept
d’Intermédiation. Par exemple, un service à valeur ajoutée peut être créé par
l’agrégation entre plusieurs services de base. Par exemple, comme l’indique dans la
figure 4, si on combine du lait et du chocolat pour fabriquer du cacao, le cacao est
un service à valeur ajoutée grâce au concept d’intermédiation.
Figure 4 : Service à valeur ajoutée dans l’Intermédiation
En revanche, il y a encore des inconvénients dans le concept d’intermédiation car il
nécessite au préalable une confiance dans lesinformations fournies par le
fournisseur d’intermédiation comme Yahoo!. Par exemple, les portails tels que
Yahoo!, AOL ne sont pas très précis au niveau de la recherche. Un client cherchant
les informations pour ses vacances, ayant des enfants et aimant les loisirs à
24 Chapitre 2 : Etat de l’art
extérieur, peut utiliser l’intermédiation connaissant son profil qui lui proposera des
vacances dans les montagnes ou autres plutôt que les informations génériques.
2.1.3 Intermédiaire vers infomédiaire (cyber-intermédiaire) 2.1.3.1 Présentation d’infomédiaire [oHagel] [wMontculier]
Dès le début de la généralisation d’Internet, des observateurs ont fait valoir que le
réseau mettrait à mal toutes les entités faisant office d'intermédiaires entre des
fournisseurs et des consommateurs (distributeurs, revendeurs, agents, etc.) car le
réseau facilite très largement le contact direct entre ces deux catégories d'acteurs
économiques.
La valeur ajoutée des intermédiaires n'est donc plus la simple mise en relation et la
consignation de transactions ; l'une des stratégies possible de survie, pour eux, c'est
de se transformer en « infomédiaire » : en intermédiaire d'échange d'informations.
Les informations dont il s'agit sont surtout celles concernant l'identité et les
préférences du consommateur, dont la connaissance permet aux fournisseurs de
personnaliser leur offre.
Le rôle de l'infomédiaire est de favoriser la communication par le consommateur de
ces informations qu'il revendra à des fournisseurs, en lui offrant des garanties
solides sur l'usage qui en sera fait et lui apportant en échange un service à valeur
ajoutée.
Si c'est là le sens principal du terme, celui-ci peut s'appliquer aussi à
l'intermédiation d'informations entre consommateurs : lorsque les vendeurs en ligne
de livres, disques et vidéos donnent la possibilité à chaque internaute de donner son
avis sur un de ces produits culturels, une valeur ajoutée de conseil par des pairs
(d'autres consommateurs) est ainsi créée.
2.1 Concept d’Intermédiation 25
2.1.3.2 Théorie économique: nouveaux coûts de transaction et nouveaux intermédiaires
Comment expliquer en termes économiques la croissance des intermédiaires
Internet ? On pronostique souvent la chute des intermédiaires devant la poussée de
l’Internet et les possibilités de contact direct entre producteurs et acheteurs. Il est
certain que de nombreuses strates vont disparaître. Les clients ne voudront plus
payer les x % du prix final d’un bien qui correspondent aux marges des grossistes et
des détaillants si des moyens d’information et de distribution efficaces sont mis en
place par les producteurs.
On suppose premièrement que l’Internet réduisera à zéro tous les coûts de
transaction (recherche, achat, surveillance…), et deuxièmement que les transactions
entre agents seront simples et non décomposables.
En réalité, les coûts de transaction ne tendent pas systématiquement vers zéro avec
les nouvelles technologies de l’information, Internet en particulier. Des
intermédiaires sont renforcés ou émergent du fait même que tous les coûts de
transaction ne tendent pas vers zéro. Supposons un schéma simple à trois agents (un
producteur, un acheteur, un intermédiaire) et à deux périodes : sans Internet et avec
Internet) et regardons la variation des coûts de transaction entre la première période
et la seconde. Soit T1, le coût de la transaction directe entre le producteur et
l’acheteur et T2 la somme des coûts de transaction issus de la relation producteur-
intermédiaire et de la relation intermédiaire-acheteur. En passant de la première
période à la seconde, quatre cas de figure sont théoriquement possibles selon que T1
est < ou > à T2 (sans Internet) et que T’1< ou > à T’2 (avec Internet) (figure 5).
1. Dans la première case, il reste efficace pour les producteurs de garder des liens
directs avec les consommateurs, l’Internet apparaît « parallèles» au marché direct
(exemple d’un marchand de pizza qui se fait connaître sur l’Internet et qui garde
une relation directe au consommateur).
26 Chapitre 2 : Etat de l’art
2. Le scénario 2 est celui des intermédiaires menacés par une réduction des coûts de
commercialisation directe, encourageant le court-circuitage de la distribution
traditionnelle (par exemple, la vente de vin sur l’Internet met en difficulté les
grossistes et les négociants ; la vente de CD fait concurrence aux magasins
spécialisés).
Figure 5 : Cyber-intermédiaire
3. Le cas 3 représente la situation où apparaissent des cyber-intermédiaires
(infomédiaire). Ce sont des intermédiaires qui se créent à partir d’économies
d’échelle et de taille. Au milieu des années 1980, des chercheurs du MIT ont
annoncé l’avènement de « créateurs de service » électroniques.
La thèse d’économistes américains du MIT au milieu des années 1980 : les
technologies de l’informations conduisent vers des relations plus marchandes (et par
la même vers des « créateurs de service ») et moins hiérarchiques entre acteurs
économiques.
2.1 Concept d’Intermédiation 27
L’Internet a réduit fortement ces vingt dernières années les délais ainsi que les coûts
de traitement et de transport de l’information. L’Internet rend à la fois la
coordination par le « marché » et la coordination par la « hiérarchie » (à l’intérieur
d’une entreprise, ou entre deux entreprises lorsque le fournisseur est unique) des
partenaires plus efficaces, mais ils conduisent globalement à un renversement vers
une plus grande coordination par le marché (service).
Le cœur de l’argumentation des auteurs peut être résumé comme suit : la diminution
des coûts de coordination avantage plus le marché que la hiérarchie puisque le
marché est plus fortement consommateur d’efforts en coordination. Les marchés
deviennent plus attractifs.
Forme organisationnelle Marché Hiérarchie
Coûts de production Faible Fort
Coûts de coordination (interfaces) Fort Faible
Toutefois, il demeure des motifs de création des hiérarchies électroniques. Il existe
encore de nombreux cas où l’on rencontre de fortes spécificités d’actifs et des
descriptions de produits complexes pour lesquels la hiérarchie électronique est
souhaitable. Il s’agit notamment du développement et de la distribution du produit.
Comme exemple de ce basculement vers les marchés électroniques, les auteurs
choisissent les réservations dans les transports aériens. En raison du plus grand
éventail de choix disponibles sur le marché électronique, la part dans le total des
réservations effectuées par les agences de voyage a fortement augmenté par rapport
aux réservations directes auprès des compagnies aériennes. Les « créateurs de
service » devraient se multiplier [aMalone].
4. La case 4 montre la situation où des liens existants sont pris en charge par
l’Internet (exemple des réseaux électroniques mis en place par les grossistes
répartiteurs dans la distribution du médicament).
28 Chapitre 2 : Etat de l’art
Les grossistes répartiteurs: des intermédiaires qui ont permis une baisse des coûts de
transaction grâce à un réseau d’information et de distribution efficace. Par exemple,
les grossistes répartiteurs ont proposé de nouveaux services aux pharmacies et fait
baisser les coûts de transaction. Le réseau électronique entre grossistes et détaillants
a généré des économies de coûts de transaction : le nombre de personnes en charge
des commandes a diminué de 60 % en dix ans, les pharmaciens ont pu réduire
considérablement leurs stocks et le temps passé à traiter des commandes.
Les grossistes ont pu proposer des services à valeur ajoutée destinés aux
pharmaciens : information sur les médicaments, aide à la gestion d’une officine,
conseils sur la publicité, les investissements, les traitements informatiques.
Le réseau opérationnel est devenu un réseau stratégique : les fabricants ont obtenu
des informations fiables sur les médicaments, cette transmission d’information
permet de négocier dans des conditions plus favorables avec l’Etat.
Les grossistes européens ne devraient pas disparaître à court terme : il y a eu
concentration des grossistes et hausse de leur rentabilité. Les grossistes ont anticipé
la stratégie des fabricants et ont atteint une taille équivalente en fusionnant avec
leurs homologues européens et mondiaux. Les grossistes ont développé une
stratégie internationale en acquérant des médicaments à l’étranger.
Il y a peu d’avantages à procéder par transactions directes entre pharmaciens et
laboratoires : les prix sont fixés par l’Etat et compte tenu de la contrainte
d’universalité d’approvisionnement et de la variabilité des commandes, les gains
commerciaux issus d’une fonction de courtage du réseau restent limités. Rappelons
que le maillon des grossistes génère une valeur ajoutée de l’ordre de 7% avec un
profit estimé à 2,5 % [source www.01net.com].
Un autre exemple pour le cas 4, il s’agit du système de distribution classique de
Fnac et le site Web www.fnac.fr. Il est claire que les deux sont complémentaires et
à court terme, les boutiques de Fnac ne disparaîtront pas mais existeront en parallèle
avec le site Web. Semblablement, le site www.sncf.com créé en 2000 est devenu le
2.1 Concept d’Intermédiation 29
premier site d’e-commerce en ligne en France. Les agences classiques de SNCF
vont toujours exister à court terme même si le site représente 11% du chiffre
d’affaire de la société [source journée BEA-SNCF 11/6/2004].
Le cas 3 correspond à une relation directe transformée en relation d'infomédiaire
sur l’Internet. L’Internet génère de nouveaux coûts de recherche, de vérification sur
la fiabilité des sources… Il entraîne de nouveaux coûts de transaction et fait donc
émerger de nouveaux acteurs, notamment celui de créateur de services qui va jouer
un rôle central dans l’information dans les années à venir car il détient les outils
pour assembler, les moyens pour fédérer des informations, etc.
De plus, les intermédiaires ne fournissent pas un service simple et unifié. Si on
résume le rôle d’un intermédiaire à une activité simple de coordination, on agrège et
on sous-estime les services réellement rendus. De façon générale, les intermédiaires
rendent service au consommateur en assumant des fonctions : de recherche et
d’évaluation, d’identification des besoins ; de sélection des biens et services en
fonction de ces besoins, de prise en charge du risque consommateur (garanties,
retour des articles…), de distribution du produit… Ils rendent service aux
producteurs en disséminant l’information sur les produits, en influençant l’achat ; en
remontant l’information sur les consommateurs en assumant une partie du risque
producteur (vol, fraude, stocks…) et en générant des économies d’échelle sur les
coûts de transaction. Finalement, ils procèdent à une intégration des besoins des
consommateurs et des producteurs et produisent un bouquet de services qui
équilibre les souhaits des producteurs et des consommateurs via un module
d’intégration.
Cette analyse a le mérite de rendre compte de la diversité des scénarios après
introduction de l’Internet. Tous les intermédiaires ne sont pas menacés, et un
nouveau type d’intermédiaire émerge, le cyber-intermédiaire (infomédiaire).
Toutefois, elle repose entièrement sur l’hypothèse de minimisation des coûts de
transaction. Dans la réalité, les entreprises cherchent plutôt à maximiser le profit.
Elles ne considèrent pas uniquement les mécanismes de coordination avec les
30 Chapitre 2 : Etat de l’art
consommateurs et les autres entreprises, mais aussi les mécanismes de production
qu’elles cherchent à réorganiser.
Prenons l’exemple du site www.sncf.com, on aperçoit une tendance très forte de ce
site car il est en train de migrer du cas 4 vers le cas 3 cités au-dessus, c'est-à-dire ce
site va de plus en plus loin que nous avons imaginé au début. Actuellement, le site
propose non seulement les billets classiques mais également des billets d’avion, la
réservation d’hôtel, la location de voiture. Ceux-ci sont faits par des partenaires qui
offrent les interfaces standardisées comme les Web services. La SNCF reste
toujours dans son métier de base pour des billets de train, mais il a un acteur en
interne dans son architecture du site www.sncf.com : le créateur de service qui joue
le rôle essentiel, le rôle central. Il permet d’agréger et d’appeler une grande variété
de services venant d’autres fournisseurs de service. Cette idée sera reprise dans
l’architecture Archises que nous allons proposer dans la contribution.
Que voulez-vous de plus quand vous arrivez à une ville, il y a une voiture qui vous
attend et vous pouvez vous-même la conduire vers l’hôtel ayant déjà réservé avec
votre confort personnel ?
2.1.4 Intelligence dans l’Intermédiation (modèle OSI)
Nous essayons de chercher dans le modèle OSI, quelle est la position de
l’infomédaire ? En fait, en comparant entre le modèle Web/XML basé sur TCP/IP
et le modèle que nous voyons sur Internet actuellement, on s’apperçoit que le
modèle d’infomédiaire est une extension du modèle OSI. Dans le modèle OSI,
l’intelligence de réseau se trouve dans la couche 3 (couche réseau). Il a pour but de
garantir une personne à un service précis. L’approche d’intermédiation préconise
une intelligence entre la couche 7 applicative et la couche 6 présentation (figure 6).
Il a pour but d’assembler et de créer un nouveau service via la chaîne d’assemblage
de composants.
2.1 Concept d’Intermédiation 31
Figure 6 : Intelligence dans l’Intermédiation
En fait, le modèle OSI place l’intelligence du réseau dans la couche 3 (réseau) ce
qui permet de garantir la communication, la QoS dans le réseau. En revanche, le
modèle OSI+ qui lui place l’intelligence du réseau dans la couche 7 application
permet de savoir à quel type de client (via son profil) pour l’offrir les meilleurs
services dont il a besoin. L’intelligence de la couche 7 permet de créer des
nouveaux besoins [tBuranarach].
La figure 7 illustre les services à valeur ajoutée dans le concept d’Intermédiation.
Figure 7 : Service à valeur ajoutée dans Intermédiation
2.1.5 Intermédiation dans la littérature 2.1.5.1 Concept Portail de Yahoo!
Le concept de Yahoo! est une architecture typique de l’intermédiation. En fait, on
aperçoit que Yahoo! n’a aucune donnée stockée sur sa base physique. Mais il est
32 Chapitre 2 : Etat de l’art
une énorme collection de répertoires « universels » du Web. Ce sont des liens vers
les informations sur le Web. Autrement dit, ce sont des méta-données qui elles-
mêmes, ne contiennent pas des informations précises, elles fournissent seulement
les services intermédiaires pour les utilisateurs qui se relient au Web et l'information
dont les utilisateurs ont besoin. Yahoo! est donc un fournisseur de services à valeurs
ajoutées.
Nous voyons bien qu’il y a une tendance vers les Portails d’intermédiation [aBuret]
du type Yahoo! (figure 8). Il est le point d’entrée sous forme d’application Web
regroupant un certain nombre de services et de contenus à un ensemble de clients.
Figure 8 : My Yahoo!
Le Portail Yahoo! a beaucoup évolué. Au début, c’était un annuaire de sites classés
par thèmes. La principale activité de Yahoo! Est maintenant l’agrégation de
contenu. Il ne contient pas seulement les informations publiées par d’autres sites
mais aussi les services tels que l’email, Yahoo! Messenger, jeux, chat, page
personnalisée, boutique, enchère, …
Pourquoi Yahoo! a autant de succès ? Les Portails d’Intermédiation du type Yahoo!
sont nés du constat que l’information sur l’Internet et l’intranet est diffusée de
manière non structurée. Le client est débordé par le nombre d’outils en tout genre.
Le concept de Portail d’Intermédiation vise donc à regrouper les informations sous
2.1 Concept d’Intermédiation 33
un accès unique. Il a des caractéristiques : un point d’accès unique, personnalisation
de services offerts, organisation des informations accessibles. Il a encore des
inconvénients à résoudre dans le futur, comme par exemple, il ne connaît pas la
sémantique d’un profil de client : un client âgé avec un enfant a besoin des services
qui ne sont pas identiques avec un client jeune célibataire. Enfin, le Portail de
Yahoo! n’a pas intégré de moteur d’assemblage qui permet de créer de nouveaux
services à valeur ajoutée via la fédération de services.
2.1.5.2 Cocoon 2.1.5.2.1 Présentation Cocoon
Cocoon [wCocoon] (figure 9) est une infrastructure de publication XML intégrant
la technologie XSP qui permet de traiter les documents en XML. Cocoon se base
sur une architecture 3 tiers :
Figure 9 : Cocoon
- Document : contient des fichiers XML créés par les propriétaires de contenu.
- Traitement : analyse, filtre, ajoute des fichiers XML avec le processeur XSP.
- Présentation : selon le format demandé par le client (HTML, WML, PDF,
XHTML), elle crée des pages HTML ou XML en traitant les fichiers XSL et
XML.
34 Chapitre 2 : Etat de l’art
2.1.5.2.2 Objectif de Cocoon
Le projet Cocoon a pour but de changer la manière dont l'information Web est
créée, générée et distribuée. Ce nouveau paradigme est basé sur le fait que le
contenu, le style et la logique des documents étant souvent créés par différents
individus de manière indépendante pour augmenter la réutilisation des composants
et réduire le temps de mise sur le marché
La génération de Web est principalement basée sur le langage HTML, mais HTML
ne sépare pas l'information de sa présentation, mélangeant balises de formatage,
balises de description et logique de programmation (à la fois du côté serveur et du
côté client comme ASP, PHP, JSP). Cocoon change cette façon de voir : il autorise
le contenu, la logique et le style dans différents fichiers XML et utilise les capacités
de transformation du XSL pour les assembler.
2.1.5.2.3 Avantages de Cocoon :
- C’est une nouvelle génération de systèmes d’intermédiation qui commence à
apparaître en utilisant les technologies du type Cocoon en exploitant la notion du
langage intermédiaire commun de manière plus fine, plus appropriée, en séparant le
contenu et la présentation, ce qui leur permettent d’interagir avec les terminaux de
tout type (HTML, WML...).
- La naissance du métier Web designer et du rédacteur des pages XML permettant
de séparer le contenu et la présentation du document. Le Web designer et le
rédacteur peuvent travailler de la manière indépendante et en parallèle : le Web
designer fournit une transformation XSL adéquate qui correspond à chaque type de
l’utilisateur. Le rédacteur des pages XML : création du document.
- Architecture 3 tiers : Cocoon vise à une séparation complète des trois tiers, lui
permettant de séparer la conception, la création et la gestion des travaux
indépendamment afin d’augmenter la réutilisation des composants et réduire le
temps de mise sur le marché.
2.1 Concept d’Intermédiation 35
2.1.5.2.4 Inconvénients de Cocoon
- La création du fichier XML par le Web designer ( la couche Document ) est faite
manuellement par des humains à l’aide d'un éditeur de texte standard ou d'un
éditeur XML, au lieu de formaliser et d’automatiser avec le DTD ou avec le XML
Schéma.
- Le rédacteur des pages XML : juste un éditeur de document, ne permet pas de
créer et fédérer des services.
2.1.5.2.5 Conclusion
L’idée de Cocoon permet de penser à des notions de création rapide des données
pour tout type de terminal (HTML, WML,…) de façon à séparer le contenu et la
présentation. Ce concept partage un bon concept d’utiliser un langage commun
intermédiaire décrit en XML pour consolider les données externes au niveau de
l’architecture interne comme Archises va proposer.
2.1.5.3 Concept de BEA (Quick Silver, Liquid computing)
BEA [wBEA] définit son nouveau concept, le « Liquid computing » : “A state of
computing in which information and process flow wherever business demands
across all application, services, business ecosystem and value chain on global
basis”.
Le concept « Liquid computing » de BEA (figure 10) est basé sur le concept
d’intermédiation. Il est basé sur le triangle de trois acteurs: entreprise, utilisateur et
producteur.
Figure 10 : Liquid Computing
36 Chapitre 2 : Etat de l’art
• Le producteur (« breakthrough productivity ») : création d’un service le plus
rapide possible.
• L’utilisateur (« active adaptability ») : gestion d’adaptabilité des nouveaux
clients.
• L’entreprise (« entreprise compatibility ») : capable du « plug and play » et
de l’interopérabilité entre les services.
Le « Liquid computing » est un bon concept mais il est toujours lié au framework
de BEA qui s’appelle BEA Web Logic. Ce framework est une solution propriétaire
de BEA et il faut bien maîtriser l’outil de BEA pour créer de nouveaux services, ce
qui n’est ni facile ni négligeable à maîtriser aujourd’hui.
2.1.5.4 Hub d’information (système des compagnies aériennes)
Dans l’aviation civile, le concept d’intermédiation a été beaucoup utilisé. Le hub de
chaque compagnie aérienne est un exemple typique de l’intermédiation. Chaque
passager devrait passer ce hub d’escale pour effectuer le vol souhaité. Par exemple,
Air France a choisi l’aéroport Roissy Charles de Gaulle comme son hub principal
pour tous les vols internationaux. Ainsi la performance et le taux de remplissage de
chaque vol ont beaucoup augmenté. En outre, au niveau de la gestion, il est plus
facile de coopérer avec d’autres compagnies ou de gérer le trafic. Mais le concept
d’intermédiation a encore certains points faibles. Nous pouvons noter que chaque
client doit effectuer au moins une escale via le hub d’intermédiation pour arriver à
sa destination.
Enfin, il faudrait bien sécuriser ce hub. Par exemple, après l’accident du terminal 2
E au mois de juin 2004, Air France a du mal à réorganiser leurs vols vers d’autres
aéroports.
La figure 11 illustre le concept d’intermédiation via le hub.
2.1 Concept d’Intermédiation 37
Figure 11 : Hub d’information
2.1.6 Conclusion du concept d'Intermédiation
De nombreux sites Internet proposent aujourd’hui, à l’instar de Yahoo!, des portails
d’intermédiation. Ces portails permettent à des tiers d'offrir de nouveaux services en
agrégeant des informations, en les filtrant et en les représentant dans un format
standard commun à tous, en l’occurrence HTML [oMesserchmitt 03].
Il existe un grand nombre de portails (Yahoo!, My Yahoo!, AOL.COM, My
AOL.com…) pour un usage à partir de micro-ordinateurs. Il va exister des portails
pour les terminaux mobiles WAP. En effet, avec le concept d'intermédiation
aujourd’hui, un terminal très simple ne peut pas fonctionner facilement pour
téléphoner, consulter des services spécialisés comme la météo, naviguer sur le Web
ou sur le (monde des serveurs) WAP et recevoir les notifications de la messagerie,
de l'agent boursier ou du système d'alarme de la maison.
Une nouvelle génération de systèmes d’intermédiation commence à apparaître
utilisant les technologies du type Cocoon [wCocoon]. Ces systèmes exploitent la
notion du langage intermédiaire commun de manière plus fine, plus appropriée, en
38 Chapitre 2 : Etat de l’art
séparant le contenu du rendu, ce qui leur permettent d’interagir avec les terminaux
de tout type (HTML, WML, XHTML, VoiceXML…).
Pour résumer, le concept d’intermédiation permet d’ajouter et d’enrichir les
informations avant d’être transférées vers le client. Comme les données externes des
différents producteurs ou serveurs sont hétérogènes, il est nécessaire de les
représenter dans un format commun. Les données représentées dans ce langage
intermédiaire peuvent être ensuite traduites dans le format adapté à chaque type de
terminal. Le niveau d'intermédiation permet ainsi aux terminaux de différents types
d'accéder à différents types de services. Grâce à l’intermédiation, nous pouvons
créer un filtre pour mieux adapter les besoins des clients de plus en plus complexes.
Une nouvelle approche dans notre contribution, qui va plus loin, sera généralisée
dans le système d’intermédiation sera plus ouvert pour permettre à des tiers
d’enrichir l’offre de services de leur propre initiative, par création de services, sans
avoir besoin d’une intégration lourde dans le système.
2.2 Composant & Réseau intelligent 39
2.2 Composant & Réseau Intelligent 2.2.1 Réseau intelligent & recommandation Q12xx (UIT-T) [rIN Q12xx]
Au cours des années 80, les opérateurs américains tentaient de résoudre le problème
de la création de nouveaux services en modifiant les commutateurs du réseau. Pour
présenter les nouveaux services, les fournisseurs dépendaient fortement des
opérateurs qui sont les seuls à pouvoir modifier les programmes complexes et
propriétaires de leurs commutateurs. Le délai d’attente était trop long, de trois à
cinq ans pour introduire un nouveau service, ce qui était très contraingnan dans un
contexte fortement concurrentiel où l’opérateur doit réagir rapidement (une
demande de service doit être déployé en trois à six mois) [oIN Gaïti] [oZnaty].
C’est dans ce contexte que le concept de réseau intelligent (RI) [rIN Q12xx] fut
introduit. Il s’agit d’un concept architectural permettant de créer et de fournir
rapidement des services de télécommunications. Le RI permet de créer des services
en facilitant la fourniture de services indépendamment de la mise en œuvre [aKung]
[aIN0909].
Dans ce contexte, le concept de réseau intelligent (RI) fut introduit. C’est un
concept architectural permettant de créer et de fournir rapidement des services de
télécommunication. Il permet de créer des services en facilitant la fourniture de
services indépendants de la mise en œuvre.
Le principe du réseau intelligent défini par l'UIT-T dans les recommandations
Q12xx est le suivant:
- séparation entre le contrôle de service et le contrôle d'appel pour faciliter le
déploiement de nouveaux services.
- création et gestion rapide et uniformément des services par l'assemblage de
Service Independent Building Block (SIB Q.12xx).
40 Chapitre 2 : Etat de l’art
Pour mieux comprendre comment le RI peut permettre d'atteindre l'objectif de mise
en oeuvre rapide de services, nous avons établi une comparaison générale entre les
traitements des services traditionnels de type non-RI (ne répondant pas aux objectifs
précités) et le traitement de services de type RI (répondant aux objectifs précités).
Ces deux cas sont illustrés par un modèle de traitement de services non-RI et un
modèle de traitement de services RI.
La figure 12 montre la différence en utilisant le concept de réseau intelligent par
rapport au réseau classique.
Figure 12 : Réseau classique vs réseau intelligent
Dans ce schéma, le service de traitement de base (traitement des appels - Call
Control Point CCP) doit être accessible dans tout le réseau. Il se trouve dans les
commutateurs.
Dans un modèle non-RI, chaque demande de nouveau service nécessite de modifier
le code des autocommutateurs. Le temps de traitement est donc très long et le
2.2 Composant & Réseau intelligent 41
service n’est pas accessible partout dans le réseau. De plus, le fournisseur de ce
commutateur est le seul à être capable de modifier le code.
Avec le modèle de RI, chaque demande de service est déclenché vers le niveau
logique de service par des déclencheurs (triggering) qui se trouve dans chaque
commutateur. Ces déclencheurs ouvrent l’accès à une session d'interaction avec la
logique du service RI, le service en cours doit être temporairement suspendu. La
logique du service RI traite la demande via un environnement de création de
services qui doit être mis au point pour permettre la mise en place rapide de
nouveaux services complémentaires. Ainsi les services complémentaires sont donc
indépendants du traitement d’appel et le temps nécessaire pour créer de nouveaux
services est ainsi notablement réduit.
On peut donner ici un exemple typique du réseau intelligent, un des premiers
services mis en œuvre, c’est le numéro vert (0800 en France). Comment fonctionne-
t-il ? Pour appeler un numéro vert, ce service se repose sur une table de traduction
d’un numéro logique 0800xxxxxx en un numéro de destination réelle. Cette table
est globale pour tous les commutateurs. Pour économiser le coût de mise en œuvre,
il faut avoir un nœud central stockant cette table et accessible par tous les
commutateurs qui est appelé le SCP (Service Control Point).
Dans l’architecture de réseau intelligent, le SCP joue le rôle central. Les
commutateurs CCPs (Call Control Point) et SSPs (Service Switching Point) sont les
esclaves du SCP. Grâce à cette séparation, elle permet de créer les nouveaux
services via le SCP de manière simple et très rapide au lieu de modifier le code dans
le SSP qui est déjà très complexe et coûteux. Chaque fois qu’il y a une demande de
service, elle sera traitée via le mécanisme de branchement. Cette demande sera
exécutée au niveau logique du service SCP qui constitue l’intelligence de réseau
intelligent.
2.2.2 Le modèle de réseau intelligent :
42 Chapitre 2 : Etat de l’art
Le réseau intelligent est une architecture bien détaillée, composée en quatre plans
(figure 13) dont chaque plan représente une vue abstraite différente des capacités
offertes par un réseau structuré en réseau intelligent. Ces différentes vues se
rapportent aux aspects du service, à la fonctionnalité globale, à la fonctionnalité
répartie et aux aspects physiques d'un réseau intelligent :
- Dans le plan de service se trouve les services tels que le service libre appel, le
service UPT, le service de renvoi… C’est une vue orientée vers les services, elle se
compose de plusieurs éléments de service (SF Service Feature). Un SF comporte un
ou plusieurs composants SIBs enchaînés que nous trouvons dans le plan fonctionnel
global.
- Le plan fonctionnel global contient des SIBs qui enchaînent via un processus de
traitement d’appel GSL (Global Service Logic). Il y a 14 SIBs, chacun est
responsable d’une fonction précise.
Figure 13 : Modèle de réseau intelligent
2.2 Composant & Réseau intelligent 43
- Descendons un niveau, on trouve le plan fonctionnel réparti, qui modélise le RI
comme un ensemble d’entités fonctionnelles réparties exécutant des actions (FEAs
Functional Entity Action). FEA comporte des entités telles que SSF, CCF, SCF,
SDF. Le CCF s’occupe des traitements de base, tandis que le SSF est un trigger
pour déclencher des appels venant du CCF et il les envoie vers le SCF dont il a
besoin des SIBs comme SIB-translate, SIB-screen, SIB-compare … Pour le SCF,
c’est l’intelligence du RI, il exécute des services demandés, il contient des SIBs
comme SIB-translate, SIB-algorithm, SIB-verify…
- Le niveau le plus bas est le plan physique où se trouve des entités physiques telles
que SSP, CCP, SCP, SDP et les interfaces entre ces entités. Ce sont les éléments
pris en charge par les équipementiers et les opérateurs de réseau.
2.2.3 Réseau Intelligent & Composant 2.2.3.1 Composant SIB (Service Independent Building Block)
SIB (figure 14) est « un composant » de base dans le réseau intelligent. Il est considéré comme une fonction spéciale pour créer des éléments réutilisable du service, un bloc fonctionnel réutilisable, indépendant de service, il comporte :
- une entrée logique (input) : entrée de composant SIB,
- une ou plusieurs sorties logiques (outputs) : sortie de composant SIB,
- paramètres statiques SSD (Service Support Data) :
+ peut être fixes : profil de client, table de traduction …
+ peut être une référence comme un pointeur CIDFP (Call Instance Data Field Pointer) : pointeur vers une zone de stockage,
- paramètres dynamiques CID (Call Instance Data) : numéros de l’appel (donnée entrée) ou cause de l’erreur (donnée sortie).
44 Chapitre 2 : Etat de l’art
Figure 14 : Composant SIB
2.2.3.2 Les 14 SIBs de base dans le réseau intelligent
- SIB algorithm : effectue une opération mathématique (addition, soustraction, multiplication, division).
- SIB authenticate : le module qui remplit la fonction d'authentification pour un service.
- Charge : permet d’appliquer une taxation particulière.
- Compare : la comparaison entre deux identificateurs.
- Distribution : répartit les appels vers ses différentes sorties en fonction d’un algorithme déterminé par l'utilisateur.
- Limit : limite le nombre d’appels qui peuvent atteindre.
- Log Call : journalise certaines informations des appels dans un fichier.
- Queue : met en file d’attente des appels.
- Screen : compare et détermine un identificateur pour savoir s’il appartient ou non dans la liste.
- Service data management : permet de manipuler les données d'utilisateur spécifiques.
- Status notification : fournit la capacité de savoir l'état des ressources du réseau.
- Translate : traduit en un paramètre de sortie à partir d’un paramètre d'entrée.
- User interaction : permet l'échange d'informations avec un utilisateur et le réseau.
- Verify : vérifie si l'information est conforme à la forme attendue.
2.2.3.3 Le processus d’assemblage des SIBs
2.2 Composant & Réseau intelligent 45
Pour assembler les SIBs, le réseau intelligent utilise un enchaînement de SIBs via le
BCP (Basic Call Process). La figure 15 illustre le processus d’assemblage des SIBs.
Figure 15 : Processus d’assemblage des SIBs
Comment cette méthode fonctionne-t-elle? En fait, des SIBs sont assemblés via la
logique de traitement du service GSL (Global Service Logic). C’est la logique de
liaison permettant d’enchaîner des SIBs dans l’ordre pour qu’ils soient connectés à
assurer des services :
- un SIB particulier BCP traite des appels, il contient un POI (Point of Initiation) et
un ensemble de PORs (Point of Return). Le POI est le point de lancement du BCP
vers la chaîne des SIB, les PORs sont des points logiques de retour des modules
SIBs vers le BCP.
- la chaîne des SIBs auxquels ils sont connectés par l’ordre concaténé. Elle
commence au point POI et se termine par l’ensemble de points POR.
Grâce à cette méthode d’enchaînement, les services créés dans le commutateur
deviennent plus rapides et de plus en plus nombreux. Imaginons qu’au départ, il y a
N services, avec cette méthode, les services seront créés avec la puissance N.
2.2.3.4 Evaluation de SIB
46 Chapitre 2 : Etat de l’art
L’avantage de SIB est l’idée de créer les services via l’assemblage des composants,
beaucoup plus rapidement que la manière monolithique. Par exemple, à partir de 14
SIBs au départ, en théorie, nous pouvons créer :
∑=
14
114
n
nA = ∑= −
14
1 )!14(!14
n n = (14 +14*13 + 14*13*12 +
14*13*12*11+…+14*13*…*2 + 14*13*12*….*2*1)
=14(1+13(1+12(1+11(1+10(1+9(1+8(1+7(1+6(1+5(1+4(1+3(1+2(1+1(1)))))))))))))
=14(1 +13 …5(1+ 4(1 + 3 (1 + 2.2))))))))))))) = 1 312 174 089 604
En gros, avec n SIBs au départ, on peut avoir :
n !+ n.(n-1)+ (n-1)(n-2) +…3.2 + 2.1 = n(1 + (n-1)(1+ (n-2) (1+…2(1+1)))…) SIBs
De plus, avec des nouveaux SIBs ont été créés, nous pouvons réutiliser comme les
SIBs de base pour créer un nouveau SIB. Les services peuvent donc être créés de
manière exponentielle, bien sûr il faut les tester, les valider car certains assemblages
ne donnent aucun sens. Un autre avantage est de réutiliser plusieurs fois un
composant SIB sans réécrire une seule ligne de code. Mais ici, la question est de
« comment les assembler ? » : il y a toujours des implémentations qui ne sont pas
compatibles avec les spécifications déjà écrites. Alors, il faut les adapter dans leurs
nouveaux contextes.
Malgré les efforts de UIT-T pour standardiser les composants SIBs, il reste toujours
fermé dans le monde des télécoms. SIB est né avec un demi-échec car il est
complexe et surtout il est propriétaire.
Deuxièmement, les SIBs sont limités dans le domaine des télécoms, ce qui n’est pas
adapté dans le monde d’informatique aujourd’hui avec l’émergence de l’Internet. Il
fallait qu’ils soient émergés avec cette évolution.
Troisièmement, avec les spécifications déjà complexes à comprendre, les SIBs sont
décrits au niveau très abstrait, ils sont difficiles à implémenter et chaque fournisseur
les implémente de leur manière différente. Le problème est donc qu’un composant
2.2 Composant & Réseau intelligent 47
SIB d’Alcatel ne peut communiquer avec celui de Matra ou Nortel … En fait,
chaque fournisseur crée son propre composant propriétaire, ce qui n’est pas du tout
utilisable par les autres opérateurs.
Enfin, les normes RI, UIT-T Q.12xx, malheureusement ne définissent qu'un modèle
abstrait de composants réutilisables SIBs et un cadre conceptuel de gestion et de
déploiement de services RI. Un opérateur de téléphonie publique est pratiquement
obligé d'acheter chez un seul fournisseur toute l'infrastructure RI : un
environnement de création de services propriétaires, un système de déploiement de
service propriétaire pour déployer les services, des ordinateurs de commande de
service SCP propriétaires pour exécuter les services.
2.2.4 Conclusion de réseau intelligent
Le réseau intelligent préconise la séparation de la logique de services et de la
commutation. Cette séparation a pour but de développer des nouveaux services sans
avoir à modifier et à mettre à jour les commutateurs. Un mécanisme de
déclenchement de service externe (triggering : IF condition vérifiée THEN activer
service externe ELSE continuer), intégré dans le commutateur, peut activer la mise
en œuvre d’un service au niveau du réseau intelligent : le nombre de services
supplémentaires est quasi infini alors que le nombre de services natifs du
commutateur est limité et difficilement extensible (figure 16).
Figure 16 : Services dans le réseau intelligent
48 Chapitre 2 : Etat de l’art
Le réseau intelligent préconise aussi le développement rapide de nouveaux
services par l'assemblage de composants logiciels réutilisables SIB (Service
Independent Building Block) (figure 17).
Figure 17 : Assemblage de composants dans le réseau intelligent
Ainsi, le réseau intelligent introduit un nouveau type de développement : la création
de services. Alors que les programmeurs traditionnels conçoivent des composants
logiciels, les créateurs de services conçoivent de nouveaux services en assemblant
des composants logiciels. Le cycle de développement (analyse, codage et test) est
semblable dans les deux cas. Il est sensiblement plus court dans le cas de la création
de services car il s’agit d’un processus d'assemblage de composants.
La création de services dans le réseau intelligent est un domaine de recherche très
intéressant. Le concept de réseau intelligent est un demi-échec car certains acteurs
des télécommunications proposent des concepts de services propriétaires comme
base de composants réutilisables. De plus, ils s’appuient essentiellement sur des
outils propriétaires. En outre, l’UIT-T vise à standardiser la création de services
dans le réseau intelligent en définissant le concept de SIB avec les
recommandations CS-1, CS-2, CS-3. Pour ces raisons, le réseau intelligent est
devenu très compliqué à implémenter et a été dépassé même si l’idée était bonne au
départ.
2.3 Assemblage de composant 49
2.3 Assemblage de composant 2.3.1 Définition de composant
Nous sommes actuellement dans un mouvement d’évolution de la fabrication des
logiciels [aCESURE]. Après l’approche de composant dans la programmation en
langage modulaire [voir 2.3.2], vient ensuite l’approche de composant dans la
programmation en langage fonctionnel [voir 2.3.3] avec la lisibilité des codes, et
puis l’approche de composant dans la programmation orientée objet [voir 2.3.4]
avec une meilleure organisation. Une nouvelle technique de programmation est la
méthode orientée composant [voir 2.3.5] et la méthode orientée Web Services
[voir 2.3.6] permettant de réutiliser les composants. La figure 18 illustre l’évolution
de composant dans les langages de programmation.
Figure 18 : Comparaison les types de composant
En fait, le concept de composant réutilisable est le rêve persistant des
informaticiens. Quand on fabrique une voiture, on réutilise les roues, les moteurs…
au lieu de tout reproduire. Quant à la construction d’une maison, faudrait-il
assembler les composants tels que les briques, les murs, les fenêtres, … ? Et si on
fabrique un ordinateur, que fait-on ? On peut assembler les composants tels que le
disque dur, la mémoire, le processeur sur la carte mère. Pourquoi ne pas appliquer
ce concept dans l’informatique ? [tFassino] [tOliver]. La figure 19 illustre les
chaînes d’assemblage dans la vie.
50 Chapitre 2 : Etat de l’art
Figure 19 : Chaîne d’assemblage dans littérature
Dans le passé, on avait le processus de codage dans le cycle du développement de
logiciel. Le problème est de trouver une solution de création rapide des applications
avec le coût le moins cher et la solution est de réutiliser les codes existants. On n’a
plus besoin de savoir comment le code a été créé. L’importance est de trouver le
bon composant et le bon fonctionnement, de bien l'intégrer et de bien le paramétrer.
Depuis des années, il y avait une tendance à réutiliser le code existant pour ne pas
« réinventer la roue » : le concept de composant. Il s’agit tout simplement de
réutiliser du code existant qui se partage avec d’autres applications.
Qu’est-ce c’est vraiment un composant ? A notre connaissance, il n’existe pas une
définition complète car chaque expert a un point de vue différent sur ce concept.
Selon, J.Harris, CI Lab [wHarris], un composant est un morceau de logiciel
suffisamment petit pour que l'on puisse le créer, le maintenir mais aussi
suffisamment grand pour que l'on puisse l'installer et en assurer le support. De
plus, il est doté des interfaces pour inter opérer avec d’autres composants.
Selon Clemens Szyperski [aSzyperski LNCS02] dans son livre Software
Component, un composant est une unité indépendante du déploiement, une unité de
« third-party composition » et il n’a aucun statut externe. Quand à un objet, c’est
2.3 Assemblage de composant 51
une unité d’instanciation qui a une identité unique et qui peut avoir le statut externe,
il est donc encapsulé de son statut et de son comportement.
D’après la définition dans RNTL (Réseau National des Technologies Logicielles,
appel d'offre 2000) : le concept de composant a 5R « Riviable, Reuseable,
Replaceable, Reliable, Resilient ». Ce concept permet de faire la
« co-compétition », c’est à dire de faire la coopération pour grandir le gâteau à
partager tout en étant en compétition [oARAGO 24].
Selon Sami Jaber, un composant est une unité primaire de déploiement et de
composition spécifiée par une interface décrivant des services et de des
dépendances. Les composants sont des briques autonomes pouvant être
dynamiquement contrôlées et assemblées pour former des applications.
En résumé, un composant est considéré comme une boîte noire et représenté par
des entrées et des sorties permettant de relier entre différents composants. Son but
est d’assembler les composants pour former un nouveau service. Un service est
donc une collection de composants logiciels indépendants, interconnectés sur une
plate-forme de communication.
Avantages du concept d'assemblage de composants : l'intérêt de la technologie
de composant est de gagner du temps de développement. En effet, la recherche et
l'évaluation des composants se font bien plus rapidement que le développement de
ses propres outils. Nous sommes dans un monde ouvert qui permet de créer
facilement les services de plus en plus complexes. Imaginons qu'un logiciel avec
100% de développement au lieu de 50% de développement et 50% de réutilisation.
Certes, c’est plus rapide, moins de fautes, bien sûr il faut parfois faire l’adaptation
pour qu’il soit réutilisable [aACCORD].
Pour expliquer plus précisément le concept de composant, on peut citer un exemple
dans la vie quotidienne avec la machine à laver. Depuis longtemps, ce concept a été
bien utilisé dans la machine à laver pour créer des fonctions de plus simples en plus
sophistiquées grâce à l’assemblage des fonctions de base.
52 Chapitre 2 : Etat de l’art
Pour résumer, voici les avantages du composant :
-Le développement est simple par rapport au développement traditionnel.
-Réutilisation : Un composant peut être réutilisé par plusieurs applications simultanément, et une application (service) peut aussi utiliser plusieurs composants à la fois pour former une application complète.
-Sécurité : comme c’est une boîte noire, on ne pourra connaître, analyser ou copier le code source. C’est un point fort pour le commercialiser. Autre point, il est très utile car personne n’aura modifié son code.
-Fiabilité : comme le composant dont on dispose est normalement déjà testé. Chaque programme qui l’utilise bénéficie de la fiabilité du composant.
-Versioning (en VS.Net) [oArcher] : cette fonctionnalité est déjà impliqué dans la version .Net de Visual Studio et d’autres projets. Elle permet de faire évoluer un composant sans avoir à recompiler l’application.
Inconvénients du concept d'assemblage de composants :
-Il n’y a pas de code source, difficile à modifier.
-Il faut chercher pour trouver le meilleur composant qui correspond bien à notre besoin.
-Il faut bien assembler les composants dont nous avons besoin pour notre système.
La machine à laver, un exemple de composant :
La machine à laver [oAppleman Progz] est relativement simple, elle comporte
seulement quatre composants principaux: remplissage, agitation, vidage, séchage.
On peut créer via l’équation de SIB (chapitre 1), il y a environ : e x 4 ! = 1,8271 x
24 = 44 composants (figure 20).
2.3 Assemblage de composant 53
Figure 20 : Composant dans la machine à laver
A l’intérieur de chaque composant, il peut contenir des milliers lignes de code.
Avec la méthode de composant, on peut comprendre comment un programme
fonctionne et les utiliser sans avoir besoin de regarder une ligne de code.
Un composant de la machine est un bloc de code avec un nom, ayant des lignes de
code (une suite des instructions) pour effectuer une fonction précise et aussi
renvoyer un résultat.
Une tâche comporte une suite de composants pour effectuer une fonction précise :
Tâche Prélavage= Remplissage(max) + Vidage()
Tâche Lavage = Remplissage(moyen) + Agitation() + Vidage()
Tâche Rinçage = Remplissage ( ) + Vidage ( ) + Séchage(min)
Tâche Séchage = Séchage(max)
Les nouvelles tâches créées peuvent être réutilisées pour assembler avec les autres fonctions de base pour afin de former une nouvelle tâche, par exemple :
Tâche Séchage_plus = Tâche Rinçage + composant Séchage(max)
Conclusion : La réutilisation de composant permet de créer plus rapidement de
nouveaux services. Possédant un logiciel avec la moitié du code réutilisé, nous
avons une productivité très fabuleuse. Il ne nous reste que la moitié du travail à
accomplir. D’autre part, on peut réutiliser ce code pour un autre programme. Avec
54 Chapitre 2 : Etat de l’art
l’évolution de l’information, jour après jour, la programmation étant de plus en plus
compliquée, avec la réutilisation, nous pouvons corriger facilement un grand
nombre d’erreurs.
Bien sûr, au niveau de la performance, le composant ne peut être optimisé au
maximum possible. Ainsi, il faut faire les adaptations pour qu’il puisse être réutilisé.
Mais le contexte concurrentiel du marché d’aujourd’hui oblige un fournisseur de
logiciel à sortir une application le plus tôt possible à la meilleure qualité et au prix le
moins cher. Le concept de composant est bien accepté car il permet de créer un
service plus rapide et moins coûteux en augmentant la productivité.
Dans le contexte actuel en vue d’arriver à la productivité la plus grande avec la
meilleure qualité, il faudrait passer du mode de production artisanale à des modes
de productions industrielles à la base de composants réutilisables : les bons
programmeurs savent quoi écrire, les grands programmeurs savent quoi
réécrire et réutiliser.
Pour bien approfondir le concept de composant, nous allons traiter l’évolution de
composant dans les langages de programmation.
2.3.2 Composant & Programmation en langage modulaire (Basic) 2.3.2.1 Description de programmation modulaire
C'est depuis longtemps que l’on pensait au concept de composant qui a pour but de
décomposer un système en des petits morceaux qu’il est plus facile à traiter. Voici
un exemple qui montre comment marche une fonction dans le langage modulaire.
C’est un programme en BASIC de conversion en majuscule, commence en ligne
200 [oAppleman Progz].
100 REM Begin Subroutine
101 If C >= ascii(“a”) then Goto 40
102 Goto 107
2.3 Assemblage de composant 55
103 If C<=ascii(“z”) then Goto 60
104 Goto 107
105 flag=1
106 Goto 108
107 flag=0
108 Return : fin de subroutine
200 REM Begin MAIN function avec caractère X
201 C = Ascii(X)
202 Goto 100
203 If flag=1 then Goto 205
204 Goto 207
205 REM X est minuscule
206 X = chr(C-32) // convertir en majuscule
207 Return
2.3.2.2 Module (composant) = interfaces + corps + initialisation (variables)
Pour conclure, un composant dans la programmation modulaire est une
combinaison des interfaces et des corps (un bout de code) et une initialisation (des
variables ou contexte), il représente une fonction précise.
Les caractéristiques de cette méthode :
- Boîte blanche : on peut modifier le code partout dans le composant du langage
modulaire. C’est facile pour un petit programme mais le problème devient très
compliqué pour un programme complexe. De plus, modifier un programme
complexe pour un utilisateur est difficile et très dangereux s’il ne connaît pas bien le
fonctionnement du système.
56 Chapitre 2 : Etat de l’art
- Modulaire monolithique : le composant modulaire est vraiment un bout de code.
Il exécute d’un point fixe au point suivant pas à pas jusqu’une fin bien déterminée.
- Pas de « wrapping » : on peut faire des GOTO partout dans le code. De plus, dans
le code, on peut faire autant de sorties et d’entrées.
- Il n’y a pas d’interfaces avec d’autres composants.
2.3.3 Composant & Programmation en langage fonctionnel (C, Pascal) 2.3.3.1 Description de la Programmation en langage fonctionnel
La méthode orientée fonctionnelle est une évolution de la méthode de
programmation modulaire car il permet la réutilisation des codes au lieu d’écrire
des milliers de lignes de code.
Par exemple, quand on appel Convertir (&X) qui se trouve en dehors du programme
principal [oAppleman Progz] :
Function test(x as integer) As integer
Dim result as Integer
If (x >= asc(“a”) and x <=asc(“z”) then
Result = 1
Else
Result = 0
Endif
Test = result
End Function
Sub Main(X as String)
2.3 Assemblage de composant 57
Dim C as integer
C = asc(X)
If test(X) then
X = chr(C -32)
End If
End Sub
2.3.3.2 Composant (service)=objets-nom+messages
Les caractéristiques de cette méthode :
- Boîte grise : on peut à la fois réutiliser le code et à la fois modifier ce code.
- Modulaire monolithique : le composant fonctionnel est vraiment un bout de
code. Il exécute d’un point fixe au point suivant pas à pas vers une fin bien
déterminée.
- Pas de « wrapping » : on peut faire encore des GOTO partout dans le code mais il
y a des recommandations d’y éviter. De plus, dans le code, on peut faire autant de
sorties et d’entrées.
- Il n’y a pas d’interfaces avec d’autres composants.
2.3.4 Composant & Programmation orientée objet (C++, Java) 2.3.4.1 Rappel du langage d’objet :
Le langage d’objet est une méthode de programmation basée sur des objets. Il est
une évolution du langage modulaire.
Objet : une instance d’une classe qui contient un état et un comportement, désignée
par un identifiant unique.
58 Chapitre 2 : Etat de l’art
Classe : un type abstrait de données, comportant des attributs et des méthodes pour
définir des caractéristiques et des comportements communs des objets de la classe.
Attribut : un nom et un type (type de base ou une classe).
Méthode : opération applicable à l’objet de base qui peut modifier l’état d’objet,
c’est le comportement d’objet.
Les caractéristiques de base de l’objet :
Encapsulation : des attributs et des méthodes sont encapsulés dans une classe. On
ne peut pas manipuler directement sur l’objet mais on peut passer par ses méthodes
publiques.
Héritage : caractéristique permet de créer une nouvelle classe à partir d’une classe
déjà existante. Cette nouvelle classe hérite des attributs et des méthodes de la classe
héritée.
Override : surcharge le code d’une méthode pour définir un nouveau
comportement de la classe héritée.
Polymorphisme : permet d’appeler des différents codes d’une même méthode en
fonction du type de l’objet appelé ou de différents types de paramètres.
2.3.4.2 service (composants )=objets-nom+messages
Qu’est-ce que c’est un objet sous le point de vue de composant ? Un objet dans le
langage orienté objet fournit un ensemble de services via des fonctions avec des
entrées et des sorties. Pour créer un service, on identifie le service dont on a besoin
et assemble les objets qui rendent ces services.
Les caractéristiques du composant dans la programmation orientée objet est :
- Boîte grise : on peut à la fois réutiliser et modifier son code.
2.3 Assemblage de composant 59
- « Wrap monolithique » : le composant doit être écrit sur le même langage et
avoir des liens très stricts pour pouvoir les assembler.
- Il y a des interfaces avec d’autres composants.
2.3.5 Composant & Programmation orientée composant (C#) 2.3.5.1 Composant vs Objet
Avec le langage d’objet, l’avantage est de réutiliser une classe ou de définir une
classe héritée d’une autre classe en écrivant peu de code. En plus, il est facile de
faire évoluer le code en ajoutant de nouvelles classes ou en utilisant l’héritage pour
avoir un nouveau comportement. Il est aussi facile de modifier une classe sans
perturber les autres classes via le mécanisme d’encapsulation. Mais la limite de
l’objet est sa granularité est encore trop fine, pas bien adapté à la programmation à
grande échelle [aBézivin]. En plus, il n’est pas encore assez modulaire comme
l’approche composant [oSzyperski 02].
Voici la différence entre deux approches (figure 21) :
- Objet a du polymorphisme, de l’héritage et possède souvent un état (un ensemble
des attributs de l’objet).
- Au contraire de composant, objet n’est pas forcément utilisable.
- Objet et composant ont pour but de créer des services via l’interface. Objet n’est
qu’une instance de classe.
Figure 21 : Objet vs composant
60 Chapitre 2 : Etat de l’art
2.3.5.2 service (composants)=components+scripts+glues
Les caractéristiques de cette méthode :
- Boîte noire : assemblage des composants sans avoir besoin comment ce code a été
créé.
- « Wrapping » : le code est bien « wrapping », cela garantit la sécurité du code
- Interface : il fournit des interfaces pour qu’un client puisse utiliser facilement.
2.3.5.3 Composant dans la programmation orientée composant vs composant dans la programmation orientée objet
La différente principale entre un composant dans l’approche orientée objet et un
composant dans l’approche orientée composant consite en deux abstractions : boîte
blanche [oJacohson] et boîte noire [oSzyperski 02]. L’abstraction de type boîte
blanche, l’interface peut imposer l’encapsulation et les limites de ce que les clients
peuvent faire. De plus, une modification dans une boîte blanche peut changer
complètement le comportement du système. L’abstraction de type boîte noire,
aucun détail hormis l’interface et sa spécification ne sont connus des clients
[aSzyperskiSD011] [aSzyperskiSD012].
La manipulation de composant dans l’approche orientée objet se fait au travers de
méthodes, mais le corps de l’objet n’est pas totalement masqué. De plus, la
réutilisation d’un objet se fait principalement au niveau du langage et non au niveau
de binaire comme l’approche de composant [aGabriel].
Cette approche boîte noire permet de masquer l’hétérogénéité des composants,
c'est-à-dire le fait qu’ils ont été conçus et développés indépendamment les uns des
autres et qu’ils sont éventuellement écrits dans les langages différents. Cette
approche est en train de se développer par Microsoft dans leur framework .NET
[oPlatt] version 2.x qui va sortir en 2006 [voir 2.4.1].
2.3 Assemblage de composant 61
Une autre différence entre composant et objet est la modularité. Elle permet une
bonne décomposition logique et physique de l’application en composants logiciels
autonomes et indépendantes. Cette modularité assure l’indépendance des différents
composants permettant leur interchangeabilité. Il offre donc de la souplesse quant à
l’évolution de l’application et à son adaptabilité. Cette capacité de modifier la
configuration d’un système offre une grande flexibilité d’évolution de l’application.
Donc, un service peut être créé plus rapidement grâce à l’approche de composant
[oHeinneman].
2.3.6 Composant & Web Services (.NET, J2EE) 2.3.6.1 Description Web Services
Selon la définition de W3c, Web Services [wWS-ARCH] est une opportunité des
systèmes distribués avec les avantages du Web. Il essaie de combler les faiblesses
du concept orienté objet et le concept de composant (COM/DCOM, CORBA)
[wCOM].
Un composant de Web Services ressemble beaucoup au composant dans le concept
orienté composant sauf il :
- s’est basé sur le standard XML [wXML] (eXtensible Markup Language). XML
est un format « universel » permettant l’échange d’information entre applications.
- est décrite par WSDL (Web Service Description Language). WSDL est bâti sur
XML, WSDL est dédié à la description de tous les éléments nécessaires d’un Web
Services dont les ports d’entrées, les ports de sorties…
- se transporte par le protocole standard SOAP (Simple Object Access Protocol).
SOAP [wSOAP] est le protocole standard destiné aux Web Services. Il donne la
structure des messages échangés, ce qui permet leur sémantique. Il utilise XML
comme format des messages SOAP et HTTP comme le protocole de transport sur
l’Internet. SOAP permet d’utiliser des applications invoquées à distance via
l’Internet.
62 Chapitre 2 : Etat de l’art
- se trouve facilement via UDDI [wUDDI], le catalogue des services offerts sur
l’Internet. L’initiative UDDI est un annuaire universel supporté par les grandes
entreprises. Il a pour but de fournir un moyen pour les fournisseurs de services
puissent publier leurs services au client. Il permet aussi à un client de trouver
facilement les services dont il a besoin.
La figure 22 illustre la communication entre des Web Services.
Figure 22 : Web Services
Un composant Web Service est implémenté dans l’architecture orientée Service
(SOA - Service Oriented Architecture) [wBEA]. Dans le schéma de SOA (figure
23) un Web Service est créé, fourni par le fournisseur de service (service
provider). Le fournisseur de service enregistre ensuite ce Web Service dans le
Service Registry (équivalent aux pages jaunes) et fournit la description de ce
service pour que d’autres personnes puissent l’utiliser. Cette description contient les
informations des fonctionnalités et la localisation du service. Enfin, le demandeur
de service (Service Requester) peut chercher le service dont il a besoin dans le
Registry ; ensuite il fait le « bind » et « invoke » ce service [wWS-ARCH].
2.3 Assemblage de composant 63
Figure 23 : Web Services – SOAP - UDDI
En général, un Web Service est un service accessible via le Web. Plus précisément,
un Web Service est une boîte noire des fonctionnalités que sont fournies par des
composants programmables et qui sont accessibles via l’Internet avec le standard de
données en XML et le protocole de transport SOAP.
L’idée de Web Services provient du RPC, mais un Web Service garantit
l’indépendance de la plate-forme d’exécution du Web Service. La figure 24 illustre
l’évolution des modèles de services dans la littérature.
Figure 24 : Modèles de services
64 Chapitre 2 : Etat de l’art
2.3.6.2 Web Services (composants)=http+composant =SOAP + composant + WSDL
L’avantage des Web Services : il permet d’avoir un nouvel acteur, c’est le créateur
de service. Celui-ci dispose d’une bibliothèque contenant tous les composants
permettant de créer des services. Lorsqu’il crée un service, il choisit dans la
bibliothèque, puis il les assemble en prenant les composants et les configurer.
Inconvénient des composants Web Services : se pose le problème de
communication entre des Web Services, c'est-à-dire, malgré l’interface commune
en XML, il y a encore des problèmes à régler dans le concept de Web Services :
comment traverser le « Firewall », etc. Il manque encore un langage de lien –
langage d’assemblage universel pour relier les Web Services pour former un
nouveau service.
2.3.7 Transformation & composant 2.3.7.1 Définition de transformation
Moteur de transformation XSLT [oXSLT]: XSLT (figure 25) est un standard du
W3C qui permet de réaliser des transformations de documents XML. Il définit
d’une part un langage qui permet d’exprimer des règles de transformation et d’autre
part une façon de parcourir les documents XML afin d’y appliquer ces règles.
Figure 25 : XSLT
Le principe de fonctionnement de XSLT est celui d’une transformation d’arbre.
Le document XML source est vu comme un arbre : à chaque balise du document
2.3 Assemblage de composant 65
correspond un nœud de l’arbre. Le moteur de transformation parse cet arbre et en
fonction des règles de transformation, il va donc construire l’arbre cible qui
correspond au document XML résultat. Dans le vocabulaire XSLT l’ensemble des
règles de transformation est décrit en XML et s’appelle une feuille de style XSLT.
Les règles décrites dans une feuille de style XSLT sont constituées de deux parties.
Une partie permet d’identifier un motif dans l’arbre source. L’autre partie permet de
construire un morceau de l’arbre cible. Cette partie est soit composée d’un sous
arbre qui sera copié dans l’arbre cible, soit composée d’un ensemble de commandes
XSLT permettant la création d’éléments dans l’arbre cible.
Il est important de noter que XSLT a été conçu pour transformer tout type de
document XML. Nous pouvons utiliser XSLT comme technique de transformation
de modèle car il est possible de représenter les modèles sous forme de documents
XML. Le standard XSLT du W3C qui permet de transformer un document XML
source en un document XML cible est une technique de transformation que nous
pouvons utiliser. Par contre, aucun moteur de transformation existant ne permet de
manipuler les méta-modèles sous forme d’objets, il faut alors en élaborer un de
toutes pièces.
2.3.7.2 Feuille de style XSLT
Une feuille de style XSLT [oXSLT] est constituée de plusieurs templates. Chacun
de ces templates s’applique sur une sous-partie de l’arbre correspondant au
document source et permet la génération d’une partie de l’arbre correspondant au
document cible. Il n’y a pas de correspondance binaire entre les templates et les
règles de transformation que nous avons définies, un template peut réaliser une
partie ou plusieurs règles de transformation. La logique d’une feuille de style XSLT
ressemble fortement à la logique d’une application écrite en utilisant un langage de
programmation fonctionnelle.
66 Chapitre 2 : Etat de l’art
2.3.7.3 Evaluation de XSLT
L’intérêt de cette technique est de développer un programme parfaitement adapté
aux transformations contrairement à XSLT qui impose des contraintes dues à la
syntaxe du langage XML. Un autre avantage est que la conception de ces
programmes est aussi beaucoup plus simple car elle ne nécessite pas l’apprentissage
d’un nouveau langage ni d’une nouvelle technique. Par contre, l’inconvénient
majeur est qu’il faut redéfinir tout ce que fait un moteur de transformation. Ceci
veut dire qu’il faut pour chaque nouvelle base de règles redéfinir une façon de
parcourir les modèles et une nouvelle façon de générer les modèles cibles.
L’avantage principale d’utiliser XSLT est qu’il existe beaucoup d’outils très utiles
comme par exemple XMLSpy [wXMLSpy] permettant la manipulation de
documents XML et l’élaboration de feuilles de style XSLT pour pouvoir les
transformer. Néanmoins, il est important de noter que XSLT reste encore très peu
utilisé.
Une question qui reste ouverte est de savoir si XSLT permet ou non de réaliser
toutes les transformations possibles et imaginables. Dans nos travaux nous n’avons
pas trouvé de telles limites mais nous sommes bien conscients que cela n’est pas
une preuve.
2.3.8 Conclusion sur l’assemblage de composant
Nous avons pu voir dans ce chapitre en quoi les composants représentent une
évolution logique pour l’approche d’assemblage de composant. On a discuté des
évolutions naturelles comme un pas vers la réutilisation. Puis on a présenté les
aspects innovants des composants dans la programmation modulaire par rapport aux
composants dans la programmation orientée objet, orientée composant et
composant du type Web Services.
Pour conclure, les composants ne sont pas la réponse universelle, mails ils
représentent sans doute un progrès pour l’industrie de logiciel. Il n’existe pas non
2.3 Assemblage de composant 67
plus de modèle universel qui adresse tous les besoins du client. Il est donc important
de choisir les points forts du concept de composant en fonction des besoins, ainsi
que l’évolution potentielle de ces besoins. C’est l’idée du concept d’Archises que
nous allons aborder dans le chapitre suivant. Ce chapitre a aussi présenté les travaux
de la communauté XSLT sur l’utilisation des techniques de transformation.
La figure 26 a montré comment trouver un prix minimum pour le concept
d’assemblage de composant. En fait, plus on décompose un système en plusieurs
composants, plus on a le coût des interfaces à résoudre. Il faut donc trouver un bon
design pour le système d’information, c'est-à-dire un équilibre entre les composants
et les interfaces [oLowy] [wLowydotNET]. C’est un des objectifs que nous
essayons de proposer dans le chapitre de contribution.
Figure 26 : Prix minimum et bon design pour composant
68 Chapitre 2 : Etat de l’art
2.4 Architectures intelligentes pour la création de services
2.4.1 Framework .NET 2.x de Microsoft (sortie début 2006) [wDotNet] 2.4.1.1 Evolution de système opération & présentation de Framework .NET
L’informatique, durant ces vingt dernières années, a beaucoup changé que ce soit
côté matériel que du côté logiciel. Nous essayons de faire le tour dans le passé, dans
les grandes dates de l’ère Microsoft (figure 27):
1981 : la sortie du système d’exploitation MS-DOS et langage Basic (Quick Language).
1990 : première version Windows graphique et langage Visual Basic.
1997 : Internet et la sortie de VisualStudio 6 et serveur Web IIS.
Figure 27 : Evolution des langages et l’OS
A partir du 2000 : le début de l’ère .NET et Web Services et les version Windows
200x et Windows.NET. Donc, qu’est-ce c’est .NET ? En fait, .NET ou dotNET est
une nouvelle stratégie de Microsoft en réponse à l’évolution du Web. Elle se
présente comme une vision de la prochaine génération d’applications qui repose sur
des standards tels que XML, SOAP, WSDL,…[wXML] [wWeb Services]
2.4 Architectures intelligentes pour la création de services 69
L’environnement .NET a été conçu pour supporter plusieurs langages. Pour
atteindre cet objectif, .NET utilise le langage pivot MSIL (Microsoft Intermediate
Language).
2.4.1.2 Pourquoi le framework.NET ?
Nous voyons bien ici une vague d’évolution des technologies qui s’écoule très vite
aujourd’hui (figure 28). Cela touche de plus en plus notre vie quotidienne,
notamment des technologies que propose Microsoft fait couler beaucoup d’encre
car il est un concept « très ouvert » par rapport aux autres concepts de Microsoft
dans le passé [aMeijer].
Figure 28 : Intelligence dans l’évolution des technologies
2.4.1.3 Moteur d’assemblage « Commun Runtime Language » 2.4.1.3.1 Définition du moteur Visual Studio.NET CLR
Le moteur d’exécution est un moteur .NET permettant d’assembler et créer
rapidement des nouveaux services. Il est le cœur de l’architecture .NET.
70 Chapitre 2 : Etat de l’art
CLR Common Runtime Language : CLR (figure 29) est un moteur d’exécution
pour assembler les codes en MSIL et les codes natifs du système pour les convertir
en code exécutable selon le type de l’OS, ce travail est fait via un compilateur JIT.
CLR est un environnement permettant l'exécution de code compilé sous forme de
MSIL. Jusqu’avant l'exécution, le CLR compile le code MSIL en code machine
natif grâce à un compilateur Just In Time (JIT). Pendant l'exécution la mémoire est
automatiquement gérée par le CLR, grâce à un Garbage Collector.
Figure 29 : Architecture .NET & CLR
2.4.1.3.2 MSIL (Microsoft Intermediate Language)
C’est un langage intermédiaire dans le framework .Net proposé par Microsoft, il
permet de convertir les codes qui sont écrits en plusieurs langages tels que C#,
VB.Net, VC.net ou Cobol.Net (figure 30).
L’avantage est de créer un langage commun pouvant exécuter sur n’importe quel
l’OS à condition il y a un framework pré installé.
MSIL est aussi le langage intermédiaire constitué des instructions élémentaires de
type « assembleur évolué ». Tous les langages supportés par la plate-forme .NET
peuvent être compilés en code intermédiaire MS IL. Ce code intermédiaire peut
2.4 Architectures intelligentes pour la création de services 71
ensuite être exécuté par le CLR, l'environnement d'exécution de la plate-forme
.NET. MS IL permet l'indépendance du langage de la plate-forme .NET [wMono].
Figure 30 : MSIL & assemblage de composants en .NET
2.4.1.3.3 Architecture.NET
Un des avantages de l’architecture du Framework.Net est un environnement de
création rapide de nouveaux services. Il permet à un programmeur d’écrire en
langage de haut niveau et d’exécuter sur n’importe quel l’OS. En fait, le code .NET
est compilé en deux étapes : il est d’abord converti en langage intermédiaire, MSIL,
puis le compilateur JIT (Just-In-Time) utilise ces instructions MSIL pour le
convertir en langage natif qui est ensuite exécuté par le CLR. On peut très bien
mélanger et faire des classes en différents langages supportés par .NET et faire
exécuter ensemble dans le même projet.
2.4.1.3.4 Assemblage de composants dans .NET
Que fait un assemblage de composants dans le framework .NET? En fait, il est le
conteneur physique des classes qui seront utilisées par des applications. Un
assemblage est généré automatiquement chaque fois qu’on crée un exécutable ou
72 Chapitre 2 : Etat de l’art
une dll. Il contient quatre blocks de base : manifest, metadata, Intermediate
Langugage et ressources. Il a un numéro unique pour contrôler la version de
chaque assemblage.
La figure 31 illustre le mécanisme d’assemblage de composants dans .NET
Figure 31 : Assemblage de composants dans .NET
- Le metadata permet d’interroger l’assemblage sur ses types de données, ses
méthodes…
- Le manifest contrôle des exigences de versions, l’auteur de l’assemblage, les
autorisations de sécurité et les dépendances avec d’autres assemblages.
- Les ressources : images, sons, textes...
- La dernière chose est Intermediate Language, MSIL [oPlatt]. Il est le code
intermédiaire de Microsoft, permettant notre application de pouvoir exécuter dans le
CLR. Ce code compilé en MSIL sera ensuite compilé une deuxième fois en code
natif selon l’environnement d’exécution.
2.4 Architectures intelligentes pour la création de services 73
Un assemblage peut se présenter sous trois formes différentes : un ensemble de
DLL et de fichiers EXE, un fichier CAB qui regroupe les fichiers sous une forme
compressée, un paquet Windows Installer.
2.4.1.4 Conclusion de .NET
Les idées proposées par Microsoft sur le Framework.NET sont bonnes mais
l’implémentation est toujours propriétaire, faut il se méfier de celui-ci ? L’idée dont
nous avons parlé est simple, faire tourner les applications sur Windows mais aussi
sur Linux en installant le fameux framework.NET. Ce framework est facile à
installer dans n’importe quel PC dans le monde entier. Elle est basée sur des
standards du marché et du W3c tels que Web Services et XML. Mais ça fait 3 ans
que cette solution a été lancée, elle est toujours axée sur Windows mais peu difficile
à implémenter sur Linux.
74 Chapitre 2 : Etat de l’art
2.4.2 JAIN-Sun (Java Advanced Intelligent Network) – un modèle appliqué de réseau intelligent
Le modèle JAIN [wJain], animé par SUN, est basée sur le concept de réseau
intelligent et pour combler les faiblesses du réseau intelligent traditionnel à savoir
notamment la non standardisation des composants réutilisables et des interfaces de
programmation (API) pour les différents éléments de l’infrastructure du réseau
intelligent. Le modèle JAIN est un ensemble des APIs permettant de développer
rapidement des produits de télécommunication et des services de prochaine
génération sur la plate-forme Java. JAIN APIs apporte la portabilité de service, la
convergence de l'accès au réseau téléphonique et aux réseaux informatiques. JAIN
propose une technologie de logiciels à composants du monde informatique
indépendants des plates-formes, en l’occurrence JavaBeans [wEJB] et une
bibliothèque d’APIs Java telles que JAIN TCAP,JAIN ISUP,JAIN MAP,JAIN INAP.
JAIN est composé de trois couches correspondant au réseau intelligent (figure 32) :
- La couche de réseau qui gère les terminaux (Call Control Point in RI),
- La couche de signal (Signaling Service Point - SSP en RI),
- La couche de service qui permet d’ajouter les nouveaux services (Service Control Point -SCP in RI).
Figure 32 : JAIN
2.4 Architectures intelligentes pour la création de services 75
L’objectif de JAIN est d’assurer la convergence de portabilité de services et de permettre d’accéder à tout type de terminal. L'idée fondamentale est de fournir un automate simple pour traiter le multimédia, le multi protocole en utilisant le réseau intelligent et réseau sur IP.
Le modèle JAIN apporte :
- La portabilité de service: écrire une fois, exécuter n'importe où,
- La convergence avec n’importe quel réseau,
- L'accès à tout type de terminal,
- L’assemblage de composants JavaBeans.
Le consortium JAIN, SUN propose la création de services par assemblage de
composants JavaBeans uniquement, ce qui est assez fermé dans le contexte actuel car
le développeur devrait avoir la liberté d’utilisation du langage de programmation
selon son habitude. En plus, l’utilisateur de JAIN est obligé d’utiliser la
programmation dans le monde de SUN : Java & JavaBeans.
2.4.3 CTI (Couplage Téléphonie Informatique) CTI - « Computer Telephony Integration » ou Couplage Téléphonie Informatique
[aChouCTI]. Il a pour but de réunir les deux domaines, l’informatique et la
téléphonie pour créer de nouvelles applications communes. L’intérêt de CTI est un
gain de productivité important dans la gestion téléphonique et une meilleure qualité,
efficacité du service rendu aux clients. La figure 33 illustre le fonctionnement de
CTI.
Figure 33 : CTI
76 Chapitre 2 : Etat de l’art
Le CTI permet à l’utilisateur d’un poste de travail de contrôler les fonctions de son
téléphone (décrocher, raccrocher, transfert d’appel). Il permet aussi aux centres
d’appels de bénéficier des différents services offerts par l’informatique tels que
l’accès à des bases de données, supervision d’appels, routage. En général, le réseau
intelligent est appliqué dans la téléphonie publique PSTN pour le traitement
intelligent des appels. Au contraire, l’environnement CTI est plutôt orienté vers les
clients finaux.
Le CTI comporte trois composants : le «switch-to-host interface», l’API et le « CTI
ressource architecture ». Le «switch-to-host interface» est l’interface du type CSTA
(Computer Supported Telephony Applications) [wCSTA] ou SCAI (Switch to
Computer Application Interface) qui fournit la connexion entre le PABX et le
serveur CTI. L’API permet à un développeur de créer une nouvelle fonction ou un
service pour le CTI. Le « CTI ressource architecture » est le gestionnaire de la
téléphonie et des ressources dans le système telle que la reconnaissance de la voix.
L’idée de CTI est bien mais il est un protocole « propriétaire », pas tout à fait
ouvert. Il est basé sur des services téléphoniques pour étendre le monde des PABX
à l’informatique. De plus, l’API de CTI est très complexe à implémenter. Enfin,
avec CTI, il faut investir dans un logiciel propriétaire très onéreux, très peu
extensible et difficilement adaptable à ses propres besoins. Il faut donc développer
des systèmes plus ouverts qui répondent à ses principales attentes du client, et qui
pourraient être étendu par des communautés autres que PABX. C’est notre
contribution dans le chapitre suivant.
2.4.4 Conclusion sur les architectures intelligentes 77
2.4.4 Conclusion sur les architectures intelligentes
Aujourd’hui, presque tous les grands éditeurs de logiciels américains ont lancé leur
technologie orientée intermédiation et création de services (Service-driven
Networking), notamment .NET de Microsoft lancé en juillet 2000 et ONE (Open Net
Environment), JAIN de SUN lancé en février 2001. Ces technologies permettent,
entre autres, de créer de nouveaux services en réutilisant les applications existantes.
Ces nouvelles technologies, loin d’être finalisées de l’aveu même de leurs
concepteurs (« We (Sun) are working openly on chapter two, while they (Microsoft)
are just now starting chapter one. ») [wONE], se sont focalisées pour l’instant sur la
réutilisation des services Web via le protocole SOAP, les « Web Services ».
De nombreux travaux de recherche sont menés dans le monde sur les architectures
intelligentes proprement dit. L’initiative JAIN (2.4.2) qui a pour objectif de combler
les faiblesses du réseau intelligent traditionnel, à savoir notamment la non
standardisation des composants réutilisables et des interfaces de programmation API
pour les différents éléments de l’infrastructure du réseau intelligent. JAIN propose
une technologie de logiciels à composants du monde informatique indépendante des
plates-formes, en l’occurrence JavaBeans et une bibliothèque d’APIs Java telles que
JAIN TCAP, JAIN ISUP, JAIN MAP ou JAIN INAP.
Effectivement, il y a une tendance à déplacer l’intelligence de service dans le monde
intermédiaire, et que .NET, ONE, CTI, eLiza [weLiza], Oxygen [wOxygen] ont
d’autres ambitions, notamment de devenir les systèmes d’exploitation de l’Internet
(« The Network is the Computer ») [oDertouzos].
3.1 Architecture n-tiers d’Archises 79
Chapitre 3 : Architecture Archises
But: proposer l’architecture Archises (Architecture of Intelligent Semantic
Services) pour créer rapidement de nouveaux services à valeur ajoutée,
notamment dans les réseaux téléphonie sur IP. Cela est suivi par un framework de
test dans le chapitre 4 qui implémente Archises pour pouvoir tester ses nouveaux
services.
3.1 Architecture n-tiers d’Archises [aBerners 96] [wMeyers]
Dans les années 80, avec la possibilité de disposer des applications de plus en plus
dans le réseau, le modèle client-serveur s’était imposé dans les architectures
d’informatiques : les utilisateurs profitaient de l’intelligence qui se trouvaient dans
le serveur.
Avec le temps, les informations se multiplient, le serveur dans l’architecture client-
serveur évolue. Il a besoin d’un découpage en l’architecture trois-tiers : le client, le
serveur et la base de données. L’intelligence se partage entre le serveur et la base de
données.
La standardisation des systèmes d’information entraîne la possibilité de dialoguer
entre eux. Un exemple typique est celui de réseau « peer-to-peer » ou de réseau
distribué. Le perfectionnement des protocoles d’échanges, notamment avec
l’émergence des Web Services [wWebServices], permet de concevoir des
architectures distribuées. L’intelligence se partage entre chaque noeud de réseau,
c’est l’architecture n-tiers. Chaque nœud contient certain nombre d’applications, qui
80 Chapitre 3 : Architecture Archises
communiquent et dialoguent entre eux. La figure 34 illustre l’évolution de
l’intelligence dans l’architecture x-tier (un-tier, deux-tiers, trois-tiers, n-tiers).
Figure 34 : Intelligence dans l’architecture x-tiers
Archises est une architecture n-tiers où l’intelligence se trouve dans chaque noeud
de réseau. L’objectif d’Archises est de définir une nouvelle architecture de
création de nouveaux services qui allie les atouts de l’intermédiation (fédération
de services, accès aux services à partir de tout type de terminal) (voir 2.1), du
réseau intelligent (séparation de la logique de service et de la commutation,
assemblage de composants à partir de fonctions de base) (voir 2.2) et de
l’assemblage des composants réutilisables (voir 2.3) et des architectures
intelligentes (voir 2.4).
3.2 Architecture Archises détaillée 81
3.2 Architecture Archises détaillée 3.2.1 Présentation
L'architecture Archises [bNGUYEN EADS01] (Architecture of Intelligent
Semantic Services) a pour but d’offrir de nouveaux services notamment dans le la
téléphonie sur IP.
Le développement des télécommunications d'entreprise s'est effectué autour de
deux axes : les réseaux de téléphonie sur IP (ToIP) à communication de circuits et
les réseaux informatiques à communication de paquets.
L'architecture des réseaux privés de téléphonie s'est traditionnellement organisée
autour d'un système de commutation comprenant un ou plusieurs autocommutateurs
ou PABX (« Private Automatic Branch eXchange ») reliés à un ensemble de
terminaux téléphoniques. Les équipements téléphoniques tendent à migrer peu à
peu de la téléphonie classique vers la téléphonie IP. En dehors de la mode et de
l'attrait de la nouveauté, chacun sait que la téléphonie IP n'est ni meilleure ni moins
chère que la téléphonie traditionnelle. Il est primordial de préparer l'émergence de
véritables nouveaux services à valeur ajoutée avec ces nouveaux produits. Comme
ses systèmes téléphoniques IP partagent la même infrastructure IP que les systèmes
de données classiques, il est naturel de combiner les services de ces deux mondes
des télécommunications et des données afin de proposer de nouveaux services
adaptés aux besoins des utilisateurs.
Archises est une architecture de type trois-tiers, dont la figure 35 ci-dessous illustre
les trois modules : module d’accès aux services en haut, module de multiplexage de
services au milieu et module de présentation de services en bas.
82 Chapitre 3 : Architecture Archises
Figure 35 : Architecture Archises
D'autres protocoles de signalisation, spécifiques à des services particuliers ont été
développés, comme par exemple le protocole LDAP (« Lightweight Directory
Access Protocol ») spécifique aux services d’annuaire ou le protocole HTTP
(« HyperText Transfer Protocol ») spécifique à la navigation Web, etc. Ces
protocoles ne sont habituellement utilisés que pour la mise en œuvre des services
correspondants au sein de réseaux informatiques de transmission de données. Leur
inter fonctionnement avec des protocoles de signalisation de type téléphonie
nécessite que des serveurs de nature différente soient capables de communiquer
entre eux, c’est-à-dire que certains au moins des serveurs aient une connaissance
des « métiers » des autres serveurs. Il en résulte une grande complexité des
protocoles ainsi qu’un manque de souplesse lorsqu’on souhaite faire évoluer les
fonctions offertes.
D’autre part, l’utilisation de serveurs multiples dédiés à des métiers différents
conduit souvent les abonnés à dialoguer successivement avec plusieurs serveurs
3.2 Architecture Archises détaillée 83
pour accomplir une fonction donnée, ce qui affecte l’efficacité et l’ergonomie du
système.
Dans le cadre du Web service [wWebServices] [aLara], il est habituel de traiter des
requêtes d’utilisateur en interrogeant des sources d’information hétérogènes, de
traduire les différentes réponses et de les regrouper dans une page de données d’un
langage de balisage tel que HTML (« HyperText Markup Language ») ou XML
[wXML] (« eXtensible Markup Language »), qui est retournée au logiciel de
navigation Web de l’utilisateur. Ceci peut être réalisé au moyen d’architectures de
type trois-tiers (« three-tier architecture »). Ceci permet de traiter individuellement
des requêtes utilisateur, mais non de lui présenter des services diversifiés auxquels il
a accès.
Le principal but d’Archises est de rendre plus flexibles les architectures de
réseaux de communication, en ce sens qu'elles permettent aisément d'intégrer de
nouveaux services ou de modifier des services existants, en s'affranchissant du
caractère spécifique des interfaces avec les serveurs de différents métiers tout en
offrant une grande richesse fonctionnelle aux abonnés.
Archises propose ainsi un dispositif de supervision de terminaux reliés à un réseau
de communication pour fournir à des abonnés utilisant les terminaux différents
services gérés par plusieurs serveurs dédiés. Le dispositif comprend des moyens
d’interface avec le réseau, un module de présentation de services aux terminaux à
travers lesdits moyens d’interface, un module de multiplexage de services (Portal
Manager) communiquant avec le module de présentation, et un module d’accès
aux services communiquant avec le module de multiplexage. Il comporte
également plusieurs modules d’accès associés chacun à un serveur dédié respectif.
Chaque module d’accès est agencé pour délivrer des pages de dispositif de
supervision de terminaux selon de type de chaque terminal que nous pouvons
appeler les terminaux virtuels (virtual terminal).
84 Chapitre 3 : Architecture Archises
Les principaux mécanismes d’Archises seront détaillés par la suite afin de mieux
comprendre le fonctionnement de l’architecture Archises.
3.2.2 Connecteur (virtual application)
Au cœur de l’architecture Archises se trouve un connecteur ou application
virtuelle (figure 36), qui est une entité fonctionnelle ayant pour tâche d’assurer la
conversion des données hétérogènes en un langage intermédiaire afin de
consolider les données externes au niveau de l’intermédiation intelligente.
Figure 36 : Connecteur d’Archises
3.2.3 Transformateur & enrichissement 3.2.3.1 Mécanisme de transformation Archises
Une entité fonctionnelle, nommée transformateur (moteur d’intégration, figure 37),
peut transformer un service particulier en un service à valeur ajoutée
[oMesserchmitt 03] [oFennader]. Par exemple, la réponse d'un annuaire LDAP,
« nom - prénom - numéro de téléphone » , peut être transformée en « nom - prénom
3.2 Architecture Archises détaillée 85
- numéro de téléphone - touche interactive Appel (no tel) -
pré[email protected] - touche interactive Messagerie ».
Les règles de transformation [bNGUYEN EADS02] peuvent aussi décrire les
libellés du message dans les différentes langues et sous plusieurs formes afin de
délivrer le service dans la langue de l'utilisateur et selon le type de son terminal. Le
transformateur peut également ajouter un niveau d’intrusion qui permet
d'interrompre ou non un service en cours d'exécution.
Figure 37 : Moteur d’intégration d’Archises
Le transformateur est régi par les règles de transformation écrites par le créateur
de services.
3.2.3.2 Langage de transformation de service
Ce langage permet de transformer un service particulier en un service à valeur
ajoutée et aussi d'adapter le service en fonction de l'utilisateur et de son terminal.
86 Chapitre 3 : Architecture Archises
Comme Archises se focalise volontairement à la définition, à l'analyse et à la
validation d'une nouvelle architecture de services, il n’est pas envisagé de
développer des outils conviviaux de création de services. Les langages de script et
de transformation permettront par ailleurs aux créateurs de services de développer
rapidement de nouveaux services à partir d’un simple éditeur de texte avec l'aide
d'un environnement de création de services (voir détail en 3.3).
Compte tenu de l'état de l'art actuel et de la disponibilité des outils de
développement, ces langages seront à priori basés sur une syntaxe XML.
(voir le détail de l’implémentation du mécanisme de transformation dans 4.2.1)
Figure 38 : Transformation dans Archises
3.2.4 Déclencheur (ou triggering)
Ce mécanisme consiste en l’interruption du traitement classique pour activer la mise
en œuvre d’un service externe particulier lorsque les conditions de déclenchement
sont vérifiées (figure 39). Il peut avoir lieu au niveau du serveur : c’est le cas de la
téléphonie publique où le déclenchement s’effectue dans l’autocommutateur (par
exemple suite à la détection d’un numéro vert). Mais Archises propose également
d’étendre ce mécanisme à tout type de serveur, qu’il s’agisse ou non de téléphonie.
3.2 Architecture Archises détaillée 87
Figure 39 : Mécanisme de déclenchement (triggering) d’Archises
Archises propose aussi d’étudier l’exécution de ce mécanisme à l’intérieur même du
niveau d’intermédiation. Il est pris en charge par une entité fonctionnelle nommée
déclencheur. Nous pourrons étudier le mécanisme de déclenchement à différents
niveaux : serveur, connecteur ou intermédiation proprement dite.
Figure 40 : Mécanisme de déclenchement (triggering) d’Archises
88 Chapitre 3 : Architecture Archises
3.2.5 Moteur d’assemblage d’Archises (ou moteur d’intégration)
Le mécanisme de déclenchement peut être amené à activer la mise en œuvre d'un
service particulier par une entité fonctionnelle appelée moteur d’intégration.
Dans les années 1970, un programme (phase de développement) était vu comme
une suite d'instructions en langage machine, lesquelles étaient
préalablement « micro-codées » (phase de micro programmation) en une suite de
micro-instructions.
Dorénavant, on peut considérer un programme ou un service (phase de création de
services) comme une suite de fonctions contenant une suite d’instructions en
langage machine (phase de développement).
Archises préconise ainsi le développement rapide de nouveaux services par
l'assemblage de fonctions réutilisables (phase de création de services).
La figure 41 montre le mécanisme d’assemblage des fonctions d’Archises
Figure 41 : Assemblage des fonctions d’Archises
3.2 Architecture Archises détaillée 89
L’assemblage des fonctions de base est décrit par un script (fourni par le
créateur de services) et exécuté au niveau du moteur d’intégration. Celui-ci ne voit
que des fonctions de base locales qui peuvent être réellement présentes au niveau de
l’intermédiation et donc directement accessibles. Lorsque les fonctions de base
réutilisables sont distantes, elles sont représentées en local par des connecteurs.
Prenons un exemple ci-dessous :
Figure 42 : Moteur d’assemblage et d’intégration d’Archises
Une invocation de service classique ou appel de procédure peut être décrit en XML,
le métalangage courant de l'Internet. Comme un appel de procédure classique, un
appel de procédure XML a fatalement un nom et des paramètres en entrée et en
sortie.
<?xml version="1.0"?>
<methodCall>
<methodName> ….. </methodName>
<input_Params>
<param>
90 Chapitre 3 : Architecture Archises
<value> ….. </value>
</param>
</input_Params>
<output_Params> ….. </output_Params>
</methodCall>
Les appels de procédure XML sont particulièrement efficaces pour l'enchaînement
automatique des traitements dans lequel certains paramètres XML ou balises XML
en sortie d'une procédure sont utilisés par une autre procédure. Le moteur
d'intégration du niveau d'intermédiation Archises enchaîne les procédures en
suivant une définition de service à valeur ajoutée Archises, décrite elle aussi en
XML.
<?xml version="1.0"?>
<Archises_Service>
<matched_Event> …. </matched_Event>
<methodCall> …. </methodCall>
<methodCall> …. </methodCall>
</Archises_Service>
Les services à valeur ajoutée Archises sont définis, intégrés, testés et déployés par
les intégrateurs. Les développeurs de procédures ou d'applications ne sauraient
jamais ce que les intégrateurs font avec leurs programmes. Archises peut
pratiquement intégrer n'importe quel programme. Tous les grands éditeurs de
logiciels comme Microsoft, Sun Microsystems, IBM, Oracle ont annoncé des
interfaces XML [wXML] pour leurs applications. Pour les applications classiques,
Archises propose de traduire les interfaces natives en XML Archises.
3.2 Architecture Archises détaillée 91
3.2.6 Adapter à tout type de terminal
Figure 43 : Adaptation à tout type de terminal d’Archises
Comme les données externes provenant des différents producteurs ou serveurs sont
hétérogènes, il est nécessaire que Archises les représente dans un format commun
(figure 43-44). Les données représentées dans ce langage intermédiaire peuvent être
ensuite traduites dans le format adapté à chaque type de terminal. Le niveau
d'intermédiation permet ainsi aux terminaux de différents types d'accéder à
différents types de services.
Figure 44 : Adaptation à tout type de terminal d’Archises
92 Chapitre 3 : Architecture Archises
L’intermédiation permet aux terminaux de déporter leur logique de service, une
fonction client de messagerie par exemple. Les terminaux peuvent devenir très
simples et donc peu coûteux car ils réclament peu de ressources logicielles et
matérielles. Une architecture de terminal très simple (thin client computing)
d'intermédiation peut aussi gérer des terminaux complexes grâce au langage
intermédiaire (figure 45).
Figure 45 : Terminal très simple
3.3 Environnement de Création de services 93
3.3 Environnement de Création de Services 3.3.1 Le besoin d’un environnement de création de services
dans Archises
Dans un premier temps, ces services dans Archises sont testés et déployés dans le
réseau de la téléphonie sur IP. Le problème est de comment créer des composants
d’Archises d'une manière rapide. C'est-à-dire, comment à partir d’une expression
d'une simple idée de service, aboutir à un service tout prêt à être utilisé. Cela nous
mène au processus de création de services RSCE (Rapid Service Creation
Environment). Ce processus est important car il peut influencer énormément sur la
qualité du service ainsi que la possibilité de son adaptation ou modification dans le
futur ou interaction entre ces services. On commence par la définition des acteurs
qui interviennent lors de ce processus et ensuite on énumérera les étapes pour la
création de services dans l’environnement RSCE d’Archises [aNGUYEN
ICCCN02].
3.3.2 Les acteurs dans le processus de création de services
Le processus de création de services [aLui] fait intervenir un ensemble d’acteurs. Ils
interviennent dans tout le cycle de vie d’un service, depuis la détection du besoin
d’un service jusqu’à son déploiement sur le réseau. Nous précisons la relation entre
les acteurs ainsi que leurs rôles dans un cycle d’un service.
- Fournisseur d’accès : son rôle consiste à offrir le lien entre les équipements des
clients et les équipements de service lors de l’accès aux services. Il doit aussi avoir
une documentation permettant une description de son réseau et des services qui y
sont déployés.
- Fournisseur de ressources : il gère des ressources en deux phases : la phase de
création et la phase d’exécution. Lors de la phase de création, on trouve les langages
de programmation, les gestionnaires de bases de données pour stocker les
94 Chapitre 3 : Architecture Archises
composants. Parmi celles utilisées lors de la phase d’exécution on trouve les super
calculateurs de ressource, la gestion des conflits de ressource.
- Fournisseur de gestion : dans RSCE, le fournisseur de gestion a le droit du
contrôle de la gestion de tout le domaine en offrant des services de gestion au
fournisseur d’accès. Il est le gestionnaire de service : offre des services de gestion
comme l’installation et déploiement des services, offre des services de maintenance
des équipements de réseau, contrôle de la qualité du réseau.
- Créateur de service (figure 46): c’est le nouveau venant du monde des
télécommunications. Arrivant au monde informatique, son rôle est de développer la
logique de service en utilisant des composants existants ou en créant dès le début.
Il joue le rôle central dans le processus de création de services d’Archises. Grâce à
lui, le producteur peut communiquer avec le consommateur à la manière souple,
rapide.
Figure 46 : Créateur de service
3.3.3 RSCE – environnement de création rapide de nouveaux services
Figure 47 : Création de services
3.3 Environnement de Création de services 95
Le processus de création de services (figure 47) se compose en trois phases :
développement, assemblage et déploiement. La phase de développement est de
créer les micro-services, ce sont les services primitifs de base d’Archises. Cette
phase utilise des outils de développement intégrés, des outils de création de
services. La phase d'assemblage a pour but d'assembler ces micro-services en
utilisant les moteurs d'assemblage. La phase de déploiement a pour but de délivrer
les services qui sont créés dans la phase d'assemblage, ceci qui n’est pas dans le
contexte de ce travail d'Archises. La figure 48 illustre le processus de création de
services.
Figure 48 : Processus de création de services
Actuellement, l’approche de codage manuel multitude de If est très populaire.
Cela conduit toujours à développer des interactions entremêlées, difficilement
intelligibles, coûteuses à maintenir et à faire évoluer, et surtout, les codes sont très
difficiles à réutiliser.
Le processus de création de services est géré par le créateur de service. Son rôle
est d’assembler des composants existants ou de créer un nouveau service dès le
début (figure 49).
Les programmeurs traditionnels conçoivent des composants logiciels, les créateurs
de service conçoivent de nouveaux services en assemblant des composants
logiciels. Le cycle de développement (analyse, codage et test) est semblable dans
les deux cas. Il est seulement notablement plus court dans le cas de la création de
services car ce n'est qu'un processus d'assemblage de composants. Le RSCE est un
96 Chapitre 3 : Architecture Archises
environnement de travail commun permettant de créer et d'assembler les services
grâce à des composants (SIB ou non-SIB). Il est géré par le créateur de service.
Figure 49 : Rapid Service Creation Environment
3.3.4 Langage SCDL (Service Creation Description Language) de création de services
Pour créer un nouveau service, le créateur de service devrait utiliser un langage
comme son outil pour constituer ce service. On appelle ce langage SCDL (Service
Creation Description Language) (voir Annexe A). Ce langage a été développé et
utilisé dans l’architecture Archises.
Ce langage a pour but de créer facilement de nouveaux services via des automates
du langage. Il permet de transformer des données hétérogènes en format commun. Il
peut assembler, combiner les services hétérogènes. Il est construit à partir de la
syntaxe XML Schéma [wXML Schema], qui est lui-même bâti sur XML. De plus,
il peut représenter des scénarios dans les modules d’architecture Archises: le
déclencheur & moteur d’intégration, le module de transformation et le module
« Context Manager »
Avec les services de base, prenons un exemple, des services comme +;-,*, / et 13
composants SIBs [rIN Q12xx]
3.3 Environnement de Création de services 97
<basic_services>
<SIB1/>
<SIB2/>
...
<SIB13/>
<function name="PlusAB">
<input>
<value>A</value>
<value>B</value>
</input>
<output>C</output> //C=A+B
</function>
<function name="MinusAB">
<input>
<value>A</value>
<value>B</value>
</input>
<output>C</output> //C=A- B
</function>
98 Chapitre 3 : Architecture Archises
<function name="MulAB">
<input>
<value>A</value>
<value>B</value>
</input>
<output>C</output> //C=A* B
</function>
<function name="DivAB">
<input>
<value>A</value>
<value>B</value>
</input>
<if>
<value>0</value>
<output> Error divided by 0 </output>
</if>
<else>
<output>C </output > //C=A / B
</else>
3.3 Environnement de Création de services 99
</function>
</basic_services>
Basés sur les services de base, le créateur de service peut créer facilement de
nouveaux services. Par exemple, pour créer un service comme la conversion franc
français en dollar américain. Pour faire cela, le créateur de service a donc besoin de
deux services de base, MulAB et DivAB.
Supposons que: 1 USD = 1 (FF / 6.5597) *1.20. Le script pour ce service :
<function name="francToDola ">
<input>
<value>franc</value>
<value constant="true">Rate1</value>
//Taux1= 6.5597 = francTo€uro
<value constant="true">Rate2</value>
//Taux2=1.20 = €uroToDollar
</input>
<functionCall> DivAB(franc, Rate1, &C)</functionCall>
<functionCall> MulAB(C, Rate2, &D)</functionCall>
<output>D</output>
// D = franc / 6.5597 *1.20
</function>
100 Chapitre 3 : Architecture Archises
Figure 50 : Schéma pour le langage SCDL
Avec SCDL, le créateur de service peut traiter un message venant de n’importe quel
service hétérogène via ses mécanismes prédéfinis. Par exemple, quand il y a un
message venant d’un Web service, selon des règles prédéfinies par le créateur de
service, les actions correspondantes peuvent être déclenchées.
Voici la syntaxe pour la figure 50:
<xsd:element name="services">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="telephony"/>
<xsd:element ref="ldap"/>
<xsd:element ref="http-service"/>
<xsd:element ref="web-service"/>
<xsd:element ref="triggering" minOccurs="0"/>
</xsd:choice>
</xsd:complexType></xsd:element>
3.3 Environnement de Création de services 101
<xsd:element name="web-service">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="id" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
<xsd:element ref="transformation" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
3.3.5 Les mécanismes d’Archises écrits en SCDL 3.3.5.1 SCDL dans le mécanisme de transformation
La syntaxe SCDL dans le mécanisme transformation d’Archises (figure 51) :
Figure 51 : SCDL
102 Chapitre 3 : Architecture Archises
<xsd:element name="transformation">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input" type="xsd:string"/>
<xsd:element name="ruleToXML" type="xsd:string"/>
<xsd:element ref="toXML" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="toXML">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input_XML" type="xsd:string"/>
<xsd:element name="RuleAddTag" type="xsd:string"/>
<xsd:element ref="informative_message" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType></xsd:element>
<xsd:element name="informative_message">
<xsd:complexType>
3.3 Environnement de Création de services 103
<xsd:sequence>
<xsd:element name="input_infor_mes" type="xsd:string"/>
<xsd:element name="intrusion_xx" type="xsd:string"/>
<xsd:element ref="intrusion" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="intrusion">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input_infor_mes" type="xsd:string"/>
<xsd:element name="language_yy" type="xsd:string"/>
<xsd:element ref="multilanguage" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="multilanguage">
<xsd:complexType>
<xsd:sequence>
104 Chapitre 3 : Architecture Archises
<xsd:element name="result" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
3.3.5.2 SCDL dans le mécanisme de déclenchement
La syntaxe SCDL dans le mécanisme déclenchement d’Archises (figure 52) :
Figure 52 : Mécanisme de déclenchement
<xsd:element name="triggering">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="context" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
3.4 Services à valeur ajoutée dans Archises 105
3.4 Services à valeur ajoutée dans Archises Le but principal d'Archises est de rendre plus flexibles les architectures de
réseaux de communication, en ce sens qu'elles permettent aisément d'intégrer de
nouveaux services ou de modifier des services existants, en s'affranchissant le
caractère spécifique des interfaces avec les serveurs de différents métiers tout en
offrant une grande richesse fonctionnelle aux abonnés.
Archises propose ainsi un dispositif de supervision de terminaux reliés à un réseau
de communication pour fournir à des abonnés différents services gérés par plusieurs
serveurs dédiés. Le dispositif comprend des moyens d’interface avec le réseau, un
module de présentation de services aux terminaux à travers lesdits moyens
d’interface, un module de multiplexage de services communiquant avec le module
de présentation, et un module d’accès aux services communiquant avec le module
de multiplexage (Portal Manager). Il comporte plusieurs modules d’accès associés
chacun à un serveur dédié respectif.
Chaque module d’accès est agencé pour délivrer des pages de données balisées au
module de multiplexage en réponse à des messages entrants issus du serveur dédié
et/ou à des requêtes de page issues du module de multiplexage. Il est également
agencé pour délivrer des données de fusion au module de multiplexage en réponse à
des requêtes de fusion. Chaque page délivrée est associée à un abonné avec lequel
le module de multiplexage (Portal Manager) a une session de communication en
cours par l’intermédiaire du module de présentation. Certaines pages délivrées au
module de multiplexage contenant des codes de fusion se rapportant à des services.
Le module de multiplexage comprend des moyens de traitement de chaque page
reçue du module d’accès pour détecter les codes de fusion, adresser une requête de
fusion au module d’accès associé au serveur dédié gérant le service auquel se
rapporte chaque code de fusion détecté, substituer les données de fusion délivrées
par ledit module d’accès en réponse à la requête de fusion à un champ de la page
106 Chapitre 3 : Architecture Archises
incluant le code de fusion détecté, et fournir la page traitée au module de
présentation dans le cadre de la session en cours avec l’abonné associé.
Chaque page fournie au module de présentation contient des données balisées
décrivant, selon un format indépendant des terminaux, des éléments d’interaction
avec l’abonné associé.
Le module de présentation comprend des moyens de contrôle de terminaux
interprétant chaque page reçue du module de multiplexage dans le cadre d’une
session en cours avec un abonné utilisant l’un des terminaux, de façon à générer des
commandes adaptées à la présentation sur le terminal à partir d’éléments
d’interaction décrits par les données balisées de la page.
Le module de multiplexage comprend en outre des moyens de routage afin de
recevoir des adresses de page depuis le module de présentation dans le cadre d’une
session en cours avec un abonné, identifier un module d’accès auquel est destinée
l’adresse de page reçue, et transmettre une requête de page correspondante au
module d’accès identifié.
Le dispositif a une architecture de type trois-tiers, et joue un rôle d’agent « proxy »
vis-à-vis des terminaux pour les différents services gérés par les serveurs dédiés.
Ces services sont multiplexés par un module central qui tient des sessions avec des
abonnés sans avoir de connaissance particulière sur les services gérés par les
serveurs dédiés ni sur les caractéristiques physiques des terminaux.
Le module de multiplexage (Portal Manager) combine des éléments relevant de
différents métiers dans les données qui sont fournies pour la présentation des
services aux abonnés. Pour cela, il associe simplement des codes de fusion
déterminés à des modules d’accès auxquels il adresse les requêtes permettant de
compléter les pages précédemment reçues. Ce sont ces modules d’accès qui, de
façon autonome ou en liaison avec serveurs dédiés, incorporent une connaissance
des métiers correspondants pour fournir les données requises par le module de
multiplexage.
3.4 Services à valeur ajoutée dans Archises 107
Il est donc relativement aisé d’enrichir ou de faire évoluer le système. L’ajout ou la
substitution de nouveaux serveurs dédiés fonctionnant selon des protocoles
spécifiques n’implique pas la remise en cause des protocoles utilisés par ailleurs
dans le système.
Dans une réalisation préférée du dispositif, les données balisées contenues dans
certaines pages fournies au module de présentation décrivent, en plus des éléments
d’interaction avec l’abonné associé, au moins un lien entre l’un desdits éléments
d’interaction et une adresse de page.
Les moyens de contrôle de terminaux du module de présentation sont alors agencés
pour associer chaque lien d’une page reçue du module de multiplexage dans le
cadre d’une session en cours avec un abonné utilisant l’un des terminaux, à un
événement pouvant se produire au niveau du terminal, et pour retourner l’adresse de
page dudit lien au module de multiplexage dans le cadre de ladite session en
réponse à une occurrence dudit événement.
D'autres particularités et avantages de la présente d'Archises apparaîtront dans la
description d'exemples de réalisation non limitatifs, en référence aux dessins
annexés ci-dessous :
Figure 53 : Architecture Archises
108 Chapitre 3 : Architecture Archises
Dans l’exemple de réalisation décrit ci-après, des équipements terminaux de
différents types ont accès, par l’intermédiaire d’un réseau de communication
d’entreprise, à des services diversifiés de téléphonie, d’annuaire LDAP, de
navigation Web sur un réseau Internet ou Intranet qui sont fournis par un ensemble
de serveurs dédiés reliés au réseau.
La figure 53 ci-dessus montre aussi les terminaux de différents types (par
exemple terminal WAP et terminal http du type Web) raccordés à un réseau de
communication en mode paquet fonctionnant selon le protocole IP (« Internet
Protocol »). Le réseau peut être un réseau local qui est équipé d’une organisation
pour fournir des services de transmission de données aux détenteurs des terminaux.
Il est par exemple constitué de plusieurs sous réseaux de type Ethernet entre
lesquels la commutation des paquets IP est effectuée de façon classique par des
routeurs non représentés.
Plusieurs serveurs, dédiés aux services considérés, sont par ailleurs connectés au
LAN : un serveur de téléphonie sur IP, un serveur d’annuaire LDAP, un serveur
Web.
Le module principal, le cœur de l’architecture Archises est la partie Portal
Manager, il est également raccordé au réseau LAN. Ce dispositif remplit la fonction
d’un proxy, c’est-à-dire que, pour accéder aux services gérés par les serveurs dédiés
(serveur de téléphonie sur IP) du réseau, les terminaux ne peuvent ouvrir de session
qu’avec le dispositif. D’autre part, la signalisation entrante relative à ces services ne
peut être adressée aux terminaux que par l’intermédiaire du dispositif.
Bien entendu, il est possible que certains des serveurs et le proxy soient réalisés
dans une plate-forme commune. Par exemple, les serveurs de téléphonie seront
fréquemment dans le même équipement de réseau. Le serveur proxy pourra aussi
être dans le même équipement que l’un des serveurs dédiés, par exemple le serveur
de téléphonie sur IP.
3.4 Services à valeur ajoutée dans Archises 109
L’accès aux services regroupe l’ensemble des traitements spécifiques aux différents
services gérés par les serveurs dédiés. Il réalise l’interface du serveur proxy avec les
différents serveurs dédiés, et échange des données en provenance et à destination de
l’entité service selon un format unifié.
Le module d’accès aux services comporte des modules d’accès respectivement
associés aux serveurs dédiés avec lesquels ils sont capables de dialoguer. Chaque
module d’accès effectue les traitements relatifs à la fourniture d’un service par le
serveur dédié associé aux utilisateurs du réseau intégrant le serveur proxy. On
trouve ainsi, dans l’exemple considéré, un module d’accès associé au serveur dédié
de téléphonie sur IP, un module d’accès associé au serveur dédié d’annuaire LDAP,
un module d’accès associé au serveur dédié de navigation Web.
Dans un mode de réalisation d'Archises, chaque module d’accès gère une connexion
au niveau applicatif du modèle OSI avec son serveur dédié associé. La structure des
données échangées et le protocole d’échange de ces données dépendent du service
concerné (par exemple SIP pour la téléphonie sur IP, LDAP pour le service
annuaire, HTTP pour la navigation, etc.).
Dans un autre mode de réalisation, une partie ou la totalité des serveurs dédiés
dialoguent directement avec les modules d’accès correspondants selon une
connexion d’un protocole de niveau transport, typiquement TCP (« Transmission
Control Protocol »), et échangent des pages de données balisées fournissant des
descriptions sémantiques d'éléments selon le langage XML (« eXtensible Markup
Language »). Des grammaires de XML, dont les descriptions de types de
documents (soit en DTD, « Document Type Description » soit en XML Schéma)
ont été développées pour être adaptées à différents métiers, peuvent ainsi être
utilisées pour les échanges entre le serveur proxy et les serveurs des métiers
correspondants.
Le module de multiplexage (Portal Manager, figure 54) réalise l’interaction entre
les différents services gérés par les serveurs dédiés, route les requêtes en
110 Chapitre 3 : Architecture Archises
provenance du module de présentation vers les modules d’accès, et transmet au
module de présentation les données en provenance du module d’accès. Il
administre d’autre part les sessions ouvertes avec les différents terminaux gérés par
le serveur proxy.
Figure 54 : « Portal Manager » d’Archises
Le module de présentation (entité présentation) contient l’ensemble des moyens
de connexion et de dialogue avec les différents types de terminaux compatibles avec
le serveur proxy, et remplit la fonction de présentation des données reçues du
module de multiplexage vers le terminal à partir duquel l’abonné destinataire des
données a ouvert une session avec le serveur proxy. Selon leurs caractéristiques, les
terminaux peuvent être agencés pour communiquer selon différents types de
protocoles de communication. Pour chacun de ces protocoles, le module de
présentation comprend un module d’interface qui organise l’émission et la réception
des messages correspondants.
Les modules d’accès et les modules d’interface terminale du module de
présentation sont reliés à un module d’interface avec le LAN qui accomplit les
fonctions des couches 1 à 4 du modèle OSI. Bien entendu, si le serveur proxy est
3.4 Services à valeur ajoutée dans Archises 111
incorporé au même équipement que l’un des serveurs dédiés, le module d’accès
correspondant pourra dialoguer directement avec ce serveur dédié sans passer par le
module d’interface.
Le module d’accès génère des pages de données balisées, c’est-à-dire des
ensembles de descriptions d'éléments dont la syntaxe est commune à l’ensemble des
modules d’accès, qu'il transmet au module de multiplexage. On utilise des pages de
description de données structurées au sens XML. En variante, on pourrait utiliser
des objets de type COM (« Component Object Model ») tels que proposés par
Microsoft. L’intérêt de telles pages réside dans leur souplesse d’utilisation, et la
possibilité de présenter des données dans un format qui peut être adapté par une
simple opération de filtrage à tout type de terminal.
Les pages XML délivrées par le module d’accès font l’objet d’un traitement dans le
module de multiplexage (Portal Manager), qui sera décrit plus loin, avant d’être
transmises au module de présentation. Les pages XML traitées transmises au
module de présentation contiennent des données balisées qui décrivent, selon un
format indépendant des terminaux, des éléments d’interaction avec les abonnés.
Certains de ces éléments d’interaction sont à présenter de façon dynamique à
l’abonné concerné par la page, le mode de présentation étant défini dans le module
en fonction du type d’interface homme machine dont est pourvu le terminal utilisé
(affichage sur écran de tel type ou telle taille, signalisation sonore, messages
vocaux, etc.) et éventuellement des paramètres de configuration de l’interface
homme machine définis par l’abonné.
Ces éléments présentés de façon dynamique peuvent représenter un contexte
d’abonné (par exemple appel entrant, poste occupé, message reçu, etc.), de
l’information fournie dans le cadre d’un service (par exemple numéro d’annuaire,
contenu d’un message, page Web, etc.), des champs de saisie permettant à l’abonné
d’entrer des informations utiles aux serveurs (par exemple numéro d’appel,
identification de fiche annuaire, message à émettre, etc.), ou des actions que
l’abonné peut sélectionner à l’aide d’un événement programmable dans le module
112 Chapitre 3 : Architecture Archises
de présentation (actionnement d’une touche virtuelle, commande vocale, etc.). Pour
ce dernier type d’élément, les données balisées de la page XML appartiennent à un
lien dynamique qui pointe vers une adresse de page.
D’autres éléments d’interaction décrits dans les pages XML transmises au module
de présentation peuvent se rapporter à des événements déterminés susceptibles de se
produire au niveau des terminaux et définis de façon statique, c’est-à-dire
indépendamment du contexte d’abonné et des éléments dynamiques présentés. Ces
événements, définis au niveau du module de présentation, comprennent par
exemple l’actionnement par l’abonné d’une touche spéciale, l’expiration d’une
temporisation, etc. Les données balisées de la page XML décrivant ce genre
d’élément appartiennent à un lien statique pointant vers une adresse de page.
Dans les liens précités, il est possible d’utiliser des adresses de pages similaires à
des adresses URL (« Uniform Resource Locator ») couramment utilisées dans les
applications de navigation, par exemple de la forme « process_id://page_id », où le
champ « process_id » désigne un processus relevant d’un module d’accès, et le
champ « page_id » désigne une page gérée par ledit processus. Certaines adresses
sont complétées par un ou plusieurs champs de paramètres utiles à la production de
la page désignée, les paramètres correspondants pouvant être fournis explicitement
dans la page XML transmise au module de présentation ou récupérés dans des
champs de saisie décrits dans cette page XML.
Le module de présentation comporte un navigateur XML qui analyse les pages
reçues du module de multiplexage en liaison avec une mémoire contenant le XML
Schema définissant la syntaxe commune de ces pages. Le navigateur extrait les
éléments dynamiques de chaque page reçue pour un abonné, et les fournit au
module de contrôle de l’interface homme-machine du terminal utilisé par l’abonné.
Plusieurs modules de contrôle sont prévus dans le module pour tenir compte des
différents types HM dont peuvent être équipés les terminaux. Ces modules génèrent
les commandes appropriées pour la présentation des éléments requis sur les
3.4 Services à valeur ajoutée dans Archises 113
terminaux, ces commandes sont délivrées par l’intermédiaire des modules
d’interface.
Les modules de contrôle surveillent en outre l’occurrence des événements
correspondant aux liens d’action définis dans la page XML, et avisent le navigateur
de la détection d’un tel événement. En réponse à la détection d’un tel événement, le
navigateur retourne au module de multiplexage, dans le cadre de la session en cours
avec l’abonné concerné, une primitive GET_URL incluant l’adresse de page du lien
correspondant.
En plus, la figure 53 montre schématiquement les composants du module d‘accès
aux services du serveur proxy. Une unité de transformation réalise l’interface
avec le serveur dédié correspondant au module d‘accès considéré. L’unité gère
notamment l’ensemble du dialogue avec le serveur dédié, et transcrit les données
reçues du serveur dans un format uniforme correspondant aux pages échangées au
sein du serveur proxy. Pour cela, il dispose d’une table de traduction qui lui
permet d’associer aux données échangées selon un format spécifique avec le
serveur dédié des balises (« tags ») communes à l’ensemble des modules du serveur
proxy. Une fois traduites, les données reçues sont transmises soit à une unité de
construction de pages dynamiques soit à une autre unité du module appelée serveur
de données de fusion.
L’unité de construction de pages dynamiques organise les données balisées au sein
d’une page XML selon la structure commune définie dans le XML Schéma [wXML
Schema]. La page ainsi constituée est transmise à une unité appelée serveur de
pages qui l’associe à des informations identifiant l’abonné pour lequel elle a été
construite.
114 Chapitre 3 : Architecture Archises
3.5 Fonctionnement des mécanismes dans Archises [aNGUYEN JDIR04]
Deux types de message peuvent déclencher l’envoi d’une page XML du module
d’accès au module de multiplexage :
- un message provenant du serveur associé à destination d’un abonné
identifié. Dans ce cas, l’unité construit la page à émettre à partir des éléments
contenus dans le message de signalisation entrante, conformément à la structure
commune définie dans le langage SCDL correspondant à cet automate.
- une requête de page reçue du module de multiplexage (Portal Manager)
pour un abonné identifié. A la réception d’une requête de page, le serveur de pages
détermine d’abord si la page demandée est une page statique contenue dans la
bibliothèque de pages. Si c’est le cas, il n’est pas nécessaire d’interroger le serveur
dédié : le serveur de pages construit la page à partir de la page statique mémorisée
et des éventuels paramètres fournis avec la requête, puis adresse la page ainsi
obtenue au module de multiplexage en indiquant l’abonné concerné. Sinon, la page
est construite par l’unité qui interroge le serveur dédié à travers l’unité de
transformation lorsque des données extérieures sont nécessaires pour construire la
page. L’unité peut également extraire, des requêtes de page et/ou des données de la
page en construction, des événements ou paramètres qui sont transmis à l’unité de
transformation pour faire remonter la signalisation vers le serveur dédié.
Le module d’accès peut d’autre part recevoir du module de multiplexage (Portal
Manager) des requêtes de fusion qui sont traitées par le serveur de données de
fusion. Une requête de fusion comprend un code de fusion associé à un type de
données de fusion, et éventuellement des paramètres associés. Les serveurs ont des
fonctionnements similaires, le serveur manipule toutefois des données de fusion qui
ne sont généralement pas organisées sous forme de pages. A la réception d’une
requête de fusion, le serveur détermine d’abord si les données demandées sont des
données statiques contenues dans la bibliothèque. Si c’est le cas, il n’est pas
3.5 Fonctionnement des mécanismes dans Archises 115
nécessaire d’interroger le serveur dédié : le serveur récupère les données de fusion
dans la bibliothèque, les complète avec les éventuels paramètres fournis avec la
requête, puis les retourne au module de multiplexage en indiquant l’abonné
concerné. Sinon, le serveur de données de fusion interroge le serveur dédié à travers
l’unité de transformation, en indiquant d’éventuels paramètres fournis avec la
requête, pour obtenir les données extérieures requises et retourne les données de
fusion qui en résultent au module de multiplexage.
Les codes de fusion sont présents dans certaines pages retournées par les serveurs
de pages des modules d’accès. Ils sont généralement accompagnés de paramètres
servant à élaborer les données de fusion. Pour faciliter leur identification dans les
pages XML, ils peuvent comprendre une balise spéciale et un nom de fonction
permettant d’identifier un port logique du module d’accès pour le routage de la
requête de fusion correspondante (ce nom est associé à l’un des modules d’accès et
à un port logique de celui-ci auquel doit être envoyée la requête de fusion
correspondante). Leur syntaxe est la suivante : « %fonction (para1,…, paraN) », où
« % » est la balise caractéristique des codes de fusion « fonction » est le nom de
fonction, et « para1,…, paraN » désignent les N paramètres associés (N ≥ 0).
Certains de ces paramètres associés peuvent eux-mêmes être des codes de fusion,
les parenthèses permettant de séparer les codes de fusion imbriqués selon une
structure arborescente.
Chaque page reçue du module d’accès est analysée par un moteur d’intégration
(moteur d'assemblage). L’opération d'intégration consiste à remplacer les codes de
fusion, présents en association avec d’éventuels paramètres dans une page reçue
d’un module d’accès, par des données de fusion consistant en des données balisées
ou un lien.
Cette opération d'intégration ne nécessite aucune connaissance de l’organisation des
services participant au niveau du module de multiplexage. Les codes de fusion
peuvent être repérés sans effectuer d’analyse détaillée (« parsing ») en détectant
simplement les balises « % » éventuellement présents dans la page reçue. Lorsque
116 Chapitre 3 : Architecture Archises
le moteur d’intégration repère ainsi un code de fusion, il interroge une table de
correspondance sur la base du nom de fonction du code, ce qui lui permet
d’identifier le port logique du module d’accès où acheminer la requête de fusion.
Celle-ci peut être formulée très simplement en recopiant le code de fusion avec ses
paramètres et en identifiant l’abonné concerné. A la réception des données de fusion
retournées pour cet abonné par le serveur de données de fusion du module d’accès
interrogé, le moteur d’intégration les substitue au code de fusion précédemment
repéré.
Les correspondances (nom de fonction du code de fusion, port logique du module
d’accès) sont enregistrées dans la table lors d’une procédure d’installation des
modules d’accès, au cours de laquelle ceux-ci déclarent au module de multiplexage
les noms de fonctions des codes de fusion traités par leurs serveurs de données de
fusion respectifs en indiquant les ports logiques associés. Si un code de fusion
détecté ne figure pas dans la table de correspondance, le moteur d’intégration
supprime simplement ce code de la page XML traitée.
Au cours de la même procédure d’installation, les modules d’accès déclarent au
module de multiplexage les identités « process_id » des processus pris en compte
par leurs serveurs de pages respectifs en indiquant les ports logiques associés. Ceci
permet au module de multiplexage d’enregistrer les correspondances entre ces
identités « process_id » et ces ports logiques dans une autre table.
Le module de multiplexage (Portal Manager) comporte un module de routage qui
reçoit les adresses de pages reçues du module de présentation avec les primitives
GET_URL à la suite d’événements détectés au niveau des terminaux. Le module de
routage interroge la table de correspondance sur la base des identités « process_id »
contenues dans ces adresses pour déterminer le port logique du module d’accès où
la requête de page doit être acheminée, et il transmet cette requête accompagnée des
paramètres correspondants.
3.5 Fonctionnement des mécanismes dans Archises 117
Chaque création d’association d’un couple (terminal physique, abonné) par le
module de présentation donne lieu à une requête d’ouverture de session d’abonné
reçue par un module de gestion des abonnés du module de multiplexage (primitive
OPEN_SESSION). Ce module fonctionne avec une table d’enregistrement des
abonnés pour lesquels une session est ouverte. La requête d’ouverture de session
d’abonné contient des informations indiquant un identifiant d’abonné (par exemple
son numéro d’appel téléphonique) et un port logique du module de présentation
pour l’envoi des pages destinées à l’abonné. Elle contient de plus des informations
relatives à l’authentification de l’abonné, comme par exemple un mot de passe saisi
par ce dernier.
Le module interroge la table afin de s’assurer que l’abonné n’est pas enregistré,
auquel cas il retourne un acquittement négatif NACK qui est transmis au module de
présentation. Dans le cas contraire, il crée un enregistrement dans la table incluant
les informations contenues dans la requête d’ouverture de session, puis renvoie un
acquittement positif ACK à destination de l’entité présentation. Un mécanisme de
suppression d’un enregistrement est aussi prévu, par exemple, dans le cas d’une
dissolution d’un couple (terminal, abonné) qui donne lieu à l’envoi par le module de
présentation d’une requête de fermeture de session d’abonné à destination du
module (primitive CLOSE_SESSION).
La réception d’un acquittement positif ACK par le module de présentation
déclenche une requête de page d’accueil par défaut vers le module de multiplexage
(Portal Manager). Cette requête peut être formulée sous forme de l’adresse de la
page demandée accompagnée de paramètres correspondant à l’abonné (numéro
d’abonné, mot de passe) et aux paramètres d’adressage de son terminal sur le LAN
pour l’acheminement de la voix et des données (paramètres réseau tels que l’adresse
IP, ports UDP, etc.), et relayée comme les autres adresses de page par le module de
routage vers le module d’accès.
Cette page d’accueil par défaut peut notamment être générée par le module d’accès
associé au serveur de téléphonie. Elle peut décrire une mire d’accueil offrant par
118 Chapitre 3 : Architecture Archises
exemple les différents services fournis par les serveurs dédiés connectés, et
précisant à l’abonné son contexte courant téléphonique. Les informations (liens)
relatives aux services disponibles contiennent notamment des adresses de pages
destinées à être transmises par les modules d’accès sur la requête du service. Ainsi,
lorsque l’abonné sélectionne par exemple le service de téléphonie, le module de
présentation transmet au module de multiplexage, dans le cadre de la session
ouverte avec l’abonné, l’adresse de page contenue dans le lien sélectionné.
Connaissant cette session, le module de gestion des abonnés peut renseigner le
module de routage pour que la requête de page soit transmise au module d’accès en
indiquant l’identité de l’abonné, le port logique ayant été obtenu dans la table.
Les modules de gestion des abonnés et de routage interviennent de la même
manière pour les différentes requêtes de pages émanant du module de présentation.
Ainsi, le traitement de ces requêtes par le module de multiplexage (Portal Manager)
ne nécessite aucune connaissance du service concerné par la requête. Le module de
routage se contente de solliciter un port logique en passant en arguments les
informations contenues dans les données reçues du module de présentation ainsi
que l’identification de l’abonné, sans analyser le contenu de la requête ou l’identité
du service qui la traite. Une fois la requête parvenue au module d’accès, elle est
servie comme expliqué ci-dessus, ceci donne lieu à l’envoi par ce module d’accès
d’une nouvelle page XML accompagnée d’informations d’identification de
l’abonné. Cette page XML est reçue par le moteur d’intégration qui l’analyse et
opère les fusions requises le cas échéant, comme indiquées précédemment.
Le module de gestion des abonnés coopère également avec le module d’analyse et
de fusion pour acheminer les pages traitées dans le cadre des sessions ouvertes avec
les différents abonnés. Le module interroge la table pour déterminer à partir des
informations d’identification d’abonné accompagnant chaque page XML le port
logique correspondant à la session en cours avec l’abonné, vers lequel il achemine
la page traitée (primitive SEND_PAGE).
3.5 Fonctionnement des mécanismes dans Archises 119
A titre d’exemple, une page XML générée par le module d’accès associé au serveur
d’annuaire peut inclure des données balisées telles que :
$label/name=NGUYEN
$label/firstname=Tuanloc
$label/phonenumber=0144278785
$label/[email protected]
%call(0144278785, MakeCall)
%mail([email protected], SendMail).
Dans cet exemple, les quatre premières lignes décrivent des éléments à présenter à
l’abonné, repérés par la balise « $label », à savoir le nom d’un abonné répertorié
dans l’annuaire (Nguyen), son prénom (Tuan-Loc), son numéro de téléphone
(0144278785) et son adresse de messagerie ([email protected]). Le module
de présentation adoptera le mode d’affichage de ces éléments qui convient au
terminal utilisé par l’abonné. Les deux dernières lignes comportent des codes de
fusion repérés par la balise « % ».
Le code « %call (0144278785, MakeCall) » détecté par le moteur d’intégration
engendre une requête de fusion vers le module d’accès associé au serveur de
téléphonie, qui y répond par exemple en retournant les données de fusion :
<link href = “cs_server://1049600?phonenumber=0144278785” title =
$label/MakeCall”>, qui représentent un lien entre la donnée balisée
« $label/MakeCall », qui génèrera la présentation à l’abonné d’une commande
d’appel (touche virtuelle) et l’adresse de page « cs_server://1049600 » qui
correspond à une page d’appel téléphonique gérée par le module d’accès associé au
serveur de téléphonie sur IP, avec le paramètre d’appel
« phonenumber=0144278785 » désignant le numéro appelé.
120 Chapitre 3 : Architecture Archises
De même, le code « %mail ([email protected], SendMail) » détecté par le
moteur d’intégration engendre une requête de fusion vers le module d’accès associé
au serveur de messagerie, qui y répond par exemple en retournant les données de
fusion :
<link href = “mail_server://[email protected]” title =
$label/SendMail”>, qui représentent un lien entre la donnée balisée
« $label/SendMail », qui génèrera la présentation à l’abonné d’une commande
d’envoi de message (touche virtuelle) et l’adresse de page
« mail_server://1249600 » qui correspond à une page d’envoi de message gérée par
le module d’accès associé au serveur de messagerie, avec le paramètre
« mailaddress= [email protected] » désignant l’adresse d’envoi du message.
La figure ci-dessous est une illustration d’un exemple d’affichage généré sur l’écran
d’un terminal à la suite de la production de la page précédente, traitée par le moteur
d’intégration. L’activation par l’abonné de l’une des touches virtuelles déclenchera
alors la remontée de l’adresse de page « cs_server://1049600 » ou
« mail_server://1249600 » du module de présentation vers le module de
multiplexage (Portal Manager), puis une requête de page vers le module d’accès
pour initialiser l’établissement de l’appel demandé ou l’envoi du message.
Figure 55 : Adaptation à tout type de terminal
3.5 Fonctionnement des mécanismes dans Archises 121
L’opération d’intégration peut impliquer plusieurs requêtes de fusion successives
lorsque des codes de fusion imbriqués sont présents dans la page. Dans ce cas, la
hiérarchie des parenthèses permet au moteur d’intégration de séparer les codes de
fusion et de commencer par générer les requêtes de fusion pour les codes intérieurs,
les données de fusion intermédiaires consistant alors en des paramètres que le
moteur d’intégration substitue aux codes de fusion correspondants.
A titre d’exemple, une page XML générée par le module d’accès peut inclure le
code de fusion suivant :
%call(%last_outgoing_call, Bis).
Dans cet exemple, le code de fusion « %last_outgoing_call », traité en premier,
correspond à un port logique du serveur de données de fusion du module d’accès
associé au serveur journal. A la réception de la requête de fusion adressée à ce port
logique, le module d’accès interroge le serveur journal pour récupérer le dernier
numéro de téléphone appelé par l’abonné, et ce numéro est retourné au module de
multiplexage en tant que données de fusion, par exemple « 78722 ». Le code de
fusion « %call (78722, Bis) » résultant de cette première étape est ensuite traité à
son tour au moyen d’une requête de fusion vers le module d’accès qui retourne, de
la même manière que dans l’exemple précédent, les données balisées :
<link href = “cs_server://1049600?phonenumber=78722” title = $label/Bis”>,
permettant de présenter à l’abonné une touche virtuelle correspondant à la fonction
de répétition du dernier appel (touche bis).
On voit que le moteur permet au module de multiplexage de fusionner des objets
correspondant à des services différents sans avoir de connaissance a priori des
services concernés. Ainsi, une page reçue du module en provenance d’un premier
module d’accès et contenant une action correspondant à un service dont le
traitement a lieu au sein d’un second module d’accès est traitée par le module de
multiplexage (Portal Manager) de telle sorte qu’elle ne contienne plus de codes de
fusion, mais des liens et/ou des données balisées décrivant des éléments à présenter,
122 Chapitre 3 : Architecture Archises
et qu’elle soit exploitable par le module de présentation sans qu’il y ait besoin
d’établir de dialogue entre les différents serveurs ou modules d’accès.
L’incorporation des codes de fusion aux pages XML délivrées par le module
d’accès n’implique pas non plus qu’un module d’accès connaisse la structure des
services offerts par les serveurs dédiés auxquels il n’est pas associé. Dans le premier
exemple ci-dessus, pour insérer les codes « %call(0144278785, MakeCall) » et
« %mail([email protected], SendMail) », le serveur de pages du module
d’accès associé au serveur d’annuaire a simplement besoin de savoir que
« 0144278785 » est un numéro de téléphone appelable et « tuan-
[email protected] » une adresse de messagerie (ce qui fait partie du métier
annuaire), sans connaître comment les serveurs traitent les appels téléphoniques et
envoient des messages.
3.6 Conclusion 123
3.6 Conclusion Comme l’architecture d’intermédiation Archises préconise la création de services
par l’assemblage des fonctions de base. Archises est, pour l’instant, plus
ouverte car elle peut réutiliser les fonctions de base de tous les services, de
téléphonie ou de données, locaux ou distants moyennant une adaptation. La
réutilisation de services Web – SOAP [wSOAP] peut être aisément effectuée en
développant un connecteur Archises SOAP. Il est à souligner qu’Archises se limite
à n’être qu’une nouvelle architecture de réseau intelligent, où l’intelligence de
service se trouve déplacée dans le monde intermédiaire, et que .NET et ONE ont
d’autres ambitions, notamment de devenir les systèmes d’exploitation de l’Internet
(« The Network is the Computer »).
Le consortium JAIN [voir 2.4.2], animé par SUN, propose la création de services
par assemblage de composants JavaBeans uniquement. Comme Archises préconise
l’assemblage de fonctions de base et comme un composant JavaBeans fournit des
fonctions de base, Archises peut réutiliser les composants JavaBeans [wJavaBean]
ou les composants COM [wCOM] de Microsoft moyennant une petite adaptation,
par le connecteur Archises JavaBeans ou par le connecteur Archises COM. Par
ailleurs, Archises peut bien sûr interagir avec les fonctions de base des JAIN APIs
via le connecteur Archises Java.
Pour résumer, Archises résulte de la fusion de trois concepts (concept
d’intermédiation, concept de réseau intelligent, concept de composant) et les
architectures intelligentes. Ce nouveau concept hérite non seulement des bénéfices
de chacun d’eux mais intègre aussi des mécanismes additionnels nés de la
convergence de ces deux concepts comme :
Transformation au niveau de l'intermédiation (figure 56): elle consiste à
transformer un service fourni, grâce à des règles définies par le créateur de services,
en un service à valeur ajoutée : ajout de touches interactives, traduction multi
langues…
124 Chapitre 3 : Architecture Archises
Figure 56 : Transformation
Déclencheur (triggering) au niveau de l'intermédiation (figure 57):
l'intermédiation peut intégrer un mécanisme de déclenchement de service de réseau
intelligent (RI) sans qu'il faille toucher aux commutateurs.
Figure 57 : « Triggering »
3.6 Conclusion 125
Le triggering (figure 58) peut être intégré dans les serveurs autres que les
commutateurs tels que le serveur de messagerie.
Figure 58 : « Triggering »
Création de services par assemblage de fonctions de base et non de composants
SIB : un service ou un programme peut être décrit ou « assemblé » comme une suite
de fonctions réutilisables (contenant une suite d'instructions) et non plus comme une
suite d’instructions réutilisables (contenant une suite de micro-instructions).
126 Chapitre 4 : Implémentation pour valider Archises
Chapitre 4 : Implémentation pour valider Archises
Objectif : Ce chapitre étudie le «framework d’Archises». Cette étude a été
fournie par Nortel Networks via une plate-forme de création de services avec des
téléphones IP pour déployer les nouveaux services. Elle a pour but de valider le
concept d’Archises en montrant qu’il fonctionne et que c’est un nouveau concept
ouvert pour pourvoir élargir dans le futur.
Cette étape comporte trois phases: une phase d’intégration des différents
composants du prototype, une phase de développement ou de création de services
par l’assemblage de fonctions de base et enfin une phase d’analyse de la nouvelle
architecture de réseau intelligent d’intermédiation (Archises) à partir des
expérimentations.
Cette analyse s’attardera particulièrement sur l’aspect temps réel de l’architecture
Archises avec des différentes mesures de temps de réponse, sur la facilité ainsi
que la rapidité de création de services à valeur ajoutée.
4.1 Veilles technologies 127
4.1 Veilles technologies 4.1.1 SIP Session Initiation Protocol [wSIP] 4.1.1.1 Présentation SIP
En 1999, le protocole SIP (Session Initiation Protocol, RFC 3261) [wSIP] est
proposé comme standard par l'IETF (Internet Engineering Task Force). Il est
rapidement apparu comme une alternative à H.323 car il est plus simple à
implémenter. Ainsi dans ces dernières versions de système d'exploitation,
Microsoft propose un client SIP à la place de H323 [wH323] dans leur version de
NetMeeting et MSN Messenger, Yahoo suit aussi cette évolution dans leur
versions de messenger. Dans l’industrie des télécommunications, Nortel
Networks, EADS-Télécom, Alcatel puis Siemens ont réaffirmé leur soutien à SIP
dans le cadre de leurs offres de téléphonie privée dans le marché mondial. EADS-
Télécom a développé un logiciel pour PC offrant des fonctions de gestion d'appels
téléphoniques et de travail de groupe, dans le cadre de téléconférences, …
SIP vient du monde d'Internet et non de celui de la téléphonie et de l'UIT-T, d'où
est issu H.323. SIP a été conçu, au départ, pour favoriser la tenue de
téléconférences multimédias sur Internet. C'est un protocole de signalisation de
niveau applicatif, qui établit, modifie et termine des sessions multimédias
interactives sur IP entre des terminaux SIP.
Les principales composantes dans SIP sont: le terminal - (SIP device ou user
Agent), le Proxy Server, le serveur de redirection (Redirect Server) (figure 59).
128 Chapitre 4 : Implémentation pour valider Archises
Figure 59 : SIP
Les terminaux sont considérés comme clients lorsqu'ils effectuent une requête et
comme des serveurs lorsqu'ils y répondent. Ils peuvent communiquer directement
entre eux ou par l'intermédiaire d'autres serveurs.
Le Proxy Server joue le rôle de serveur d'un côté (réception de requête) et de
client de l'autre (envoi de requête).
Le Serveur de redirection établit la correspondance entre l'adresse SIP du terminal
appelé et la ou les adresses où il pourra effectivement être joignable.
Le Registry Server permet de connaître l'endroit où se trouve un usager et fournit
cette information au proxy et au serveur de redirection.
4.1.1.2 Principe de fonctionnement de SIP Dans le cas que nous étudierons, le protocole SIP établit une session entre
l'ordinateur appelant et l'ordinateur appelé. SIP représente les numéros de
téléphone sous la forme d'URL grâce au schéma SIP. Par exemple,
4.1 Veilles technologies 129
sip:[email protected] (henry est le nom de l'utilisateur, matra.com est l'hôte
identifié par le nom DNS matra.com) (figure 60).
Figure 60 : Fonctionnement de SIP
Figure 61 : Les codes de messages SIP
Pour commencer une session, l'ordinateur appelant peut créer une connexion avec
son interlocuteur et lui envoyer un message INVITE dans un paquet UDP.
Si l'appelé accepte l'appel, il répond par un code de réponse. L'appelant peut
répondre un message ACK et confirme la réception du message 200 (Success). La
figure 62 montre une transaction de SIP pour aboutir un appel entre deux clients
SIP.
130 Chapitre 4 : Implémentation pour valider Archises
Figure 62 : Transaction de SIP
Pour terminer une conversation, n'importe quel partie peut envoyer un message
contenant la méthode BYE. Lorsque l'autre partie accuse la réception de ce
message, la session prend fin.
4.1.1.3 Conclusion de SIP
Le protocole SIP, le protocole qui brigue la téléphonie Internet, il constitue pourtant
un protocole ouvert et standardisé, porteur de nouveaux services réseaux, couplant
informatique et téléphonie, en entreprise comme dans le monde des opérateurs.
Le protocole d'ouverture de session SIP sera-t-il à la téléphonie sur IP ce qu'est le
protocole HTTP au web ? L’idée au début est destinée à être employé sur des
PABX-IP, pour devenir un standard des communications unifiées (voix, vidéo et e-
mail) en temps réel dans le monde IP. Aujourd'hui, on en est encore loin de cela.
D'une manière générale, SIP manque encore de nombreux éléments de services
actuellement utilisés dans les réseaux téléphoniques ainsi que dans les PABX
d'entreprise pour prétendre remplacer le protocole H.323, qui a les faveurs de
4.1 Veilles technologies 131
l'industrie. Ainsi, la récupération des données n'est pas spécifiée dans SIP. Il
pourrait très bien baser sur le standard tel que le XML.
Toutefois, la route est encore longue, qui conduira SIP sur la voie du protocole
standard de transport des applications multimédias d'entreprise. SIP nécessitera,
notamment, des interfaces de programmation d'applications (API) de haut niveau
pour faciliter l'intégration de services téléphoniques d'entreprise et aussi de services
sur le monde d’Internet. Et la communication en protocole SIP entre différentes
applications exigera aussi des extensions pour assurer l'interopérabilité multi
fournisseur au niveau des fonctionnalités.
4.1.2 XML (méta-langage) & Web Services 4.1.2.1 Introduction XML
XML [wXML] (eXtensible Markup Language) est un standard du W3C pour
faciliter la création, la gestion et le partage de documents sur le Web. XML
repousse les limites du Web en séparant le contenu et la présentation du langage
HTML. Il est donc préfigure l’accès au contenu du Web, indépendamment de son
stockage physique. Il peut banaliser l’accès à tout type d’information. XML est
extensible dans la mesure où il n’est pas un format fixe (données et présentation de
ces données). C’est un métalangage qui permet de définir nos propres langages de
balises pour différents types d’affichages selon le langage du client. Pour cela,
XML s’appuie sur le standard ISO SGML. XML supprime aussi la dépendance à un
type de document inflexible comme HTML tout en évitant la complexité de SGML.
XML a donné la naissance à une famille de standards du W3C : DOM, SAX, XSL,
DTD, XML Schéma [wXML Schema]. Le XML Schéma et DTD sont similaires
aux templates des processeurs de traitement de texte pour exprimer en XML des
représentations communes des données. DOM et SAX manipulent ces documents
XML. XSL est la feuille de style permettant de combiner avec XML pour former un
ficher HTML.
132 Chapitre 4 : Implémentation pour valider Archises
4.1.2.2 Pourquoi XML a-t-il été choisi comme le langage de base dans des mécanismes de base d’Archises ?
D’abord, comme le langage Java a résolu le problème de portabilité entre des
programmes, XML règle celui de portabilité des données. Selon une étude de
Gartner Groupe, « 95% des grandes entreprises ont déployé une infrastructure de
données basée sur XML et un chiffre estimé environ de 10 milliard de dollar en
2003-2004». XML bénéfice du support de l’industrie informatique. Il garantit la
pérennité des technologies pour déployer à une grande échelle.
Ensuite, XML est un format d’échange de données qui facilite l’interopérabilité des
applications notamment le Web. Les données XML peuvent être obtenues de
n’importe quel type de données dans des bases de données très diverses.
Enfin, XML supporte les données semi-structurées permettant d’intégrer
uniformément des données provenant de différentes bases.
Pour ces raisons, notre architecture proposée Archises a choisi XML comme
langage pivot, langage intermédiaire.
4.1.3 LDAP 4.1.3.1 Présentation LDAP
LDAP (Lightweight Directory Access Protocol) [rRFC2251] [aMirtain] est né de
l’adaptation de X500 DAP au protocole TCP/IP. Il garde l’idée essentielle de
X500 mais il est plus simple pour implémenter. L’annuaire LDAP est une base de
données spécifiée rapidement à lire des informations. LDAP fonctionne en mode
client-serveur. Pour faire une requête vers le serveur LDAP, il faut faire un Bind,
Opérations (Search, Add, Modify), Unbind (figure 63).
4.1 Veilles technologies 133
Figure 63 : LDAP
4.1.3.2 Création de nouveaux services avec LDAP
Il y a une tendance que l’initiative Cocoon [voir 2.1.5.2] est en train de mener sur
l’intégration du serveur LDAP dans leur système pour pouvoir créer un nouveau
service. Ensuite, le résultat obtenu par la requête du serveur LDAP sera envoyé
au client selon leur type de terminal. Par exemple, un format WML [wWAP] sera
créé pour un client WAP, un format HTML pour un client Web et un format
standard en XML pour d’autres types de terminal (figure 64).
Figure 64 : Fonctionnement de LDAP
134 Chapitre 4 : Implémentation pour valider Archises
4.1.3.3 Conclusion de LDAP
On utilise LDAP dans notre architecture Archises comme une base de données. Il
faut donc créer un connecteur pour communique entre Archises et les services
fournis par LDAP. L’annuaire LDAP peut remplacer un SGBD traditionnel
dans le cas de données simples, distribuées à large échelle et utilisées par multiples
applications.
4.1 Veilles technologies 135
4.1.4 Langage PML (Phone Markup Language)
PML [wPML] est le langage utilisé dans l'implémentation des messages venant
de PABX d’Archises. Il a pour but de créer un script d’exécution dans le Call
Server. Le script PML traite des appels entrants et des appels sortants. Il peut
dévier, refuser ou interrompre un appel. Un exemple de PML : un script simple
pour dévier un appel entrant vers le Voicemail si l’appelé est occupé.
<pml>
<incoming_call>
<busy>
<location url="sip:[email protected]" clear=”yes”>
<redirect/>
</location>
</busy>
</incoming_call>
</pml>
Le langage PML peut être utilisé dans le contexte du réseau SIP et H.323 ou la
téléphonie sur IP en général.
136 Chapitre 4 : Implémentation pour valider Archises
4.2 Implémentation pour valider Archises 4.2.1 Transformation de services 4.2.1.1 Objectif
Le but de cette implémentation est de valider le mécanisme de transformation
dans l’architecture Archises. Ce mécanisme permet d’enrichir l’information
XML à partir d’une source donnée telle que LDAP [rRFC2251] et SIP [wSIP]. Les
services LDAP sont fournis par l’application virtuelle LDAP du serveur Archises.
Celui-ci devient alors un client LDAP d'un ou des serveurs LDAP distants.
4.2.1.2 Contexte de l’implémentation
- le protocole LDAP implémenté est la version 3 [rRFC2251],
- seules les authentifications anonymes et simples sont supportées,
- seules les opérations Bind, Unbind et Search sont supportées.
4.2.1.3 Architecture de l’implémentation du connecteur LDAP
Les services LDAP sont fournis par l’application virtuelle LDAP du serveur
Archises (figure 65). Cette application virtuelle LDAP est dissociée en deux
parties :
- Agent LDAP, qui s’interface avec les serveurs LDAP,
- Agent Services LDAP, qui fournit les services LDAP offerts par l’application
virtuelle LDAP.
4.2.1 Implémentation 137
Figure 65 : LDAP d’Archises
Les paramètres des services LDAP sont définis dans des structures de données qui
contiennent l’ensemble des paramètres nécessaires concernant : la configuration des
opérations LDAP (accès au serveur LDAP, requête et réponse LDAP), les mires
d’affichage du service (saisie des entrées utilisateurs, résultat).
Donc ces structures de données sont les seuls éléments dynamiques de l’application
virtuelle LDAP, l’Agent LDAP et l’Agent Services LDAP étant génériques.
Pour créer ou modifier un nouveau service LDAP, il suffit à l’exploitant ou au
créateur de service de fournir ou de modifier la structure de données correspondant
au service.
Comme tout client LDAP, le serveur Archises communique avec le serveur LDAP
en utilisant les opérations :
138 Chapitre 4 : I
Bind
Search
...
UnBind
L’opération Bind o
l’opération Unbind à
4.2.1.4 Age
L’Agent LDAP com
(RFC 2251). L’Agen
LDAP. Pour le serve
implémentées. L’Ag
entrées d’un annuair
4.2.1.4.1 Opé
Pour établir une ses
Services LDAP l’int
Paramètre
Type
Serveur
Port
Version
Nom
Authentification
mplémentation pour valider Archises
Time out
uvre une session LDAP, sa fermeture est commandée par
la fin du time out.
nt LDAP
munique avec un serveur LDAP selon le protocole LDAP v3
t LDAP fournit une interface de type LDAP à l’Agent Services
ur Archises, seules les opérations Bind, UnBind et Search sont
ent LDAP ne peut ni ajouter, ni modifier, ni supprimer des
e : il ne peut faire que des interrogations.
ration BIND
sion avec un serveur LDAP, l’Agent LDAP reçoit de l’Agent
erface suivante :
Description
Requête Bind
Adresse IP ou nom du serveur LDAP
Numéro de port du serveur LDAP (port par défaut : 389)
3
Nom de l’utilisateur (ou NULL pour accès anonyme)
Mot de passe (ou NULL pour accès anonyme)
4.2.1 Implémentation 139
L'Agent LDAP demande alors l'établissement de la session LDAP, autrement dit il
établit la connexion TCP avec le serveur LDAP distant, si elle n'est pas déjà
ouverte, et transmet le message Bind LDAP.
Suite à la réponse d’établissement de session du serveur LDAP, l’Agent LDAP
fournit à l’Agent Services LDAP l’interface suivante :
Paramètre Description
Type Réponse Bind
Résultat OK ou NOK
4.2.1.4.2 Opération UNBIND
Pour terminer une session avec un serveur LDAP, l’Agent LDAP reçoit de l’Agent
Services LDAP l’interface suivante :
Paramètre Description
Type Requête UnBind
Serveur Serveur LDAP
4.2.1.4.3 Opération SEARCH
Pour effectuer une recherche, l’Agent LDAP reçoit de l’Agent Services LDAP
l’interface suivante :
Paramètre Description
Type Requête Search
Serveur Serveur LDAP
Objet de base Base de la recherche
Portée Profondeur de la recherche
Alias Gestion d’alias
140 Chapitre 4 : Implémentation pour valider Archises
Limite Nombre maximum d’entrées de retour
Time-out Temps au delà duquel la recherche est interrompue
Type de résultat Type d’attributs d’entrée ou Type ET Valeur
Filtre Attributs de filtrage
Attributs de sortie Attributs de sortie de l’entrée de sortie
Suite à la réponse du serveur LDAP, l’Agent LDAP fournit à l’Agent Services
LDAP l’interface suivante :
Paramètre Description
Type Réponse Search
Entrée trouvée Entrée ou objet LDAP trouvé
Résultat OK ou NOK
Attributs de sortie Attributs de sortie de l’entrée trouvée
4.2.1.5 Agent services LDAP
L’Agent Services LDAP gère les différents services d'annuaire LDAP. C'est un
module générique qui est chargé d’interpréter les variables contenues dans les
structures de données. A partir de cette interprétation, l'Agent Services LDAP
pourra fournir le service souhaité : en interagissant avec l’Agent LDAP, en
préparant les mires d’affichage du service pour les terminaux (saisie des entrées et
résultats). L'Agent Services LDAP est initialisé par un message venant du serveur
d'exploitation:
Paramètre Description
Type Service
Code Présentation du nom, recherche dans l'annuaire 1,
recherche dans l'annuaire 2 ou recherche dans l'annuaire
4.2.1 Implémentation 141
L'Agent Services LDAP traite le message reçu et envoie vers le Context Manager
un message XML qui sera affiché grâce au browser du serveur Archises sur l'écran
de l'utilisateur. Celui-ci peut alors rentrer les renseignements nécessaires pour le
service de recherche.
L'Agent Services LDAP recevra donc en retour un message rendant compte de la
saisie de l'utilisateur :
Paramètre Description
Type Saisie
Attributs de filtrage
concernés
Types ET Valeurs
Nom Nom de l'utilisateur à saisir éventuellement pour Bind
Mot de passe Mot de passe de l'utilisateur à saisir éventuellement
pour Bind
NB : le “Nom” et le “Mot de passe” ne sont affichés que si le service le permet.
Si la session LDAP avec le serveur correspondant n'est pas ouverte, l'Agent
Services LDAP traite le message reçu et envoie vers l'Agent LDAP un message
Bind. Puis il envoie un message Search.
L'Agent Services LDAP traite ensuite le message Search Response reçu et envoie
vers le terminal un message XML de résultat, qui peut être filtré par le Context
Manager en fonction du contexte d'abonnement et de service.
A la réception du message Search Response, l’Agent Services LDAP initialise ou
réinitialise le time out de la session LDAP.
142 Chapitre 4 : Implémentation pour valider Archises
4.2.1.6 Formatage d'un écran pour l'affichage
Figure 66 : Transformation d’Archises
Avant d'être affichés, les messages issus de l'Agent Services LDAP (Messages
demandant une saisie de l'utilisateur ou Message d'affichage du résultat) devront
subir cinq types de traitements majeurs (figure 66) :
- Ajout de l’intrusion,
- Transformation en message XML,
- Transformation en écran logique,
- Transformation d’affichage,
- Traduction des labels.
La figure 67 illustre un exemple de cette transformation : un appel entrant peut être
interrompu et ensuite, il déclenche le serveur d’annuaire LDAP pour fédérer les
deux services : le service d’annuaire LDAP et le service téléphonique pour former
4.2.1 Implémentation 143
un nouveau service. Le client dans Archises peut connaître non seulement le
numéro de l’appelant mais aussi les informations personnelles de celui-ci.
Figure 67 : Agrégation de services dans Archises
4.2.1.6.1 Ajout de l'intrusion
L'intrusion est la capacité d'un message à interrompre l'utilisateur. Elle est
représentée par une donnée supplémentaire à ajouter au message reçu. Cette donnée
a pour valeur un entier compris entre 1 et 10 : 1 représente une intrusion maximale.
Le niveau d’intrusion peut être consolidé par le Context Manager en fonction du
contexte d'abonnement et de service.
L'ajout de cette donnée au message Search Response est régi par une table liant
chaque type de message (Demande de saisie, Affichage du résultat) à un niveau
d'intrusion correspondant :
Message initial Transformation
Type de message Intrusion=value
144 Chapitre 4 : Implémentation pour valider Archises
4.2.1.6.2 Transformation en message XML
Dans le cas de l'affichage du résultat, il est nécessaire de transformer le message
reçu : par exemple, le message Search Response.
Paramètre Description
Type Réponse Search
Entrée trouvée Entrée ou objet LDAP trouvé
Résultat OK ou NOK
Attributs de sortie Attributs de sortie de l’entrée trouvée
en un message XML pour être intégré dans le serveur Archises.
Cette transformation doit être réalisée selon les règles décrites dans la table
suivante :
Message initial Transformation
Type de message <type> message
Intrusion <intrusion>value
Résultat <item> ou <result> #notfound
Entrée trouvée <type d’un attribut> valeur de l’attribut
Attribut de sortie <type d’un attribut> valeur de l’attribut
Dans le cas d'une demande de saisie, il s'agira plutôt de la création d'un message
XML approprié suite à la réception d'un message « Service ».
4.2.1.6.3 Transformation en écran logique
Il s'agit ici, à partir du message XML précédent, d'ajouter des actions et des labels à
certains tags spécifiques : par exemple le tag « telephonenumber » se voient
attribuer l'action « #appel » et le label « #labelphone ». Le message XML prend
alors la forme d'un écran logique muni de Softkeys pour invoquer des actions.
4.2.1 Implémentation 145
Cette transformation doit être réalisée selon les règles décrites dans la table
suivante:
Message initial Transformation
<type> message <title> #message
<type de service>
<type de service>
<softkey> <label> #service_name
<action> protocol://value
4.2.1.6.4 Transformation d'affichage
Chaque tag du message XML consolidé se voit attribuer un niveau de priorité
d'affichage. Il s'agit en fait de classer les différents tags par l’importance au niveau
de l'affichage. Si l'écran est trop petit, les tags de moindres priorités ne seront donc
pas affichés.
Ce niveau de priorité d'affichage prend la forme d'un attribut du tag XML. C’est un
entier compris entre 0 et 10 :
- 10 est le niveau prioritaire d'affichage,
- 0 représente un tag qui ne doit jamais être affiché quelque soit la taille de l'écran
(c'est par exemple le cas du tag « intrusion »).
Cette affectation des attributs « niveau de priorité » s'effectue selon une table
répertoriant tous les tags envisageables, et le niveau de priorité qui leur est associé :
Message initial Transformation
<tag> <tag pr=value>
146 Chapitre 4 : Implémentation pour valider Archises
4.2.1.6.5 Traduction des labels
Enfin, il s'agit en dernier lieu de remplacer tous les labels (comme “#label_phone”)
par le texte correspondant selon :
La capacité d’affichage du terminal, la langue utilisée sur le terminal.
Pour chaque famille d’écrans donnée, il existe une chaîne dynamique de tables de
labels . Chaque table traduit tous les labels du service pour une langue donnée :
Message initial Transformation
#value Traduction de value dans la langue voulue
4.2.1.7 Traitement d'un message ascendant
L'Agent Services LDAP peut recevoir un message ascendant, c'est-à-dire venant du
terminal.
Paramètre Description
Type Saisie
Attributs de filtrage
concernés
Types ET Valeurs
Nom Nom de l'utilisateur à saisir éventuellement pour Bind
Mot de passe Mot de passe de l'utilisateur à saisir éventuellement
pour Bind
Avant toute chose, l'Agent Services LDAP teste s'il existe les champs « Nom » et
« Mot de passe » du message « Saisie » :
Si ces champs existent et sont remplis, un nouveau message Bind LDAP est émis
vers l'Agent LDAP, tenant compte de ces valeurs. Dans ce cas une nouvelle session
LDAP dite personnelle est ouverte en plus de la session LDAP par défaut (si celle-
ci est ouverte).
4.2.1 Implémentation 147
Si ces champs n’existent pas ou ne sont pas remplis, un nouveau message Bind
LDAP est émis vers l’Agent LDAP seulement si la session LDAP par défaut est
fermée.
Dans tous les cas, l'Agent Services LDAP relève alors la liste des attributs (Type ET
Valeur) saisis par l'utilisateur, pour les intégrer dans le champ « filtre » du message
Search LDAP qui sera transmis à l'Agent LDAP.
A la réception du message Search Response, l’Agent Services LDAP initialise le
time out de la session courante avec une grande valeur si la session est par défaut ou
avec une petite si la session est personnelle. De plus, il peut envoyer la présentation
du nom du correspondant.
4.2.1.8 Exemple de la recherche d'un abonné (voir Annexe B)
148 Chapitre 4 : Implémentation pour valider Archises
4.2.2 Création de services d’Archises 4.2.2.1 Objectif
Objectif de cette implémentation est de créer de nouveaux services via RSCE
(Rapid Service Creation Environment) dans le serveur Archises et de les déployer
au client. Le téléphone IP de Nortel Networks est utilisé dans cette implémentation.
4.2.2.2 Mécanisme de fonctionnement
Afin de limiter l'impact sur le code du serveur Archises, les nouveaux services
peuvent être fournis par l'extérieur, c'est-à-dire qu'ils peuvent être développés en
dehors d’Archises et accessibles de façon transparente pour le client. RSCE est
implémenté implicitement dans le serveur Archises. Grâce à celui-ci, les services
d’Archises peuvent être créés exponentiellement.
Les services sont hébergés sur des serveurs HTTP ou de fichiers. Le serveur
Archises doit pouvoir accéder à ces serveurs de pages extérieurs : l’interfaçage est
assuré par le serveur Services Extérieurs. Ces services sont développés en utilisant
le langage PML et peuvent être statiques ou dynamiques (pages générées par des
scripts ASP, PHP, etc).
L'implémentation est effectuée dans le cadre d’un projet de recherche à EADS-
Télécom avec le téléphone IP de Nortel Networks. Celui-ci fonctionne avec le
protocole propriétaire UNISTIM de Nortel Networks, mais il est aussi équivalent au
SIP. Le PABX utilisé est celui d’EADS-Télécom.
PML est le langage d’échange entre les différents éléments du serveur Archises. Il
dérive du langage XML et s’inspire du langage WML, qui est utilisé pour formater
les pages sur les téléphones portables WAP.
PML est le langage de présentation : il permet de spécifier les données, les textes et
les graphiques affichés sur l’écran d’un poste et il définit les interactions avec
l’utilisateur.
4.2.2 Création de services d’Archises 149
L’utilisateur du terminal IP de Nortel accède aux services extérieurs par la touche
‘Services’ qui permet déjà l’accès aux services de base du serveur Archises. Ils
peuvent s’afficher sur la page de services ou sur la page d'accueil.
La figure 68 est une image de la plate-forme où Archises a été implémentée.
Figure 68 : Plate-forme de l’implémentation du concept d’Archises
4.2.2.3 Mise en œuvre de la fonction
Chaque serveur extérieur (application virtuelle) publie la liste des services et du
dictionnaire associé qu'il offre dans le fichier XML suivant : list_services.xml.
<services timeout=1>
<service name="" link=""/>
<service name="" link=""/>
<dictionary link=""/>
</services>
150 Chapitre 4 : Implémentation pour valider Archises
Le fichier de configuration définit : l’intervalle (en minutes) pour la relecture de la
liste des services pour chaque service son nom et son URL, l’URL du dictionnaire
(si un ou plusieurs services utilisent des références à ce dictionnaire). Les adresses
de ces listes sont dans le fichier servextern.xml.
<servers>
<server name="" link=""/>
<server name="" link=""/>
</servers>
Les services peuvent être hébergés par un serveur HTTP sur un réseau accessible du
serveur Archises ou dans un répertoire local/réseau accessible du PC faisant office
de serveur Archises.
4.2.2.4 Plate-forme de test
La configuration matérielle comprend (figure 69):
- Un PC hébergeant un Call Manager PABX,
- Un PC hébergeant un serveur Archises,
- Un PC hébergeant les deux serveurs HTTP les plus courants (IIS et Apache)
configurés sur des ports TCP différents (80 pour IIS, 81 pour Apache, par exemple),
- Des terminaux IP de Nortel Networks.
Les différentes fonctions du serveur peuvent éventuellement être co-localisées sur le
même PC.
4.2.2 Création de services d’Archises 151
Figure 69 : Configuration matérielle de la plate-forme de validation d’Archises
La configuration logicielle comprend :
-La configuration de l’adresse IP de côté de PABX,
-La déclaration d’abonnés logiques (terminal IP) sur le PABX,
-La création d’un service hébergé sur un serveur HTTP, également accessible par
fichier et sa déclaration au serveur Archises,
-Pour le serveur Web IIS 5.0, la déclaration des types de fichiers .pml et .xml.
4.2.2.5 Exemple : fichiers PML utilisés pour les testes
(voir Annexe C)
4.2.2 Création de services 152
4.3 Conclusion Ce chapitre a pour but de valider Archises via deux implémentations : la
transformation de services et la création de nouveaux services via Archises.
Cela montre que le concept d’Archises est un bon concept qui facilite la création de
nouveaux services. Ainsi, le temps pour créer un service est beaucoup réduit via la
chaîne de création de services dans Archises. Le nombre de services à valeur
ajoutée résultant de cette transformation peut croître de manière exponentielle grâce
à l'application du nouveau concept d’Archises. Il permet aussi d’avancer ce concept
vers une architecture Archises plus généralisée que nous allons discuter dans le
chapitre suivant.
5.1 Définition des termes 153
Chapitre 5 :
Architecture généralisée
Dans ce chapitre, nous essayons d’élargir le contexte de la création de
services abordé dans le chapitre 3 en proposant une équation plus générale pour
pouvoir créer n’importe quel nouveau service dans le futur.
Malgré l’intérêt d’un mariage entre le monde du logiciel et le monde du réseau, il y
a très peu de travaux de recherche appuyant sur la définition de l’architecture. Nous
essayons de mener une recherche pour découvrir le bon fonctionnement d’un
système nommé « network-based application architecture » [tFielding], autrement
dit l’architecture de logiciel basée sur réseau. Voici l’équation :
Service = composant(s) + architecture + [assembleur(s)] + [adaptateur(s)] +
[déclencheur(s)]
L’approche d’Archises consiste à définir une équation finale permettant de créer de
nouveaux services. Il s’agit de la définition du terme « service » que nous avons
abordé dans le chapitre 3.
5.1 Définition des termes 5.1.1 Composant
Les composants sont des entités logicielles autonomes qui représentent les services.
Ils peuvent être facilement créés via le mécanisme d’assemblage d’Archises [voir
3.2.5]. Ils peuvent aussi être réutilisés tout simplement sans besoin de savoir
comment ces codes ont été créés [aSzyperski 02] (figure 70).
154 Chapitre 5 : Architecture généralisée
Figure 70 : Composant
Un composant logiciel est aussi comparable à un composant électronique pour
plusieurs raisons. D’abord, les deux exécutent une fonction, c'est-à-dire offrent des
services. Ensuite, ils fournirent à travers des ports pour les composants et des pattes
pour les composants électroniques, les éléments fournis par ceux-ci.
5.1.1.1 Composant classique
Définition : un composant classique est une boîte noire qui fournit des services. Un
composant a besoin d’autres composants comme entrées pour bien fonctionner
[aPerry].
Un composant classique est un morceau de code qui exécute une tâche précise. Il
comporte des entrées et des sorties. Il est aussi composé d’une suite d’instructions
logicielles (ou suite des fonctions).
Autrement dit, un composant classique est une boîte noire qui importe des services
et exporte des interfaces ou des services. Il peut également fournir des
transformations de données via ses interfaces [tScheider].
Nous pouvons également dire qu’un composant est une application autonome qui
propose un nombre de services et est compilé en code binaire.
5.1.1.2 Composant d’Archises
Définition : un composant d’Archises [aNGUYEN Cosci04] est une entité
d’abstraction qui contient des instructions logicielles. Il fournit des
transformations de données via ses interfaces : des entrées et des sorties. Les
5.1 Définition des termes 155
nouveaux composants peuvent être formés grâce au mécanisme d’assemblage de
composants avec la chaîne de création de services (figure 71).
Figure 71 : Composant d’Archises
Un composant d’Archises est aussi un composant classique avec des
transformations de données via ses interfaces. Son avantage est d’être composé des
codes binaires indépendants et d’interagir pour former une application par le
mécanisme d’assemblage [voir 3.2.5]. Chaque composant peut être considéré
comme une boîte noire pour laquelle il suffit de connaître les services rendus et
quelques règles d’interconnexion pour pouvoir agréger avec d’autres composants.
5.1.2 Assembleur (glue)
Définition : un assembleur [tScheider] est un composant spécial qui permet de
relier les composants. Il possède les interfaces et le mécanisme d’abstraction
permettant la communication et la coordination entre les composants.
Dans l’informatique, il y a toujours des composants génériques qui offrent les
services de base. Pour former une application, il faut relier les services de base et
adapter ces services en utilisant les assembleurs.
156 Chapitre 5 : Architecture généralisée
Le moteur d’assemblage intègre les fonctions de base en service à valeur ajoutée à
partir d’un script écrit par le créateur de services. Le moteur d’assemblage ne voit
que des fonctions de base qui peuvent être réellement présentes au niveau de
l’intermédiation. Lorsque les fonctions de base réutilisables sont à distance, elles
sont représentées en local par des connecteurs de transformation.
La figure 72 compose de trois composants de base qui sont reliés via une zone
appelée « Glue » (assembleur).
Figure 72 : Assembleur (glue)
En fait, l’assembleur s’interpose entre des composants pour réunifier la sémantique
de la relation de composition.
5.1.3 Déclencheur (triggering-script)
Définition : un déclencheur est une structure de relation entre des composants,
des assembleurs et des adaptateurs permettant d’appeler des services à l’extérieur
via les connecteurs. Il déclenche un scénario entre les composants, les colles et les
adaptateurs.
Par exemple, c’est le déclencheur qui prend en charge la connexion entre Archises
et le monde extérieur d’Archises. Le déclencheur permet d’activer la mise en œuvre
5.1 Définition des termes 157
de services à valeur ajoutée à partir des évènements générés par les services de base
fournis.
Le déclencheur comporte deux éléments : la configuration et le style architectural.
La configuration contient le scénario pour créer le lien entre les connecteurs et les
composants d’Archises. Il est déclenché au moment de l’exécution du système. Le
style architectural possède des contraintes d’architecture qui permet de déclencher
tel ou tel service selon le scénario prédéfini dans la configuration.
5.1.4 Adaptateur
Définition : un adaptateur est un composant spécial qui assume des mécanismes
de transformation. Il permet de communiquer, coordonner ou coopérer les
composants venant de l’extérieur par d’autres fournisseurs de service.
Pour qu’un composant soit conforme à une architecture logicielle, parfois il faudrait
transformer ou configurer les données hétérogènes en un langage commun
intermédiaire en langage intermédiaire. Nous avons choisi XML comme le langage
intermédiaire.
5.1.5 Architecture (framework de test)
Définition : l’architecture est une plate-forme de création de nouveaux services
et l’assemblage de composants. C’est aussi le framework sur lequel les services
peuvent être bâtis.
Grâce à l’architecture, des composants peuvent être assemblés. L’architecture est le
niveau d’abstrait d’Archises et elle est transparente pour le client.
158 Chapitre 5 : Architecture généralisée
5.2 Service d’Archises 5.2.1 Service
Définition : un service d’Archises est une suite des composants. Il a les
caractéristiques suivantes :
- exécute une tâche précise,
- a des entrées et des sorties,
- se compose d’une suite d’instructions logicielles (ou suite des fonctions),
- peut également fournir des transformations et des mécanismes d’assemblage de données via ses interfaces,
- est neutre et indépendant de système d’exploitation,
- a un automate de fonctionnement selon les règles prédéfinies.
La figure 73 illustre le fonctionnement d’un service d’Archises:
Figure 73 : Service d’Archises
5.2 Service d’Archises 159
5.2.2 Service intelligent 5.2.2.1 Intelligence
Définition : L’intelligence a deux niveaux :
- «Bas niveau»: Être capable d’exécuter une fonction informatique
- «Haut niveau»: Capacité de comprendre, de raisonnement ou de découvrir des
relations entre les « composants » pour réaliser un service [aBerners 96].
5.2.2.2 Service intelligent
Définition : un service intelligent (figure 74) est un service classique qui :
- est autonome,
- s’adapte au nouvel environnement.
Service intelligent via la chaîne de création de services avec SCDL [voir 3.3.4].
Figure 74 : Chaîne d’assemblage d’Archises
Le langage SCDL [aNGUYEN ICCCN02] permet de définir un automate pour
chaque service à la manière automatique, intelligente. Cela permet de créer un
nouveau service plus facile et plus rapide grâce à la chaîne d’assemblage de
services qui se trouve au cœur de RSCE.
160 Chapitre 5 : Architecture généralisée
5.3 Service intelligent avec sémantique d’Archises (Intelligent Semantic Service) 5.3.1 Sémantique
Définition : La sémantique a deux niveaux :
- «Bas niveau»: étude du sens dans un message ou dans un langage.
- «Haut niveau»: extension du Web actuel qui permet de fournir un sens bien défini
pour l’information dans le Web. Il a pour but de mieux co-opérer entre l’homme et
l’ordinateur [rRFC 2396].
5.3.2 Service intelligent avec sémantique
Définition : un service intelligent avec sémantique d’Archises est un service
intelligent et capable de communiquer avec d’autres services via la sémantique
La figure 75 illustre un automate simple avec le langage SCDL (déjà présenté dans
le chapitre 3). Par exemple, quand on reçoit un numéro entrant, on le convertit ce
numéro en nom de la personne via l’annuaire correspondant à ce numéro.
Figure 75 : Service intelligent avec sémantique
5.3 Service intelligent avec sémantique 161
5.3.3 Service d’Archises - “Intelligent Semantic Service”
Archises fournit des contraintes architecturales telles que les interfaces de chaque
composant, les assembleurs entre des composants, les adaptateurs de composant
dans l’architecture.
Pour résumer, un service du type d’Archises est un service intelligent avec
sémantique. Autrement dit, un service d’Archises se compose d’une suite de
compositions des éléments architecturaux : composant(s), assembleur(s),
adaptateur(s), déclencheur(s). Nous pouvons définir un service d’Archises comme
ceci :
Service = composant(s) + architecture + [assembleur(s)] + [adaptateur(s)] +
[déclencheur(s)]
La figure 76 montre la différence un service d’Archises par rapport aux autres types
de services dans la littérature.
Figure 76 : « Intelligent Semantic Service » d’Archises
162 Chapitre 5 : Architecture généralisée
5.4 Conclusion 5.4.1 Archises = inter-services + intra-services
Archises a pour but de créer une jonction entre le monde du logiciel et le monde du
réseau. Pour connecter au monde de logiciel, c'est-à-dire les services, nous pouvons
distinguer deux types de services : intra-services et inter-services.
Qu’est-ce que les intra-services ? Ce sont les services prédéfinis par le RSCE
Archises [voir 3.3]. Ces services sont créés, testés et déployés et bien intégrés dans
l’architecture Archises (figure 77).
Figure 77 : Intra-services et inter-services d’Archises
Au contraire, les inter-services sont ceux qui ont été créés par les fournisseurs
externes. Alors, pour qu’ils soient intégrés dans Archises, il faut disposer des
connecteurs pour transformer en langage intermédiaire XML d’Archises. Par
exemple, un connecteur LDAP pour le serveur LDAP, chaque type de serveur
LDAP a des paramètres différents : le serveur LDAP de Microsoft et de Netscape, à
la base, ils sont identiques mais ils peuvent avoir certains paramètres communs,
d’autres sont différents.
5.4 Conclusion 163
5.4.2 Service = composant(s) + architecture + [assembleur(s)] + [adaptateur(s)] + [(déclencheur(s)]
Ce chapitre examine le « background » de cette thèse. Il a aussi pour but de
généraliser l’architecture Archises que nous avons proposé dans le chapitre 3.
Un service du type d’Archises est une suite d’assemblage de composants qui
possède des contraintes telles que les composants de « glue » (assembleur) pour les
coller ensemble, les contraintes d’adaptateur pour qu’il satisfasse au bon
fonctionnement d’Archises. Il est parfois s’adapter avec des contraintes de
déclenchement pour pouvoir déclencher un autre service. Son but est de créer un
nouveau service par l’agrégation de plusieurs services existants.
Par exemple, un appel entrant peut être interrompu et ensuite, il déclenche le
serveur d’annuaire pour fédérer les deux services : le service d’annuaire et le service
téléphonique pour former un nouveau service. Le client dans Archises peut
connaître non seulement le numéro de l’appelant mais aussi les informations
personnelles de celui-ci. Nous voyons bien qu’il y a eu un mariage entre le monde
d’informatique (annuaire d’informatique) et le monde de télécoms (PABX). Grâce
aux mécanismes dans l’architecture Archises, nous pouvons créer de plus en plus de
nouveaux services sans être obligé de modifier dans ces systèmes de plus en plus
complexes. Aucune connaissance sur la téléphonie n’est nécessaire sauf les
interfaces déjà fournies par le fournisseur de services. C’est l’atout d’Archises :
Service = composant(s) + architecture + [assembleur(s)] + [adaptateur(s)] +
[(déclencheur(s)]
164 Chapitre 6 : Conclusion et Perspectives
Chapitre 6 :
Conclusion et Perspectives 6.1 Conclusion Cette thèse présente l’architecture Archises qui a pour but de créer rapidement de
nouveaux services à valeur ajoutée de la meilleure qualité. Ce concept a été
implémenté dans la téléphonie sur IP pour valider Archises. Le futur travail sera
basé sur l’ouverture du concept d’Archises vers une architecture « universelle » afin
de résoudre d’autres problèmes dans le domaine des réseaux.
L'objectif à long terme d’Archises est de placer l’intelligence dans la couche
applicative du modèle OSI. Archises propose une solution pour créer des services
« intelligents » répondant aux besoins du client et des marchés de plus en plus
exigeants.
Pour résumer, cette thèse contribue à la recherche en informatique :
- L’architecture Archises pour créer de nouveaux services à valeur ajoutée. Le
nombre de services à valeur ajoutée résultant des mécanismes implémentés dans
Archises peut croître de manière exponentielle grâce à l'application du nouveau
concept d'Archises.
- Le framework d’Archises qui est implémenté dans la téléphonie sur IP pour
valider Archises via des composants réutilisables et des contraintes d’architecture. Il
a pour but de créer des services de base d'Archises et aussi de valider le concept
d'Archises.
- Des évolutions du concept d’Archises pour devenir dans le futur une
architecture « universelle » afin de résoudre d’autres problèmes dans le domaine
des réseaux.
6.3 Perspective 165
Archises est donc une jonction neutre, ouverte entre le monde du logiciel et le
monde du réseau.
6.2 Evaluation Evidemment, le travail réalisé dans cette thèse n’est pas exhaustif. Plusieurs travaux
restent à mener pour la construction d’une architecture Archises pleinement
adaptable et flexible.
Tout d’abord, les problèmes liés à la sécurité du système ne sont pas traités. Ce
problème est transparent pour Archises.
Deuxièmement, l’architecture est restreinte dans le domaine de la création de
nouveaux services. Elle peut être étendue vers l’aspect de gestion de nouveaux
services. Certainement, pour déployer un nouveau service, il faudrait le gérer plus
tard.
6.3 Perspectives
Figure 78 : Perspective d’Archises
Il reste aussi des travaux à effectuer pour s’affranchir des limitations décrites ci-
dessus. Nous pensons en particulier à des perspectives que nous pouvons envisager
de réaliser :
166 Chapitre 6 : Conclusion et Perspectives
6.3.1 Voitures intelligentes en réseau
Selon une étude d’IDC, il y aurait un milliard de voiture dans le monde entier en
2010. En moyenne, nous restons environ 550h par an dans notre voiture.
Actuellement, qu’est-ce que nous pouvons faire pendant ce laps de temps ? Presque
rien sauf écouter de la musique et du multimédia [aBouju00]. Dans le futur proche,
nous pouvons imaginer que l’homme pourrait tout faire dans la voiture de demain,
créer un espace de travail, consulter ses emails, les services de la bourse, surveiller
sa maison à distance, communiquer avec d’autres voitures en réseau pour savoir
l’état de trafic en temps réel, trouver l’itinéraire, bénéficier du télé-dépannage
…[wVoIN] (figure 79).
Figure 79 : Un modèle de voiture intelligente de demain (Microsoft)
Effectivement, l’architecture Archises devrait être élargie pour construire un
environnement ouvert. Cet environnement permettrait d’intégrer des services
« intelligents » dans les voitures du futur : la mobilité, la communication et les
services à valeur ajoutée dans les voitures de demain [aNGUYEN DNAC03]
(figure 80).
6.3 Perspective 167
Figure 80 : Evolution dans les voitures
Nous pouvons imaginer une architecture Archises++-- avec des API pour se
connecter vers le monde extérieur. Via Archises, l’intelligence sera diffusée dans
chaque voiture et également dans le serveur central du réseau. Archises serait donc
une jonction entre le monde du service et le monde du réseau des voitures. La
figure 81 illustre le modèle Archises dans les voitures intelligentes.
Figure 81 : Voitures intelligentes en réseau
168 Chapitre 6 : Conclusion et Perspectives
6.3.2 Domaine de gestion dans les réseaux
Dans le domaine de gestion de réseau, pour créer un nouveau service du type
d’Archises, il faut avoir un gestionnaire de service pour le gérer. Il s’agit le SMF
(Service Management Function) [oIN Thorner] [rIN Q12xx] dans le modèle de
réseau intelligent que nous pouvons citer dans le schéma ci-dessous (figure 82).
Figure 82 : La gestion dans le réseau téléphonique
6.3.3 Archises appliquée dans le réseau de capteurs (Wireless Sensor Networks) [aNGUYEN WCNC05]
Ce travail est en cours pour appliquer le concept d’Archises dans le réseau de
capteurs (Wireless Sensor Networks). Le réseau de capteurs [oPujolle 03]
[tMadden] a des capteurs diffusés partout dans l’air pour capter les informations. La
figure 83 illustre quelques exemples de capteurs.
Figure 83 : Capteurs (Sensor)
6.3 Perspective 169
Comment faire communiquer entre les capteurs et comment mettre l’intelligence
dans ce réseau compte tenu des problèmes de pénuire d’énergie qui s’accentuent ?
Une des solutions est de déplacer l’intelligence dans chaque capteur vers une
architecture de plus haut niveau [wLiscano] [aGscottberger] [aMainwaring].
Archises s’adapterait totalement à cette demande dans le futur (figure 84).
Figure 84 : Archises pour le réseau de capteurs
170 Bibliographie
Bibliographie
Articles [aACCORD] Projet Accord. Assemblage de composants par contrats en
environnement ouvert, réparti. RNRT 06/2002.
[aCESURE] Projet CESURE RNRT numéro 98 (2000). Etat de l’art des modèles
de composant. RNRT 05/2000.
[aBézivin] J. Bézivin. Le changement de paradigme des objets aux modèles :
rupture ou continuité ? (2003). Colloque scientifique - 20 ans : où sont les
objets ?, Université Paris 6.
[aBernstein] P. Berstein (1996). Middleware : a model for distributed systems
services. Communications of the ACM, 02/1996, p86-98.
[aBerners 96] T. Berners-Lee. WWW: Past, present, and future (1996). IEEE
Computer, (10/1996), pp. 69–77.
[aBerrett] R. Barrett et P.P. Maglio (1999). Intermediaires : An approach to
manipulating information streams. IBM Systems Journal v38 No4, 1999.
[aBouju00] A. Bouju, A. Stockus, F. Bertrand et P. Boursier. Web-based Vehicle
Localization. Proceedings of IEEE Intelligent Vehicles Symposium (IV2000), pp
436-441, Dearborn, USA, 10/2000.
[aCChiang 02] C.CChiang (2002). The use of adapters to support interoperability
of components for reusability. Elsevier, 10/2002.
[aChouCTI] S.L Chou et etc (2000). Computer Telephony Integration and its
applications. IEEE Communications Surveys and Tutorials 3(1).
Bibliographie 171
[aEmsellem] D. Emsellem, A. Charfi et M. Riveil (2003). Dynamic component
composition in .NET. In ECOOP'2003 Workshop on .NET: The Programmer's
Perspective. Darmstat, Germany.
[aFieldingWeb] R.T. Fielding et Richard N. Taylor. Principled design of the
modern Web architecture. ACM Transactions on Internet Technology (TOIT),
2(2), May 2002, pp. 115-150.
[aFron] A. Fron. Les Web Services. IMAFA 2004.
[aGabriel] R.P Gabriel (2002). Objects have failed. OOPSA Debate, 11/2002.
[aGadner] T. Gadner (2001). Introduction to Web Services. Ariadne, 2(29),
10/2001, http://www.ariadne.ac.uk/issue29/gadner
[aGscottberger] Y. Gsottberger et etc (2004). Embedding Low-Cost Wireless
Sensors into Universal Plug and Play Environments. LNCS 2920, Heidelberg
Allemagne 01/2004.
[aIN0909] Projet P909-GI (2000). Enabling technologies for IN Evolution
Internet integration. Annexe 3, deliverable 2, 03/2000.
[aJavaBean] A. Quinn (2004). JavaBeans : components for the Java Platform.
http://java.sun.com/docs/books/tutorial/javabeans/index.html
[aKart] M.L. Kart, C. Shapiro (1999) Competition policy in the information
economy. http://faculty.hass.berkeley.edu/~shapiro/software.pdf
[aKung] R. King (1999). Le réseau intelligent : ce qui est fait actuellement. Projet
SERENITE.
[aLara] R. Lara et C. Bussler (2003). Semantic Web Services. FMOODS 2003
172 Bibliographie
[aLui] A. Lui et etc. eSAE (2002) : A Rapid Service Creation Environment for
next-generation services. Bell Labs Technical Journal, v6(2), p18-29, 02/2002.
[aMacker] J.P. Macker et V.D. Park et M.S. Corson (2001). Mobile and wireless
Internet services: putting the pieces together. IEEE Communications Magazine
39(6), p148-155.
[aMainwaring] A. Mainwaring, J. Polastre, R. Szewczyk et D. Culler. Wireless
Sensor Networks for Habitat Monitoring (2002). ACM International Workshop on
Wireless Sensor Networks and Applications, WSNA, Sept.2002.
[aMalone] T. Malone, J. Yates et R. Benjamin (1987). Electronics markets and
electronic hierarchies. Communications of the ACM, Juin 1987, vol 30.
[aMirtain] Mirtain (1999). Service d’annuaire LDAP. JRES99
[aMeijer] E. Meijer C. Szyperski (2001).What's in a name: .NET as a component
framework. Online Proceedings, First OOPSLA Workshop on Language
Mechanisms for Programming Software Components at OOPSLA 2001, October
2001.
[aNGUYEN Cosci04] T.A. Nguyen et T.L. Nguyen. Intermediation Architecture
for Service Creation. COSCI’04, p. 79-82, Vietnam, 03/2004.
[NGUYEN DNAC03] T.L. Nguyen (2003). Voitures intelligentes en réseau.
DNAC2003 - Sharm el Sheikh, Egypte, http://www-rp.lip6.fr/dnac/egypte/22-
Tuan-Loc.pdf
[aNGUYEN JDIR04] T.L. Nguyen, G. Pujolle et F. Krief (2004). Archises-
Nouvelle Architecture pour la Création de Services à valeur ajoutée. JDIR 2004.
[aNGUYEN ICCCN02] T.L. Nguyen (2002). Intelligent Intermediation
Architecture for Creating new value-added Services. ICCCN 2002, Etats-Unis.
Bibliographie 173
[aNGUYEN WCNC05] T.L. Nguyen, A. Jamalipour et G. Pujolle (2004). An
Architecture for Service Creation in Wireless Sensor Networks. Soumis à IEEE
WCNC2005, New Orleans, Etats-Unis.
[aPerry] D.E. Perry et A.M. Wolf (1992). Foundation for the study of software
architecture (1992). ACM SIGSOFT Software Engineering Notes, 17(4), 10/1992,
p40-52.
[aSinha] A. Sinha (1992). Client-server computing. Computing of the ACM,
35(7), 07/1992.
[aSzyperski LNCS02] C.Szyperski (2002). Component Technology-What, where
and how? LNCS 2876.
[aSzyperskiSD022] C. Szyperski (2002). Back to the Universe. Beyond Objects
column. Software Development. Vol. 10, No. 1, September 2002.
[aSzyperskiSD021] C. Szyperski (2001). Services rendered. Beyond Objects
column, Software Development. Vol. 10, No. 1, January 2002.
[aSzyperskiSD012] C. Szyperski (2001). Universe of Composition. Beyond
Objects column, Software Development. Vol. 10, No. 8, August 2002.
[aSzyperskiSD011] C. Szyperski (2001). Components and Web Services. Beyond
Objects column, Software Development. Vol. 9, No. 8, August 2001.
[aSzyperskiSD00] C. Szyperski (2000). Components and architecture. Beyond
Objects column, Software Development. Vol. 8, No. 10, October 2000.
[aWang] H.J Wang et etc. ICEBERG : An Internet core Network architecture for
integrated communications (2000). IEEE Personal Communications 08/2000.
174 Bibliographie
Brevets [bNGUYEN EADS02] TL Nguyen (2002). Mécanisme de transformation. EADS-
Télécom.
[bNGUYEN EADS01] TL Nguyen (2001). Terminal Proxy Server. EADS-
Télécom.
Ouvrages [oArcher] T. Archer (2001). Inside C#. MS Press.
[oAppleman Progz] D. Appleman (1994). La programmation - Comment ça
marche. Dunod.
[oARAGO 24] ARAGO 24 (2000). Architecture de logiciels et réutilisation de
composants. OFTA Paris.
[oBuret] J. Buret et A. Aune (2003). Les portails. Rapport de DESS.
[oChapelle] D. A. Chapelle et T. Jewell (2002). Java Web Services. O’REILLY
[oDertouzos] M. Dertouzos MIT (2001). The Unfinished Revolution.
HarperCollinsPublishers.
[oFennader] R. Fernader et H. Leroux (1999). UML : Principes de modélisation.
Dunod.
[oHagel] J Hagel III et M Singer (1999). Valeur sur le Net – Infomédiaire : les
nouveaux champions du Web. Editions d’Organisation.
[oHeinneman] G.T. Heinneman et W.T. Council (2001). Component-based
software engineering : putting the pieces together. Addison-Wesley.
Bibliographie 175
[oIN Thorner] Jan Thörner (1994). Intelligent Network. Artech House Publishing.
[oIN Gaïti] D.Gaïti/G.Pujolle (1993). L'intelligence dans les réseaux. Eyrolles.
[oJacohson] I. Jacohson (1997). Software Reuse Architecture, Process and
Organization for Business Success. ACM Press.
[oLowy] J. Lowy (2003). .NET Components. O’REILLY.
[oMesserchmitt 03] D.G. Messerchmitt et C. Szyperski (2003). Software
Ecosystem. MIT Press (2003).
[oPlatt] D.S. Platt (2001). Introduction to Microsoft.NET. MS Press.
[oPujolle 03] G. Pujolle (2003). Les Réseaux. Eyrolles.
[oZnaty] S. Znaty (1997). Les Réseaux intelligents : Ingénierie des service de
télécommunication. Hermes Sciences.
[oSzyperski 02] C. Szyperski (2002). Component Software - Beyond Object-
Oriented Programming. Addison-Wesley, 2nd edition.
[oXSLT] M. Kay (2001). XSLT : Programmer’s Reference. Wrox.
RFC [rIN Q12xx] Réseau Intelligent, Recommandation Q12xx de UIT-T.
[rRFC1866] T. Berners-Lee et D. Connolly. Hypertext Markup Language-2.0.
Internet RFC 1866 (11/1995).
[rRFC1945] T. Berners-Lee, R. T. Fielding, et H. F. Nielsen (1996). Hypertext
Transfer Protocol - HTTP/1.0. Internet RFC 1945.
176 Bibliographie
[rRFC2251]. LDAP v3. http://www.faqs.org/rfcs/rfc2251.html
[rRFC2396]T. Berners-Lee, R. T. Fielding, et L. Masinter (1998). Uniform
Ressource Identifiers (URI): Generic syntax. Internet RFC 2396 .
Web [wAvalon] Projet Avalon: http://avalon.apache.org
[wBEA] BEA Systems. http://www.bea.com
[wCocoon] Cocoon Apache. http://xml.apache.org/cocoon
[wCOM] COM de Microsoft. http://www.microsoft.com/com
[wCSTA]ECMA.
http://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm
[wDotNET] Microsoft.NET. http://www.microsoft.com/dotnet
[wEJB] Composant JavaBeans. http://java.sun.com/products/javabeans
[weLiza] Projet eLiza. Recherche d’IBM.http://www-1.ibm.com/servers/automatic
[wFramework] .NET Framework. http://msdn.microsoft.com/netframework
[wH323] IUT-T. http://www.openh323.org
[wHarris] J.Harris, CI Lab. Composant concept.
[wInFutur] J.C Merlin et G. Roucairol (2000). Rapport du groupe Internet du futur
RNRT. http://www.telecom.gouv.fr/rnrt/idf
Bibliographie 177
[wJAIN] Sun JAIN Integrated Network APIs for the Java platform.
http://java.sun.com/products/jain
[wLiscano] R. Liscano. Service Discovery in Sensor Networks : an overview.
http://www.site.uottawa.ca/~rliscano
[wLowydotNET] J. Lowy. dotNET Component-Oriented Development.
http://www.idesign.net
[wMeyers] J. Meyers. A short history of the computer.
http://wwwsoftlord.com/comp
[wMono] Projet Mono. http://www.go-mono.com
[wMontculier] C. Montculier (2001). Le rôle de l’infomédiaire.
http://www.01net.com
[wNetworking] K.Kenedy - Interagency working group on Information
Technology Research and development (2002). Networking and Information
technology research and development- Investing in our future. Report to US
President and US Congress.
[wOpenSource] Open Source Initiative. http://www.opensource.org
[wOSGI] Alliance OSGI. http://www.osgi.org
[wONE] Sun ONE. http://sun.com/software/sunone
[wOxygen] Projet de recherche de MIT. http://oxygen.lcs.mit.edu
[wPARLAY] The Parlay Industry Working Group. http://www.parlay.org
[wPML] PML W3c. http://www.w3.org/TR/voicexml20
178 Bibliographie
[wWSCA] H. Kreger (2001).Web Services Conceptual Architecture. IBM WSCA
1.0
[wWebSemantic] W3C Web Semantic. http://www.w3.org/2001/sw
[wWebServices] W3C Web Services. http://www.w3.org/2001/ws
[wSIP] SIP. http://www.ietf.org/html.charters/sip-charter.html
[wSOAP] SOAP. http://www.w3.org/TR/soap
[wUDDI] UDDI. http://www.uddi.org
[wUPNP] Microsoft Corporation (2000). Universal plug and play device
architecture. http://www.upnp.org/download/UPnPDA10_20000613.htm
[wVoIN] Microsoft vehicule. http://www.microsoft.com/automotive
[wWAP] WAP forum. http://www.wapforum.org
[wWS-ARCH] Group de travail W3c, Web Service Architecture.
http://www.w3.org/TR/ws-arch
[wWeb] World Wide Web Consortium (2002). A little history of World Wide
Web. http://www.w2.org/History.html
[wXML] W3C XML. http://www.w3.org/XML
[wXML Schema] XML Schema. http://www.w3c.org/
[wXMLSpy] XML Spy. http://www.xmlspy.com
Bibliographie 179
Thèses [tAndrés] Thèse d’Andrés Farias (2003). Un modèle de composant avec des
protocoles explicites. Université de Nantes.
[tBuranarach] Thèse de Buranarach (2001). The foundation of Semantic
Interoperability on the World Wide Web. University of Pittsburgh, 11/2001.
[tFassino] Thèse de J.P Fassino (2001). THINK : vers une architecture de
systèmes flexibles. Laboratoire des Systèmes Répartis - France Télécom R&D.
[tFielding] Thèse de R.T Fielding (2000). Architecture style and design of
Network-based software architectures. University of California Irvine.
[tMadden] Thèse de S.R. Madden (2003). The design and evaluation of a Query
Processing Architecture for sensor networks. University of California, Berkeley.
[tScheider] Thèse de J.G Scheider (1999). Components, Scripts and Glue : A
conceptual framework for software composition. Université Bern.
[tOliver] Thèse de O. Stiemerling (2000). Component-based Tailorability.
Universitat Bonn.
180 Acronymes
Acronymes
Archises Architecture of Intelligent Semantic Services
API Application Programmer Interface
COM Component Object Model
CLR Common Language Runtime
CSTA Computer Supported Telephony Applications
SCAI Switch to Computer Application Interface
CTI Computer Telephony Interface
DCOM Distributed Component Object Model
DNS Domain Name Server
DLL Dynamic Link Library
DTD Document Type Description
DBMS Database Management System
DSML Directory Services Markup Language
EJB Enterprise JavaBeans
HTTP HyperText Transport Protocol
HTML HyperText Markup Language
Acronymes 181
H.323 Mis au point par l'UIT-T, ce protocole définit un mode de
communication d'égal à égal entre terminaux voix sur un
réseau de paquets IP pour le transport de trafic multimédia
(voix ou vidéo)
IIS Internet Information Server
IP Internet Protocol
JAIN Java Advanced Intelligent Network
LDAP Lightweight Directory Access Protocol
MSIL Microsoft Intermediate Language
OS Operating System
OSI Open System Interconnection
PML Phone Markup Language
PABX Private Automate Branch Exchange
QoS Quality of Service
Q1200 Recommendation de réseau intelligent d’UIT-T
RI Réseau Intelligent
RSCE Rapid Service Creation Environment
SCDL Service Creation Description Language
SGBD Système de Gestion de Base de données
SCE Service Creation Environment
182 Acronymes
SIB Service Independent Building Block
SIP Session Initiation Protocol
SLA Service Level Agreement
TCP Transmission Control Protocol
ToIP Téléphonie sur IP
UDDI Universal Discovery Description & Integration
UIT-T Union Internationale des Télécommunications
UNISTIM Protocol SIP de Nortel Networks
URL Uniform Resource Location
VAS Value-added Service
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WML Wireless Markup Protocol
WSDL Web Service Description Language
XML eXtensible Markup Language
XSL eXtensible Stylesheet Language
XSLT XSL Transformation
184 Annexe A
Annexe A : grammaire du
langage SCDL Le langage SCDL (Service Creation Description Language) a pour but de créer
facilement de nouveaux services via des automates. Ce langage permet de
transformer des données hétérogènes en format commun. Il sera utilisé comme un
automate de base pour assembler, combiner les services hétérogènes. Il est construit
à partir de la syntaxe de XML Schéma [XML Schema], qui est lui-même bâti sur
XML. Voici la syntaxe du SCDL :
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd = http://www.w3.org/2001/XMLSchema elementFormDefault="qualified">
<xsd:element name="display">
<xsd:complexType>
<xsd:attribute name="input-variable" type="xsd:string" use="optional"/>
<xsd:attribute name="view" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="actions">
<xsd:complexType>
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="condition"/>
Annexe A : la grammaire du langage SCDL 185
<xsd:element ref="display"/>
<xsd:element ref="triggering"/>
<xsd:element ref="actions"/>
</xsd:choice>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="condition">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="actions"/>
</xsd:sequence>
<xsd:attribute name="input-variable" type="xsd:string" use="optional"/>
<xsd:attribute name="expression" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="transformation">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input" type="xsd:string"/>
186 Annexe A
<xsd:element name="ruleToXML" type="xsd:string"/>
<xsd:element ref="toXML" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="toXML">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input_XML" type="xsd:string"/>
<xsd:element name="RuleAddTag" type="xsd:string"/>
<xsd:element ref="informative_message" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="informative_message">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input_infor_mes" type="xsd:string"/>
<xsd:element name="intrusion_xx" type="xsd:string"/>
Annexe A : la grammaire du langage SCDL 187
<xsd:element ref="intrusion" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="intrusion">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input_infor_mes" type="xsd:string"/>
<xsd:element name="language_yy" type="xsd:string"/>
<xsd:element ref="multilanguage" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="multilanguage">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="result" type="xsd:string"/>
<xsd:element name="error" minOccurs="0"/>
</xsd:sequence>
188 Annexe A
</xsd:complexType>
</xsd:element>
<xsd:element name="triggering">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="context" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="services">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="telephony"/>
<xsd:element ref="ldap"/>
<xsd:element ref="http-service"/>
<xsd:element ref="web-service"/>
<xsd:element ref="triggering" minOccurs="0"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
Annexe A : la grammaire du langage SCDL 189
<xsd:element name="http-service">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="id" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
<xsd:element ref="transformation" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ldap">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="id" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
<xsd:element ref="transformation" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="xml-service">
<xsd:complexType>
<xsd:sequence>
190 Annexe A
<xsd:element name="id" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
<xsd:element ref="transformation" minOccurs="0"/>
</xsd:sequence></xsd:complexType>
</xsd:element>
<xsd:element name="web-service">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="id" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
<xsd:element ref="transformation" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="telephony">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="id" type="xsd:string"/>
<xsd:element ref="actions" type="xsd:string"/>
<xsd:element ref="transformation" minOccurs="0"/>
</xsd:sequence></xsd:complexType>
</xsd:element></xsd:schema>
Annexe B : exemple de la recherche d’un abonné 191
Annexe B (4.2.1) : recherche
d’un abonné Annexe B illustre l’exemple du chapitre 4.2.1 :
B.1 Demande de lancement du service LDAP
Le service LDAP est demandé par un appel à l'Agent Services LDAP, celui-ci reçoit un message « Service ».
Paramètre Description Type Service Code Présentation du nom, recherche dans l'annuaire 1,
recherche dans l'annuaire 2 ou recherche dans l'annuaire 3
A partir de ce message, l'Agent Service LDAP peut formater la mire d'affichage de saisie des renseignements nécessaires à la recherche.
Ce formatage est réalisé selon un processus tout à fait similaire au formatage des mires d'affichage des résultats. Dans notre exemple, voici les différentes tables et messages :
B.1.1) Ajout de l’intrusion
Au message “Service”, on ajoute l’intrusion (est un niveau relativement faible) grâce à la table :
Message initial Transformation Type de message Intrusion = 4
Le message devient :
Paramètre Description Type Service Code Présentation du nom, recherche dans l'annuaire 1,
recherche dans l'annuaire 2 ou recherche dans l'annuaire 3
Intrusion 4
192 Annexe B
B.1.2) Transformation en message XML
Le message précédent est alors transformé en un message XML « standard » par l’intermédiaire d’une autre table :
Message initial Transformation Type de message <type> Service Code <code> Nom de service Intrusion 4 <intrusion> 4
Le message devient :
<xml version 1.0>
<type> service </type>
<saisie>
<zone_fixe> Nom </zone_fixe>
<zone_variable>
<longeur> 40 </longeur>
<type> alpha_numéric </type>
</zone_varible>
</saisie>
<intrusion> 4 </intrusion>
</xml>
B.1.3) Transformation en écran logique
Au message précédent sont ajoutés des labels et des actions pour consolider le message XML en un « écran logique » grâce à la table suivante :
Message initial Transformation <type> service <title> #search_1
<saisie> <saisie>
Annexe B : exemple de la recherche d’un abonné 193
<zone_fixe> Nom </zone_fixe>
<zone_variable>
<longeur> 40 </longeur>
<type> alpha_numéric </type>
</zone_varible>
<generic_service>
<softkey>
<label> #submit </label>
<action> ldap://ldap.server.com/search
</action>
</softkey>
</generic_service>
</saisie>
Le message devient :
<xml version 1.0>
<title> #search_1 </title>
<saisie>
<zone_fixe> Nom </zone_fixe>
<zone_variable>
<longeur> 40 </longeur>
<type> alpha_numéric </type>
</zone_varible>
<generic_service>
194 Annexe B
<softkey>
<label> #submit </label>
<action> ldap://ldap.server.com/search </action>
</softkey>
</generic_service>
</saisie>
<intrusion> 4 </intrusion>
</xml>
B.1.4) Transformation d’affichage
Chaque attribue majeur écope alors d’un niveau de priorité d’affichage (compris entre 0 et 10) indiquant si l’affichage du tag est primordial ou secondaire, notamment en fonction de la taille de l’écran.
Le niveau 0 indique un tag qu’il ne faut pas afficher. Le niveau 10 indique un affichage indispensable.
Message initial Transformation <title> <title pr=3> <zonefixe> <zonefixe pr=4> <zonevar> <zonevar pr=4> <generic_service> <generic_service pr=4> <intrusion> <intrusion pr=0>
Le message devient :
<xml version 1.0>
<title pr=3> #search_1 </title>
<saisie>
<zone_fixe pr=4> Nom </zone_fixe>
<zone_variable pr=4>
Annexe B : exemple de la recherche d’un abonné 195
<longeur> 40 </longeur>
<type> alpha_numéric </type>
</zone_varible>
<generic_service pr=4>
<softkey>
<label> #submit </label>
<action> ldap://ldap.server.com/search </action>
</softkey>
</generic_service>
</saisie>
<intrusion pr=0> 4 </intrusion>
</xml>
B.1.5) Traduction des labels
Enfin, tous les labels sont remplacés par le texte correspondant selon :
- La capacité d’affichage du terminal,
- La langue utilisée sur le terminal.
Pour chaque famille d’écran donnée, il existe une chaîne dynamique de tables de labels. Chaque table traduit tous les labels du service en une langue donnée. Selon la langue choisie par l’utilisateur (ici le français), la table adéquate est choisie :
Message initial Transformation #search_1
#submit
Recherche de numéro du téléphone dans l’annuaire 1
Envoie
196 Annexe B
Le message devient :
<xml version 1.0>
<title pr=3>
Recherche de numéro du téléphone dans l’annuaire 1
</title>
<saisie>
<zone_fixe pr=4> Nom </zone_fixe>
<zone_variable pr=4>
<longeur> 40 </longeur>
<type> alpha_numéric </type>
</zone_varible>
<generic_service pr=4>
<softkey>
<label> Envoie </label>
<action> ldap://ldap.server.com/search </action>
</softkey>
</generic_service>
</saisie>
<intrusion pr=0> 4 </intrusion>
</xml>
B.2 Traitement de la réponse de l’utilisateur
Lorsque l'utilisateur valide ses entrées, un message « Saisie » est renvoyé à l'Agent Services LDAP. Un contrôle de la conformité de ces entrées peut être assuré à l'aide
Annexe B : exemple de la recherche d’un abonné 197
des champs « Type de donnée » et « Taille du champ de saisie » de la structure de saisie.
Paramètre Description Type Saisie Attributs de filtrage concernés
cn=Henry MARTIN
Nom $Nom =NULL Mot de passe $Mdp =NULL
Les champs « Nom » et « Mot de passe » du message « Saisie » sont NULL : connexion anonyme.
B.3 Interrogation des tables de paramétrage (BIND Request +Search Request)
En supposant que la session anonyme est fermée, l’Agent Services LDAP doit consulter la table du Bind Request du serveur LDAP distant sans prendre en compte d’éventuelles données d’accès personnalisé :
Serveur 211.123.12.26 Port 389 Version 3 Nom $Nom Authentification $MdP
L’interface suivante est donc proposée à l’API de l’Agent LDAP :
Paramètre Description Type Requête Bind Serveur 211.123.12.26 Port 389 Version 3 Nom NULL Authentification NULL
L’Agent LDAP retourne le Bind Response :
Paramètre Description Type Réponse Bind Résultat OK
Remarque : Si le résultat est NOK un message d’erreur descendant est renvoyé au terminal.
198 Annexe B
L'Agent Services LDAP relève alors la liste des attributs (Type ET Valeur) saisis par l'utilisateur pour les intégrer dans le champs « filtre » du message Search LDAP : ici, cn=Henry MARTIN.
Le reste des paramètres de la requête Search est récupéré dans la table du Search Request du serveur LDAP distant :
Serveur Ldap.matranortel.net Objet de base o=base Portée Sub Alias 0 Limite 100 Time-out 60 Type de résultat Type ET Valeur Filtre Cn= ? Attributs de sortie TelephoneNumber
Le message envoyé à l’Agent LDAP est donc :
Paramètre Description Type Requête Search Serveur ldap.matranortel.net Objet de base o=base Portée Sub Alias 0 Limite 100 Time-out 60 Type de résultat Type ET Valeur Filtre Cn= Henry MARTIN Attributs de sortie TelephoneNumber
A la réception du message Search Response, l’Agent Services LDAP initialise le time out de la session courante. Dans notre cas la valeur de ce time out est grande.
La Search Response émise par l’Agent LDAP à l’Agent Services LDAP est la suivante :
Paramètre Description Type Réponse Search Entrée trouvée Cn=Henry Martin, o=MNC, c=fr Résultat OK Attributs de sortie TelephoneNumber=0123456789
Remarque : Si le résultat est NOK un message d’erreur descendant est renvoyé au terminal.
Annexe B : exemple de la recherche d’un abonné 199
B.4 Interrogation des tables de sortie : traitement du résultat
Les cinq transformations habituelles, représentées dans la structure de sortie, sont appliquées au message Search Response…
B.4.1) Ajout de l’intrusion
Au Search Response, on ajoute l’intrusion (le numéro 4 est un niveau relativement faible) grâce à la table :
Message initial Transformation Type de message Intrusion = 4
Le message devient :
Type Réponse Search Entrée trouvée cn=Henry Martin Résultat OK Attributs de sortie TelephoneNumber=0123456789 Intrusion 4
B.4.2) Transformation en message XML
Le message précédent est alors transformé en un message XML « standard » par l’intermédiaire d’une autre table :
Message initial Transformation Type de message <type> #response Résultat <item> Entrée trouvée <name>Henry Martin Attribut de sortie <phone_number> 01 23 45 67 89 Intrusion <Intrusion>4
Le message devient :
<xml version 1.0>
<type> #response </type>
<item>
<name> Henry Martin </name>
200 Annexe B
<phone_number> 01 44 12 32 65 </phone_number>
</item>
<intrusion> 4 </intrusion>
</xml>
B.4.3) Transformation en écran logique
Au message précédent sont ajoutées des labels et des actions pour consolider le message XML en un « écran logique » grâce à la table suivante :
Message initial Transformation <type> response <title> #response
<phone_number>
<phone_service>
<softkey>
<label> #call
<action> phone://01 23 45 67 89
</softkey>
</phone_service>
<generic_service>
<softkey>
<label> #save
<action> annuaire://save/0123456789
</softkey>
</generic_service>
Le message devient :
<xml version 1.0>
<title> #response </title>
Annexe B : exemple de la recherche d’un abonné 201
<item>
<name> Henry Martin </name>
<phone_number> 01 44 12 32 65 </phone_number>
<phone_service>
<softkey>
<label> #call </label>
<action> phone:// 01 44 12 32 65 </action>
</softkey>
</phone_service>
<generic_service>
<softkey>
<label> #save </label>
<action> annuaire://save/0144123265 </action>
</softkey>
</generic_service>
</item>
<intrusion> 4 </intrusion>
</xml>
Remarque : Si plusieurs entrées ont résulté de la recherche, une action générique #Next (softkey « Suite ») doit être ajoutée aux premiers items.
B.4.4) Transformation d’affichage
Chaque attribue majeur écope alors d’un niveau de priorité d’affichage (compris entre 0 et 10) indiquant si l’affichage du tag est primordial ou secondaire, en fonction notamment de la taille de l’écran.
202 Annexe B
Un niveau à 0 indique un tag qu’il ne faut pas afficher. Un niveau 10 indique un affichage indispensable.
Cette transformation est assurée par la table suivante :
Message initial Transformation <phone_number> <phone_number pr=5> <phone_service> <phone_service pr=5> <generic_service> <generic_service pr=4 <name> <name pr=3> <title> <title pr=2> <intrusion> <intrusion pr=0>
Le message devient :
<xml version 1.0>
<title pr=3> #response </title>
<item>
<name pr=4> Henry Martin </name>
<phone_number pr=5> 01 44 12 32 65 </phone_number>
<phone_service pr=5>
<softkey>
<label> #call </label>
<action> phone:// 01 44 12 32 65 </action>
</softkey>
</phone_service>
<generic_service pr=4>
<softkey>
<label> #save </label>
<action> annuaire://save/0144123265 </action>
</softkey>
Annexe B : exemple de la recherche d’un abonné 203
</generic_service>
</item>
<intrusion pr=0> 4 </intrusion>
</xml>
B.4.5) Traduction des labels
Enfin, tous les labels sont remplacés par le texte correspondant selon :
- La capacité d’affichage du terminal,
- La langue utilisée sur le terminal.
Pour chaque famille d’écrans donnée, il existe une chaîne dynamique de tables de labels. Chaque table traduit tous les labels du service dans une langue donnée. Selon la langue choisie par l’utilisateur (ici le français), la table adéquate est choisie :
Message initial Transformation #response Résultat de la recherche #call Appeler #save Enregistrer
Le message devient :
<xml version 1.0>
<title pr=3> Résultat de la recherche</title>
<item>
<name pr=4> Henry Martin </name>
<phone_number pr=5> 01 44 12 32 65 </phone_number>
<phone_service pr=5>
<softkey>
<label> Appel </label>
<action> phone:// 01 44 12 32 65 </action>
204 Annexe B
</softkey>
</phone_service>
<generic_service pr=4>
<softkey>
<label> Enregistrer</label>
<action> annuaire://save/0144123265 </action>
</softkey>
</generic_service>
</item>
<intrusion pr=0> 4 </intrusion>
</xml>
Ce message peut alors être traité par le browser du serveur Archises pour construire l’écran d’affichage des résultats (figure 85) :
Figure 85 : Service à valeur ajoutée d’Archises
Annexe C : fichiers PML d’exemple utilisés pour les tests 205
Annexe C (4.2.2) : fichiers
PML utilisés pour les tests C.1 Généralités
Les fichiers du service sont stockés dans un répertoire du PC hébergeant le serveur
Archises. Ce répertoire est également déclaré auprès des deux serveurs HTTP (co-
localisés également sur le même PC). Le serveur IIS est accessible par le port TCP
standard 80, le serveur Apache est accessible par le port 81.
C.2 Fichier servextern.xml
Le fichier de configuration du serveur Archises :
<servers timeout="1">
<server name="hello" link="http://127.0.0.1/servext/servexternIIS.xml"/>
<server name="hello2" link="http://127.0.0.1:81/servext/servexternApache.xml"/>
</servers>
C.3 Fichier servexternApache.xml
<services>
<service name="A Hello Apache" link="http:// 127.0.0.1/servext/hello.pml"/>
</services>
C.4 Fichier servexternIIS.xml
<services>
<external_service name="EuroToUSD"
206 Annexe C
link="http://localhost/servext/euro_usd.asp"></external_service>
<internal_service name="Date"
link="http://localhost/serveurArchises/date.asp">
</ internal_service>
<dictionary link=""></dictionary>
</services>
C.5 Fichier euro_usd.asp
<%@language="vbscript"%>
<pml>
<page id="" title="Calculette">
<section id="" title="">
Devise : <input name="dev" type="text" size="2" maxlength="2" format="alphanumerical"/><br/>
Montant : <input name="somme" type="text" size="6" maxlength="6" format="numerical"/>
<link href="ptp://Extern/GetFile?link=http://localhost/serveurArchises/convert_euro_usd.asp?montant=somme;devise=dev" title="$label#Terminal/Link/Valid"/>
<link href="ptp://Extern/GetServices" title="$label#Terminal/Link/back"/>
</section>
</page>
</pml>
C.6 Fichier date.asp
Fichier pour affichier la Date du C5.
<%@language="vbscript"%>
Annexe C : fichiers PML d’exemple utilisés pour les tests 207
<pml>
<page id="" title="Date">
<section id="" title="">
Date: <%Response.Write(DATE)%><br>
Time: <%Response.Write(TIME)%>
<link href="ptp://Extern/GetServices" title="$label#Terminal/Link/back"/>
</section>
</page>
</pml>
C.7 Fichier hello.pml
<pml>
<page id="1" title="Bonjour!">
<section>
<link href="ptp://Extern/GetFile?link=http://127.0.0.1/servext/suite.pml"
title="SuiteA"/>
</section>
</page>
</pml>
C.8 Fichier suite.pml
La suite du fichier hello.pml (button SuiteA) :
<pml>
<page id="1" title="Suite">
208 Annexe C
<section>
C'est la suite %Home()
<link href="ptp://Extern/GetFile?link=http://127.0.0.1/servext/plante.pml"
title="Plante"/>
52 c'est %name(52)
</section>
<session>
<br/>Ceci est la deuxième page
%Home() %annuaire()
%Call(52,send) %Call(52)
</section>
</page>
</pml>
C.9 Fichier plante.pml
En cas d’erreur, ce fichier est déclenché :
<pml>
<page id="1" title="Plante!">
<section>Sélectionner "Plante" SVP%Home()
<link href="ptp://Extern/GetFile?link=http://127.0.0.1/error.pml" title="Err404"/>
</section>
</page>
</pml>