Vous êtes sur la page 1sur 70

RAPPORT DE PROJET DE FIN DETUDES

Filire Ingnieurs en Tlcommunications

Option Rseaux

Prototype de cration de nouveaux services dans les rseaux NGN


Elabor par : Meharouech Sourour Encadr par :

M. Zouhair Trabelsi M. Mohamed Zerzeri

Anne universitaire : 2004/2005

A ma mre

Avant propos

Dans le cadre de ma formation dingnieur au sein de lEcole Suprieur des Communications de Tunis, option rseaux , je suis mene effectuer ce projet de fin dtude qui reprsente laccomplissement de mon second cycle dtudes suprieures. Ce projet a t men en collaboration entre le centre dtude et de recherche des tlcommunications (CERT) et lcole suprieure des communications de Tunis.

Je tiens exprimer ma gratitude M. Mohamed ZERZERI, ingnieur principale au CERT, pour lencadrement de mon travail et pour son soutien, ses encouragements, ses aides prcieuses, sa disponibilit et sa patience.

Je tiens galement remercier M. Mounir FRIKHA, de mavoir guid et conseill durant llaboration de ce projet de fin dtudes.

Mes remerciements sadressent galement M. Zouhair Trabelsi pour ses conseils prcieux et ses remarques pertinentes qui mont aid laccomplissement de mon travail.

Jexprime aussi toute ma gratitude envers le corps professoral et administratif de lEcole Suprieur des Communications de Tunis pour llaboration de mon projet

Projet de Fin dtudes 2004-2005

Sommaire
Introduction gnrale........................................................................................................................1 Chapitre1............................................................................................................................................3 Introduction ......................................................................................................................................4 1- Architecture du rseau NGN........................................................................................................4 2 - Le rseau daccs ........................................................................................................................6 2.1- Les rseaux daccs fixes......................................................................................................6 2.2- Les technologies daccs fixe sans fil / radio........................................................................6 2.3- Les rseaux daccs mobiles.................................................................................................6 3- Les volutions au niveau de la couche transport .........................................................................6 4- La couche contrle.......................................................................................................................8 4.1- Les entits fonctionnelles du coeur de rseau NGN .............................................................8 4.1.1- La Media Gateway (MG)...............................................................................................8 4.1.2- La Signalling Gateway (SG) ..........................................................................................8 4.1.3- Le serveur dappel ou Media Gateway Controller (MGC) ............................................9 4.2- Les familles de protocoles dun rseau NGN .......................................................................9 5- La couche service.......................................................................................................................10 6- Conclusion .................................................................................................................................10 Chapitre2 : Le modle OSA ...........................................................................................................12 Introduction ....................................................................................................................................13 1- Prsentation des organismes travaillant sur le modle OSA .....................................................13 1.1- 3GPP / OSA ........................................................................................................................13 1.2- Le groupe Parlay .................................................................................................................13 1.3- JAIN (Java APIs for Interoperable Networks)....................................................................14 2- Larchitecture OSA/Parlay.........................................................................................................14 2.1- Introduction.........................................................................................................................14 2.2- Larchitecture OSA 3GPP...................................................................................................15 2.3- Prsentation de larchitecture OSA/Parlay .........................................................................18 3- Conclusion .................................................................................................................................22 Chapitre3 : Le modle Web Services.............................................................................................23 Introduction ....................................................................................................................................24 1- Origines des services Web .........................................................................................................24 2- Dfinition et description des Service Web.................................................................................24 3- Les domaines dutilisation des services Web ............................................................................25 3.1- Lintgration dapplications................................................................................................25 3.2- Les projets de portail...........................................................................................................26 4- Principales technologies de dveloppement de Services Web ..................................................26 4.1- XML -eXtensible Markup Language..................................................................................27 4.2- Le protocole daccs SOAP: Simple Object Access Protocol ............................................27 4.2.1- Dfinition et description de SOAP ..............................................................................27 4.2.2- Processus dchange de messages en SOAP ...............................................................28

SUPCOM

Projet de Fin dtudes 2004-2005 4.2.3- La spcification SOAP.................................................................................................29 4.3- WSDL : Web Services Description Language...................................................................31 4.3.1- Dfinitions et description de WSDL...........................................................................31 4.3.2- Structure dun document WSDL .................................................................................32 4.4- UDDI: Universal Description Discovery and Integration ..................................................33 4.4.1- Dfinition et description dUDDI ................................................................................33 4.4.2- Application de lUDDI ................................................................................................33 5- Cycle de vie dun service Web ..................................................................................................34 5.1- Cycle de vie dutilisation ....................................................................................................34 5.2- Cycle de vie complet...........................................................................................................35 5.3- Exemple dun Web services................................................................................................37 6- Gestion de la scurit dans les services Web.............................................................................38 7- Les points forts des services Web ..............................................................................................39 7.1- Universalit .........................................................................................................................39 7.2- Simplicit dutilisation........................................................................................................39 7.3- Couplage lche des applications : simplification des contraintes durbanisation...............39 8- Le niveau de maturit des services Web....................................................................................40 Chapitre 4 : Comparaison entre les deux modles OSA et Web Services .................................42 Introduction ....................................................................................................................................43 1- Comparaison des fonctions prsentes dans chaque architecture................................................43 2- Comparaison des interfaces dfinies dans chaque architecture ................................................44 2.1- Parlay/OSA .........................................................................................................................44 2.2- Web services .......................................................................................................................46 3- Degr de dpendance de chaque modle vis--vis du rseau ....................................................46 4- UDDI vs Framework..................................................................................................................47 5- Comment peuvent-ils converger ? .............................................................................................47 6- Conclusion .................................................................................................................................49 Chapitre5 : Dveloppement dun prototype pour la cration de nouveaux services ................50 1- Les diffrentes plates formes existantes ....................................................................................51 2- Pourquoi la plate-forme .NET pour dvelopper notre prototype ...............................................51 3- Pourquoi le langage de programmation Java ............................................................................52 4- Notre objectif .............................................................................................................................52 5- Modle de programmation de notre Web service ......................................................................52 6- Les tapes de cration du prototype...........................................................................................52 6.1- Etape 1 : Dfinition et implmentation de la classe de service...........................................53 6.2- Etape 2 : Dploiement et description de la classe Java un serveur SOAP .......................55 6.3- Etape 3 : La publication du web service .............................................................................59 6.4- Etape 4 : La dcouverte du service .....................................................................................62 7- Conclusion .................................................................................................................................63 Conclusion gnrale ........................................................................................................................64

SUPCOM

Projet de Fin dtudes 2004-2005

Introduction gnrale

Introduction gnrale

Dans le domaine des Services de Tlcommunication de 3me Gnration, il est dactualit dutiliser le slogan Any time, Any How, Anywhere . Du point de vue des utilisateurs finaux, ce slogan exprime leur souhait daccder un service depuis nimporte quel rseau, en utilisant nimporte quel type de terminal tout en bnficiant des mmes prfrences de prsentation et de service. Du point de vue des concepteurs et dveloppeurs dapplication, cela requiert un effort dabstraction, premirement pour capturer les prfrences de lutilisateur, et deuximement, pour matrialiser et fournir une telle qualit de service. Diffrents systmes rpondent dj en partie aux souhaits des utilisateurs. Cependant, les techniques utilises restent limites. Ils leur manquent laspect douverture, c'est--dire, dune part, la possibilit dtre applicables tous types de terminaux et rseaux daccs, et dautre part, de couvrir tout type de service. Laspect de standardisation est particulirement important ds quil sagit de fournir un service mettant en jeu des domaines diffrents : Domaine de lutilisateur, domaines des oprateurs de rseaux, domaine des fournisseurs de service. Le groupement doprateurs Third Generation Partnership Project (3GPP) vise tudier ces aspects novateurs des services offerts aux utilisateurs et laborer un environnement permettant doffrir lutilisateur le mme service sur nimporte quel type de terminal et travers nimporte quel type de rseau, ceci o que soit localis lutilisateur. Dans ce PFE intitul Prototype de cration de nouveaux services dans les rseaux NGN nous tudions larchitecture des deux modles de cration de services, OSA et Web services. Nous effectuons par la suite une comparaison entre ces deux approches. Suite cette comparaison, nous allons choisir lune des deux approches pour dvelopper un prototype pour la cration de nouveaux services. Ce Projet de Fin dEtude est constitu de 5 chapitres : Le premier chapitre introduit des concepts de base des rseaux NGN, tel quelles sont dfinis par le cabinet Arcome pour le compte de lART 1 . Le deuxime chapitre prsente larchitecture Open Service Access (OSA), cest dire Accs Ouvert aux Services permettant aux nouveaux services dexploiter les fonctionnalits des rseaux au moyen dinterfaces standardises. Ce chapitre prsente aussi la spcification du groupe Parlay relative cette approche.

ART : Autorit de Rgulation des Tlcommunications franaise

SUPCOM

-1 -

Projet de Fin dtudes 2004-2005

Introduction gnrale

Le troisime chapitre aborde la spcification du Web services dont lobjectif est de faire interagir des composants htrognes, distants et indpendants ddis particulirement aux applications de type Business to Business et Enterprise Application Integration. Le quatrime chapitre compare les deux architectures de cration de nouveaux services OSA et Web services, et suite cette comparaison nous allons justifier le choix de retenir lune des deux approches pour notre travail. Dans le dernier chapitre, nous allons prsenter les diffrentes plates formes de travail, ainsi que les tapes pour le dveloppement de notre prototype de cration de services, nous terminons par crer des interfaces pour les utilisateurs de ce service et qui cache la complexit de ces tapes lutilisateur.

SUPCOM

-2 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

Chapitre

Concepts de base du rseau NGN

1- Introduction 2- Architecture du rseau NGN 3- Conclusion

SUPCOM

-3 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

Introduction
Lvolution progressive du monde des tlcommunications vers des rseaux et des services de nouvelle gnration est aujourdhui une tendance forte qui suscite lintrt dune majorit dacteurs. Elle rsulte de la conjonction dun ensemble de facteurs favorables dont : Les volutions profondes du secteur des tlcommunications ; Le dveloppement de gammes de services nouveaux ; Les progressions technologiques denvergure dans le domaine des rseaux de donnes. Il en rsulte de ce contexte et afin de sadapter aux grandes tendances qui sont la recherche de souplesse dvolution de rseau, la distribution de lintelligence dans le rseau, et louverture des services tiers, une volution vers un nouveau modle de rseaux et de services appel NGN (Next Generation Networks). Les NGN sont bass sur une volution progressive vers le tout IP et sont modliss en couches indpendantes dialoguant via des interfaces ouvertes et normalises. Les rseaux de tlcommunications traditionnels volueront vers un modle ouvert, distribu, fortement bas sur le protocole IP et la transmission en mode paquet en gnral. Cette volution technologique se fera de manire progressive pour les oprateurs et transparente pour les utilisateurs. Ce chapitre prsentera une tude technologique afin de dcrire et comprendre lensemble des concepts nouveaux globalement dsigns sous lappellation NGN. Il inclut aussi une synthse des volutions technologiques majeures et le dtail des nouveaux concepts lis aux NGN.

1- Architecture du rseau NGN


Les rseaux de nouvelle gnration peuvent tre prsents comme un concept permettant de dfinir et dployer des rseaux volutifs et favorisant pour les fournisseurs de services et les oprateurs la cration et la gestion de services innovants. Les services doivent tre volutifs et accessibles indpendamment du rseau daccs utilis. Le NGN est caractris par plusieurs lments essentiels: Un coeur de rseau unique et mutualis pour tous types daccs et de services ; Une architecture de coeur de rseau en 3 couches : Transport, Contrle et Services.

SUPCOM

-4 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

Figure1.1 : Principe gnral darchitecture dun rseau NGN (Source ART)

Une volution du transport en mode paquet (une convergence progressive vers le tout IP); Des interfaces ouvertes et normalises entre chaque couche, et notamment au niveau des couches contrle et services afin de permettre la ralisation de services indpendants du rseau ;

Le support dapplications multiples, multimdia, temps rel, en mobilit totale, adaptables lutilisateur et aux capacits des rseaux daccs et des terminaux ; La prise en compte de rseaux daccs multiples ; La prise en compte de terminaux multiples.

Le schma, ci-dessous, prsente de manire trs simplifie, larchitecture physique dun rseau NGN.

Figure 1.2 : Architecture physique dun cur de rseau NGN (source ART)

SUPCOM

-5 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

2 - Le rseau daccs
Ce paragraphe va prsenter les principales technologies daccs actuellement connues dont la gnralisation contribuera alimenter le besoin et le dveloppement des NGN.

2.1- Les rseaux daccs fixes


Les rseaux daccs fixes sadaptent progressivement au support de services de donnes haut dbit : Le rseau tlphonique commut, initialement support des services voix, a permis une ouverture des services voix/donnes haut dbit grce aux technologies xDSL accessibles aux nouveaux oprateurs par le biais du dgroupage de la boucle locale. Laccs Ethernet, initialement conu pour fournir des services de donnes (IP) en entreprises, voit son usage stendre en termes de dbit, de primtre dutilisation et de services transports (voix et donne, multimdia).

2.2- Les technologies daccs fixe sans fil / radio


Plusieurs technologies permettent de fournir des services voix et donnes fixes en utilisant un accs radio. On citera notamment la boucle locale radio, les rseaux locaux sans fil et Bluetooth. Ces technologies sont globalement rcentes (pas plus de quelques annes), mais apparaissent trs prometteuses et promises des volutions et un dveloppement trs importants. Quant aux rseaux satellitaires, plusieurs tentatives de dploiement dj relativement anciennes ont men des checs (avant tout dordre conomique du fait des cots particulirement levs de dploiement), mais ils pourraient, dans les prochaines annes, trouver enfin leur place parmi les rseaux daccs effectivement utiliss pour fournir des services fixes .

2.3- Les rseaux daccs mobiles


Plusieurs rseaux daccs radio fournissant des services de radiocommunications mobiles publics sont prsents. Le GSM est une technologie historiquement oriente vers les services voix et donnes bas dbit mature et trs largement rpandue, mais volue actuellement avec lajout de services de transmission de donnes en mode paquet (GPRS), et court terme avec lmergence de la nouvelle gnration convergente voix/donnes/multimdia : lUMTS.

3- Les volutions au niveau de la couche transport


La couche Transport gre lacheminement du trafic vers sa destination. Les principales volutions du rseau de transport concernent les technologies de transmission et de commutation utilises sur les liaisons qui interconnectent les rseaux daccs au coeur de rseau. La question qui se pose cest comment les backbones sont susceptibles dvoluer afin de supporter le trs haut dbit, et surtout le transport unifie de flux mixtes voix/donne/multimdia avec la qualit de service adquate.

SUPCOM

-6 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

Figure 1.3 : Architecture du rseau NGN (source ART)

Tout dabord il faut distinguer entre le niveau rseau de transmission et le niveau rseau de commutation dans un rseau de transport (couche transport) Le rseau de transmission correspond au rseau physique de liens et de nuds qui desservent une zone (un immeuble, une ville, une rgion, un pays ou un continent). Le rseau de commutation correspond certains noeuds qui permettent dacheminer une communication travers le rseau de transmission en fonction de sa destination. Dans les architectures traditionnelles, un oprateur possde (ou loue) un rseau de transmission sur lequel sappuient en gnral plusieurs rseaux de commutation, lun ddi la commutation de la voix, lautre ddi la commutation de donnes. Lide qui sous-tend les NGN est de fusionner ces deux rseaux en un seul. Si lon visualise les technologies mises en jeu en sappuyant sur le modle en couches OSI (Open System Interconnection), la sparation entre rseau de transmission et rseau de commutation est trs nette. Pour la mise en oeuvre de ces rseaux de transport de nouvelle gnration , on peut mettre en vidence deux volutions majeures des rseaux de transport au niveau des rseaux de transmission et des rseaux de commutation. Concernent les rseaux de transmission, les techniques dominantes sont remises en cause. En effet, le multiplexage TDM (Time Division Multiplexing), utilise en grande majorit dans les rseaux actuels, est une technique de transmission adapte pour la commutation de circuits alors que la tendance actuelle est de migrer les rseaux de transmission actuels vers un rseau de transmission unique, neutre, voire favorable la commutation de paquets et donc on assiste aujourdhui des nombreux dveloppements autour du multiplexage WDM et aussi des plusieurs volutions lies loptique et au WDM.

SUPCOM

-7 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

Concernent les rseaux de commutation, La tendance actuelle est donc de dvelopper un rseau de commutation unique, sappuyant sur lactuel rseau de commutation de paquets, et qui permettrait de transporter tout type de trafic (voix, vido, donne, etc.). Concernant la Commutation IP, La tendance actuelle est la migration dIPv4 IPv6. Les principales amliorations de cette dernire version sont lamlioration du champ ToS renomme CoS pour Classe of Service, lintgration par dfaut du protocole de scurit IPsec (Internet Protocol Security), une nouvelle dfinition des adresses de diffusion, ainsi que lintgration par dfaut et lamlioration des mcanismes de traitement de ces adresses au niveau des commutateurs. Lobjectif de ces diffrentes volutions est de rpondre quatre impratifs : ladquation aux nouveaux besoins de services, le support de trs haut dbit, une garantie de qualit de service, et une gestion optimise du rseau de transport.

4- La couche contrle
Les volutions au niveau de la couche contrle sont majeures. Plusieurs nouveaux mcanismes et protocoles sont mises en jeu et donc une nouvelle architecture qui dcoule. La couche Contrle se compose de serveurs dits softswitch grant dune part les mcanismes de contrle dappel (pilotage de la couche transport, gestion des adresses), et dautre part laccs aux services (profils dabonns, accs aux plates-formes de services valeur ajoute).

4.1- Les entits fonctionnelles du coeur de rseau NGN


4.1.1- La Media Gateway (MG) Les Gateways ont un rle essentiel : elles assurent non seulement lacheminement du trafic, mais aussi linterfonctionnement avec les rseaux externes et avec les divers rseaux daccs. La Media Gateway est situe au niveau du transport des flux mdia entre le rseau RTC et les rseaux en mode paquet, ou entre le coeur de rseau NGN et les rseaux daccs. Elle a pour rle le codage et la mise en paquets du flux mdia reu du RTC et vice-versa (conversion du trafic TDM IP). Et aussi la transmission, suivant les instructions du Media Gateway Controller, des flux mdia reus de part et d'autre. 4.1.2- La Signalling Gateway (SG) La fonction Signalling Gateway a pour rle de convertir la signalisation change entre le rseau NGN et le rseau externe interconnect selon un format comprhensible par les quipements chargs de la traiter, mais sans linterprter (ce rle tant dvolu au Media Gateway Controller). Notamment, elle assure ladaptation de la signalisation par rapport au protocole de transport utilis. Cette fonction est souvent implmente physiquement dans le mme quipement que la Media Gateway, do le fait que ce dernier terme est parfois employ abusivement pour recouvrir les deux fonctions MG + SG.

SUPCOM

-8 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

4.1.3- Le serveur dappel ou Media Gateway Controller (MGC) Dans un rseau NGN, cest le MGC qui possde l'intelligence . Il gre : Lchange des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation, et linterprtation de cette signalisation. Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP, communication avec les serveurs dapplication pour la fourniture des services. Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du rseau, etc. La rservation des ressources dans le MG et le contrle des connexions internes au MG (commande des Media Gateways). Donc dans larchitecture des rseaux NGN, le serveur dappel, aussi appel Softswitch ou Media Gateway Controller (MGC) est le nud central qui supporte lintelligence de communication.

4.2- Les familles de protocoles dun rseau NGN


La convergence des rseaux voix/donnes ainsi que le fait dutiliser un rseau en mode paquet pour transporter des flux multimdia, ayant des contraintes de temps rel , a ncessit ladaptation de la couche Contrle. En effet ces rseaux en mode paquet taient gnralement utiliss comme rseau de transport mais noffraient pas de services permettant la gestion des appels et des communications multimdia. Cette volution a conduit lapparition de nouveaux protocoles, principalement concernant la gestion des flux multimdia, au sein de la couche Contrle. On peut classer les protocoles de contrle en diffrents groupes : Les protocoles de contrle dappel permettant ltablissement, gnralement linitiative dun utilisateur, dune communication entre deux terminaux ou entre un terminal et un serveur ; les deux principaux protocoles sont H.323, norme de lUIT et SIP, standard dvelopp lIETF. Les protocoles de commande de Media Gateway qui sont issus de la sparation entre les couches Transport et Contrle permettent au Softswitch ou Media Gateway Controller de grer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de lIETF et H.248/MEGACO, dvelopp conjointement par lUIT et lIETF, sont actuellement les protocoles prdominants. Les protocoles de signalisation entre les serveurs de contrle (ou Media Gateway Controller) permettant la gestion du plan contrle au niveau du coeur de rseau avec des protocoles tels que BICC (Bearer Independant Call Control), SIP-T (SIP pour la tlphonie) et H.323. Linterconnexion avec les rseaux de signalisation SS7 se fait gnralement via des passerelles de signalisation ou Signalling Gateways par lutilisation de protocole tel que SIGTRAN.

SUPCOM

-9 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

De plus, linterconnexion de ces rseaux de donnes avec les rseaux existants de tlphonie (TDM avec signalisation SS7) a ncessit le dveloppement de protocoles ddis linterconnexion des rseaux et au transport de la signalisation SS7 sur des rseaux en mode paquet.

5- La couche service
Actuellement, les services sont ddis un type de rseau : services Rseau Intelligent sur le rseau tlphonique pour les terminaux tlphoniques (fixes ou mobiles), et services mail, web, news sur les rseaux IP. Lapparition des nouveaux rseaux daccs, tels que lUMTS, le GPRS, lxDSL, lEthernet longue distance, et la multiplication des terminaux communicants (tlphone mobile GPRS/ UMTS, PDA,) et la convergence des coeurs de rseaux, poussent une transformation de larchitecture des plates-formes de services. Cette nouvelle architecture doit offrir la possibilit aux clients daccder aux services, quelle que soit la nature des terminaux et le type de protocole utilis pour accder aux plates-formes de services, via un rseau de transport unifi, en mode paquet. Le service rendu doit tre adapt aux besoins et aux moyens des clients. Deux modles principaux et complmentaires mergent de ces besoins dvolution darchitecture de la couche Services. Une architecture centre sur le Softswitch , base sur linterface de services normalise du modle OSA/Parlay et un modle orient Web Services , bas sur les technologies et des protocoles issus du monde Internet. Dans les chapitres suivants, nous allons dtailler ces deux architectures, nous proposons aussi une comparaison entre eux et nous terminons par choisir une pour dvelopper notre prototype.

6- Conclusion
Globalement, lvolution vers les NGN reprsente encore ce jour un sujet relativement amont, notamment du point de vue des oprateurs et dans une moindre mesure des purs fournisseurs de services. En effet, la conjoncture actuelle influe fortement sur les positions vis--vis des NGN puisque les acteurs sont confronts des problmatiques de financement et de prennit, ce qui les met dans un contexte peu favorable des volutions techniques et lapparition de nouveaux business models. Cela explique une certaine frilosit des acteurs interrogs vis--vis des solutions NGN qui prsentent une vision oriente vers une transition douce plutt quune rvolution des rseaux et services, mais qui pourrait se dbloquer rapidement si le contexte conomique volue. Mais on peut dire que la migration vers les NGN apparat comme un processus invitable du fait de la convergence voix/donnes/image et fixe/mobile. Elle est dj enclenche par un certain nombre dacteurs en France, en Europe et sur dautres continents, et ses impacts doivent donc tre analyss et anticips.

SUPCOM

-10 -

Projet de Fin dtudes 2004-2005

Concepts de base du rseau NGN

Cependant elle sannonce longue (une chelle de temps de 10 20 ans semble raisonnable), incomplte (cohabitation invitable avec les architectures dites traditionnelles) et difficile court terme du fait de lexistence de solutions concurrentes ayant des niveaux de fonctionnalits et de maturit diffrents, et des problmatiques dinteroprabilit de bout en bout.

SUPCOM

-11 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Chapitre

Le modle OSA

1- Introduction 2- Les diffrents organismes 3- Larchitecture OSA

SUPCOM

-12 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Introduction
Le modle OSA (Open Service Access) a t spcifi et standardis par le Joint API Group qui fdre les travaux du 3GPP (3rd Generation Partnership Program), de lETSI, du JAIN (Java APIs for Interoperable Networks) et du Parlay Group. Lobjectif de ce groupe de travail tant de proposer une interface standardise unique pour lensemble des besoins et de maintenir aussi lindpendance des applications par rapport la technologie rseau sous-jacente. Chaque organisme sest align sur ce modle fdrateur : le 3GPP travers SA1 et SA2, ETSI par le SPAN 14 SPAR et Parlay par le groupe Parlay. Le modle OSA est donc partag et soutenu par un nombre important dorganisations issues du monde des tlcommunications mobiles et fixes (3GPP, ETSI, Parlay Group) ou transverses aux mondes tlcoms et Internet (JAIN). Dans ce chapitre, nous allons prsenter les diffrentes solutions proposes par chaque organisme.

1- Prsentation des organismes travaillant sur le modle OSA


1.1- 3GPP / OSA
Le 3GPP (3rd Generation Partnership Project) est le fruit dune collaboration de plusieurs organismes de standardisation ainsi que la plupart des constructeurs ayant pour objectif de dfinir un ensemble de spcifications techniques pour les systmes mobiles de 3me gnration. En particulier, le 3GPP demande la dfinition dune architecture permettant doffrir le concept VHE (Virtual Home Environment) et nous pouvons dire que cest le 3GPP qui est lorigine de la dfinition OSA (Open Service Architecture, devenue Open Service Access). Il a identifi le modle OSA comme un des outils ncessaires la mise en place du concept VHE.

1.2- Le groupe Parlay


Le groupe Parlay est un forum ouvert ayant pour objectif de dfinir les spcifications dune API (Application Programming Interface) pour le modle OSA. Et donc nous pouvons dire que cest le Parlay Group qui est lorigine des API dOSA. Cette interface doit permettre aux diffrents acteurs, oprateurs, programmeurs et fournisseurs de services, de dvelopper des applications multi-technologies et multi-rseaux : cest le lien entre les services et les rseaux. LAPI permet de supporter les services dune tierce partie (ASP), en dfinissant une infrastructure grant les changes scuriss entre clients et serveurs. Il faut prciser que le but de Parlay est dtre indpendant dun langage particulier (utilise UML, IDL et CORBA) et que Parlay nest pas un langage, mais un ensemble de dfinitions de types de donnes et de mthodes regroupes au sein dAPIs dapplications.

SUPCOM

-13 -

Projet de Fin dtudes 2004-2005

Le modle OSA

1.3- JAIN (Java APIs for Interoperable Networks)


Lobjectif de JAIN est de crer un ensemble ouvert, depuis les fournisseurs de services tiers, en passant par les oprateurs et les constructeurs, jusquaux fabricants de terminaux et aux clients finaux. Cet ensemble est dfini pour tre distribu depuis nimporte quel protocole et middleware tels que RMI (Remote Method Invocation), CORBA (Common Object Request Broker Architecture) et DCOM (Distributed Common Object Model). Larchitecture JAIN sappuie sur les dveloppements du langage de programmation JAVA. Et son service de contrle dappel est bas sur celui dfini par le groupe Parlay. Ainsi larchitecture JAIN sarticule autour de deux axes : Les spcifications des Protocole API qui dfinissent linterface avec les protocoles de signalisation des rseaux fixes, mobiles et IP. Les spcifications des Applications API en charge de la dfinition des API ncessaires la cration de service, avec laide de Java, pour tous les protocoles couverts par les protocoles API.

2- Larchitecture OSA/Parlay
2.1- Introduction
A peu prs au mme moment o la communaut JAIN se mettait en place et dbutait ses travaux, British Telecom (BT), Microsoft, Nortel, Siemens et Ulticom formaient le Parlay Group, qui a donn le jour une panoplie dAPIs orientes objet et indpendantes du langage les exploitant, afin de faciliter la cration de services dans les rseaux publics de tous types. Les APIs dapplications dfinies par le groupe Parlay doivent permettre un accs ouvert mais scuris un ensemble de fonctionnalits aujourdhui rendues par les diffrents rseaux privs ou publics. Il est attendu de la publication de ces APIs quelles soient utilises par une plus grande communaut de dveloppeurs afin de dynamiser le dveloppement de nouveaux services de tlcommunications. Mais pour ce faire, les spcifications que dfinit Parlay ont besoin dun modle architectural standardis permettant aussi de prendre en compte des abonns mobiles, et le modle OSA dvelopp conjointement par le 3GPP sest avr idal pour une mise en commun des efforts du Parlay Group avec le groupe de travail du 3GPP, qui ont ds lors collabor ldification dun standard commun OSA/Parlay. OSA/Parlay noffre pas seulement la possibilit aux oprateurs douvrir leurs rseaux des parties tierces, mais sadresse galement aux oprateurs cbls comme aux oprateurs sans fils, en proposant sans diffrenciation aucune une nouvelle mthode peu coteuse, rapide et efficace pour crer leurs propres services en fonction de la demande quils peroivent. Nous allons par la suite dans cette partie nous intresser plus particulirement la mise en commun des spcifications mises au point par le Parlay Group avec larchitecture OSA (Open

SUPCOM

-14 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Services Architecture) pour services mobiles du 3GPP, alliance laquelle lon se rfre communment par la combinaison des deux acronymes : OSA/Parlay.

2.2- Larchitecture OSA 3GPP


Le 3GPP reprsente la co-opration de diffrents organismes de standardisation pour promouvoir la production de spcifications techniques pour les systmes mobiles de 3me gnration (bass sur les techniques daccs CDMA). Le 3GPP a dfinit OSA comme une architecture donnant la possibilit aux oprateurs, fournisseurs de services et dapplications de tirer profit des fonctionnalits offertes par le rseau travers une interface ouverte et standardise, qui est linterface OSA. Cette interface fait le lien entre les applications et les services quest capable doffrir le rseau, et maintient lindpendance des applications par rapport la technologie rseau sous-jacente. Du point de vue du dveloppeur dapplication, le but de l'architecture Open Service Access est de lui permettre dutiliser un ensemble standardis d'interfaces afin d'accder une mme fonctionnalit de rseau indpendamment des technologies de rseau sous-jacentes (rseau tlphonique, rseau IP ou autre). Cela rend les applications portables sur des rseaux diffrents. Du point de vue des oprateurs de rseaux, OSA ouvre aux applications lusage des capabilits de rseaux, et ceci de manire extensible en permettant dinclure des nouvelles fonctionnalits rseau sans ncessairement devoir modifier les applications existantes. Dans le modle architectural OSA, cinq types dentits cls sont retenir. Il y a : Les applications Le serveur dapplications sur lequel rsident 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 schma suivant prsente ces diffrentes entits

SUPCOM

-15 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Figure 2.1 : Larchitecture OSA

Larchitecture OSA est en ralit une architecture distribue, dont le plus haut niveau est constitu par les applications clientes, qui se trouvent dans les serveurs dapplications. Le Gateway fait, lui, office de serveur situ la frontire du domaine du fournisseur dapplications. Entre les serveurs dapplications clients et le Gateway sur lequel tournent les SCS existe le rseau et la mthode de communication la plus couramment utilise entre ces deux entits distantes travers ce rseau est le recours un bus middleware CORBA. Nous expliquerons les caractristiques de chaque entit dans la partie suivante. 2.2.1- Les applications clientes Les applications clientes rsident sur des serveurs dapplications et accdent aux SCSs travers linterface OSA et les APIs Parlay du Gateway. Ces APIs servent de liens entre les applications et les SCSs. De cette manire, les applications sont rendues indpendantes de la technologie du rseau sous-jacent. 2.2.2- Le serveur dapplications Il est configur de manire se connecter au Gateway par lintermdiaire dune connexion TCP/IP (nimporte quel PC suffisamment puissant peut faire office de serveur dapplications, dune simple machine Linux un serveur avanc et spcialis par un constructeur). Le serveur dapplications peut avoir pour rle galement de cacher lutilisation de CORBA au programmeur, en faisant appel des Convenience Classes , dcrites dans un langage de haut niveau tel que Java.

SUPCOM

-16 -

Projet de Fin dtudes 2004-2005 2.2.3- Les Services Capability Servers (SCS)

Le modle OSA

Les SCSs implmentent les spcifications Parlay sur linterface OSA du Gateway, et se chargent deffectuer la translation de ces APIs vers les protocoles de tlcommunications spcifiques prsentes au plus bas niveau, cachant de cette manire la complexit du rseau aux applications. Ils mettent aussi disposition des applications clientes les fonctionnalits OSA appeles Service Capability Features (SCFs), ou plus simplement Services. 2.2.4- Les Service Capability Features (SCF) Une SCF constitue labstraction dun service particulier offert par le rseau et accessible au travers des APIs Parlay. Les SCFs sont spcifies en tant quinterfaces avec leurs mthodes propres. Un seul et mme SCS peut tre vu par les applications en tant quune ou plusieurs SCFs. 2.2.5- Le Gateway Pour communiquer avec le monde extrieur et les diffrents lments entrant en jeu, les applications vont communiquer dabord travers une interface intermdiaire qui est le Gateway OSA. Pour communiquer avec le monde extrieur et les diffrents lments entrant en jeu, les applications vont communiquer dabord travers une interface intermdiaire qui est le Gateway OSA. Le Gateway OSA consiste en plusieurs SCS, qui ne sont autres que des entits fonctionnelles qui fournissent limplmentation des interfaces OSA/Parlay ncessaires la communication avec lapplication. Cest donc llment central de larchitecture OSA, et cest travers cet quipement quun provider devient en mesure de proposer une manire standardise pour ouvrir son rseau et ses fonctionnalits des ASPs et dveloppeurs tiers dapplications. 2.2.6- CORBA CORBA est lacronyme de Common Object Request Broker Architecture, et dsigne une infrastructure permettant une communication rpartie entre objets. CORBA a t standardis par un consortium appel OMG (Object Management Group) en 1989, et permet en soi de remplir les mme fonctions dappels de mthodes loignes (RPC : Remote Procedure Calls) que le font dautres mcanismes de communication distribue et rpartie tels que DCOM (Microsoft) ou RMI (Java). Le but de lOMG a t de faire de CORBA une technologie dobjets distribus capable dtre dploye dans tout environnement, indpendamment de la plateforme, du langage et du protocole utilis. Il sagit donc dune architecture ouverte et garantissant une grande interoprabilit entre diffrents composants, permettant de rpartir des objets entre les composants en communication, o lobjet reprsente en loccurrence un regroupement de donnes et de traitements agissant sur ces mmes donnes.

SUPCOM

-17 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Ainsi nimporte quel programme bas sur CORBA peut sentendre avec nimporte quel autre programme aussi bas sur CORBA, mme si ce dernier se situe sur une diffrente machine provenant dun quipementier diffrent, tournant sur un autre systme dexploitation et dcrit par un autre langage de programmation sur un autre rseau.

2.3- Prsentation de larchitecture OSA/Parlay


2.3.1- Prsentation et objectif du groupe Parlay Le groupe Parlay est un consortium but non lucratif fond en 1998 qui a t constitu lorigine (Parlay phase 1) par British Telecom, Microsoft, Nortel Networks, Siemens et Ulticom. Fin 2000, le groupe comprenait plus de quarante membres, et il compte aujourdhui plus de 65 compagnies, issues tant des tlcoms que des industries de la technologie de linformation (IT). Parmi ces dernires on peut citer: Alcatel, Ericsson, Fujitsu, HP, IBM, Lucent, NTT, Sun Microsystems, Telcordia Technologies, Telecom Italia, Orange Communications. Cest un forum ouvert qui sest fix comme objectif de dfinir des API dapplications et de les promouvoir au sein dorganismes de standardisation comme lETSI, mais aussi auprs dautres forums tels que JAIN, le 3GPP, lOMG, le MSF (Multiservice Switching Forum) ou encore lIN Forum. 2.3.2- UML Afin de garantir une accessibilit une communaut de dveloppeurs aussi large que possible, les APIs ne ciblent pas une technique dimplmentation particulire. Afin de garantir une accessibilit une communaut de dveloppeurs aussi large que possible, les APIs ne ciblent pas une technique dimplmentation particulire. Il est important de bien concevoir que Parlay nest pas un langage, mais une dfinition dinterfaces et de mthodes regroupes au sein dAPIs dapplication dont le but est de permettre un accs ouvert mais scuris un ensemble de fonctionnalits (commande dappel, gestion de la mobilit, interaction usager, messagerie, etc) aujourdhui rendues par les diffrents rseaux publics ou privs. Pour exprimer ces dfinitions, Parlay utilise la notation UML (Unified Modeling Language), qui est un formalisme objet standardis par lOMG (comme CORBA et IDL) et destin la modlisation dun systme, logiciel ou non, plusieurs niveaux dabstraction afin de le construire, le documenter et le maintenir. Ce type de description convient donc parfaitement aux interfaces que Parlay sefforce de modliser, travers une architecture distribue OSA. UML peut tre utilis avec la plupart des langages de programmation (orients objet ou non), et la plupart des architectures techniques du commerce (CORBA ). 2.3.3- Structure des APIs Parlay Parlay spcifie pour le domaine IT les capacits et fonctionnalits de tlphonie usuellement disponibles dans un rseau Telecom traditionnel. En fonction du type de fonctionnalit dont il SUPCOM -18 -

Projet de Fin dtudes 2004-2005

Le modle OSA

sagit, celles-ci sont rparties en diffrents groupes, que lon appelle communment Service Capability Features (SCF) ou plus simplement Services, et qui sont rendues disponibles travers des Service Capability Servers (SCS).

Figure 2.2 : Structure Parlay

Les SCFs (linterface de fonctionnalit de service), offrant aux applications les fonctionnalits du rseau, sont standardises. Les SCFs sont des interfaces CORBA, et leur ensemble forme lAPI OSA. Les SCSs (les serveurs de fonctionnalit de service) jouent le rle dintermdiaire entre invocations sur les SCFs et vnements sur les lments de rseaux. LAPIs dOSA est divise en deux ensembles: Les SCFs de type Framework offrent le support la gestion denregistrement des fonctionnalits rseau, labonnement des applications aux fonctionnalits rseau et les mcanismes daccs scuris aux applications. Les SCFs de type Service Rseau offrent lusage des fonctionnalits rseau.

Figure 2.3 : Les API dOSA

Essentiellement, la sparation entre les deux interfaces peut tre vue de la manire suivante : Les interfaces du Framework fournissent les outils ncessaires pour assurer que les interfaces de services soient accessibles de manire fiable, constante, sre et grable. Le framework possde son propre SCS. SUPCOM -19 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Les interfaces de Services offrent aux applications laccs toute la panoplie des fonctionnalits du rseau. Les Services possdent leurs propres SCSs. Le Framework qui est lun des SCS de linterface Parlay/OSA est indispensable au bon fonctionnement des services et il gre principalement les fonctions suivantes: Les fonctions dauthentification des applications pour accder au rseau ; Les fonctions dautorisation pour les applications utiliser certains SCF et donnes clients, et, pour les clients, utiliser une application (vrification dinscription) ; Les fonctions de dcouverte des SCF, permettant aux applications dobtenir des informations sur les SCF accessibles ; La gestion dtablissement de services pour les applications qui doivent accepter en ligne le contrat doffre de services ; La gestion de lintgrit des services : gestion de la qualit du service rendu. La gestion de lenregistrement des SCF. Les SCFs de type Service Rseau, qui nous concernent plus particulirement sont les suivantes: SCF dinteraction avec lutilisateur: cette interface permet une application de dialoguer avec un utilisateur, travers un modle de communication trs simple. Lapplication envoie des messages vocaux lutilisateur. Ce dernier peut interagir par pression de bouton sur son clavier tlphonique. Ce SCF est donc trs utile, puisquil permet lutilisateur daccder au Virtual Home Environment travers un rseau tlphonique. SCF des capabilits des terminaux et SCF de mobilit usager: Ces interfaces permettent une application de collecter les capabilits du terminal de lutilisateur et sa localisation. Dans notre contexte de gestion de profil, les informations sur le terminal, y compris sa localisation, seront utilises pour prslectionner les profils adapts la situation courante de lusager.

Figure 2.4 : Les diffrents SCF de type rseau

2.3.4- Le Framework Parlay et la scurit La classe dinterfaces du Framework se distingue des autres interfaces, et contrairement aux interfaces de Services, il est absolument ncessaire de limplmenter.

SUPCOM

-20 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Le Framework contrle laccs aux diffrents services depuis le Gateway, en fournissant un ensemble de fonctions indpendantes du rseau assurant des mcanismes dauthentification, de gestion dintgrit, de notification dvnements. Lauthentification (Authentication) : elle est ralise par encryptage des donnes et des algorithmes de signature lectronique. La gestion de lintgrit (Integrity Management) : le Framework offre galement des interfaces de gestion de lintgrit du systme, dont des interfaces de gestion de la charge et des erreurs, mais aussi un mcanisme de battements de coeur (heartbeat mechanism), qui consiste en un change de signaux entre le Framework et une application ou un SCS, pour sassurer de la bonne sant de ce dernier. La notification dvnements (Event Notification) : cela autorise une application de demander une notification lorsquun service ou une classe de services particulire se libre. 2.3.5- Les Services Parlay Les interfaces de services rendent visibles aux applications un ensemble de fonctions rendues par les rseaux sous-jacents. Ces services comprennent : Generic Call Control Service: dfinit la manire dont les applications peuvent passer des appels travers le rseau, comment elles peuvent dmarrer une confrence vocale, comment elles sont utilises pour router des appels partir du rseau, comment elles peuvent initier des appels multi-mdias et dtecter de nouveaux vnements. Common Data Definitions : dfinit les objets et types utiliss tout au long des spcifications Parlay. Mobility : dfinit la manire dont une application peut parvenir localiser un terminal, et la manire dont elle peut requrir une notification lorsquun terminal mobile change de position. User Location : dfinit la manire dont une application peut obtenir des informations sur la localisation dun utilisateur en temps rel. User Status : dfinit la manire dont une application peut obtenir des informations sur ltat dun utilisateur : occup, injoignable, etc. Data Session Control : dtermine la manire dont les applications grent leurs sessions de dchange de donnes inities partir dun terminal. Generic Messaging : dtermine la manire dont les applications interagissent avec des systmes de messagerie tels que voice mail, Fax ou email. Connectivity Management : dtermine la manire dont les applications grent la qualit de service et la configuration de VPNs. Presence and Availability Management : dtermine la manire dont les applications affichent la prsence et la disponibilit dun utilisateur travers des messages types. SUPCOM -21 -

Projet de Fin dtudes 2004-2005

Le modle OSA

Policy Management : dtermine la manire dont les applications interagissent avec dautres rseaux possdant une politique particulire.

3- Conclusion
Au fil des versions toujours plus volues des APIs Parlay, dautres interfaces publiques de support administratif ont t greffes et mises disposition de lutilisateur directement, et dautres fonctions encore ont t rajoutes pour permettre aux fournisseurs dapplications 3rd Party de participer plus simplement et plus activement. Des dfinitions dinterfaces propres aux applications e-Commerce sont en cours de standardisation. Limplmentation de toutes ces fonctionnalits nest pas obligatoire, il nest ncessaire dimplmenter que celles que le rseau est mme de fournir, en fonction du type de services quil propose.

SUPCOM

-22 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Chapitre

Le modle Web Services

1- Introduction 2- Dfinition et description des Web services 3- Les principales technologies de dveloppement

SUPCOM

-23 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Introduction
Les Services Web reprsentent une nouvelle re de la communication. Par leur indpendance vis--vis des langages et des plates formes, les Services Web ont cr un nouvel univers dans la communication entre les applications. Cet univers repose sur la dfinition de standards nouveaux et universels. Nous allons dans ce chapitre essayer de rpondre aux questions suivantes : Que sont les Services Web ? Quels sont ses principes et ses fondamentaux ? Quels sont les avantages et les limites de cette technologie? Nous allons aussi voir dans ce chapitre les domaines dutilisation des Services Web, et leur niveau de maturit.

1- Origines des services Web


Avec l'essor du web qui a eu dans les dernires annes, 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 connat comme services web. Labstraction est une des plus importantes dimensions du dveloppement de linformatique. Labstraction concerne, pour une part, linteraction entre applications. Cette relation porte plusieurs noms : interaction, interoprabilit, change ; etc. Elle est aussi passe par plusieurs modles, client - serveur, fournisseur consommateur, mais toujours pour un mme objectif : lchange dinformations. Les web services rpondent une double demande : celle dun change sr et celle dun change ouvert. Lchange ouvert est permis, puisquun serveur ne doit pas ncessairement connatre lavance son client pour offrir son service vers lextrieur. Et donc en tenant en compte que les services web permettent de connecter des applications diffrentes, l'utilit de cette technologie devient vidente et importante.

2- Dfinition et description des Service Web


Le groupe de W3C qui travaille sur les services Web a utilis dans un document appel Web Services Architecture la dfinition de service Web suivante: A web service is a software system designed to support interoperable machine to machine interaction 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 in conjunction with otherweb-related standards . Cela veut dire que les Services Web sont des services offerts via le web et qui sont associ principalement deux spcifications : SOAP, protocole dchange de messages XML permettant dinvoquer des oprations distance ; et WSDL, langage de description des Services Web.

SUPCOM

-24 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Par exemple, un client demande le prix dun article en envoyant un message sur le web. Ce message contient la rfrence de larticle. Le Web Service va recevoir la rfrence, effectuer le traitement 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 dimplmentations, et un protocole daccs. Linterface dun Service Web est dcrite en XML, elle est par consquent indpendante du langage de programmation. Elle dcrit une liste doprations que lutilisateur peut invoquer, et donne les dtails techniques de cette invocation (protocoles, URL daccs, etc.). Une opration, qui peut tre synchrone ou asynchrone, est constitue dun change de messages XML entre le Service Web et son client. Linterface des Services Web est dcrite dans un document WSDL : Web Service Definition Language. Chaque Service Web a un nombre non limit dimplmentations. Il peut tre dvelopp en tout langage de programmation : C++, Java, VB, etc. Le point dentre du service est son interface, nous naccdons pas directement son implmentation :

Figure 3.2 : Architectures dun Web services

3- Les domaines dutilisation des services Web


3.1- Lintgration dapplications
Les Web Service ont pour objectif de faciliter la mise en place des communications interapplicatives. Lintgration dapplication regroupe en fait 2 concepts : lEAI (Enterprise Application Integration) et le B2B (Business To Business). LEAI a pour objectif duniformiser le systme informatique interne dune entreprise. Dans une entreprise ou lEAI est mis en place, les applications (facturation, gestion des clients, gestion

SUPCOM

-25 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

des fournisseurs) collaborent dans le but datteindre des objectifs de lentreprise. Le but de lEAI est de rduire les cots des transactions en liminant le plus grand nombre possible de sources derreur et en automatisant la majorit des tches. Le B2B a pour objectif de favoriser les changes dinformations entre entreprises partenaires. Le B2B adresse autant les mcanismes de communication interapplicatifs (infrastructure technique) que la smantique des informations changes (comment modliser un bon de commande, une facture, etc.), les accords de collaboration, etc.

3.2- Les projets de portail


De part leur modularit, les Services Web peuvent aussi tre utiliss dans le cadre de projets de portail. En effet, un portail est compos de petites applications indpendantes offrant des fonctionnalits lutilisateur : une fentre donnant la mto, une autre lhoroscope, une autre permettant de faire de la traduction de texte, etc. Chaque petite application a sa propre interface utilisateur, et accde aux applications de lentreprise, qui effectuent tous les traitements intelligents. Ces petites applications sont appeles des portlets, et certains diteurs commencent utiliser les Services Web pour connecter ces portlets lapplicatif de lentreprise.

Figure 3.3 : Exemple de projet Portail

4- Principales technologies de dveloppement de Services Web


Une caractristique qui a permis un grand succs de la technologie des services web est qu'elle est construite sur des technologies standard. Le schma suivant est une reprsentation conceptuelle dun service Web et qui montre les principales technologies sur lesquelles il se base.

SUPCOM

-26 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Figure 3.4 : Reprsentation conceptuelle dun service Web

4.1- XML -eXtensible Markup Language


XML eXtensible Markup Language est un format texte simple, trs flexible tir du SGML (l'ISO 8879). A l'origine conu pour la publication lectronique grande chelle, XML joue aussi un rle de plus en plus important dans l'change d'une large varit de donnes sur le Web et ailleurs. W3C recommande depuis 1998 XML en tant que standard de description de donnes. XML est un mta langage permettant didentifier la structure dun document. Un document est compos dune dfinition de sa structure et dun contenu. La structure dun document XML est souvent reprsente graphiquement comme un arbre. La racine du document constitue le sujet du document, et les feuilles sont les lments de ce sujet. De ce fait, XML est alors flexible et extensible et est devenu rapidement le standard dchange de donnes sur le web.

4.2- Le protocole daccs SOAP: Simple Object Access Protocol


4.2.1- Dfinition et description de SOAP SOAP est une initiative de Microsoft et Developmentor, ne en 1998. Les principaux diteurs du march ont particip son dveloppement et intgrent cette technologie leur stratgie : IBM avec Websphere, Sun avec Sun ONE, BEA avec Weblogic, Microsoft avec .Net, etc. Le W3C a finalement particip la dfinition de SOAP. On peut donc dfinir ce protocole comme un protocole pour lchange dinformation dans un environnement rpartie, bas sur le standard XML. Ce protocole consiste en trois parties : une enveloppe qui dcrit le contenu du message et SUPCOM -27 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

comment le traiter, un jeu de rgles de codage exprimer les cas de types de donnes dfini par lapplication et une convention pour reprsenter des appels de procdure loigns (RPCs) et ses rponses. Autrement dit SOAP est la spcification qui formalise le format des messages XML qui sont changs pour faire de linvocation de services distance c'est--dire comment reprsenter une requte, une rponse, une erreur, etc. Ces messages sont transports par un protocole standard (HTTP, HTTP Extension Framework SMTP) ou tout autre mcanisme de transport (JMS, etc.). SOAP nest pas li aucun systme dexploitation ni langage de programmation. Il est indpendant du langage dimplmentation des applications client et serveur.

Figure 3.5 : Prsentation du protocole SOAP

4.2.2- Processus dchange de messages en SOAP Les messages SOAP sont des transmissions fondamentalement sens unique d'un expditeur un rcepteur. Lorsquune transmission dun message commence (e.g. invocation dun service web), un message SOAP (ou document XML) est gnr. Ce message est envoy partir dune entit apple le SOAP sender, localis dans un SOAP noeud. Le message est transmis zro ou plusieurs noeuds intermdiaires (SOAP intermediates) et le processus fini lorsque le message arrive au SOAP receiver. Le chemin suivi par un message SOAP est nomm message path. La figure suivante montre les lments qui participent au processus.

Figure 3.6 : Processus dchange de messages en SOAP

SUPCOM

-28 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Quand un message SOAP arrive dans une entit SOAP, il suivit le processus dcris cidessous : 1. Identifier toutes les parties du message SOAP destin cette entit. 2. Vrifiez que toutes les parties obligatoires identifies dans le pas 1 sont soutenues par lentit et traitez-les en consquence. Si ce n'est pas le cas rejeter le message. 3. Si lentit n'est pas la destination suprme du message, elle enlve alors toutes les parties identifies dans le pas 1 avant l'expdition du message. Le traitement d'un message ou une partie d'un message exige que le processeur de SOAP comprenne, parmi d'autres choses, le modle dchange utilis (exp ; sens unique, multicast), le rle du destinataire dans ce modle, l'emploi de mcanismes RPC, la reprsentation ou le codage de donnes, aussi bien que d'autres smantiques ncessaires pour un traitement correct. 4.2.3- La spcification SOAP La spcification SOAP est constitue de 4 parties. Les trois premires concernent le format des messages : lenveloppe SOAP, les rgles dencodage, et SOAP RPC. La quatrime partie de la spcification dfinit lutilisation de SOAP avec des protocoles de transport. Dans cette section, nous allons dtailler ces 4 parties : 1- Lenveloppe SOAP Lenveloppe SOAP dfinit le format des messages changs. En fait, un message SOAP peut tre considr comme une enveloppe : nous y ajoutons les informations traiter par le destinataire (le message transmettre), nous prcisons ladresse du destinataire dans lentte de lenveloppe, nous envoyons lenveloppe au destinataire, qui extrait les informations, effectue les traitements adquats et renvoie une rponse lexpditeur si ncessaire.

Figure 3.7 : Lenveloppe SOAP

Lenveloppe SOAP dfinit lespace de nom (namespace : URI permettant de connatre la provenance de chaque balise) prcisant la version supporte de SOAP. Cet espace de nom est standard et permet de diffrencier les lments du schma. Lenveloppe SOAP est constitue dun en-tte facultatif (SOAP header) et dun corps obligatoire (SOAP body).

SUPCOM

-29 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Figure 3.8 : Les lments formant lenveloppe SOAP

Entte SOAP Lentte contient les informations traiter par les intermdiaires du message lors de sa transmission au destinataire. Par exemple, nous pouvons y ajouter les informations concernant le contexte au cours duquel le message a t envoy : informations sur la transaction en cours, lauthentification de lexpditeur, etc. Le contenu de lentte nest pas normalis par SOAP : les deux parties qui schangent ce message doivent donc sentendre sur un format commun.
Corps SOAP

Le corps SOAP contient linformation destine au receveur. Il doit fournir le nom de la mthode invoque par une requte, ou le nom de la mthode pour gnrer la rponse. Il doit aussi, fournir lespace de nom correspondant au nom du service. Le contenu du corps SOAP est utilis dans un processus comme le marshaling dappels RPC et le rapport des erreurs. Le corps SOAP peut contenir un SOAP fault. Ce bloc est utilis pour transmettre linformation des erreurs durant le traitement du message. Malgr que l'en-tte et le corps sont dfinis comme des lments indpendants, ils ont une relation : une entre de corps est smantiquement quivalente une entre d'en-tte. 2- Les rgles de codage Les rgles de codage fournissent un mcanisme permettant de coder en XML de manire standard les donnes changes par les applications. Ces rgles de codage se basent sur XMLSchema, recommandation du W3C pour dfinir des grammaires XML. Les rgles de codage prcisent en particulier la faon dencoder les types de base (string, int, etc.), les tableaux de bytes et autres types de donnes en XML. 3- SOAP RPC SOAP RPC est la partie la plus connue de la spcification. En effet, 80% des applications utilisant SOAP le font pour des appels de procdures distance, car SOAP offre un mcanisme simple et portable cette intention. SOAP RPC permet en particulier dappeler les oprations des Services Web. 4- Le transport des messages SOAP La quatrime partie de la spcification SOAP dfinit comment transporter les messages SOAP. Pour le moment, seul le transport avec le protocole HTTP a t dfini. Mais il est possible de transporter les messages SOAP avec dautres protocoles tels que SMTP. Des exemples ont mme t mis en place par IBM pour transporter ces messages avec MQSeries ou JMS.

SUPCOM

-30 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

La dfinition de lutilisation de SOAP avec HTTP est trs simple : les messages SOAP sont envoys dans une requte POST, et on ajoute un attribut lentte HTTP : SOAPAction, qui prcise le but de la requte SOAP (information destine au filtrage des messages SOAP par les firewall). Donc il suffit dencapsuler le message SOAP dans un message http.

4.3- WSDL : Web Services Description Language


WSDL est le fruit dune collaboration entre IBM et Microsoft, ils avaient tous deux propos leur propre langage de dfinition des Services Web : IBM avec NASSL Network Accessible Service Specification Language et Microsoft avec SCL SOAP Contract Language. Lobjectif de cette spcification est de formaliser la description des Services Web. 4.3.1- Dfinitions et description de WSDL WSDL est un langage permettant de dcrire les services Web et en particulier, les interfaces des services web. Ces descriptions sont des documents XML. Un document WSDL permet de dfinir tous les lments dun service : Les types de donnes utilises. Les messages changs. Les oprations fournies par le service. Les protocoles utiliser pour appeler ces oprations. Les points daccs du service : liste des URL. WSDL dcrit un service web en deux tapes fondamentales : une abstraite et une concrte. Dans chaque tape, la description utilise un nombre de constructions pour favoriser la rutilisation de la description et pour sparer les proccupations de conception indpendantes.

Figure 3.9 : La spcification dun service Web avec WSDL

Au niveau abstrait, WSDL dcrit un service Web en termes des messages qu'il envoie et reoit. Au niveau concret, WSDL indique des dtails de format de transport pour une ou plusieurs interfaces.

SUPCOM

-31 -

Projet de Fin dtudes 2004-2005 4.3.2- Structure dun document WSDL

Le modle Web Services

Un document XML commence par la balise dfinition et contient les balises suivantes : types: cette balise dcrit les types utiliss ; message: cette balise dcrit la structure dun message chang ; portType: cette balise dcrit un ensemble doprations (interface dun service web) ; operation: cette balise dcrit une opration ralise par le service web. Une opration reoit des messages et envois des messages ; binding: cette balise dcrit le lien entre un protocole (http) et un portType ; service: cette balise dcrit un service comme un ensemble de ports ; port: cette balise dcrit un port au travers duquel il est possible daccder un ensemble doprations. Un port rfrence un Binding. 1- Lentte du document WSDL Llment racine du document WSDL sappelle <definitions>. On y dfinit les espaces de nommage utiliss dans la suite du document, xsd pour lutilisation de XML-Schema et soap pour le binding SOAP. <definitions xmlns:xsd=http://www.w3.org/2000/10/XMLSchema xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/> 2- La dfinition des types de donnes utiliss Lappel dun Service Web seffectue par change de messages XML. Ces messages comportent les paramtres dinvocation du service (ou de la rponse). Ces paramtres sont bien videmment typs. Il est possible dutiliser les types de donnes fournis par XML-Schema, ou de dfinir ses propres types de donnes, dans llment <types>. 3- La dfinition des messages changs Chaque opration fonctionne par change de messages XML. Pour les oprations synchrones par exemple, il y a un message dentre (la requte), et un message de sortie (la rponse). On dfinit les messages qui sont changs dans des lments <message>. 4- La dfinition des oprations Une fois les messages modliss, on peut dfinir les oprations qui prennent en paramtre dentre/sortie ces messages. A ce stade de la conception de notre document WSDL, on obtient une description complte des oprations et de leurs paramtres dentre/sortie. On appelle cette partie la dfinition abstraite du service. Dans la suite du document, on associe ces oprations un protocole, et une liste dURL. 5- Lassociation un protocole particulier

SUPCOM

-32 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Une fois les oprations dfinies, on les associe un protocole, dans le cas gnrale SOAP par dessus HTTP. Cette association sappelle un binding, et est par consquent dfinie dans un lment <binding>. Cette partie est la plus complexe du document WSDL. Elle est quasiment identique dun document WSDL lautre. Lobjectif tait de rendre WSDL extensible, et de pouvoir adapter les descriptions aux diffrents cas (SOAP par dessus SMTP, HTTP, etc.). 6- Lassociation une URL La dernire tape est dassocier ce binding une implmentation particulire, ce que lon fait dans la balise <service>. Un service peut avoir plusieurs points daccs. Chacun de ces diffrents points daccs est dfini dans un lment <port>. Il suffit ensuite dajouter tous ces lments bout bout pour obtenir le document WSDL total. Ce document contient tous les lments ncessaires linvocation du service avec SOAP.

4.4- UDDI: Universal Description Discovery and Integration


4.4.1- Dfinition et description dUDDI Lobjectif primaire d'UDDI est de dcrire et dcouvrir des services Web. Le noyau dUDDI travaille avec la notion de "business registry", que est un service sophistiqu de noms et rpertoires. Plus prcisment, UDDI dfinit des structures de donnes et APIs pour publier les descriptions des services dans le registre et pour interroger le registre afin de chercher des descriptions publies. Les spcifications du registry UDDI ont deux buts principaux en ce qui concerne la dcouverte d'un service: le premier, soutenir les dveloppeurs dans la dcouverte d'informations sur les services. Le deuxime, permettre la liaison dynamique et en consquence habiliter les clients pour interroger le registre et obtenir des rfrences aux services dintrt. Un registre UDDI contient 3 types dinformation : Pages blanches : le rfrentiel comporte des informations sur les fournisseurs de services. Pages Jaunes : le rfrentiel comporte des critres de catgorisation de services. Pages vertes : le rfrentiel comporte des informations techniques (WSDL). 4.4.2- Application de lUDDI Par exemple on veut chercher les services Web offert par une entreprise en utilisant son nom ou son identificateur.

SUPCOM

-33 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Figure 3.10 : Fentre de recherche

Le rsultat de la recherche :

Figure 3.11 : Rsultat de la recherche

5- Cycle de vie dun service Web


5.1- Cycle de vie dutilisation

SUPCOM

-34 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Lexploitation un service Web, se fait travers un ensemble dtapes qui doivent tre excut dans lordre, le schma suivant prsente ce processus.

Figure 3.12 : Cycle de vie de lutilisation

5.2- Cycle de vie complet


Le cycle de vie dun service web se compose de 4 tapes qui doivent tre excut dans lordre : Etape 1 : Dploiement du service Web, Dpendant de la plate-forme (Apache : WSDD) Etape 2 : Enregistrement du service Web, WSDL : description du service, Rfrentiels : DISCO (local), UDDI (global). Etape 3 : Dcouverte du service Web. Etape 4 : Invocation du service Web par le client Les schmas suivant vont prsenter ces quatre tapes et les entits responsables de leur ralisation.

SUPCOM

-35 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

1-Dploiement

Figure 3.13 : Le Dploiement

2- Enregistrement

Figure 3.14 : Lenregistrement

3- Dcouverte

Figure 3.15 : La dcouverte

SUPCOM

-36 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

4- Invocation

Figure 3.16 : Linvocation

5.3- Exemple dun Web services


Prenons lexemple dun processus bon de commande, comprenant deux acteurs : un client et un fournisseur. Ce processus utilise deux services : un service de gestion des commandes gr par le fournisseur et permettant de traiter les demandes de devis et les bons de commande, et un service de validation des devis gr par le client et permettant de valider si le devis rpond bien aux attentes du client. Le scnario 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 ce devis (contraintes de cots, dlais de livraison, etc.). En cas dacceptation, le client envoie un bon de commande au service de gestion des commandes, qui lui transmet ensuite un acquittement.

SUPCOM

-37 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Figure 3.17 : Le droulement des tapes

6- Gestion de la scurit dans les services Web


Lorsque les donnes changes sont sensibles, il est ncessaire de mettre en place des mcanismes de scurit. Lobjectif est que des intrus ne puissent pas dtourner des informations prives, que la provenance des messages reus soit garantie, etc. La scurit pour la mise en place de communication inter-applicative regroupe en fait quatre concepts : La confidentialit : un tiers, mme sil intercepte le message, ne doit pas tre en mesure de comprendre les informations qui sont transportes. Lauthentification : lorganisme qui envoie le message doit pouvoir tre authentifi, afin de garantir que le message na pas t envoy par une tierce personne. Lintgrit des messages : permet de garantir que le contenu du message na pas t altr pendant le transport. La non rpudiation : par ce mcanisme, on sassure que lorganisme qui a envoy le message est bien celui qui la dit. Lexpditeur du message ne peut ainsi nier lavoir envoy.

SUPCOM

-38 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Il est dj possible de scuriser en partie les changes de donnes avec les Services Web au niveau du transport, en utilisant SSL (HTTPS), ce qui permet de garantir lauthentification et la confidentialit par encryptage du message. Toujours au niveau du transport, on peut utiliser un protocole dIBM : HTTPR HTTP Reliable, qui dfinit une surcouche de HTTP garantissant la rception du message par le destinataire et son intgrit.

7- Les points forts des services Web


7.1- Universalit
Les Services Web visent rsoudre un problme qui a fait couler beaucoup dencre et favoris la cration de nombreuses initiatives : linteroprabilit entre les applications disparates. Ces dernires annes, les entreprises se sont en effet rendues compte que la principale source de cots dans le dveloppement dune nouvelle application est son intgration lexistant. Les Services Web sont lapproche la plus simple qui ait t propose pour rsoudre ce problme majeur. Par son mcanisme simpliste, transport de messages XML sur http, les Services Web russissent l o dautres initiatives beaucoup plus complexes, telles que Corba, ont chou. Un autre point fort des Services Web est que les spcifications sont pousses par les acteurs forts du march : IBM, Microsoft, Sun et Bea, ainsi que par un organisme de normalisation, le W3C. Ils sont dj intgrs de nombreux produits : Websphere, Weblogic, .Net, etc. Cest srement la premire initiative qui met daccord le monde Java et le monde Microsoft !

7.2- Simplicit dutilisation


Un autre facteur de russite des Services Web est leur simplicit et leur utilisation des standards accepts par tous : HTTP et XML. La mise en place dune communication interapplicative simple ne doit pas prendre plus de deux jours de dveloppements en utilisant cette technologie !

7.3- Couplage lche des applications : simplification des contraintes durbanisation


Le troisime atout majeur des Services Web est la possibilit de coupler les applications de manire beaucoup plus souple quavec Corba, RMI ou DCOM. En effet, ces RPC permettent de mettre en place des collaborations entre objets distants. Rsultat, pour mettre en place une collaboration entre applications, il est ncessaire de faire collaborer les objets qui les composent.

SUPCOM

-39 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Figure 3.18 : Appel des mthodes via un RPC

Or ce mcanisme entrane un couplage fort des applications qui collaborent. Il est souvent ncessaire que la structure des donnes soit la mme des deux cts de la connexion. Les Services Web quand eux introduisent la notion de service : une application offre des fonctionnalits dautres applications, et on na plus se soucier de la structure interne de lapplication et des objets qui la composent. Les appels de mthodes au niveau objet sont la responsabilit du service, une sorte de Proxy entre lapplication cliente, et les objets de lapplication distante.

Figure 3.19 : Couplages des applications via le Web services

8- Le niveau de maturit des services Web


Les Services Web sont mrs pour une utilisation en intra-entreprise. SOAP et WSDL servent de base la communication inter-applicative. Peu de changements sont survenus entre la spcification SOAP 1.1 et SOAP 1.2, propose par le W3C. Les produits dIBM, Microsoft, BEA et autres diteurs intgrent dj cette technologie (notons quune API cliente de SOAP est mme disponible en natif sous Windows XP). Cependant, les Services Web ne sont pas encore mrs pour une utilisation en extra-entreprise (B2B). En effet, les mcanismes de scurit ne sont pas suffisamment dvelopps pour garantir la protection des donnes changes avec lextrieur. Il serait ncessaire de mettre en place des mcanismes propritaires plus difficilement maintenables. SUPCOM -40 -

Projet de Fin dtudes 2004-2005

Le modle Web Services

Quel que soit le cas dutilisation, il reste dfinir des architectures solides bases sur ces technologies. Pour les architectes, la vraie problmatique sera de structurer les applications en Services , les diffrents services ayant entre eux un couplage lche. Les spcifications ne donnent pour le moment aucune indication sur ces contraintes darchitecture.

SUPCOM

-41 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Chapitre

Comparaison entre les deux modles : OSA et Web Services

1- Introduction 2- Comparaison entre les deux architectures OSA et Web services 3- Couplage des deux modles

SUPCOM

-42 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Introduction
Les deux modles OSA et Web services, ont un mme objectif : permettre un accs personnalis aux services multimdia adapts au terminal utilis. Cependant, ces deux architectures de services NGN diffrent dans leur architecture. Dans ce chapitre, nous effectuerons une comparaison entre les deux architectures dcrites dans les chapitres prcdents. Il est important de voir les points communs et les points de diffrences entre les terminologies adoptes dans les deux contextes. Parlay Environment Service Interface Service Object Application Service Supplier Service Service Requestor (Application) Service Provider Web Service Environment Web Service

En outre, les proprits de service du Parlay et le service de description des services Web sont des concepts semblables.

1- Comparaison des fonctions prsentes dans chaque architecture


Le tableau suivant dcrit les fonctions principales dans les deux architectures et identifie les entits qui les fournissent. Fonction Service denregistrement Recherche dun service Ngociation Publication Invocation Authentification Autorisation Parlay/OSA Framework Framework Framework Publication directe Framework Framework Framework Web services Publier publish Recherche find Pas dfini Service de description Service de dfinition dinterface Pas dfini Pas dfini

Du tableau suivant nous pouvons remarquer: Dans Parlay/OSA, le Framework fournit un seul point d'entre et le support O&M est partag par les Services; dans Web Services, ces fonctions sont implmentes dans chaque service. Parlay/OSA supporte seulement une directe publication de l'interface du service. Dans Parlay/OSA, le Framework est responsable de la correction provisionnelle du Service aux applications. De plus, le Framework a des obligations vers le Service pour assurer l'accs correct au Services demand par l'application. SUPCOM -43 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Dans Web Services, Web Service Registry n'a aucune obligation vis vis au Web Service Provider et Web Service Requestors. Dans Parlay/OSA, une application doit contacter le Framework pour avoir la rfrence d'un Service. Cette rfrence est valide seulement pour la dure d'une session, et seulement pour les applications bien appropries qui peuvent apporter une rfrence d'un Service. Dans Web Services, accdez au Web Service Registry est facultatif.

2- Comparaison des interfaces dfinies dans chaque architecture


Pour comparer les interfaces Parlay/OSA et Web Services, nous pouvons analyser les interactions entre Applications/Services et ressources du rseau. En particulier c'est important de considrer : Les diffrentes mthodes pour activer un service ; Les types d'interactions entre les capacits du rseau et les applications.

2.1- Parlay/OSA
Les mthodes possibles pour activer l'excution d'un service incluent : 1. l'utilisateur, travers les protocoles de rseau (par exemple DTMF, SIP, etc.), cre une demande. Le rseau trait la demande et le contrle du service passe une application qui excute le service et ordonne les ressources du rseau pour excuter la demande de l'utilisateur. 2. un vnement survenu dans le rseau (par exemple changement d'emplacement de l'utilisateur, arrive d'un message, etc.) produit une notification l'application qui excute le service qui utilise quelques ressources du rseau ou produire le contenu pour l'utilisateur. 3. l'utilisateur, travers les protocoles Internet (par exemple HTTP, WAP, RMI), invoque un service (par exemple un service Internet). Pendant son excution le service peut faire des demandes rseau (par exemple, dtecter l'emplacement de l'utilisateur).

SUPCOM

-44 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Figure 4.1 : Les diffrentes actions dun service selon larchitecture Parlay/OSA

La capacit du rseau est dtermine par les vnements asynchrones provenant du rseau. Par consquent, un service qui doit avoir le maximum de contrle du rseau doit avoir le contrle de la plupart de ses vnements et changements d'tat. Une manire de satisfaire ce besoin est d'organiser les interactions entre les services et le rseau dans les transactions. Une transaction est employe pour crer un contexte pour corrler et traiter les interactions lies la mme session de service : une transaction pourrait consister en une commande initiale ou vnement avec plusieurs rponses. En outre, la rception de quelques rponses pourrait dpendre des "ractions humaines" (par exemple rpondre/ne pas rpondre un appel), avec des intervalles de temps imprvisibles entre la demande et les messages de rponse. Les services offerts par Parlay/OSA sont dfinis en considrant la dfinition des protocoles de tlcommunication. Bien qu'une des conditions des services de Parlay/OSA soit l'abstraction des mcanismes implments dans le rseau (par exemple, des protocoles ou des ressources spcifiques du rseau), les services de Parlay/OSA permettent un contrle de la capacit du rseau en dtectant la plupart des vnements. Par consquent, les services de Parlay/OSA sont dfinis en tenant compte de l'importance de traiter les vnements du rseau lancs par des applications asynchrones. En outre, les interfaces de service de Parlay/OSA sont dfinies selon une approche transactionnelle : L'change des messages et de leur traitement est (par exemple, les requtes/vnements d'un appel sont manipuls par des exemples spcifiques de l'interface fournie par l'objet de service et par l'application). Le traitement d'une demande a pu produire un ou plusieurs messages de rponse, probablement fournis d'une manire asynchrone.

SUPCOM

-45 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Selon leurs caractristiques, les services de Parlay/OSA dfinissent des composants de service orients aux ralisateurs avec la connaissance du comportement "abstrait" des capacits du rseau et cela peut exploiter le contrle totale des capacits du rseau.

2.2- Web services


Les services Web sont souvent employs dans un modle d'interaction requte/rponse. L'information dans le message est oriente service et non pas ressource. Par consquent, dans beaucoup de cas les demandes de service sont rsolues dans une simple interaction, sans utiliser des rponses intermdiaires ou des messages multiples corrls dans une transaction simple. En outre, dans ce modle d'interaction, les interactions sont lances par une application envoyant une demande un service. ce moment, les caractristiques des services Web incluent des conditions pour prciser le modle d'interaction, mais les spcifications pour mettre en application des conditions ne sont pas encore indiques. Les mcanismes pour supporter des conditions peuvent tre dfinis dans le contexte des protocoles, tels que SOAP, et ce mcanisme a t dfini pour WSDL/SOAP dans le contexte des interfaces des services web. Selon leurs caractristiques, le modle d'interaction requte/rponse fournit un modle simple d'interaction qui a une communaut large de ralisateurs. Cependant, il ne fournit pas le contrle et la scalabilit des modles asynchrones d'interaction. Ce modle est bien convenu aux services viss, aux outils de dveloppement de niveau lev ou aux dveloppeurs non-telecom, tels que les fournisseurs des services Web, avec moins d'interactions entre l'application et le service.

Figure 4.2 : Les diffrentes interactions dans le modle Web services

3- Degr de dpendance de chaque modle vis--vis du rseau


Le modle OSA est orient softswitch, qui, est le nud central de la couche contrle, et le passage obligatoire pour accder aux services, via linterface OSA. SUPCOM -46 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Et donc le modle OSA semble plutt adapt aux services fortement dpendants des fonctions de la couche Contrle du rseau (exemple : demande dinformation sur la localisation, ou sur les caractristiques du terminal, etc.). Alors que le modle Web Services, prconis par le W3C, est, comme son nom lindique, bas sur des technologies Web dont larchitecture est distribue. Linitiation des sessions est prise en charge par le protocole SIP (Session Initiation Protocol). La couche dadaptation, ncessaire pour laccs aux services, est prise en charge par un ensemble de protocole Web, tels que XML, SOAP, WSDL et UDDI. Et donc, le modle web services est plutt adapt aux services relativement transparents au rseau (exp : communication universelle entre terminal et serveur, ou entre terminaux, ou entre serveurs, une fois la connexion rseau tablie entre les deux entits). Il sappuie sur des concepts dj anciens dinformatique distribue. Son introduction influe essentiellement la couche services et dans une moindre mesure les terminaux, mais peu le rseau. Cest ce qui explique quil est dj mis en uvre dans le domaine Internet, et pourra aisment tre largi aux autres domaines. Contrairement au modle OSA qui sera plus long et difficile mettre en uvre du fait de sa forte dpendance du rseau. Il devrait avoir vocation se dvelopper avec lessor des rseaux et services UMTS. A priori, ces deux modles ne sont pas concurrents mais complmentaires. On peut en effet imaginer des applications mixtes bases sur le modle Web services mais faisant appel pour certains services des requtes de type OSA.

4- UDDI vs Framework
Le modle de services Web est cens tre une sorte despace global o plusieurs (probablement des milliers) de diffrents fournisseurs de services enregistrent et fournissent leurs services. cet gard UDDI agit principalement comme un annuaire global, cest dire : UDDI stocke des donnes appartenant aux diffrents fournisseurs. UDDI est une entit indpendante. D'autre part, le modle Parlay/OSA s'occupe du rapport entre un oprateur et un certain nombre de tiers parties. Le Framework agit en tant quun point d'accs pour diffrents services, mais tous appartiennent au mme "fournisseur" (l'oprateur). Ce modle implique ce qui suit : Le Framework stocke des donnes appartenant un seul fournisseur. Le Framework appartient au fournisseur ce qui explique galement le fait que le Framework dpend beaucoup des SCSs qu'il soutient. En consquence, dans la plupart des cas l'oprateur est forc de maintenir les SCSs dans le mme domaine du Framework.

5- Comment peuvent-ils converger ?


La comparaison met l'accent sur le fait que la solution de Parlay fournit une solution uniforme pour s'ouvrir aux tiers partie d'une manire scuris et bien contrl. En particulier, le Framework

SUPCOM

-47 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

joue un rle central en mettant en application des fonctions de scurit et de gestion, ces fonctions sont partages par diffrentes interfaces de service. D'autre part le modle de Parlay apparat beaucoup plus complexe que les Web services, qui refltent galement les diffrences entre les modles rigides des tlcommunications et les modles flexibles d'Internet. Dans ce paragraphe, nous allons montrer quil est possible de combiner les deux modles : OSA et Web services pour avoir des scnarios possibles de convergence. Le schma suivant illustre la solution propose par le groupe Parlay X, cette solution est larchitecture de base qui va donner naissance plusieurs configurations possibles.

Figure 4.3 : Larchitecture propose par le groupe Parlay X

Dans la suite, nous allons prsenter un scnario possible de convergence qui vise l'introduction des fonctions du Framework dfinit par le groupe Parlay dans le modle Web services.

SUPCOM

-48 -

Projet de Fin dtudes 2004-2005

Comparaison OSA-Web Services

Le principe est le suivant : lapplication utilisera Web services pour la dcouverte et linteraction avec le rseau et elle ne va pas voir limplmentation du Gateway OSA. Les informations publies dans le registre du Web services vont donner lapplication les informations ncessaires pour la connexion avec le Gateway Web services. Ce dernier est attach au Gateway OSA via une interface OSA. Afin d'accder une ou plusieurs ressources du rseau fourni par un oprateur, l'application doit agir avec le Framework, via les interfaces des services web. Les interfaces permettant d'accder au Framework et les ressources du rseau doivent tre prsentes dans une version simplifie par le groupe de travail Parlay. Cette solution laissera le mme modle et la mme solution architecturale dfinis par Parlay dans un contexte de Web Services.

Figure 4.4 : Scnario du convergence Du Web services OSA

6- Conclusion
On peut conclure que ces deux modles ne sont pas concurrents mais complmentaires. Puisque plusieurs applications mixtes bases sur le modle Web services mais faisant appel pour certains services des requtes de type OSA. Suite cette comparaison entre les deux modles de cration de services OSA et Web services, et grce aux nombreux avantages du web services par apport au modle OSA et de la tendance des chercheurs a opt vers lutilisation du modle Web Services. Nous allons choisir ce modle pour la cration du prototype de cration de services.

SUPCOM

-49 -

Projet de Fin dtudes 2004-2005

Prototype

Chapitre

Dveloppement dun prototype pour la cration de nouveaux services

1- Prsentation de lenvironnement et de loutil de travail 2- Dveloppement des diffrentes tapes du prototype 3- Analyse des Rsultats

SUPCOM

-50 -

Projet de Fin dtudes 2004-2005

Prototype

1- Les diffrentes plates formes existantes


Malgr quun web services se dfinisse dune faon unique comme tant un composant programm dans n'importe quel langage et permettant aux deux plates-formes distantes (le poste d'un utilisateur ou un serveur) de dialoguer ensemble, plusieurs plates formes existent dans ce domaine. Chaque acteur propose une solution diffrente, mais toutes ces implmentations sont inter oprables, c'est--dire que les services des uns sont utilisables par les autres. Parmi les leaders de ce domaine nous pouvons citer le groupe Microsoft avec sa solution .Net et J2EE qui regroupe les organisations suivantes : Sun, IBM, etc.

1.1- Prsentation de la plate-forme J2EE


Java 2 Entreprise Edition (J2EE) offre une solution complte de dveloppement d'applications Internet. Cette spcification intgre des API qui sont responsables de la partie charge de l'interface avec l'utilisateur. La plateforme J2EE est essentiellement un environnement fournissant une infrastructure d'excution pour faire tourner nos applications. Un des avantages majeurs de J2EE est quil fait abstraction de l'infrastructure d'excution. En effet, J2EE spcifie les rles et les interfaces pour les applications, ainsi que l'environnement d'excution dans lequel les applications sont dployes. Ceci permet aux dveloppeurs d'application de ne pas avoir reprogrammer les services d'infrastructure.

1.2- Prsentation de la plate-forme .NET de Microsoft


.Net fut prsent par Bill Gates en Juillet 2000 lors du Congrs des dveloppeurs professionnels, La premire version .NET a t rendue publique le 15 janvier 2002. Elle a t dfinit par Microsoft comme tant " une plate-forme pour la nouvelle gnration des web services. Elle vise simplifier la vie de l'utilisateur en lui fournissant des services intgrs, accessibles depuis tous ses priphriques, tout moment et en tout lieu. La plate-forme .NET est un moyen simple de normaliser la coopration des services logiciels entre eux (services Web), quelle que soit leur localisation, leur implmentation technique, qu'ils soient internes ou externes, existants ou inventer. " En ce sens, .NET reprsente l'adaptation de Microsoft de ce que nous appelons web services.

2- Pourquoi la plate-forme .NET pour dvelopper notre prototype


Mme si les responsables informatiques demeurent encore prudents l'gard de .NET, la nouvelle plate-forme de dveloppement de Microsoft dispose d'atouts pour s'imposer. Elle a t conue prcisment pour rpondre aux problmes dintgration. Microsoft, mise sur les Web Services, ensemble de spcifications et mcanismes qui formatent les donnes selon une norme afin de les rendre comprhensibles par dautres applications. .NET est une plate-forme fonde totalement sur des standards. Par exemple, les donnes sont transmises entre les processus au format XML. Elle intgre aussi le protocole SOAP et grce cette intgration, n'importe quel

SUPCOM

-51 -

Projet de Fin dtudes 2004-2005

Prototype

client peut accder facilement au service quil demande et cela indpendamment du systme d'exploitation. Suite cette prsentation des nombreux avantages offerts par cet environnement de travail nous avons choisi la plate-forme .NET pour dvelopper, excuter et tester notre service web.

3- Pourquoi le langage de programmation Java


Java possde un certain nombre de caractristiques qui ont largement contribu son norme succs parmi ces caractristiques nous pouvons citer quil est indpendant de toute plate-forme, il est orient objet, c'est--dire chaque fichier source contient la dfinition d'une ou plusieurs classes qui sont utilises les unes avec les autres pour former une application. Il est sr puisque la scurit est une partie intgrante du systme d'excution et du compilateur. Java est aussi le langage le plus recommand pour crer des web services puisque il permet de gnrer des servlets, ces dernires sont des classes capables de sexcuter en mode requte rponse. Ces servlets vont jouer un rle trs important dans le dveloppement de notre prototype.

4- Notre objectif
Nous devons crer un prototype pour le dveloppement des web services, pour le faire, nous devons dfinir toutes les tapes ncessaires et les excuter dans lordre. Nous commenons par crer un simple web service, sur le quel nous allons appliquer notre prototype. Le test du prototype seffectuera en utilisant la plate-forme .NET, Nous terminons par analyser les rsultats de lexcution qui vont tre gnrs automatiquement par cet outil.

5- Modle de programmation de notre Web service


Notre modle de programmation comporte deux parties fondamentales : Cration d'un service Web : Lorsque nous dveloppons notre service Web, nous crons entre autre une application qui expose les fonctionnalits de ce service aux clients qui vont lutiliser. Accs un service Web : Lorsque nous voulons accder ce service, notre application cliente doit rechercher les fonctionnalits contenues dans ce service Web, y faire rfrence et lutiliser. Le client de notre service Web est une application base sur sue le protocole UDDI, puisque ce dernier va jouer le rle dun navigateur.

6- Les tapes de cration du prototype


Pour crer un prototype dun web services, nous devons se baser sur le cycle dutilisation de ce service. Un client demandant un service, va commencer par lancer une recherche dans une base de donnes appel UDDI, le service doit tre bien dfini dans cette base, nous devons aussi faire une description de lentit offrant ce service ainsi que des spcifications concernant les techniques utilises. La recherche va gnrer un rsultat si et seulement si le service existe quelque part dans un serveur web, une fois nous avons trouv le serveur hbergeant ce service, le

SUPCOM

-52 -

Projet de Fin dtudes 2004-2005

Prototype

client et le serveur vont se mettre daccord sur un format dappel grce un contrat appel WSDL, ce contrat va tre gnrer par le serveur hbergeant le service et donc ce dernier doit bien connatre les droits daccs que peut avoir un client, nous pouvons donc conclure quil faut ajouter la dfinition du service, la dfinition du client qui va exploiter ce service. Nous remarquons que grce au cycle dexploitation du web service (appel encore cycle dutilisation) nous pouvons dgager le cycle de dveloppement appel encore prototype dun web service. Le schma suivant illustre les diffrentes tapes de notre prototype.

Figure 5.1 : les tapes de cration du prototype

Une fois que ce prototype a t bien dfinit, il peut tre appliqu nimporte quel service. Dans notre application, nous dfinissons un simple service, auquel nous allons appliquer notre prototype.

6.1- Etape 1 : Dfinition et implmentation de la classe de service


D'abord, nous commenons par crer une simple interface permettant laccs au prototype. Cette interface permet aussi lutilisateur davoir des informations sur les diffrentes tapes du prototype. Ensuite, nous devons crire un programme en Java qui va mettre en application notre service. Ce programme est constitu dune simple classe nomm ConvertTemperature. Cette classe est un processus qui convertit les tempratures mesures en degrs Fahrenheit en degrs Celsius. Avant la dclaration de cette classe ConvertTemperature, nous devons ajouter deux importants attributs pour rendre notre classe conforme aux applications Web. Si nous attachons l'attribut Web Service notre classe Public, nous pouvons inclure des informations

SUPCOM

-53 -

Projet de Fin dtudes 2004-2005

Prototype

supplmentaires pour notre web service, et si nous attachons lattribut Web Method, notre classe va tre expose comme une partie du web service.

[WebMethod (Description="cette mthode convert la temprature en degrs Fahrenheit en une temprature en degrs Celsius.)] <@ WebService Language="java" Codebehind="Service .asmx.cs" Class = "Temp Convert.Service" %> L'attribut WebMethod doit s'appliquer chaque mthode publique qui est disponible comme partie du service Web. Et la directive @ WebService sert comme une dclaration de notre service et met en corrlation l'adresse URL du service Web et son implmentation, afin que lapplication puisse traiter les demandes de service Web XML et de renvoyer les rponses. Si la compilation ne gnre pas derreurs, une nouvelle interface souvre pour tester le bon fonctionnement de lapplication.

Figure 5.2 : Test de lapplication

En arrire plan, le test de lapplication ce passe comme suit : dans le navigateur saffiche cette adresse http : \\ localhost : 8080\web service1 ensuite la temprature en dFahrenheit prend la

SUPCOM

-54 -

Projet de Fin dtudes 2004-2005

Prototype

valeur 212, normalement le rsultat de la temprature en dCelsius sera affich. Aprs lexcution, Le service rpond en retournant la valeur convertie de la temprature dans le document 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 devons maintenant le mettre la disposition de tout le monde.

6.2- Etape 2 : Dploiement et description de la classe Java un serveur SOAP


Pour mettre notre application Web la disposition d'autres utilisateurs, nous devons la dployer sur un serveur Web accessible aux clients que nous souhaitons prendre en charge. Aprs le dveloppement de notre classe Java nous avons besoin de transformer cette classe Cest-dire nous allons associer ce service un serveur web. Pour dployer le service Web sur un autre serveur que le serveur de dveloppement, nous devons effectuer deux tapes : ajouter un projet de configuration Web qui va copier le service du serveur de dveloppement au serveur de dploiement et dfinir un fichier appel descripteur de dploiement de service web, ce fichier porte lextension wsdd pour Web Service Deployment Descriptor. Loutil .NET nous permet de crer un serveur SOAP et dimplmenter la classe java dfinissant notre service ce serveur. A la fin de cette tape, ce serveur va hberger notre service, excuter les requtes du client et envoyer les rponses. Dans ce qui suit nous allons prsenter les tapes ncessaires pour effectuer le dploiement. Compilation de la classe de service Nous devons compiler la classe java du service que nous avons dfinit, lissu de cette compilation, nous devons avoir dans notre dossier de travail un nouveau fichier service1.class Dfinition de descripteur de dploiement La description de service dcrit les services disponibles ainsi que les mthodes d'interaction avec ces services. Sans description de service, il est impossible d'interagir par programme avec un service Web. Le descripteur de dploiement doit tre plac dans le mme dossier que le .class dfinissant le service, nous appelons ce descripteur deploy.wsdd son contenu va avoir la forme suivante : <deployment Xmlns= http://XML .net/Wsdd Xmlns: 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 -

Projet de Fin dtudes 2004-2005 Explications de ces diffrents lments Balise <deployment Xmlns= http://XML .net/Wsdd Xmlns: java= http://Xml .net/Wsdd/providers/java > de

Prototype

dbut

avec

attributs les espaces de nom des balises mise en uvre dans descripteur le

Le nom dinvocation 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 compile <parameter name = class Name value ConvetTemperature /> associe au service

<parameter name = allowed Methods value

/>

autorisation daccs au service

</service >

fin de la balise

service

</deployment >

fin de la balise

deployment

Activation du dploiement Le descripteur de dploiement doit tre maintenant pris en compte par le serveur pour raliser le dploiement du service. La ligne de commande est : Java org . asp.net . adminclient deploy . Wsdd Installation du service Nous avons, lors de ltape prcdente, demand au serveur dtre en mesure de traiter toutes les requtes SOAP correspondant notre service, cela signifie donc qu la rception dune

SUPCOM

-56 -

Projet de Fin dtudes 2004-2005

Prototype

requte HTTP-SOAP , le serveur pourra appliquer la mthode spcifie dans la requte une instance de la classe correspondante notre service. Cependant, pour que le serveur soit en mesure dutiliser la classe de notre service, il doit tre en mesure daccder lURL suivante : http://localhost:8080\webapp\asp.net\service1\converttemperature Le nom convert temperature correspond au nom du service que nous avons indiqu dans le descripteur de dploiement. Nous pouvons alors constater que notre service a t bien dploy sur le serveur, en ayant en retour la page HTML suivante :

Bonjour, cette page prsente un aspnet web service Cliquer sue le lien pour invoquer le service
Excution du service La dernire tape du dploiement consiste mettre en uvre notre service, pour lexcuter et obtenir la rponse SOAP correspondante, nous devons invoquer le service. Linvocation doit tre ralise de la faon suivante : http:// localhost : 8080/ asp.net/service? Methode=convert temperature&dFahrenheit = 40 Nous obtenons la rponse 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 arrire plan, pour lutilisateur, une simple interface saffiche et cache la complexit de ces tapes.

SUPCOM

-57 -

Projet de Fin dtudes 2004-2005

Prototype

Figure 5.3 : Dploiement du service

Ces tapes doivent sexcuter dans lordre : compilation de la classe du service, dfinition du descripteur, activation de dploiement, installation du service et linvocation du service. Suite la compilation, nous pouvons avoir soit un message derreur si un problme est survenu lors de lexcution de lopration, soit un message prcisant le succs de lopration.

Figure 5.4 : Message derreur

Figure 5.5 : Rsultat

SUPCOM

-58 -

Projet de Fin dtudes 2004-2005

Prototype

En tapant sur le bouton dfinir le descripteur , une nouvelle interface souvre prcisant les diffrentes informations concernant le service et que nous devons remplir.

Figure 5.6 : Dfinition du descripteur

Suite lactivation du dploiement, le rsultat peut tre soit un message derreur si un problme est survenu lors de lexcution de lopration, soit un message prcisant le succs de lopration. Suite linstallation du service, la page HTML de notre service souvre. Enfin, linvocation du service donne naissance une nouvelle interface qui va gnrer le rsultat de notre service.

Figure 5.7 : Linvocation du service

Le dploiement du service est ltape la plus importante dans le cycle de dveloppement dun web service, la fin de cette tape, notre service est cre et il ne reste que sa publication pour faciliter laccs.

6.3- Etape 3 : La publication du web service


La publication du service est lenregistrement des informations de ce service dans un registre nomm UDDI. LUDDI fournit un mcanisme pour annoncer et dcouvrir des Web services. Il

SUPCOM

-59 -

Projet de Fin dtudes 2004-2005

Prototype

contient des informations sur des entreprises et les services qu'ils offrent. Les caractristiques techniques sont habituellement dfinies en utilisant WSDL. Ce dernier dcrit ce qu'un Web service fait, et comment il communique, et o il est localis. Les informations dun service concernent : Le fournisseur du service : son nom, une petite prsentation, comment le contacter, etc ; Le service : son nom, type du service, quelques informations sur les technologies utilises, etc ; Binding Templates : li chaque service, reprsente une liste qui fournisse des informations sur o trouver le service et comment lemployer. Un Binding Templates peut contenir aussi le point d'accs pour accder au service et un indicateur sur la faon de lemployer. Pour effectuer donc cette publication et avant dajouter les informations propres de notre service, nous devons ajouter des informations sur le registre qui va contenir les dtails du service. Linterface suivante permet lutilisateur dajouter les informations appropries pour le service et le registre.

Figure 5.8 : La publication du service dans le registre UDDI

Si nous cliquant sur le bouton dtails du registre , une nouvelle interface saffiche, lutilisateur doit remplir les champs contenant le nom du registre, son adresse et un mot de passe permettant par la suite lutilisateur dajouter des informations dans ce registre ou de modifier son contenu. SUPCOM -60 -

Projet de Fin dtudes 2004-2005

Prototype

Figure 5.9 : Laccs au registre UDDI

Nous passons par la suite la publication de notre service en cliquant sur le bouton publier , une nouvelle interface saffiche :

Figure 5.10 : La publication du registre

Une fois que ce tableau a t rempli et que la publication est acheve avec succs, un consommateur de Web service peut avoir accs des informations sur notre service, il suffit quil questionne l'enregistrement d'UDDI pour trouver les descriptions WSDL et pour dterminer comment employer le Web service. Arrivant ce stade, nous devons vrifier si le service a t bien publi dans le registre UDDI, il suffit de tester la rponse du registre UDDI. Nous pouvons avoir deux rsultats, soit un message prcisant que le service nest pas trouv, soit un message donnant des informations sur le service.

SUPCOM

-61 -

Projet de Fin dtudes 2004-2005

Prototype

Figure 5.11 : Message derreur

Si la recherche gnre un rsultat cela veut dire que notre web service a t publi correctement dans le registre UDDI, sinon la publication a rencontr des problmes au cours de son excution et il faut renregistrer notre service.

6.4- Etape 4 : La dcouverte du service


La dcouverte de service Web XML est le processus utilis par un client pour rechercher un service Web et obtenir sa description, cest dire le processus qui consiste localiser et dcouvrir, un ou plusieurs documents connexes dcrivant un service Web particulier l'aide du langage WDSL (Web Services Description Language). C'est grce ce processus que les clients d'un service Web XML apprennent que ce service existe et o trouver son document de description. ce stade nous avons effectu lenregistrement de notre Web service dans UDDI. Maintenant nous pouvons employer l'enqute d'UDDI pour la dcouverte du service. Lapplication de la recherche UDDI montre comment employer l'enqute UDDI. Nous commenons l'application par appeler le make_uddi et le run_uddi de run.bat : commande partir de l'annuaire d'instruction dUDDI. Ces deux commandes excutent lapplication permettant davoir des informations sur nimporte quel Web service condition quil soit publi dans lUDDI. Voici la structure d'un document de dcouverte :

<? 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 droulent en arrire plan, mais pour lutilisateur il doit remplir un tableau qui cache la complexit de ces tapes :

SUPCOM

-62 -

Projet de Fin dtudes 2004-2005

Prototype

Figure 5.12 : La dcouverte du service

7- Conclusion
Dans ce chapitre, nous avons prsent les bases de la programmation suivant le modle de cration de nouveaux services dans les rseaux NGN, Web service, afin de dcouvrir les grands principes de cration de ces services. Notre prototype est un ensemble dinterfaces successives faisant appel aux diffrentes tapes faire pour la cration dun service suivant le model Web service. Ces tapes doivent tre excutes dans lordre, et le passage dune tape lautre ne peut se faire que lorsque ltape prcdente est acheve avec succs. Ce prototype est indpendant du service que nous voulons crer, et donc chaque utilisateur peut lappliquer son service pour le rendre conforme au modle Web service. Mais ce prototype est dpendant de la plate forme .NET puisque il se base sur les technologies intgres en elle tel que SOAP, WSDL et UDDI.

SUPCOM

-63 -

Projet de Fin dtudes 2004-2005

Conclusion gnrale

Conclusion gnrale

Dans le cadre de ce projet, nous avons contribu la ralisation dun prototype pour la cration de services web, lobjectif dun tel prototype est de rendre notre application conforme au modle web services. Dans la premire partie de ce travail, nous avons prsent les concepts de base du rseau NGN avant de se limiter la couche service et de dtailler les deux architectures de cration de services, larchitecture OSA et larchitectures Web services. Dans la deuxime partie, nous avons compar ces deux modles et suite la simplicit et la flexibilit du modle Web service, nous avons choisi ce dernier pour dvelopper notre prototype. Dans la troisime partie, nous nous sommes intresss la conception et la ralisation du prototype, dans ce contexte, nous avons prsent tout dabord lenvironnement de travail .NET qui est une plate-forme fonde totalement sur des standards comme XML, SOAP, ensuite nous avons enchan avec les diffrentes tapes pour la cration de notre prototype, de limplmentation du service jusqu sa publication. Nous avons aussi cr des interfaces simples pour les utilisateurs de ce prototype, ces interfaces vont cacher la complexit de droulement de ces tapes lutilisateur. Ce prototype reste volutif et modulables en prvision dextensions futures.

SUPCOM

-64 -

Projet de Fin dtudes 2004-2005

Bibliographie

Bibliographie

[1] Etude technique, conomique et rglementaire de lvolution vers les rseaux de nouvelle gnration (NGN, Next Generation Networks). Etude ralise par le cabinet Arcome pour le compte de l'Autorit de rgulation des tlcommunications. [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 /HewlettPackard [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 -