Service Ngn Pfe Meharouech Sourour

5/7/2018 Service Ngn Pfe Meharouech Sourour - slidepdf.com

http://slidepdf.com/reader/full/service-ngn-pfe-meharouech-sourour 1/70

RAPPORT DE PROJET DE FIN D’ETUDES

Filière

Ingénieurs en Télécommunications

Option

Réseaux

Prototype de création de nouveaux

services dans les réseaux NGN

Elaboré par :

Meharouech Sourour

Encadré par :

M. Zouhair Trabelsi

M. Mohamed Zerzeri

Année universitaire : 2004/2005



A ma mère …



Av a n t p r o p o s

Dans le cadre de ma formation d’ingénieur au sein de l’Ecole Supérieur des Communications

de Tunis, option « réseaux », je suis menée à effectuer ce projet de fin d’étude qui représente

l’accomplissement de mon second cycle d’études supérieures.

Ce projet a été mené en collaboration entre le centre d’étude et de recherche des

télécommunications (CERT) et l’école supérieure des communications de Tunis.

Je tiens à exprimer ma gratitude à M. Mohamed ZERZERI, ingénieur principale au CERT,

pour l’encadrement de mon travail et pour son soutien, ses encouragements, ses aides précieuses,

sa disponibilité et sa patience.

Je tiens également à remercier M. Mounir FRIKHA, de m’avoir guidé et conseillé durant

l’élaboration de ce projet de fin d’études.

Mes remerciements s’adressent également à M. Zouhair Trabelsi pour ses conseils précieux et

ses remarques pertinentes qui m’ont aidé à l’accomplissement

de mon travail.

J’exprime aussi toute ma gratitude envers le corps professoral et administratif de l’Ecole

Supérieur des Communications de Tunis pour l’élaboration de mon projet



Projet de Fin d’études 2004-2005

Sommaire

Introduction générale........................................................................................................................1

Chapitre1............................................................................................................................................3

Introduction ......................................................................................................................................41- Architecture du réseau NGN........................................................................................................42 - Le réseau d’accès ........................................................................................................................6

2.1- Les réseaux d’accès fixes......................................................................................................62.2- Les technologies d’accès fixe sans fil / radio........................................................................62.3- Les réseaux d’accès mobiles.................................................................................................6

3- Les évolutions au niveau de la couche transport .........................................................................64- La couche contrôle.......................................................................................................................8

4.1- Les entités fonctionnelles du coeur de réseau NGN .............................................................84.1.1- La Media Gateway (MG)...............................................................................................8

4.1.2- La Signalling Gateway (SG)..........................................................................................84.1.3- Le serveur d’appel ou Media Gateway Controller (MGC)............................................9

4.2- Les familles de protocoles d’un réseau NGN .......................................................................95- La couche service.......................................................................................................................106- Conclusion .................................................................................................................................10

Chapitre2 : Le modèle OSA ...........................................................................................................12

Introduction ....................................................................................................................................131- Présentation des organismes travaillant sur le modèle OSA .....................................................13

1.1- 3GPP / OSA ........................................................................................................................131.2- Le groupe Parlay.................................................................................................................13

1.3- JAIN (Java APIs for Interoperable Networks)....................................................................142- L’architecture OSA/Parlay.........................................................................................................14

2.1- Introduction.........................................................................................................................142.2- L’architecture OSA 3GPP...................................................................................................152.3- Présentation de l’architecture OSA/Parlay .........................................................................18

3- Conclusion .................................................................................................................................22

Chapitre3 : Le modèle Web Services.............................................................................................23

Introduction ....................................................................................................................................241- Origines des services Web.........................................................................................................242- Définition et description des Service Web.................................................................................24

3- Les domaines d’utilisation des services Web ............................................................................253.1- L’intégration d’applications................................................................................................253.2- Les projets de portail...........................................................................................................26

4- Principales technologies de développement de Services Web ..................................................264.1- XML -eXtensible Markup Language..................................................................................274.2- Le protocole d’accès SOAP: Simple Object Access Protocol............................................27

4.2.1- Définition et description de SOAP ..............................................................................274.2.2- Processus d’échange de messages en SOAP ...............................................................28

SUPCOM



Projet de Fin d’études 2004-2005

4.2.3- La spécification SOAP.................................................................................................294.3- WSDL : Web Services Description Language...................................................................31

4.3.1- Définitions et description de WSDL...........................................................................314.3.2- Structure d’un document WSDL .................................................................................32

4.4- UDDI: Universal Description Discovery and Integration ..................................................33

4.4.1- Définition et description d’UDDI ................................................................................334.4.2- Application de l’UDDI ................................................................................................335- Cycle de vie d’un service Web ..................................................................................................34

5.1- Cycle de vie d’utilisation ....................................................................................................345.2- Cycle de vie complet...........................................................................................................355.3- Exemple d’un Web services................................................................................................37

6- Gestion de la sécurité dans les services Web.............................................................................387- Les points forts des services Web..............................................................................................39

7.1- Universalité.........................................................................................................................397.2- Simplicité d’utilisation........................................................................................................397.3- Couplage lâche des applications : simplification des contraintes d’urbanisation...............39

8- Le niveau de maturité des services Web....................................................................................40Chapitre 4 : Comparaison entre les deux modèles OSA et Web Services .................................42

Introduction ....................................................................................................................................431- Comparaison des fonctions présentes dans chaque architecture................................................432- Comparaison des interfaces définies dans chaque architecture ................................................44

2.1- Parlay/OSA .........................................................................................................................442.2- Web services .......................................................................................................................46

3- Degré de dépendance de chaque modèle vis-à-vis du réseau ....................................................464- UDDI vs Framework..................................................................................................................475- Comment peuvent-ils converger ? .............................................................................................476- Conclusion .................................................................................................................................49

Chapitre5 : Développement d’un prototype pour la création de nouveaux services................50

1- Les différentes plates formes existantes ....................................................................................512- Pourquoi la plate-forme .NET pour développer notre prototype...............................................513- Pourquoi le langage de programmation Java ............................................................................524- Notre objectif .............................................................................................................................525- Modèle de programmation de notre Web service......................................................................526- Les étapes de création du prototype...........................................................................................52

6.1- Etape 1 : Définition et implémentation de la classe de service...........................................536.2- Etape 2 : Déploiement et description de la classe Java à un serveur SOAP.......................556.3- Etape 3 : La publication du web service .............................................................................596.4- Etape 4 : La découverte du service .....................................................................................62

7- Conclusion .................................................................................................................................63

Conclusion générale ........................................................................................................................64

SUPCOM



Projet de Fin d’études 2004-2005 Introduction générale

Introduction générale

Dans le domaine des Services de Télécommunication de 3ème Génération, il est d’actualitéd’utiliser le slogan « Any time, Any How, Anywhere ».

Du point de vue des utilisateurs finaux, ce slogan exprime leur souhait d’accéder à un servicedepuis n’importe quel réseau, en utilisant n’importe quel type de terminal tout en bénéficiant desmêmes préférences de présentation et de service. Du point de vue des concepteurs etdéveloppeurs d’application, cela requiert un effort d’abstraction, premièrement pour capturer lespréférences de l’utilisateur, et deuxièmement, pour matérialiser et fournir une telle qualité deservice.

Différents systèmes répondent déjà en partie aux souhaits des utilisateurs. Cependant, lestechniques utilisées restent limitées. Ils leur manquent l’aspect d’ouverture, c'est-à-dire, d’unepart, la possibilité d’être applicables à tous types de terminaux et réseaux d’accès, et d’autre part,de couvrir tout type de service. L’aspect de standardisation est particulièrement important dèsqu’il s’agit de fournir un service mettant en jeu des domaines différents : Domaine del’utilisateur, domaines des opérateurs de réseaux, domaine des fournisseurs de service.

Le groupement d’opérateurs Third Generation Partnership Project (3GPP) vise à étudier cesaspects novateurs des services offerts aux utilisateurs et élaborer un environnement permettantd’offrir à l’utilisateur le même service sur n’importe quel type de terminal et à travers n’importequel type de réseau, ceci où que soit localisé l’utilisateur.

Dans ce PFE intitulé «Prototype de création de nouveaux services dans les réseaux NGN»nous étudions l’architecture des deux modèles de création de services, OSA et Web services.Nous effectuons par la suite une comparaison entre ces deux approches. Suite à cettecomparaison, nous allons choisir l’une des deux approches pour développer un prototype pour lacréation de nouveaux services.

Ce Projet de Fin d’Etude est constitué de 5 chapitres :

Le premier chapitre introduit des concepts de base des réseaux NGN, tel qu’elles sont définispar le cabinet Arcome pour le compte de l’ART1.

Le deuxième chapitre présente l’architecture Open Service Access (OSA), c’est à dire « AccèsOuvert aux Services » permettant aux nouveaux services d’exploiter les fonctionnalités desréseaux au moyen d’interfaces standardisées. Ce chapitre présente aussi la spécification dugroupe Parlay relative à cette approche.

1 ART : Autorité de Régulation des Télécommunications française

SUPCOM -1 -



Projet de Fin d’études 2004-2005 Introduction générale

Le troisième chapitre aborde la spécification du Web services dont l’objectif est de faireinteragir des composants hétérogènes, distants et indépendants dédiés particulièrement auxapplications de type Business to Business et Enterprise Application Integration.

Le quatrième chapitre compare les deux architectures de création de nouveaux services OSAet Web services, et suite à cette comparaison nous allons justifier le choix de retenir l’une des

deux approches pour notre travail.Dans le dernier chapitre, nous allons présenter les différentes plates formes de travail, ainsi

que les étapes pour le développement de notre prototype de création de services, nous terminonspar créer des interfaces pour les utilisateurs de ce service et qui cache la complexité de ces étapesà l’utilisateur.

SUPCOM -2 -



Projet de Fin d’études 2004-2005 Concepts de base du réseau NGN

Chapitre

1Concepts de base du

réseau NGN

1- Introduction2- Architecture du réseau NGN

3- Conclusion

SUPCOM -3 -




Introduction

L’évolution progressive du monde des télécommunications vers des réseaux et des services denouvelle génération est aujourd’hui une tendance forte qui suscite l’intérêt d’une majoritéd’acteurs. Elle résulte de la conjonction d’un ensemble de facteurs favorables dont :

• Les évolutions profondes du secteur des télécommunications ;• Le développement de gammes de services nouveaux ;• Les progressions technologiques d’envergure dans le domaine des réseaux de données.

Il en résulte de ce contexte et afin de s’adapter aux grandes tendances qui sont la recherche desouplesse d’évolution de réseau, la distribution de l’intelligence dans le réseau, et l’ouverture àdes services tiers, une évolution vers un nouveau modèle de réseaux et de services appelé NGN(Next Generation Networks).

Les NGN sont basés sur une évolution progressive vers le « tout IP » et sont modélisés encouches indépendantes dialoguant via des interfaces ouvertes et normalisées.

Les réseaux de télécommunications traditionnels évolueront vers un modèle ouvert, distribué,fortement basé sur le protocole IP et la transmission en mode paquet en général. Cette évolutiontechnologique se fera de manière progressive pour les opérateurs et transparente pour lesutilisateurs.

Ce chapitre présentera une étude technologique afin de décrire et comprendre l’ensemble desconcepts nouveaux globalement désignés sous l’appellation NGN. Il inclut aussi une synthèsedes évolutions technologiques majeures et le détail des nouveaux concepts liés aux NGN.

1- Architecture du réseau NGN

Les réseaux de nouvelle génération peuvent être présentés comme un concept permettant dedéfinir et déployer des réseaux évolutifs et favorisant pour les fournisseurs de services et lesopérateurs la création et la gestion de services innovants. Les services doivent être évolutifs etaccessibles indépendamment du réseau d’accès utilisé.

Le NGN est caractérisé par plusieurs éléments essentiels:• Un coeur de réseau unique et mutualisé pour tous types d’accès et de services ;

• Une architecture de coeur de réseau en 3 couches : Transport, Contrôle et Services.

SUPCOM -4 -




Figure1.1 : Principe général d’architecture d’un réseau NGN (Source ART)

• Une évolution du transport en mode paquet (une convergence progressive vers le tout IP);

• Des interfaces ouvertes et normalisées entre chaque couche, et notamment au niveau des

couches contrôle et services afin de permettre la réalisation de services indépendants du

réseau ;

• Le support d’applications multiples, multimédia, temps réel, en mobilité totale, adaptables

à l’utilisateur et aux capacités des réseaux d’accès et des terminaux ;

• La prise en compte de réseaux d’accès multiples ;

• La prise en compte de terminaux multiples.

Le schéma, ci-dessous, présente de manière très simplifiée, l’architecture physique d’unréseau NGN.

Figure 1.2 : Architecture physique d’un cœur de réseau NGN (source ART)

SUPCOM -5 -




2 - Le réseau d’accès

Ce paragraphe va présenter les principales technologies d’accès actuellement connues dont lagénéralisation contribuera à alimenter le besoin et le développement des NGN.

2.1- Les réseaux d’accès fixes

Les réseaux d’accès fixes s’adaptent progressivement au support de services de données à hautdébit :

• Le réseau téléphonique commuté, initialement support des services voix, a permisune ouverture à des services voix/données haut débit grâce aux technologies xDSLaccessibles aux nouveaux opérateurs par le biais du dégroupage de la boucle locale.

• L’accès Ethernet, initialement conçu pour fournir des services de données (IP) enentreprises, voit son usage s’étendre en termes de débit, de périmètre d’utilisation etde services transportés (voix et donnée, multimédia).

2.2- Les technologies d’accès fixe sans fil / radio Plusieurs technologies permettent de fournir des services voix et données fixes en utilisant un

accès radio. On citera notamment la boucle locale radio, les réseaux locaux sans fil et Bluetooth.Ces technologies sont globalement récentes (pas plus de quelques années), mais apparaissent trèsprometteuses et promises à des évolutions et un développement très importants. Quant auxréseaux satellitaires, plusieurs tentatives de déploiement déjà relativement anciennes ont mené àdes échecs (avant tout d’ordre économique du fait des coûts particulièrement élevés de

déploiement), mais ils pourraient, dans les prochaines années, trouver enfin leur place parmi lesréseaux d’accès effectivement utilisés pour fournir des services « fixes ».

2.3- Les réseaux d’accès mobiles

Plusieurs réseaux d’accès radio fournissant des services de radiocommunications mobilespublics sont présentés.

Le GSM est une technologie historiquement orientée vers les services voix et données basdébit mature et très largement répandue, mais évolue actuellement avec l’ajout de services detransmission de données en mode paquet (GPRS), et à court terme avec l’émergence de lanouvelle génération « convergente » voix/données/multimédia : l’UMTS.

3- Les évolutions au niveau de la couche transport

La couche Transport gère l’acheminement du trafic vers sa destination. Les principalesévolutions du réseau de transport concernent les technologies de transmission et de commutationutilisées sur les liaisons qui interconnectent les réseaux d’accès au coeur de réseau.

La question qui se pose c’est comment les backbones sont susceptibles d’évoluer afin desupporter le très haut débit, et surtout le transport unifiée de flux mixtes voix/donnée/multimédiaavec la qualité de service adéquate.

SUPCOM -6 -




Figure 1.3 : Architecture du réseau NGN (source ART)

Tout d’abord il faut distinguer entre le niveau réseau de transmission et le niveau réseau de

commutation dans un « réseau de transport » (couche transport)

• Le réseau de transmission correspond au réseau physique de liens et de nœuds quidesservent une zone (un immeuble, une ville, une région, un pays ou un continent).

• Le réseau de commutation correspond à certains noeuds qui permettent d’acheminerune communication à travers le réseau de transmission en fonction de sa destination.

Dans les architectures traditionnelles, un opérateur possède (ou loue) un réseau detransmission sur lequel s’appuient en général plusieurs réseaux de commutation, l’un dédié à la

commutation de la voix, l’autre dédié à la commutation de données. L’idée qui sous-tend lesNGN est de fusionner ces deux réseaux en un seul. Si l’on visualise les technologies mises en jeuen s’appuyant sur le modèle en couches OSI (Open System Interconnection), la séparation entreréseau de transmission et réseau de commutation est très nette.

Pour la mise en oeuvre de ces réseaux de transport « de nouvelle génération », on peut mettreen évidence deux évolutions majeures des réseaux de transport au niveau des réseaux detransmission et des réseaux de commutation.

Concernent les réseaux de transmission, les techniques dominantes sont remises en cause.

En effet, le multiplexage TDM (Time Division Multiplexing), utilisée en grande majorité dans

les réseaux actuels, est une technique de transmission adaptée pour la commutation de circuitsalors que la tendance actuelle est de migrer les réseaux de transmission actuels vers un réseau detransmission unique, neutre, voire favorable à la commutation de paquets et donc on assisteaujourd’hui à des nombreux développements autour du multiplexage WDM et aussi à desplusieurs évolutions liées à l’optique et au WDM.

SUPCOM -7 -




Concernent les réseaux de commutation, La tendance actuelle est donc de développer unréseau de commutation unique, s’appuyant sur l’actuel réseau de commutation de paquets, et quipermettrait de transporter tout type de trafic (voix, vidéo, donnée, etc.).

Concernant la Commutation IP, La tendance actuelle est la migration d’IPv4 à IPv6. Lesprincipales améliorations de cette dernière version sont l’amélioration du champ ToS renommée

CoS pour Classe of Service, l’intégration par défaut du protocole de sécurité IPsec (InternetProtocol Security), une nouvelle définition des adresses de diffusion, ainsi que l’intégration pardéfaut et l’amélioration des mécanismes de traitement de ces adresses au niveau descommutateurs.

L’objectif de ces différentes évolutions est de répondre à quatre impératifs : l’adéquation auxnouveaux besoins de services, le support de très haut débit, une garantie de qualité de service, etune gestion optimisée du réseau de transport.

4- La couche contrôle

Les évolutions au niveau de la couche contrôle sont majeures. Plusieurs nouveaux mécanismeset protocoles sont mises en jeu et donc une nouvelle architecture qui découle. La coucheContrôle se compose de serveurs dits « softswitch » gérant d’une part les mécanismes de contrôled’appel (pilotage de la couche transport, gestion des adresses), et d’autre part l’accès aux services

(profils d’abonnés, accès aux plates-formes de services à valeur ajoutée).

4.1- Les entités fonctionnelles du coeur de réseau NGN

4.1.1- La Media Gateway (MG)

Les Gateways ont un rôle essentiel : elles assurent non seulement l’acheminement du trafic,

mais aussi l’interfonctionnement avec les réseaux externes et avec les divers réseaux d’accès. LaMedia Gateway est située au niveau du transport des flux média entre le réseau RTC et lesréseaux en mode paquet, ou entre le coeur de réseau NGN et les réseaux d’accès. Elle a pour rôlele codage et la mise en paquets du flux média reçu du RTC et vice-versa (conversion du traficTDM IP). Et aussi la transmission, suivant les instructions du Media Gateway Controller, des fluxmédia reçus de part et d'autre.

4.1.2- La Signalling Gateway (SG)

La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre leréseau NGN et le réseau externe interconnecté selon un format compréhensible par les

équipements chargés de la traiter, mais sans l’interpréter (ce rôle étant dévolu au Media GatewayController). Notamment, elle assure l’adaptation de la signalisation par rapport au protocole detransport utilisé. Cette fonction est souvent implémentée physiquement dans le même équipementque la Media Gateway, d’où le fait que ce dernier terme est parfois employé abusivement pourrecouvrir les deux fonctions MG + SG.

SUPCOM -8 -




4.1.3- Le serveur d’appel ou Media Gateway Controller (MGC)

Dans un réseau NGN, c’est le MGC qui possède « l'intelligence ». Il gère :

• L’échange des messages de signalisation transmise de part et d'autre avec les passerellesde signalisation, et l’interprétation de cette signalisation.

•

Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP,communication avec les serveurs d’application pour la fourniture des services.

• Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge duréseau, etc.

• La réservation des ressources dans le MG et le contrôle des connexions internes au MG(commande des Media Gateways).

Donc dans l’architecture des réseaux NGN, le serveur d’appel, aussi appelé Softswitch ouMedia Gateway Controller (MGC) est le nœud central qui supporte l’intelligence decommunication.

4.2- Les familles de protocoles d’un réseau NGN

La convergence des réseaux voix/données ainsi que le fait d’utiliser un réseau en mode paquetpour transporter des flux multimédia, ayant des contraintes de « temps réel », a nécessitél’adaptation de la couche Contrôle. En effet ces réseaux en mode paquet étaient généralementutilisés comme réseau de transport mais n’offraient pas de services permettant la gestion desappels et des communications multimédia. Cette évolution a conduit à l’apparition de nouveauxprotocoles, principalement concernant la gestion des flux multimédia, au sein de la coucheContrôle.

On peut classer les protocoles de contrôle en différents groupes :

• Les protocoles de contrôle d’appel permettant l’établissement, généralement à l’initiatived’un utilisateur, d’une communication entre deux terminaux ou entre un terminal et unserveur ; les deux principaux protocoles sont H.323, norme de l’UIT et SIP, standarddéveloppé à l’IETF.

• Les protocoles de commande de Media Gateway qui sont issus de la séparation entre lescouches Transport et Contrôle permettent au Softswitch ou Media Gateway Controller degérer les passerelles de transport ou Media Gateway. MGCP (Media Gateway ControlProtocol) de l’IETF et H.248/MEGACO, développé conjointement par l’UIT et l’IETF,sont actuellement les protocoles prédominants.

• Les protocoles de signalisation entre les serveurs de contrôle (ou Media GatewayController) permettant la gestion du plan contrôle au niveau du coeur de réseau avec desprotocoles tels que BICC (Bearer Independant Call Control), SIP-T (SIP pour la

téléphonie) et H.323. L’interconnexion avec les réseaux de signalisation SS7 se faitgénéralement via des passerelles de signalisation ou Signalling Gateways par l’utilisationde protocole tel que SIGTRAN.

SUPCOM -9 -




De plus, l’interconnexion de ces réseaux de données avec les réseaux existants de téléphonie(TDM avec signalisation SS7) a nécessité le développement de protocoles dédiés àl’interconnexion des réseaux et au transport de la signalisation SS7 sur des réseaux en modepaquet.

5- La couche serviceActuellement, les services sont dédiés à un type de réseau : services Réseau Intelligent sur le

réseau téléphonique pour les terminaux téléphoniques (fixes ou mobiles), et services mail, web,news sur les réseaux IP.

L’apparition des nouveaux réseaux d’accès, tels que l’UMTS, le GPRS, l’xDSL, l’Ethernetlongue distance, et la multiplication des terminaux communicants (téléphone mobile GPRS/ UMTS, PDA,…) et la convergence des coeurs de réseaux, poussent à une transformation del’architecture des plates-formes de services.

Cette nouvelle architecture doit offrir la possibilité aux clients d’accéder aux services, quelle

que soit la nature des terminaux et le type de protocole utilisé pour accéder aux plates-formes deservices, via un réseau de transport unifié, en mode paquet. Le service rendu doit être adapté auxbesoins et aux moyens des clients.

Deux modèles principaux et complémentaires émergent de ces besoins d’évolution

d’architecture de la couche Services. Une architecture centrée sur le « Softswitch », basée surl’interface de services normalisée du modèle OSA/Parlay et un modèle orienté « Web Services »,basé sur les technologies et des protocoles issus du monde Internet.

Dans les chapitres suivants, nous allons détailler ces deux architectures, nous proposons aussiune comparaison entre eux et nous terminons par choisir une pour développer notre prototype.

6- Conclusion

Globalement, l’évolution vers les NGN représente encore à ce jour un sujet relativementamont, notamment du point de vue des opérateurs et dans une moindre mesure des pursfournisseurs de services.

En effet, la conjoncture actuelle influe fortement sur les positions vis-à-vis des NGN puisqueles acteurs sont confrontés à des problématiques de financement et de pérennité, ce qui les metdans un contexte peu favorable à des évolutions techniques et à l’apparition de nouveauxbusiness models.

Cela explique une certaine frilosité des acteurs interrogés vis-à-vis des solutions NGN quiprésentent une vision orientée vers une transition douce plutôt qu’une révolution des réseaux etservices, mais qui pourrait se débloquer rapidement si le contexte économique évolue.

Mais on peut dire que la migration vers les NGN apparaît comme un processus inévitable dufait de la convergence voix/données/image et fixe/mobile. Elle est déjà enclenchée par un certainnombre d’acteurs en France, en Europe et sur d’autres continents, et ses impacts doivent doncêtre analysés et anticipés.

SUPCOM -10 -




Cependant elle s’annonce longue (une échelle de temps de 10 à 20 ans semble raisonnable),incomplète (cohabitation inévitable avec les architectures dites traditionnelles) et difficile à courtterme du fait de l’existence de solutions concurrentes ayant des niveaux de fonctionnalités et dematurité différents, et des problématiques d’interopérabilité de bout en bout.

SUPCOM -11 -



Projet de Fin d’études 2004-2005 Le modèle OSA

1- Introduction2- Les différents organismes3- L’architecture OSA

Chapitre

2 Le modèle OSA

SUPCOM -12 -




Introduction

Le modèle OSA (Open Service Access) a été spécifié et standardisé par le Joint API Groupqui fédère les travaux du 3GPP (3rd Generation Partnership Program), de l’ETSI, du JAIN (JavaAPIs for Interoperable Networks) et du Parlay Group.

L’objectif de ce groupe de travail étant de proposer une interface standardisée unique pourl’ensemble des besoins et de maintenir aussi l’indépendance des applications par rapport à latechnologie réseau sous-jacente.

Chaque organisme s’est aligné sur ce modèle fédérateur : le 3GPP à travers SA1 et SA2, ETSIpar le SPAN 14 SPAR et Parlay par le groupe Parlay.

Le modèle OSA est donc partagé et soutenu par un nombre important d’organisations issuesdu monde des télécommunications mobiles et fixes (3GPP, ETSI, Parlay Group) ou transversesaux mondes télécoms et Internet (JAIN).

Dans ce chapitre, nous allons présenter les différentes solutions proposées par chaque

organisme.

1- Présentation des organismes travaillant sur le modèle OSA

1.1- 3GPP / OSA

Le 3GPP (3rd Generation Partnership Project) est le fruit d’une collaboration de plusieursorganismes de standardisation ainsi que la plupart des constructeurs ayant pour objectif de définirun ensemble de spécifications techniques pour les systèmes mobiles de 3ème génération. Enparticulier, le 3GPP demande la définition d’une architecture permettant d’offrir le concept VHE(Virtual Home Environment) et nous pouvons dire que c’est le 3GPP qui est à l’origine de la

définition OSA (Open Service Architecture, devenue Open Service Access). Il a identifié lemodèle OSA comme un des outils nécessaires à la mise en place du concept VHE.

1.2- Le groupe Parlay

Le groupe Parlay est un forum ouvert ayant pour objectif de définir les spécifications d’uneAPI (Application Programming Interface) pour le modèle OSA. Et donc nous pouvons dire quec’est le Parlay Group qui est à l’origine des API d’OSA.

Cette interface doit permettre aux différents acteurs, opérateurs, programmeurs et fournisseursde services, de développer des applications multi-technologies et multi-réseaux : c’est le lien

entre les services et les réseaux.L’API permet de supporter les services d’une tierce partie (ASP), en définissant une

infrastructure gérant les échanges sécurisés entre clients et serveurs.Il faut préciser que le but de Parlay est d’être indépendant d’un langage particulier (utilise

UML, IDL et CORBA) et que Parlay n’est pas un langage, mais un ensemble de définitions detypes de données et de méthodes regroupées au sein d’APIs d’applications.

SUPCOM -13 -




1.3- JAIN (Java APIs for Interoperable Networks)

L’objectif de JAIN est de créer un ensemble ouvert, depuis les fournisseurs de services tiers,en passant par les opérateurs et les constructeurs, jusqu’aux fabricants de terminaux et aux clientsfinaux. Cet ensemble est défini pour être distribué depuis n’importe quel protocole et

«middleware» tels que RMI (Remote Method Invocation), CORBA (Common Object RequestBroker Architecture) et DCOM (Distributed Common Object Model).

L’architecture JAIN s’appuie sur les développements du langage de programmation JAVA. Etson service de contrôle d’appel est basé sur celui défini par le groupe Parlay.

Ainsi l’architecture JAIN s’articule autour de deux axes :

• Les spécifications des « Protocole API » qui définissent l’interface avec les protocoles designalisation des réseaux fixes, mobiles et IP.

• Les spécifications des « Applications API » en charge de la définition des API nécessairesà la création de service, avec l’aide de Java, pour tous les protocoles couverts par les

protocoles API.2- L’architecture OSA/Parlay

2.1- Introduction

A peu près au même moment où la communauté JAIN se mettait en place et débutait sestravaux, British Telecom (BT), Microsoft, Nortel, Siemens et Ulticom formaient le Parlay Group,qui a donné le jour à une panoplie d’APIs orientées objet et indépendantes du langage lesexploitant, afin de faciliter la création de services dans les réseaux publics de tous types.

Les APIs d’applications définies par le groupe Parlay doivent permettre un accès ouvert mais

sécurisé à un ensemble de fonctionnalités aujourd’hui rendues par les différents réseaux privés oupublics. Il est attendu de la publication de ces APIs qu’elles soient utilisées par une plus grandecommunauté de développeurs afin de dynamiser le développement de nouveaux services detélécommunications.

Mais pour ce faire, les spécifications que définit Parlay ont besoin d’un modèle architecturalstandardisé permettant aussi de prendre en compte des abonnés mobiles, et le modèle OSAdéveloppé conjointement par le 3GPP s’est avéré idéal pour une mise en commun des efforts duParlay Group avec le groupe de travail du 3GPP, qui ont dès lors collaboré à l’édification d’unstandard commun OSA/Parlay.

OSA/Parlay n’offre pas seulement la possibilité aux opérateurs d’ouvrir leurs réseaux à desparties tierces, mais s’adresse également aux opérateurs câblés comme aux opérateurs sans fils,en proposant sans différenciation aucune une nouvelle méthode peu coûteuse, rapide et efficacepour créer leurs propres services en fonction de la demande qu’ils perçoivent.

Nous allons par la suite dans cette partie nous intéresser plus particulièrement à la mise encommun des spécifications mises au point par le Parlay Group avec l’architecture OSA (Open

SUPCOM -14 -




Services Architecture) pour services mobiles du 3GPP, alliance à laquelle l’on se réfèrecommunément par la combinaison des deux acronymes : OSA/Parlay.

2.2- L’architecture OSA 3GPP

Le 3GPP représente la co-opération de différents organismes de standardisation pour

promouvoir la production de spécifications techniques pour les systèmes mobiles de 3ème génération (basés sur les techniques d’accès CDMA).

Le 3GPP a définit OSA comme une architecture donnant la possibilité aux opérateurs,fournisseurs de services et d’applications de tirer profit des fonctionnalités offertes par le réseau àtravers une interface ouverte et standardisée, qui est l’interface OSA.

Cette interface fait le lien entre les applications et les services qu’est capable d’offrir le réseau,et maintient l’indépendance des applications par rapport à la technologie réseau sous-jacente.

Du point de vue du développeur d’application, le but de l'architecture Open Service Access estde lui permettre d’utiliser un ensemble standardisé d'interfaces afin d'accéder à une même

fonctionnalité de réseau indépendamment des technologies de réseau sous-jacentes (réseautéléphonique, réseau IP ou autre). Cela rend les applications portables sur des réseaux différents.

Du point de vue des opérateurs de réseaux, OSA ouvre aux applications l’usage des capabilitésde réseaux, et ceci de manière extensible en permettant d’inclure des nouvelles fonctionnalitésréseau sans nécessairement devoir modifier les applications existantes.

Dans le modèle architectural OSA, cinq types d’entités clés sont à retenir. Il y a :

• Les applications

• Le serveur d’applications sur lequel résident les applications

• Le Gateway OSA

• Les Service Capability Servers SCS (les serveurs de fonctionnalité de service)• Les Service Capability Features SCF (les interfaces de fonctionnalité de service)

Le schéma suivant présente ces différentes entités

SUPCOM -15 -




Figure 2.1 : L’architecture OSA

L’architecture OSA est en réalité une architecture distribuée, dont le plus haut niveau estconstitué par les applications clientes, qui se trouvent dans les serveurs d’applications. LeGateway fait, lui, office de serveur situé à la frontière du domaine du fournisseur d’applications.

Entre les serveurs d’applications clients et le Gateway sur lequel tournent les SCS existe leréseau et la méthode de communication la plus couramment utilisée entre ces deux entités

distantes à travers ce réseau est le recours à un bus middleware CORBA. Nous expliquerons lescaractéristiques de chaque entité dans la partie suivante.

2.2.1- Les applications clientes

Les applications clientes résident sur des serveurs d’applications et accèdent aux SCSs àtravers l’interface OSA et les APIs Parlay du Gateway. Ces APIs servent de liens entre lesapplications et les SCSs. De cette manière, les applications sont rendues indépendantes de latechnologie du réseau sous-jacent.

2.2.2- Le serveur d’applications

Il est configuré de manière à se connecter au Gateway par l’intermédiaire d’une connexionTCP/IP (n’importe quel PC suffisamment puissant peut faire office de serveur d’applications,d’une simple machine Linux à un serveur avancé et spécialisé par un constructeur).

Le serveur d’applications peut avoir pour rôle également de cacher l’utilisation de CORBA auprogrammeur, en faisant appel à des « Convenience Classes », décrites dans un langage de hautniveau tel que Java.

SUPCOM -16 -




2.2.3- Les Services Capability Servers (SCS)

Les SCSs implémentent les spécifications Parlay sur l’interface OSA du Gateway, et se

chargent d’effectuer la translation de ces APIs vers les protocoles de télécommunicationsspécifiques présentes au plus bas niveau, cachant de cette manière la complexité du réseau aux

applications. Ils mettent aussi à disposition des applications clientes les fonctionnalités OSAappelées Service Capability Features (SCFs), ou plus simplement Services.

2.2.4- Les Service Capability Features (SCF)

Une SCF constitue l’abstraction d’un service particulier offert par le réseau et accessible autravers des APIs Parlay. Les SCFs sont spécifiées en tant qu’interfaces avec leurs méthodespropres. Un seul et même SCS peut être vu par les applications en tant qu’une ou plusieurs SCFs.

2.2.5- Le Gateway

Pour communiquer avec le monde extérieur et les différents éléments entrant en jeu, les

applications vont communiquer d’abord à travers une interface intermédiaire qui est le GatewayOSA.

Pour communiquer avec le monde extérieur et les différents éléments entrant en jeu, lesapplications vont communiquer d’abord à travers une interface intermédiaire qui est le GatewayOSA.

Le Gateway OSA consiste en plusieurs SCS, qui ne sont autres que des entités fonctionnellesqui fournissent l’implémentation des interfaces OSA/Parlay nécessaires à la communication avecl’application.

C’est donc l’élément central de l’architecture OSA, et c’est à travers cet équipement qu’unprovider devient en mesure de proposer une manière standardisée pour ouvrir son réseau et ses

fonctionnalités à des ASPs et développeurs tiers d’applications.

2.2.6- CORBA

CORBA est l’acronyme de Common Object Request Broker Architecture, et désigne uneinfrastructure permettant une communication répartie entre objets.

CORBA a été standardisé par un consortium appelé OMG (Object Management Group) en1989, et permet en soi de remplir les même fonctions d’appels de méthodes éloignées (RPC :Remote Procedure Calls) que le font d’autres mécanismes de communication distribuée etrépartie tels que DCOM (Microsoft) ou RMI (Java).

Le but de l’OMG a été de faire de CORBA une technologie d’objets distribués capable d’êtredéployée dans tout environnement, indépendamment de la plateforme, du langage et du protocoleutilisé.

Il s’agit donc d’une architecture ouverte et garantissant une grande interopérabilité entredifférents composants, permettant de répartir des objets entre les composants en communication,où l’objet représente en l’occurrence un regroupement de données et de traitements agissant surces mêmes données.

SUPCOM -17 -




Ainsi n’importe quel programme basé sur CORBA peut s’entendre avec n’importe quel autreprogramme aussi basé sur CORBA, même si ce dernier se situe sur une différente machineprovenant d’un équipementier différent, tournant sur un autre système d’exploitation et décrit parun autre langage de programmation sur un autre réseau.

2.3- Présentation de l’architecture OSA/Parlay

2.3.1- Présentation et objectif du groupe Parlay

Le groupe Parlay est un consortium à but non lucratif fondé en 1998 qui a été constitué à

l’origine (Parlay phase 1) par British Telecom, Microsoft, Nortel Networks, Siemens et Ulticom.Fin 2000, le groupe comprenait plus de quarante membres, et il compte aujourd’hui plus de 65compagnies, issues tant des télécoms que des industries de la technologie de l’information (IT).Parmi ces dernières on peut citer: Alcatel, Ericsson, Fujitsu, HP, IBM, Lucent, NTT, SunMicrosystems, Telcordia Technologies, Telecom Italia, Orange Communications.

C’est un forum ouvert qui s’est fixé comme objectif de définir des API d’applications et de lespromouvoir au sein d’organismes de standardisation comme l’ETSI, mais aussi auprès d’autresforums tels que JAIN, le 3GPP, l’OMG, le MSF (Multiservice Switching Forum) ou encore l’INForum.

2.3.2- UML

Afin de garantir une accessibilité à une communauté de développeurs aussi large que possible,les APIs ne ciblent pas une technique d’implémentation particulière.

Afin de garantir une accessibilité à une communauté de développeurs aussi large que possible,

les APIs ne ciblent pas une technique d’implémentation particulière.Il est important de bien concevoir que Parlay n’est pas un langage, mais une définitiond’interfaces et de méthodes regroupées au sein d’APIs d’application dont le but est de permettreun accès ouvert mais sécurisé à un ensemble de fonctionnalités (commande d’appel, gestion de lamobilité, interaction usager, messagerie, etc) aujourd’hui rendues par les différents réseauxpublics ou privés.

Pour exprimer ces définitions, Parlay utilise la notation UML (Unified Modeling Language),qui est un formalisme objet standardisé par l’OMG (comme CORBA et IDL) et destiné à lamodélisation d’un système, logiciel ou non, à plusieurs niveaux d’abstraction afin de leconstruire, le documenter et le maintenir. Ce type de description convient donc parfaitement auxinterfaces que Parlay s’efforce de modéliser, à travers une architecture distribuée OSA.

UML peut être utilisé avec la plupart des langages de programmation (orientés objet ou non),et la plupart des architectures techniques du commerce (CORBA …).

2.3.3- Structure des APIs Parlay

Parlay spécifie pour le domaine IT les capacités et fonctionnalités de téléphonie usuellementdisponibles dans un réseau Telecom traditionnel. En fonction du type de fonctionnalité dont il

SUPCOM -18 -




s’agit, celles-ci sont réparties en différents groupes, que l’on appelle communément ServiceCapability Features (SCF) ou plus simplement Services, et qui sont rendues disponibles à traversdes Service Capability Servers (SCS).

Figure 2.2 : Structure Parlay

Les SCFs (l’interface de fonctionnalité de service), offrant aux applications les fonctionnalitésdu réseau, sont standardisées. Les SCFs sont des interfaces CORBA, et leur ensemble formel’API OSA.

Les SCSs (les serveurs de fonctionnalité de service) jouent le rôle d’intermédiaire entreinvocations sur les SCFs et événements sur les éléments de réseaux.

L’APIs d’OSA est divisée en deux ensembles:

• Les SCFs de type Framework offrent le support à la gestion d’enregistrement desfonctionnalités réseau, l’abonnement des applications aux fonctionnalités réseau et lesmécanismes d’accès sécurisé aux applications.

• Les SCFs de type Service Réseau offrent à l’usage des fonctionnalités réseau.

Figure 2.3 : Les API d’OSA

Essentiellement, la séparation entre les deux interfaces peut être vue de la manière suivante :

• Les interfaces du Framework fournissent les outils nécessaires pour assurer que lesinterfaces de services soient accessibles de manière fiable, constante, sûre et gérable. Leframework possède son propre SCS.

SUPCOM -19 -




• Les interfaces de Services offrent aux applications l’accès à toute la panoplie desfonctionnalités du réseau. Les Services possèdent leurs propres SCSs.

Le Framework qui est l’un des SCS de l’interface Parlay/OSA est indispensable au bonfonctionnement des services et il gère principalement les fonctions suivantes:

•

Les fonctions d’authentification des applications pour accéder au réseau ;• Les fonctions d’autorisation pour les applications à utiliser certains SCF et données

clients, et, pour les clients, à utiliser une application (vérification d’inscription) ;

• Les fonctions de découverte des SCF, permettant aux applications d’obtenir desinformations sur les SCF accessibles ;

• La gestion d’établissement de services pour les applications qui doivent accepter «enligne » le contrat d’offre de services ;

• La gestion de l’intégrité des services : gestion de la qualité du service rendu.

• La gestion de l’enregistrement des SCF.

Les SCFs de type Service Réseau, qui nous concernent plus particulièrement sont lessuivantes:

• SCF d’interaction avec l’utilisateur: cette interface permet à une application de dialogueravec un utilisateur, à travers un modèle de communication très simple. L’applicationenvoie des messages vocaux à l’utilisateur. Ce dernier peut interagir par pression debouton sur son clavier téléphonique. Ce SCF est donc très utile, puisqu’il permet àl’utilisateur d’accéder au Virtual Home Environment à travers un réseau téléphonique.SCF des capabilités des terminaux et SCF de mobilité usager: Ces interfaces permettentà une application de collecter les capabilités du terminal de l’utilisateur et sa localisation.

Dans notre contexte de gestion de profil, les informations sur le terminal, y compris salocalisation, seront utilisées pour présélectionner les profils adaptés à la situation courantede l’usager.

Figure 2.4 : Les différents SCF de type réseau

2.3.4- Le Framework Parlay et la sécurité

La classe d’interfaces du Framework se distingue des autres interfaces, et contrairement auxinterfaces de Services, il est absolument nécessaire de l’implémenter.

SUPCOM -20 -




Le Framework contrôle l’accès aux différents services depuis le Gateway, en fournissant unensemble de fonctions indépendantes du réseau assurant des mécanismes d’authentification, degestion d’intégrité, de notification d’événements.

• L’authentification (Authentication) : elle est réalisée par encryptage des données et desalgorithmes de signature électronique.

• La gestion de l’intégrité (Integrity Management) : le Framework offre également desinterfaces de gestion de l’intégrité du système, dont des interfaces de gestion de la chargeet des erreurs, mais aussi un mécanisme de « battements de coeur » (heartbeatmechanism), qui consiste en un échange de signaux entre le Framework et une applicationou un SCS, pour s’assurer de la bonne santé de ce dernier.

• La notification d’événements (Event Notification) : cela autorise une application dedemander une notification lorsqu’un service ou une classe de services particulière selibère.

2.3.5- Les Services ParlayLes interfaces de services rendent visibles aux applications un ensemble de fonctions rendues

par les réseaux sous-jacents. Ces services comprennent :

• Generic Call Control Service: définit la manière dont les applications peuventpasser des appels à travers le réseau, comment elles peuvent démarrer une conférence

vocale, comment elles sont utilisées pour router des appels à partir du réseau, commentelles peuvent initier des appels multi-médias et détecter de nouveaux évènements.

• Common Data Definitions : définit les objets et types utilisés tout au long desspécifications Parlay.

• Mobility : définit la manière dont une application peut parvenir à localiser unterminal, et la manière dont elle peut requérir à une notification lorsqu’un terminal mobilechange de position.

• User Location : définit la manière dont une application peut obtenir desinformations sur la localisation d’un utilisateur en temps réel.

• User Status : définit la manière dont une application peut obtenir des informationssur l’état d’un utilisateur : occupé, injoignable, etc.

• Data Session Control : détermine la manière dont les applications gèrent leurssessions de d’échange de données initiées à partir d’un terminal.

• Generic Messaging : détermine la manière dont les applications interagissent avecdes systèmes de messagerie tels que voice mail, Fax ou email.

• Connectivity Management : détermine la manière dont les applications gèrent laqualité de service et la configuration de VPNs.

• Presence and Availability Management : détermine la manière dont lesapplications affichent la présence et la disponibilité d’un utilisateur à travers des messagestypes.

SUPCOM -21 -




• Policy Management : détermine la manière dont les applications interagissent avecd’autres réseaux possédant une politique particulière.

3- Conclusion

Au fil des versions toujours plus évoluées des APIs Parlay, d’autres interfaces publiques desupport administratif ont été greffées et mises à disposition de l’utilisateur directement, etd’autres fonctions encore ont été rajoutées pour permettre aux fournisseurs d’applications 3rdParty de participer plus simplement et plus activement.

Des définitions d’interfaces propres aux applications e-Commerce sont en cours destandardisation.

L’implémentation de toutes ces fonctionnalités n’est pas obligatoire, il n’est nécessaired’implémenter que celles que le réseau est à même de fournir, en fonction du type de servicesqu’il propose.

SUPCOM -22 -



Projet de Fin d’études 2004-2005 Le modèle Web Services

1- Introduction

2- Définition et description des Web services3- Les principales technologies de développement

Chapitre

3Le modèle

Web Services

SUPCOM -23 -




Introduction

Les Services Web représentent une nouvelle ère de la communication. Par leur indépendancevis-à-vis des langages et des plates formes, les Services Web ont créé un nouvel univers dans lacommunication entre les applications. Cet univers repose sur la définition de standards nouveaux

et universels.Nous allons dans ce chapitre essayer de répondre aux questions suivantes : Que sont les

Services Web ? Quels sont ses principes et ses fondamentaux ? Quels sont les avantages et leslimites de cette technologie?

Nous allons aussi voir dans ce chapitre les domaines d’utilisation des Services Web, et leurniveau de maturité.

1- Origines des services Web

Avec l'essor du web qui a eu dans les dernières années, il a surgi le besoin de permettre qu'une

application cliente invoque un service d'une application serveur en utilisant Internet. Ce besoin aété l'origine de ce qui se connaît comme services web.L’abstraction est une des plus importantes dimensions du développement de l’informatique.

L’abstraction concerne, pour une part, l’interaction entre applications. Cette relation porteplusieurs noms : interaction, interopérabilité, échange ; etc. Elle est aussi passée par plusieursmodèles, client - serveur, fournisseur – consommateur, mais toujours pour un même objectif :l’échange d’informations.

Les web services répondent à une double demande : celle d’un échange sûr et celle d’unéchange ouvert. L’échange ouvert est permis, puisqu’un serveur ne doit pas nécessairementconnaître à l’avance son client pour offrir son service vers l’extérieur.

Et donc en tenant en compte que les services web permettent de connecter des applicationsdifférentes, l'utilité de cette technologie devient évidente et importante.

2- Définition et description des Service Web

Le groupe de W3C qui travaille sur les services Web a utilisé dans un document appelé « WebServices Architecture » la définition de service Web suivante:

« A web service is a software system designed to support interoperable machine to machineinteraction over a network. It has an interface described in a machine processable format(specifically WSDL). Other systems interact with the web service in a manner prescribed by its

description using SOAP-messages, typically conveyed using HTTP with an XML serialization inconjunction with otherweb-related standards ».

Cela veut dire que les Services Web sont des services offerts via le web et qui sont associéprincipalement à deux spécifications : SOAP, protocole d’échange de messages XML permettantd’invoquer des opérations à distance ; et WSDL, langage de description des Services Web.

SUPCOM -24 -




Par exemple, un client demande le prix d’un article en envoyant un message sur le web. Cemessage contient la référence de l’article. Le Web Service va recevoir la référence, effectuer letraitement du service et renvoyer le prix au client via un autre message.

Figure 3.1 : Exemple de web services

Un Service Web est composé de trois parties : une interface, un nombre non limitéd’implémentations, et un protocole d’accès.

L’interface d’un Service Web est décrite en XML, elle est par conséquent indépendante dulangage de programmation. Elle décrit une liste d’opérations que l’utilisateur peut invoquer, etdonne les détails techniques de cette invocation (protocoles, URL d’accès, etc.). Une opération,qui peut être synchrone ou asynchrone, est constituée d’un échange de messages XML entre leService Web et son client. L’interface des Services Web est décrite dans un document WSDL :

Web Service Definition Language.Chaque Service Web a un nombre non limité d’implémentations. Il peut être développé en tout

langage de programmation : C++, Java, VB, etc. Le point d’entrée du service est son interface,nous n’accédons pas directement à son implémentation :

Figure 3.2 : Architectures d’un Web services

3- Les domaines d’utilisation des services Web

3.1- L’intégration d’applications

Les Web Service ont pour objectif de faciliter la mise en place des communications inter-applicatives. L’intégration d’application regroupe en fait 2 concepts : l’EAI (EnterpriseApplication Integration) et le B2B (Business To Business).

L’EAI a pour objectif d’uniformiser le système informatique interne d’une entreprise. Dansune entreprise ou l’EAI est mis en place, les applications (facturation, gestion des clients, gestion

SUPCOM -25 -




des fournisseurs) collaborent dans le but d’atteindre des objectifs de l’entreprise. Le but de l’EAIest de réduire les coûts des transactions en éliminant le plus grand nombre possible de sourcesd’erreur et en automatisant la majorité des tâches.

Le B2B a pour objectif de favoriser les échanges d’informations entre entreprises partenaires.Le B2B adresse autant les mécanismes de communication interapplicatifs (infrastructure

technique) que la sémantique des informations échangées (comment modéliser un bon decommande, une facture, etc.), les accords de collaboration, etc.

3.2- Les projets de portail

De part leur modularité, les Services Web peuvent aussi être utilisés dans le cadre de projetsde portail. En effet, un portail est composé de petites applications indépendantes offrant desfonctionnalités à l’utilisateur : une fenêtre donnant la météo, une autre l’horoscope, une autrepermettant de faire de la traduction de texte, etc. Chaque petite application a sa propre interfaceutilisateur, et accède aux applications de l’entreprise, qui effectuent tous les traitements

intelligents. Ces petites applications sont appelées des portlets, et certains éditeurs commencent àutiliser les Services Web pour connecter ces portlets à l’applicatif de l’entreprise.

Figure 3.3 : Exemple de projet Portail

4- Principales technologies de développement de Services Web

Une caractéristique qui a permis un grand succès de la technologie des services web est qu'elleest construite sur des technologies standard. Le schéma suivant est une représentationconceptuelle d’un service Web et qui montre les principales technologies sur lesquelles il se base.

SUPCOM -26 -




Figure 3.4 : Représentation conceptuelle d’un service Web

4.1- XML -eXtensible Markup Language

XML « eXtensible Markup Language » est un format texte simple, très flexible tiré du SGML(l'ISO 8879). A l'origine conçu pour la publication électronique à grande échelle, XML joue aussiun rôle de plus en plus important dans l'échange d'une large variété de données sur le Web et

ailleurs.W3C recommande depuis 1998 XML en tant que standard de description de données. XML

est un méta langage permettant d’identifier la structure d’un document. Un document estcomposé d’une définition de sa structure et d’un contenu. La structure d’un document XML estsouvent représentée graphiquement comme un arbre. La racine du document constitue le sujet dudocument, et les feuilles sont les éléments de ce sujet. De ce fait, XML est alors flexible etextensible et est devenu rapidement le standard d’échange de données sur le web.

4.2- Le protocole d’accès SOAP: Simple Object Access Protocol

4.2.1- Définition et description de SOAP

SOAP est une initiative de Microsoft et Developmentor, née en 1998. Les principaux éditeursdu marché ont participé à son développement et intègrent cette technologie à leur stratégie : IBMavec Websphere, Sun avec Sun ONE, BEA avec Weblogic, Microsoft avec .Net, etc. Le W3C afinalement participé à la définition de SOAP. On peut donc définir ce protocole comme unprotocole pour l’échange d’information dans un environnement répartie, basé sur le standard XML. Ce protocole consiste en trois parties : une enveloppe qui décrit le contenu du message et

SUPCOM -27 -




comment le traiter, un jeu de règles de codage à exprimer les cas de types de données défini parl’application et une convention pour représenter des appels de procédure éloignés ( RPC’s) et sesréponses.

Autrement dit SOAP est la spécification qui formalise le format des messages XML qui sontéchangés pour faire de l’invocation de services à distance c'est-à-dire comment représenter une

requête, une réponse, une erreur, etc.Ces messages sont transportés par un protocole standard (HTTP, HTTP Extension Framework

SMTP) ou tout autre mécanisme de transport (JMS, etc.).SOAP n’est pas lié à aucun système d’exploitation ni langage de programmation. Il est

indépendant du langage d’implémentation des applications client et serveur.

Figure 3.5 : Présentation du protocole SOAP

4.2.2- Processus d’échange de messages en SOAP

Les messages SOAP sont des transmissions fondamentalement à sens unique d'un expéditeur àun récepteur. Lorsqu’une transmission d’un message commence (e.g. invocation d’un service

web), un message SOAP (ou document XML) est génèré. Ce message est envoyé à partir d’uneentité appèle le SOAP sender, localisé dans un SOAP noeud. Le message est transmis à zéro ou àplusieurs noeuds intermédiaires (SOAP intermediates) et le processus fini lorsque le messagearrive au SOAP receiver . Le chemin suivi par un message SOAP est nommé message path. Lafigure suivante montre les éléments qui participent au processus.

Figure 3.6 : Processus d’échange de messages en SOAP

SUPCOM -28 -




Quand un message SOAP arrive dans une entité SOAP, il suivit le processus décris ci-dessous :

1. Identifier toutes les parties du message SOAP destiné à cette entité.2. Vérifiez que toutes les parties obligatoires identifiées dans le pas 1 sont soutenues par

l’entité et traitez-les en conséquence. Si ce n'est pas le cas rejeter le message.

3. Si l’entité n'est pas la destination suprême du message, elle enlève alors toutes les partiesidentifiées dans le pas 1 avant l'expédition du message.

Le traitement d'un message ou une partie d'un message exige que le processeur de SOAPcomprenne, parmi d'autres choses, le modèle d’échange utilisé (exp ; sens unique, multicast ), lerôle du destinataire dans ce modèle, l'emploi de mécanismes RPC, la représentation ou le codagede données, aussi bien que d'autres sémantiques nécessaires pour un traitement correct.

4.2.3- La spécification SOAP

La spécification SOAP est constituée de 4 parties. Les trois premières concernent le format

des messages : l’enveloppe SOAP, les règles d’encodage, et SOAP RPC. La quatrième partie de la spécification définit l’utilisation de SOAP avec des protocoles de

transport. Dans cette section, nous allons détailler ces 4 parties :

1- L’enveloppe SOAP

L’enveloppe SOAP définit le format des messages échangés. En fait, un message SOAP peutêtre considéré comme une enveloppe : nous y ajoutons les informations à traiter par ledestinataire (le message à transmettre), nous précisons l’adresse du destinataire dans l’entête del’enveloppe, nous envoyons l’enveloppe au destinataire, qui extrait les informations, effectue lestraitements adéquats et renvoie une réponse à l’expéditeur si nécessaire.

Figure 3.7 : L’enveloppe SOAP

L’enveloppe SOAP définit l’espace de nom (namespace : URI permettant de connaître laprovenance de chaque balise) précisant la version supportée de SOAP. Cet espace de nom eststandard et permet de différencier les éléments du schéma.

L’enveloppe SOAP est constituée d’un en-tête facultatif (SOAP header) et d’un corpsobligatoire (SOAP body).

SUPCOM -29 -




Figure 3.8 : Les éléments formant l’enveloppe SOAP

Entête SOAP L’entête contient les informations à traiter par les intermédiaires du message lors de sa

transmission au destinataire. Par exemple, nous pouvons y ajouter les informations concernant lecontexte au cours duquel le message a été envoyé : informations sur la transaction en cours,l’authentification de l’expéditeur, etc. Le contenu de l’entête n’est pas normalisé par SOAP : lesdeux parties qui s’échangent ce message doivent donc s’entendre sur un format commun.

Corps SOAP

Le corps SOAP contient l’information destinée au receveur. Il doit fournir le nom de laméthode invoquée par une requête, ou le nom de la méthode pour générer la réponse. Il doitaussi, fournir l’espace de nom correspondant au nom du service. Le contenu du corps SOAP estutilisé dans un processus comme le marshaling d’appels RPC et le rapport des erreurs.

Le corps SOAP peut contenir un SOAP fault. Ce bloc est utilisé pour transmettre l’informationdes erreurs durant le traitement du message.Malgré que l'en-tête et le corps sont définis comme des éléments indépendants, ils ont unerelation : une entrée de corps est sémantiquement équivalente à une entrée d'en-tête.

2- Les règles de codage

Les règles de codage fournissent un mécanisme permettant de coder en XML de manièrestandard les données échangées par les applications. Ces règles de codage se basent sur XML-Schema, recommandation du W3C pour définir des grammaires XML. Les règles de codageprécisent en particulier la façon d’encoder les types de base (string, int, etc.), les tableaux debytes et autres types de données en XML.

3- SOAP RPC

SOAP RPC est la partie la plus connue de la spécification. En effet, 80% des applicationsutilisant SOAP le font pour des appels de procédures à distance, car SOAP offre un mécanismesimple et portable à cette intention. SOAP RPC permet en particulier d’appeler les opérations des

Services Web.

4- Le transport des messages SOAP

La quatrième partie de la spécification SOAP définit comment transporter les messagesSOAP. Pour le moment, seul le transport avec le protocole HTTP a été défini. Mais il est possiblede transporter les messages SOAP avec d’autres protocoles tels que SMTP. Des exemples ontmême été mis en place par IBM pour transporter ces messages avec MQSeries ou JMS.

SUPCOM -30 -




La définition de l’utilisation de SOAP avec HTTP est très simple : les messages SOAP sontenvoyés dans une requête POST, et on ajoute un attribut à l’entête HTTP : SOAPAction, quiprécise le but de la requête SOAP (information destinée au filtrage des messages SOAP par lesfirewall). Donc il suffit d’encapsuler le message SOAP dans un message http.

4.3- WSDL : Web Services Description Language

WSDL est le fruit d’une collaboration entre IBM et Microsoft, ils avaient tous deux proposéleur propre langage de définition des Services Web : IBM avec NASSL – Network AccessibleService Specification Language – et Microsoft avec SCL – SOAP Contract Language. L’objectif de cette spécification est de formaliser la description des Services Web.

4.3.1- Définitions et description de WSDL

WSDL est un langage permettant de décrire les services Web et en particulier, les interfacesdes services web. Ces descriptions sont des documents XML.

Un document WSDL permet de définir tous les éléments d’un service :

• Les types de données utilisées.

• Les messages échangés.

• Les opérations fournies par le service.

• Les protocoles à utiliser pour appeler ces opérations.

• Les points d’accès du service : liste des URL.WSDL décrit un service web en deux étapes fondamentales : une abstraite et une concrète.

Dans chaque étape, la description utilise un nombre de constructions pour favoriser laréutilisation de la description et pour séparer les préoccupations de conception indépendantes.

Figure 3.9 : La spécification d’un service Web avec WSDL

Au niveau abstrait, WSDL décrit un service Web en termes des messages qu'il envoie etreçoit.

Au niveau concret, WSDL indique des détails de format de transport pour une ou plusieursinterfaces.

SUPCOM -31 -




4.3.2- Structure d’un document WSDL

Un document XML commence par la balise définition et contient les balises suivantes :

• types: cette balise décrit les types utilisés ;

• message: cette balise décrit la structure d’un message échangé ;

• portType: cette balise décrit un ensemble d’opérations (interface d’un service web) ;• operation: cette balise décrit une opération réalisée par le service web. Une opération

reçoit des messages et envois des messages ;

• binding: cette balise décrit le lien entre un protocole (http) et un portType ;

• service: cette balise décrit un service comme un ensemble de ports ;

• port: cette balise décrit un port au travers duquel il est possible d’accéder à un ensembled’opérations. Un port référence un Binding.

1- L’entête du document WSDL

L’élément racine du document WSDL s’appelle <definitions>. On y définit les espaces de

nommage utilisés dans la suite du document, xsd pour l’utilisation de XML-Schema et soap pourle binding SOAP.

<definitionsxmlns:xsd=”http://www.w3.org/2000/10/XMLSchema”xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”>

2- La définition des types de données utilisés

L’appel d’un Service Web s’effectue par échange de messages XML. Ces messagescomportent les paramètres d’invocation du service (ou de la réponse). Ces paramètres sont bienévidemment typés. Il est possible d’utiliser les types de données fournis par XML-Schema, ou de

définir ses propres types de données, dans l’élément <types>.

3- La définition des messages échangés

Chaque opération fonctionne par échange de messages XML. Pour les opérations synchronespar exemple, il y a un message d’entrée (la requête), et un message de sortie (la réponse). Ondéfinit les messages qui sont échangés dans des éléments <message>.

4- La définition des opérations

Une fois les messages modélisés, on peut définir les opérations qui prennent en paramètred’entrée/sortie ces messages.

A ce stade de la conception de notre document WSDL, on obtient une description complètedes opérations et de leurs paramètres d’entrée/sortie. On appelle cette partie la “définitionabstraite du service”.

Dans la suite du document, on associe ces opérations à un protocole, et une liste d’URL.

5- L’association à un protocole particulier

SUPCOM -32 -




Une fois les opérations définies, on les associe à un protocole, dans le cas générale SOAP pardessus HTTP. Cette association s’appelle un “binding”, et est par conséquent définie dans unélément <binding>.

Cette partie est la plus complexe du document WSDL. Elle est quasiment identique d’undocument WSDL à l’autre. L’objectif était de rendre WSDL extensible, et de pouvoir adapter les

descriptions aux différents cas (SOAP par dessus SMTP, HTTP, etc.).

6- L’association à une URL

La dernière étape est d’associer ce binding à une implémentation particulière, ce que l’on faitdans la balise <service>. Un service peut avoir plusieurs points d’accès. Chacun de ces différentspoints d’accès est défini dans un élément <port>.

Il suffit ensuite d’ajouter tous ces éléments bout à bout pour obtenir le document WSDL total.Ce document contient tous les éléments nécessaires à l’invocation du service avec SOAP.

4.4- UDDI: Universal Description Discovery and Integration

4.4.1- Définition et description d’UDDI

L’objectif primaire d'UDDI est de décrire et découvrir des services Web. Le noyau d’UDDItravaille avec la notion de "business registry", que est un service sophistiqué de noms etrépertoires. Plus précisément, UDDI définit des structures de données et APIs pour publier lesdescriptions des services dans le registre et pour interroger le registre afin de chercher desdescriptions publiées.

Les spécifications du « registry » UDDI ont deux buts principaux en ce qui concerne ladécouverte d'un service: le premier, soutenir les développeurs dans la découverte d'informationssur les services. Le deuxième, permettre la liaison dynamique et en conséquence habiliter lesclients pour interroger le registre et obtenir des références aux services d’intérêt.

Un registre UDDI contient 3 types d’information : Pages blanches : le référentiel comporte des informations sur les fournisseurs de

services. Pages Jaunes : le référentiel comporte des critères de catégorisation de services. Pages vertes : le référentiel comporte des informations techniques (WSDL).

4.4.2- Application de l’UDDI

Par exemple on veut chercher les services Web offert par une entreprise en utilisant son nomou son identificateur.

SUPCOM -33 -




Figure 3.10 : Fenêtre de recherche

Le résultat de la recherche :

Figure 3.11 : Résultat de la recherche

5- Cycle de vie d’un service Web

5.1- Cycle de vie d’utilisation

SUPCOM -34 -




L’exploitation un service Web, se fait à travers un ensemble d’étapes qui doivent être exécutédans l’ordre, le schéma suivant présente ce processus.

Figure 3.12 : Cycle de vie de l’utilisation

5.2- Cycle de vie complet

Le cycle de vie d’un service web se compose de 4 étapes qui doivent être exécuté dans

l’ordre :Etape 1 : Déploiement du service Web, Dépendant de la plate-forme (Apache : WSDD)

Etape 2 : Enregistrement du service Web, WSDL : description du service, Référentiels :DISCO (local), UDDI (global).

Etape 3 : Découverte du service Web.Etape 4 : Invocation du service Web par le clientLes schémas suivant vont présenter ces quatre étapes et les entités responsables de leur

réalisation.

SUPCOM -35 -




1-Déploiement

Figure 3.13 : Le Déploiement2- Enregistrement

Figure 3.14 : L’enregistrement

3- Découverte

Figure 3.15 : La découverte

SUPCOM -36 -




4- Invocation

Figure 3.16 : L’invocation

5.3- Exemple d’un Web services

Prenons l’exemple d’un processus “bon de commande”, comprenant deux acteurs : un client etun fournisseur. Ce processus utilise deux services : un service de gestion des commandes géré parle fournisseur et permettant de traiter les demandes de devis et les bons de commande, et unservice de validation des devis géré par le client et permettant de valider si le devis répond bienaux attentes du client. Le scénario est le suivant :

• Le client envoie une demande de devis au service de gestion des commandes(externe), qui lui envoie un devis en retour.

• Le client appelle le service (interne) de validation des devis, qui accepte ou non cedevis (contraintes de coûts, délais de livraison, etc.).

• En cas d’acceptation, le client envoie un bon de commande au service de gestion descommandes, qui lui transmet ensuite un acquittement.

SUPCOM -37 -




Figure 3.17 : Le déroulement des étapes

6- Gestion de la sécurité dans les services WebLorsque les données échangées sont sensibles, il est nécessaire de mettre en place des

mécanismes de sécurité. L’objectif est que des intrus ne puissent pas détourner des informationsprivées, que la provenance des messages reçus soit garantie, etc.

La sécurité pour la mise en place de communication inter-applicative regroupe en fait quatreconcepts :

• La confidentialité : un tiers, même s’il intercepte le message, ne doit pas être enmesure de comprendre les informations qui sont transportées.

• L’authentification : l’organisme qui envoie le message doit pouvoir être authentifié,

afin de garantir que le message n’a pas été envoyé par une tierce personne.• L’intégrité des messages : permet de garantir que le contenu du message n’a pas été

altéré pendant le transport.

• La non répudiation : par ce mécanisme, on s’assure que l’organisme qui a envoyé lemessage est bien celui qui l’a édité. L’expéditeur du message ne peut ainsi nier l’avoirenvoyé.

SUPCOM -38 -




Il est déjà possible de sécuriser en partie les échanges de données avec les Services Web auniveau du transport, en utilisant SSL (HTTPS), ce qui permet de garantir l’authentification et laconfidentialité par encryptage du message.

Toujours au niveau du transport, on peut utiliser un protocole d’IBM : HTTPR – HTTPReliable, qui définit une surcouche de HTTP garantissant la réception du message par le

destinataire et son intégrité.

7- Les points forts des services Web

7.1- Universalité

Les Services Web visent à résoudre un problème qui a fait couler beaucoup d’encre et favoriséla création de nombreuses initiatives : l’interopérabilité entre les applications disparates. Cesdernières années, les entreprises se sont en effet rendues compte que la principale source de coûtsdans le développement d’une nouvelle application est son intégration à l’existant. Les Services

Web sont l’approche la plus simple qui ait été proposée pour résoudre ce problème majeur.Par son mécanisme simpliste, transport de messages XML sur http, les Services Webréussissent là où d’autres initiatives beaucoup plus complexes, telles que Corba, ont échoué.

Un autre point fort des Services Web est que les spécifications sont poussées par les acteursforts du marché : IBM, Microsoft, Sun et Bea, ainsi que par un organisme de normalisation, leW3C. Ils sont déjà intégrés à de nombreux produits : Websphere, Weblogic, .Net, etc. C’estsûrement la première initiative qui met d’accord le monde Java et le monde Microsoft !

7.2- Simplicité d’utilisation

Un autre facteur de réussite des Services Web est leur simplicité et leur utilisation des

standards acceptés par tous : HTTP et XML. La mise en place d’une communication inter-applicative simple ne doit pas prendre plus de deux jours de développements en utilisant cettetechnologie !

7.3- Couplage lâche des applications : simplification des contraintes

d’urbanisation

Le troisième atout majeur des Services Web est la possibilité de coupler les applications demanière beaucoup plus souple qu’avec Corba, RMI ou DCOM. En effet, ces RPC permettent demettre en place des collaborations entre objets distants. Résultat, pour mettre en place une

collaboration entre applications, il est nécessaire de faire collaborer les objets qui les composent.

SUPCOM -39 -




Figure 3.18 : Appel des méthodes via un RPCOr ce mécanisme entraîne un couplage fort des applications qui collaborent. Il est souvent

nécessaire que la structure des données soit la même des deux côtés de la connexion. LesServices Web quand à eux introduisent la notion de « service » : une application offre desfonctionnalités à d’autres applications, et on n’a plus à se soucier de la structure interne del’application et des objets qui la composent. Les appels de méthodes au niveau objet sont laresponsabilité du service, une sorte de « Proxy » entre l’application cliente, et les objets del’application distante.

Figure 3.19 : Couplages des applications via le Web services

8- Le niveau de maturité des services Web

Les Services Web sont mûrs pour une utilisation en intra-entreprise. SOAP et WSDL serventde base à la communication inter-applicative. Peu de changements sont survenus entre la

spécification SOAP 1.1 et SOAP 1.2, proposée par le W3C. Les produits d’IBM, Microsoft,BEA et autres éditeurs intègrent déjà cette technologie (notons qu’une API cliente de SOAP estmême disponible en natif sous Windows XP).

Cependant, les Services Web ne sont pas encore mûrs pour une utilisation en extra-entreprise(B2B). En effet, les mécanismes de sécurité ne sont pas suffisamment développés pour garantir laprotection des données échangées avec l’extérieur. Il serait nécessaire de mettre en place desmécanismes propriétaires plus difficilement maintenables.

SUPCOM -40 -




Quel que soit le cas d’utilisation, il reste à définir des architectures solides basées sur cestechnologies. Pour les architectes, la vraie problématique sera de structurer les applications en «Services », les différents services ayant entre eux un couplage lâche. Les spécifications nedonnent pour le moment aucune indication sur ces contraintes d’architecture.

SUPCOM -41 -



Projet de Fin d’études 2004-2005 Comparaison OSA-Web Services

1- Introduction

2- Comparaison entre les deux architectures OSA et Web services

3- Couplage des deux modèles

Chapitre

4Comparaison entre les

deux modèles : OSA et

Web Services

SUPCOM -42 -




Introduction

Les deux modèles OSA et Web services, ont un même objectif : permettre un accèspersonnalisé aux services multimédia adaptés au terminal utilisé. Cependant, ces deuxarchitectures de services NGN différent dans leur architecture.

Dans ce chapitre, nous effectuerons une comparaison entre les deux architectures décritesdans les chapitres précédents. Il est important de voir les points communs et les points dedifférences entre les terminologies adoptées dans les deux contextes.

Parlay Environment Web Service Environment

Service Interface Web Service

Service Object Service

Application Service Requestor (Application)

Service Supplier Service Provider

En outre, les propriétés de service du Parlay et le service de description des services Web sontdes concepts semblables.

1- Comparaison des fonctions présentes dans chaque architecture

Le tableau suivant décrit les fonctions principales dans les deux architectures et identifie lesentités qui les fournissent.

Fonction Parlay/OSA Web services

Service d’enregistrement Framework Publier « publish »

Recherche d’un service Framework Recherche « find »

Négociation Framework Pas défini

Publication Publication directe Service de description

Invocation Framework Service de définition d’interface

Authentification Framework Pas défini

Autorisation Framework Pas défini

Du tableau suivant nous pouvons remarquer:

• Dans Parlay/OSA, le Framework fournit un seul point d'entrée et le support O&M estpartagé par les Services; dans Web Services, ces fonctions sont implémentées danschaque service.

• Parlay/OSA supporte seulement une directe publication de l'interface du service.

• Dans Parlay/OSA, le Framework est responsable de la correction provisionnelle duService aux applications. De plus, le Framework a des obligations vers le Service pourassurer l'accès correct au Services demandé par l'application.

SUPCOM -43 -




• Dans Web Services, Web Service Registry n'a aucune obligation vis à vis au Web ServiceProvider et Web Service Requestors.

• Dans Parlay/OSA, une application doit contacter le Framework pour avoir la référenced'un Service. Cette référence est valide seulement pour la durée d'une session, et

seulement pour les applications bien appropriées qui peuvent apporter une référence d'unService.

• Dans Web Services, accédez au Web Service Registry est facultatif.

2- Comparaison des interfaces définies dans chaque architecture

Pour comparer les interfaces Parlay/OSA et Web Services, nous pouvons analyser lesinteractions entre Applications/Services et ressources du réseau. En particulier c'est important deconsidérer :

• Les différentes méthodes pour activer un service ;

• Les types d'interactions entre les capacités du réseau et les applications.

2.1- Parlay/OSA

Les méthodes possibles pour activer l'exécution d'un service incluent :1. l'utilisateur, à travers les protocoles de réseau (par exemple DTMF, SIP, etc.), crée une

demande. Le réseau trait la demande et le contrôle du service passe à une application quiexécute le service et ordonne les ressources du réseau pour exécuter la demande del'utilisateur.

2. un événement survenu dans le réseau (par exemple changement d'emplacement del'utilisateur, arrivée d'un message, etc.) produit une notification à l'application qui exécute

le service qui utilise quelques ressources du réseau ou produire le contenu pourl'utilisateur.

3. l'utilisateur, à travers les protocoles Internet (par exemple HTTP, WAP, RMI), invoque unservice (par exemple un service Internet). Pendant son exécution le service peut faire desdemandes réseau (par exemple, détecter l'emplacement de l'utilisateur).

SUPCOM -44 -




Figure 4.1 : Les différentes actions d’un service selon l’architecture Parlay/OSA

La capacité du réseau est déterminée par les événements asynchrones provenant du réseau. Parconséquent, un service qui doit avoir le maximum de contrôle du réseau doit avoir le contrôle dela plupart de ses événements et changements d'état. Une manière de satisfaire ce besoin estd'organiser les interactions entre les services et le réseau dans les transactions. Une transaction estemployée pour créer un contexte pour corréler et traiter les interactions liées à la même sessionde service : une transaction pourrait consister en une commande initiale ou événement avecplusieurs réponses. En outre, la réception de quelques réponses pourrait dépendre des "réactionshumaines" (par exemple répondre/ne pas répondre à un appel), avec des intervalles de tempsimprévisibles entre la demande et les messages de réponse.

Les services offerts par Parlay/OSA sont définis en considérant la définition des protocoles detélécommunication. Bien qu'une des conditions des services de Parlay/OSA soit l'abstraction desmécanismes implémentés dans le réseau (par exemple, des protocoles ou des ressourcesspécifiques du réseau), les services de Parlay/OSA permettent un contrôle de la capacité duréseau en détectant la plupart des événements.

Par conséquent, les services de Parlay/OSA sont définis en tenant compte de l'importance detraiter les événements du réseau lancés par des applications asynchrones.

En outre, les interfaces de service de Parlay/OSA sont définies selon une approchetransactionnelle :

•

L'échange des messages et de leur traitement est (par exemple, les requêtes/événementsd'un appel sont manipulés par des exemples spécifiques de l'interface fournie parl'objet de service et par l'application).

• Le traitement d'une demande a pu produire un ou plusieurs messages de réponse,probablement fournis d'une manière asynchrone.

SUPCOM -45 -




Selon leurs caractéristiques, les services de Parlay/OSA définissent des composants deservice orientés aux réalisateurs avec la connaissance du comportement "abstrait" des capacitésdu réseau et cela peut exploiter le contrôle totale des capacités du réseau.

2.2- Web services

Les services Web sont souvent employés dans un modèle d'interaction requête/réponse.L'information dans le message est orientée service et non pas ressource. Par conséquent, dansbeaucoup de cas les demandes de service sont résolues dans une simple interaction, sans utiliserdes réponses intermédiaires ou des messages multiples corrélés dans une transaction simple. Enoutre, dans ce modèle d'interaction, les interactions sont lancées par une application envoyant unedemande à un service.

À ce moment, les caractéristiques des services Web incluent des conditions pour préciser lemodèle d'interaction, mais les spécifications pour mettre en application des conditions ne sont pasencore indiquées. Les mécanismes pour supporter des conditions peuvent être définis dans le

contexte des protocoles, tels que SOAP, et ce mécanisme a été défini pour WSDL/SOAP dans lecontexte des interfaces des services web.

Selon leurs caractéristiques, le modèle d'interaction requête/réponse fournit un modèlesimple d'interaction qui a une communauté large de réalisateurs. Cependant, il ne fournit pas lecontrôle et la scalabilité des modèles asynchrones d'interaction. Ce modèle est bien convenu auxservices visés, aux outils de développement de niveau élevé ou aux développeurs non-telecom,tels que les fournisseurs des services Web, avec moins d'interactions entre l'application et leservice.

Figure 4.2 : Les différentes interactions dans le modèle Web services

3- Degré de dépendance de chaque modèle vis-à-vis du réseau

Le modèle OSA est orienté softswitch, qui, est le nœud central de la couche contrôle, et lepassage obligatoire pour accéder aux services, via l’interface OSA.

SUPCOM -46 -




Et donc le modèle OSA semble plutôt adapté aux services fortement dépendants desfonctions de la couche Contrôle du réseau (exemple : demande d’information sur la localisation,ou sur les caractéristiques du terminal, etc.).

Alors que le modèle Web Services, préconisé par le W3C, est, comme son nom l’indique,basé sur des technologies « Web » dont l’architecture est distribuée. L’initiation des sessions est

prise en charge par le protocole SIP (Session Initiation Protocol). La couche d’adaptation,nécessaire pour l’accès aux services, est prise en charge par un ensemble de protocole Web, telsque XML, SOAP, WSDL et UDDI.

Et donc, le modèle web services est plutôt adapté aux services relativement transparents auréseau (exp : communication « universelle » entre terminal et serveur, ou entre terminaux, ouentre serveurs, une fois la connexion réseau établie entre les deux entités). Il s’appuie sur desconcepts déjà anciens d’informatique distribuée. Son introduction influe essentiellement lacouche services et dans une moindre mesure les terminaux, mais peu le réseau.

C’est ce qui explique qu’il est déjà mis en œuvre dans le domaine Internet, et pourra

aisément être élargi aux autres domaines. Contrairement au modèle OSA qui sera plus long etdifficile à mettre en œuvre du fait de sa forte dépendance du réseau. Il devrait avoir vocation à sedévelopper avec l’essor des réseaux et services UMTS.

A priori, ces deux modèles ne sont pas concurrents mais complémentaires. On peut en effet

imaginer des applications mixtes basées sur le modèle Web services mais faisant appel pourcertains services à des requêtes de type OSA.

4- UDDI vs Framework

Le modèle de services Web est censé être une sorte d’espace global où plusieurs

(probablement des milliers) de différents fournisseurs de services enregistrent et fournissent leursservices. À cet égard UDDI agit principalement comme un annuaire global, c’est à dire :

• UDDI stocke des données appartenant aux différents fournisseurs.

• UDDI est une entité indépendante.D'autre part, le modèle Parlay/OSA s'occupe du rapport entre un opérateur et un certain

nombre de tiers parties. Le Framework agit en tant qu’un point d'accès pour différents services,mais tous appartiennent au même "fournisseur" (l'opérateur). Ce modèle implique ce qui suit :

• Le Framework stocke des données appartenant à un seul fournisseur.

• Le Framework appartient au fournisseur ce qui explique également le fait que le

Framework dépend beaucoup des SCSs qu'il soutient. En conséquence, dans la plupartdes cas l'opérateur est forcé de maintenir les SCSs dans le même domaine duFramework.

5- Comment peuvent-ils converger ?

La comparaison met l'accent sur le fait que la solution de Parlay fournit une solution uniformepour s'ouvrir aux tiers partie d'une manière sécurisé et bien contrôlé. En particulier, le Framework

SUPCOM -47 -




joue un rôle central en mettant en application des fonctions de sécurité et de gestion, cesfonctions sont partagées par différentes interfaces de service.

D'autre part le modèle de Parlay apparaît beaucoup plus complexe que les Web services, quireflètent également les différences entre les modèles rigides des télécommunications et lesmodèles flexibles d'Internet.

Dans ce paragraphe, nous allons montrer qu’il est possible de combiner les deux modèles :OSA et Web services pour avoir des scénarios possibles de convergence.

Le schéma suivant illustre la solution proposée par le groupe Parlay X, cette solution estl’architecture de base qui va donner naissance à plusieurs configurations possibles.

Figure 4.3 : L’architecture proposée par le groupe Parlay X

Dans la suite, nous allons présenter un scénario possible de convergence qui vise àl'introduction des fonctions du Framework définit par le groupe Parlay dans le modèle Webservices.

SUPCOM -48 -




Le principe est le suivant : l’application utilisera Web services pour la découverte etl’interaction avec le réseau et elle ne va pas voir l’implémentation du Gateway OSA. Lesinformations publiées dans le registre du Web services vont donner à l’application lesinformations nécessaires pour la connexion avec le Gateway Web services. Ce dernier est attachéau Gateway OSA via une interface OSA. Afin d'accéder à une ou plusieurs ressources du réseau

fourni par un opérateur, l'application doit agir avec le Framework, via les interfaces des servicesweb. Les interfaces permettant d'accéder au Framework et les ressources du réseau doivent êtreprésentées dans une version simplifiée par le groupe de travail Parlay.

Cette solution laissera le même modèle et la même solution architecturale définis par Parlaydans un contexte de Web Services.

Figure 4.4 : Scénario du convergence « Du Web services à OSA »

6- Conclusion

On peut conclure que ces deux modèles ne sont pas concurrents mais complémentaires.Puisque plusieurs applications mixtes basées sur le modèle Web services mais faisant appel pourcertains services à des requêtes de type OSA.

Suite à cette comparaison entre les deux modèles de création de services OSA et Webservices, et grâce aux nombreux avantages du web services par apport au modèle OSA et de latendance des chercheurs a opté vers l’utilisation du modèle Web Services. Nous allons choisir cemodèle pour la création du prototype de création de services.

SUPCOM -49 -



Projet de Fin d’études 2004-2005 Prototype

1- Présentation de l’environnement et de l’outil de travail

2- Développement des différentes étapes du prototype

3- Analyse des Résultats

Chapitre

5Développement d’un

prototype pour la création

de nouveaux services

SUPCOM -50 -




1- Les différentes plates formes existantes

Malgré qu’un web services se définisse d’une façon unique comme étant un composantprogrammé dans n'importe quel langage et permettant aux deux plates-formes distantes (le posted'un utilisateur ou un serveur) de dialoguer ensemble, plusieurs plates formes existent dans ce

domaine.Chaque acteur propose une solution différente, mais toutes ces implémentations sont inter

opérables, c'est-à-dire que les services des uns sont utilisables par les autres. Parmi les leaders dece domaine nous pouvons citer le groupe Microsoft avec sa solution .Net et J2EE qui regroupeles organisations suivantes : Sun, IBM, etc.

1.1- Présentation de la plate-forme J2EE

Java 2 Entreprise Edition (J2EE) offre une solution complète de développement d'applicationsInternet. Cette spécification intègre des API qui sont responsables de la partie chargée del'interface avec l'utilisateur. La plateforme J2EE est essentiellement un environnement

fournissant une infrastructure d'exécution pour faire tourner nos applications. Un des avantagesmajeurs de J2EE est qu’il fait abstraction de l'infrastructure d'exécution. En effet, J2EE spécifieles rôles et les interfaces pour les applications, ainsi que l'environnement d'exécution dans lequelles applications sont déployées. Ceci permet aux développeurs d'application de ne pas avoir àreprogrammer les services d'infrastructure.

1.2- Présentation de la plate-forme .NET de Microsoft

.Net fut présenté par Bill Gates en Juillet 2000 lors du Congrès des développeursprofessionnels, La première version .NET a été rendue publique le 15 janvier 2002. Elle a été

définit par Microsoft comme étant " une plate-forme pour la nouvelle génération des webservices. Elle vise à simplifier la vie de l'utilisateur en lui fournissant des services intégrés,accessibles depuis tous ses périphériques, à tout moment et en tout lieu. La plate-forme .NET estun moyen simple de normaliser la coopération des services logiciels entre eux (services Web),quelle que soit leur localisation, leur implémentation technique, qu'ils soient internes ou externes,existants ou à inventer. " En ce sens, .NET représente l'adaptation de Microsoft de ce que nousappelons web services.

2- Pourquoi la plate-forme .NET pour développer notre prototype

Même si les responsables informatiques demeurent encore prudents à l'égard de .NET, lanouvelle plate-forme de développement de Microsoft dispose d'atouts pour s'imposer. Elle a étéconçue précisément pour répondre aux problèmes d´intégration. Microsoft, mise sur les WebServices, ensemble de spécifications et mécanismes qui formatent les données selon une normeafin de les rendre compréhensibles par d´autres applications. .NET est une plate-forme fondéetotalement sur des standards. Par exemple, les données sont transmises entre les processus auformat XML. Elle intègre aussi le protocole SOAP et grâce à cette intégration, n'importe quel

SUPCOM -51 -




client peut accéder facilement au service qu’il demande et cela indépendamment du systèmed'exploitation. Suite à cette présentation des nombreux avantages offerts par cet environnementde travail nous avons choisi la plate-forme .NET pour développer, exécuter et tester notre serviceweb.

3- Pourquoi le langage de programmation JavaJava possède un certain nombre de caractéristiques qui ont largement contribué à son énorme

succès parmi ces caractéristiques nous pouvons citer qu’il est indépendant de toute plate-forme, ilest orienté objet, c'est-à-dire chaque fichier source contient la définition d'une ou plusieurs classesqui sont utilisées les unes avec les autres pour former une application. Il est sûr puisque lasécurité est une partie intégrante du système d'exécution et du compilateur. Java est aussi lelangage le plus recommandé pour créer des web services puisque il permet de générer desservlets, ces dernières sont des classes capables de s’exécuter en mode requête réponse. Cesservlets vont jouer un rôle très important dans le développement de notre prototype.

4- Notre objectif

Nous devons créer un prototype pour le développement des web services, pour le faire, nousdevons définir toutes les étapes nécessaires et les exécuter dans l’ordre. Nous commençons parcréer un simple web service, sur le quel nous allons appliquer notre prototype. Le test du

prototype s’effectuera en utilisant la plate-forme .NET, Nous terminons par analyser les résultatsde l’exécution qui vont être générés automatiquement par cet outil.

5- Modèle de programmation de notre Web service

Notre modèle de programmation comporte deux parties fondamentales :• Création d'un service Web : Lorsque nous développons notre service Web, nous créons

entre autre une application qui expose les fonctionnalités de ce service aux clients quivont l’utiliser.

• Accès à un service Web : Lorsque nous voulons accéder à ce service, notre applicationcliente doit rechercher les fonctionnalités contenues dans ce service Web, y faireréférence et l’utiliser. Le client de notre service Web est une application basée sur sue leprotocole UDDI, puisque ce dernier va jouer le rôle d’un navigateur.

6- Les étapes de création du prototype

Pour créer un prototype d’un web services, nous devons se baser sur le cycle d’utilisation dece service. Un client demandant un service, va commencer par lancer une recherche dans unebase de données appelé UDDI, le service doit être bien défini dans cette base, nous devons aussifaire une description de l’entité offrant ce service ainsi que des spécifications concernant lestechniques utilisées. La recherche va générer un résultat si et seulement si le service existequelque part dans un serveur web, une fois nous avons trouvé le serveur hébergeant ce service, le

SUPCOM -52 -




client et le serveur vont se mettre d’accord sur un format d’appel grâce à un contrat appeléWSDL, ce contrat va être générer par le serveur hébergeant le service et donc ce dernier doit bienconnaître les droits d’accès que peut avoir un client, nous pouvons donc conclure qu’il fautajouter à la définition du service, la définition du client qui va exploiter ce service. Nousremarquons que grâce au cycle d’exploitation du web service (appelé encore cycle d’utilisation)

nous pouvons dégager le cycle de développement appelé encore prototype d’un web service. Leschéma suivant illustre les différentes étapes de notre prototype.

Figure 5.1 : les étapes de création du prototype

Une fois que ce prototype a été bien définit, il peut être appliqué à n’importe quel service.Dans notre application, nous définissons un simple service, auquel nous allons appliquer notreprototype.

6.1- Etape 1 : Définition et implémentation de la classe de service

D'abord, nous commençons par créer une simple interface permettant l’accès au prototype.Cette interface permet aussi à l’utilisateur d’avoir des informations sur les différentes étapes du

prototype. Ensuite, nous devons écrire ¶un programme en Java qui va mettre en application notreservice. Ce programme est constitué d’une simple classe nommé ConvertTemperature. Cetteclasse est un processus qui convertit les températures mesurées en degrés Fahrenheit en degrésCelsius. Avant la déclaration de cette classe ConvertTemperature, nous devons ajouter deuximportants attributs pour rendre notre classe conforme aux applications Web. Si nous attachonsl'attribut Web Service à notre classe Public, nous pouvons inclure des informations

SUPCOM -53 -




supplémentaires pour notre web service, et si nous attachons l’attribut Web Method, notre classeva être exposée comme une partie du web service.

[WebMethod (Description="cette méthode convert la température en degrés Fahrenheit en unetempérature en degrés Celsius.)]<@ WebService Language="java" Codebehind="Service .asmx.cs" Class = "TempConvert.Service" %>

L'attribut WebMethod doit s'appliquer à chaque méthode publique qui est disponible commepartie du service Web. Et la directive @ WebService sert comme une déclaration de notre serviceet met en corrélation l'adresse URL du service Web et son implémentation, afin que l’applicationpuisse traiter les demandes de service Web XML et de renvoyer les réponses. Si la compilationne génère pas d’erreurs, une nouvelle interface s’ouvre pour tester le bon fonctionnement del’application.

Figure 5.2 : Test de l’application

En arrière plan, le test de l’application ce passe comme suit : dans le navigateur s’affiche cetteadresse « http : \\ localhost : 8080\web service1 » ensuite la température en d°Fahrenheit prend la

SUPCOM -54 -




valeur 212, normalement le résultat de la température en d°Celsius sera affiché. Aprèsl’exécution, Le service répond en retournant la valeur convertie de la température dans ledocument XML suivant :

<?xml version="1.0"?>

<double xmlns="http://Walkthrough/XmlWebServices 1/">100</double>

Nous pouvons constater que notre service marche bien au niveau local et nous devonsmaintenant le mettre à la disposition de tout le monde.

6.2- Etape 2 : Déploiement et description de la classe Java à un serveur SOAP

Pour mettre notre application Web à la disposition d'autres utilisateurs, nous devons ladéployer sur un serveur Web accessible aux clients que nous souhaitons prendre en charge.Après le développement de notre classe Java nous avons besoin de transformer cette classe C’est-à-dire nous allons associer ce service à un serveur web. Pour déployer le service Web sur un autreserveur que le serveur de développement, nous devons effectuer deux étapes : ajouter un projet deconfiguration Web qui va copier le service du serveur de développement au serveur dedéploiement et définir un fichier appelé descripteur de déploiement de service web, ce fichierporte l’extension « wsdd » pour Web Service Deployment Descriptor.

L’outil .NET nous permet de créer un serveur SOAP et d’implémenter la classe javadéfinissant notre service à ce serveur. A la fin de cette étape, ce serveur va héberger notre service,

exécuter les requêtes du client et envoyer les réponses.Dans ce qui suit nous allons présenter les étapes nécessaires pour effectuer le déploiement. Compilation de la classe de service

Nous devons compiler la classe java du service que nous avons définit, à l’issu de cettecompilation, nous devons avoir dans notre dossier de travail un nouveau fichier « service1.class»

Définition de descripteur de déploiement

La description de service décrit les services disponibles ainsi que les méthodes d'interactionavec ces services. Sans description de service, il est impossible d'interagir par programme avecun service Web. Le descripteur de déploiement doit être placé dans le même dossier que le« .class » définissant le service, nous appelons ce descripteur « deploy.wsdd » son contenu vaavoir la forme suivante :

<deployment Xmlns= http://XML .net/WsddXmlns: java= http://Xml .net/Wsdd/providers/java

>

< service name = web service 1 style = RPC ><parameter name = class Name value ConvetTemperature /><parameter name = allowed Methods value * /></service ></deployment >

SUPCOM -55 -

http://xml/

http://xml/

http://xml/

http://xml/




Explications de ces différents éléments

Balise de début avec

<deployment Xmlns= http://XML .net/Wsdd attributs les espaces

Xmlns: java= http://Xml .net/Wsdd/providers/java

> de nom des balises

mise en œuvre dans le

descripteur

Le nom d’invocation du service

< service name = web service 1 style = RPC > avec le mode RPC (ce sera le

seul mode que nous mettons en

œuvre

la classe compilée

<parameter name = class Name value ConvetTemperature /> associée au service

<parameter name = allowed Methods value * /> autorisation d’accès auservice

</service > fin de la balise service

</deployment > fin de la balise deployment

Activation du déploiement

Le descripteur de déploiement doit être maintenant pris en compte par le serveur pour réaliserle déploiement du service. La ligne de commande est :

Java org . asp.net . adminclient deploy . Wsdd

Installation du service

Nous avons, lors de l’étape précédente, demandé au serveur d’être en mesure de traiter toutesles requêtes « SOAP » correspondant à notre service, cela signifie donc qu’à la réception d’une

SUPCOM -56 -

http://xml/

http://xml/

http://xml/

http://xml/




requête « HTTP-SOAP », le serveur pourra appliquer la méthode spécifiée dans la requête à uneinstance de la classe correspondante à notre service.

Cependant, pour que le serveur soit en mesure d’utiliser la classe de notre service, il doit êtreen mesure d’accéder à l’URL suivante :

http://localhost:8080\webapp\asp.net\service1\converttemperature

Le nom « convert temperature » correspond au nom du service que nous avons indiqué dans ledescripteur de déploiement.

Nous pouvons alors constater que notre service a été bien déployé sur le serveur, en ayant enretour la page HTML suivante :

Bonjour, cette page présente un aspnet web service

Cliquer sue le lien pour invoquer le service

Exécution du serviceLa dernière étape du déploiement consiste à mettre en œuvre notre service, pour l’exécuter et

obtenir la réponse SOAP correspondante, nous devons invoquer le service.L’invocation doit être réalisée de la façon suivante :http:// localhost : 8080/ asp.net/service? Methode=convert temperature&d°Fahrenheit = 40

Nous obtenons la réponse suivante toujours sous format SOAP XML :<soapenv: Envelope Xmlns: Soapenv = http://schemas.XmlSoap.org/ Soap/envelope/

Xmlns:xsd = http://www.w3.org/XMLSchema Xmlns: xsi = http://www.w3.org/XMLSchema-instance

>

< Soapenv: Body><ConvertTemperature Response

Soapenv:encoding style = http://schemas.xmlSoap.org/soap/encoding/ >

<ConvertTemeratureReturn xsi:type = xsd :int

>4.5</ConvertTemperatureReturn></ConvertTemperature Response ></ Soapenv: Body></soapenv: Envelope >

Toutes ces étapes se passent en arrière plan, pour l’utilisateur, une simple interface s’affiche etcache la complexité de ces étapes.

SUPCOM -57 -

http://localhost:8080/webapp/asp.net/service1/converttemperature

http://www.w3.org/XMLSchema

http://www.w3.org/XMLSchema-instance

http://schemas.xmlsoap.org/soap/encoding/



http://www.w3.org/XMLSchema-instance

http://www.w3.org/XMLSchema

http://localhost:8080/webapp/asp.net/service1/converttemperature






Figure 5.3 : Déploiement du service

Ces étapes doivent s’exécuter dans l’ordre : compilation de la classe du service, définition du

descripteur, activation de déploiement, installation du service et l’invocation du service.

Suite à la compilation, nous pouvons avoir soit un message d’erreur si un problème est

survenu lors de l’exécution de l’opération, soit un message précisant le succès de l’opération.

Figure 5.4 : Message d’erreur

Figure 5.5 : Résultat

SUPCOM -58 -




En tapant sur le bouton « définir le descripteur », une nouvelle interface s’ouvre précisant les

différentes informations concernant le service et que nous devons remplir.

Figure 5.6 : Définition du descripteur

Suite à l’activation du déploiement, le résultat peut être soit un message d’erreur si unproblème est survenu lors de l’exécution de l’opération, soit un message précisant le succès del’opération. Suite à l’installation du service, la page HTML de notre service s’ouvre. Enfin,l’invocation du service donne naissance à une nouvelle interface qui va générer le résultat denotre service.

Figure 5.7 : L’invocation du service

Le déploiement du service est l’étape la plus importante dans le cycle de développement d’unweb service, à la fin de cette étape, notre service est crée et il ne reste que sa publication pourfaciliter l’accès.

6.3- Etape 3 : La publication du web service

La publication du service est l’enregistrement des informations de ce service dans un registrenommé UDDI. L’UDDI fournit un mécanisme pour annoncer et découvrir des Web services. Il

SUPCOM -59 -




contient des informations sur des entreprises et les services qu'ils offrent. Les caractéristiquestechniques sont habituellement définies en utilisant WSDL. Ce dernier décrit ce qu'un Webservice fait, et comment il communique, et où il est localisé. Les informations d’un serviceconcernent :

Le fournisseur du service : son nom, une petite présentation, comment le contacter, etc ; Le service : son nom, type du service, quelques informations sur les technologies

utilisées, etc ; Binding Templates : lié à chaque service, représente une liste qui fournisse des

informations sur où trouver le service et comment l’employer. Un Binding Templatespeut contenir aussi le point d'accès pour accéder au service et un indicateur sur la façon del’employer.

Pour effectuer donc cette publication et avant d’ajouter les informations propres de notreservice, nous devons ajouter des informations sur le registre qui va contenir les détails du service.L’interface suivante permet à l’utilisateur d’ajouter les informations appropriées pour le service

et le registre.

Figure 5.8 : La publication du service dans le registre UDDI

Si nous cliquant sur le bouton « détails du registre », une nouvelle interface s’affiche,l’utilisateur doit remplir les champs contenant le nom du registre, son adresse et un mot de passepermettant par la suite à l’utilisateur d’ajouter des informations dans ce registre ou de modifierson contenu.

SUPCOM -60 -




Figure 5.9 : L’accès au registre UDDI

Nous passons par la suite à la publication de notre service en cliquant sur le bouton« publier », une nouvelle interface s’affiche :

Figure 5.10 : La publication du registre

Une fois que ce tableau a été rempli et que la publication est achevée avec succès, unconsommateur de Web service peut avoir accès à des informations sur notre service, il suffitqu’il questionne l'enregistrement d'UDDI pour trouver les descriptions WSDL et pour déterminercomment employer le Web service. Arrivant à ce stade, nous devons vérifier si le service a étébien publié dans le registre UDDI, il suffit de tester la réponse du registre UDDI. Nous pouvonsavoir deux résultats, soit un message précisant que le service n’est pas trouvé, soit un messagedonnant des informations sur le service.

SUPCOM -61 -




Figure 5.11 : Message d’erreur

Si la recherche génère un résultat cela veut dire que notre web service a été publiécorrectement dans le registre UDDI, sinon la publication a rencontré des problèmes au cours deson exécution et il faut réenregistrer notre service.

6.4- Etape 4 : La découverte du service

La découverte de service Web XML est le processus utilisé par un client pour rechercher unservice Web et obtenir sa description, c’est à dire le processus qui consiste à localiser etdécouvrir, un ou plusieurs documents connexes décrivant un service Web particulier à l'aide dulangage WDSL (Web Services Description Language). C'est grâce à ce processus que les clientsd'un service Web XML apprennent que ce service existe et où trouver son document dedescription.

À ce stade nous avons effectué l’enregistrement de notre Web service dans UDDI. Maintenantnous pouvons employer l'enquête d'UDDI pour la découverte du service. L’application de larecherche UDDI montre comment employer l'enquête UDDI.

Nous commençons l'application par appeler le make_uddi et le run_uddi de run.bat :commande à partir de l'annuaire d'instruction d’UDDI. Ces deux commandes exécutentl’application permettant d’avoir des informations sur n’importe quel Web service à condition

qu’il soit publié dans l’UDDI.Voici la structure d'un document de découverte :

<? xml version="1.0»?><disco: discovery xmlns:disco="http://schemas.xmlsoap.org/disco"xmlns:wsdl="http://schemas.xmlsoap.org/disco/wsdl">

<wsdl:contractRef ref="http://MyWebServer/UserName.asmx?WSDL"/></disco:discovery>

Ces étapes se déroulent en arrière plan, mais pour l’utilisateur il doit remplir un tableau qui

cache la complexité de ces étapes :

SUPCOM -62 -




Figure 5.12 : La découverte du service

7- Conclusion

Dans ce chapitre, nous avons présenté les bases de la programmation suivant le modèle decréation de nouveaux services dans les réseaux NGN, Web service, afin de découvrir les grandsprincipes de création de ces services.

Notre prototype est un ensemble d’interfaces successives faisant appel aux différentes étapes àfaire pour la création d’un service suivant le model Web service. Ces étapes doivent êtreexécutées dans l’ordre, et le passage d’une étape à l’autre ne peut se faire que lorsque l’étape

précédente est achevée avec succès.Ce prototype est indépendant du service que nous voulons créer, et donc chaque utilisateur

peut l’appliquer à son service pour le rendre conforme au modèle Web service. Mais ce prototypeest dépendant de la plate forme .NET puisque il se base sur les technologies intégrées en elle telque SOAP, WSDL et UDDI.

SUPCOM -63 -



Projet de Fin d’études 2004-2005 Conclusion générale

Conclusion générale

Dans le cadre de ce projet, nous avons contribué à la réalisation d’un prototype pour lacréation de services web, l’objectif d’un tel prototype est de rendre notre application conforme aumodèle web services.

Dans la première partie de ce travail, nous avons présenté les concepts de base du réseau NGNavant de se limiter à la couche service et de détailler les deux architectures de création deservices, l’architecture OSA et l’architectures Web services.

Dans la deuxième partie, nous avons comparé ces deux modèles et suite à la simplicité et laflexibilité du modèle Web service, nous avons choisi ce dernier pour développer notre prototype.

Dans la troisième partie, nous nous sommes intéressés à la conception et la réalisation duprototype, dans ce contexte, nous avons présenté tout d’abord l’environnement de travail .NETqui est une plate-forme fondée totalement sur des standards comme XML, SOAP, ensuite nousavons enchaîné avec les différentes étapes pour la création de notre prototype, del’implémentation du service jusqu’à sa publication.

Nous avons aussi créé des interfaces simples pour les utilisateurs de ce prototype, cesinterfaces vont cacher la complexité de déroulement de ces étapes à l’utilisateur.

Ce prototype reste évolutif et modulables en prévision d’extensions futures.

SUPCOM -64 -



Projet de Fin d’études 2004-2005 Bibliographie

Bibliographie

[1] Etude technique, économique et réglementaire de l’évolution vers les réseaux de nouvellegénération (NGN, Next Generation Networks). Etude réalisée par le cabinet Arcome

pour le compte de l'Autorité de régulation des télécommunications.

[2] Zygmunt Lozinski “Open Service Access (OSA), Application Programming Interface (API)Parlay/OSA - a New Way to Create Wireless Services” Parlay Group

[3]Ard-Jan Moerdijk1 and Lucas Klostermann “OPENING THE NETWORKS WITH PARLAY / OSA : STANDARDS AND ASPECTS BEHIND THE APIS” Parlay Group

[4] Judith M. Myerson “Web Service Architectures”

[5]http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ David Booth, W3C Fellow /Hewlett-Packard

[6]Heather Kreger “Web Services Conceptual Architecture” IBM Software Group

[7] Les Architectures de «Service » DEA MISI Mars 04

[8] Parlay Web Services: Architecture Comparison. Parlay Group

[9] http://msdn.microsoft.com/ Microsoft

SUPCOM -65 -

Documents

Service Ngn Pfe Meharouech Sourour