D

1
Définitions des besoins clients

• WIB par les Anarchitects

2
Qui sont nos clients ?

• Clients ciblés
• Opérateurs téléphoniques
• Fournisseurs daccès Internet
• Ces entreprises souhaitent
• Proposer à leurs utilisateurs des services
  (itinéraire, moteur de recherche)
• Étendre ces services à tous les supports

3
Côté services

• WIB intègre
• A partir dune étude des besoins de lentreprise,
  on définit les types de service nécessaires à
  lentreprise, afin de les intégrer sous forme de
  fonctionnalités
• WIB fait appel à des web services pour
  concrétiser ces fonctionnalités
• WIB permet ensuite à lentreprise dajouter
  facilement de nouveaux web services

4
Coté supports

• WIB adapte
• Lensemble des supports du marché doivent pouvoir
  interpréter les données de manière transparente
• WIB propose à lutilisateur final des
  fonctionnalités compatibles avec son support
• WIB présente des données cohérentes et sadapte
  aux systèmes de communications

5
Plus concrètement

• On cible le type dentreprise on implémente un
  type de fonctionnalité de base.
• On peut  Intégrer  les web services répondant à
  ces fonctionnalités.
• Ce client peut ainsi ajouter de façon simple un
  web service quil veut rendre disponible et qui
  correspond à une de ces fonctionnalités.
• Cet ajout est guidé et ne nécessite pas de
  grandes connaissances techniques.
• Les résultats renvoyés par chaque web service
  sont adaptés au support demandeur.

6
Trois scénarios à traiter

• Lutilisateur final, client de notre client,
  demande la liste des fonctionnalités qui lui sont
  disponibles
• WIB opèrera un tri sur les fonctionnalités pour
  lui afficher la liste de toutes celles
  compatibles avec son support
• Lutilisateur final souhaite exécuter une
  fonctionnalité
• WIB exécutera le web service le plus adapté parmi
  tous les web services compatibles avec son
  support
• Le client souhaite ajouter un web service
• WIB proposera une interface administrateur
  rendant lajout du web service quasi transparent
  à ladministrateur

7
Traitements impliqués

• Panel de fonctionnalités
• Organisation des web services par des
  fonctionnalités
• Ajout dun web service
• Création dune interface administrateur
• Normalisation des web services pour chaque
  fonctionnalité
• Adaptation au support
• Proposition à lutilisateur final des
  fonctionnalités compatibles avec son support
• Présentation des données
• Adaptation à son système de communication

8
Modélisation de larchitecture

• Différentes représentations

9
Architecture N-tiers
10
Modélisation en blocs
Liaison
11
Modélisation en couches

• Application
• Analyse les requêtes
• Gère les appels de services

• Zone de négociation
• Choix du service en fonction du support.
• Gère la compréhension des résultats de services.

• Intégration
• Gère ladaptation des informations aux supports.
• Négocie les moyens de transmissions dinformations

• Zone de négociation
• Choix du moyen de transport en fonction du
  support et de la requête.
• Choix de la méthode de transmission en fonction
  des informations.

• Transport
• Recherche le moyen de communication adapté.
• Gère la transmission dinformations.

12
Web Services
13
Schéma simplifié de larchitecture
Web Service
Application Serveur
Application Client
Application Client
Web Service
Application Client
Web Service
Application Client
Application Client
14
Les Web Services

• Réalisent un travail à distance
• Sont programmés dans un langage qui nous est
  inconnu
• Sont décrit par leur fichier .wsdl
• Méthodes
• Paramètres
• Types
• Sont accessibles par SOAP (protocole déchange au
  format xml permettant de dialoguer avec des web
  services)
• Renvoient une réponse au format .xml

15
Lapplication serveur

• Communique avec les clients et les services
  extérieurs
• Interprète les requêtes des clients
• Fournit aux clients la liste des fonctionnalités
  disponibles et en accord avec les
  caractéristiques du support
• Appelle les Web services et reçoit leur réponse
  au format xml
• Met en forme la réponse pour le client
  (utilisation possible des fichiers xsl permettant
  la mise en forme html dun fichier xml)
• Propose à ladministrateur une interface simple
  pour ajouter des fonctionnalités, des services et
  définir linterface client
• Est programmée en C (plateforme .NET)

16
Lapplication client

• Communique avec lapplication serveur par le
  réseau IP
• Récupère les caractéristiques du support client
  et les envoie à lapplication serveur
• Reçoit la liste des fonctionnalités disponibles
• Émet des requêtes pour lapplication serveur
• Reçoit et affiche le résultat sous la forme dun
  document html
• Est programmé en Java, pour la portabilité du
  langage

17
Webservices et problématiques

• On fait appel à des WebServices
• On envoie des données au service
• On exécute le service
• On récupère le résultat
• Questions soulevées
• Comment utiliser un Webservice?
• Quelles contraintes cette utilisation
  impose-t-elle à notre application?

18
Test Webservices

• Test
• Utilisation du Webservice GoogleSearch via une
  interface en C sous Visual Studio .Net 2003
• Résultat
• On est capables dutiliser le WebService en
  programmant linterface entre lutilisateur et le
  service
• Constat
• Chaque webservice fonctionne avec ses propres
  structures de données.

19
(No Transcript)
20
Analyse du test

• Quelle solution adopter ?
• Créer une interface utilisateur par service ?
• Utiliser uniquement des services dont on connaît
  le fonctionnement?
• Remise en contexte par rapport au projet
• On cherche à créer une application qui soit une
  plateforme fédératrice et qui sadapte à tous les
  types de services.
• Solution que lon va mettre en place
• Créer un modèle générique pour chaque
  fonctionnalité

21
Lintégration de services

• La plus value de WIB

22
Problématiques

• Une fonctionnalité doit regrouper un ensemble de
  services ajoutés par lentreprise sous forme de
  Web Services
• Lajout dun nouveau Web Service doit se faire
  simplement et efficacement.
• Les Web Services renvoient des données de types
  très différents, dont les structures sont
  définies dans le fichier .wsdl associé il faut
  pouvoir les comprendre ET les utiliser.

23
Un modèle de données générique
MAPPING
Le fichier wsdl du WS contient la description des
structures de données qui lui sont propres il
est indispensable au fonctionnement du service.
Définition des fonctionnalités et dun fichier
dit  neutre  propre à chacune ce fichier
permet lidentification et lutilisation des
données du WS.
Le mapping est lidentification des objets à
envoyer et récupérer. Cest la partie automatisée
du système des fonctionnalités.
24
Principe de fonctionnement
ltEntréesgt_at_1 stg _at_2 stg ltSortiesgt..image
txt stg ltRequêtegt...type_req
Fonct 1
Fichier neutre XML
Entrées _at_1 stg _at_2 stg
Sorties image txt stg
Requête Type_req
Ce qui est définit dans WIB
25
Le rôle du fichier neutre (1)

• Le principe est de définir, par fonctionnalité,
  un modèle de fichier XML qui prend en compte les
  éléments demandés ou retournés par chacun des WS.
• La personne qui ajoute le WS de manière guidée,
  précise les noms des éléments à récupérer.
• Le mapping va permettre au système de repérer les
  données du Web Service par leur identifiant
  propre et de les mettre en lien avec les types de
  données du modèle générique.

26
Le rôle du fichier neutre (2)

• Le fichier neutre permet de générer des classes
   génériques  compréhensibles par tout le
  système.
• Lors dune demande de service, les instances de
  ces classes génériques sont créées et complétées
  par les résultats des WS.
• La couche dintégration peut alors traiter les
  données pour les adapter aux supports.

27
Modélisation Négociations - COM
28
Négociation entre Intégration et transport

• Négociation sur les protocoles de Communication
  (TCP, UDP, FTP, HTTP, HTTPS etc )
• Négociation faite en fonction des
  caractéristiques utilisateurs, des données
  échangées et de létat de la connexion (
  Protocoles déployables à un instant t)

29
Données dont on a besoin

• Couche Intégration
• Caractéristiques utilisateur
• Profils de transport
• Type des fichiers à échanger
• Couche Transport
• Protocoles de transport
• État de la connexion ( saturée, à capacité
  réduite )

30
Modélisation UML
31
COMMUNICATION
32
Communication - MDD
33
Choix des langages

• Application serveur C
• Nombreuse classes pour traiter les Web Services,
  SOAP et les fichiers XML.
• Facilité pour développer, notamment lIHM.
• Portabilité restreinte univers Windows
  (cependant il existe une plateforme .NET libre
  Mono)
• Application client Java
• Portabilité, car il existe des machines
  virtuelles sur de nombreux types de supports
  (Laptop, PDA, Smartphone,)

34
Communication - ServeurTcp

• Travail de la semaine
• Création de la classe  ServeurTcp  en C
• Mise en place de multi-threading
• Gestion de plusieurs clients simultanément
• Possibilité de réaliser des actions et des
  calculs différents pour chacun des clients
• Création dune classe client en java
• Travail à venir
• Création des autres classes évoquées dans le
  modèle de données
• Négociation avec la couche  Intégration  pour
  le choix du protocole à utiliser

35
Lajout guidé de Web Services

• Ladministrateur ou la personne souhaitant
  ajouter un web service va fournir des
  informations sur ce web service au système via
  une interface
• Il fournira - entre autres - ladresse du fichier
  wsdl, les noms des entrées et des sorties, la
  requête à envoyer pour effectuer le traitement,
• Ladministrateur pourra choisir ces informations
  dans une liste créée par analyse du fichier wsdl
  lajout dun WS est guidée.

36
Exemple de WS

• http//www.amazon.com/AWS-home-pageMoney/b/refsmm
  _sn_aws/1025618853246546?ieUTF8node3435361
• Remarque apparemment les requêtes aux web
  services ne se font que par http

37
Conduite de projet

• Semaine du 15/09 au 21/09

38
Décisions importantes
39
Points durs
40
Suivi docs
41
Synthèse du planning général

• Général étude de la charge, sécurité
• Revue du CDC besoin client, architecture
• Fonctionnalités-services traitement pour
  lexécution dun service
• Interface admin création de linterface pour
  intégrer un web service
• Base de données création et programmation
• Communication création et gestion des profils
  de communication
• Présentation adaptation des données résultats
  au support
• Bilan bilan général sur WIB et la gestion de
  projet

42
Planning septembre au 15/09
43
Planning septembre au 21/09
44
Retour sur planning

• Tâches non achevées
• Non livraison de la documentation
• Besoin client, architecture
• Non validation par léquipe
• Exigences qualité, modèle de traitement général
• Tâches non effectuées
• Informations attendues des prototypes
• Compatibilité des données échangées, définition
  des caractéristiques utilisateurs à récupérer
• Priorité mise ailleurs
• Définition des tests, etude de la charge
• Retard sur les fonctionnalités-services
• Dû au remaniement du principe général
• gt Plus de ressources (Claire, Vincent, Fanny)

45
Autres retours

• Temps passé sur le thème transversal
• Données 3h
• Dictionnaire de données 4h
• Programmation affichage dune image en Java
• Temps utilisé
• 6jours 10heures
• Difficulté
• Java ne proposait rien de générique pour ce type
  daffichage
• Programme pas enregistré
• gt mettre en place un système de stockage des
  programmes valides et commentés
• Nécessité de mise à jour du blog