TEST DE MONTÉE EN CHARGE D’UNE PLATEFORME DE TRANSACTIONS BANCAIRES

Modèle général

Client Le client envoie une demande pour solliciter un service ou une ressource particulière du serveur (serveur d’application ou serveur de données). Un utilisateur ou un client humain ou applicatif peut accéder au serveur ou aux ressources via une interface utilisateur.
Serveur Le serveur détient les ressources à partager, c’est lui qui reçoit la requête du client et lui fournit les ressources demandées (données, services, matériels) moyennant l’authentification et les privilèges nécessaires. En général, un serveur peut être sollicité par plusieurs clients.
Application C’est le siège de la partie traitement. Le traitement peut se répartir entre le client et le serveur. Si un client effectue un traitement important, on parle de client lourd, dans l’autre cas on a ce qu’on appelle un client léger. Dans le cas où les applications sont bien séparées du serveur de données, on utilise un autre serveur appelé serveur d’application.
Données On accède généralement aux données via des systèmes de gestion de base de données relationnelles (SGBDR), objet (SGBDO).
Interface utilisateur Les UI (User Interface) sous forme de GUI (Graphic User Interface) évoluent rapidement en devenant de plus en plus attrayant.
Middleware C’est un élément intermédiaire tel que des classes de logiciel assurant l’intermédiaire entre les applications et le transport de données via le réseau. Il a pour rôle d’assurer la communication entre les différents composants d’une application répartie : présentation, application et données. L’objectif du middleware est d’unifier, pour les applications, l’accès et la manipulation de l’ensemble des services disponibles. L’utilisation de ces services est devenue presque transparente car la complexité des échanges entre application est masquée.

Les consommateurs de services

             Ils invoquent les services offerts par les fournisseurs. Il peut s’agir soit d’applications clientes (comme un tableau de bord sur un ordinateur de bureau, indiquant l’évolution des indices boursiers provenant en temps réel d’un WS) ou bien soit de services qui s’appuient sur la fonctionnalité d’un autre fournisseur de service (comme un WS d’agrégation des indices boursiers, contactant les services de plusieurs bourses afin de calculer des indicateurs agrégés pour les publier auprès des clients).

XML

              XML est une famille de technologies développées au sein du W3C. XML se concentre sur les données, contrairement à HTML (HyperText Markup Language), par exemple, qui se focalise sur la présentation. Il permet ainsi de transformer Internet d’un univers d’information et de présentation de sites Web statiques à un univers Web programmable et dynamique, centré sur les données. Il est indépendant des plateformes informatiques, lisible par l’humain mais est destiné à être lu par la machine. Il est flexible en ce sens qu’on peut définir d’autres langages à partir d’XML. Il permet aux données d’êtres universellement navigables. Sa versatilité a donné naissance à une multitude de standards XML. ZapThink en a dénombré plus de 450, organisé en quatre catégories : les spécifications XML de bases, les spécifications orientées message, les spécifications orientées document et les vocabulaires de communauté. Selon cette typologie, les WS se retrouvent dans la section « spécifications orientées message ».

Entête : SOAP header

                C’est une partie facultative qui permet d’ajouter des fonctionnalités à un message SOAP de manière décentralisée sans agrément entre les parties qui communiquent. Toutefois, si un en-tête est présent, il doit être le premier élément qui apparaît dans l’enveloppe SOAP. L’en-tête d’un message SOAP commence avec la balise <soap:Header> et se termine avec la balise </soap:Header>. Trois attributs associés à l’en-tête SOAP peuvent être utilisés :
– soap:mustUnderstand : cet attribut prend la valeur 1 ou 0. La valeur 1 signale que le récepteur doit reconnaître l’information présente dans l’en-tête et que son traitement est obligatoire. La valeur 0 indique que l’en-tête peut être ignoré par le récepteur.
– soap:role : sert à indiquer le destinataire SOAP auquel un bloc d’en-tête SOAP particulier est destiné.
– soap:relay : est utilisé pour indiquer si un bloc d’en-tête SOAP ciblé sur un récepteur SOAP doit être réacheminé (relayé) s’il n’est pas traité.
<soap:role> et <soap:relay> sont utilisés conjointement par l’ensemble des nœuds SOAP intermédiaires qu’un message SOAP doit traverser pour arriver au destinataire final.

URL

               Les URL décrivent l’emplacement spécifique d’une ressource sur un serveur particulier. Ils nous disent exactement comment aller chercher une ressource à partir d’un emplacement fixe et précis. La plupart des URL suivent un format standardisé formé de trois parties principales :
– la première partie d’une URL est appelée scheme, elle décrit le protocole utilisé pour accéder à la ressource par exemple le protocole HTTP (http://)
– la deuxième partie donne l’adresse Internet du serveur
– le reste nomme une ressource sur le serveur Web
Aujourd’hui, presque chaque URI est une URL.

Sécurité des WS de type SOAP

              Les WS communiquent via des messages SOAP. De ce fait, l’altération des messages constitue la principale menace à laquelle doivent faire face les concepteurs de WS. D’une part, lorsqu’un WS envoie un message à un autre service, la confidentialité du message doit être assurée si celle-ci est requise. Si nécessaire, le destinataire du message doit être en mesure de déterminer que le message provient effectivement de l’émetteur qui le revendique, et qu’il n’a subi aucune altération. D’autre part, l’autorisation d’accès est un défi de taille puisque les WS peuvent permettre l’accès à distance à des ressources souvent très importantes : base de données bancaires, base de données de compagnie d’assurance, etc. Pour tenter de répondre à ces besoins de sécurité, une panoplie de spécifications de sécurité, pour la plupart basées sur XML, ont vu le jour. Il s’agit entre autres de XMLSignature, XML-Encryption, WS-Policy, WS SecurityPolicy, WS-Trust, XKMS (XML Key Management Specification), SAML (Security Assertions Markup Language), XACML (eXtensible Acces Control Markup Language), etc. Ces spécifications sont complémentaires, et contribuent collectivement à atteindre des objectifs de sécurité. L’arrivée de la spécification de sécurité WS-Security a grandement améliorée la sécurité des WS. Cette spécification offre une infrastructure de sécurité assez complète en se basant exclusivement sur les autres spécifications de sécurité.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 : GENERALITES SUR LES ARCHITECTURES SYSTEMES
1.1. Introduction
1.2. Modèle général
1.2.1. Client
1.2.2. Serveur
1.2.3. Application
1.2.4. Données
1.2.5. Interface utilisateur
1.2.6. Middleware
1.3. Architectures applicatives
1.3.1. Niveau d’abstraction d’une application
1.3.1.1. Niveau de présentation
1.3.1.2. Niveau de traitement
1.3.1.3. Niveau de gestion de données
1.3.2. Architecture 1-tiers : application à client passif
1.3.3. Architecture 2-tiers : architecture client-serveur de données
1.3.4. Architecture 3-tiers : architecture client-serveur distribuée
1.3.5. Architecture n-tiers : système réparti
1.4. Architecture orientée services
1.4.1. Notion de services
1.4.2. Contrat de service
1.4.3. Les différents rôles
1.4.3.1. Les fournisseurs de services
1.4.3.2. Les consommateurs de services
1.4.3.3. Les médiateurs
1.4.4. Avantages
1.4.5. Conception
1.4.5.1. L’agrégation de services
1.4.5.2. La dissémination de services
1.5. Conclusion
CHAPITRE 2 : LA TECHNOLOGIE DES WEB SERVICES
2.1. Introduction
2.2. Définition
2.3. Fonctionnement
2.3.1. Service Provider
2.3.2. Service Requester
2.3.3. Annuaire
2.4. Description en couche des Web services
2.4.1. Couche transport
2.4.2. Couche communication
2.4.3. Couche description de service
2.4.4. Couche publication de service
2.5. Les technologies
2.5.1. XML
2.5.2. SOAP
2.5.2.1. Définition
2.5.2.2. Structure d’un message SOAP
2.5.3. WSDL
2.5.3.1. Définition
2.5.3.2. Structure d’un document WSDL1
2.5.4. UDDI
2.5.4.1. Définition
2.5.4.2. Structures de données UDDI
2.5.4.3. Accès à l’annuaire UDDI
2.5.4.4. Recherche d’un service
2.5.4.5. Publication d’un service
2.5.5. REST
2.5.5.1. Définition
2.5.5.2. Le style d’architecture REST
2.5.5.3. Contraintes
2.5.5.4. Ressources
2.5.5.5. Règles à suivre pour implémenter REST
2.6. Sécurité des Web services
2.6.1. Sécurité des Web services de type SOAP
2.6.1.1. WS-Security
2.6.1.2. XML‐Signature
2.6.1.3. Autres spécifications de sécurité
2.6.2. Sécurité des Web services de type REST
2.6.2.1. Authentification basique
2.6.2.2. Authentification par empreinte
2.6.2.3. Protocole « Three-Legged » OAuth
2.6.2.4. Protocole « Two-Legged » OAuth
2.7. Conclusion
CHAPITRE 3 : LES TECHNOLOGIES ADOPTEES
3.1. Introduction
3.2. Généralités sur la plateforme JEE
3.2.1. Composants et architectures Java EE
3.2.1.1. Les composants clients ou tiers client
3.2.1.2. Les composants Web ou tiers Web
3.2.1.3. Les composants métier ou tiers métier
3.2.2. Conteneurs Java EE
3.2.3. API et services Java EE utilisés
3.2.3.1. Technologies Java SE
3.2.3.2. Technologies Java EE
3.3. Les frameworks Java EE
3.3.1.1. Présentation
3.3.1.2. Pourquoi utiliser un framework ?
3.3.1.2.1. Normes et standards
3.3.1.2.2. Framework et développement Web
3.3.1.3. Quel framework choisir ?
3.3.1.4. Les frameworks utilisés
3.3.1.4.1. Struts
3.3.1.4.2. Spring
3.3.1.4.3. Hibernate
3.3.1.4.4. Direct Web Remoting
3.3.1.4.5. Google Web Toolkit
3.4. Implémentations utilisées pour les Web services
3.4.1. CXF
3.4.1.1. Annotations
3.4.1.2. Configuration Spring et CXF
3.4.1.3. Configuration du Web service sous Spring
3.4.2. Support de REST par Spring
3.5. Conclusion
CHAPITRE 4 : CLUSTERING ET LOAD BALANCING
4.1. Introduction
4.2. Clustering
4.2.1. Définition
4.2.2. Notion de haute disponibilité
4.2.3. Types de répartition
4.2.3.1. Répartition verticale
4.2.3.2. Répartition horizontale
4.2.4. Bases du clustering
4.2.4.1. Modèle topologique maître-auxiliaire
4.2.4.2. Modèle comportemental de basculement
4.3. Load balancing
4.3.1. Définition
4.3.2. Couplage du serveur Web Apache et du serveur Java EE Tomcat
4.3.2.1. mod_proxy
4.3.2.2. mod_jk
4.3.2.3. Sessions persistantes
4.3.2.4. Partage de session
4.4. Conclusion
CHAPITRE 5 : ANALYSE ET CONCEPTION
5.1. Introduction
5.2. Contexte
5.3. Analyse des besoins
5.3.1. Expression des besoins
5.3.2. Identification des acteurs
5.3.2.1. Les clients
5.3.2.2. Les opérateurs
5.3.2.3. Les administrateurs
5.4. Modélisation UML
5.4.1. Diagramme des cas d’utilisation
5.4.1.1. Cas d’utilisation de l’acteur « client »
5.4.1.2. Cas d’utilisation de l’acteur « opérateur »
5.4.1.3. Cas d’utilisation de l’acteur « Administrateur »
5.4.2. Diagramme d’activités
5.4.3. Diagramme de classes
CHAPITRE 6 : SIMULATIONS
6.1. Introduction
6.2. Plateforme à réaliser
6.2.1. Objectif
6.2.2. Architecture générale de la plateforme
6.2.3. Architecture technique de la plateforme
6.3. e-banking
6.3.1. Outil de conception
6.3.2. Spécifications techniques
6.3.2.1. Serveur Web
6.3.2.2. Base de données
6.3.2.3. Serveur d’applications
6.3.2.4. Environnement de développement
6.3.2.5. Framework de présentation
6.3.2.6. Spring
6.3.2.7. Framework de persistance
6.3.3. Structure globale du projet
6.3.4. Web services SOAP
6.3.5. Web services REST
6.4. Mobile banking
6.4.1. Spécifications techniques
6.4.1.1. GWT
6.4.1.2. Microsoft Visual Studio 2010 Express for Windows Phone
6.4.2. Structure du projet GWT
6.4.3. Structure du projet Android
6.4.4. Structure des projets iOS et BlackBerry
6.4.5. Structure du projet Windows Phone
6.5. WAP banking
6.6. Module de paiement e-commerce
6.7. SMS banking
6.7.1. Fonctionnement du module
6.7.2. Spécifications techniques
6.7.3. Structure du projet
6.8. Clustering et load balancing
6.8.1. Architecture mise en place
6.8.2. Configuration du load balancer Apache
6.8.3. Configuration du clustering de Tomcat
6.8.3.1. Vue d’ensemble du répertoire Tomcat
6.8.3.2. Installation de plusieurs instances Tomcat sur une seule machine
6.9. Simulations
6.9.1. Présentation de l’application web
6.9.2. Présentation des applications mobiles
6.9.2.1. Version Android
6.9.2.2. Version BlackBerry
6.9.2.3. Version iOS
6.9.2.4. Version Windows Phone
6.9.2.5. Version WAP
6.9.3. Présentation du simulateur SMS
6.9.4. Présentation du site e-commerce avec notre module de paiement
6.9.5. Test de montée en charge
6.10. Conclusion
CONCLUSION GENERALE

Télécharger le rapport complet