Soutenance mémoire
Depuis son émergence, l‟informatique est devenue un outil très imposant et important sur le monde des télécommunications. Son évolution perpétuelle oblige les ingénieurs de mettre à jour leurs connaissances et d‟ajouter des améliorations à leurs œuvres tant au niveau ergonomique et maniabilité qu‟au niveau sécurité, interopérabilité, mobilité, ou autres. Le monde des recherches s‟engage vers des luttes et explorations acharnées pour mieux trouver des meilleurs et innovants résultats. Certains se sont avérés plus utiles, d‟autres non, surtout après avoir été normalisés par un organisme de standardisation national ou international.
Les « web services » sont l‟uns de ces élus qui ont connu, connaissent et connaîtront une grande célébrité dans le monde des échanges et de stockage de données numériques. En effet, pour pallier au problème d‟interopérabilité entre plateformes ou entre langages de programmation, se basant sur les standards d‟Internet et de la technologie XML, la technologie « web service » est donc née. Alors, elle aura encore un bon avantage sur les technologies propriétaires utilisant des IDL (Interface Definition Language) pour assurer l‟interopérabilité, comme CORBA. Elle a permis à la naissance de nouvelles technologies dérivées pour de fines utilisations plus adaptées aux besoins des sociétés hi-Tech.
GENERALITE SUR LES ARCHITECTURES SYSTEMES
Modèle général
Client
Le client envoie une demande pour désigner un service ou une ressource particulière du serveur (serveur d‟application ou de données). Un utilisateur, humain ou application, peut accéder au système via l‟interface utilisateur (UI).
Serveur
Le serveur détient les ressources partagées, il reçoit la requête du client et lui fournit les ressources demandées (données, services, matériels, etc.) en retour. En général, un serveur peut être sollicité par plusieurs clients. De nombreuses requêtes clientes en même temps pourraient provoquer une montée en charge et, donc, une déstabilisation du serveur en question.
Applications
Les applications constituent en général le siège de la partie « traitement ». Si le client effectue un traitement important, on parle de client lourd, dans l‟autre cas on a un client léger. Dans le cas où les applications sont bien séparées du serveur de données on peut utiliser un autre serveur qui est le « serveur d‟application ».
Données
Les données sont généralement accessibles en utilisant, par exemple, des Systèmes de Gestion de Base de Données Relationnelles ou Objet (SGBDR ou SGBDO) souvent au travers des interfaces comme JDBC (Java) ou ODBC (Microsoft). Et ce, la plupart du temps, par le biais de SQL (Structured Query Language) qui est, par définition, un langage structuré de requête. Pourtant, cela n‟empêche pas l‟accès aux données par une autre façon, si on a des fichiers brutes ou on utilise le XML (eXtensible Mark-up Language).
Interfaces utilisateurs (UI)
Les UI sont en général des GUI (Graphic UI) si l‟utilisateur est un être humain, et ils évoluent rapidement en devenant toujours plus attrayants. Mais, il s‟avère même que l‟utilisateur soit une application (ex : dans le cas du « web service »); il ne sera donc plus nécessaire d‟utiliser des GUI mais en restant sous forme de socket (IP et numéro de port) par exemple, ou encore sous une autre forme bien établie et suivant une règle bien déterminée.
Middleware
C‟est un « élément intermédiaire » noté comme classe de logiciels assurant l‟intermédiaire entre les applications et le transport des données par les réseaux. Autrement dit, il a pour rôle d‟assurer la communication entre les différents composants d‟une application répartie. Ce dialogue est basé sur un protocole applicatif commun, défini par l‟API du middleware.
D‟après le Gartner Group : « le middleware est une interface de communication universelle entre processus. Il représente véritablement la clef de voûte de toute application client-serveur. » Un middleware [22] est susceptible de fournir les services suivants :
Conversion : service prise en charge par la FAP (« Format And Protocol » ou Protocoles de Communication et Formats de Données), utilisé pour la communication entre machines mettant en œuvre des formats de données différents.
Adressage : utilisé pour identifier le serveur sur lequel est localisé le service sollicité afin d‟en savoir le chemin d‟accès, parfois en faisant appel aux services d‟un annuaire.
Sécurité : permet d‟assurer la sécurité et la confidentialité des données par des techniques d‟authentification et de cryptage d‟information.
Communication : permet de garantir une transmission de message sans altération entre deux systèmes en gérant la connexion au serveur, la préparation de l‟exécution des requêtes, la récupération des résultats et la déconnexion de l‟utilisateur.
L‟objectif du middleware est donc d‟unifier (pour les applications) l‟accès et la manipulation de l‟ensemble des services disponibles sur le réseau. L‟utilisation de ces services est devenue presque transparente, car la complexité des échanges entre applications est masquée. De plus, il y a élévation du niveau des API (interfaces de programmation au niveau applicatif) utilisées par les programmes, ce qui rend une application C/S moins complexe.
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE 1 GENERALITE SUR LES ARCHITECTURES SYSTEMES
1.1 Introduction
1.2 Modèle général
1.2.1 Présentation
1.2.2 Client
1.2.3 Serveur
1.2.4 Applications
1.2.5 Données
1.2.6 Interfaces utilisateurs (UI)
1.2.7 Middleware
1.3 Architectures applicatives
1.3.1 Niveaux d’abstraction d’une application
1.3.2 Schéma du Gartner Group
1.3.3 Architecture un tiers : Client passif
1.3.4 Architecture deux-tiers : C/S de données
1.3.5 Architecture trois-tiers : C/S distribué
1.3.6 Architecture n-tiers : C/S à objets distribués (Système réparti)
1.4 Architecture Orientée Services (SOA)
1.4.1 Evolution vers les applications orientées services
1.4.2 Notion de services
1.4.3 Eléments et opérations principaux dans un SOA
1.4.4 Contrat de service
1.4.5 SOA et Web Service
1.5 Conclusion
CHAPITRE 2 PANORAMA SUR LES WEB SERVICES
2.1 Introduction
2.2 Nécessité et utilité des Web Services
2.2.1 Evolution du Web (version 1 2 et 3)
2.2.2 Définition d’un « web service »
2.2.3 Atouts des web services
2.3 Types de « web services »
2.3.1 WS-REST
2.3.2 WS-SOAP
2.4 Les fondements du Web Service (de type SOAP)
2.4.1 Architecture de base des web services
2.4.2 XML ou eXtensible Mark-up Language
2.4.3 SOAP ou Simple Object Access Protocol
2.4.4 WSDL ou Web Services Description Language
2.4.5 UDDI ou Universal Description, Discovery and Integration
2.5 Conclusion
CHAPITRE 3 INFRASTRUCTURE DES WEB SERVICES, SPECIFICATIONS ET IMPLEMENTATIONS
3.1 Introduction
3.2 Fiabilité des échanges
3.2.1 Problématiques et enjeux
3.2.2 Echange fiable
3.2.3 Fiabilité des échanges pour les web services
3.3 Sécurité
3.3.1 Problématiques et enjeux
3.3.2 Sécurisations envisageables
3.3.3 Sécurisation des web services
3.4 Transaction
3.4.1 Problématiques et enjeux
3.4.2 Transaction atomique
3.4.3 Transactions et activités pour les web services
3.5 Processus métiers (Business processes)
3.5.1 Problématiques et enjeux
3.5.2 Gestion des processus métiers pour les web services
3.6 Les spécifications standards « WS-* »
3.6.1 Fiabilité : WS-Reliability, WS-ReliableMessaging
3.6.2 Sécurité : WS-Security, WS-Trust, WS-Federation, etc
3.6.3 Transactions et activités : WS-Transaction, WS-Coordination, etc
3.6.4 Chorégraphie et orchestration : WS-CDL, WS-BPEL
3.6.5 Autres
3.7 Les implémentations les plus connues
3.7.1 Entre J2EE et .Net : le projet WSIT
3.7.2 Implémentations du JAX-WS (Java API XML-based Web Services)
3.8 Conclusion
CHAPITRE 4 CAHIER DES CHARGES ET ETUDE CONCEPTUELLE
CONCLUSION GENERALE
