Interface utilisateur

bouton (ou exécute diverses
autres actions) puis restitue le HTML (ou XML) et autres
données envoyées comme réponse par l’application.
Le serveur Web examine les requêtes HTTP entrantes et, en se fondant sur les données de configuration de serveur
Web spécifiées précédemment, peut renvoyer des données
statiques ou transmettre la requête au conteneur Web pour
qu’il la traite. Quand le conteneur Web reçoit une requête, il
utilise ses propres données de configuration (y compris les
éléments spécifiés quand vous déployez une application J2EE) pour déterminer quels servlets applicatifs exécuter. En
termes simples, un servlet est un programme Java qui met en
oeuvre un ensemble de méthodes J2EE standard (procédures,
par exemple) que le conteneur Web peut appeler. Le
conteneur Web transfère le contrôle au servlet en appelant
l’une des méthodes standard, par exemple, goGet ou doPost.
Le conteneur Web transmet les données d’entrée utilisateur
(qui font partie de la requête HTTP reçue du navigateur)
au servlet, via les paramètres de l’une des méthodes appelées.
Le servlet peut valider et traiter les données d’entrée de
diverses manières, y compris en appelant des méthodes dans
d’autres programmes Java ou divers types comme d’autres
servlets, des JSP, des POJO (plain old Java objects) et des EJB.
(Un POJO est un objet Java sans genre particulier,
comme un servlet ou un EJB.)
Une fois que l’application J2EE (à  savoir
le servlet initial et les éventuels programmes
qu’il invoque) a produit les données
de sortie, elle doit composer un flux
de texte combinant les données de sortie
« brutes » sous forme de caractères avec
des tags HTML (ou XML) pour définir une
page Web. Un servlet d’application (celui
qui a été invoqué initialement ou un
autre) appelle une méthode standard
fournie par le conteneur Web pour passer le flux au serveur
Web, lequel met ensuite le flux dans une réponse HTTP renvoyée
au navigateur.
En principe, un développeur J2EE ne code pas à  la main
des instructions Java pour toutes les étapes nécessaires pour
combiner des données de sortie d’application et des tags
HTML. Il est beaucoup plus simple de coder un JSP, un fichier
source qui contient des tags HTML, des tags JSP spéciaux, et
des snippets de code Java. Le
conteneur Web convertit le
JSP source en pur Java source
pour un servet. Dans le code
généré, on utilise des littéraux
chaînes de caractères
Java pour contenir les tags
HTML et les autres éléments
constants du flux de sortie
HTTP produit par le servlet.
Le conteneur Web compile
également le servlet généré
et c’est en fait le servlet compilé
qui s’exécute quand une
application invoque le JSP.
Après avoir « écrit » une
page Web (c’est-à -dire, avoir
envoyé une réponse HTTP au
navigateur), une application
ITP J2EE (c’est-à -dire, l’un de
ses servlets ou JSP) ne se
contente pas d’exécuter une
opération « read » et d’attendre
une entrée utilisateur
en un point précis du code applicatif, comme le ferait une application
ITP iSeries traditionnelle. Au lieu de cela, une application
J2EE renvoie le contrôle au conteneur Web pour attendre
que la requête suivante arrive en provenance du
navigateur.
Dans une application ITP J2EE classique, le navigateur
rend la sortie de l’application et accepte l’entrée de l’utilisateur.
Contrairement à  une unité ou émulateur 5250, un navigateur
ne maintient pas une connexion avec l’application et
celle-ci ne peut pas limiter les actions de navigation qu’un
utilisateur entreprend. Ainsi, un utilisateur peut sauter directement vers différents écrans d’application via la fonction
« Web page history » d’un navigateur, et ce indépendamment
de l’endroit où l’utilisateur se trouve dans le flux prévu
de l’application. Un utilisateur peut aussi taper directement
une URL qui fait référence à  un servlet d’application. La
conséquence est qu’une application ITP J2EE ne peut jamais
prévoir quelle partie de l’application une requête utilisateur
tentera d’exécuter pas plus qu’elle ne peut compter sur le
système pour suivre le point d’exécution courant dans
l’application.
Face à  ce genre d’interface utilisateur pilotée par événements,
une méthode classique consiste à  coder un servlet
unique qui servira de frontal pour l’application. (Ce servlet
est parfois appelé « contrôleur »). Quand l’application est déployée,
le conteneur Web est configuré pour diriger vers ce
servlet toutes les requêtes possibles qui pourraient résulter
de l’action utilisateur sur les pages Web de l’une des applications
(ou même du fait que l’utilisateur tape une URL). Un
développeur doit coder le frontal (ou les programmes subordonnés)
pour examiner la requête et déterminer la suite
des événements. Comme le montre le diagramme de la figure
2, le servlet frontal appellera en principe des méthodes
d’aide dans un certain POJO pour décider quelle opération
de l’application est demandée et pour effectuer une validation
basique des données entrées. Si l’opération ou les données
sont invalides, le frontal invoque un JSP pour formater
une page d’erreur et la renvoyer comme réponse.
Pour une requête valide, le frontal appelle la méthode appropriée
dans un stateful session EJB. Un stateful session EJB
est le code J2EE central qui contrôle le flux de l’application
ITP, invoquant les POJO, les autres EJB, ou les API J2EE pour
d’autres types de ressources, pour extraire et mettre à  jour
des données et pour effectuer des calculs de gestion. Le stateful
session EJB suit la position logique de l’utilisateur dans
le flux de l’application et maintient, comme variables de programme,
les données spécifiques à  la session.
Ce stateful session EJB renvoie le résultat de l’opération
demandée (y compris les données normales et d’exception)
au frontal. Une donnée complexe, comme une « commande
» est renvoyée comme un ou plusieurs objets Java. Le
frontal invoque ensuite le JSP approprié pour formater le
résultat et renvoyer soit une page avec des résultats normaux,
soit une page d’erreur
Comme il n’y a pas de connexion permanente entre un
navigateur et une application, le conteneur Web utilise des
cookies (ou autres mécanismes) pour suivre les sessions actives
individuelles pour chaque application. Une session est
simplement le mécanisme J2EE permettant de suivre, au travers
de multiples cycles requête/réponse HTTP, un utilisateur
particulier pendant sa navigation dans une application.
Quand un servlet est exécuté, il peut appeler
une méthode standard pour extraire
l’identité attribuée par le système de la session
qui exécute actuellement le servlet.
Une application ITP utilise en principe
l’authentification J2EE (comme nous le
verrons plus loin dans la section Sécurité),
donc elle peut aussi appeler une méthode
standard pour extraire l’identité d’un utilisateur.
Ainsi, le support de session J2EE
offre au moins une possibilité de base
pour maintenir une association logique
entre une application et un utilisateur. C’est là  une situation
que l’on tient pour acquise quand on écrit une application
HLL avec une interface utilisateur 5250.
Pour des raisons de performances, le conteneur Web
n’invoque généralement qu’une seule copie d’exécution du
servlet frontal d’une application (ainsi que d’autres servlets
et JSP). Le conteneur Web utilise de multiples threads pour
prendre en charge des utilisateurs simultanés. L’utilisation
de threads vous conduit à  écrire le code servlet d’une manière
thread-safe. Entre autres implications, les servlets ne
peuvent pas stocker des données spécifiques à  une session
(par exemple, l’élément courant visualisé dans un catalogue)
dans des variables de programme.
Heureusement, les stateful session EJB sont thread-safe
et peuvent stocker des valeurs dans leurs variables de programmes
au travers de multiples requêtes HTTP. Cela permet
de concevoir une application ITP de manière à  avoir un objet
stateful session EJB distinct pour la session de chaque utilisateur.
Avec un stateful session EJB, vous pouvez stocker des
données spécifiques aux sessions dans des variables de programme
de la même manière que vous le feriez dans un programme
HLL interactif iSeries.
Le seul hic à  l’utilisation de stateful session EJB est que le
servlet frontal doit suivre quel objet EJB est associé avec
chaque session utilisateur. Pour cela, le servlet peut appeler
des méthodes de conteneur Web standard pour stocker une
référence dans le stateful session EJB de l’utilisateur dans les
données de session du conteneur Web. (Le stockage des
données de session sur le conteneur Web est plus encombrant
et moins efficace que l’utilisation d’un stateful session EJB, donc vous devriez généralement
utiliser des stateful session EJB pour
stocker la plupart des données de session
autres que cette référence EJB.)
Je me suis cantonné aux principaux
aspects de la partie interface utilisateur
d’une application ITP J2EE. Assez pour
voir que ce n’est pas simple. Les
programmeurs qui adoptent des techniques
J2EE après avoir travaillé avec
des applications ITP iSeries traditionnelles
jugeront peut-être que la
programmation par servlet est lourde
pour traiter des utilisateurs interactifs
multiples.
L’industrie s’attaque de plusieurs
manières à  la complexité de cette interface
utilisateur. JSF (JavaServer
Faces) est un standard J2EE permettant
de spécifier des éléments d’interface
utilisateur de plus haut niveau
dans les JSP, et Struts est un cadre
open-source pour spécifier plus
facilement la structure d’interface utilisateur,
y compris la disposition, la validation
des entrées, le flux des applications,
et le traitement des erreurs.
Une application ITP J2EE classique utilisera
probablement à  la fois JSF et
Struts (voir l’article « Strut : un bon
truc » pour plus d’informations sur
Struts).
Un conteneur de portail (un autre
produit d’exécution qui fonctionne sur
un serveur WAS hôte) et des portlets
(des servlets qui implémentent quelques
méthodes standard supplémentaires)
sont un autre moyen de plus
haut niveau pour composer une interface
utilisateur basée sur navigateur
qui donne accès à  des applications
J2EE séparées, parfois coopérantes.