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

Composants d'application client (client tiers)

Présentations similaires


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) Composants d'application client (client tiers) Considérations sur les réseaux Considérations sur les réseaux Considérations sur la sécurité Considérations sur la sécurité Considérations sur la plate-forme dexécution du client Considérations sur la plate-forme dexécution du client Règles de conception générales des clients J2EE Règles de conception générales des clients J2EE

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

4 Plan (3/3) Règles de conception des clients Java Règles de conception des clients Java Applications clientes Applications clientes Applets Applets MIDlets MIDlets Clients web Clients web Clients EJB Clients EJB Clients de serveurs dentreprise Clients de serveurs dentreprise Présentation de linterface utilisateur Présentation de linterface utilisateur Validation des saisies de lutilisateur Validation des saisies de lutilisateur Communication avec le serveur Communication avec le serveur Gestion des informations détat Gestion des informations détat Résumé 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… 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 à lapplication par lintranet ou le World Wide Web, et par des médiums différents: connexions sans ou avec fil, ou combinaison des deux. Ces clients peuvent accéder à lapplication par lintranet 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 lutilisateur, le client est lapplication. Elle doit être utile, utilisable et avoir de bons temps de réponse. Du point de vue de lutilisateur, le client est lapplication. Elle doit être utile, utilisable et avoir de bons temps de réponse. Les programmes dexemples utilisés dans ce chapitre sont tirés de lapplication dexemple Java Pet Store, disponible en ligne sur le site de Sun, et du site web Java Blue Prints. Les programmes dexemples utilisés dans ce chapitre sont tirés de lapplication dexemple 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. 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). 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 : Trois aspects du réseau impactent le développement de la partie cliente : le temps de latence du réseau nest pas nulle, le temps de latence du réseau nest pas nulle, la bande passante nest pas infinie, la bande passante nest pas infinie, le réseau nest pas toujours fiable. le réseau nest pas toujours fiable. Une application bien conçue prend en compte ces problèmes et leur apporte des solutions. 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 cest nécessaire, transmets le minimum de données et se comporte raisonnablement bien lorsque la connexion avec le serveur est rompue. Le client idéalse connecte au serveur uniquement lorsque cest 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. 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. 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 lInternet Inter-Orb Protocol (IIOP) utilisé pour transmettre des objets sur le réseau. La plupart des firewalls sont configurés pour laisser passer le protocole hypertexte (HTTP) mais pas lInternet 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. 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 lidentification des utilisateurs: Les contraintes de sécurité affectent aussi lidentification 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, lauthentification peut être très simple et utiliser le système dauthentification de lentreprise 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, lauthentification peut être très simple et utiliser le système dauthentification de lentreprise dans le cas dune application Internet les mécanismes à mettre en place sont nettement plus sophistiqués. Larchitecture J2EE propose des mécanismes standards pour lauthentification. dans le cas dune application Internet les mécanismes à mettre en place sont nettement plus sophistiqués. Larchitecture J2EE propose des mécanismes standards pour lauthentification.

8 Considérations sur la plate-forme dexécution du client Chaque plate-forme cliente à des capacités propres qui influencent la conception de lapplication. Chaque plate-forme cliente à des capacités propres qui influencent la conception de lapplication. Par exemple un navigateur ne peut pas générer des graphiques et a besoin dun serveur pour obtenir les graphiques sous forme dimages téléchargées à partir du serveur. Par exemple un navigateur ne peut pas générer des graphiques et a besoin dun serveur pour obtenir les graphiques sous forme dimages 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. 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 lutilisateur sur son terminal. 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 lutilisateur 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. 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 Larchitecture J2EE encourage lutilisation de clients légers, ce qui nempêchent pas daccomplir plusieurs fonctions sur le client J2EE: Larchitecture J2EE encourage lutilisation de clients légers, ce qui nempêchent pas daccomplir plusieurs fonctions sur le client J2EE: présentation de linterface utilisateur: les vues de lapplication peuvent être téléchargées à partir du serveur (navigateur) ou traitée sur le client (application), présentation de linterface utilisateur: les vues de lapplication peuvent être téléchargées à partir du serveur (navigateur) ou traitée sur le client (application), validation des saisies de lutilisateur: bien que le serveur dEJB ou le serveur de données dentreprise puissent vérifier eux aussi les données, une première validation peut avoir lieu sur le client, validation des saisies de lutilisateur: bien que le serveur dEJB ou le serveur de données dentreprise puissent vérifier eux aussi les données, une première validation peut avoir lieu sur le client, communication avec le serveur: quand lutilisateur 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, communication avec le serveur: quand lutilisateur 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 lapplication: les applications doivent conserver des informations détats sur ce que fait lutilisateur dans lapplication (garder trace que lutilisateur effectue un processus particulier…) gestion des états de lapplication: les applications doivent conserver des informations détats sur ce que fait lutilisateur dans lapplication (garder trace que lutilisateur 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. 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 à lutilisateur et reposent sur le serveur pour les fonctionnalités de lapplication. Les navigateurs sont le type de client le plus léger. Ils présentent les données à lutilisateur et reposent sur le serveur pour les fonctionnalités de lapplication. Du point de vue du déploiement de lapplication, les navigateurs sont la solution la plus attrayante: Du point de vue du déploiement de lapplication, les navigateurs sont la solution la plus attrayante: ils permettent de mettre à jour lapplication le plus facilement, quand lapplication change seul le côté serveur est modifié, ils permettent de mettre à jour lapplication le plus facilement, quand lapplication 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 ils sont présent sur un très grand nombre de plates-formes, notamment sur les terminaux mobiles

11 Présentation de linterface utilisateur 1/2 Les navigateurs téléchargent les documents à partir dun serveur. Les navigateurs téléchargent les documents à partir dun serveur. Les documents contiennent les données ainsi que des instructions pour présenter les données. 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 lHypertext Markup Language (HTML). 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 lHypertext Markup Language (HTML). Les langages à balises permettent davoir une présentation raisonnable quel que soit le navigateur utilisé. Les langages à balises permettent davoir 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)). 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 linterface utilisateur 2/2 Les navigateurs présentent lavantage davoir une interface familière pour les utilisateurs et dêtre largement déployés en entreprise. Les navigateurs présentent lavantage davoir une interface familière pour les utilisateurs et dêtre largement déployés en entreprise. Linconvénient de ce type de client réside dans le manque de possibilité dinteractions avec lutilisateur. Linconvénient de ce type de client réside dans le manque de possibilité dinteractions avec lutilisateur. Il est possible dutiliser des technologies comme JavaScript en combinaison avec dautres standards comme les Cascading Style Sheets (CSS) et le Document Object Model (DOM), on parle alors de Dynamic HTML (DHTML). Il est possible dutiliser des technologies comme JavaScript en combinaison avec dautres 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 à saméliorer (Netscape 7, Internet Explorer 6). Cependant le support de ces technologies est très inégal suivant les navigateurs, même si la situation tend à saméliorer (Netscape 7, Internet Explorer 6). Un autre problème plus important est le temps de réponse potentiellement faible des navigateurs. 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 linterface. Le client crée une connexion avec le serveur à chaque fois, ce qui peut induire des problèmes de temps de latence. Le client dépend du serveur pour la présentation donc il doit contacter le serveur à chaque modification de linterface. 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. 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 lon considère un formulaire HTML, le navigateur ne peut pas appliquer de vérification des informations seul. Si lon considère un formulaire HTML, le navigateur ne peut pas appliquer de vérification des informations seul. Il est cependant possible dinclure quelques vérifications simples sur le navigateur pour éviter des connexions inutiles vers le serveur. Il est cependant possible dinclure quelques vérifications simples sur le navigateur pour éviter des connexions inutiles vers le serveur. Il est possible dutiliser des fonctions Javascript pour effectuer des vérifications sommaires avant lenvoi des données vers le serveur. Il est possible dutiliser des fonctions Javascript pour effectuer des vérifications sommaires avant lenvoi des données vers le serveur. Les fonctions Javascript peuvent être générées par des JSP par exemple. 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é. 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 : Formulaire HTML :

Family name: Family name:
Fonction Javascript de validation : Fonction Javascript de validation :

15 Communication avec le serveur 1/2 Les navigateurs se connectent à une application J2EE par le web et pour cela utilisent le protocole http. 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 lutilisateur interagit avec lapplication: on utilise alors des hyperliens, des images et textes cliquables et des formulaires pour recueillir les actions de lutilisateur. Quand des interfaces de navigateurs sont utilisées dans une application, cela impacte la façon dont lutilisateur interagit avec lapplication: on utilise alors des hyperliens, des images et textes cliquables et des formulaires pour recueillir les actions de lutilisateur. Le navigateur traduit ces actions en requêtes HTTP transmises au serveur web. Le navigateur traduit ces actions en requêtes HTTP transmises au serveur web. Les requêtes de lutilisateur pour demander des ressources sont en général des requêtes HTTP GET. Les requêtes de lutilisateur pour demander des ressources sont en général des requêtes HTTP GET. LURL des requêtes peut inclure des paramètres pour indiquer les données à envoyer. LURL 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 lapplication Pet Store est: Par exemple la requête pour afficher tous les chiens dans lapplication 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. 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. Ce type de requête emploie le type MIME application/x-www-form-urlencoded. Par exemple une requête pour une commande peut utiliser lURL: Par exemple une requête pour une commande peut utiliser lURL:http://javapetstore.sun.com/cart.do Le corps de la requête pourrait inclure la ligne suivante : 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. 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 quun serveur a traité la requête dun client, il doit retourner une réponse http qui contient en général un document HTML généré à partir de pages JSP. Après quun serveur a traité la requête dun 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. 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 dun même utilisateur sur une courte durée. Les informations détat dune session permettent de conserver les informations dune session entre plusieurs requêtes. 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 dun même utilisateur sur une courte durée. Les informations détat dune session permettent de conserver les informations dune session entre plusieurs requêtes. Par exemple, un caddy utilise les informations détat pour garder une trace des articles sélectionnés par lutilisateur. Par exemple, un caddy utilise les informations détat pour garder une trace des articles sélectionnés par lutilisateur. Deux moyens existent pour maintenir les informations détats avec un navigateur : les cookies et la réécriture d'URL. 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. 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. 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. 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. On ne peut donc pas toujours compter sur ce système pour conserver les informations de session. De plus seule une petite quantité dinformation peut être stockée sur le client par ce moyen ( 4Ko est la taille habituelle supportée par les navigateurs) De plus seule une petite quantité dinformation 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 dURLs (URL rewriting) stocke les informations de session dans lURL, ainsi lorsque lutilisateur demande une URL les informations de session sont incluses dans lURL. La ré-écriture dURLs (URL rewriting) stocke les informations de session dans lURL, ainsi lorsque lutilisateur demande une URL les informations de session sont incluses dans lURL. Cette technique peut être utilisée dans la plupart des environnements mais consomme plus de bande passante et demande au serveur de récrire lURL à chaque requête, ce qui augmente la taille de la réponse envoyée au client Cette technique peut être utilisée dans la plupart des environnements mais consomme plus de bande passante et demande au serveur de récrire lURL à 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 lutilisateur, et un utilisateur malveillant pourrait les modifier. Ces deux techniques sont vulnérables : les cookies sont stockés dans le système de fichiers du terminal de lutilisateur, 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 leffacement des cookies. De plus les mécanismes de cache au niveau du client peuvent avoir des effets de bord, il faut donc veiller à permettre leffacement 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. 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. 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). 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. 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. 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 linterface utilisateur et sexécutent dans un navigateur web. Les applets sont des composants qui prennent en charge linterface utilisateur et sexécutent dans un navigateur web. Elles dépendent plus dun serveur que les applications et sont aussi distribuées sous forme de fichiers JAR. Elles dépendent plus dun 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. 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 dAPI Java qui en conjonction avec le Connected Limited Device Configuration (CLDC), fournit un environnement dexécution Java 2 Micro Edition (J2ME) pour les terminaux mobiles. Les MIDlets sont de petites applications programmées pour le Mobile Information Device Profile (MIDP), un jeu dAPI Java qui en conjonction avec le Connected Limited Device Configuration (CLDC), fournit un environnement dexécution Java 2 Micro Edition (J2ME) pour les terminaux mobiles. Ce type dapplication est distribué dans un fichier JAR qui contient à la fois les classes et les ressources utilisées par lapplication et avec un fichier de description de lapplication (Java Application Descriptor (JAD) ). Ce type dapplication est distribué dans un fichier JAR qui contient à la fois les classes et les ressources utilisées par lapplication et avec un fichier de description de lapplication (Java Application Descriptor (JAD) ).

24 Clients web Comme les navigateurs, les clients Java peuvent se connecter au serveur web dune application J2EE en utilisant le protocole HTTP. Cela est particulièrement utile car cest souvent le seul protocole disponible pour atteindre le serveur. Comme les navigateurs, les clients Java peuvent se connecter au serveur web dune application J2EE en utilisant le protocole HTTP. Cela est particulièrement utile car cest souvent le seul protocole disponible pour atteindre le serveur. Dans ce cas, à la différence des navigateurs qui transforment automatiquement les actions de lutilisateur en requêtes HTTPs, cest au développeur dimplémenter lenvoi des requêtes. Dans ce cas, à la différence des navigateurs qui transforment automatiquement les actions de lutilisateur en requêtes HTTPs, cest au développeur dimplémenter lenvoi des requêtes. Lun des aspects essentiels est le format des messages employé entre le client Java et le serveur. Lun 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 dEJB, en utilisant des appels Remote Method Invocation (RMI). Il est possible de créer une connection directe entre une application ou une applet Java et un serveur dEJB, en utilisant des appels Remote Method Invocation (RMI). Ce type de communication nest 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 communication nest 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 linstallation dun conteneur EJB côté client sur le poste de lutilisateur et ce type de client nest pas encore clairement défini dans les spécifications EJB. Ce type de client requiert linstallation dun conteneur EJB côté client sur le poste de lutilisateur et ce type de client nest pas encore clairement défini dans les spécifications EJB.

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

27 Présentation de linterface utilisateur Bien quun client Java contienne linterface de lapplication, la logique derrière linterface peut en fait provenir du serveur comme cest le cas pour un navigateur ou être entièrement incluse dans lapplication. Bien quun client Java contienne linterface de lapplication, la logique derrière linterface peut en fait provenir du serveur comme cest le cas pour un navigateur ou être entièrement incluse dans lapplication. Cest ce cas qui est présenté ici. Cest ce cas qui est présenté ici. Les applets et applications Java peuvent utiliser les Java Foundation Classes (JFC)/lAPI Swing, un ensemble de composants pour la création dinterfaces client tandis que les MIDlets, utilisent la MIDP User Interface API, une API dédiée à la création dinterface pour des terminaux mobiles. Les applets et applications Java peuvent utiliser les Java Foundation Classes (JFC)/lAPI Swing, un ensemble de composants pour la création dinterfaces client tandis que les MIDlets, utilisent la MIDP User Interface API, une API dédiée à la création dinterface pour des terminaux mobiles. La création dinterface pour des clients Java demande habituellement plus de travail que la création dune interface de navigateur, mais les bénéfices ergonomiques sont substantiels et les capacités de programmation sont plus vastes. La création dinterface pour des clients Java demande habituellement plus de travail que la création dune 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. 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 lutilisateur 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. 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: Exemple: public void validateAll()throws ApplicationException { if (username.size()<4){ /*Complain about username being too short...*/ } if (username.size()<4){ /*Complain about username being too short...*/ } if (password.size()<6){ /*Complain about password 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 (zipCode.size()!=5){ /*Complain about ZIP code not having 5 characters...*/ } if (creditCard.size()!=12){ /*Complain about credit card number not having 12 digits...*/ } 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 lutilisation de listes déroulantes et cases à cocher pour recueillir les informations de lutilisateur. É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 lutilisation de listes déroulantes et cases à cocher pour recueillir les informations de lutilisateur.

29 Communication avec le serveur Les clients Java peuvent accéder à lapplication J2EE de plusieurs façons: Les clients Java peuvent accéder à lapplication J2EE de plusieurs façons: en tant que client web, en passant par un serveur web en tant que client web, en passant par un serveur web en tant que client EJB, en communiquant directement avec un serveur dEJB en tant que client EJB, en communiquant directement avec un serveur dEJB en tant que client du serveur dentreprise, en se connectant directement aux serveurs du système dinformation de lentreprise en tant que client du serveur dentreprise, en se connectant directement aux serveurs du système dinformation de lentreprise

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: 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 : 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 : Ou utiliser du XML : 1 Big and Badder 1 Big and Badder 2 The Dot 2 The Dot 4 Invasion of the Dots 4 Invasion of the Dots Les possibilités sont infinies, cest au développeur de choisir le format des messages en fonction de lapplication. Les possibilités sont infinies, cest au développeur de choisir le format des messages en fonction de lapplication. Lutilisation de messages binaires consomme moins de bande passante. Lutilisation de messages binaires consomme moins de bande passante.

31 Exemple de code pour émettre une requête binaire Transmission du nom dun utilisateur Transmission du nom dun utilisateur Code côté client : 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: 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.*/ /*Interpret the request.*/ DataInputStream in = new DataInputStream(req.getInputStream()); DataInputStream in = new DataInputStream(req.getInputStream()); int command =in.readInt(); int command =in.readInt(); resp.setContentType("application/binary"); resp.setContentType("application/binary"); DataOutputStream out = new DataOutputStream(resp.getOutputStream()); DataOutputStream out = new DataOutputStream(resp.getOutputStream()); byte command =in.read(); byte command =in.read(); switch (command){ switch (command){ case LOGIN_USER: case LOGIN_USER: String username =in.readUTF(); String username =in.readUTF(); String password =in.readUTF(); String password =in.readUTF(); /*Check username and password against user database...*/ /*Check username and password against user database...*/ }}

33 Communication en XML Les technologies Java pour XML permettent de simplifier lopération de lecture dune requête en XML, notamment en utilisant la Java API for XML Parsing (JAXP). Les technologies Java pour XML permettent de simplifier lopération de lecture dune requête en XML, notamment en utilisant la Java API for XML Parsing (JAXP). LAPI 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 lapplication. LAPI 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 lapplication. Lutilisation de XML permet de sadresser à dautres types de clients comme Flash ou StarOffice qui sont capable de lire certains dialectes de XML. Lutilisation de XML permet de sadresser à dautres 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) 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). 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 dimplé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. Il est ainsi possible dimplé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 lutilisateur (ou un autre utilisateur de lapplication) les modifie. Cela implique que le client Java embarque une partie de la logique applicative et puisse mettre à jour les données lorsque lutilisateur (ou un autre utilisateur de lapplication) les modifie.

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


Télécharger ppt "Composants d'application client (client tiers)"

Présentations similaires


Annonces Google