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