La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

PRÉSENTATION du 26 octobre 2006

Présentations similaires


Présentation au sujet: "PRÉSENTATION du 26 octobre 2006"— Transcription de la présentation:

1 PRÉSENTATION du 26 octobre 2006
Projet WIB PRÉSENTATION du 26 octobre 2006 Claire De Bie Pierre Goaziou Vincent Penet Nazim Saouli Fanny Sisombat

2 Architecture de distribution de services
Points clés : Web Services Administration assistée Adaptation des résultats Communications intelligentes Client multi supports

3 A qui s’adresse notre produit ?
Opérateurs téléphoniques Fournisseurs d’accès à Internet

4 Quels sont les besoins ? Itinéraire Recherche Traducteur
Différents services Opérateurs téléphoniques Fournisseurs d’accès à Internet Différents supports

5 ORGANISATION EN FONCTIONNALITES
Réponses aux besoins Web Service Service Itinéraire Itinéraire adresse GPS FONCTIONNALITE ORGANISATION EN FONCTIONNALITES

6 Réponses aux besoins Transport PRESENTATION DES RESULTATS Image
TCP ? UDP TCP ADAPTATION DE LA COMMUNICATION

7 WIB : plateforme d’intégration de web services
Intègre facilement des web services Exécute des fonctionnalités Communique avec différents types de supports Adapte les données au support (Présentation) WIB est une plateforme innovante : Elle exécute des web services de manière transparente pour l’utilisateur. Elle intègre de manière simple ces web services et les organise en fonctionnalités. Elle adapte ses communications aux supports qui la sollicitent.

8 Notre Client Ce n’est pas l’utilisateur final
C’est l’entreprise qui a besoin de fournir un panel de service à ses clients Notre client a besoin de satisfaire l’utilisateur final en lui donnant accès à des services. Notre principal but est de fournir à notre client les moyens de le faire facilement

9 Scénarios d’utilisation

10 3 scénarios d’utilisation
L’utilisateur se connecte WIB lui fournit la liste des fonctionnalités auxquelles il a accès L’utilisateur demande l’exécution d’une 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

11 L’utilisateur se connecte
Connexion utilisateur Affichage liste à l’utilisateur Appli Cliente Récupération caractéristiques Caractéristiques utilisateurs Vous avez le choix entre : Itinéraire (et oui c’est tout !) J’ai un petit écran Envoi demande + caractéristiques utilisateurs Envoi résultat + liste fonctionnalités Comparaison des caractéristiques Appli Serveur Liste fonctionnalités Définition de la liste adaptée L’utilisateur 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

12 L’utilisateur demande l’exécution d’une fonctionnalité
Sélection fonctionnalité Affichage résultat à l’utilisateur Appli Cliente Récupération caractéristiques Caractéristiques utilisateurs Carte + itinéraire Saisie entrées Demande & réception entrées Envoi demande + nom_fonctionnalité + caractéristiques_utilisateurs Entrez les adresses de départ et d’arrivée Je veux exécuter Itinéraire Envoi résultat + résultat_web_service Adapter/présenter le résultat Comparaison des caractéristiques Demande d’entrée à l’utilisateur Fonctionnalité Appli Serveur Entrées ? OUI NON Liste web services Choix du web service à exécuter MapPoint est le Web Service le mieux adapté Caractéristiques web services Exécution web service

13 L’administrateur ajoute un web service
Interface administrateur WSDL Affichage des propositions Modifications Interprétation du fichier WSDL Validation Appli Serveur Optimisation des règles proposition Enregistrement en BDD Proposition des méthodes et E/S

14 Architectures

15 Notre architecture : vue simplifiée
Web Service Serveur Client Marquer WIB au lieu d’  »application serveur » pke je sais pas si on peut dire que nos 3 couches dont une quis ‘appelle application peuvent être nommée sous « application serveur »

16 L’application client

17 L’application client Rôle et traitements : Type de données échangées :
Elle récupère les caractéristiques utilisateurs Elle communique avec le serveur par le réseau IP Elle émet des requêtes pour l’application serveur Elle reçoit les réponses fournies par le serveur Elle affiche le résultat à l’utilisateur Type de données échangées : Requêtes : Informations utilisateur (identifiant, caractéristiques support…) Informations d’affichage Paramètres d’entrée Résultats Changer le cas de la deconnexion immediate : rajout d’un time out

18 Application serveur

19 Architecture WIB Application Négociation Transport Application Serveur
Analyse les requêtes. Gère les fonctionnalités et appels de web services. Application Serveur Transport Négociation Application 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. caract Transport : Stocke les informations utilisateur Gère la transmission d’informations. Notre architecture s’organise en 3 couches, indépendantes le + possible les unes des autres Capable de dialoguer entre elles Capables d’adapter leur traitement en fonction de la demande.

20 Notre particularité Le client n’a accès qu’aux fonctionnalités qui lui correspondent Adaptation du résultat et de la transmission Renvoie la liste des fonctionnalités Execute un WebService Application Le client peut demander une fonctionnalité qui ne lui correspond pas Risque d’erreurs Adapte la liste des fonctionnalités Dégrade le résultat d’un WebService Choisit TCP ou UDP suivant le support Négociation Reçoit les connexions client Envoie le résultat du WebService au client Transport

21 Détails des couches : Transport

22 La couche transport : Rappels et traitements
Rôle : permettre au serveur de dialoguer avec les clients. Les clients pourront se connecter en utilisant les protocoles : TCP UDP Le reste de l’application dialoguera avec la couche transport par l’intermédiaire d’objet messages : Message Identifiant client Requête Type de requête Données

23 La couche transport : les connexions
TCP : L’utilisateur se connecte, échange des messages avec le serveur, puis se déconnecte. Si pendant 10 minutes aucun message n’est échangé, les informations du client sont supprimées. UDP : Pas de connexion. Si pendant 10 minutes aucun message n’est échangé, les informations client sont supprimées.

24 Couche Transport : MDD simplifié
Liste des utilisateurs Serveur Tcp Serveur Udp Liste des Messages Message Utilisateur Socket Liste de caractéristiques Requête

25 La couche transport : état actuel
Ce qui fonctionne : Files d’attente Multithreading Liste des clients connectés Ce qui est en cours : Serveur Tcp (en modification) Serialization entre Java et C# Travail à finir : Serveur Udp

26 Détails des couches : Négociation

27 Négociation : les caractéristiques
Définition : ce sont des capacités Taille mémoire Capacité d’affichage 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 l’application client

28 Négociation : les caractéristiques support
Application Serveur Négociation Application Réponse Application Client Négociation Requête caract On récupère les caractéristiques du support lors d’une demande de l’utilisateur. Une connexion est établie et les caractéristiques et la requête sont envoyées au serveur. Négociation stocke les caractéristiques. Application interprète la requête. Avant d’envoyer la réponse au client, les caractéristiques du support sont supprimées de la mémoire, la réponse est envoyée et la connexion est rompue.

29 Négociation : le principe (1)
Demande de la liste des fonctionnalités Fonctionnalité Négociation Application Carac Fonct requête ? caract Dans tous les cas, Négociation stocke les caractéristiques du support. La requête est envoyée à la partie Application de notre système qui l’interprète : Si c’est une demande de liste de fonctionnalité, on veut récupérer les fonctionnalités les plus adaptées au support et donc à ses caractéristiques. La question est alors comment faire ? On a alors attribué a chaque fonctionnalité des caractéristiques minimales à avoir pour l’effectuer. On compare ces caractéristiques à celles du support pour en déduire la liste des fonctionnalités utilisables par ce support. Liste de fonctionnalités Données : Caractéristiques minimales de fonctionnalité

30 Négociation : le principe (2)
Demande d’exécution d’une fonctionnalité Web service Négociation Application Carac WS requête ? caract La requête est envoyée à la partie Application de notre système qui l’interprète : Si c’est une demande d’exécution de fonctionnalité, on veut connaître le web service le plus adapté au support et donc à ses caractéristiques. La question est alors comment faire ? On a alors attribué a chaque web service des caractéristiques à avoir pour l’effectuer. On compare ces caractéristiques à celles du support pour déterminer le web service à utiliser pour ce support. Données : Caractéristiques de web service Choix du web service

31 Négociation : le principe (3)
Envoi de données au support Transport Négociation caract Choix du moyen de transport Protocole

32 Détails des couches : Application

33 Application : Définir les caractéristiques (2)
WS2 WS1 IHM Admin Taille mem : 30M ; écran : 1280x800 Taille mem : 3M ; écran : 120x90 Taille mem : 5M ; écran : 120x90 Taille mem : 3M ; écran : 400x150 Téléphone simple Smartphone PDA Ordinateur Solution de base Administrateur choisi un profil de support pour le WS Caractéristiques associées au profil stockées en base de données

34 Application : Définir les caractéristiques (3)
Web Service Appel du web service WS2 WS2 WS1 Result Détermination caractéristiques Programme de détermination des caractéristiques par rapport aux éléments renvoyés par le web service Solution améliorée Appel du WebService lors de l’ajout Détection des caractéristiques associées au résultat

35 Définir les caractéristiques
Taille mem : 5 Mo ; écran : 800x600  Ordinateur WS1 Taille mem : 3 Mo ; écran : 120x90  Téléphone simple WS2 Web service Taille mémoire Écran WS1 5 Mo 800x600 WS2 3 Mo 120x90 En BDD : Après chaque ajout de web service et de détermination de ses caractéristiques, il faut mettre à jour les caractéristiques de la fonctionnalité. On les détermine grâce aux caractéristiques des web services : les caractéristiques de fonctionnalités sont les caractéristiques du service web « minimum », qui demande le moins de capacités. Fonctionnalité 3 Mo 100x90

36 Application : Traitements associés & Points clefs
Intégration d’un Web Service Proposition des méthodes, E/S et caractéristiques du WS Validation des infos du Web service via l’interface administrateur Enregistrement des infos du Web Service en BDD Exécution d’une fonctionnalité Exécution d’un Web Service Récupération du résultat du Web Service Récupération des paramètres à exécuter en mémoire Récupération de la valeur des entrées en mémoire ou chez l’utilisateur Requête au Web Service

37 Application : MDD

38 Ajout d’un web service :
Proposition automatique des méthodes, entrées et sorties

39 Principe général Lors de l’ajout d’un nouveau web service, l’administrateur doit déterminer plusieurs paramètres : L’adresse du fichier WSDL. La méthode qu’il veut utiliser ainsi que les types des entrées et sorties. Les caractéristiques du nouveau web service. Notre système guidera l’administrateur dans sa recherche et lui proposera des solutions.

40 Outil de propositions L’administrateur saisit le nom du WSDL
Opération1 Input1 Input2 Output2 Opération2 Opération3 L’administrateur saisit le nom du WSDL Le système analyse le WSDL pour trouver : Les opérations Les entrées et sorties Création d’un tableau d’opérations

41 Outil de propositions (2)
Fonction du tableau d’opérations : Comparaison entre : les noms de méthodes Liste de mots clés (pour proposer la méthode la plus pertinente à l’administrateur) Lorsque l’utilisateur a fait un choix différent des propositions, la liste des mots clés par fonctionnalité est enrichie.

42 Exécution d’un Web Service

43 Exécution d’un web service
Entrées nécessaires & provenance Sorties & destination @ WSDL BDD Méthode à appeler Nombre d’entrées Entrées 1,2,…,n BDD (défini par l’admin) Mémoire (défini par l’utilisateur) Résultat du web service Mémoire (vers l’utilisateur)

44 Exécution d’un Web Service
Proxy Application Serveur Marquer WIB au lieu d’  »application serveur » pke je sais pas si on peut dire que nos 3 couches dont une quis ‘appelle application peuvent être nommée sous « application serveur »

45 Librairie DynWSLib http://www.xmlwebservices.cc
Permet de créer dynamiquement un Proxy pour un Web Service Permet d’utiliser le Web Service comme une ressource locale Permet de nous interfacer uniquement avec paramètres que l’on maîtrise

46 Exécution d’un web service : état actuel
Programme qui marche avec plusieurs web services Gestion des erreurs à faire Cas où le web service ne répond pas Cas où un paramètre est mauvais et déclenche une erreur Vérifier le type du résultat « Object result » permet-il de tout récupérer ? Une image ? Effectuer les tests

47 IHM

48 IHM : Administration X WIB Interface en 3 parties: Monitoring
Intégration/Modification WS Historique Reste de l’application Non défini Intégrer un WS Modifier 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 d’erreurs Historique des ajouts et des modifications de WebServices

49 IHM : Intégrer un service
WIB X WSDL : WSDL : Méthodes : Entrées : Sorties : Reste de l’application Non définie Proposition des méthodes, entrées et sorties pertinentes Validation ou modification de cette proposition par l’utilisateur

50 IHM : Intégrer un service
WIB X Reste de l’application Non défini Caractéristique du WS? Nom caractéristique Clef 1 2 3 4 5 Définition des caractéristiques à associer au WebService en cours d’intégration Ce choix s’effectue dans une liste préétablie

51 IHM : Intégrer un service
WIB X Reste de l’application Non défini Attribut manuel ? Nom Client Nom ADMIN Nom WSDL Clef 1 2 3 4 5 Définition des entrées : A demander à l’utilisateur A définir par défaut

52 IHM : Intégrer un service notre problème
Comment créer une interface client qui fonctionnerait avec un maximum de Web Services ?

53 IHM : Intégrer un service notre idée
Les Web Services ont la plupart du temps des entrées représentables sous forme de string Notre application client est en Java. Java met a notre disposition SWING pour créer des interfaces multi plateformes. En SWING, on joue avec : Des « panels » Des « labels » Des « textfields » Des « buttons », …

54 IHM : Intégrer un service notre solution
Coté serveur : lors de l’ajout d’un Web Service WIB X Reste de l’application Non défini Attribut manuel ? Nom Client Nom ADMIN Nom WSDL Clef 1 2 3 4 5

55 IHM : Intégrer un service notre solution
Génération de la description de l’interface du web service : XML Exemple : <panel> <label>Mot clef</label> <textfield></textfield> </panel> <button>Rechercher</button>

56 IHM : Intégrer un service notre solution
Coté client : Création d’objets à la volée : jButton (bouton) jLabel (zone de texte) jPanel (zone d’affichage) jTextfield (zone d’écriture) Utilisation de Layout pour positionner les objets dans le panel principal. WIB X Label : APPEL Reste de l’application Non défini

57 Traitement de la charge

58 Traitement de la charge
Duplication des serveurs d’application La base de données sera partagée. Elle contiendra : les Fonctionnalités les Web Services les clients autorisés à se connecter Lors du lancement d’un serveur, celui-ci se connecte à la base de données et charge les Fonctionnalités. Les clients seront répartis sur les différents serveurs.

59 Déploiement

60 Déploiement de WIB Installation sur le serveur
Installeur qui copie les différents fichiers Configuration de l’application (accès à la BDD,…) Mise à l’écoute des clients Distribution de l’application client Téléchargement de l’application sur un site web Création des comptes client sur un site Penser au fil rouge aussi…

61 Suivi de projet

62 Planning prévu fin septembre
Principe Séparation par parties du système Parties étudiées sur des périodes différentes Etude d’une partie : Doc puis code Inconvénients Mauvaise visibilité sur l’ensemble Non-validation de la doc => Retard sur le code Blocages empêchant l’avancement

63 Nouvelle gestion Séparation par versions Répartition code et doc
Sur une période donnée Travail sur toutes les parties du système Chaque partie a un objectif "versionné" Version suivante sur la période suivante Répartition code et doc Pour chaque personne Une tâche doc (étude, décision, rédaction) Une tâche code (tests, programmation, doc)

64 Nouveau planning doc

65 Nouveau planning code

66 Nouveau planning code

67 Prototypes

68 Octobre : Version 1 Prototype
Trois scénarios opérationnels Demande de la liste des fonctionnalités Demande d’exécution d’une fonctionnalité Intégration d’un web service Traitement de résultats de type simple Convertibles en string Pas d’image

69 Novembre : Version 2 Prototype
Traitement d’image Réception du résultat à l’exécution du web service Dégradation de la donnée Affichage dynamique adapté Proposition des caractéristiques Base de données Transport opérationnel Meilleure interopérabilité

70 Décembre : version 3 Interface administrateur Optimisation
Historique Affichage des erreurs Test après intégration Optimisation Application cliente

71 Merci de votre attention
C’est fini ! Merci de votre attention

72 Négociation C’est la partie qui permet à WIB d’être auto adaptatif :
Elle stocke les caractéristiques du support le temps de l’exécution de la requête. Elle est la seule à les connaître. Les négociations sont basées sur les caractéristiques du support utilisateur : A la demande de la liste de fonctionnalités disponibles pour un utilisateur, elle négocie cette liste avec Application A la demande d’exécution d’une fonctionnalité pour un utilisateur, elle négocie le choix du web service avec Application Lorsque le système veut échanger des informations avec le client, elle négocie le choix du mode de communication avec Transport. Le caractère auto adaptatif de notre système dans le choix des fonctionnalités se base principalement sur les caractéristiques su support. C’est la partie négociation qui va permettre de le gérer. Elle est la seule à connaître ces caractéristiques (rappel : OS, taille mémoire, résolution écran et débit). Ainsi la partie négociation va se charger de négocier 3 types de choses selon ces caractéristiques support : Lors d’une demande de liste de fonctionnalités, elle détermine les fonctionnalités disponibles pour le support. Lors d’une demande d’exécution de fonctionnalité, elle choisit le web service adapté au support. Lors d’un renvoi d’informations au support, elle négocie le choix du moyen de communication adapté. Nous allons donc voir plus en détails comment se font ces négociations.

73 Échanges d’information Schéma des flux simplifié

74 Application Serveur Application Client
Demande de liste des fonctionnalités disponibles Web Service Envoi de la liste des fonctionnalités disponibles Demande d’exécution d’une fonctionnalité particulière Web Service Envoi d’une demande d’entrées nécessaires Web Service Envoi des données d’entrées demandées Envoi des données résultat de la fonctionnalité

75 VUE GENERAL WEB SERVICES
Sorties : Récupère les données du Web Services Entrées : Requête enregistrées dans notre système pour chaque WS. Données pour le WS. Application Négociation Sorties : Résultat de la requête sous forme de données compréhensibles par le support. Entrées : Choix du Web services Données pour le Web services Transport Sorties : Retour des données adaptées au support Entrées: Caractéristiques Supports Choix de la fonctionnalité adaptés au support Client Entrées : Caractéristiques supports/ Données pour traitement Sorties : Résultats attendu par l’utilisateur / Requête d’attente de données de l’utilisateur. VUE GENERAL

76 La couche transport : principe

77 Optimisation de la proposition

78 État des lieux chemin itinéraire Solution assez statique :
Fonctionnalité 1 route Ajout des mots correspondant à des nouvelles méthodes choisies par l’administrateur. Fonctionnalité 1 itinéraire chemin On enregistre les mots clefs dans un fichier chemin itinéraire Ajout d’un WS : Chargement des mots dans un tableau en mémoire Le tableau se supprime en fin / donnée non persistante Si aucune méthode n’est trouvée / l’administrateur la rajoute et elle est prit en compte dans le fichier Solution assez statique : pas de priorité dans les mots clés. pertinence des mots clés à améliorer

79 Amélioration possible
Priorité des mots clés On associe à chaque mot clé un compteur d’utilisation pertinente. A chaque fois que la proposition est acceptée par l’administrateur, on incrémente le compteur du mot clé utilisé. On réorganise les mots clés par ordre croissant de compteur. Pertinence des mots clés On définit des contextes d’utilisation des mots clé. On choisit le mot clé en fonction du contexte.

80 Instaurer un système expert.
Établir une base de règles Organise les fonctionnalités et les mots clé associés en fonction des contextes. Ré-organise les règles en fonction des compteurs. Enrichir la base de règles par l’ajout de web services


Télécharger ppt "PRÉSENTATION du 26 octobre 2006"

Présentations similaires


Annonces Google