version PDF - Flash informatique
Transcription
version PDF - Flash informatique
ECOLE POLYTECHNIQUE FEDERALE DE LAUSANNE La génération de documents PDF depuis un serveur applicatif [email protected] & [email protected], Hôpitaux Universitaires de Genève Introduction Dans bien des applications de type Web, il est nécessaire de générer des documents au format PDF (www.adobe. 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 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/2003 1 2 2 2 3 11 13 17 21 23 24 La génération de documents PDF depuis un serveur applicatif Cellule AFS epfl.ch en service public Propriétaires de noms de domaines: ayez l’oeil sur vos contrats! Poste pour jeune chercheur Réseaux IP – Voix et multimédia sur IP Un projet pionnier de Voice over IP (VoIP) au Centre Cantonal des Télécommunications (CCT) iGames – Implémentation d’un service de jeu en réseau employant les agents mobiles Programme des cours FileMaker Pro 5.5 ou 6.0 – Sésame ouvre-toi ! SWITCH en vitesse Calendrier Prochaines parutions 2 3 4 5 6 SP 7 8 9 10 délai rédaction 06.02.03 06.03.03 03.04.03 15.05.03 19.06.03 28.08.03 02.10.03 30.10.03 27.11.03 parution 25.02.03 25.03.03 29.04.03 03.06.03 08.07.03 19.08.03 16.09.03 21.10.03 18.11.03 16.12.03 FI 1 - 21 janvier 2003 – page 1 Cellule AFS epfl.ch en service public (A single, shared name space for all users, from all machines) [email protected], SIC Dans le Flash informatique du 19 novembre 2002 (http://sawww.epfl.ch/SIC/SA/publications/FI02/fi-9-2/92-page3.html), 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! 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: http://lglwww.epfl.ch/ 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 +41 21 693 4231, Fax +41 21 693 5079 mailto:[email protected] [email protected], SIC Flash informatique 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 !■ 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, [email protected] 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: http://sic.epfl.ch/publications/ Adresse: SIC-SA EPFL, CP 121, CH-1015 Lausanne Téléphone: +41 21 69 32246 & 32247 FI 1 - 21 janvier 2003 – page 2 Réseaux IP Voix et multimédia sur IP Antoine Delley, EIA-FR, département des technologies de l’information, [email protected] L es 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 (www.itu.org), ont participé à ce symposium mis sur pied par ICTnet (www.ictnet.ch) et l’EIA-FR (www.eif.ch). 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 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) FI 1 - 21 janvier 2003 – page 4 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. 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 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 172.190.30.24. Le paramètre m indique qu’il s’agit d’un flux audio qui utilisera le port UDP 49150 et le protocole RTP. Il requiert l’algorithme de codage audio G.723.1 (valeur 4). Dans le sens opposé, le codage audio est de type GSM (valeur 0). tué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 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 effecFI 1 - 21 janvier 2003 – page 6 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 : http://www2.epfl.ch/e-scale. Avec nos excuses. [email protected] 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) (www.apple.com/webobjects) et par conséquent le language Java (jdk 1.3.1 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 (www.reportmill.com) ❚ PDFGenerator (www.cluster9.com) ❚ iText: (sourceforge.net/projects/itext/) ❚ RReport: (www.java4less.com/print_java_e.htm) ❚ FOP: (xml.apache.org/fop/) ❚ SVGObjects: (www.svgobjects.com) 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 (www.macromedia.com/ 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, (www.adobe.com/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 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 0.23. 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) (www.apple.com/webobjects) WebObjects(tm) est un environnement de développement et de déploiement d’applications Web dont l’origine FI 1 - 21 janvier 2003 – page 8 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 1.3.1 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-8859-1"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/ 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> 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/372.33.11</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 La génération de documents PDF depuis un serveur applicatif On voit ici un certain nombre de balises <WEBOBJECT>. 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-8859-1"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/ 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 ; } FI 1 - 21 janvier 2003 – page 10 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. 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) [email protected], SIC A vec 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 ([email protected]). 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 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. FI 1 - 21 janvier 2003 – page 12 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. ■ iGames Implémentation d’un service de jeu en réseau employant les agents mobiles Fiorenzo Gamba, [email protected] & Jean-Frédéric Wagen, [email protected], EIA-FR, Ecole d’ingénieurs et d’architectes de Fribourg - http://shlikah.eif.ch L a 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 802.11 (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 HotSpots, 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 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é FI 1 - 21 janvier 2003 – page 14 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 2.4.10 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 2002. La plate-forme Grasshopper a besoin d’un environnement d’exécution Java (JRE). Sun Microsystems JRE 1.3.1 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: JeodeTM PDA Edition [7]. Jeode est une solution d’Insignia Inc. 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 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 2002. [2] Bernard Burg: Agents in the World of Active Web-services, Hewlett Packard Labs, USA, 2002, www.hpl.hp.com/org/ stl/maas/docs/HPL-2001-295.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 1999. FI 1 - 21 janvier 2003 – page 16 [4] Grasshopper, the agent development platform developed by IKV++ Technologies, www.grasshopper.de. [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 2000. [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] JeodeTM PDA Edition is an Java runtime environment implementation of the Insignia,www.insignia.com [8] iGames Project ressorces, shlikah.eif.ch ■ Programme des cours organisés par le Service informatique central de l’EPFL Renseignements (les matins des lu, me & ve) [email protected] ✆ 021/69 353 14 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: http://sic.epfl.ch/formation CONDITIONS D’INSCRIPTION Renseignements (tous les matins) [email protected] ✆ 021/69 322 44 Fax: 021/69 322 20 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) Mac Win Date(s) Horaire Internet & Entourage (Outlook express) 03-0053 1 19.02.2003 13:30 - 17:00 Internet & Outlook express 03-0030 1 20.02.2003 08:30 - 12:00 Nouveau Mac Macintosh, transition de OS 9 à OS X 03-0054 1 25.02.2003 08:30 - 12:00 Mac Macintosh, votre machine en pratique 03-0052 1 05.02.2003 13:30 - 17:00 Mac Macintosh, votre machine en pratique 03-0055 1 07.03.2003 08:30 - 12:00 Win Windows XP, votre machine en pratique 03-0029 1 23.01.2003 08:30 - 12:00 ACQUISITION ET TRAITEMENT DE DONNÉES OS Win Win Win Win Win Win Nom du cours LabVIEW Basics 1 LabVIEW Basics 2 LabVIEW DAQ LabVIEW Programmation avancée LabVIEW Real-Time LabVIEW Vision IMAQ N˚ 1/2 jour(s) 03-0014 6 03-0023 4 03-0018 4 03-0024 6 03-0016 4 03-0020 4 Date(s) 17 au 19.02.2003 22 & 23.05.2003 20 & 21.03.2003 16 au 18.06.2003 17 & 18.03.2003 22 & 23.04.2003 Horaire 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 FI 1 - 21 janvier 2003 – page 17 Formation BASE DE DONNÉES OS Nom du cours Win Mac Win Mac Mac Access, introduction FileMaker Pro, 1-introduction FileMaker Pro, 1-introduction FileMaker Pro, 2-perfectionnement: modèles FileMaker Pro, 3-perfectionnement: liste de valeurs et options FileMaker Pro, 4-perfectionnement: scripts et boutons FileMaker Pro, 5-avancé: développement d’une base de données Mac Mac N˚ 1/2 jour(s) Date(s) Horaire 03-0131 03-0064 03-0050 03-0065 4 1 1 1 03-0066 1 18.02.2003 13:30 - 17:00 03-0067 1 26.02.2003 08:30 - 12:00 03-0068 3 04, 06 & 11.03.2003 08:30 - 12:00 03, 10, 13 & 17.02.03 23.01.2003 06.02.2003 11.02.2003 13:30 - 17:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 DESSIN OS Nom du cours Mac Mac Illustrator, introduction Illustrator, niveau avancé N˚ 1/2 jour(s) 03-0132 03-0123 2 2 Date(s) Horaire 20 & 21.02.2003 08:30 - 12:00 13.03.2003 08:30 - 17:00 ÉDITION OS Win Mac Win Mac Win Mac Mac Nouveau Win Win Mac Win Mac Win Mac Win Mac Win Mac Mac Win Mac - Nom du cours Acrobat (PDF) Acrobat (PDF) FrameMaker, 1-mise en forme FrameMaker, 1-mise en forme FrameMaker, 2-livre et EndNote FrameMaker, 2-livre et EndNote In-Design Word XP, les nouveautés et astuces Word, atelier d’exercices Word, atelier d’exercices Word, images et colonnes Word, images et colonnes Word, longs documents Word, longs documents Word, modèles et publipostage (mailing) Word, modèles et publipostage (mailing) Word, outils Word, outils Word, styles Word, tableaux Word, tableaux FI 1 - 21 janvier 2003 – page 18 N˚ 1/2 jour(s) 03-0049 03-0069 03-0047 03-0061 03-0048 03-0062 03-0122 03-0033 03-0081 03-0082 03-0036 03-0077 03-0038 03-0079 03-0039 03-0080 03-0037 03-0078 03-0075 03-0035 03-0076 1 1 3 3 1 1 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Date(s) Horaire 12.02.2003 03.03.2003 04, 06 & 11.02.2003 25, 27.02 & 04.03.2003 19.02.2003 18.03.2003 05, 12 & 19.03.2003 20.02.2003 27.02.2003 12.03.2003 04.02.2003 11.03.2003 17.02.2003 25.03.2003 04.03.2003 02.04.2003 13.02.2003 20.03.2003 19.02.2003 27.01.2003 06.03.2003 13:30 - 17:00 13:30 - 17:00 13:30 - 17:00 13:30 - 17:00 13:30 - 17:00 13:30 - 17:00 13:30 - 17:00 13:30 - 17:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 13:30 - 17:00 08:30 - 12:00 08:30 - 12:00 13:30 - 17:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 13:30 - 17:00 13:30 - 17:00 Formation OUTLOOK OS Nom du cours Win Win Outlook XP (messagerie) Outlook XP, atelier d’exercices N˚ 1/2 jour(s) 03-0087 03-0088 1 1 Date(s) Horaire 03.02.2003 08:30 - 12:00 18.02.2003 08:30 - 12:00 PRÉSENTATION OS Mac Win Mac Nom du cours PowerPoint, introduction PowerPoint, les présentations PowerPoint, les présentations N˚ 1/2 jour(s) 03-0070 1 03-0043 2 03-0071 2 Date(s) 03.02.2003 28 & 30.01.2003 10 & 12.02.2003 Horaire 13:30 - 17:00 08:30 - 12:00 13:30 - 17:00 PROGRAMMATION OS Nouveau Win Nouveau Win Nouveau Win Nouveau Win Nouveau Win Win Win Win Win Linux Linux Linux Linux Nouveau Win Nouveau Win Linux Linux Nom du cours .NET - Développement .NET FrameWork VB avec VB .NET .NET - Développement d’applications MS .NET pour Windows .NET - Développement d’applications Web avec Visual Studio .NET (ASP) .NET - Introduction à Visual Basic .NET .NET - Programmation en C# Java Java avancé Java Script Java Serveurs d’applications J2EE Langage C Langage C++ MPI, Introduction à la programmation parallèle PHP Programmation: introduction pour débutant (avec Java) Programmation: introduction pour débutant (avec VB.NET) SQL - My SQL XML et technologies associées N˚ 1/2 jour(s) Date(s) Horaire 03-0095 10 10 au 14.02.2003 08:30 - 17:00 03-0094 4 06 & 07.02.2003 08:30 - 17:00 03-0096 03-0093 03-0111 03-0113 03-0118 03-0115 03-0114 03-0109 03-0116 03-0110 03-0097 10 6 8 10 10 6 10 10 10 8 6 03-0119 10 23 au 27.06.2003 08:30 - 17:00 03-0120 03-0108 03-0117 10 4 6 30.06 au 04.07.2003 08:30 - 17:00 18 & 19.02.2003 08:30 - 17:00 19 au 21.05.2003 08:30 - 17:00 10 au 14.03.2003 03 au 05.02.2003 03 au 06.03.2003 31.03 au 04.04.2003 16 au 20.06.2003 14 au 16.04.2003 07 au 11.04.2003 20 au 26.02.2003 12 au 16.05.2003 18 au 21.03.2003 27 au 29.01.2003 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 08:30 - 17:00 SYSTÈME OS Nom du cours Linux Win Win Win Linux, introduction Windows 2000, active directory Windows 2000, administration Windows 2000, comment sécuriser votre réseau, concrètement Windows 2000, configurations clients et serveurs Windows 2000, implémentation Professionnel et Serveur (core technologies) Win Win N˚ 1/2 jour(s) Date(s) Horaire 03-0112 03-0102 03-0106 6 10 6 25 au 27.03.2003 08:30 - 17:00 07 au 13.02.2003 08:30 - 17:00 11 au 13.03.2003 08:30 - 17:00 03-0107 03-0104 8 4 26 au 31.03.2003 08:30 - 17:00 27 & 28.02.2003 08:30 - 17:00 03-0099 10 27 au 31.01.2003 08:30 - 17:00 FI 1 - 21 janvier 2003 – page 19 Formation Win Win Win Win Windows 2000, performance, tuning Windows 2000, prise en charge d’une infrastructure réseau Windows 2000, technique de déploiement RIS Windows XP Pro, utilisateurs avancés 03-0100 2 04.02.2003 08:30 - 17:00 03-0105 03-0101 03-0103 8 2 2 04 au 07.03.2003 08:30 - 17:00 05.02.2003 08:30 - 17:00 25.02.2003 08:30 - 17:00 TABLEUR OS Nom du cours Win Mac Win Mac Win Win Mac Excel, 1-introduction Excel, 1-introduction Excel, 2-feuille de calcul Excel, 2-feuille de calcul Excel, base de données Excel, graphiques Excel, graphiques N˚ 1/2 jour(s) 03-0044 03-0083 03-0045 03-0084 03-0086 03-0046 03-0085 1 1 3 3 2 1 1 Date(s) Horaire 27.01.2003 17.02.2003 05, 07 & 12.02.2003 17, 19 & 24.03.2003 07 & 09.04.2003 19.02.2003 31.03.2003 08:30 - 12:00 13:30 - 17:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 WWW - WEB OS Nom du cours N˚ 1/2 jour(s) Mac Mac Dreamweaver, 1ère partie Dreamweaver, 2ème partie 03-0072 03-0073 2 2 Win Mac Mac Mac Mac Win Dreamweaver, avancé Fireworks, création d’éléments graphiques Flash, 1ère partie Flash, 2ème partie GoLive, 2ème partie Jahia:création de sites Web 03-0074 03-0060 03-0058 03-0059 03-0057 03-0127 2 2 3 2 2 1 Date(s) Horaire 04 & 06.02.2003 13:30 - 17:00 11 & 13.02.2003 13:30 - 17:00 24.02.2003 03 & 05.03.2003 03, 04 & 10.02.2003 17 & 18.02.2003 27 & 29.01.2003 28.01.2003 08:30 - 17:00 08:30 - 12:00 08:30 - 12:00 08:30 - 12:00 13:30 - 17:00 13: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: ..................................................................... Tél.: ............................. Prénom:......................................................................... E-Mail:............................................................................ Institut: .......................................... Fonction: ......................................... 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 Date: .............................................................................................. en français o en anglais o 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 FileMaker Pro 5.5 ou 6.0 Sésame ouvre-toi ! Isabelle Fernandez, [email protected] S i vos bonnes résolutions prises pour 2003, sont : 1. Arrêter de fumer 2. Moins jouer sur ma PlayStation 2 3. Ne plus raconter des blagues sur les blondes 4. Surfer toute la saison 5. Sécuriser mes bases de données. ❚ Si vous respectez le point 3, ❚ Si le point 4 c’est sur la neige, ❚ Si vos bases de données du point 5 sont créées avec FileMaker, alors vous pouvez lire et appliquer les conseils ci-dessous. Bonne année ! Comment protéger l’accès à toutes les données Afin de limiter l’ouverture, soit la lecture et l’écriture des données d’un fichier FileMaker, il suffit d’ajouter un mot de passe : ❚ Fichier / Autorisation d’accès / Mot de passe... ❚ Donner un mot de passe, si possible alphanumérique et sans caractère accentué ❚ Valider Créer Le premier mot de passe correspond au niveau administrateur de la base de données. Vous pouvez bien entendu ajouter des mots de passe supplémentaires en limitant les fonctionnalités autorisées; pour cela il est nécessaire de décocher les options présentes dans la zone Autorisation d’accès en fonction des actions à limiter. Comment limiter la lecture de certains modèles Certains modèles peuvent contenir des informations confidentielles dont la lecture n’est pas offerte à tous les utilisateurs. Pour limiter la vue de certains modèles en fonction des utilisateurs, il est nécessaire de gérer les mots de passe et les groupes. ❚ Créer les mots de passe pour chaque type d’utilisateurs ou pour chaque utilisateur Un mot de passe peut bien entendu être utilisé par un groupe d’utilisateurs. Dans ce cas, il est distribué à toutes les personnes concernées. Il est donc prudent, dans la fenêtre de définition des mots de passe, de décocher l’option Nouveau mot de passe. Cela évite qu’un utilisateur modifie le mot de passe en question et limite ainsi l’accès à ses collègues. La notion de mot de passe permet d’allouer des fonctionnalités FileMaker spécifiques à l’activité des utilisateurs. ❚ Fichier / Autorisation d’accès / Groupes... ❚ Donner un nom au futur groupe, si possible en relation avec le type d’utilisateurs ❚ Valider Créer ❚ Créer tous les groupes nécessaires Si les mots de passe limitent les actions possibles, les groupes permettent de définir les modèles et rubriques accessibles. En résumé, les mots de passe gèrent les actions, les groupes gèrent la vue des données. L’art subtil réside alors dans les liens à créer entre les mots de passe et les groupes. ❚ Fichier / Autorisation d’accès / Table des autorisations... ❚ Sélectionner le premier groupe, soit le groupe niveau administrateur ❚ Activer (noircir) ou désactiver (griser) les différents mots de passe correspondant aux personnes ayant accès à la totalité du fichier; il faut pour cela cliquer sur les pastilles précédant les noms ❚ Utiliser le bouton Valider ❚ Activer le deuxième groupe ❚ Associer les mots de passe correspondants; le mot de passe général fait automatiquement partie de tous les groupes ❚ Activer (noircir), limiter à la lecture seule (blanchir) ou refuser l’accès (griser) les pastilles correspondant aux modèles FI 1 - 21 janvier 2003 – page 21 ❚ Valider ❚ Procéder ainsi pour tous les groupes nécessaires Comment limiter à la lecture certaines rubriques ❚ ❚ ❚ ❚ ❚ ❚ Affichage / Mode modèle Sélectionner le modèle désiré Cliquer la rubrique à protéger Format / Format de rubrique... Décocher l’option Autoriser la saisie dans la rubrique Valider la fenêtre de dialogue L’inconvénient des ces méthodes réside dans le fait que cette rubrique ne permet certes plus l’écriture, mais également la recherche. Vous pouvez également agir plus finement en limitant à la lecture seule ou en interdisant la lecture des rubriques elles-mêmes en fonction des utilisateurs. ❚ Créer les mots de passe et les groupes, comme expliqué dans les points ci-dessus ❚ Sélectionner le groupe à modifier ❚ Activer (noircir), limiter à la lecture seule (blanchir) ou refuser l’accès (griser) les pastilles correspondant aux rubriques ❚ Valider Dans ce cas, tous les mots de passe associés à ce groupe n’auront plus accès à cette rubrique en lecture ou écriture (selon le niveau sélectionné) quel que soit le modèle sélectionné. Maintenant que vous avez la maîtrise des différents niveaux de protection dans FileMaker Pro 5.5 ou supérieur, notamment la gestion des mots de passe, vous pouvez encore perfectionner l’accès à votre fichier. Comment protéger certaines fiches Une autre méthode consiste à placer la rubrique sous forme de rubrique de fusion : ❚ Affichage / Mode modèle ❚ Sélectionner le modèle désiré ❚ Cliquer la position de la future rubrique ❚ Insertion / Fusionner... ❚ Sélectionner la rubrique à placer ❚ Valider la fenêtre de dialogue Cette méthode permet d’offrir l’accès en écriture selon certaines conditions, par exemple l’état d’un dossier. Si ce dernier est ouvert, l’écriture est autorisée; si le dossier est fermé, la modification de la fiche n’est plus autorisée. Pour cela il est naturellement nécessaire de posséder une rubrique spécifiant la nature du dossier. ❚ Fichier / Autorisation d’accès / Mot de passe... ❚ Sélectionner le mot de passe à «limiter» ❚ Sélectionner l’option Limité... dans le menu local présent à côté de la fonction «Modifier les fiches» ❚ Saisir la formule adéquate; dans notre exemple l’état du dossier doit être Ouvert pour permettre la modification de la fiche ❚ Valider les fenêtres de dialogue L’utilisateur ouvrant le fichier avec ce mot de passe ne pourra plus modifier les fiches possédant une autre valeur que Ouvert (soit Fermé ou vide) dans la rubrique Etat dossier. Seul l’administrateur du fichier, possédant le mot de passe général pourra déverrouiller cette fiche; il peut également permettre les modifications aux autres utilisateurs en insérant la valeur Ouvert dans la rubrique Etat du dossier. Pour revenir au message essentiel du début de cet article, et au vu de cette nouvelle année qui commence, le mot de passe Bonheur ouvre-toi reste valable...■ FI 1 - 21 janvier 2003 – page 22 SWITCH en vitesse [email protected], SIC D epuis le mois d’octobre 2002, l’EPFL possède un accès à SWITCH avec une bande passante de 400 Mbps, soit 4 fois plus qu’avant. En ce qui concerne les coûts et tarifs, il faut déjà savoir que le trafic payant n’est plus uniquement celui qui transite sur les lignes transatlantiques (USA) mais concerne tout ce qui n’est pas académique (voir la page de SWITCH : www.switch.ch/ network/international.html). Tout le trafic à destination de ressources académiques (comme Géant ou Internet2) est compris dans le forfait de base. Par contre l’accès à tous les autres sites, même en Suisse, fait désormais partie du trafic payé au volume entrant. En 2003, le prix du forfait de base correspond à celui de l’ancienne bande passante et le prix du Gbyte a baissé (15 Frs le Gbyte la semaine entre 08h00 et 20h00, détails sur mathe.epfl.ch) mais par contre le volume payant est désormais plus important. Cela signifie qu’il faut toujours rester attentif et conserver une attitude responsable de consommateur averti pour rester dans le cadre du budget alloué. Avec le projet SWITCHlambda, commencé par l’achat de fibres optiques entre Genève et Zürich, le but est d’avoir un investissement à long terme. Si la location de services ATM a donné une impulsion au réseau SWITCH, les aléas des prix avec les fournisseurs ne permettaient pas un développement intéressant dans le futur (www.switch.ch/network/ switchlambda/). SWITCH a donc décidé d’acquérir un patrimoine de fibres permettant d’évoluer avec les performances et les prix des équipements terminaux uniquement. Actuellement, le dédoublement de la première ligne (le long de l’autoroute) avec des lignes le long des voies de chemin de fer, permettra de s’affranchir totalement du réseau ATM et d'offrir une connexion à haut débit dans toute la Suisse. Ces efforts sont faits pour conserver des tarifs que les hautes écoles pourront payer durant de nombreuses années, ceci malgré les contraintes budgétaires. ■ FI 1 - 21 janvier 2003 – page 23 Calendrier JE 23.01.03 1515 Salle Wavre DIS – Direction informatique stratégique J.-Cl. Berney, +41 21 69 32590, courriel: [email protected] ME 29.01.03 1000 Salle Conférences SIC Conférence des Webmasters E. Mc Murray, +41 21 69 35672, courriel: [email protected] Info sur http://www.myepfl.ch/atelier LU 03.02.03 1715 IN202 Séminaire I&C — Prof. Gunnar Karlsson, KTH, Sweden Info sur: http://ic.epfl.ch/page6879.html LU 10.02.03 1715 IN202 Séminaire I&C — Prof. Alan Wills Info sur: http://ic.epfl.ch/page6879.html JE 13.02.03 1515 Salle BP-B CI – Comité informatique E. Sanchez, +41 21 69 32672, 32640, courriel: [email protected] MA 18.02.03 0845 Salle Polyvalente SIC Comité de rédaction du FI J. Dousson, +41 21 69 32246, courriel: [email protected] JE 20.02.03 1415 Salle Conférences SIC PolyPC — Groupe des utilisateurs de PC Ch. Zufferey, +41 21 69 34598, courriel: [email protected] Info sur: http://pcline.epfl.ch/pc/grp/home.htm JE 20.02.03 1515 Salle Wavre LU 03.03.03 1400 Salle Conférences SIC Conférence des Webmasters E. Mc Murray, +41 21 69 35672, courriel: [email protected] Info sur http://www.myepfl.ch/atelier JE 13.03.03 1515 Salle BP-B CI – Comité informatique E. Sanchez, +41 21 69 32672, 32640, courriel: [email protected] LU 17.03.03 1715 IN202 Séminaire I&C — Prof. François Baccelli, ENS and INRIA, France Info sur: http://ic.epfl.ch/page6879.html MA 18.03.03 0845 Salle Polyvalente SIC Comité de rédaction du FI J. Dousson, +41 21 69 32246, courriel: [email protected] JE 20.03.03 1415 Salle Conférences SIC PolyPC — Groupe des utilisateurs de PC Ch. Zufferey, +41 21 69 34598, courriel: [email protected] Info sur: http://pcline.epfl.ch/pc/grp/home.htm JE 20.03.03 1515 Salle Wavre DIS – Direction informatique stratégique J.-Cl. Berney, +41 21 69 32590, courriel: [email protected] LU 24.03.03 1715 IN202 Séminaire I&C — Prof. Michael Mendler, University of Bamberg, Germany:State Charts and Compositionality Info sur: http://ic.epfl.ch/page6879.html JE 03.04.03 1000 Salle Conférences SIC Conférence des Webmasters E. Mc Murray, +41 21 69 35672, courriel: [email protected] Info sur http://www.myepfl.ch/atelier JE 17.04.03 1415 Salle Conférences SIC PolyPC — Groupe des utilisateurs de PC Ch. Zufferey, +41 21 69 34598, courriel: [email protected] FI 1 - 21 janvier 2003 – page 24 DIS – Direction informatique stratégique J.-Cl. Berney, +41 21 69 32590, courriel: [email protected] ISSN 1420-7192