archises - nouvelle architecture pour la création de...

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


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


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


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


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


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 à


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.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).


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.


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).


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

http://www.fnac.fr/

http://www.sncf.com/


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


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.




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


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


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.


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.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


• 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.


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


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).


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


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 :


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


- 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).


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


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


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


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


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.


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


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.


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).


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


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


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.


- 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)


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


- 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.


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.


- « 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


2.3.5.2 service (composants)=components+scripts+glues


- 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].


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.


- 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].


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


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


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.


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


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


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.


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


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


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.


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.


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


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


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.


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


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).


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


- 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.


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.


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


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


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>


<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.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


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


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


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


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]


<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>


<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>


</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>


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>


<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


<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: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"/>

<xsd:element ref="intrusion" type="xsd:string"/>


</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="intrusion">

<xsd:complexType>

<xsd:sequence>


<xsd:element name="language_yy" type="xsd:string"/>

<xsd:element ref="multilanguage" type="xsd:string"/>


</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="multilanguage">

<xsd:complexType>

<xsd:sequence>


<xsd:element name="result" type="xsd:string"/>


</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: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


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.


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


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.


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


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


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


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


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.


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


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.


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


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).


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é.


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

mailto:[email protected]


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,


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…


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).


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,


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.


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


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.


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).


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


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.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.


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)


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 :


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 :


Type Requête Search

Serveur Serveur LDAP

Objet de base Base de la recherche

Portée Profondeur de la recherche

Alias Gestion d’alias


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 :


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:


Type Service

Code Présentation du nom, recherche dans l'annuaire 1,

recherche dans l'annuaire 2 ou recherche dans l'annuaire


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 :


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.


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


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


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.


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 :


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.


Cette transformation doit être réalisée selon les règles décrites dans la table

suivante:


<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é :


<tag> <tag pr=value>


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 :


#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.


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).


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)


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>


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 :


[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


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.


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


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.


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.


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 :


[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


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 :


[(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 :


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


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

http://doi.acm.org/10.1145/514183.514185

http://doi.acm.org/10.1145/514183.514185

http://www.ariadne.ac.uk/issue29/gadner

http://faculty.hass.berkeley.edu/~shapiro/software.pdf

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.

http://www.cs.berkeley.edu/%7Eculler/papers/wsna02.pdf

http://www.cs.berkeley.edu/%7Eculler/papers/wsna02.pdf

http://www.research.microsoft.com/users/cszypers/pub/Components.pdf

http://www.research.microsoft.com/users/cszypers/pub/Components.pdf

http://oopsla.acm.org/2001/fp/workshops/31.html

http://oopsla.acm.org/2001/fp/workshops/31.html

http://www-rp.lip6.fr/dnac/egypte/22-Tuan-Loc.pdf

http://www-rp.lip6.fr/dnac/egypte/22-Tuan-Loc.pdf

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.

http://www.sdmagazine.com/documents/sdm0209h/

http://www.sdmagazine.com/beyond/


http://www.sdmagazine.com/

http://www.sdmagazine.com/documents/sdm0201i/




http://www.sdmagazine.com/documents/sdm0208h/




http://www.sdmagazine.com/documents/sdm0108c/




http://www.sdmagazine.com/documents/sdm0010k/




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

http://www.faqs.org/rfcs/rfc2251.html

http://avalon.apache.org/

http://www.bea.com/

http://xml.apache.org/cocoon

http://www.microsoft.com/com

http://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm

http://www.microsoft.com/dotnet

http://java.sun.com/products/javabeans

http://msdn.microsoft.com/netframework

http://www.openh323.org/

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

http://java.sun.com/products/jain

http://www.site.uottawa.ca/~rliscano

http://www.idesign.net/

http://wwwsoftlord.com/comp

http://www.go-mono.com/

http://www.01net.com/

http://www.opensource.org/

http://www.osgi.org/

http://sun.com/software/sunone

http://www.parlay.org/

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

http://www.w3.org/2001/sw

http://www.w3.org/2001/ws

http://www.ietf.org/html.charters/sip-charter.html

http://www.w3.org/TR/soap

http://www.uddi.org/

http://www.upnp.org/download/UPnPDA10_20000613.htm

http://www.microsoft.com/automotive

http://www.wapforum.org/

http://www.w3.org/TR/ws-arch

http://www.w2.org/History.html

http://www.w3.org/XML

http://www.w3c.org/

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:element ref="condition"/>

http://www.w3.org/2001/XMLSchema

Annexe A : la grammaire du langage SCDL 185

<xsd:element ref="display"/>

<xsd:element ref="triggering"/>

<xsd:element ref="actions"/>

</xsd:choice>


</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: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:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="informative_message">

<xsd:complexType>

<xsd:sequence>


<xsd:element name="intrusion_xx" type="xsd:string"/>


<xsd:element ref="intrusion" type="xsd:string"/>


</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="intrusion">

<xsd:complexType>

<xsd:sequence>


<xsd:element name="language_yy" type="xsd:string"/>

<xsd:element ref="multilanguage" type="xsd:string"/>


</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="multilanguage">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="result" type="xsd:string"/>


</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:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="services">

<xsd:complexType>


<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>


<xsd:element name="http-service">

<xsd:complexType>

<xsd:sequence>




</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="ldap">

<xsd:complexType>

<xsd:sequence>




</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="xml-service">

<xsd:complexType>

<xsd:sequence>

190 Annexe A




</xsd:sequence></xsd:complexType>

</xsd:element>

<xsd:element name="web-service">

<xsd:complexType>

<xsd:sequence>




</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="telephony">

<xsd:complexType>

<xsd:sequence>




</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


<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>



<zone_variable>



</zone_varible>

<generic_service>

<softkey>

<label> #submit </label>

<action> ldap://ldap.server.com/search

</action>

</softkey>

</generic_service>

</saisie>


<xml version 1.0>

<title> #search_1 </title>

<saisie>


<zone_variable>



</zone_varible>

<generic_service>

194 Annexe B

<softkey>


<action> ldap://ldap.server.com/search </action>

</softkey>

</generic_service>

</saisie>


</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>


<xml version 1.0>

<title pr=3> #search_1 </title>

<saisie>

<zone_fixe pr=4> Nom </zone_fixe>

<zone_variable pr=4>




</zone_varible>

<generic_service pr=4>

<softkey>



</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


<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>



</zone_varible>


<softkey>

<label> Envoie </label>


</softkey>

</generic_service>

</saisie>


</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


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.


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


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


<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>


</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>


<xml version 1.0>

<title> #response </title>


<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>


</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>


<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>


</softkey>

</phone_service>


<softkey>

<label> #save </label>


</softkey>


</generic_service>

</item>


</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


<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>


204 Annexe B

</softkey>

</phone_service>


<softkey>

<label> Enregistrer</label>


</softkey>

</generic_service>

</item>


</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>

archises - nouvelle architecture pour la création de...

Documents