Au travers d’un portail et dans le futur

bien plus ambitieux que la seule émulation 5250. Certes
ces problèmes individuels trouvent de nombreuses
solutions, mais vous devez réfléchir à  la manière de tout
faire fonctionner ensemble. Comme je travaille moimême
à  la résolution de ces problèmes, je penche pour
le développement applicatif au moyen de WebSphere Portal.

Avec cette méthode, vos applications tirent leur substance
d’un service (le conteneur portail) situé au-dessus de
WAS (WebSphere Application Server). Le conteneur portail
fournit l’infrastructure pour les applications que vous développez,
sous l’aspect intégration, déploiement, sécurité, collaboration,
personnalisation et prise en charge des unités
avec et sans fil. Affranchis de cette infrastructure complexe,
les programmeurs peuvent se concentrer sur l’écriture des
applications proprement dites. Et ces dernières ne sont pas de simples versions GUI de ce que nous faisons déjà  en RPG.
Ainsi, en matière de collaboration, si un responsable du service
client consulte le solde d’un client et s’il a une question
à  propos d’une note introduite par un agent collecteur, le
responsable peut cliquer sur le nom de l’agent pour démarrer
une session de messagerie instantanée préremplie avec
les renseignements sur le client.
Pour vos utilisateurs, le portail est considéré comme leur
bureau. Vous écrivez des applications de type portail, appelées
« portlets », pour servir de briques à  vos applications de
gestion. L’idée est de fragmenter les applications en petits
portlets, largement indépendants puis, en bénéficiant des
possibilités d’intégration du portail, de combiner ces petits
composants en applications plus vastes. Les portlets communiquent
entre eux via des événements et des messages et
l’intégration se fait en grande partie par une
fonction administrative, et pas avec des liens
étroits dans votre code. Il s’en suit que pour
une page d’application donnée, vous pouvez
mélanger, associer et réutiliser des portlets –
sans écrire de code supplémentaire – à  un
degré que je n’avais jamais vu auparavant.
Depuis longtemps nous entendons parler
d’architectures à  base de composants, mais
l’approche portail est la première que j’ai vue
capable de construire des applications de
gestion back-office de qualité.
D’un point de vue technique, chaque portlet est essentiellement
un servlet Java, mais les portlets supportent l’API
du portlet, une API qui favorise l’architecture MVC
(Model/View/Controller). Pour le côté vue, ou présentation,
de vos portlets, vous utiliserez un langage markup ou des JSP
(Java Server Pages). A cause de la séparation distincte de la
logique de contrôle des portlets des vues JSP, le même code
contrôleur prend en charge les vues sur tous les types d’unités.
Pratiquement, cela signifie qu’un agent d’exploitation
sur le terrain peut utiliser un appareil sans fil pour consulter
le stock, avec une application obéissant à  la même logique de
gestion que l’application desktop à  part entière dont dispose
l’employé de l’entrepôt. Pour plus d’informations sur
WebSphere Portal, consultez les guides et white papers à 
www.ibm.com/developerworks/websphere/zones/portal.