Soutenance 9 Novembre

1
Soutenance 9 Novembre

• Anarchitects

2
Contexte

• Pack de services annexes proposés
• Intégration simple et rapide
• Ressources dentreprises sollicitées au minimum
• Adaptation multi support

3
Notre solution
4
Notre solution

• Pack de services annexes
• Intégration simple et rapide
• Ressources dentreprises sollicitées au minimum
• Adaptation multi support

Web Service 1
Web Service 2
Itinéraire
Web Service 1
Utilisation de Web Services Organisation en
fonctionnalités
Web Service 2
Web Service 3
Recherche
5
Notre solution

• Pack de services annexes
• Intégration simple et rapide
• Ressources dentreprises sollicitées au minimum
• Adaptation multi support

Opérateurs téléphoniques
Fournisseur daccès à Internet
6
Notre solution

• Pack de services annexes
• Intégration simple et rapide
• Ressources dentreprises sollicitées au minimum
• Adaptation multi support

Web Service 1
Web Service 2
Itinéraire
Web Service 1
Administrateur de lentreprise
Traduction
Web Service 1
Possibilité dajout de fonctionnalités et de Web
Services Administration guidée
Web Service 2
Web Service 3
Recherche
7
Notre solution

• Pack de services annexes
• Intégration simple et rapide
• Ressources dentreprises sollicitées au minimum
• Adaptation multi support

Quel moyen de communication ?
Opérateurs téléphoniques Fournisseur daccès
Internet
Adaptation des données et des moyens de
communication au support
8
WIB plateforme innovante dintégration de web
services

• Il sadapte aux utilisateurs
• Il leur propose des fonctionnalités de façon
  personnalisée
• Il choisit le web service le plus approprié
• Il renvoie des données compréhensibles et
  cohérentes
• Il utilise le moyen de communication adapté

• Il intègre facilement les web services
• Il guide ladministrateur
• Il sintègre simplement au système de lentreprise

9
Scénarii
10
Scénarii dutilisation
Chez le client
WIB
Utilisateur final
Administrateur
11
Architecture de communication
Serveur dApplication
12
Montée en charge
13
Problématique

• Nombre dutilisateurs augmente
• Nombre de connexions au serveur augmente
• Problème
• Comment continuer à assurer la même qualité de
  service aux utilisateurs ?

14
Solution

• Faire fonctionner WIB sur plusieurs serveurs
• Tous les serveurs dapplication attaquent le même
  serveur de données
• Mettre en place des load-balancers utilisant
  lalgorithme  least-connection 

15
Schéma de la solution
16
WLBS et NLBS

• WLBS Windows load-balancing Service
• Remplacé par Network Load-balancing Service (
  NLBS ) à partir de Windows 2000
• NLBS is intended for applications with relatively
  small data sets that rarely change (one example
  would be web pages), and do not have
  long-running-in-memory states.
• These types of applications are called stateless
  applications, and typically include Web, File
  Transfer Protocol (FTP), and virtual private
  networking (VPN) servers.
• Every client request to a stateless application
  is a separate transaction, so it is possible to
  distribute the requests among multiple servers to
  balance the load.

17
Serveur de données

• Fonctionner avec un seul serveur de données
• Perte de nos données si le serveur tombe
• Pas envisageable
• Fonctionner avec deux serveurs de données
• Mettre en place un système de Fail-Over
• Assurer la cohérence des données entre les deux
  serveurs
• Permet de continuer à fonctionner lorsquun des
  serveurs tombe

18
Notre Architecture finale
19
Scénario dutilisation
Chez le client
WIB
Utilisateur final Client du client
Administrateur
20
Lutilisateur se connecte
Connexion utilisateur
Appli Cliente
Caractéristiques utilisateurs
Vous avez le choix entre Itinéraire (et oui
cest tout !)
Jai un petit écran
Appli Serveur
Liste fonctionnalités
Lutilisateur a un petit écran Traduction
nécessite un grand écran Itinéraire nécessite un
petit écran
Itinéraire est disponible
Caractéristiques fonctionnalités
21
Scénario dutilisation
Chez le client
WIB
Utilisateur final Client du client
Administrateur
22
Lutilisateur demande lexécution dune
fonctionnalité
Sélection fonctionnalité
Appli Cliente
Caractéristiques utilisateurs
Carte itinéraire
Entrez les adresses de départ et darrivée
Je veux exécuter Itinéraire
Fonctionnalité
Appli Serveur
Liste web services
MapPoint est le Web Service le mieux adapté
Caractéristiques web services
23
Scénario dutilisation
Chez le client
WIB
Utilisateur final Client du client
Administrateur
24
Ladministrateur ajoute un web service
Interface administrateur
Saisie _at_ WSDL
Appli Serveur
25
Notre Architecture
26
Négociation Adaptation
Application Serveur
27
Lapplication Serveur
Application Serveur
28
Rappels et traitements

• Rôles
• Permettre au serveur de dialoguer avec les
  applications client
• Stocker les informations concernant les
  utilisateurs pendant 10 min
• Informations échangées
• Message
• Identifiant du client
• Protocole utilisé
• Requête
• Type de requête
• Données

29
Principe
lt?xml version"1.0" encoding"utf-8"?gt ltMessage
xmlnsxsi"http//www.w3.org/ ... gt
ltIdUsergttotolt/IdUsergt ltProtocolegttcplt/Protocol
egt ltRequestgt ltRequestIdgtgetList_fonclt/
RequestIdgt ltDatagt
ltCaracteristiquesgt
ltCaracteristique name"ScreenSize.Height"
value"800" /gt ltCaracteristique
name"ScreenSize.Width" value"1280" /gt
lt/Caracteristiquesgt lt/Datagt
lt/Requestgt lt/Messagegt
Application Serveur
OBJET MESSAGE Identifiant toto
Protocole tcp Requête
Type de requête getList_Fonc
Données Liste des caractéristiques
XML
OBJET MESSAGE
30
Etat actuel

• Ce qui fonctionne
• Files dattente
• Multithreading
• Stockage des informations concernant les
  utilisateurs connectés
• Serveur Tcp
• Serialization / Déserialisation dobjets en XML
• Ce qui est en cours
• Gestion des cas particuliers
• Ce qui reste à faire
• Serveur Udp

31
Lapplication Serveur
Application Serveur
32
Négociation

• Compare des caractéristiques
• TCP ou UDP
• Dégrade les images
• Transforme la description générée par la couche
  Application

Adapte la liste de fonctionnalités à lutilisateur
Choisit le Webservice adapté à lutilisateur
Choisit le protocole de transport
Adapte les données au support de lutilisateur
Adapte la description de linterface utilisateur
33
Les caractéristiques

• Définition ce sont des capacités
• Taille mémoire
• Capacité daffichage
• Débit de connexion
• Évolutivité nouvelle caractéristique
• Coté serveur
• Ajout dans la base de donnée
• Prise en compte au prochain démarrage du serveur
• Coté client
• Mise à jour de lapplication client

34
Lapplication Serveur
Application Serveur
35
Application

• WIB propose un ensemble de fonctionnalités de
  base et la possibilité den ajouter
• Ladministrateur gère ces fonctionnalités en
  ajoutant des web services
• Quil a développé
• Quil a sous-traité
• Qui sont à distance

Web Service 1
Web Service 2
Itinéraire
36
Application

• La liste des fonctionnalités adaptée est
  déterminée par négociation la couche précédente.
• Le web service adapté est choisi par négociation
  avec la couche précédente
• Le web service choisi est appelé et les résultats
  sont récupérés

Demande de la liste des fonctionnalités
Demande lexécution dune fonctionnalité
Renvoie des données pour exécuter un web service
37
Application
Web Service
Renvoie des données pour exécuter un web service
Type XML

• Les balises sont prédéfinies dans Application
• Les données sont organisées entre ces balises

38
Notre Architecture
39
MCD
1,1
40
Gestion des accès en base

• Qui y accède ?
• Un administrateur chez le client
• Plusieurs utilisateurs

Utilisateurs
Administrateur
41
Gestion des accès en base

• Quelles actions y sont faites ?

Administrateur
42
Gestion des accès en base

• Quelles actions y sont faites ?

Utilisateurs
43
Accès concurrentiels

• Entre les utilisateurs aucun
• Toutes les tables sont interrogées
• Une table est modifiée
• Cette table nest pas interrogée par dautres
  utilisateurs
• Entre ladministrateur et les utilisateurs deux
  cas à gérer
• La table HISTORIQUE
• Modifiée par les utilisateurs
• Consultée par ladministrateur
• Les autres tables
• Modifiées par ladministrateur
• Consultées par les utilisateurs

44
Accès concurrentiels

• Nos solutions Actions de lutilisateur
• Au démarrage de lapplication, la base de données
  est chargée en mémoire
• Les requêtes utilisateurs sont donc faites sur
  les objets en mémoire
• Seul la création dans la table HISTORIQUE donnera
  lieu à une connexion à la base toutes les n
  modifications

45
Accès concurrentiels

• Nos solutions Actions de ladministrateur
• A louverture de son application, on charge les
  données de la base dans linterface
  administrateur
• Lorsquil rafraîchit lhistorique, la requête est
  lancée à la base
• Lorsquil les valide, ses modifications sont
  enregistrées en base

46
Accès concurrentiels

• Mise à jour pour les utilisateurs

47
Mise en œuvre de la base de données

• Outils utilisés
• PowerAMC (Génération du modèle en base)
• MySql Server 5.0
• Composants
• Librairie MySql.Data.dll
• Connector/NET
• Avancement
• Fichiers scripts définis
• Installation.sql, desinstallation.sql,
  remplissage_test.sql, vidage_test.sql
• Connexion à la base depuis notre application
• Chargement de la base en mémoire
• Traitements sur ces données mémoire

48
Notre Architecture
49
Administration

• Interface en 3 parties
• Monitoring
• Informations sur le statut du système
• Intégration/Modification WS
• Intégrer un WebService
• Modifier les infos associées à un WebService
• Historique
• Log derreurs
• Historique des ajouts et des modifications de
  WebServices

50
Intégrer un service

• Proposition des méthodes, entrées et sorties
  pertinentes
• Validation ou modification de cette proposition
  par lutilisateur

51
Intégrer un service

• Définition des caractéristiques à associer au
  WebService en cours dintégration
• Ce choix seffectue dans une liste préétablie

52
Intégrer un service

• Définition des entrées
• A demander à lutilisateur
• A définir par défaut

53
Notre Architecture
54
Application Client

• Spécifications
• Fonctionner sur nimporte quel OS
• Fonctionner sur nimporte quel support
• Fonctionner de façon optimale
• Faciliter le déploiement
• Contraintes
• Récupérer les caractéristiques sur le support
• Adapter laffichage aux données et aux supports
• Adapter WIB à la technologie du client

55
Description de lIHM Utilisateur
Application Serveur
APPLICATION
XML
NEGOCIATION
TRANSPORT
56
Types de clients choisis par WIB
Application

• On développe une application en Java
• On fonctionne sur nimporte quel OS
• On définira à terme dautres applications
• On développe une application en C
• PC (Windows)
• PDA (Windows CE)
• On développe un client léger

User Interface
CLIENT
User Interface
SERVEUR
Application
DataBase
57
Une seule Fenêtre fixe
58
UNE IHM dynamique
59
Possibilité de réglage des paramètres
60
Organisation
61
Tests
62
Les tests unitaires

• Pour chaque classe, on va construire une classe
  test qui linstancie
• On écrit dans la classe test les tests sur chaque
  méthode de la classe
• Le composant Csunit génère un rapport derreur
  lors de la compilation

63
Qualité
64
Slides sur la qualité
65
Suivi de projet
66
Planning doc
67
Planning code
68
Cette semaine

• Définition dun plan qualité
• Reprise des spécifications fonctionnelles du
  rapport
• Définition du fonctionnement de notre application
  client
• Interprétation de Cookswing pour les affichages
  dynamiques en JAVA
• Programmation des traitements de la couche
  Application sur les données chargées depuis la
  BDD
• Sérialization/Désérialization des messages XML
• SVN surchargé

69
Reste à faire

• En terme détude
• Type renvoyés par un web service
• Optimisation des propositions
• Dégradation dune image
• Ajout dune fonctionnalité
• Déploiement et installation
• En terme de documentation
• Plan du rapport défini à se répartir
• Y intégrer les docs existants
• Définir le contenu type des docs de conception
• Plan qualité en cours de validation

70
Merci de votre attention
71
Lapplication client

• Rôle et traitements
• Elle récupère les caractéristiques utilisateurs
• Elle communique avec le serveur par le réseau IP
• Elle émet des requêtes pour lapplication serveur
• Désérialise les données XML ( API DOM)
• Utilise SWT pour créer linterface
• ? Problème de portabilité
• Utiliser Ajax pour obtenir une interface
  dynamique. Mais on retravaille sur le xml de
  manière indépendante de notre appli client
• ? Problème defficacité
• On reste avec Swing
• ? Problème dévolutivité

72
Produits

• Cisco IOS Server Load-balancer

73
3 scénarios dutilisation

• Lutilisateur se connecte
• WIB lui fournit la liste des fonctionnalités
  auxquelles il a accès
• Lutilisateur demande lexécution dune
  fonctionnalité
• WIB va lui demander les entrées éventuelles
• WIB lui renvoie le résultat
• Le client administrateur ajoute un Web Service
• WIB va intégrer le Web Service au système

74
Qualité
75
Qualité du logiciel

• Approche Facteurs / Critères / Métriques
• A partir de la norme ISO/CEI 9126
• Les facteurs
• La capacité fonctionnelle
• La fiabilité
• Le rendement
• La facilité dutilisation
• La maintenabilité
• Lévolutivité

76
Qualité du logiciel

• La capacité fonctionnelle existence de
  fonctions et de leurs propriétés qui satisfont
  les besoins clients
• Proposer des services
• Ajouter de nouveaux services
• Adapter les données à tous les supports
• Adapter la communication à tous les supports
• La fiabilité aptitude à maintenir le niveau de
  service quelles que soient les conditions
• Stress tests
• La facilité dutilisation effort fourni par
  lutilisateur
• Côté administrateur connaissance requise par
  lutilisateur
• Côté client interactivité

77
Qualité du logiciel

• Le rendement rapport entre le niveau de service
  et la quantité de ressources utilisées
• Tests de performance
• La maintenabilité effort nécessaire pour faire
  des modifications données
• Métriques sur le code
• Pourcentage de commentaires
• Nombre de lignes de code par module
• Nombre de paramètres passés à une méthode
• Profondeur dhéritage
• Complexité de McCabe
• Lévolutivité aptitude du logiciel à supporter
  les évolutions
• Une couche négociation dégradable
• Interchangeabilité des composants

78
Qualité du logiciel

• A suivre
• Pour chaque facteur
• Définir plus en détail les objectifs
• Définir les processus dévaluation
• Définir les valeurs attendues des métriques
• Définir les objectifs sécurité
• Trouver un logiciel de test gratuit !
• Parce que calculer la complexité de McCabe
• A voir Mercury.com

79
Procédures de tests
80
Les tests unitaires

• Ils vérifient la validité de chaque méthode de
  notre système.
• Pour chaque méthode, on liste les valeurs
  possibles des arguments.
• On vérifie le comportement des méthodes dans
  chaque cas.

ArrayList Parcours_xml (string xml_file)
Test 1 la string est invalide. Valeur dentrée
 toto 
Test 2 le fichier est introuvable.
Valeur dentrée  toto.wsdl 
81
Les tests de composants

• Ils valident le rôle et le bon fonctionnement de
  chaque composant
• On détermine des entrées possibles du composant
• On vérifie si on obtient les résultats attendus.
• Ils tiennent compte du dialogue avec les autres
  composants.
• Interface avec les IHM
• Définition des messages derreurs

Liste de valeurs dentrée possibles xml_file
   Xml_file  toto.wsdl 
Liste de comportement à avoir Récupération de
 null  qui entraine un message derreur à
lécran.
82
Les tests dintégration

• Ils garantissent le fonctionnement du système au
  fur et à mesure de lajout de composants.
• On définit une liste de valeurs possibles
  dentrée
• On vérifie quon récupère les sorties attendues.

• On a prévu un découpage du code entre les membres
  de WIB.
• Chaque développeur prévoit sur sa partie de
  développement
• les tests unitaires
• les tests de composant
• On prévoit de valider ces tests par un système
  automatique tenant compte de tout les cas définis
  manuellement.

83
Sa particularité est la nôtre

• Elle joue le rôle de diplomate de notre
  application
• Elle récupère les caractéristiques du support
• Elle détermine les fonctionnalités disponibles en
  fonction des caractéristiques du support
• Elle détermine quel web service utilisé pour
  répondre à une demande
• Elle détermine le protocole de transport le plus
  adapté au support
• Son rôle sarticule donc essentiellement sur la
  gestion de caractéristiques.

84
La sécurité
85
La sécurité analyse

• Les 5 critères de sécurité

86
La sécurité besoins

• Protéger notre système contre les intrusions 
• Protéger le système contre les attaques visant à
  déstabiliser le bon fonctionnement de Wib.
• Protéger le système contre les attaques visant à
  consulter des données confidentielles (base de
  données, Web services utilisés, )
• Protéger le système contre les utilisateurs non
  autorisés à utiliser le système Wib
• Sécuriser les échanges de données 
• Assurer lintégrité des données échangées.
• Assurer la confidentialité des données échangées.
• Assurer lauthentification des utilisateurs

87
La sécurité où ?

• Lors des transmissions entre lapplication client
  et lapplication serveur.
• Lors des échanges entre lapplication serveur et
  les web services.
• Lors des échanges entre lapplication serveur et
  la base de données.
• Lors de lidentification des utilisateurs.
• Lors de laccès à la base de données
  (lecture/ajout/modification/suppression)
• Lors de la génération des fonctionnalités
  disponibles pour un utilisateur.
• Lors de la mise en forme des résultats pour un
  utilisateur.

88
La sécurité solutions

• Serveur placé derrière un routeur NAT muni dun
  firewall.
• Accès au fonctionnalités uniquement pour les
  utilisateurs enregistrés (page web pour
  senregistrer)
• Connexion SSL entre client et serveur
• Lintégrité
• La confidentialité
• Lauthentification
• Accès à la base de données nécessitant une
  authentification.

89
Tests unitaires
90
Les tests unitaires

• Ils vérifient la validité de chaque méthode de
  nos classe.
• Pour chaque classe, on va construire une classe
  test qui linstancie
• On écrit dans la classe test les tests sur chaque
  méthode de la classe
• Le composant Csunit génère un rapport derreur
  lors de la compilation

91
(No Transcript)
92
MDD Application
93
Contraintes

• Des caractéristiques récupérées sur le support
  utilisateur et non à distance.
• Un souci de portabilité et de facilité de
  déploiement.
• Un affichage adapté aux données et aux supports.
• Le choix de la technologie est laissé au client
  afin dintégrer WIB à son existant

94
Notre solution

• Comment générer une IHM qui intègre le plus grand
  nombre de web services possible ?
• Génération de la description de linterface du
  web service XML
• Exemple
• ltpanelgt
• ltpanelgt
• ltlabelgtMot cleflt/labelgt
• lttextfieldgtlt/textfieldgt
• lt/panelgt
• ltpanelgt
• ltbuttongtRechercherlt/buttongt
• lt/panelgt
• lt/panelgt

95
Que désire notre client ?

• Lapplication client touche lutilisateur de
  notre client on nimpose pas de technologie.
• Clients lourds, clients léger
• Technologie déjà mise en place
• On transformera le fichier Xml suivant le support
  client utilisé.
• Xaml, Xul, .jar

96
Proposition Wib - client riche

• Définition
• Technologie permettant daméliorer la couche
  présentation dune application n-tiers (web ou
  autre)
• Technologie sensée palier les différences entre
  application native (installée sur le bureau) et
  application Web au niveau de l'ergonomie tout
  en restant portable
• Une technologie qui intègre la problématique de
  déploiement et de mise à jour de version (qui
  garde les qualités de déploiement des
  applications web actuelles)
• Principe de fonctionnement
• une description XML de l'interface permet de
  générer à la volée, à partir d'un moteur et d'une
  librairie de composants graphiques, l'interface
  graphique utilisateur.

97
Quelle Technique ?
Application

• Swixml
• Utilise la bibliothèque Swing
• Xul
• Respecte la contrainte liée à portabilité
• lis des fichiers locaux
• Difficulté pour le décrire en Java
• Eclipse RCP
• XAML
• Java Web start
• Sunml
• Uiml

User Interface
UI
Application
DataBase
98
Notre Architecture
99
Outil de propositions

• Problématique proposer à ladministrateur des
  méthodes pertinentes
• Le système analyse le WSDL en cherchant les
  opérations.

• Il trouve une proposition dopération
  pertinente grâce à un système de mots clé liés
• Chaque fonctionnalité est lié à un fichier de
  mots clé qui représente le vocabulaire le plus
  utilisé
• On cherche la proposition à partir de ces mots
  clés
• On enrichit le fichier avec de nouveaux mots clé
  selon les ajouts de web services.

100
Lapplication Serveur

• Application
• Analyse les requêtes.
• Gère les fonctionnalités et appels de web
  services.

Application Serveur

• Négociation
• Négocie les choix de fonctionnalités et de web
  services.
• Négocie le protocole de transport à utiliser
• Présente les données.

• Transport
• Stocke les informations utilisateur
• Gère la transmission dinformations.

101
Couche Transport interfaces

• Interfaces utilisées
• Interface dévénements
• Arrivée() signale larrivée dun nouveau
  Message
• Interfaces fournies 
• Interface de contrôle du serveur
• DémarrerServeur  lance lécoute du serveur sur
  les ports définis
• ArreterServeur  arrête daccepter des clients
  pour stopper le serveur
• Interface de récupération dinformation sur les
  Utilisateurs
• GetCaracUtil  revoie la liste des
  caractéristiques dun client
• GetPasswordUtil  renvoie le mot de passe envoyé
  par un client lors de la connexion
• Interface déchange de Messages
• GetMsg  renvoie le premier Message de la file
  dattente
• PostMsg  Envoie un Message à un client

102
La couche transport les connexions

• TCP
• Mode connecté
• Temps de conservation des informations 10 min
• UDP
• Mode déconnecté.
• Temps de conservation des informations 10 min

103
Couche Transport schéma simplifié
Transport
Liste des utilisateurs
Serveur Tcp
Serveur Udp
Liste des Messages
Message
Utilisateur
Socket
Liste de caractéristiques
Requête
104
Contexte

• Problématique
• Clients opérateur téléphonique et fournisseur
  daccès Internet.
• Utilisateurs multi support
• Besoins
• Diversifier les services
• Assurer cohérence et fiabilité
• Adapter les résultats
• Assister ladministration

105
Transition

• Tous ces serveurs pour gérer tout plein
  dutilisateurs
• Qui dit plein dutilisateurs dit plein de
  supports
• Qui dit plein de supports dit adaptation à gérer
• Détaillons notre serveur
• Mais dabord, mettons-nous en situation