La génération de documents

Transcription

1 ECOLE POLYTECHNIQUE FEDERALE DE LAUSANNE La génération de documents PDF depuis un serveur applicatif Introduction Dans bien des applications de type Web, il est nécessaire de générer des documents au format PDF ( com/products/acrobat/adobepdf.html). En effet bien que l interface utilisateur de type HTML soit parfaite lors de sessions interactives, il est important de pouvoir fournir à l utilisateur certaines pages dans un format imprimable. Nous allons ici rapidement passer en revue les possibilités offertes, puis détailler une solution choisie aux Hôpitaux Universitaires de Genève à la division d informatique médicale. Principes et solutions de génération de documents PDF Principes Il y a plusieurs manières de créer un document en PDF. En effet, un document PDF n est en fait qu une description lisible par un être humain d ordres de dessins (lignes, remplissages, textes, fontes, etc.). Le format PDF est d ailleurs inspiré du Postscript, avec la possibilité de programmation Alexander.Lamb@dim.hcuge.ch & Nicolas.Cassoni@dim.hcuge.ch, Hôpitaux Universitaires de Genève en moins. Bien que lisible (sauf dans la version encryptée) le format ne permet pas à un être humain de le générer à la main comme pour un fichier HTML par exemple. En effet, non seulement le format est complexe, mais un système de dictionnaire interne au format nécessite le positionnement des instructions au byte près! Ainsi, il est possible au travers de librairies spécialisées de générer directement un document PDF avec des fonctions dans le genre de createdocument, addtextwithfontatposition, drawlinefromto, etc. Toutefois, attaquer le problème à un si bas niveau s avère en général fastidieux. Les problèmes de calcul de sauts de pages, de positionnement des éléments graphiques, et (non des moindres) de formatage d un bloc de texte en plusieurs lignes avec césures de mots, restant du ressort de l application appelant ces fonctions. Il est également possible en utilisant divers logiciels disponibles soit commercialement soit en OpenSource, de convertir des pages du format HTML au format PDF. Toutefois, cette solution, Suite en page 7 Sommaire FI 1/ La génération de documents PDF depuis un serveur applicatif 2 Cellule AFS epfl.ch en service public 2 Propriétaires de noms de domaines: ayez l oeil sur vos contrats! 2 Poste pour jeune chercheur 3 Réseaux IP Voix et multimédia sur IP 11 Un projet pionnier de Voice over IP (VoIP) au Centre Cantonal des Télécommunications (CCT) 13 igames Implémentation d un service de jeu en réseau employant les agents mobiles 17 Programme des cours 21 FileMaker Pro 5.5 ou 6.0 Sésame ouvre-toi! 23 SWITCH en vitesse 24 Calendrier Prochaines parutions délai rédaction parution SP FI 1-21 janvier 2003 page 1

2 Cellule AFS epfl.ch en service public (A single, shared name space for all users, from all machines) SIC Dans le Flash informatique du 19 novembre 2002 ( j informais sur la mise en place de la cellule AFS de notre Ecole et sur sa phase de démarrage. Dorénavant notre cellule AFS epfl.ch avec son premier serveur des fichiers afs1 est ouverte pour le service public. Elle est dédiée dans sa phase initiale d exploitation en priorité aux étudiants de l EPFL et à leurs responsables informatiques. Pour coordonner l ouverture des comptes, ces responsables sont priés de me contacter. AFS Home Directory Je rappelle que l utilisateur AFS a son Unix home-directory de la forme /afs/epfl.ch/users/x/xuser-name où x est la première lettre de son user-name ( exemple : /afs/epfl.ch/ users/a/alinghi ) AFS authentification La validation AFS doit se faire à travers Gaspar (http: //gaspar.epfl.ch) AFS Client L installation du client AFS pour chacune des quatre plate-formes : Linux, Mac OS X, Solaris 8 et Windows NT/ 2000/XP est expliquée à l adresse: sic.epfl.ch/se/afs/ Propriétaires de noms de domaines: ayez l oeil sur vos contrats! Richard.Timsit@epfl.ch, SIC Les noms de domaine sont une véritable marchandise qui se négocie sur Internet à la vitesse de l éclair. Faites donc bien attention à la gestion de votre nom de domaine en payant vos factures dans les temps et à l unité accréditée par l ICANN qui vous a enregistré. Les rappels en provenance de Verisign ou autres prestataires auprès de qui vous avez réservé votre domaine, ressemblent étrangement (serait-ce volontaire?) à du spam, et si vous n êtes pas attentifs, ils pourraient bien passer à la poubelle! Toute négligence dans le respect de votre contrat sera très difficilement réparable. Votre nom de domaine peut être racheté dans la seconde où expire votre contrat d achat n importe où sur la planète. Des outils bien sophistiqués sont à disposition pour ce genre de coup. Un grand vide juridique touche ce domaine, à vous d avoir le vertige! Poste pour jeune chercheur Le Laboratoire de génie logiciel de l Ecole polytechnique fédérale de Lausanne offre un poste d assistant-doctorant en informatique Le collaborateur participera aux travaux de recherche du Laboratoire et à ses tâches d enseignement. L activité de recherche est censée déboucher sur un doctorat. Les activités de recherche du Laboratoire se concentrent sur les méthodes de développement de logiciel et les outils associés. En se basant sur l approche orientée objets, nous couvrons toutes les activités de développement: analyse, spécifications formelles, conception, programmation et test. Le Laboratoire possède une excellente expertise dans le Unified Modeling Language (UML), y compris le Object Constraint Language (OCL), et la méthode Fondue. Nos travaux de recherche en méthodes orientées objets visent à incorporer des méthodes formelles (spécifications algébriques et réseaux de Petri) dans des approches classiques descriptives, en étendant ces derniers aux systèmes répartis. L intégration des aspects relatifs aux transactions et au middleware dans tout le cycle de développement, y compris la spécification et l architecture, est une de nos préoccupations. Des projets en cours traitent de l animation de modèles UML et de la génération automatique de cas de test à partir de spécifications écrites en UML. D autres informations sur le Laboratoire se trouvent sur son site Web: Formation exigée: diplôme EPF ou titre universitaire (DEA ou master) en informatique. Langues: français (oral) et anglais (oral et écrit). Entrée en fonction: à convenir. Les candidatures, accompagnées des pièces usuelles (lettre de postulation, CV, copies des diplômes, etc.), sont à envoyer à: Prof Alfred Strohmeier, Laboratoire de génie logiciel, EPFL-IC-LGL, CH-1015 Lausanne Tél , Fax mailto:alfred.strohmeier@epfl.ch Flash informatique Les articles ne reflètent que l opinion de leurs auteurs. Toute reproduction, même partielle, n est autorisée qu avec l accord de la rédaction et des auteurs. Rédacteur en chef: Jacqueline Dousson, fi@epfl.ch Mise en page & graphisme: Appoline Raposo de Barbosa Comité de rédaction: Omar Abou Khaled, Jean-Daniel Bonjour, Nicolas Bouche, Milan Crvcanin, Jean-Damien Humair, Pierre Kuonen, Jacques Menu, Elaine Mc Murray, Philippe Pichon, Daniel Rappo, François Roulet, Christophe Salzmann & Jacques Virchaux Impression: Atelier de Reprographie EPFL Tirage: 4000 exemplaires Adresse Web: Adresse: SIC-SA EPFL, CP 121, CH-1015 Lausanne Téléphone: & FI 1-21 janvier 2003 page 2

3 Réseaux IP Voix et multimédia sur IP Antoine Delley, EIA-FR, département des technologies de l information, delley@eif.ch Les réseaux de télécommunications représentent l épine dorsale informationnelle des entreprises et, par extension, de l économie. En raison de la forte concurrence qui règne dans le domaine des télécommunications, l offre en technologies d accès et en services est très large. Malheureusement, elle pèche souvent par manque de transparence. Du 18 au 22 octobre 2002, un symposium international destiné aux responsables de la planification et de l exploitation d infrastructures publiques de télécommunications a livré un aperçu de la situation. Des représentants de plus de trente pays, invités par l Union internationale des télécommunications ( ont participé à ce symposium mis sur pied par ICTnet ( et l EIA-FR ( Architecture du réseau Le réseau peut être subdivisé en deux parties distinctes, le réseau de transit et le réseau d accès (fig. 1). Les exigences posées par les applications ont une incidence directe sur les technologies qui seront mises en œuvre, aussi bien au niveau de l épine dorsale que sur l accès d usager. Un réseau universel doit satisfaire à un faisceau d exigences, souvent contradictoires. Le principal dilemme est la priorisation des applications en temps réel par rapport au transfert de données. La téléphonie et les applications multimédias de communication synchrone requièrent des caractéristiques temps réel. Le temps total de transfert de l information entre deux interfaces d usagers ne devrait pas dépasser 200 ms sur une liaison intercontinentale, codage de l information compris. Cette exigence ne peut pas être satisfaite par les réseaux IP conventionnels, sans mécanisme de contrôle de la qualité de service. De telles applications fonctionnent généralement avec un débit constant (p. ex. 64 kbit/s pour la parole codée selon G.711). Elles tolèrent sans difficulté un temps d établissement de la communication de plusieurs centaines de ms. Le transfert de données et les applications Internet traditionnelles sont beaucoup plus tolérantes eu égard à la transparence temporelle. Elles génèrent des débits variables, de quelques bits/s à plusieurs Mbits/s. Elles sont, par contre, très sensibles au temps d établissement de la communication. fiig.1 Architecture du réseau FI 1-21 janvier 2003 page 3

4 Réseaux IP voix et multimédia sur IP Différentes qualités de service peuvent être implémentées sur les réseaux IP. La version la plus simple est la qualité Best effort, c est-à-dire, sans gestion aucune de la qualité. Ce cas est le plus répandu dans les Intranets et il est généralisé sur l Internet. A l autre extrême, les réseaux IP peuvent offrir un service garanti, avec réservation des ressources. La communication multimédia est possible sur divers types de réseaux. Afin d assurer la compatibilité entre applications, l UIT (Union Internationale des Télécommunications) et l IETF (Internet Engineering Task Force) ont élaboré des familles de standards regroupés sous les appellations génériques H.32x, SIP (Session Initiation Protocol) et MGCP (Media Gateway Control Protocol). Concept VoIP basé sur H.323 Avec H.323, l UIT a spécifié un environnement complet de protocoles de communication multimédias pour les réseaux IP. L interfonctionnement avec les autres réseaux est garanti car des standards apparentés ont été conçus: H.320 pour le RNIS et H.324 pour le réseau téléphonique analogique. H.323 est supporté par la quasi-totalité des constructeurs. Il est, pour cette raison, très largement utilisé comme protocole d interfonctionnement. fig. 2 types de qualités de service dans les réseaux IP La figure 2 livre une vue d ensemble des diverses qualités de service et des mécanismes mis en œuvre pour y parvenir. Ce tableau donne un aperçu réducteur. Il n aborde que les mécanismes mis en œuvre tout au travers du réseau, entre ses points d extrémité. En plus, pour offrir une qualité de service donnée, il ne suffit pas de mettre en place un mécanisme à une seule couche. A titre d exemple, la mise en œuvre de services synchrones pour des applications en temps réel, comme la téléphonie, requiert non seulement l usage des protocoles RTP/RTCP, mais également des mécanismes de priorisation et de réservation des ressources dans les couches inférieures. Voix et multimédia sur IP Jusque vers le milieu des années 90, les organismes de normalisation ont tenté de transmettre les données de manière toujours plus efficace sur des réseaux conçus pour la téléphonie. A partir de cette date, il y a eu changement de paradigme. C est sur les réseaux de données, en particulier sur l Internet, que l on s est évertué à convoyer la parole. Il a donc fallu développer des algorithmes de codage audio plus tolérants et introduire des mécanismes de contrôle de la qualité de service dans les réseaux de données. fig. 3 topologie d un réseau VoIP (Voice over IP) fig. 4 architecture des protocoles selon H.323 Dans un environnement H.323, l établissement de la communication est effectué au moyen du protocole Q.931, le même que dans le RNIS. Le protocole RAS (Registration, Admission and Status) sert à l enregistrement des équipements terminaux et au contrôle d admission à la communication. H.245 permet de commander les applications de bout en bout. Les applications de données se servent de T.120, alors que l audio et la vidéo disposent de plusieurs types de codecs. La figure 5 illustre la procédure d établissement d une communication multimédia point à point dans un environnement IP. La première phase se sert du protocole H.225/RAS. Le terminal qui lance l établissement requiert, au préalable, l autorisation de la part du portier. Ensuite, par l intermédiaire du protocole Q.931, il ouvre la connexion vers le partenaire. Le partenaire doit également demander son admission au portier, avant de confirmer l établissement de connexion. Lorsque les deux terminaux ont achevé la phase de connexion, une phase d échange de paramètres, basée sur H.245, se déroule. Aussitôt que le canal logique est disponible, la communication audio et vidéo peut débuter. Elle utilise les protocoles RTP (Real Time Protocol) et RTCP (Real Time Control Protocol). La libération de connexion H.323 débute par une phase de déconnexion entre points d extrémités. Ensuite, chaque terminal informe le portier de la fin de la communication. Les ressources du réseau sont, dès lors, à nouveau disponibles pour l ensemble des usagers. FI 1-21 janvier 2003 page 4

5 Réseaux IP voix et multimédia sur IP Concept VoIP basé sur SIP (Session Initiation Protocol) L échange des messages de signalisation et de contrôle du protocole SIP est effectué sous la forme de transactions. Il est apparenté au protocole HTTP. Une transaction est composée d une requête et d une réponse. Les requêtes sont toujours émises par un client et les réponses par un serveur. Cette même structure client-serveur va se retrouver dans les terminaux, le serveur d enregistrement, le proxy et le serveur de re-direction. fiig. 7 architecture des protocoles selon SIP fig. 5:établissement de connexion au moyen du protocole H.323 fig. 6 libération de connexion dans H.323 fig. 8 établissement et libération d une connexion au moyen du protocole SIP FI 1-21 janvier 2003 page 5

6 Réseaux IP voix et multimédia sur IP Dans la figure 8, la demande d établissement contient les adresses de destination et de source en format SIP, de même que les paramètres c et m. Le paramètre c définit les coordonnées pour le flux audio qui sera émis vers l usager Frey. Ce flux sera transmis au moyen du protocole IP version 4, vers l adresse IP Le paramètre m indique qu il s agit d un flux audio qui utilisera le port UDP et le protocole RTP. Il requiert l algorithme de codage audio G (valeur 4). Dans le sens opposé, le codage audio est de type GSM (valeur 0). Dans l exemple de la figure 10, une connexion entre deux réseaux RNIS transite par un réseau IP. Le contrôleur de passerelles contient également la fonctionnalité de passerelle de signalisation. Les passerelles de médias convertissent les flux de paquets IP contenant le signal audio en des flux synchrones à 64 kbit/s, et inversement. La signalisation mise en œuvre entre le RNIS et la passerelle de signalisation est basée sur le système de signalisation no 7 (SS7). La commande des passerelles de médias est faite au moyen du protocole MGCP. Suite au message d établissement IAM (Initial Address Message) du protocole SS7, le contrôleur de passerelles ordonne l ouverture d une connexion avec les messages CRCX (Create Connection) et transmet le message IAM vers sa destination. L ouverture de connexion est confirmée avec les messages ACK (Acknowledge). Le message MDCX (Modify Connection) permet de transmettre à la passerelle de gauche le numéro de port UDP choisi par la passerelle de droite. Les messages ACM (Address Complete) et ANM (Answer Message) du SS7 permettent d indiquer de bout en bout que la sonnerie retentit, respectivement, que l usager appelé a répondu. La libération de la connexion est effectuée au moyen des messages DLCX (Delete Connection) et ACK, pour le protocole MGCP, et de REL (Release) et RLC (Release Complete), pour le SS7. Concept VoIP basé sur MGCP (Media Gateway Control Protocol) Le protocole MGCP sert à l échange de message de signalisation entre un contrôleur de passerelles de médias et des passerelles réparties dans un réseau IP. Pour l établissement et la libération des connexions, MGCP se sert de signaux et d événements. La standardisation de MGCP a été stoppée pour faire place à MEGACO/H.248 (MEdia GAteway COntrol protocol), protocole élaboré en collaboration entre l IETF et l UIT. Ce nouveau standard n étant pas dérivé de MGCP, la migration vers MEGACO/H.248 semble très difficile. fig.10 établissement et libération de connexion au moyen du protocole MGCP fig 9 architecture des protocoles selon MGCP Dans un prochain article, nous décrirons et comparerons les différentes technologies d'accès aux réseaux (RNIS, xdsl, câble TV, câbles d'énergie, UMTS, boucle locale radio, LAN sans fil public, satellite, ). Erratum L article Déploiement d une grille de calcul à l EPFL: vers un plan d urbanisme du 17 décembre 2002 donnait l adresse du site e-scale pour l échange d informations destiné aux personnes qui s intéressent à ce type de développement. Une faute de frappe s est malencontreusement glissée dans le texte, nous vous redonnons ici l adresse exacte : Avec nos excuses. Marie-christine.Sawley@epfl.ch FI 1-21 janvier 2003 page 6

7 La génération de documents PDF depuis un serveur applicatif Suite de la première page bien que simple à mettre en œuvre pose deux problèmes: tout d abord le format HTML étant moins riche que le format PDF, la conversion ne présente souvent pas beaucoup d intérêt, hormis peut-être la génération automatique d en-têtes et pieds de page. Ensuite, pour que ces logiciels fonctionnent, il s agit en général de créer un fichier (au format HTML) qui sera ensuite converti dans un autre fichier (au format PDF). Le serveur applicatif devant donc générer des fichiers avec des noms uniques là où a priori un travail en mémoire aurait suffi, doit relire ceux-ci pour les envoyer au poste client, et finalement doit gérer l effacement de ces fichiers temporaires. Il existe une troisième solution qui consiste à créer un fichier chablon dans un méta langage qui permettra à une librairie de génération PDF de haut niveau de prendre celui-ci en entrée, le fusionner avec les données et produire le résultat en PDF, souvent directement en mémoire prêt à être renvoyé sur le poste client. Nous n abordons pas ici les solutions d édition à partir de bases de données. En effet, il existe des outils permettant de lancer des requêtes complexes en SQL et générer le résultat, souvent en PDF. Utiliser ce genre d outil suppose tout d abord que toutes les informations nécessaires à générer les documents sont contenues dans une base de données mais surtout nécessite une réécriture d une partie de la logique métier nécessaire en SQL (ou dérivé) alors que celle-ci était déjà présente dans l application. Ceci avec la conséquence évidente d augmenter la quantité de travail, le risque d erreurs ou d incohérences et l effort de maintenance. Solutions Nous allons aborder ici les solutions qui tombent dans la catégorie permettant la création de fichiers chablons et la génération en mémoire des documents. Sachant que nous utilisons le serveur applicatif WebObjects(tm) ( et par conséquent le language Java (jdk ou plus récent), un rapide tour non exhaustif du marché (libre ou non) nous a permis de référencer les solutions suivantes: ReportMill ( PDFGenerator ( itext: (sourceforge.net/projects/itext/) RReport: ( FOP: (xml.apache.org/fop/) SVGObjects: ( ReportMill est une solution commerciale de très bonne qualité. Le produit vient avec un éditeur graphique qui permet de construire les chablons des pages et d y connecter les sources de données (directement depuis le EOModel dans le cas d un usage avec WebObjects(tm)). Ils appellent cela du object reporting. Cela signifie qu une zone du document n est pas forcément simplement une colonne d une table ou un attribut d un objet mais peut être également le résultat d une fonction. Ainsi, la réutilisation du code de la logique métier est maximale. Récemment la société a ajouté le support pour d autres serveurs applicatifs ainsi que la génération du format Flash ( software/flash/) pour les applications interactives. L utilisation du logiciel depuis WebObjects(tm) est extrêmement simple et ne requiert qu environ 3 lignes de codes pour initialiser le document avec la source de données, déclancher la génération et retourner le résultat avec le retour de la requête utilisateur. Ce produit a toutefois un coût et ne concernera donc que les entreprises qui le récupéreront largement dans le gain en productivité. PDFGenerator est une solution similaire que nous n avons pas eu l occasion de tester. C est également une solution commerciale. itext est une solution OpenSource. En soit il ne représente pas vraiment ce que nous recherchons puisqu il s agit d une librairie d assez bas niveau de génération de code PDF. Toutefois, le site fait mention d Intermezzo qui permet la génération d un document PDF à partir d une source XML (utilisant itext), ou même de fusionner un document chablon XML avec des données d un autre fichier pour en faire un document PDF. RReport semble aller dans la direction voulue en offrant une encapsulation de itext. L intérêt principal étant de cacher au développeur les finesses de calculs du positionnement. Ils ont un outil permettant de construire visuellement les chablons de documents. Financièrement, cela fonctionne sur le mode du shareware: très bon marché! Nous n avons pas non plus testé cette solution (à tort probablement) car nous étions déjà trop avancé dans l utilisation d une autre technologie. FOP (Formatting Objects Processor) est un projet OpenSource du groupe Apache. Il s agit d une solution de génération de documents (PDF ou autres) à partir d un modèle en XSL. SVGObjects est une librairie OpenSource utilisant FOP et le format SVG, ( spécialement destinée à l usage avec WebObjects(tm). Ces deux dernières solutions étant celles retenues dans notre groupe, nous allons y consacrer le reste de l article. Générer des documents PDF à l aide de FOP Il existe 3 manières d intégrer FOP à un serveur applicatif. 1. On peut générer un document XML contenant des données et envoyer celui-ci avec un chablon XSL vers un serveur Cocoon. Ce dernier effectue la fusion des deux document en entrée et génère un document PDF en sortie. 2. On peut générer un document XSL au format FO contenant déjà les données et envoyer celui-ci vers un serveur Cocoon qui effectuera la génération PDF. 3. On peut utiliser une librairie locale à son application qui effectuera la conversion d un document XSL en document PDF. Un serveur Cocoon (xml.apache.org/cocoon/) est un logiciel s installant avec un serveur Apache permettant de gérer la fusion (utilisant XSLT) de données XML avec un chablon XSL pour créer un document XSL au format FO. Ce dernier sera ensuite converti en PDF. FI 1-21 janvier 2003 page 7

8 La génération de documents PDF depuis un serveur applicatif La première et la seconde solution utilisent un serveur Cocoon. La différence entre les deux est que dans la seconde, la fusion est déjà effectuée et le serveur ne s occupe que de la génération PDF. La troisième solution est techniquement la même que la seconde, sauf que la génération du PDF se fait directement dans le serveur applicatif à l aide des classes FOP sans nécessiter d aller-retour avec un serveur Cocoon, Cocoon utilisant ces mêmes classes. Ici, nous avons successivement utilisé les 3 méthodes. La première générait des problèmes de stabilité et de temps de réponse (temps de fusion, volume du trafic). La seconde solution a été utilisée de façon transitoire en attendant de pouvoir migrer notre serveur applicatif sur une jdk récente supportant FOP. La troisième est celle que nous utilisons actuellement en production et pour laquelle nous allons détailler le fonctionnement. Nous allons également décrire les librairies réutilisables que nous avons développées pour une intégration simplifiée dans nos applications WebObjects(tm). Et SVG alors? SVG est un format défini par Adobe permettant de dessiner ou d inclure des images dans un document. Il est probable que c est la réponse d Adobe au format Flash de Macromédia. Dans le format XSL/FO, certaines instructions sont en fait du SVG. En particulier, l inclusion d une image dans un document se fait grâce à des balises SVG qui seront ensuite interprétées par les classes SVG correspondantes. Finalement, pour l intégration de cette technologie dans WebObjects(tm), nous avons utilisé le projet SVGObjects qui consiste en du code assez simple et élégant pour automatiser la génération du PDF partant du format XSL/FO. SVGObjects a été écrit par Ravi Mendis, un ancien employé d Apple, consultant WebObjects(tm) et collègue de l un des auteurs de ce document à l époque où il était lui-même chez Apple. Pour plus d informations, il est recommandé de lire WebObjects developer s Guide chez SAMS (Ravi Mendis). Les librairies nécessaires Pour compiler une application utilisant XSL/FO et exécuter la génération PDF, il faut intégrer les librairies java suivantes (toutes se trouvent sur le site Apache): Batik: interprétation du SVG Fop: interprétation du XSL/FO Logkit-1.0: nécessaire à batik et fop Avalon-framework: nécessaire à batik et fop A la date de ce document, la version de FOP était Il peut sembler à la lecture de ce nombre que nous sommes face à une librairie tout juste en qualité bêta, mais pour nos besoins, aucun problème sérieux n est venu perturber le développement. FOP étant activement développé dans le groupe Apache, on peut espérer de nouvelles versions rapidement. Exemples et intégration avec WebObjects(tm) WebObjects(tm) ( WebObjects(tm) est un environnement de développement et de déploiement d applications Web dont l origine remonte à février 1996, date à laquelle la société NeXT(tm) Software a présenté ce qui était probablement le premier serveur applicatif sur le marché. A l époque, l environnement fonctionnait avec le language Objective-C et bénéficiait des librairies et de l expérience OpenStep(tm). Depuis, la société NeXT a été rachetée par Apple et, le marché dictant ses préférences, WebObjects(tm) (aujourd hui en version 5.2) a été réécrit en pur Java, mais tout en gardant bien des concepts et patterns OpenStep(tm) qui font aujourd hui encore l originalité et la qualité du produit. WebObjects(tm) permet le développement sur Windows(tm) ou MacOSX(tm). Le produit contient un environnement complet de développement et de déploiement. Etant maintenant en pur Java, il est possible de déployer les applications sur tout système supportant une jdk ou mieux. Toutefois, ce sont les plates-formes MacOSX, Windows2000 et Solaris qui sont supportées d office par le produit. Parmi les forces du produit on peut noter EOF (Enterprise Objects Framework) une couche de persistance d objets dans les bases relationnelles particulièrement efficace, la possibilité de définir des composantes HTML ou autres réutilisables sous formes d objets, une excellente séparation de la couche métier de la couche présentation, la génération automatique de WebServices, et finalement, la possibilité de déployer des applications avec des postes client en Swing plutôt que HTML. Même si d un point de vue marketing, Apple n est pas aussi présent que les autres grands noms dans le monde J2EE (WebObjects n est pas à proprement parler un serveur J2EE, mais peut s y intégrer), il est intéressant de noter que beaucoup d'entreprises utilisent WebObjects pour des applications Internet ou Intranet de haute disponibilité. Exemples documents XSL/FO Voici quelques exemples de documents tels qu ils doivent être générés avant leur transformation par les classes FOP en PDF. Ces exemples sont partiels et devront être adaptés avant de les essayer! Tout d abord la définition d une page: <?xml version="1.0" encoding="iso "?> <fo:root xmlns:fo=" Format"> <fo:layout-master-set> <fo:simple-page-master master-name="first" margin-top="0.5cm" margin-bottom="0.0cm" margin-left="1.5cm" margin-right="0.5cm" page-width="21cm" page-height="29.7cm"> <fo:region-body region-name="xsl-region-body" margin-bottom="1.7cm" margin-top="1cm" margin-right="1cm"/> <fo:region-before region-name="xsl-regionbefore" extent="1cm" /> <fo:region-after region-name="xsl-regionafter" extent="1.7cm" /> </fo:simple-page-master> </fo:layout-master-set> </fo:root> FI 1-21 janvier 2003 page 8

9 La génération de documents PDF depuis un serveur applicatif Ensuite la définition d en-têtes et de pieds de page. Commençons pas une en-tête simple: <fo:static-content flow-name="xsl-region-before"> contenu du header... </fo:static-content> Maintenant un pied de page avec calcul du numéro de la page: <fo:static-content flow-name="xsl-region-after"> <fo:table> <fo:table-column column-width="9cm" /> <fo:table-column column-width="9cm" /> <fo:table-body> <fo:table-row space-before.optimum="0.1cm"> <fo:table-cell> <fo:block text-align="start" font-size="8pt"> Imprimé par Urlu Berlu </fo:block> </fo:table-cell> <fo:table-cell> <fo:block text-align="end" font-size="8pt"> Page <fo:page-number/>/<fo:page-numbercitation ref-id="lastblock" /> </fo:block> </fo:table-cell> </fo:table-row> </fo:table-body> </fo:table> <fo:block> <fo:leader leader-length="18cm" rule-thickness="0.1mm" color="#000000"/> </fo:block> </fo:static-content> Et finalement, le contenu de la page: <fo:flow flow-name="xsl-region-body"> Le contenu de la page... <!-- block vide avec id pour connaitre nombre total de page --> <fo:block id="lastblock"/> </fo:flow> Intégration avec WebObjects(tm) WebObjects(tm) permet la création de composantes. Ces composantes sont formées d éléments fixes et d éléments qui seront dynamiques, c est à dire remplacés lors de la génération par des valeurs provenant du code Java. Ainsi, une composante est en fait un chablon, un contrôleur écrit en Java (sous classe WOComponent de la librairie WebObjects(tm)) et un fichier définissant les liens entre les deux (tel bouton devra appeler telle fonction, telle zone devra être remplie par telle variable, etc.). En général, dans une application WebObjects(tm) classique, les composantes sont des pages HTML ou des sous-ensemble de pages HTML (il est possible également de définir des morceaux de pages qui seront réutilisés). Toutefois, le principe du chablon et de la génération dynamique est également applicable à d autres formats. Par exemple, nous faisons un usage important du XML et utilisons parfois ce principe pour générer des réponses comme WebServices. Ici, c est la génération de XSL/FO qui nous intéresse! Ainsi, notre exemple devient: <WEBOBJECT NAME=hug.pdfcomponent.foundation.Layout1> <WEBOBJECT NAME=hug.pdfcomponent.foundation.Header1></WEBOBJECT> <WEBOBJECT NAME=hug.pdfcomponent.foundation.Footer1> <fo:block text-align="center" font-size="9pt"> Hôpitaux Universitaires de Genève, Rue Micheli-du-Crest 24 </fo:block> <fo:block text-align="center" font-size="9pt">tel 022/ </fo:block> </WEBOBJECT> <WEBOBJECT NAME=hug.pdfcomponent.foundation.Body1> <!-- motif de consultation --> <fo:block space-before.optimum="1cm" font-size="10pt"> <fo:block font-weight="bold">motif de consultation:</fo:block> <fo:block start-indent="1cm" space-before.optimum="0.2cm"> <WEBOBJECT NAME=PFDataDisplayComponent10></WEBOBJECT> </fo:block> <fo:block start-indent="1cm" space-before.optimum="0.2cm"> <WEBOBJECT NAME=PFDataDisplayComponent2></WEBOBJECT> </fo:block> </fo:block> <!-- diagnostic retenu --> <fo:block space-before.optimum="0.5cm" font-size="10pt"> <fo:block font-weight="bold">diagnostics retenus:</fo:block> <fo:block start-indent="1cm" space-before.optimum="0.2cm"> <WEBOBJECT NAME=PFDataDisplayComponent3></WEBOBJECT> </fo:block> </fo:block> <!-- traitements --> <fo:block space-before.optimum="0.5cm" font-size="10pt"> <fo:block font-weight="bold">traitements:</fo:block> <fo:block start-indent="1cm" space-before.optimum="0.2cm"> </fo:block> </fo:block> <!-- salutations --> <fo:block space-before.optimum="1cm" font-size="10pt"> Veuillez agréer, cher (chère) Collègue, nos sincères salutations.</fo:block> <!-- signature --> <fo:block space-before.optimum="2cm" font-size="10pt"> Dr <WEBOBJECT NAME=WOString3></WEBOBJECT> </fo:block> </WEBOBJECT> </WEBOBJECT> FI 1-21 janvier 2003 page 9

10 La génération de documents PDF depuis un serveur applicatif On voit ici un certain nombre de balises <WEBOB- JECT>. Ces balises seront interprétées en temps réel et remplacées par une nouvelle chaîne de caractères. Cette dernière peut être à son tour une composante XSL/FO avec des balises WebObjects(tm). En effet, la génération est récursive. En particulier, la balise Layout1 contient la structure de la page. Cette composante aura le même aspect que le XSL présenté plus haut pour la définition d une page avec une balise indiquant où placer le contenu: <?xml version="1.0" encoding="iso "?> <fo:root xmlns:fo=" Format">... idem que plus haut... <WEBOBJECT NAME=ComponentContent1></ WEBOBJECT> </fo:root> Chaque balise WebObjects(tm) représente donc une souscomposante qui sera incluse à la génération. Les noms des balises correspondent aux noms des liens que l on retrouve dans le fichier de connexions. Ce fichier à l aspect suivant: hug.pdfcomponent.foundation.footer1: hug. pdfcomponent.foundation.footer { user = session.user; } hug.pdfcomponent.foundation.layout1: hug.pdfcomponent.foundation.layout { } WOString3: WOString { value = session.dataset.lastupdateuserinfo. fullname; } On remarque que ces connexions peuvent posséder des attributs qui seront évalués à la génération. Ces attributs sont spécifiques à chaque classe de composantes. Des composantes plus complexes peuvent être utilisées comme par exemple des répétitions de zones (pour des listes) ou des conditionnelles (pour afficher un contenu sous certaines conditions seulement). Dans ce cas, pour une conditionnelle, le chablon comporterait du code de la forme: <WEBOBJECT NAME=Conditional1>le détail de l arrêt de travail</webobject> et le fichier de connexion: Conditional1:WOConditional { condition = composante.questionnaire.arrettra vail ; } Pour une répétition d une liste: <WEBOBJECT NAME =Repetition1>le bloc à répéter</webobject> et le fichier de connexion: Repetition1:WORepetition { list = composante.listetraitements ; item = composante.traitement ; } La generation du PDF Maintenant que nous avons les chablons, comment allons-nous générer le PDF? C est là qu intervient le code faisant partie du projet SVGObjects. En effet, de même que dans WebObjects(tm), chaque composante hérite naturellement de la classe WOComponent, nous allons faire hériter chaque composante PDF de notre application de la classe FOComponent, elle-même héritant de la classe WOComponent. Les composantes WebObjects(tm) ont ceci d intéressant que lors de la génération récursive, chaque composante (page ou élément de page donc) est appelée. La fonction appelée est: public void appendtoresponse(woresponse response, WOContext context) La plupart du temps cette fonction n a pas besoins d être ré-implémentée. Cette fois pourtant, nous allons intervenir au niveau le plus haut dans la génération et juste avant de retourner la page générée (qui à ce moment n est en fait encore que du XSL/FO) faire passer celle-ci par la génération PDF. Le code de la fonction appendtoresponse ressemble donc à ceci: super.appendtoresponse(response, context); Document document = response.contentasdomdocu ment(); ByteArrayOutputStream out = new ByteArrayOutputStream(); Logger logger = Hierarchy.getDefaultHierarchy ().getloggerfor("fop"); Driver driver = new Driver(); driver.setlogger(logger); driver.setrenderer(driver.render_pdf); driver.setoutputstream(out); try { driver.render(document); } catch (Exception e) { e.printstacktrace(); } // set the PDF data NSData datafile = new NSData(out.toByteArray( )); response.setcontent(datafile); // set the header response.setheader("application/pdf", "Content-Type"); response.setheader(string.valueof(datafile.le ngth()), "Content-Length"); response.removeheadersforkey("cache-control"); Il n y aura que la composante principale (celle qui représente la page complète en PDF) qui sera une sous-classe de FOComponent. En effet, les composantes telles que Layout, Header, Footer, etc. sont directement des sous-classes de WOComponent car ce n est pas à leur niveau que l on désire générer le PDF. FI 1-21 janvier 2003 page 10

11 La génération de documents PDF depuis un serveur applicatif Conclusion Après une première période d expérimentation, nous avons graduellement créé une librairie de composantes WebObjects(tm) XSL/FO réutilisables. En effet, devant générer beaucoup de documents qui possèdent souvent des caractéristiques très proches, il était tentant de fournir aux développeurs le moyen de rapidement les créer. Aujourd hui, la librairie comprend une quinzaine de composantes XSL qui, rajoutées aux composantes standards WebObjects(tm) ainsi qu aux composantes orientées données des applications cliniques, nous accélèrent le développement, tout en permettant à des programmeurs n ayant pas de connaissance XSL/FO de travailler efficacement. Alexander Lamb est responsable du groupe Serveurs Applicatifs à la Division d Informatique médicale des Hôpitaux Universitaires de Genève. Il était anciennement chez NeXT puis Apple dans la division services de ces sociétés respectives, intervenant sur des sites utilisant les technologies WebObjects(tm) et OpenStep. Nicolas Cassoni est développeur dans ce même groupe, auteur d une partie du code permettant la génération PDF ainsi que d autres applications WebObjects(tm) comme la saisie de données structurée ou la gestion des droits pour les utilisateurs des applications cliniques. Un projet pionnier de Voice over IP (VoIP) au Centre Cantonal des Télécommunications (CCT) Jacqueline.Dousson@epfl.ch, SIC Avec des collègues de la section Téléinformatique du SIC, j'ai rencontré Monsieur André Bourget qui dirige le Centre Cantonal des Télécommunications (CCT) de l'etat de Vaud (Andre.Bourget@dpsi.vd.ch). Il nous a présenté ce projet qui est maintenant dans sa phase d exploitation. Pour une description technique de la transmission de la voix sur les réseaux IP, se référer à l article de ce numéro: Réseaux IP - Voix et multimédia sur IP. Les éléments qui ont poussé à s engager dans un tel projet sont de plusieurs ordres: Une des caractéristiques de l administration cantonale vaudoise, qui avec 30'000 collaborateurs est le premier employeur de la région lémanique, est son extrême décentralisation. Les collaborateurs sont répartis sur plus de 450 sites avec parfois seulement 4 personnes sur un site. Difficile dans ces conditions d offrir à des coûts raisonnables les prestations offertes par les centraux téléphoniques modernes (renvoi d appels, utilisation d annuaires en ligne, gestion de carnets d adresses personnels,...) qui sont limités à un rayon d action d environ 1 km. Le choix de VoIP permettrait de développer la notion de central téléphonique virtuel, concept où la distance n intervient plus et où les coûts sur le long terme sont mieux contrôlés. La mobilité non négligeable de ce personnel réclamait pour tout changement de bureau d une personne l intervention d un agent pour s occuper du déplacement de son raccordement téléphonique. Là encore la solution VoIP permettait de diminuer coût et perte de temps. Enfin devoir gérer deux réseaux - données et voix - ayant une grande similitude mais réclamant des compétences différentes induisait un gaspillage inutile. La perception claire des enjeux de VoIP a conduit à s engager bien tôt dans cette voie quitte à s impliquer avec les constructeurs pour faire avancer la technologie. Calendrier Le projet a démarré en 2000 où les 232 centraux téléphoniques classiques ont progressivement été remplacés par six Call Managers Cisco. Aujourd hui plus de 1000 appareils téléphoniques CISCO ont été mis en service, ils seront 3000 l été prochain. FI 1-21 janvier 2003 page 11

12 Du point de vue de l utilisateur Avec cette virtualisation du central téléphonique apportée par VoIP, tous les collaborateurs travaillent comme s ils étaient sur le même site. En déplacement sur un autre site, le collaborateur peut récupérer sa configuration personnelle (carnet d adresses, filtrage d appels, boîte vocale,...) sur un autre poste téléphonique. Certaines nouvelles fonctionnalités sont intéressantes: ainsi, l employé du service des impôts peut accéder automatiquement depuis son poste de travail informatique au dossier du contribuable qui l appelle. A terme, ce type de fonctionnalités devrait être augmenté afin de rationaliser les activités administratives de plus en plus orientées vers le service aux usagers. Sous-estimé au départ du projet, le changement d outil n a pas été ressenti comme mineur par l usager. Pour mieux l intégrer, des formations courtes ont été progressivement mises en place afin que toutes les nouvelles fonctionnalités soient connues et bien utilisées. Les défauts de jeunesse (menus en anglais, qualité moyenne des transmissions) sont à présent résolus. Technologies L infrastructure réseau a dû être mise à niveau, la qualité de service requise pour le traitement de la voix étant supérieure à celle demandée par le traitement de données informatiques. Le choix du matériel s est porté sur CISCO, seul constructeur à répondre de façon satisfaisante aux tests, mais le CCT maintient une veille technologique dans le domaine afin de basculer vers une infrastructure moins propriétaire dès qu une solution alternative fiable se présente. En effet, le monopole Cisco en matière de télécommunications ressemble à beaucoup de points de vue à celui exercé par Microsoft dans le domaine des O.S., et est porteur des mêmes dangers pour l entreprise et donc l utilisateur final. Les compétences et la maîtrise du projet restent en interne mais la mise en œuvre et la gestion sont externalisées. Un avenir plus nomade Le problème du téléphone cellulaire a été abordé par le CCT. L utilisation du poste fixe reste encore plus confortable (taille de l écran, possibilité de travailler en mains libres) mais, aujourd hui le téléphone cellulaire est tellement répandu dans la population, que l étude de son utilisation privée sur un site ou pour toute une institution est incontournable. Non seulement pour communiquer mais aussi pour localiser, authentifier ou donner accès avec le meilleur confort pour le personnel. Le choix VoIP place le CCT dans une position toute privilégiée pour déployer ces solutions car toute solution d avenir dans ce domaine part d IP! L avenir appartient donc à ceux qui prévoient et qui commencent tôt! L audace et le courage du CCT engagé dans cette voie depuis quelques années les met dans une situation bien enviable. FI 1-21 janvier 2003 page 12

13 igames Implémentation d un service de jeu en réseau employant les agents mobiles Fiorenzo Gamba, gamba@eif.ch & Jean-Frédéric Wagen, wagen@eif.ch, EIA-FR, Ecole d ingénieurs et d architectes de Fribourg - La technologie d Agent Mobile est de plus en plus considérée par la communauté scientifique ainsi que par certains opérateurs pour améliorer les services mobiles. Cependant l efficacité de cette technologie n est pas prouvée. Nos investigations ont visé à qualifier et mesurer l utilité des agents mobiles basés sur une exécution particulière d un service de jeu: igames. Premièrement, nous espérons clarifier quelques avantages et limitations des services génériques habituellement offerts par les plates-formes mobiles d agent. En second lieu, notre implémentation peut servir comme base pour des procédures de benchmarking. Des fonctionnalités de base peuvent alors être examinées et plusieurs indicateurs d exécution peuvent être mesurés. Les essais ont été réalisés dans différentes situations tout en essayant de garder un équilibre entre les environnements réalistes et usités. Les tests ont été réalisés en utilisant la plate-forme mobile d agents Grasshopper d IKV, pour fournir un service de jeu conçu, fonctionnant sur les terminaux fixes (PC) et mobiles (PDA). Divers accès: LAN, modem, WLAN, GPRS ont été examinés. Les mesures entreprises pour cette recherche mettent en évidence les limitations des technologies d agent mobile actuelles, compte tenu de l état de l art du matériel et du logiciel, bien que disponible dans le commerce. Des technologies d accès avec un débit au-dessus de 1 Mbps sont actuellement exigées. On espère que les futures réalisations et conceptions des plates-formes d agent mobile ainsi que les architectures des services mobiles soient optimisées pour ce type d approche. Ainsi les opérateurs pourront utiliser plus efficacement la technologie d agent mobile. Dans ce dernier cas, l énorme potentiel des agents mobiles pour des terminaux fixes et mobiles peut être exploité. Introduction L évolution des télécommunications est caractérisée par une augmentation de disponibilité de largeur de bande et par une augmentation de la mobilité des utilisateurs. Ceci mène à une révolution dans les offres de services. De nombreux services sont offerts, et avec un nombre croissant de technologies d accès fixes et mobiles. En même temps, les modèles de services migrent vers des solutions Web-services, où des applications peuvent être offertes de manière flexibles selon le terminal et la connectivité d utilisateur. En outre, la facilité d utilisation et le besoin d être rapidement sur le marché [2] sont des facteurs de plus en plus dominants. Ceci exige du développement de services d être idéalement indépendant de la plate-forme et d avoir un comportement dynamique, s adaptant aux différents contextes. On a proposé des technologies d agent mobile en tant qu élément de la solution pour offrir cette flexibilité et cette adaptabilité. Plusieurs opérateurs mobiles offre déjà de nouveaux services complémentaires d accès, nommés «Hot-Spot». Les Hot-Spots fournissent l accès mobile public à bande large à l Internet et aux Intranets par l intermédiaire du WLAN (wireless LAN). La couverture d un accès de Hot-Spot est en général plus faible comparée à la solution classique de réseau mobile, type 2/3G. Cependant, cette limitation peut être vue comme un avantage pour offrir une capacité de largeur de bande élevée aux utilisateurs dans un secteur donné. Tous les services mobiles n exigent pas des possibilités de Roaming, qui sont complexe à mettre en œuvre, c est pourquoi nous définissons un mode d accès limité, le Micro-Spot. L accès Micro-Spot est limité à un petit espace dans un environnement privé, tel que l entrée d un théâtre ou d un hôtel, etc. Les services associés au Micro-Spot sont limités aux utilisateurs localisés dans ce secteur. Comparés aux Hot- Spots, les services offerts par le Micro-Spot ne sont pas redistribués dans d autres Micro-Spots. Ils peuvent être fournis par de petites entités privées, par exemple: bande d annonce vidéo pour un cinéma, services de jeu dans un club, etc. Le scénario Le contexte de notre scénario est celui d une file d attente dans un cinéma ou ailleurs. Le but est d offrir un service de jeu réseau multi-joueurs aux personnes attendant un événement. Une personne arrivant dans un secteur couvert par un Micro-Spot reçoit l information spontanée lui indiquant la disponibilité du service igames de la part du fournisseur de service local. La personne accède au service igames par l intermédiaire d un terminal mobile avec une interface sans fil, par exemple, à l aide d un PDA de type ipaq avec une interface réseau WLAN. Après identification par l intermédiaire d une page Web, l utilisateur accède à une liste de jeu et peut ainsi s inscrire et jouer avec d autres utilisateurs. Les agents mobiles simplifient la manipulation des utilisateurs et de leur équipement terminal. Le jeu est envoyé directement au terminal mobile sous la forme d un agent mobile. Déployer un service sous forme de petites entités réduit la puissance et la largeur de bande du système d igames par rapport à une solution de traitement centralisé. L interface utilisateur est automatiquement adapté par l agent mobile selon le profil de l utilisateur et de l équipement associé [5]. FI 1-21 janvier 2003 page 13

14 igames Implémentation d un service de jeu en réseau employant les agents mobiles Le jeu MinesSweeper [8] met en évidence les propriétés des agents mobiles suivants: mobilité, communication, et coopération. On peut imaginer d autres jeux ou services basés sur la plate-forme ainsi développée. Plate-forme et architecture La plate-forme igames est le noyau de notre développement, voir fig.1. Elle est basée sur la plate-forme d agent mobile, Grasshopper de la société IKV++ [4]. Grasshopper offre une solution conforme au standard MASIF et est portable sur Windows CE, GNU/Linux, Unix, ou encore Windows suite. La plate-forme igames offre les fonctionnalités suivantes: enregistrement, accès, authentification, livraison de code de logiciel, gestion de joueur et administration de système. trois combinaisons appelées full UE, medium UE et light UE [3]: Full UE: est assez puissant pour faire fonctionner un certain nombre d agents. Les agents communiquent par le biais du réseau sans fil avec d autres agents situés sur le réseau fixe, et peuvent se déplacer probablement entre les terminaux sur les réseaux mobile et/ou fixe. Medium UE: ne peut pas exploiter la plate-forme d agent mobile (dû à la limitation du CPU, temps de traitement et/ou à la mémoire). Cependant, il peut commander et communiquer avec l agent par l intermédiaire d un proxy situé sur la plate-forme igames. Il peut avoir une interface utilisateur graphique faite sur mesure (employant J2ME par exemple). Light UE: n a pas la capacité de faire fonctionner les applications adaptées aux besoins du client. Elle peut seulement communiquer avec le système d igames par SMS, ou par un protocole léger comme WAP et communique avec un proxy situé dans le réseau fixe. Ce proxy peut être déployé sur la passerelle WAP ou être situé sur le BSC [1]. La conception et les détails de l implémentions sont expliqués dans [6]. La figure 2 représente une vue globale du fonctionnement. fig. 1 igames: architecture globale. Trois parties sont identifiées: plate-forme igames, accès réseau et équipement d utilisateur La figure 1 fournit une vue d ensemble et globale de notre architecture du service igames. Trois différentes sections sont identifiées. La première partie de la plate-forme igames est composée d une base de données gérant les profils d utilisateur et où sont stockées toutes les informations appropriées concernant les utilisateurs et leurs terminaux. Une base de données de jeux est responsable du dépôt des classes et autres agents jeu. Le dernier élément est le point d accès, c est-à-dire, un serveur de Web/Wap qui est l unique interface commune pour tous les joueurs. Le serveur de Web/Wap sert également de plate-forme d administration. La deuxième partie de notre architecture d igames représente les différents accès réseau. Actuellement nous nous sommes adaptés aux accès suivants: WLAN, GSM/GPRS, et modem analogue. Les accès WLAN ou Bluetooth sont typiquement des solutions adaptées aux entreprises et pourraient être déployés pour l accès de type Micro-Spot. Les accès GSM/GPRS sont des solutions d accès mobiles 2/2.5G. La dernière partie d igames est consacrée aux terminaux mobiles. Trois types de dispositif mobile sont définis. Leurs sous-divisions sont basées sur les capacités CPU, mémoire, écran, possibilités d accès et autres mesures d exécution. Le terme équipement d utilisateur (user equipment, UE) a été choisi pour caractériser la combinaison du type de terminal mobile et de son type d accès au réseau. Nous avons identifié fig.2 igames: fonctionnement global, différentes phases depuis l authentification jusqu au déplacement du jeu Résultats Environnement L installation suivante a été utilisée pour nos mesures: la plate-forme d igames est déployée sur un Pentium III 800Mhz avec 256MB de RAM fonctionnant sous GNU/ Linux kernel connecté à un réseau Ethernet commuté à 100Mb/s. Les terminaux clients sont un ordinateur portable Pentium III à 600Mhz avec 128MB de RAM sous Windows XP Professionnel et un ipaq 3870 PDA sous Windows Pocket PC La plate-forme Grasshopper a besoin d un environnement d exécution Java (JRE). Sun Microsystems JRE a été choisi pour le système de PC. Pour l ipaq PDA, on a constaté que la recommandation d IKV pour la solution Java personnal posait problème. Notre choix s est porté sur la solution suivante: Jeode TM PDA Edition [7]. Jeode est une solution d Insignia Inc. FI 1-21 janvier 2003 page 14

15 igames Implémentation d un service de jeu en réseau employant les agents mobiles Accès réseau De nombreux accès réseau peuvent caractériser le mode de connexion au Micro-Spot. Le tableau 1 montre un sommaire de 7 accès réseau différents que nous avons choisis pour tester notre service. À l heure de nos mesures l accès UMTS n était pas encore offert par les opérateurs et les terminaux pas encore disponibles. Le terme de pseudo UMTS a alors été défini comme un accès utilisant le WLAN à 1Mbits/s. Il y a quelques différences entre l UMTS et le WLAN, cependant les deux technologies utilisent le même mécanisme de direct sequence spread spectrum et ont approximativement le même débit de 1Mbits/s. accès d ISP avec le modem 56K; accès à distance par GSM (entrepris seulement avec le PDA); Pseudo UMTS (= WLAN à 1 Mbits/s); WLAN à 11Mbits/s. Méthodologie Tous les systèmes ont été testés dans les mêmes conditions, en utilisant le même accès réseau, le même agent mobile représentant le jeu et la même configuration. Avant chaque ensemble de tests, tous les systèmes ont été remis dans un état initial et la plate-forme d agent mobile Grasshopper a été réinitialisée. Ainsi le classloader de la JVM était vidé et ne contenait pas d ancienne version de l objet GameAgent. Chaque test a été répété au moins cinq fois et les résultats ont été calculés sous la forme de la valeur moyenne. Examiner les paramètres et la métrique Tous les essais ont été réalisés dans les mêmes conditions en utilisant le jeu MinesSweeper. La taille de la classe du jeu est environ de 10 K bytes (voir fig. 3). La mesure renvoie trois métriques principales: 1) le temps d enregistrement de joueur au service d agent mobile, 2) le temps de transférer du code de l objet GameAgent après abonnement et 3) le temps nécessaire pour avoir le jeu prêt à jouer à partir de l abonnement. Nous avons ajouté une métrique supplémentaire concernant l appréciation subjective de la qualité de jeu (jouabilité). Ce quatrième élément de mesure est une métrique ad-hoc basée seulement sur le sentiment des utilisateurs: rapidité de l interaction avec le système igames. Nous avons établi une échelle représentant cette jouabilité: 5 excellent, 4 bon, 3 moyen, 2 jouable avec difficulté, et 1 injouable. Conclusion et travaux futurs Les agents mobiles émergent des concepts théoriques pour améliorer les services offerts. Les investigations ci-dessus qualifient et mesurent l utilité des agents mobiles dans un contexte particulier, mais bien représentatif des futurs développements incluant multimédia et mobilité. Nos résultats ont clarifié quelques avantages et limitations; par exemple, pour qu un agent mobile puisse fonctionner sur un terminal, ce dernier a besoin d une solution software (Grasshopper), et ces dernières sont gourmandes en ressource CPU, mémoire et temps d exécution. De plus, leurs réalisations ne tiennent habituellement pas compte de la limitation de la largeur de bande; dans notre cas le temps d exécution de l agent jeu est trop lent si la vitesse d accès est inférieure à environ 1 Mbps. Cependant nous avons pu mettre en évidence le potentiel des agents mobiles en terme d avantages et de flexibilité. Nos futures investigations se porteront sur l implémentation de solutions d agent mobile plus légère, mais nous poursuivrons également nos études sur des problèmes liés à la simultanéité et à la synchronisation des agents agissants les uns avec les autres. Tableau 1 Vue d ensemble des différents accès de réseau FI 1-21 janvier 2003 page 15

16 igames Implémentation d un service de jeu en réseau employant les agents mobiles fig.3 igames: Représentations des résultats de métriques et estimation de qualité de Jeu MinesSweeper pour l ipaq PDA et PC en fonction des différents types d accès Références [1] Laurent Perato and Khaldoun Al Agha. Web access for the UMTS air interface by using mobile agents. In IEEE WCNC 02: Wireless Communications and Networking Conference, Orlando, USA, March [2] Bernard Burg: Agents in the World of Active Web-services, Hewlett Packard Labs, USA, 2002, stl/maas/docs/hpl pdf. [3] Hartmann Jens, Song Wei: Agent Technology for Future Mobile Networks. Second Annual UCSD Conference on Wireless Communications in co-operation with the IEEE Communications Society, San Diego, USA, March [4] Grasshopper, the agent development platform developed by IKV++ Technologies, [5] Hartmann Jens, Carsten Pils: The User Agent: An approach for service and profile management in wireless access systems, International Pacific Rim International Workshop on Intelligent Information Agents (PRIIA 2000), Melbourne, Australia, August [6] Fiorenzo Gamba, Jean-Frédéric Wagen: Mobile Agent Gaming in Micro-Spot, Technical paper, University of Applied Sciences of Western Switzerland, 2002, available at shlikah.eif.ch/igames [7] Jeode TM PDA Edition is an Java runtime environment implementation of the Insignia, [8] igames Project ressorces, shlikah.eif.ch FI 1-21 janvier 2003 page 16

17 Renseignements (les matins des lu, me & ve) 021/ Programme des cours organisés par le Service informatique central de l EPFL Ces cours sont ouverts à tous, membres ou non de l EPFL. Pour le personnel de l EPFL, le SIC se charge des frais de cours. Les descriptifs des cours sont sur Internet: Renseignements (tous les matins) Josiane.Scalfo@epfl.ch 021/ Fax: 021/ CONDITIONS D INSCRIPTION En cas d empêchement à suivre le(s) cours, l élève avertira le Service informatique central au minimum une semaine à l avance (sauf cas exceptionnel), faute de quoi le SIC se réserve le droit de facturer à son unité les frais occasionnés pour le cours. Une confirmation parviendra à l élève environ deux semaines avant le(s) cours. S il est déjà complet, l élève sera informé de suite et son nom placé en liste d attente. Dès qu un cours identique sera fixé, il recevra un nouveau formulaire d inscription. Le SIC se réserve le droit d annuler un cours si le nombre minimum de 4 participants n est pas atteint ou pour des raisons indépendantes de sa volonté. Aucune compensation ne sera due par le SIC. INTRODUCTION AU POSTE DE TRAVAIL OS Nom du cours N 1/2 jour(s) Date(s) Horaire Mac Internet & Entourage (Outlook express) :30-17:00 Win Internet & Outlook express :30-12:00 Nouveau Mac Macintosh, transition de OS 9 à OS X :30-12:00 Mac Macintosh, votre machine en pratique :30-17:00 Mac Macintosh, votre machine en pratique :30-12:00 Win Windows XP, votre machine en pratique :30-12:00 ACQUISITION ET TRAITEMENT DE DONNÉES OS Nom du cours N 1/2 jour(s) Date(s) Horaire Win LabVIEW Basics au :30-17:00 Win LabVIEW Basics & :30-17:00 Win LabVIEW DAQ & :30-17:00 Win LabVIEW Programmation avancée au :30-17:00 Win LabVIEW Real-Time & :30-17:00 Win LabVIEW Vision IMAQ & :30-17:00 FI 1-21 janvier 2003 page 17

18 Formation BASE DE DONNÉES OS Nom du cours N 1/2 jour(s) Date(s) Horaire Win Access, introduction , 10, 13 & :30-17:00 Mac FileMaker Pro, 1-introduction :30-12:00 Win FileMaker Pro, 1-introduction :30-12:00 Mac FileMaker Pro, 2-perfectionnement: modèles :30-12:00 Mac Mac Mac FileMaker Pro, 3-perfectionnement: liste de valeurs et options :30-17:00 FileMaker Pro, 4-perfectionnement: scripts et boutons :30-12:00 FileMaker Pro, 5-avancé: développement d une base de données , 06 & :30-12:00 DESSIN OS Nom du cours N 1/2 jour(s) Date(s) Horaire Mac Illustrator, introduction & :30-12:00 Mac Illustrator, niveau avancé :30-17:00 ÉDITION OS Nom du cours N 1/2 jour(s) Date(s) Horaire Win Acrobat (PDF) :30-17:00 Mac Acrobat (PDF) :30-17:00 Win FrameMaker, 1-mise en forme , 06 & :30-17:00 Mac FrameMaker, 1-mise en forme , & :30-17:00 Win FrameMaker, 2-livre et EndNote :30-17:00 Mac FrameMaker, 2-livre et EndNote :30-17:00 Mac In-Design , 12 & :30-17:00 - Nouveau Win Word XP, les nouveautés et astuces :30-17:00 Win Word, atelier d exercices :30-12:00 Mac Word, atelier d exercices :30-12:00 Win Word, images et colonnes :30-12:00 Mac Word, images et colonnes :30-17:00 Win Word, longs documents :30-12:00 Mac Word, longs documents :30-12:00 Win Word, modèles et publipostage (mailing) :30-17:00 Mac Word, modèles et publipostage (mailing) :30-12:00 Win Word, outils :30-12:00 Mac Word, outils :30-12:00 Mac Word, styles :30-12:00 Win Word, tableaux :30-17:00 Mac Word, tableaux :30-17:00 FI 1-21 janvier 2003 page 18

19 Formation OUTLOOK OS Nom du cours N 1/2 jour(s) Date(s) Horaire Win Outlook XP (messagerie) :30-12:00 Win Outlook XP, atelier d exercices :30-12:00 PRÉSENTATION OS Nom du cours N 1/2 jour(s) Date(s) Horaire Mac PowerPoint, introduction :30-17:00 Win PowerPoint, les présentations & :30-12:00 Mac PowerPoint, les présentations & :30-17:00 Nouveau Nouveau Nouveau Nouveau Nouveau Nouveau PROGRAMMATION OS Nom du cours N 1/2 jour(s) Date(s) Horaire Win Win Win.NET - Développement.NET FrameWork VB avec VB.NET au :30-17:00.NET - Développement d applications MS.NET pour Windows & :30-17:00.NET - Développement d applications Web avec Visual Studio.NET (ASP) au :30-17:00 Win.NET - Introduction à Visual Basic.NET au :30-17:00 Win.NET - Programmation en C# au :30-17:00 Win Java au :30-17:00 Win Java avancé au :30-17:00 Win Java Script au :30-17:00 Win Java Serveurs d applications J2EE au :30-17:00 Linux Langage C au :30-17:00 Linux Langage C au :30-17:00 Linux MPI, Introduction à la programmation parallèle au :30-17:00 Linux PHP au :30-17:00 Win Nouveau Win Programmation: introduction pour débutant (avec Java) au :30-17:00 Programmation: introduction pour débutant (avec VB.NET) au :30-17:00 Linux SQL - My SQL & :30-17:00 Linux XML et technologies associées au :30-17:00 SYSTÈME OS Nom du cours N 1/2 jour(s) Date(s) Horaire Linux Linux, introduction au :30-17:00 Win Windows 2000, active directory au :30-17:00 Win Windows 2000, administration au :30-17:00 Win Windows 2000, comment sécuriser votre réseau, concrètement au :30-17:00 Win Windows 2000, configurations clients et serveurs & :30-17:00 Win Windows 2000, implémentation Professionnel et Serveur (core technologies) au :30-17:00 FI 1-21 janvier 2003 page 19

20 Formation Win Windows 2000, performance, tuning :30-17:00 Win Windows 2000, prise en charge d une infrastructure réseau au :30-17:00 Win Windows 2000, technique de déploiement RIS :30-17:00 Win Windows XP Pro, utilisateurs avancés :30-17:00 TABLEUR OS Nom du cours N 1/2 jour(s) Date(s) Horaire Win Excel, 1-introduction :30-12:00 Mac Excel, 1-introduction :30-17:00 Win Excel, 2-feuille de calcul , 07 & :30-12:00 Mac Excel, 2-feuille de calcul , 19 & :30-12:00 Win Excel, base de données & :30-12:00 Win Excel, graphiques :30-12:00 Mac Excel, graphiques :30-12:00 WWW - WEB OS Nom du cours N 1/2 jour(s) Date(s) Horaire Mac Dreamweaver, 1ère partie & :30-17:00 Mac Dreamweaver, 2ème partie & :30-17:00 Win Dreamweaver, avancé :30-17:00 Mac Fireworks, création d éléments graphiques & :30-12:00 Mac Flash, 1ère partie , 04 & :30-12:00 Mac Flash, 2ème partie & :30-12:00 Mac GoLive, 2ème partie & :30-17:00 Win Jahia:création de sites Web :30-17:00 INSCRIPTION POUR LES COURS ORGANISÉS PAR LE SIC A retourner à Josiane Scalfo ou à Danièle Gonzalez, SIC-EPFL, CP 121, 1015 Lausanne Je, soussigné(e) Nom:... Prénom:... Tél.: Fonction:... Institut:... Faculté:... Adresse:... m engage à suivre le(s) cours dans son (leur) intégralité et à respecter l horaire selon les conditions d inscription: Nom du cours N du cours N cours de remplacement Date du cours... Pour les cours système Windows, choix du support de cours en français o en anglais o Date:... Signature:... Autorisation du chef hiérarchique (nom lisible et signature):... Intérêt et souhait pour d autres cours Description ou titre des cours que je souhaite voir organiser par le SIC:... FI 1-21 janvier 2003 page 20