Une meilleure architecture avec MVC et Struts

Dans l’étape Meilleure Architecture, nous entamons la création d’une nouvelle
application, conçue dans les règles, qui utilise RPG ou Cobol modulaire
pour piloter une nouvelle interface utilisateur Web. J’entends déjà  l’une de
vos premières questions : « Que signifie conçue dans les règles ? ». Cela signifie
que l’application suit une séparation MVC, selon laquelle la logique de
gestion RPG ou Cobol est le modèle, les servlets WebSphere sont le contrôleur,
et les JSP (Java Server Pages) sont la vue. L’objectif est de réutiliser la
partie la plus importante, le modèle. Pour cela, ce dernier doit être aussi découplé
que possible de la vue et du contrôleur, afin de pouvoir le réutiliser
dans d’autres scénarios à  venir. Par exemple, pour piloter un appareil personnel
ou pour travailler en B-to-B (business-to-business) au moyen des
services Web.
La figure 1 montre un exemple de l’architecture applicative que nous recherchons.
Nous avons le code du modèle à  droite, dans le troisième niveau
(tier), et le code du contrôleur à  gauche, dans le second niveau (tier) s’exécutant
à  l’intérieur du WebSphere Application Server. Ce sont des niveaux
logiques, car ils pourraient se trouver sur le même système physique ou sur des systèmes différents. Il s’agit d’un choix que l’on peut
changer immédiatement parce que les deux parties de l’application
ne sont pas liées entre elles.
Nous l’avons dit, nous voulons que la logique du modèle
soit indépendante de celle du contrôleur. Cela signifie, par
exemple, qu’elle ne décidera pas explicitement du flux de
l’écran. Ce travail est effectué par le code
du contrôleur dans le servlet, qui décide
aussi quel élément de la logique de gestion
il faut invoquer pour une requête
donnée à  partir de l’utilisateur (c’est-à dire,
quand l’utilisateur appuie sur un
bouton).
Un servlet est simplement une classe
Java, mais qui a la particularité d’élargir
une classe de base particulière de telle
sorte qu’elle hérite du comportement du
serveur. Cela signifie qu’une certaine méthode est appelée
chaque fois que l’utilisateur appuie sur un bouton Submit sur
un formulaire Web qui est codé pour appeler le servlet. Nous
recommandons un servlet unique pour toute l’application.
Son travail consiste à  lire les données entrées par l’utilisateur
en provenance du formulaire et à  appeler la logique de gestion
appropriée, en lui transmettant ces données.

Ainsi, si nous appelons RPG ou Cobol, ces données sont
généralement transmises comme des paramètres d’entrée,
et les données sont renvoyées dans des paramètres de sortie.
La logique de gestion doit être accessible par l’intermédiaire
de Java, donc si elle est en RPG ou en Cobol, un habillage Java
est nécessaire. Il y a de nombreux moyens d’appeler RPG ou
Cobol à  partir de Java, y compris par l’intermédiaire de Java
Native Interface, par le biais de PCML (Program Call Markup
Language) dans l’iSeries Toolbox for Java, comme une procédure
stockée par l’intermédiaire de JDBC, et par le biais de
MQSeries. Toutes ces méthodes fonctionnent bien, mais la
plus répandue est PCML, suivie de près par les procédures
stockées.
Au retour de la logique de gestion, le servlet décide
quelle JSP il montrera ensuite, peut-être en analysant les
données renvoyées à  partir de la logique de gestion, puis
transfère le contrôle à  cette JSP, en le transmettant aux données
renvoyées de la logique de gestion. Une JSP est simplement
un HTML avec des tags spéciaux insérés pour extraire
des données à  partir d’un bean Java simple et pour insérer
ces données dans la page Web à  l’exécution, un peu comme
Workstation Data Manager fait avec les fichiers écrans et les
données d’applications.
La page Web résultante
est retransmise au navigateur
Web en attente
(que nous appelons niveau
1).
Il y aurait beaucoup
à  dire sur le reste du
contenu d’une JSP. Par
exemple, aujourd’hui
nous ne codons pas
souvent des tags HTML
directement. Nous utilisons
plutôt des bibliothèques
de tags, qui sont
des tags définis par l’utilisateur.
La spécification
JSP permet aux intéressés
de créer leurs propres tags en fournissant du code Java
qui produira HTML et JavaScript à  l’exécution, quand le moteur
JSP rencontrera le tag. Les tags peuvent prendre des attributs
qui influenceront la production.
Il existe aujourd’hui plusieurs bibliothèques de tags et la
communauté Java est en train de s’accorder sur un ensemble
de standards. Dans les outils Web de WebSphere Development
Studio Client, des extensions apportées au standard de
bibliothèque de tags peuvent rendre ces tags visibles dans l’éditeur Page Designer WYSIWYG
(What You See Is What You Get). Un
certain nombre de tags sont fournis
dans des palettes, pour vous simplifier
la tâche, dont un certain nombre
qui vous sont réservés en tant
que développeurs iSeries, comme
nous le verrons. Vous pouvez les
utiliser par un glisser-déposer et
vous pouvez utiliser la vue d’attributs
pour les configurer.
JavaScript est un code qui fonctionne
sur un navigateur Web. Il
ressemble à  Java mais est sensiblement
différent. JavaScript est plutôt
facile à  apprendre et à  utiliser, mais
les bibliothèques de tags sont de
plus en plus capables de générer ce
que nous voulons. Il est bon aussi
d’avoir quelques notions de CSS
(Cascading Style Sheets). Elles permettent
d’attribuer des polices et
des styles globaux à  des structures
particulières dans vos pages Web.
En les modifiant une fois, on affecte
immédiatement toutes les pages de
l’application. Elles simplifient nettement
la maintenance.
Bien qu’il soit facile et simple
d’apprendre HTML, JavaScript, et
CSS (collectivement connus sous le
nom de Dynamic HTML ou DHT
ML), c’est une chose que vous pouvez
remettre à  plus tard parce que
les outils sont suffisamment matures
dès aujourd’hui pour que
vous puissiez couvrir un terrain appréciable
avec peu ou pas de cette
connaissance. De plus, le fignolage
ultime des pages Web est souvent
laissé aux utilisateurs intéressés et
doués pour ce genre d’art, particulièrement
si les pages Web sont destinées
à  un usage public plutôt
qu’interne.