Passer au contenu

Gérer la diversité des accès fixes et mobiles

Les serveurs d’applications multiterminaux gèrent la disparité des postes clients fixes et mobiles, voire des réseaux par lesquels ils sont connectés. En fonction de ces variables, des traitements spécifiques sont déclenchés.

Lorsqu’on envisage de garantir la pérennité et la marge de progression d’un futur Intranet mobile, il est préférable d’appréhender globalement l’évolution concomitante des tuyaux, des terminaux et des applications. Les premiers passent aujourd’hui du mode circuit (GSM) au mode paquet (GPRS), tandis que l’UMTS est en point de mire. Les débits nominaux sur le lien radio entre le terminal GPRS et le réseau passent de 9 600 bits/s à plusieurs dizaines de kilobits par seconde. Les terminaux commencent à être construits sur la base de systèmes d’exploitation évolués et adopteront de grands écrans tactiles en couleurs. Les applications mobiles peuvent et doivent exploiter ces technologies, pour offrir davantage de fonctions et améliorer leur ergonomie. Elles se rapprocheront ainsi de la richesse des applications traditionnelles sur PC, tout en tirant parti de la mobilité.

Des traitements spécifiques sont déclenchés

Les serveurs d’applications multiterminaux apparus chez IBM, Oracle ou BEA Systems commencent à offrir des réponses à cette problématique. Ces offres sont basées sur des serveurs d’applications ciblant jusqu’alors le monde de l’Intranet traditionnel. Dès lors, les différents types de postes clients sont placés au même niveau. Ainsi, ils profitent de l’ouverture et des capacités de montée en charge ou de haute disponibilité du serveur d’applications. Sans pour autant être traités pareillement.Lorsqu’un terminal se connecte à un tel serveur, celui-ci l’identifie et déclenche les traitements applicatifs qui lui sont spécifiques. Avec certains serveurs, le type de réseau et le débit disponible sont également pris en compte. Ensuite, le terminal et l’application interagissent traditionnellement, le serveur d’applications se chargeant d’aiguiller les réponses aux requêtes, vers le bon réseau, en passant par la passerelle WAP-SMS. Des serveurs supportent, en outre, le mode déconnecté des PDA, en lançant une procédure de synchronisation avec, par exemple, une base de données embarquée.Les traitements permettant de prendre en compte les spécificités des terminaux et des réseaux se présentent généralement sous la forme de servlets Java, qui génèrent un code XML intermédiaire adapté à chaque grande catégorie de terminaux. Ces traitements sont de différentes natures, selon que l’on souhaite adapter des applications existantes ou en développer de nouvelles. Dans le premier cas, il s’agit d’extraire un contenu ou un flux HTML, XML ou 3270 et de le convertir à la volée, dans le format XML intermédiaire précité. Cette méthode, dont la mise en ?”uvre est souvent facilitée par un outil de développement interactif, permet de démarrer rapidement un Intranet mobile, dont l’ergonomie et les capacités d’évolution seront toutefois limitées.

Développer une couche pour englober les mobiles

Il est donc conseillé de développer une couche entièrement nouvelle, permettant de cibler les terminaux mobiles. Son rôle consistera à générer un flux XML adapté aux formats d’affichage, mais aussi à décrire une logique applicative spécifique, prenant, par exemple, en compte la localisation de l’utilisateur. En amont, cet effort sera minimisé, en capitalisant sur des données au format SQL, ou mieux, XML, ainsi que sur des composants métiers. Dès lors, on pourra exploiter les réseaux et terminaux du futur en ne remettant en cause qu’une petite partie des développements. Un effort d’autant plus modeste que la complexité des applications mobiles sera longtemps limitée par les capacités des terminaux. Il sera ensuite temps de réaliser des applications plus riches mais aussi plus pérennes.Quel que soit le type d’application, des feuilles de styles XSL, dont l’éditeur du serveur fournit des exemples, produisent, à partir du format XML intermédiaire, un flux adapté à chaque modèle de client. Il s’agit certes de générer du WML adapté aux terminaux WAP, du HTML pour les PC, ou du HTML dépouillé pour les PDA. Mais il faut aussi se conformer au format de chaque téléphone WAP ou navigateur pour PDA. Les implémentations du standard WAP sont souvent particulières. Ce problème devrait être réduit par la version WAP 1.2, qui apportera la notion de User Agent Profil, permettant au terminal de communiquer ses caractéristiques ergonomiques.

WAP se diluera dans les standards d’Internet

En masquant les spécificités des terminaux et des réseaux par lesquels ils sont connectés, ces serveurs préfigurent la convergence de WAP, d’IP et de HTML, qu’ils intégreront le moment venu. À moyen terme, WAP 2.0 s’inscrira dans un ensemble de standards plus généraux, dont il ne sera qu’un représentant. Les couches actuelles de WAP seront remplacées par IP et HTTP, rendant inutile la fonction de traduction des passerelles WAP. Tandis que l’affichage à l’écran d’applications fixes ou mobiles sera réalisé via X-HTML, dont les modules cibleront les différents terminaux. L’un d’entre eux générera ainsi un format WML 2.0.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Lévy-Abégnoli