Composants d'application client (client tiers)

Présentation au sujet: "Composants d'application client (client tiers)"— Transcription de la présentation:

1 Composants d'application client (client tiers)

2 Plan (1/3) Composants d'application client (client tiers)
Considérations sur les réseaux Considérations sur la sécurité Considérations sur la plate-forme d’exécution du client Règles de conception générales des clients J2EE

3 Plan (2/3) Règles de conception pour les navigateurs web
Présentation de l’interface utilisateur Validation des saisies utilisateur Communication Conserver les informations d’état Cookies Réécriture d'URL

4 Plan (3/3) Règles de conception des clients Java Résumé
Applications clientes Applets MIDlets Clients web Clients EJB Clients de serveurs d’entreprise Présentation de l’interface utilisateur Validation des saisies de l’utilisateur Communication avec le serveur Gestion des informations d’état Résumé

5 Composants d'application client (client tiers)
Du point de vue du développeur une application J2EE peut supporter de nombreux types de clients: stations de travails, assistants numériques, téléphones cellulaires… Ces clients peuvent accéder à l’application par l’intranet ou le World Wide Web, et par des médiums différents: connexions sans ou avec fil, ou combinaison des deux. Du point de vue de l’utilisateur, le client est l’application. Elle doit être utile, utilisable et avoir de bons temps de réponse. Les programmes d’exemples utilisés dans ce chapitre sont tirés de l’application d’exemple Java Pet Store, disponible en ligne sur le site de Sun, et du site web Java Blue Prints.

6 Considérations sur les réseaux
Les clients J2EE peuvent être connectés par de nombreux types de réseaux. La qualité de service sur ces réseaux peut varier considérablement, suivant le type de liaison (débit, connexion permanente ou intermittente). Trois aspects du réseau impactent le développement de la partie cliente : le temps de latence du réseau n’est pas nulle, la bande passante n’est pas infinie, le réseau n’est pas toujours fiable. Une application bien conçue prend en compte ces problèmes et leur apporte des solutions. Le client idéalse connecte au serveur uniquement lorsque c’est nécessaire, transmets le minimum de données et se comporte raisonnablement bien lorsque la connexion avec le serveur est rompue.

7 Considérations sur la sécurité
Chaque type de réseau comporte des mesures de sécurité différentes, qui limitent la façon dont se connectent les clients. Par exemple lorsque les clients se connectent par Internet, les communications transitent souvent par un firewall qui filtre laisse passer uniquement certains types de protocoles. La plupart des firewalls sont configurés pour laisser passer le protocole hypertexte (HTTP) mais pas l’Internet Inter-Orb Protocol (IIOP) utilisé pour transmettre des objets sur le réseau. Cet aspect incite à utiliser HTTP et non des services comme CORBA ou RMI qui utilisent le protocole IIOP pour le transport des données. Les contraintes de sécurité affectent aussi l’identification des utilisateurs: quand le client et le serveur sont dans le même domaine de sécurité, comme cela peut être le cas dans une application intranet, l’authentification peut être très simple et utiliser le système d’authentification de l’entreprise dans le cas d’une application Internet les mécanismes à mettre en place sont nettement plus sophistiqués. L’architecture J2EE propose des mécanismes standards pour l’authentification.

8 Considérations sur la plate-forme d’exécution du client
Chaque plate-forme cliente à des capacités propres qui influencent la conception de l’application. Par exemple un navigateur ne peut pas générer des graphiques et a besoin d’un serveur pour obtenir les graphiques sous forme d’images téléchargées à partir du serveur. Un client programmable peut télécharger uniquement les données numériques et construire lui-même un graphique. Une autre chose à prendre en compte est la prise en charge des formulaires par le client, qui varie suivant le type de terminal (grands écrans, souris et clavier sur une station de travail, petits écrans et boutons pour des téléphones portables…), et qui impose des limitations à la quantité de données manipulée par l’utilisateur sur son terminal. Une application qui gère plusieurs types de plates-formes doit mettre en place des stratégies spécifiques pour distribuer les ressources en fonction du type de terminal client.

9 Règles de conception générales des clients J2EE
L’architecture J2EE encourage l’utilisation de clients légers, ce qui n’empêchent pas d’accomplir plusieurs fonctions sur le client J2EE: présentation de l’interface utilisateur: les vues de l’application peuvent être téléchargées à partir du serveur (navigateur) ou traitée sur le client (application), validation des saisies de l’utilisateur: bien que le serveur d’EJB ou le serveur de données d’entreprise puissent vérifier eux aussi les données, une première validation peut avoir lieu sur le client, communication avec le serveur: quand l’utilisateur sollicite une fonction gérée par le serveur, le client doit envoyer une requête vers le serveur dans un protocole compréhensible par les deux parties, gestion des états de l’application: les applications doivent conserver des informations d’états sur ce que fait l’utilisateur dans l’application (garder trace que l’utilisateur effectue un processus particulier…) Les sections suivantes présentent les règles de conception pour les deux types de clients les plus répandus : les navigateurs web et les applications Java.

10 Règles de conception pour les navigateurs web
Les navigateurs sont le type de client le plus léger. Ils présentent les données à l’utilisateur et reposent sur le serveur pour les fonctionnalités de l’application. Du point de vue du déploiement de l’application, les navigateurs sont la solution la plus attrayante: ils permettent de mettre à jour l’application le plus facilement, quand l’application change seul le côté serveur est modifié, ils sont présent sur un très grand nombre de plates-formes, notamment sur les terminaux mobiles

11 Présentation de l’interface utilisateur 1/2
Les navigateurs téléchargent les documents à partir d’un serveur. Les documents contiennent les données ainsi que des instructions pour présenter les données. Ces documents sont en général construits dynamiquement à partir de pages JSP (et moins souvent à partir de servlets) et écrits dans un langage à balise tel que l’Hypertext Markup Language (HTML). Les langages à balises permettent d’avoir une présentation raisonnable quel que soit le navigateur utilisé. Il y a des alternatives à HTML particulièrement pour les terminaux mobiles (Wireless Markup Language (WML), Compact HTML, (CHTML), Extensible HTML (XHTML) Basic, et Voice Markup Language (VoiceML)).

12 Présentation de l’interface utilisateur 2/2
Les navigateurs présentent l’avantage d’avoir une interface familière pour les utilisateurs et d’être largement déployés en entreprise. L’inconvénient de ce type de client réside dans le manque de possibilité d’interactions avec l’utilisateur. Il est possible d’utiliser des technologies comme JavaScript en combinaison avec d’autres standards comme les Cascading Style Sheets (CSS) et le Document Object Model (DOM), on parle alors de Dynamic HTML (DHTML). Cependant le support de ces technologies est très inégal suivant les navigateurs, même si la situation tend à s’améliorer (Netscape 7, Internet Explorer 6). Un autre problème plus important est le temps de réponse potentiellement faible des navigateurs. Le client dépend du serveur pour la présentation donc il doit contacter le serveur à chaque modification de l’interface. Le client crée une connexion avec le serveur à chaque fois, ce qui peut induire des problèmes de temps de latence. Envoyer les informations de présentation en même temps que les données peut entraîner une plus grande consommation de bande passante.

13 Validation des saisies utilisateur
Si l’on considère un formulaire HTML, le navigateur ne peut pas appliquer de vérification des informations seul. Il est cependant possible d’inclure quelques vérifications simples sur le navigateur pour éviter des connexions inutiles vers le serveur. Il est possible d’utiliser des fonctions Javascript pour effectuer des vérifications sommaires avant l’envoi des données vers le serveur. Les fonctions Javascript peuvent être générées par des JSP par exemple. Les EJBs et le serveur de données doivent eux aussi valider les données, et on ne doit jamais faire exclusivement confiance au client pour la validation: celui-ci peut facilement être détourné.

14 Validation - Exemple Formulaire HTML :
<form name="account_form"method="POST" action=" onSubmit="return checkFamilyName();"> <p>Family name:<input type="text"name="family_name"></p> <!-...--> <p><input type="submit"value="Send it!"/></p> </form> Fonction Javascript de validation : <script language="JavaScript"> <!-- function checkFamilyName(){ var familyName = window.document.account_form.family_name.value; if (familyName ==""){ alert("You didn't enter a family name."); return false; } else { return true; } } --> </script>

15 Communication avec le serveur 1/2
Les navigateurs se connectent à une application J2EE par le web et pour cela utilisent le protocole http. Quand des interfaces de navigateurs sont utilisées dans une application, cela impacte la façon dont l’utilisateur interagit avec l’application: on utilise alors des hyperliens, des images et textes cliquables et des formulaires pour recueillir les actions de l’utilisateur. Le navigateur traduit ces actions en requêtes HTTP transmises au serveur web. Les requêtes de l’utilisateur pour demander des ressources sont en général des requêtes HTTP GET. L’URL des requêtes peut inclure des paramètres pour indiquer les données à envoyer. Par exemple la requête pour afficher tous les chiens dans l’application Pet Store est:

16 Communication avec le serveur 2/2
Les requêtes pour modifier des données sur le serveur sont en général des requêtes HTTP POST. Ce type de requête emploie le type MIME application/x-www-form-urlencoded . Par exemple une requête pour une commande peut utiliser l’URL: Le corps de la requête pourrait inclure la ligne suivante : action=add&itemId=EST-27 La Servlet API fournit une interface simple pour capturer les requêtes entrantes de type GET et POST et pour en extraire les paramètres. Après qu’un serveur a traité la requête d’un client, il doit retourner une réponse http qui contient en général un document HTML généré à partir de pages JSP.

17 Conserver les informations d’état
Comme HTTP est un protocole à base de requêtes et de réponses, chaque requête est traitée individuellement. Il a donc été nécessaire de développer des mécanismes pour identifier un client particulier et conserver l’état de la conversation avec le client. Une extension au protocole HTTP (HTTP State Management Mechanism) introduit la notion de session et d’état de session (session state). Une session est une séquence de demandes de services provenant d’un même utilisateur sur une courte durée. Les informations d’état d’une session permettent de conserver les informations d’une session entre plusieurs requêtes. Par exemple, un caddy utilise les informations d’état pour garder une trace des articles sélectionnés par l’utilisateur. Deux moyens existent pour maintenir les informations d’états avec un navigateur : les cookies et la réécriture d'URL.

18 Cookies Les cookies sont des données que le serveur envoie au client.
A chaque fois que le client envoie des informations au serveur, il inclut les cookies reçus du serveur . Malheureusement, certains utilisateurs désactivent les cookies, certains firewalls ou passerelles filtrent les cookies et certains navigateurs ne les prennent pas en charge. On ne peut donc pas toujours compter sur ce système pour conserver les informations de session. De plus seule une petite quantité d’information peut être stockée sur le client par ce moyen ( 4Ko est la taille habituelle supportée par les navigateurs)

19 Réécriture d'URL La ré-écriture d’URLs (URL rewriting) stocke les informations de session dans l’URL, ainsi lorsque l’utilisateur demande une URL les informations de session sont incluses dans l’URL. Cette technique peut être utilisée dans la plupart des environnements mais consomme plus de bande passante et demande au serveur de récrire l’URL à chaque requête, ce qui augmente la taille de la réponse envoyée au client Ces deux techniques sont vulnérables : les cookies sont stockés dans le système de fichiers du terminal de l’utilisateur, et un utilisateur malveillant pourrait les modifier. De plus les mécanismes de cache au niveau du client peuvent avoir des effets de bord, il faut donc veiller à permettre l’effacement des cookies.

20 Règles de conception des clients Java
Les clients Java peuvent être divisés en trois grandes catégories : les applications, les applets et les MIDlets. Ces trois types de clients utilisent des librairies communes mais diffèrent dans leur déploiement.

21 Applications clientes
Les applications clientes utilisent le Java 2 Runtime Environment, Standard Edition (JRE). Elles sont très similaires aux applications autonomes et dépendent moins des serveurs que les navigateurs. Les applications clientes sont distribuées dans des fichiers JAR et peuvent être explicitement installées sur les postes clients ou installées à la demande en utilisant la technologie Java Web Start.

22 Applets Les applets sont des composants qui prennent en charge l’interface utilisateur et s’exécutent dans un navigateur web. Elles dépendent plus d’un serveur que les applications et sont aussi distribuées sous forme de fichiers JAR. Les applets sont exécutées avec le Java Plug-In, qui fournit les mêmes classes que le JRE.

23 MIDlets Les MIDlets sont de petites applications programmées pour le Mobile Information Device Profile (MIDP), un jeu d’API Java qui en conjonction avec le Connected Limited Device Configuration (CLDC), fournit un environnement d’exécution Java 2 Micro Edition (J2ME) pour les terminaux mobiles. Ce type d’application est distribué dans un fichier JAR qui contient à la fois les classes et les ressources utilisées par l’application et avec un fichier de description de l’application (Java Application Descriptor (JAD) ).

24 Clients web Comme les navigateurs, les clients Java peuvent se connecter au serveur web d’une application J2EE en utilisant le protocole HTTP. Cela est particulièrement utile car c’est souvent le seul protocole disponible pour atteindre le serveur. Dans ce cas, à la différence des navigateurs qui transforment automatiquement les actions de l’utilisateur en requêtes HTTPs, c’est au développeur d’implémenter l’envoi des requêtes. L’un des aspects essentiels est le format des messages employé entre le client Java et le serveur.

25 Clients EJB Il est possible de créer une connection directe entre une application ou une applet Java et un serveur d’EJB, en utilisant des appels Remote Method Invocation (RMI). Ce type de communication n’est pas toujours possible, notamment lorsque les communications passent par Internet (firewalls) et que le protocole IIOP est filtré (ce protocole est utilisé pour le transport des appels RMI). Ce type de client requiert l’installation d’un conteneur EJB côté client sur le poste de l’utilisateur et ce type de client n’est pas encore clairement défini dans les spécifications EJB.

26 Clients de serveurs d’entreprise
Habituellement les clients Java ne communiquent pas directement avec les serveurs du système d’information de l’entreprise (bases de données, annuaires LDAP…) car un client mal configuré ou mal programmé pourrait endommager les données contenues dans le système d’information de l’entreprise. De plus ce type de client doit implémenter la logique métier de l’application et cela peut être difficile à implémenter suivant le type de clients.

27 Présentation de l’interface utilisateur
Bien qu’un client Java contienne l’interface de l’application, la logique derrière l’interface peut en fait provenir du serveur comme c’est le cas pour un navigateur ou être entièrement incluse dans l’application. C’est ce cas qui est présenté ici. Les applets et applications Java peuvent utiliser les Java Foundation Classes (JFC)/l’API Swing, un ensemble de composants pour la création d’interfaces client tandis que les MIDlets, utilisent la MIDP User Interface API, une API dédiée à la création d’interface pour des terminaux mobiles. La création d’interface pour des clients Java demande habituellement plus de travail que la création d’une interface de navigateur, mais les bénéfices ergonomiques sont substantiels et les capacités de programmation sont plus vastes. De plus ce type de client réclame moins de bande passante, car seules les données sont échangées entre le serveur et le client, la présentation étant prise en charge par ce dernier.

28 Validation des saisies de l’utilisateur
Les clients Java peuvent embarquer une partie de la logique applicative pour vérifier les données côté client et ainsi réaliser des vérifications plus poussées sur les données avant de les envoyer au serveur. Exemple: public void validateAll()throws ApplicationException { if (username.size()<4){ /*Complain about username being too short...*/ } if (password.size()<6){ /*Complain about password being too short...*/ } if (zipCode.size()!=5){ /*Complain about ZIP code not having 5 characters...*/ } if (creditCard.size()!=12){ /*Complain about credit card number not having 12 digits...*/ } } Évidemment la manière la plus simple de réduire les validations côté client consiste à rendre impossible la saisie de données erronées, par exemple en privilégiant l’utilisation de listes déroulantes et cases à cocher pour recueillir les informations de l’utilisateur.

29 Communication avec le serveur
Les clients Java peuvent accéder à l’application J2EE de plusieurs façons: en tant que client web, en passant par un serveur web en tant que client EJB, en communiquant directement avec un serveur d’EJB en tant que client du serveur d’entreprise, en se connectant directement aux serveurs du système d’information de l’entreprise

30 Envoi des données du client vers le serveur
Le client peut envoyer les données au serveur sous forme de flux binaire par exemple ou envoyer une liste des données séparées par des virgules par exemple: 1,Big and Badder,2,The Dot,4,Invasion of the Dots Ou le client peut utiliser des paires clés-valeurs : id=1,title="Big and Badder" id=2,title="The Dot" id=4,title="Invasion of the Dots“ Ou utiliser du XML : <movies> <movie><id>1</id><title>Big and Badder</title></movie> <movie><id>2</id><title>The Dot</title></movie> <movie><id>4</id><title>Invasion of the Dots</title> </movie> </movies> Les possibilités sont infinies, c’est au développeur de choisir le format des messages en fonction de l’application. L’utilisation de messages binaires consomme moins de bande passante.

31 Exemple de code pour émettre une requête binaire
Transmission du nom d’un utilisateur Code côté client : static final int LOGIN_USER =1; //... HttpConnection c; DataOutputStream out; String username,password; /*Construct the body of the HTTP POST request using out...*/ out.write(LOGIN_USER); out.writeUTF(username); out.writeUTF(password); /*Send the HTTP request...*/

32 Exemple de code pour récupérer une requête binaire
Servlet chargée de récupérer une requête binaire, côté serveur: public void doPost(HttpServletRequest req, HttpServletResponse resp)throws IOException,ServletException { /*Interpret the request.*/ DataInputStream in = new DataInputStream(req.getInputStream()); int command =in.readInt(); resp.setContentType("application/binary"); DataOutputStream out = new DataOutputStream(resp.getOutputStream()); byte command =in.read(); switch (command){ case LOGIN_USER: String username =in.readUTF(); String password =in.readUTF(); /*Check username and password against user database...*/ }

33 Communication en XML Les technologies Java pour XML permettent de simplifier l’opération de lecture d’une requête en XML, notamment en utilisant la Java API for XML Parsing (JAXP). L’API JAX-RPC permet de traiter automatiquement les messages XML, en utilisant le format Simple Object Access Protocol (SOAP). Cette possibilité réduit le temps de développement et les tests de cette partie de l’application. L’utilisation de XML permet de s’adresser à d’autres types de clients comme Flash ou StarOffice qui sont capable de lire certains dialectes de XML. Un client C++ peut aussi utiliser SOAP pour effectuer des appels de procédure distante (remote procedure calls (RPC)) vers une application J2EE. (cf. webservices)

34 Gestion des informations d’état
Là où les navigateurs demandent de robustes dispositifs côté serveur pour maintenir les informations de session, les clients Java peuvent gérer eux-mêmes les informations de session, car ils disposent de plus de ressources (mémoire). Il est ainsi possible d’implémenter des modes de fonctionnement non-connecté le client Java gardant en cache les informations nécessaires et les transmettant en temps utile au serveur. Cela implique que le client Java embarque une partie de la logique applicative et puisse mettre à jour les données lorsque l’utilisateur (ou un autre utilisateur de l’application) les modifie.

35 Résumé La plate-forme J2EE supporte une large gamme de terminaux d’accès et de stratégies de développement des parties clientes de l’application.