Projet de Diplôme. Mobile Doctor s Desktop

Dimension: px
Commencer à balayer dès la page:

Download "Projet de Diplôme. Mobile Doctor s Desktop"

Transcription

1 Projet de Diplôme Mobile Doctor s Desktop Auteur : Probst Julien Filière : Télécommunication Réseau Date : 13 décembre 2007 Professeur : Markus Jaton 1/105

2 Table des matières 1 Préface Motivation Problématique Cahier des charges Introduction Matériel & Technologies Personal Digital Assistant Phone JAVA Serveurs XML Services Web Utilisation des technologies XML : Utilisation des parsers XML : Envoi de données binaires Serveur d'applications : Conception Introduction Problématique lié au PDA Objectifs Fonctionnement de base Protocole de transfert Description d une application Conception Conclusion Serveur d applications : Réalisation Présentation Structure Fonctionnement Analyseur Couche Transport Sécurité Applications Conteneur d applications Chargeur d applications Package et classes Client lourd fixe Conclusion /105

3 7 Applications Développement d applications : X2JWS Application : Test Application : Démo Application : FichePatient Application : Web Conclusion Etude : Synchronisation du PDA Tests du serveur Scénarios Analyse du transport Améliorations Protocole Applications Divers Conclusion générale Bibliographique Liste des symboles et abréviations Annexes Création d une nouvelle application Installation SSL (Tiré de M.Badan) Journal de travail /105

4 1 Préface 1.1 Motivation Dans le cadre de la plate-forme iminet, un nombre important de fonctions sont implémentées sur le modèle client-serveur, avec un serveur d applications JBoss et des clients légers (Internet Explorer, Firefox ) abritant les fonctions d interfaçage avec l utilisateur. Pour fonctionnel et flexible que soit ce modèle, il montre ses limites dés que l on veut implémenter des applications plus gourmandes en interactions avec l utilisateur. D autre part, dés que les applications deviennent multi-sessions, l utilisateur se voit pénalisé par les contraintes de sécurité qui lui imposent de réintroduire son mot de passe pratiquement à chaque nouvelle interaction avec le serveur. Les facilités basées sur les cookies ou sur le stockage en local des mots de passe et implémentées par les navigateurs ou par les systèmes d exploitation ne sont en principe pas compatibles avec des systèmes à sécurité accrue, comme c est le cas des systèmes à vocation médicale, et manipulant des données personnelles sensibles. Un autre inconvénient qui se fait jour est la difficulté qu il y a de s adapter à différents éléments d affichage. Si en théorie, on peut utiliser des transformations XSLT pour adapter la page à un affichage de petites dimensions, il n en reste pas moins que la notion de formulaire avec laquelle sont implémentées la plupart des entrées de données sur le Web s accommode assez mal d écrans de petites dimensions (640 x 320, voir 320 x 240). De plus, la nécessité de rafraîchissement d une page entière est pénalisant dans le cas de liaisons à bas débit (GPRS), et AJAX, s il permet de résoudre des problèmes d interactivité, n est pas particulièrement économe en bande passante. Or, pour un médecin, l utilisation d un ordinateur de poche (PDA, Personal Digital Assistant) comme organe d entrée-sortie constitue une alternative intéressante, car il peut en principe l avoir toujours sur lui, et ainsi rester atteignable en urgences sans pour autant être assigné à résidence à proximité d un ordinateur, ou contraint de promener une lourde mallette contenant un ordinateur portable soumis à une séquence de boot-up plus ou moins fastidieuse. En conséquence, on se propose d implémenter un client dédié pour PDA, utilisant les protocoles Web (HttpRequest / HttpResponse) mais implémentant son propre moteur d affichage, dédié à l application, résident sur le PDA. Il devrait être possible d ajouter des applications au cours du temps, lesquelles pourront profiter des services offerts par le client dédié, (comme par exemple le téléchargement de nouvelles applications ou la mise à jour d applications existantes) mais avec un confort d utilisation incomparablement plus élevé, et un interface homme-machine (HMI) optimisé pour la plate-forme mobile. 1.2 Problématique Diverses applications existent déjà dans le cadre de iminet ; ces applications sont implémentées de manières diverses. La majorité d entre elles se fondent sur des clients légers, mais l une d elles au moins utilise un exécutable spécifique : il s agit de l application de génération de questionnaires. 4/105

5 Toutes les applications existantes ne sont pas forcément utiles sur un élément d entréesortie de dimensions réduites tel un PDA ; à l inverse, certaines applications n ont de sens que sur un élément portable et actif en permanence ; l intérêt du client dédié est que de nombreux services peuvent être mutualisés entre les diverses applications ; citons par exemple : Service réseau (connexions asynchrones sécurisées, implémentation du protocole http, avec requêtes asynchrones selon modèle XmlHttpRequest/Response, marshaling/unmarshaling XML, dispatching des requêtes entre applications) Service de sécurisation : les applications sont sécurisées selon un principe unique : la sécurisation d une application est valable pour toutes les autres, d éventuelles modifications dans les attributions de privilèges éventuels sont immédiatement prises en compte par toutes les applications Intégration et vérification des applications : le client dédié s assure que le code exécuté est un code valide, et que l application concernée n est pas en train de faire des opérations illicites. Cette vérification est analogue à la notion de «sandbox» que l on retrouve dans de nombreuses applications, en particulier dans le monde Java. Uniformité de l interface utilisateur (look and feel) entre les applications, support de fonctions avancées, comme le «glisser-déposer» entre des applications différentes, ou l édition interactive de champs, une aide précieuse sur des PDA au clavier souvent étriqué ou inexistant 5/105

6 Reconnaissance et téléchargement automatique de nouvelles applications lorsque nécessaire Mise à jour automatique des applications lors de l apparition de nouvelles versions Mise à disposition de librairies ayant des versions cohérentes entre elles L utilisation d un client dédié, ou client «riche» (client «lourd» dans certaines terminologies) permet de mutualiser des services très spécifiques, généralement peu ou pas supportés par des clients légers dont la vocation est beaucoup plus générique. Spécialement sur des terminaux de poche (PDA), les services habituellement offerts aux applications au niveau client sont assez pauvres et ne permettent pas aisément d implémenter des interfaces utilisateurs agréables et hautement sécurisés. D un autre côté, les technologies de la famille web 2, comme AJAX, si elles connaissent un succès incontestable dans des applications comme gmail ou Google Earth, se révèlent souvent décevantes en application réelle. Javascript n est pas à proprement parler un langage de programmation digne de ce nom, ses performances en parsing XML, par exemple, sont assez peu convaincantes, et beaucoup de programmeurs préfèrent utiliser JSON (Javascript Object Notation) plutôt que XML dans ce contexte. Sécuriser des scripts Javascript est un problème qui cherche encore une solution si tant est qu elle existe, et le support de Javascript pour des navigateurs pouvant s exécuter sur PDA est aléatoire. Pour ces diverses raisons, le client dédié semble être une solution intéressante et raisonnable à l intégration d applications biomédicales à l usage du médecin sur des ordinateurs de poche. Une autre caractéristique intéressante de ce client dédié réside en son intégration avec les fonctions du PDA. Les PDA modernes intègrent en effet de nombreuses fonctionnalités, comme l agenda électronique, le téléphone mobile GSM, les possibilités de visualisation, voire dans certains cas d édition de documents de type Office, la présence de navigation GPS pour certains modèles, les connexions sans-fil WiFi, et beaucoup d autres caractéristiques qui peuvent toutes s avérer utiles au praticien en particulier. Un client dédié peut, mieux qu un service client léger basé sur un navigateur, s intégrer aux applications existantes et tirer parti de ressources locales pour faciliter le travail du professionnel itinérant. Enfin, le client dédié peut, plus facilement qu un client léger, intégrer des fonctions de type PUSH, ou «push-like», et ainsi intégrer de manière harmonieuse les annonces spontanées du serveur vers le médecin, en se servant au besoin de canaux de communication multiples (GSM, WiFi, Web, etc ). 1.3 Cahier des charges Il s agit dans ce cadre d implémenter une infrastructure de sécurisation, de téléchargement, de mise à jour et de lancement d applications veillant à ce qu une application donnée ne puisse pas aisément être détournée de son usage premier (cheval de Troie, ou application patchée par décompilation de midlet, par exemple). Cette infrastructure fournira aussi quelques services d interface avec le PDA (comme par exemple un interface avec le carnet de rendez-vous ou avec la base de données de contacts) à titre d exemple et de services aux applications. Enfin, l infrastructure comprendra un serveur d applications de support, contrôlant les paramètres utilisés par le terminal mobile, ainsi que les applications qui ont le droit de s exécuter à un instant donné. 6/105

7 Il en résulte de ce fait une application formée de trois parties bien distinctes : 1. Sécurisation du poste mobile, sécurisation et mise à jour des applications, authentification des utilisateurs 2. Services locaux, applications s exécutant sur le mobile 3. Services distants, parties «serveur» des applications du bureau mobile Chacune de ces trois parties sera traitée par un étudiant, à savoir : 1. Stephen Badan ETR 2. Grégoire Wuillamoz ETR 3. Julien Probst ETR 7/105

8 2 Introduction La partie me concernant repose sur la conception d une plateforme permettant la communication entre deux entités différentes : un client de type PDA et un serveur. Ces deux domaines ne sont pas du tout comparables, d un coté le serveur pouvant proposer une architecture très lourde composée d une multitude de fonctionnalités super complexes et de l autre un simple PDA aux performances et possibilités relativement restreintes. La problématique réside dans le fait de développer une passerelle offrant un maximum de possibilités tout en restant compatible et utilisable de manière optimale par ces deux domaines très différents. Lors de la conception, il faut donc impérativement prendre en compte plusieurs paramètres liés à l utilisation d un PDA comme : La sécurité relativement déplorable Les faibles performances La qualité de la connexion La compatibilité non assurée avec les technologies existantes Premièrement, la sécurité est un élément qui se doit d être optimal, vu le cadre médical du projet. Le simple fait d utiliser un PDA met en danger les données car il peut facilement être oublié, volé, atteint par différents virus ou encore lu sans authentification via un outil de synchronisation. Il faut donc développer un ensemble de fonctionnalités permettant de garantir la protection et l intégrité des données stockées sur les deux entités. Une méthode d authentification forte est donc requise, elle sera intégralement développée par M.Badan, ce qui induit la nécessité d établir un lien entre nos deux projets dans le but de garantir le meilleur niveau de sécurité possible. Le PDA étant une plateforme souffrant d un manque cruel de performances, il faut proposer un lien offrant une comptabilité optimale avec le serveur qui, pour sa part, utilise généralement des technologies très évoluées et relativement gourmandes en ressources. Cela nécessite une bonne compréhension au niveau de la gestion des ressources et du fonctionnement des technologies. Il faut donc utiliser un protocole de communication entre les deux entités le plus léger et le plus souple possible, dans le but de rendre les données interprétables de manière optimale, que ce soit par le serveur ou le PDA. Une autre problématique est liée à la qualité de la connexion, qui varie énormément vu l utilisation généralement «mobile» du PDA. En effet, il est fort probable que la connexion soit interrompue lors de l entrée dans un bâtiment ou lors d un passage dans un tunnel. De ce fait, le serveur se doit de proposer des solutions permettant de supporter de manière optimale les différentes coupures pouvant survenir à n importe quel instant. Il est aussi nécessaire de pouvoir garantir une intégrité des données si celles si s avéraient être altérées lors de l envoi. Finalement, la compatibilité reste un élément important qu il faut impérativement contrôler avant de débuter le développement. En effet, les plateforme mobiles sont en pleine émergence et les technologies actuelles destinées à un monde «fixe» ne sont pas forcément «adaptées» à ce type d utilisation. Au niveau des fonctionnalités de la plateforme serveur, il s agit de développer un environnement d exécution permettant de garantir le respect des contraintes préalablement définies. En effet, le serveur va offrir la possibilité d intégrer et d exécuter de nouvelles applications en garantissant de manière transparente la sécurité et l échange avec la plateforme client. Une application n aura donc pas besoin de ce soucier de ces 8/105

9 différentes facettes et pourra s occuper uniquement de sa partie «logique». Un objectif au niveau serveur est de faciliter au maximum l intégration et le développement des nouvelles applications. Cela en offrant des services simples, compréhensibles et facilement accessibles. De ce fait, le développeur pourra les utiliser directement, sans avoir à passer par une phase fastidieuse d élaboration. Afin de démontrer au mieux les capacités et fonctionnalités offertes par le serveur, diverses applications seront développées. 9/105

10 3 Matériel & Technologies 3.1 Personal Digital Assistant Phone Le but de ce projet étant de développer un client lourd sur une unité mobile, l heig-vd met à notre disposition un PDA Phone de la marque HTC, modèle 3300 STD. L écran tactile de ce PDA est de grande taille, ce qui permet l affichage d une interface graphique complète. Par contre, point négatif, ses performances sont inférieures à la moyenne, en raison de son processeur cadencé à 200MHz Caractéristiques 1 Processeur TI s OMAP 850, 201 MHz Système d exploitation Microsoft Windows Mobile 5.0 Mémoire Dimensions Poids Type d écran Téléphonie Contrôles ROM: 128MBs RAM: 64MB SDRAM 108 mm X 58 mm X 16.8 mm 130g avec la batterie 2.8'' TFT-LCD 240 X 320 avec couleurs GSM/GPRS/EDGE: 850, 900, 1800, 1900 (quadbande) HTC RollR (Trackball et Track Wheel) Connectivité Bluetooth 2.0 Wi-Fi : IEEE b/g HTC ExtUSB (11-pin mini-usb et audio jack en un) Appareil photo Audio Batterie Slot d extension Adaptateur secteur 2 Megapixels Microphone et haut-parleur intégrés Ecouteur: AMR/AAC/WAV/WMA/MP3 codec Batterie rechargeable Lithium-ion polymère Capacité: mah Temps de conversation: h Temp de veille: h Carte mémoire microsd AC input/frequency: 100 ~ 240V AC, 50/60Hz DC output: 5V and 1A /105

11 3.2 JAVA Présentation Java est à la fois un langage de programmation orienté objet et un environnement d'exécution portable. La force majeure de java réside dans sa capacité à pouvoir être «porté» sur différentes plateformes grâce à sa machine virtuelle. Le langage objet est un concept de programmation spécifique, dont le principe phare est d'associer les données avec les opérations en une seule et même entité, appelée «objet». Le but est de pouvoir séparer les différentes tâches logicielles, ce qui permet d'avoir des fondations plus solides, afin de bâtir une architecture de qualité. La machine virtuelle java est un environnement d'exécution développé pour une plateforme spécifique (Linux, Windows, Unix etc.). Une fois installée, elle permet d'exécuter les différentes applications java dans leur code d'origine et ce, sans recompilation. Il est donc possible de distribuer des applications compatibles avec les différents environnements existants. Grâce à sa portabilité, java est très intéressant dans le domaine du Web. En effet, l'intérêt du Web est de mettre la communauté d'utilisateurs en réseau et de promouvoir l'échange d'informations. Le fait que les utilisateurs se servent d'un grand nombre de machines différentes, nécessitant des applications dédiées, cause des problèmes de compatibilité qui peuvent être résolus grâce à Java Buts Lors de la création de java, les 5 objectifs suivants ont été fixés: 1. Utiliser une méthode orientée objet 2. Permettre à un même programme d'être exécuté sur plusieurs systèmes d'exploitation différents 3. Pouvoir utiliser les réseaux informatiques de manière native 4. Pouvoir exécuter du code distant de manière sûre 5. Être facile à utiliser et posséder les points forts des langages de programmation orientés objet comme le C Framework Java Un Framework est un ensemble de bibliothèques, d'outils et de conventions permettant le développement d'applications. Différents Frameworks Java ont été créés, dans le but de satisfaire le plus grand nombre de développeurs. J2SE J2SE (Java 2 Standard Edition) est le framework Java destiné aux applications pour poste de travail. 2 Inspiré de 11/105

12 Ce framework contient toutes les API de base, mais également toutes les API spécialisées pour le poste client tel que des API's graphiques AWT, Swing et Java2D, ainsi que différentes API d'usage général telles que des API's de parsing XML. J2EE J2EE est la version entreprise Java pour le développement d'applications robustes, fiables, adaptables et sécurisées coté serveur. Basé sur la plateforme java standard J2SE, J2EE est utilisé pour concevoir des architectures orientées services, en proposant différents modèles de composants et des APIs pour les communications. J2ME J2ME est le framework Java destiné aux plateformes mobiles telles que les PDA ou les téléphones mobiles. Ces différentes devices n'ont actuellement pas les performances d'un ordinateur de bureau ; il a donc fallu développer un framework optimisé. J2ME se présente ainsi comme une version allégée de J2SE, déclinée en plusieurs configurations composées de différents profils. Connected Limited Device Configuration (CLDC) est la configuration la plus allégée ; elle ne propose que le minimum de classes de base et peut être couplée à différents profils : Mobile information Device Profile (MIDP) qui améliore l'interface utilisateur et offre une API basique de développement de jeux 2D. Les applications créées pour ce profil sont appelées MIDLets Information Module Profile (IMP) qui est un profil dédié aux machines embarquées n'ayant aucun ou qu'un simple affichage et une connexion réseau limitée Connected Device Configuration (CDC) est une configuration qui contient une bonne partie des classes de J2SE excepté celles qui sont liées à une interface graphique. Cette configuration est plus riche que CLDC et propose les profils suivants : Foundation Profile, qui est basé sur J2SE mais n offre qu une interface utilisateur textuelle Personal Basis Profile qui est une extension du profil Foundation et qui inclut une partie de l'interface graphique de base AWT Personal Profile, qui est une extension du profil Personal Basis et ajoute de nouvelles fonctions AWT, de même qu'un support des applets Java et Internet Java propose différentes solutions pour le développement d'applications distribuées sur le Web comme des services accessibles depuis des postes client, des pages dynamiques ou encore des jeux. Voici une liste des différentes facettes proposées par Java : Servlet 3 Une servlet est une application java s exécutant coté serveur qui peut être appelée depuis un navigateur Internet ou autre. Son rôle est d effectuer divers traitements comme l accès 3 Tiré de 12/105

13 à une base de données, puis de retourner une réponse html, XML ou autre au client. Les servlets ont de nombreux avantages par rapport aux autres technologies côté serveur. Tout d'abord, étant donné qu'il s'agit d'une technologie Java, les servlets fournissent un moyen d'améliorer les serveurs web sur n'importe quelle plateforme, d'autant plus que les servlets sont indépendantes du serveur web. En effet, les servlets s'exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet et le serveur web. Ainsi le programmeur n'a pas à se soucier de détails techniques tels que la connexion au réseau ou la mise en forme de la réponse http. D'autre part, les servlets sont beaucoup plus performantes que les scripts, car il s'agit de pseudo-code, chargé automatiquement lors du démarrage du serveur ou bien lors de la connexion du premier client. Les servlets sont donc actives (résidentes en mémoire) et prêtes à traiter les demandes des clients grâce à des threads, tandis qu'avec les langages de script traditionnels, un nouveau processus est créé pour chaque requête HTTP. Cela génère donc une charge moins importante au niveau du processeur du serveur (d'autant plus qu'un système de cache peut permettre de stocker les calculs déjà accomplis) et permet d économiser de la place en mémoire. L'un des principaux atouts des servlets est la réutilisation, permettant de créer des composants encapsulant des services similaires, afin de pouvoir les réutiliser dans des applications futures. Enfin, une servlet étant une application Java, elle peut utiliser toutes les API Java afin de communiquer avec des applications extérieures, se connecter à des bases de données, accéder aux entrées-sorties (fichiers par exemple), etc. JSP 4 Le JavaServer Pages ou JSP est une technologie basée sur Java qui permet aux développeurs de générer dynamiquement du code HTML, XML ou tout autre type de page Web. La technologie permet au code Java et à certaines actions prédéfinies d'être ajoutés dans un contenu statique. La syntaxe du JSP ajoute des balises XML, appelées actions JSP, qui peuvent être utilisées pour appeler des fonctions. De plus, la technologie permet la création de bibliothèques de balises JSP (taglib) qui agissent comme des extensions au HTML ou au XML. Les bibliothèques de balises offrent une méthode indépendante de la plate-forme pour étendre les fonctionnalités d'un serveur HTTP. Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java. Un compilateur JSP peut générer un servlet Java en code source Java, qui peut à son tour être compilé par le compilateur Java, ou peut générer le pseudo-code Java interprétable directement. Dans les deux cas, il est utile de comprendre comment le compilateur JSP transforme la page en servlet Java. Les JSP sont spécialement conçues pour créer des pages WEB dynamiques, car la syntaxe de base permet d'inclure directement du code HTML sans passer par java. Le code java en lui-même est ajouté à l'intérieur du code JSP. Applet Une applet est un logiciel qui s'exécute dans une fenêtre d'un navigateur WEB. Cette 4 Tiré de 13/105

14 approche offre un moyen de fournir à l'utilisateur une application graphique et interactive sans l'installation d'un client lourd. Le fonctionnement de l'applet s'effectue du coté du client ; sa vitesse de fonctionnement va donc fortement dépendre de la machine utilisée. Java Script Java Script est un outil complémentaire à java ayant une syntaxe proche mais un concept fondamental complètement différent. Le code java Script peut être directement intégré au sein de pages Web pour y être exécuté sur le poste client depuis le navigateur. Java Script peut être utilisé pour interagir avec le document HTML ou encore pour réaliser des services dynamiques. Analyse Il faut faire une distinction entre les applications serveur et client. En effet, leur domaine d'exécution est totalement différent. Une application client comme une applet permet d'afficher des éléments graphiques et d'effectuer des traitements de données chez le client. Par contre, la vitesse d'exécution sera dépendante des performances de la machine utilisée. Pour sa part, une application serveur ne peut pas afficher une interface dédiée chez le client, mais peut interagir avec les données. Le traitement est ainsi centralisé et s'effectue sur le serveur, ce qui allège nettement le travail effectué par le client. Dans le cas de l'utilisation d'un client lourd qui va se charger de l'interface utilisateur et de la mise en page des données, l utilisation d une servlet est judicieuse. En effet, le protocole d échange entre le client et le serveur va être complexe et sera traité par différents modules. La servlet va donc servir uniquement de passerelle entre l environnement logique et la requête http. Si l on décide d'utiliser un client léger comme un navigateur (Firefox, IE, etc ), l'utilisation des JSP est préférable car elles permettent de coder directement dans le langage d'origine d'une page Web (HTML, XML, etc.) et d'inclure du code Java. Dans un domaine totalement différent où le but est de proposer une interface graphique dédiée à l'intérieur d'un navigateur WEB, l'utilisation des applets devient intéressante. Elles peuvent s'exécuter sur n'importe quelle plateforme, du moment qu'une machine virtuelle java est installée, et permettent de générer des éléments graphiques grâce aux différentes API's proposées. 3.3 Serveurs Différents types de serveurs vont devoir être utilisés. D une part, il nous faut un serveur permettant d exécuter nos servlets Java ; d autre part, nous avons besoin d un serveur pour le stockage de nos différentes informations dans une base de données. 14/105

15 3.3.1 Tomcat 5 Apache Tomcat est un conteneur de servlets J2EE. Issu du projet Jakarta, Tomcat est désormais un projet principal de la fondation Apache. Tomcat implémente les spécifications des servlets et des JSP de Sun Microsystems. Il inclut des outils pour la configuration et la gestion, mais peut également être configuré en éditant des fichiers de configuration XML. Comme Tomcat inclut un serveur HTTP interne, il est aussi considéré comme un serveur HTTP SQL 6 MySQL est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées. Il est multi-thread, multi-utilisateurs. C'est un logiciel libre développé sous double licence en fonction de l'utilisation qui en est faite : dans un produit libre (open-source) ou dans un produit propriétaire. Dans ce dernier cas, la licence est payante, sinon elle est libre. JDBC 7 La technologie JDBC (Java DataBase Connectivity) est une API fournie avec Java (depuis sa version 1.1) permettant de se connecter à des bases de données, c'est-à-dire que JDBC constitue un ensemble de classes permettant de développer des applications capables de se connecter à des serveurs de bases de données (SGBD). L'API JDBC a été développée de manière à permettre à un programme de se connecter à n'importe quelle base de données en utilisant la même syntaxe, ce qui signifie que l'api JDBC est indépendante du SGBD. De plus, JDBC bénéficie des avantages de Java, dont la portabilité du code, ce qui lui vaut, en plus d'être indépendante de la base de données, d'être indépendante de la plate-forme sur laquelle elle s'exécute. 3.4 XML Présentation XML (extensible Markup Language) est un langage informatique basé sur des balises, spécifié et recommandé par W3C. La formulation XML est une sorte de langage Html amélioré qui permet de définir ses propres balises. Cela a pour avantage d offrir une plus grande souplesse en permettant de décrire de nouvelles structures. De plus, contrairement à Html qui regroupe le contenu et la présentation dans un seul et même document, XML décrit uniquement le contenu. Cela évite de devoir créer différentes versions du document selon le type d'affichage désiré. Il est ainsi possible d'échanger des Parties inspirées de wikipedia.com 15/105

16 données XML entre plateformes complètement différentes, qui se chargeront elles-mêmes de les afficher grâce à une transformation XSLT. Un autre avantage est le fait de pouvoir définir la structure d'un fichier XML grâce à une DTD ou un schéma XML ; cela permet de décrire rigoureusement la forme qu un type de document doit respecter. Voici un exemple, où il faut simplement définir une personne en spécifiant son nom, son prénom et son âge. La représentation XML a pour avantage d'être très facilement compréhensible. <Personne> <Nom>Probst</Nom> <Prénom>Julien</Prénom> <Age>24</Age> </Personne> Buts 9 Les objectifs de conception de XML sont les suivants: 1. XML devrait pouvoir être utilisé sans difficulté sur Internet 2. XML devrait soutenir une grande variété d applications 3. XML devra être compatible avec SGML 4. Il devrait être facile d écrire des programmes traitant les documents XML 5. Le nombre d options dans XML doit être réduit au minimum, idéalement à aucune 6. Les documents XML devraient être lisibles par l homme et raisonnablement clairs 7. La conception de XML devrait être préparée rapidement 8. La conception de XML sera formelle et concise 9. Il devrait être facile de créer des documents XML 10. La concision dans le balisage de XML est de peu d importance Avantages Lisibilité : XML est facilement lisible car il ne contient que les informations Une structure arborescente : permettant de modéliser la majorité des problèmes informatiques Portabilité : Vu qu'il ne contient que le contenu sous format texte, il peut être interprété par n'importe quelle plateforme Déployable : il peut être facilement distribué par n'importe quels protocoles à même de transporter du texte, comme HTTP Extensibilité : un document XML doit pouvoir être utilisable dans tous les domaines d'applications /105

17 3.4.4 XML schéma 10 XML Schéma est un langage de description de format de document XML permettant de définir la structure d'un document XML. La connaissance de la structure d'un document XML permet notamment de vérifier la validité de ce document et de permettre la création de nouvelles données XML en respectant la structure. Une instance d'un XML Schéma est un peu l'équivalent d'une définition de type de document (DTD). XML Schéma amène cependant plusieurs différences avec les DTD. Il permet par exemple de définir des domaines de validité pour la valeur d'un champ, alors que cela n'est pas possible dans une DTD. En revanche, il ne permet pas de définir des entités. XML Schéma est lui-même un document XML, ce qui n'est pas le cas d'une DTD qui a une syntaxe spécifique. Voici un exemple de Schéma XML représentant notre document XML spécifié lors de la présentation : <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" <xs:element name="personne"> <xs:complextype> <xs:sequence> <xs:element name="nom" type="xs:string"/> <xs:element name="prénom" type="xs:string"/> <xs:element name="age" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Ce schéma décrit un élément «Personne» qui contient un élément «nom», «prénom» et «âge», de type texte. Grâce à ce simple document, on peut reproduire sans problème une nouvelle version de notre fichier XML Parsers Présentation Un parser est un programme informatique permettant d'analyser la structure syntaxique d'un texte dans le but d en ressortir le contenu. Le parser va suivre une logique définie lors de l extraction des données. il est donc nécessaire que le texte analysé la respecte scrupuleusement. Par exemple, pour XML qui peut être défini par un schéma, il est très facile de parser les documents respectant la structure. Implémentation JAVA Java et XML sont deux outils très efficaces pour l'échange de données via Internet. D un coté Java, qui offre une plateforme de développement portable, et de l autre XML, qui est formalisé et facilite l échange d informations entre les différents systèmes. La liaison des 10 Tiré de 17/105

18 deux technologies permet le développement de services Web utilisables depuis n'importe où, via n'importe quelle plateforme. La méthode la plus facile pour lier des données XML à java est d'utiliser un parser qui respecte les interfaces SAX (Simple API for XML) ou DOM (Document Object Model). Il existe aussi différentes API s plus évoluées permettant d effectuer la liaison. SAX Dans l'approche SAX, le parser commence au début du document et analyse chaque partie une à une et ce, sans garder les résultats en mémoire. Il faut donc traiter les données les unes après les autres et il n y aura pas moyen d effectuer des modifications. Dans l'approche SAX les éléments sont envoyés au parser par un push. Notre parser va donc attraper les éléments dès qu'ils arrivent afin de les transmettre directement au client sans attendre que celui-ci soit prêt à les recevoir. DOM Pour sa part, DOM va créer en mémoire un arbre représentant l intégralité des données XML tout en respectant la structure. L'arbre étant chargé en mémoire, une application peut facilement, par la suite, lire ou modifier les différentes informations. L'implémentation de DOM offre une grande flexibilité aux programmeurs. Par contre, la charge processeur et l'utilisation de la mémoire peuvent devenir problématiques lors de la manipulation de données volumineuses. StAX StAX (Streaming API for XML) est une API basée sur le streaming, la gestion d'événements et sur le pull-parsing. StAX offre la possibilité de créer des parsers XML bidirectionnels rapides, faciles à développer et légers en mémoire. Le but du pull-parsing est de donner le contrôle du parsing au programmeur, qui peut aller chercher l'élément suivant selon son désir. StAX a été créé pour répondre aux limitations des deux APIs de SAX et DOM. StAX vise trois types de développeurs : Les développeurs de librairies et d'infrastructure, qui créent des applications serveur ayant besoin d'une API très performante Les développeurs J2ME, qui ont besoin d'une API simple, très légère et de type pullparsing Les développeurs J2EE et J2SE, qui ont besoin d'une API pull-parsing capable de lire et d'écrire des documents XML de manière très efficace Afin de réaliser une API aussi complète, les auteurs ont décidé de séparer StAX en deux API légères et efficaces, au lieu d'en surcharger une seule. Les deux API's sont l'api cursor et iterator. L'API curseur travaille avec un pointeur qui permet de se déplacer du début à la fin d'un document XML. Le curseur ne peut pointer qu'un élément à la fois et ne peux jamais revenir en arrière. Cette API à l avantage d être très performante. L'API itérateur travaille avec des objets «événements». Elle parcourt le document XML du début à la fin et permet à l'application d'aller chercher l événement courant. Cette API à pour avantage de travailler avec des objets, ce qui offre une plus grande flexibilité. Voici une liste d opérations qui ne sont pas réalisables avec l'api curseur : Les événements XML étant des objets, il est possible de les passer au parser via 18/105

19 des maps, des tableaux ou des listes Il est possible de créer des sous-types d événements XML qui peuvent contenir des informations bien spécifiques Avec la manipulation des objets, il est nettement plus simple d'ajouter ou de supprimer des événements au document XML Les recommandations suivantes sont préconisées pour l'utilisation de StAX : Pour le développement dans des environnements disposant d une mémoire limitée, comme J2ME, il est possible de générer un code plus court et plus efficace avec l'api curseur Si la performance est la priorité, l'api curseur est plus efficace Si l on veut modifier le flux d'événements, l'utilisation de l'api itérateur est requise Si l on veut que notre application supporte l'ajout d'éléments externes afin de traiter les événements du flux, il faut utiliser l'api itérateur De manière générale, si l on ne sait pas quelle API choisir, il faut plutôt s orienter vers l'api itérateur qui est plus flexible et extensible TrAX TrAX (Transformation API for XML) est une API de mise en page d'un fichier XML. Elle permet par exemple de mettre en page un fichier XML grâce à un fichier XSL. Cette API utilise les fonctions XSLT pour traiter les informations XML. TrAX est donc relativement différent des divers parsers, car il ne permet pas de lire un fichier XML mais uniquement de le mettre en page. JAXB (modèle DOM) JAXB (Java API for XML Binding) est un outil java très pratique, qui permet de lier automatiquement un objet java à un fichier XML, ce qui permet de naviguer directement dans l'arbre XML et d interagir avec les diverses informations. JAXB utilise simplement des classes java pour transformer le fichier XML en objet. L'utilitaire XJC 11 permet de les créer très facilement selon un schéma XML. Le problème de JAXB vient du fait qu'il utilise aussi un modèle DOM et contient l'arbre entier en mémoire. Cela peut provoquer des baisses de performance avec de gros fichiers. Par contre, la manipulation de données avec JAXB est vraiment très confortable. kxml kxml 12 est un parser très léger destiné aux plateformes mobiles. La version actuelle (2) est basée sur une API curseur afin de réduire la taille du footprint au maximum. La prochaine version de kxml sera séparée en deux parties, afin d être directement compatible avec l API StAX, c'est-à-dire qu elle va aussi intégrer l API itérateur basée sur les événements. kxml est actuellement sous licence BSD. Streaming Vs DOM Le problème majeur du modèle DOM est le chargement en mémoire de l'arbre représentant le document XML. En effet, dans le cas où les données sont trop /105

20 volumineuses, la charge processeur et la mémoire utilisée peuvent devenir problématiques. En utilisant un parser de type pull, on peut directement traiter une donnée et la détruire après, afin d'utiliser un minimum de ressources. Par contre, cela implique de connaître préalablement le traitement exact à effectuer sur les données, car il ne sera pas possible de les manipuler à nouveau, par la suite. Le modèle pull est ainsi particulièrement efficace sur des plateformes ayant une mémoire limitée, comme les plateformes mobiles utilisant J2ME, ou encore lors de traitements volumineux. Par contre, pour sa part, un modèle DOM offre nettement plus d'aisance à l'utilisation. En effet, une fois le document XML chargé en mémoire, il est possible de naviguer, modifier ou lire les données de manière vraiment simplifiée. Dans le cas de l utilisation de JAXB, le lien entre le document XML et java est même effectué de manière automatique. Ces deux technologies n offrent pas les mêmes fonctionnalités ; les APIs de streaming sont beaucoup plus performantes et légères, ce qui les rend utilisable de manière optimale sur les plateformes mobiles, tandis que les APIs DOM simplifient nettement l utilisation et l accessibilité aux documents XML, mais en utilisant plus de ressources. Pull Parsing versus Push Parsing Le pull-parsing réfère à un modèle de programmation où le développeur «appelle» les éléments du document XML lorsqu'il en a besoin. Le push-parsing, lui, fait référence à un modèle où c'est le parser qui envoie les données au client dès qu'elles sont disponibles et ce, même s il n'est pas prêt à les recevoir. Le pull-parsing propose de sérieux avantages par rapport au push-parsing tels que : Le client contrôle la réception des différentes informations XML ; il peut ainsi décider à quel moment il veut aller chercher les données. Le client peut lire différents objets XML en un seul thread, vu que c'est lui qui va chercher les différentes informations. Cela est impossible avec un push-parser, car il va falloir attendre la fin du document pour en lire un second dans le même thread Le parsing pull-parser est généralement plus simple à mettre en oeuvre Le parser peut directement filtrer les éléments non désirables pour le client Comparaison des différentes API XML 13 Table 4-1 XML Parser API Feature Summary Feature StAX SAX DOM TrAX API Type Pull, streaming Push, streaming In memory tree XSLT Rule Ease of Use High Medium High Medium XPath Capability No No Yes Yes CPU and Memory Efficiency Good Good Varies Varies Forward Only Yes Yes No No Read XML Yes Yes Yes Yes Write XML Yes No Yes Yes Create, Read, Update, Delete No No Yes No /105

21 Conclusion Les conclusions à tirer dans le domaine du parsing Java sont les suivantes : Pour les plateformes mobiles, l'utilisation du parser kxml basé sur l API pull-parsing est recommandée, vu sa faible demande en ressources et ses performances Pour la communication entre le serveur et une plateforme mobile, StAX est un outil fort pratique. Il permet de générer directement une réponse sans passer par un arbre DOM ; le client peut donc directement l'interpréter. De plus, kxml étant aussi basé sur une API pull-parser, il est utile d utiliser les mêmes bases afin de simplifier le développement et l adaptation entre les deux environnements Pour les échanges de données en local ou sur des machines puissantes, l utilisation de JAXB est conseillé vu sa simplicité d'utilisation, sa puissance et ses possibilités comme la modification de données et le lien XML>Objet qu'il propose Pour notre projet, la communication se fera donc avec le parser StAX sur le serveur et kxml sur le client. Les différentes données XML concernant la configuration du serveur seront interprétées grâce à JAXB. 3.5 Services Web Présentation Les services Web se présentent comme un ensemble de fonctionnalités disponibles sur Internet, proposées à une communauté d utilisateurs. Ces divers services sont stockés sur des serveurs et sont accessibles par différents clients qui peuvent ainsi, depuis leur navigateur Internet, «appeler», des services Web comme Google, ebay ou autres. L utilisation des services Web offre certains avantages. Premièrement, ils utilisent des standards et des protocoles ouverts, ce qui permet l interopérabilité entre divers logiciels fonctionnant sur diverses plateformes. De plus, ils utilisent http, ce qui leur permet de fonctionner au travers de différents pare-feux. Les inconvénients viennent du fait que les différentes normes de service Web sont relativement jeunes dans certains domaines. Le langage WSDL (Web Services Descritpion Language) est une tentative de normalisation regroupant la description des éléments permettant de mettre en place l accès à un service réseau. Ce langage utilise notamment XML pour décrire un service Web. WSDL n est pas encore approuvé par le W3C mais il est soutenu par Ariba, IBM et Microsoft. Ce langage permet uniquement de décrire une interface publique afin d atteindre un service Web de manière correcte, c'est-à-dire «comment communiquer pour utiliser le service». Actuellement, trois méthodes différentes sont couramment utilisées afin de faire appel à des services Web : XML-RPC, SOAP et REST. Ces trois méthodes ne sont pas comparables ; d une part il y a XML-RPC et SOAP, d autre part REST. Les deux premières utilisent XML pour la transmission de données et la dernière utilise des principes du Web, spécialement les possibilités du protocole http. Le but de cette partie de l étude est de présenter les différentes technologies d appel de 14 Inspiré de 21/105

22 services les plus utilisées, ainsi que d examiner si les possibilités offertes sont compatibles avec notre environnement mobile et nos contraintes de sécurité. En effet, l utilisation d un PDA ayant des performances très limitées ainsi que très peu de fonctionnalités peut engendrer certains problèmes lors de l utilisation des technologies existantes développées spécialement pour les plateformes fixes. De plus, l application au domaine médical oblige à intégrer des mesures de sécurité élevées, ce qui n est pas forcément compatible avec les technologies actuelles XML-RPC XML-RPC est un protocole basé sur RPC (Remote Procedure Call) qui permet de faire des appels de procédures situées sur un système distant, à l aide d un serveur d application. XML-RPC est à la fois le nom d une technologie d échange de données XML via réseau et une dénomination englobant tous les protocoles d échanges XML. XML-RPC est défini pour être aussi simple que possible tout en permettant d envoyer des structures de données complexes. La simplicité de compréhension facilite nettement l implémentation et le débugage ; de plus, la syntaxe permet de trouver rapidement les erreurs. XML-RPC se propose d encapsuler les données dans un document XML. Puis, une fois les données reçues, il permet de séparer les données du document. Voici un exemple d appel de procédure avec XML-RPC sur le service en ligne Flickr.fr. La requête sur le site est vraiment très basique, ce qui permet de voir facilement la structure du document : <?xml version='1.0' encoding='utf-8'?> <methodcall> <methodname>flickr.echo</methodname> <params> <param> <value> <struct> <member> <name>name</name> <value><string>value</string></value> </member> </struct> </value> 22/105

23 Et la réponse : </param> </params> </methodcall> <?xml version="1.0" encoding="utf-8"?> <methodresponse> <params> <param> <value> <string> <method>flickr.test.echo</method> <format>xmlrpc</format> <foo>bar</foo> <api_key>78ce850f064baa9e7fc </api_key> </string> </value> </param> </params> </methodresponse> Cet appel à distance est relativement simple et compréhensible. Par contre, la taille du document est particulièrement grande par rapport au contenu réel ; cela provient de la structure XML qui génère des entêtes volumineux SOAP SOAP, développé par Microsoft et IBM, est devenu une recommandation du W3C depuis sa version 1.2 en Actuellement, les différents services Web se doivent d être accessibles via ce protocole. SOAP peut être décrit comme une évolution de XML-RPC ; il est basé sur le même principe, c'est-à-dire l utilisation de XML pour l envoi et la réception de données. Il fonctionne donc de la même manière, mais offre beaucoup plus de possibilités, comme le fait de pouvoir customiser chaque partie d un message SOAP de façon à répondre totalement aux besoins du programmeur. Le message SOAP peut ainsi devenir très complexe et très complet, ce qui engendre par contre une demande nettement plus gourmande en ressources lors du parsing du document. Voici la requête au même service basique que celui décrit pour XML-RPC. <?xml version='1.0' encoding='utf-8'?> <s:envelope xmlns:s=" xmlns:xsi=" xmlns:xsd=" <s:body> <x:flickrrequest xmlns:x="urn:flickr"> <method>flickr.echo</method> <name>value</name> </x:flickrrequest> </s:body> </s:envelope> 23/105

24 Et voici la réponse : <?xml version="1.0" encoding="utf-8"?> <s:envelope xmlns:s=" xmlns:xsi=" xmlns:xsd=" <s:body> <x:flickrresponse xmlns:x="urn:flickr"> <method>flickr.test.echo</method> <format>soap</format> <foo>bar</foo> <api_key>78ce850f064baa9e7fc </api_key> </x:flickrresponse> </s:body> </s:envelope> Les entêtes XML représentent toujours une grosse partie du document REST REST n est pas un protocole en soi, ni une technologie, mais une philosophie de l utilisation du Web. REST utilise simplement le protocole http avec les différentes méthodes proposées comme GET, POST ou autre. La philosophie de REST réside dans le fait qu il n est pas nécessaire de faire des appels complexes comme avec XML-RPC ou SOAP, mais de combiner les méthodes http avec des URIs afin d appeler directement les services. Voici l exemple d un appel REST : Et voici la réponse : &name=value <?xml version="1.0" encoding="utf-8"?> <rsp stat="ok"> <method>flickr.test.echo</method> <format>rest</format> <foo>bar</foo> <api_key>cc5eb7cce4f7e5bb39c259a63e6e9215</api_key> </rsp> L appel et la réponse sont nettement plus courts et simples avec REST. Il offre la possibilité d accéder directement à un service en utilisant http sans passer par une couche XML lors de l appel Comparaison Il est clair que la méthode la plus simple est REST, qui a l avantage de ne pas ajouter une couche d abstraction à des données qui n en ont pas forcément besoin. Il est donc possible d appeler directement un service en utilisant les fonctionnalités offertes par http, ce qui n est pas possible avec SOAP et XML-RPC qui obligent à mettre la requête en forme. SOAP et XML-RPC sont basés sur la même idéologie. Mais, la tendance actuelle des différents programmeurs s oriente vers SOAP qui permet de palier à certains problèmes de XML-RPC comme le manque de précision et la limitation des fonctionnalités. De plus, SOAP 24/105

25 est supporté par le W3C, mais est souvent considéré comme trop compliqué. La meilleure solution lors de l implémentation d un service Web est de développer un support pour les trois technologies différentes, vu qu elles sont toutes trois utilisées Analyse Le premier désavantage d ordre général de ces solutions, est le temps utilisé pour effectuer le parsing et le transport du document XML. Bien que XML soit relativement simple, le temps nécessaire pour traiter ce type de document utilise beaucoup de ressources système. De plus, le document devant transiter via le Web, les entêtes XML prennent beaucoup de place par rapport au contenu ce qui engendre une baisse des performances et occupe une bonne partie de la bande passante. Un autre désavantage important, touchant la sécurité, est le fait que ces protocoles utilisent http, ce qui leur permet de passer de manière transparente à travers les firewall. Une solution serait d implémenter un parser directement sur le firewall, afin d interpréter le message XML. Mais cela est très difficile, spécialement dans le cas de SOAP qui peut être très différent d un message à l autre. En effet, il n a pas de modèle d adressage uniforme et peut avoir diverses structures. Par exemple, il pourrait y avoir ou non un entête, le corps pourrait être encodé en RPC et parfois il pourrait y avoir un nom de méthode. Bref, il est impossible de définir si un paquet est valide ou non à ce niveau. C est donc à l application de garantir sa propre sécurité. XML-RPC est simple à comprendre et à utiliser ; par contre, il présente quelques lacunes au niveau de sa structure. En effet, étant très basique, il ne permet pas de définir de nouvelles structures ni de spécifier un type d encodage, ce qui limite l utilisation des caractères spéciaux. SOAP, pour sa part, permet d effectuer des requêtes très complexes et répondant aux besoins du programmeur. Cela implique par contre une certaine complexité lors de l appel à un service distant. La méthode d appel nécessite plusieurs étapes complexes ; premièrement, le programmeur doit construire un message, y incorporer les différents arguments, puis l envoyer. Après ça, il doit attendre une réponse, parser le document XML et interpréter les résultats. Plus le schéma est complexe, plus le temps utilisé pour le parsing du document sera long, de même que pour l implémentation du code. Un autre problème lié à SOAP vient du fait qu il existe beaucoup d implémentations différentes, ce qui engendre des soucis de compatibilité. Cela provient d un manque de maturité du standard, qui contient des ambiguïtés. Voici un petit tableau résumant les différences majeures entre XML-RPC et SOAP : Feature XML-RPC SOAP basic scalars yes Yes structs yes Yes arrays yes Yes named structs and arrays no Yes detailed fault handling yes Yes short learning curve yes No Developers specified character set no yes (US-ASCII, UTF-8, UTF-16) Developer defined data types no Yes Can specify recipient no Yes require client understanding no Yes message specific processing instructions no Yes REST, pour sa part, permet d appeler de manière très simple les différents services Web mais n offre pas la possibilité de le faire de manière complexe. 25/105

26 3.5.7 Compatibilité avec nos besoins Dans notre cas, la technologie REST est à écarter, car nous n utiliserons pas un navigateur Web mais un client lourd ayant une interaction forte avec le serveur. Le format de requête http est beaucoup trop basique ; le client lourd a tout intérêt à utiliser un format XML défini, afin de pouvoir effectuer des requêtes complexes dans le but de répondre à nos besoins de sécurité et à ceux des différentes applications. Il reste donc XML-RPC et SOAP. Ces deux technologies reposent sur la même base et permettent de faire des appels de services via des requêtes XML. D un coté nous avons XML-RPC qui est relativement simple mais limité, de l autre SOAP qui offre beaucoup de possibilités mais est nettement plus complexe. Dans notre cas, nous avons des critères bien spécifiques : Sécurité optimale : il faut impérativement sécuriser l accès en le limitant aux utilisateurs authentifiés Rapidité d exécution dans un environnement mobile : il faut impérativement utiliser un parser de type pull comme kxml sur la plateforme mobile Echange de données complexes : dans le but de répondre de manière optimale aux besoins du programmeur Dans notre cas, la sécurité va être garantie par la plateforme. Le problème est de pouvoir interpréter les données relatives à la sécurité depuis le serveur, puis, une fois seulement l authentification effectuée, les applications seront appelées. Cela nécessite donc d effectuer un contrôle avant l accès aux applications proposant les services. XML-RPC ne répond pas réellement à notre problématique. En effet, sa simplicité limite son utilisation à des cas plus simples d échange de données entre applications. Il nous faut un protocole plus souple, permettant de spécifier des données relatives à la sécurité pouvant être interprétées directement par notre plateforme et non par l application. SOAP est vraiment très complet et répond à nos besoins en matière de flexibilité et de sécurité. Par contre, le point négatif vient de sa complexité et surtout du temps nécessaire à parser un document XML. Le fait de travailler sur une plateforme mobile n arrange pas du tout les choses : les performances étant vraiment limitées, le parsing d un document trop complexe va devenir beaucoup trop important. De plus, la compatibilité entre les implémentations SOAP sur J2ME et les serveurs n est pas garantie. Aucun des trois protocoles présentés ne répond donc vraiment à nos besoins. Il devient par conséquent pertinent de créer un protocole dédié, qui serait adapté de manière optimale à notre plateforme. L avantage qui en découlerait, serait d avoir un contrôle complet lors de l élaboration des communications. Cela permettrait de définir nous mêmes les éléments à intégrer au protocole ainsi que la méthode de parsing, afin d améliorer les performances au maximum. Ce protocole devrait pouvoir rester léger tout en offrant une certaine flexibilité au niveau des données. Dans ce cas, l authentification s effectuant depuis la plateforme serveur, des données spécifiques relatives à la sécurité pourront être intégrées puis interprétées par notre propre mécanisme, ce qui représente un grand avantage. Il serait aussi envisageable d optimiser la sécurité au niveau du protocole en n utilisant pas http, ceci afin de pouvoir bloquer l accès depuis un firewall. Cela limiterait par contre son utilisation. 26/105

27 4 Utilisation des technologies 4.1 XML : Utilisation des parsers Introduction Après avoir déterminé quelles API's seront utilisées dans le projet, il est utile d en présenter le fonctionnement de base. Le document XML suivant va être utilisé pour expliquer les différents fonctionnements et la mise en place des parsers. <Personne> <Nom>Probst</Nom> <Prenom>Julien</Prenom> <Age>24</Age> </Personne> JAXB Pour débuter, il faut créer le schéma XML correspondant au document XML précédent, afin d'exécuter XJC qui va générer les classes Java nécessaires à JAXB : <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" <xs:element name="personne"> <xs:complextype> <xs:sequence> <xs:element name="nom" type="xs:string"/> <xs:element name="prenom" type="xs:string"/> <xs:element name="age" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Une fois le schéma créé, il suffit d'exécuter XJC 15 : %JDK_HOME%/bin/xjc schema.xsd Une fois exécuté, les 2 classes suivantes sont générées : ObjectFactory.Java qui est la fabrique d'objet nécessaire à la création d'une nouvelle personne Personne.java qui est la représentation Java du document XML. Cette Classe permet d'effectuer l'initialisation ou la lecture du nom, du prénom et de l age 15 Voir 27/105

28 Une fois la phase d'initialisation terminée, il est possible de passer à la lecture ou à la création d'une nouvelle personne. Lecture Pour débuter, il faut ouvrir le fichier XML désiré, créer le contexte dans lequel le fichier va être chargé et définir où se trouvent les classes générées par XJC. InputStream is = new FileInputStream( c:\personne.xlm ); JAXBContext jc = JAXBContext.newInstance(SCHEMA_PACKAGE_LOCATION); Maintenant que le contexte est chargé, il est possible d'effectuer le unmarshalling, c'est-àdire la transformation du fichier XML en langage Java. Pour débuter, on crée le unmarshaller. Puis, on effectue la transformation. Unmarshaller u = jc.createunmarshaller(); Personne personne = (Personne)(u.unmarshal( is )); Le tour est joué, notre fichier XML se retrouve à l'intérieur de notre objet Personne. Il est ainsi possible de lire les différentes informations grâce aux commandes suivantes : personne.getage(); personne.getprenom(); personne.getnom(); Écriture Pour débuter, il faut créer la fabrique d'objets qui va nous permettre de créer des personnes. Puis, simplement créer une nouvelle personne grâce à la fabrique. ObjectFactory objfactory = new ObjectFactory(); Personne personne = objfactory.createpersonne(); Une fois l'objet personne créé, les diverses informations peuvent être modifiées à l'aide des commandes suivantes : personne.setage(); personne.setprenom(); personne.setnom(); Lorsque notre objet est initialisé, il faut définir la destination du résultat et spécifier le contexte dans lequel a été créé l objet. OutputStream out = new FileOutputStream(location+XML); JAXBContext jc = JAXBContext.newInstance(SCHEMA_PACKAGE_LOCATION); Finalement, on crée le marshaller qui va servir à transformer l'objet java en données XML et on effectue la transformation. Marshaller m = jc.createmarshaller(); m.marshal( diary, out ); 28/105

29 Analyse de l'api JAXB Les exemples de création et de lecture présentés montrent que la mise en oeuvre d'un système basique JAXB est vraiment simple. Il suffit de générer un schéma XML puis de créer les classes java au moyen de XJC. Une fois l'arbre DOM représenté par un objet Java créé, on accède très simplement à toutes les informations XML grâce aux méthodes get et set. Il est ainsi possible de lire et de modifier toutes les informations à n'importe quel moment. Bref, JAXB est vraiment un outil très puissant et pratique pour le traitement de données XML StAX StAX, se divise en deux types d'api bien spécifiques et complémentaires, soit une basée sur un curseur et l autre basée sur des itérateurs. Le fait de séparer l api StAX en deux parties permet d optimiser chacune d elles et d éviter une surcharge qui se manifesterait avec une seule API contenant les deux fonctionnalités. API curseur Cette API représente un curseur qui va se déplacer du début à la fin de notre fichier XML. Le curseur va avancer d'un élément à un autre sans jamais pouvoir revenir en arrière. Il est donc important de savoir que faire avec un élément lorsque celui ci est pointé. Les deux interfaces proposées, basées sur les curseurs, sont XMLStreamReader et XMLStreamWriter. Elles permettent de lire et d'écrire tous les éléments nécessaires à la lecture/création d'un document XML tels que : encodage du document, nom d'éléments, attributs, tags d'ouverture, tags de fermeture, commentaires, texte, etc.. L'avantage de l utilisation des curseurs est la possibilité de définir la séquence d'éléments qui doivent être reçus grâce à la commande require(string TAG, String Value). Il est ainsi possible de suivre une structure bien spécifique, définie par exemple par un schéma XML. Lecture Pour commencer, il faut créer notre «XMLStreamReader» grâce à la fabrique «XMLInputFactory». L'InputStream is représente le document XML et ISO représente l'encodage textuel du flux. XMLInputFactory factory = XMLInputFactory.newInstance(); XMLStreamReader reader = factory.createxmlstreamreader(is,"iso "); Dès lors, il est possible de lire notre document XML. Pour débuter, on précise que le curseur doit pointer un élément de début de document. reader.require(reader.start_document, null,null);//tag début de document reader.nexttag();//on pointe le prochain Tag L'élément suivant doit être une balise d'ouverture <personne>. //<personne> reader.require(reader.start_element, null, "personne");//tag d'ouverture reader.nextag();//on pointe le prochain Tag 29/105

30 Elle contient un élément contenant le nom de la personne. <nom>probst</nom>. On va donc commencer par définir le tag attendu <nom> puis, se déplacer sur l'élément suivant qui représente le nom. On va donc appeler la méthode gettext() qui permet de lire un élément textuel dans un document XML. Une fois le nom lu, on pointe l'élément suivant qui doit être la balise de fin de nom </nom>. //<nom>probst</nom> reader.require(reader.start_element, null, "nom");//tag d'ouverture reader.next();//on pointe le prochain élément String nom = reader.gettext();//on prend le nom reader.next();//on pointe le prochain élément reader.require(reader.end_element, null, "nom");//tag de fermeture reader.nexttag();//on pointe le prochain Tag Maintenant que le nom est initialisé, il est possible d'effectuer différents traitements nécessaires et ce, sans avancer dans le document XML. Une fois le traitement effectué, on lit les éléments suivants de la même manière. //<prenom>julien</prenom> reader.require(reader.start_element, null, "prenom"); reader.next(); String prenom = reader.gettext(); reader.next(); reader.require(reader.end_element, null, "prenom"); reader.nexttag(); //Traitement sur le prénom //<age>24</age> reader.require(reader.start_element, null, "age"); reader.next(); String age = reader.gettext(); reader.next(); reader.require(reader.end_element, null, "age"); reader.next(); L'élément suivant doit être le Tag de fin </personne>. Et finalement, la fin du document. //</personne> reader.require(reader.end_element, null, "personne"); reader.next(); reader.require(reader.end_document, null,null); Voila notre fichier complètement lu grâce à l'api StAX basée sur les curseurs. On remarque bien le fait qu'il est possible d'aller chercher les informations quand elles sont désirées. Il est ainsi possible par exemple, d'effectuer différents traitements sur un nom avant d'aller chercher le prénom. L'implémentation du parsing est relativement simple à comprendre et à mettre en place. Écriture L'écriture se déroule de la même manière ; on va simplement écrire des tags et des éléments de manière séquentielle en respectant le schéma. Pour débuter, on passe par la fabrique «XMLOutputFactory» afin de créer le «XMLStreamWriter». L'OutputStream 30/105

31 représente le document XML de sortie. XMLOutputFactory xof = XMLOutputFactory.newInstance(); XMLStreamWriter xsw = xof.createxmlstreamwriter(out,"iso "); Une fois créé, on écrit le début du document, suivi de la balise de début <personne>. //début de document xsw.writestartdocument("iso ","1.0"); //<personne> xsw.writestartelement("personne"); Puis, on écrit simplement les éléments nécessaires séquentiellement jusqu'à la fin du document. //<nom>julien</nom> xsw.writestartelement("nom"); xsw.writecharacters("probst"); xsw.writeendelement("nom"); //<prenom>julien</prenom> xsw.writestartelement("prenom"); xsw.writecharacters("julien"); xsw.writeendelement("prenom"); //<age>julien</age> xsw.writestartelement("age"); xsw.writecharacters("24"); xsw.writeendelement("age"); //<personne> xsw.writeendelement("personne"); //fin de document xsw.writeenddocument(); La création d'un document XML respectant un schéma précis est donc relativement simple à mettre en oeuvre. API Itérateurs L'API itérateurs représente un document XML en tant qu'une pile d'événements. Les événements sont tirés par l'application directement depuis le parser. L'interface de base pour lire des événements est XMLEventReader ; sa méthode la plus importante est nextevent() qui retourne le prochain événement XML du document. L'interface pour écrire des événements est XMLEventWriter. Lecture La lecture avec les itérateurs est relativement simple à mettre en oeuvre. Il suffit de lire le document XML jusqu'à la fin et de saisir les différents éléments. //Création de la fabrique 31/105

32 XMLInputFactory factory = new XMLInputFactory; //Création du reader XMLEventReader reader = factory.createxmleventreader(is); //On lit le document jusqu'à la fin while(reader.hasnext()){ //On analyse l'événement ManageEvent(reader.nextEvent()); } Chaque événement va devoir être analysé afin de définir l'action à entreprendre. L objectif est de connaître la balise courante afin de savoir à quoi un événement textuel correspond. //Méthode d'analyse d'un événement private void ManageEvent(XMLEvent event){ //Si l'événement est une balise de début if (event.isstartelement()){ StartElement startelement = event.asstartelement(); //On prend le nom de l'élément currentelement = startelement.getname().getlocalpart(); //Si l'événement est une balise de fin }else if(event.isendelement()){ EndElement endelement = event.asendelement(); //Si l'événement est textuelle }else if(event.ischaracters()){ Characters characters = event.ascharacters(); }} //Selon la balise actuelle, //Si on est en train de lire un nom, if(currentelement.compareto("nom")==0){ nom=charcters.getdata(); //Si on lit un prénom }else if(currentelement.compareto("prenom")==0){ prenom=charcters.getdata(); //Si on lit un age }else if(currentelement.compareto("age")==0){ age=charcters.getdata(); } La mise en place d'un système basé sur les itérateurs est également très simple à mettre en oeuvre. Elle permet d'analyser un document XML en se basant sur l'événement courant. C'est ensuite au développeur de décider de l action à entreprendre en présence de tel ou tel événement et de mémoriser les différents états. L'avantage de cette API est le fait de pouvoir ajouter très facilement des traitements sur différents événements ou de pouvoir les transmettre à une application externe, afin qu elle puisse elle-même les analyser. Écriture L'écriture revient à générer les événements dans l'ordre. On va donc avoir cinq types 32/105

33 d'événements différents pour notre document XML, les START_DOCUMENT, END_DOCUMENT, START_ELEMENT, END_ELEMENT et CHARACTERS. Ces événements doivent être créés depuis une fabrique d'événements XML. //Création de la fabrique d'événements XMLEventFactory eventfactory = new XMLEventFactory(); //création de la fabrique de writer XMLOutputFactory factory = new XMLOutputFactory(); //création du writer depuis la fabrique XMLEventWriter writer = factory.createxmleventwriter(out); Une fois la phase d'initialisation terminée, on écrit directement dans le document XML. writer.add(eventfactory.createstartdocument()); //<personne> writer.add(eventfactory.createstartelement(null,null,"personne")); //<nom>probst</nom> writer.add(eventfactory.createstartelement(null,null,"nom")); writer.add(eventfactory.createcharacters("probst")); writer.add(eventfactory.createendelement(null,null,"nom",)); //<prenom>probst</prenom> writer.add(eventfactory.createstartelement(null,null,"prenom")); writer.add(eventfactory.createcharacters("julien")); writer.add(eventfactory.createendelement(null,null,"prenom")); //<age>24</age> writer.add(eventfactory.createstartelement(null,null,"age")); writer.add(eventfactory.createcharacters("24")); writer.add(eventfactory.createendelement(null,null,"age")); //</personne> writer.add(eventfactory.createendelement(null,null,"personne")); writer.add(eventfactory.createenddocument()); La création d'un document XML en utilisant les événements est là aussi, simple à mettre en oeuvre. L'avantage est de pouvoir ajouter des objets «événement» au document, ce qui permet à une application de définir son propre contenu. Analyse des API's StAX Les deux API's sont relativement plus compliquées à mettre en œuvre que JAXB mais cela reste très rapide. Les deux API s proposées se complètent parfaitement en offrant des possibilités différentes. L'API curseur permet de suivre une structure de manière relativement simple et très performante. Par contre, l'api itérateur est légèrement plus complexe à mettre en place mais permet l utilisation d'objets, ce qui la rend plus souple. Avec l'api itérateur, il est facile de donner ou de lire des événements quelconques directement depuis une application, ce qui permet de lire différents documents XML sans modifier le code de base du parser. 33/105

34 4.1.4 Conclusion En finalité, les deux API's StAX et JAXB sont adéquates pour gérer les différents types de flux XML utilisés dans notre projet. Ces deux parsers sont très performants dans leur domaine respectif et sont simples à utiliser. JAXB va servir à analyser les différents fichiers de configuration internes au serveur afin de les lire et de les modifier. En effet, le serveur étant une machine «puissante», les ressources nécessaires au chargement des documents seront négligeables et n'affecteront pas le fonctionnement global. De plus, l'utilisation d'un arbre DOM est très pratique pour lire les informations de configuration. L'API curseur de StAX va servir à créer le parser de transfert entre le serveur et le client. Vu qu un protocole de transfert sera établi, la souplesse offerte par l'api itérateur n'est pas réellement un avantage, vu qu une application ne doit pas pouvoir interférer dans la structure du document. De plus, kxml utilise aussi une API curseur. Il est donc judicieux d utiliser la même base de développement pour les deux parsers afin d optimiser la compatibilité et l adaptation entre les deux environnements. 4.2 XML : Envoi de données binaires Lors de l'utilisation de XML, il peut être nécessaire d'envoyer des données binaires. Le problème vient du fait que XML ne peut gérer que des valeurs textuelles. Il est donc nécessaire d'encoder les valeurs binaires en caractères XML valides Base 64 Base 64 est un codage de l'information utilisant 64 caractères. Il a été choisi pour être disponible sur la majorité des systèmes et il est principalement utilisé pour la transmission de messages. Base 64 permet d'encoder 6 bits successifs ; il groupe donc 3 bytes entre eux et les découpe en 4, ce qui permet de coder directement le résultat. Voici un exemple d'une table de correspondance entre la valeur binaire et sa valeur codée. Le dernier caractère '=' est utilisé pour le processus de codage des caractères finaux. Valeur Codage Valeur Codage Valeur Codage Valeur Codage 0 A 17 R 34 i 51 z 1 B 18 S 35 j C 19 T 36 k D 20 U 37 l E 21 V 38 m F 22 W 39 n G 23 X 40 o H 24 Y 41 p I 25 Z 42 q J 26 a 43 r K 27 b 44 s L 28 c 45 t M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (complément) = 15 P 32 g 49 x 34/105

35 16 Q 33 h 50 y En utilisant Base64, il est possible d envoyer des données binaires quelconques. La vitesse d encodage et de décodage est rapide car la table permet de retrouver de manière directe la valeur correspondant à une clé. Par contre, la taille d un fichier encodé avec base64 peut prendre jusqu'à 33% de place supplémentaire au fichier original, ce qui n est pas forcément optimal pour l envoi de données volumineuses. Il serait possible d encoder les données avec Huffman ou autre, mais le temps utilisé pour décoder les données sur une plateforme mobile serait trop important. Malheureusement, java n intègre pas base64 dans son API de base. Il faut donc se référer à différentes sources comme une version de Base64 créée par Robert Harder, pouvant être téléchargée à l adresse Cette API est très complète et offre toutes les fonctionnalités de base64. De plus, elle est développée pour un domaine public, c'est-à-dire qu elle ne contient pas de droits d auteurs et qu il est possible de l utiliser à notre guise. 35/105

36 5 Serveur d'applications : Conception 5.1 Introduction Le but du serveur est de proposer différentes applications offrant des services utilisables via internet. Il sera donc possible d'accéder depuis partout aux différentes applications et services proposés. Bien entendu, l'accès sera réservé aux clients autorisés. Il y aura deux types d'applications, soit serveur et client. Une fois une application client installée, elle aura la possibilité d accéder aux différents services proposés par l application serveur correspondante. En effet, son but est de s'occuper des différents traitements «logiques» comme l accès et la manipulation d informations stockées dans une base de données. Une fois les données interprétées, elles seront retournées à l application client qui va s occuper de les afficher sur la plateforme mobile. Une séparation totale entre les applications et le serveur est un des objectifs principaux. Cela va permettre de garantir une indépendance complète entre les différents éléments, dans le but d offrir une meilleure stabilité et de simplifier au maximum le développement de nouvelles applications. Un protocole basé sur XML permettant le transfert entre le client et le serveur va être défini dans le but de garantir la sécurité du système et la formalisation de l échange de données entre les applications. En effet, le fait de définir notre propre protocole va nous permettre de spécifier des informations relatives à la sécurité pouvant être analysées directement par le serveur sans passer par la couche applicative, de même qu une structure à respecter lors de l échange. 5.2 Problématique lié au PDA Le fait d utiliser un PDA nous confronte à certaines problématiques dans les différentes facettes du projet. Le but de ce sous-chapitre est d énumérer les problèmes, afin d en avoir conscience et d y répondre de manière optimale par la suite. Sécurité o Vol o Confidentialité des données Connexion o Mauvais débit o Coupures fréquentes Performances o Vitesse d exécution o Traitement des informations Affichage o Petite taille d écran o AP graphique de base (AWT) ancestrale 36/105

37 Divers o Compatibilité pas assurée vu l émergence de la technologie Dans le contexte qui me concerne, les problématiques majeures sont liées à la qualité de la connexion, aux performances et à la compatibilité. La partie sécurité est approfondie séparément par M.Badan et l interface et les services du PDA par M.Wulliamoz. 5.3 Objectifs Voici une liste des différents objectifs que le serveur se doit d atteindre. Le but est de fixer un maximum de contraintes, afin de réaliser un «produit» de qualité supérieure. Modulable Portable Sécurisé Utilisable de manière optimale avec des plateformes mobiles Utilisable quel que soit l OS de la plateforme client Capable de proposer une API de développement d applications de qualité Facile à : o Utiliser o Comprendre o Modifier Maintenant que les différents objectifs sont fixés, il faut rassembler les idées qui permettront de les résoudre. Modulable Le principe de la modularité est de permettre l ajout de nouvelles fonctionnalités, ou la modification de celles qui sont déjà existantes, et ceci de la manière la plus simple possible. Dans le domaine de la programmation, la modularité revient à séparer les différentes entités présentes dans le système. Ce point est très important, car un projet ne respectant pas ce principe ne peut que très difficilement être réutilisé. La modularité a un impact direct sur l'utilisation, la compréhension et la simplicité d'ajout ou de modification de fonctionnalités. La séparation en couches est un moyen de répondre à la problématique posée et sera expliquée plus en détail dans la suite du rapport. Portable Le but de la portabilité est de pouvoir faire fonctionner le système sur des plateformes différentes. Java est un outil des plus efficaces car, grâce à sa machine virtuelle, il peut être utilisé sur la plupart des plateformes existantes. Sécurisé La sécurité est un point très important du système, vu le cadre «médical» du projet. C'est d'ailleurs la raison pour laquelle M. Badan a effectué un travail très complet sur cet aspect de l étude. Le but final pour le serveur d'applications est de limiter l accès des différentes ressources aux utilisateurs authentifiés en utilisant le module de sécurité 37/105

38 développé par M.Badan. Utilisable de manière optimale avec des plateformes mobiles Le serveur doit utiliser des technologies viables pour des éléments mobiles. En effet, les performances de ces plateformes, que ce soit au niveau de la mémoire ou de la fréquence de travail, sont vraiment dérisoires lorsqu il s'agit de traiter des informations «lourdes». Dans notre cas, vu que nous utilisons Java, une machine virtuelle J9 va devoir tourner sur le client, ce qui va avoir un impact direct sur les performances qui sont déjà faibles. Pour répondre au mieux à cette difficulté, il ne faut jamais surcharger la machine client, en évitant au maximum de la faire travailler et lui envoyer uniquement les informations à afficher. L utilisation d une API XML de streaming permet de gagner en performances, spécialement sur le client en utilisant un parser de type pull. Utilisable quel que soit l OS de la plateforme client La communication entre le serveur et le client ne doit pas être limitée aux applications Java. Il doit être possible d'effectuer un échange de manière totalement transparente entre un environnement (ex) C++ et notre serveur. Cela offre de grandes possibilités d'utilisation et de développement futur. XML répond parfaitement à cette problématique. En effet, XML étant formalisé, il est possible de l'utiliser pour échanger des informations entre différentes plateformes. API de développement (de services) de qualité Ce point est également très important, car le but du projet est de proposer une plateforme de développement de nouvelles applications. Il est donc nécessaire de proposer une API simple, compréhensible et très efficace. 5.4 Fonctionnement de base Notre serveur représente un conteneur d'applications proposant des services Web. Le but est de permettre à un client d'atteindre ces différents services le plus facilement possible en respectant les objectifs préalablement établis. Le serveur fonctionne en mode passif et attend les différentes connexions des utilisateurs. Lors de la réception d'une requête, le serveur doit être en mesure de savoir quelle application et quel service exécuter. La requête doit donc contenir ces deux informations. De plus, étant donné qu une requête doit pouvoir être authentifiée, la présence d'un champ contenant une information permettant l'authentification est donc impérative. Ces 3 informations indispensables peuvent être interprétées comme l'entête d'une requête qui sera interprétée par la plateforme. Une fois l'entête connu, le serveur va pouvoir exécuter le service et l'application désirés. Le service pouvant requérir certains paramètres d'initialisation, il faut les inclure directement dans la requête. C'est à ce moment-là que la partie logique entre en jeu, le but du service étant d'analyser les éléments de requête et de générer la réponse. A partir de l'analyse de base, il est possible de tirer les éléments suivants qui devront impérativement être présents dans une requête : Entête o ID 38/105

39 o o Corps o Application Service Arguments d'initialisation du service Au niveau de la réponse, la même structure va être utilisée, ce qui permettra de générer des éléments pouvant être interprétés par le client lourd au niveau de l'entête. Le corps contiendra aussi les données de retour devant être analysées par l application client. Maintenant, le but est de formaliser un échange. Sachant que XML est idéal pour répondre à la problématique, il faut définir le protocole d échange entre les applications. 5.5 Protocole de transfert Présentation Les protocoles existants SOAP, XML-RPC et REST n étant pas idéals pour notre problématique, la création de notre propre protocole de transfert s avère obligatoire. Le développement d un nouveau protocole offre plusieurs avantages : premièrement, cela permet d avoir un contrôle total au niveau des données, que ce soit pour le traitement ou pour la structure. Il est ainsi possible de définir exactement ce qui doit être contenu dans notre document et de quelle manière traiter ce contenu. De plus, il est possible d utiliser notre propre parser lors de l interprétation des documents, ce qui permet d optimiser le temps nécessaire au parsing, spécialement sur la plateforme mobile qui souffre d un manque de performances Buts Définir une structure propre à notre problématique Etre facile à utiliser Etre léger afin de minimiser les ressources utilisées lors du parsing Permettre l authentification des requêtes Permettre le chargement d une application et d un service précis Permettre l échange de données complexes entre les applications client et serveur Authentification d une requête Au niveau de l authentification, il a été défini avec M. Badan que seul un Id suffisait pour authentifier un utilisateur. En effet, l envoi de la requête est contrôlé au niveau du client lourd qui va insérer un id unique relatif à l utilisateur qui sera authentifié de manière forte. Ainsi, si la requête est validée par le client lourd, cela signifie qu elle a accès au serveur. De ce fait, il reste à contrôler l id coté serveur et définir si il est valide ou non. S il est valide, la requête a accès aux applications, sinon cela signifie que l id a été altéré ou est non valide (pirate) et la requête est abandonnée. De plus, une connexion sécurisée SSL sera établie afin de garantir l encryption des données. 39/105

40 5.5.4 Chargement de service Le chargement d un service se fait de manière basique en spécifiant son nom et le service désiré. C est donc notre plateforme qui va devoir analyser la requête et utiliser ces différentes informations afin d effectuer le chargement. Une fois le nom d une application et celui du service connu, il est facile, en utilisant Java, de charger une classe ou un Jar puis d exécuter une de ses méthodes. La fonction de chargement sera expliquée plus tard Echange de données Pour débuter, définissons les types d éléments pouvant être transportés par notre protocole. Le but est d offrir un maximum de flexibilité lors de l échange de données entre les applications. Les données simples : Textes : String, Integer, Doubles, etc. Listes Tableaux Les données complexes : Données binaires sous format Base64 Données XML complexes Les données simples de type texte, c'est-à-dire tout ce qui peut être représenté dans un format String comme les entiers, les flottants ou les textes, vont être englobées en un seul et même type. Cela évite de surcharger la méthode de parsing et permet de gagner en performances. Par contre, le programmeur doit absolument connaître préalablement le type de données. Une difficulté liée à XML est qu il ne permet pas l envoi de caractères spéciaux comme les &. ;, < ou encore >. L utilisation d une section CDATA permet de protéger les données, ce qui évite qu elles soient interprétées par le parser XML. Grâce à cela, il est possible d envoyer n importe quelles données XML. Pour les données complexes, il doit être possible d envoyer et de recevoir des tableaux de bytes. Cela afin d envoyer des fichiers ou n importe quel type de données. Il faut donc pouvoir encoder et décoder un flux binaire en valeurs compatibles avec notre document XML. Base64 est parfaitement adapté à cette problématique. Un autre type de données complexes peut être XML ; en effet, il est très intéressant d offrir la possibilité d inclure à notre document des données respectant une structure dépendant d une application spécifique, le but étant d envoyer les données XML tout en bénéficiant des possibilités du parser. Cela sans utiliser une section CDATA, afin d envoyer simplement le document XML sous format texte Structure Il est maintenant possible de définir une structure de base répondant aux besoins de la problématique. Cette structure est inspirée de celle réalisée par M.Greppin pour son client riche sur plateforme fixe. Après modification, elle est capable de contenir toutes les informations nécessaires concernant l entête et le corps. 40/105

41 Document <transfert> Entête Corps <id>id requête</id> <application>application</application> <service>service</service> <argument> <arg>argument textuelle</arg> <arg> <![CDATA[<cplx>;</cplx>]]> </arg> <arg>q+cjwvehm6c2ozw1hpgo=</arg> <arg> <doc type="book"> <title>xml</title> <date>2007</date> </doc> </arg> </arguments> </transfert> Authentification Chargement d application Arguments de réponse ou de requête pour une application La séparation de l entête et du corps permet de séparer le traitement des données. En effet, la plateforme va uniquement s intéresser à l entête, afin d authentifier la requête et de charger l application avec le service désiré. L application, pour sa part, va s occuper de traiter le corps de la requête qui contient toutes les données applicatives. Ce protocole permet donc d effectuer une analyse des données à deux niveaux différents. En ce qui concerne les arguments destinés aux applications, il va être possible de les envoyer sous les formes suivantes : Textes <arguments> <arg>argument textuelle</arg> <arg> </arg> <arg> </arg> <arg><![cdata[<cplx> ; </cplx>]]></arg> </arguments> Listes, tableau <arguments> <arg>tableau[0]</arg> <arg>tableau[1]</arg> <arg>tableau[2]</arg> </arguments> Données binaires représentées avec Base64 41/105

42 <arguments> <arg>pd94bwwgdmz4kphhzonnjagvtysb4bwxuczp4==</arg> <arg>gojcqkjphhzomvszw1lbnqgbmftzt0ic2vydmljzsigdhlwz==</arg> </arguments> Données XML <arguments> <arg> <doc type="book"> <title>xml</title> <date>2007</date> </doc> </arg> <arg> <author> <name>bray</name> <firstname>tim</firstname> </author> </arg> </arguments> Un point négatif à noter au niveau des donnes échangées entre les applications client/serveur est l impossibilité de découvrir quel type d objet est envoyé. Il serait facilement possible d ajouter un attribut type à la balise <arg> afin de définir le type exact de l argument courant. Quoi qu il en soit, les applications client et serveur doivent savoir de quelle manière communiquer entre eux Comparaison Reprenons la comparaison préalablement faite sur XML-RPC et SOAP en incluant notre nouveau protocole. Il est bien sûr entendu que ce protocole est spécialement dédié à notre plateforme et n offrira pas forcément les mêmes prestations lors de son utilisation dans un cadre plus général comme avec les deux autres protocoles. FOR Mobile Doctor s Desktop Feature XML-RPC SOAP New Protocol Basic scalars yes yes yes Structs yes yes no Arrays yes yes yes Named structs and arrays no yes no Detailed fault handling yes yes limited Short learning curve yes no yes Developers specified yes (US-ASCII, no character set UTF-8, UTF-16) yes Developer defined data types no yes yes Can specify recipient no yes no Require client understanding no yes yes Message specific processing no yes yes 42/105

43 instructions Notre protocole présente une faiblesse majeure qui est la représentation non typée de la liste d arguments. C est à l application de savoir exactement à quoi correspond un argument. Par contre, il présente un grand nombre d avantages par rapport aux deux autres protocoles. Le premier est le fait d avoir un contrôle de A à Z au niveau de l analyse du document. L authentification et le chargement de l application sont donc directement gérés par notre plateforme. Les applications se chargeront de lire le corps du document de manière transparente et beaucoup plus simplement qu avec SOAP. Deuxièmement, la taille du fichier XML est nettement plus faible, ce qui permet d économiser du temps lors du parsing. De plus, le choix du type de parser étant libre, il est possible d utiliser ce qu il y a de plus efficace pour notre plateforme, à savoir StAX sur le serveur et un pull-parser (kxml) pour le client. 5.6 Description d une application Présentation Une des faiblesses de notre protocole est le fait que les deux applications doivent connaître l ordre exact des arguments de requête et de réponse. Le mieux est de représenter une application serveur en définissant les arguments nécessaires à la génération d une requête ainsi que ceux de la réponse. Un langage existe déjà, il s agit de WSDL (Web service definition language). WSDL est un format permettant de décrire un service Web. Dans notre cas, nous avons créé un nouveau protocole d échange, optimisé pour la plateforme. Un nouveau langage de description associé à notre protocole est la meilleure alternative, car elle permet de définir les besoins exacts d une application. Les éléments qui doivent être incorporés dans notre langage de définition d une application sont : Le nom de l application Le nom des différents services Les arguments de requête dans l ordre des différents services Les arguments de réponse dans l ordre des différents services Structure Voici la définition de l application «Patient» contenant un service «getpatient». Le type «fixed» d une requête permet de définir si la liste d arguments est fixée à cette unique forme, car il se peut que le développeur choisisse de ne pas fixer le nombre exact d arguments. <application name="patient"> <service name="getpatient"> <requestarguments type="fixed"> <arg type="int"> id </arg> 43/105

44 </service> </application> </requestarguments> <responsearguments type="fixed"> <arg type="string"> name </arg> <arg type="int"> birthdate </arg> <arg type="int"> phone </arg> <arg type="string"> illness </arg> </responsearguments> Analyse La lecture de ce document XML est très facilement compréhensible ; il permet de connaître les arguments nécessaires au bon fonctionnement d une application. Cela offre une meilleure compatibilité entre les différentes applications devant communiquer entre elles. De plus, le fait de formaliser une application permet de développer certains outils permettant de générer de manière automatique le squelette d une nouvelle application comme X2JWS, qui sera détaillé plus loin. 5.7 Conception Présentation L'élaboration d'un serveur utilisant de nombreux composants avec de multiples interconnexions est très souvent difficile à mettre en place, tout comme le fait de permettre l'évolution constante du produit, en offrant la possibilité d'ajouter ou de modifier des composants de la manière la plus simple possible. L'organisation en couches permet de séparer les différents tiers utilisés dans l'architecture. Le fait de séparer les différentes couches offre une meilleure gestion de l'ensemble. Cela évite de mélanger les fonctionnalités et on y gagne ainsi en compréhension. Dans l'exemple ci dessous, on constate qu'il s'agit d'une architecture composée de 4-tiers. Pour débuter, il y a le client, par exemple un navigateur Web qui va s'occuper de l'envoi de requêtes à notre serveur. Le second tiers est la partie Web s'occupant de gérer uniquement les différentes requêtes et réponses. Le troisième tiers, la logique métier, s'occupe uniquement des opérations purement «techniques». C'est à dire qu'elle ne contient pas de données, mais va uniquement en manipuler. Finalement, comme quatrième tiers, une partie base de données qui contient les informations utiles à la logique métier. Cela permet ainsi de séparer complètement les différents types d'opérations à réaliser pour répondre à la requête du client. De ce fait, la modification d'un tiers n'aura pas d'impact sur les autres /105

45 Architecture N-tiers Le fait de séparer en tiers permet une mise à jour constante et précise. De plus, la compréhension du fonctionnement général est nettement facilitée, vu qu'il n'y a pas de mélange entre les différentes fonctionnalités. Le problème réside dans l'utilisation de différentes technologies qu'il faut interconnecter. C'est la qu'intervient J2EE, en proposant différents composants permettant des interconnexions entre l'environnement java et diverses technologies Couches 17 Le concept de séparation en couches d'un système permet de dissocier les différents éléments ou fonctionnalités, cela afin de garantir l'évolution, la modularité et la structure du système. Notre architecture complexe se doit donc d'avoir sa propre structure afin de définir les différentes entités composant l'ensemble. Le problème principal réside dans la difficulté à mettre en oeuvre une architecture propre et stable. En effet, la phase de séparation demande de très bonnes connaissances des outils disponibles, de même qu'une très bonne aptitude à utiliser l'abstraction et les concepts objets. La phase de conception débute par deux questions fondamentales : Quelles sont les grandes parties? Comment sont-elles connectées? Ces règles guident la définition des grandes parties et permettent de déterminer les éléments principaux du système, afin d'en établir la structure. Une couche est associée à un sous-système ayant un objectif spécifique. Il est important de noter que le couplage n'est pas forcément restreint à un échange entre une couche et sa voisine immédiate inférieure. En effet, il est possible d'établir une collaboration ou un couplage entre couches sans qu'elles ne soient voisines directes. Il est par contre nécessaire de conserver les concepts de base. Une couche supérieure peut donc avoir des liens avec une couche service, technique ou fondation. Les différentes règles à établir dépendent fortement du type d'application désiré. Le couplage est un /105

46 élément primordial dans le développement d'applications Recherche des couches Éléments clés Voici les différentes couches potentielles pour notre architecture. Deux types d'éléments sont distingués, d une part logiciels et d autre part matériels : Les éléments matériels : Le client Le serveur d'authentification (couche sécurité) La base de données (couche données) Les éléments logiciels : La gestion des connexions (couche connexion) La partie transport (couche transport) La partie d'analyse de la requête (couche analyse) La partie logique des données applicatives (couche applicative) Le connecteur à la base de données (couche connecteur) Analyse Couche connexion Cette couche est à la base d'une connexion client-serveur. C'est elle qui, une fois chargée, aura la possibilité d obtenir les éléments de requête et de réponse. Une fois initialisés, ces derniers seront transmis à une couche différente afin de pouvoir être interprétés correctement. Ainsi, le premier objectif est de créer la couche transport à l aide des éléments de requête et de réponse. Une fois ceci effectué, il faut initialiser la partie permettant d effectuer l analyse de ces éléments. En résumé, la couche connexion s occupe des deux tâches suivantes : Créer la couche transport avec la requête et la réponse Initialiser la couche analyse Couche transport Vu que nous utilisons une communication complexe basée sur XML, il est intéressant de créer une couche spécialisée dans la lecture d'une requête et dans la génération d'une réponse. Cette couche va permettre d interpréter le protocole de transfert et ainsi, d interagir avec les différentes données. Cette couche va donc servir de lien entre les données de transfert et les différentes couches locales. Elle sera utilisée par les couches suivantes : Analyse Applicative Couche analyse La couche analyse est la fondation même de notre structure serveur. C'est elle qui 46/105

47 s'occupe de traiter l entête d une requête client grâce à la couche transport. Elle a connaissance des opérations exactes à effectuer selon les éléments de requête et va gérer les différentes phases primordiales à l'élaboration de la réponse. Vu sa connaissance globale des différents éléments, c'est elle qui se charge de générer l'entête de la réponse grâce à la couche transport. Pour le corps, elle va devoir faire appel à la couche applicative. Ainsi, lors de sa création, elle doit analyser, extraire et approuver le contenu de la requête. Après extraction du contenu, elle dispose de deux parties bien distinctes: une entête contenant les informations sommaires qui lui seront utiles, et un corps contenant les données pures qui seront transmises à la partie applicative. Une fois l'entête connu, elle va pouvoir authentifier la requête en faisant appel à la couche de sécurité. Puis, elle va charger la couche applicative qui va s occuper de traiter les données du corps de la requête. L'application à charger est connue sous la forme générique d'une «application mobile» par la logique métier, c'est à dire qu'elle ne connaît pas du tout son fonctionnement, mais uniquement les éléments nécessaires à sa création. Au final, ce n'est pas la logique métier qui va manipuler les données à proprement parler, mais bien la partie applicative. La logique métier gère l'ensemble des fonctionnalités grâce à l'entête de la requête et transmet le corps de la requête à la partie applicative, qui va générer le corps de la réponse. La logique métier a des liaisons avec les couches suivantes : La couche transport, afin d'écrire les entêtes des différentes réponses La couche applicative, afin d'initialiser les différentes applications chargées Le serveur d'authentification, afin de sécuriser l'accès Et une liste d'outils Couche applicative La partie applicative est la partie «logique» à proprement parler. C'est elle qui va traiter les informations contenues dans le corps de la requête. Les applications sont une partie majeure de notre architecture, car ce sont elles qui proposent les différents services accessibles par le client. Il est important de noter qu'une application est totalement indépendante du serveur ; c'est à dire qu'un élément «application» est chargé par le serveur sans connaître son fonctionnement exact. La partie applicative a des liaisons avec les couches suivantes : La couche transport, afin d'écrire le corps de la réponse Le connecteur à la base de données Une liste de services et outils Le connecteur Le connecteur est un élément permettant aux applications de faire au maximum abstraction de la base de données. Il offre la possibilité de se connecter à la base de données et de rechercher les différentes informations. Actuellement, le connecteur utilise une simple connexion JDBC sur une base de données SQL. Il n'est pas vraiment utile de le séparer en une couche spécifique, comme le serait un élément nettement plus complexe tel un EJB Entreprise Java Beans. Couche Sécurité Cette couche va permettre d authentifier un utilisateur de manière sûre. Pour ce faire, elle va être utilisée directement par la couche analyse dans le but de définir au plus tôt si la 47/105

48 requête est valide ou non. De manière optimale, la partie logique se trouve sur un serveur distant et va permettre de gérer entièrement le contrôle des différents utilisateurs. Par la suite, un module interne va être développé afin de garantir un niveau de sécurité minimal et permettant de tester de manière simple l ensemble de la plateforme. Schéma Après avoir effectué l analyse des couches, il est possible de définir un schéma de fonctionnement du serveur. 5.8 Conclusion Une des grosses parties de la conception fut l élaboration du protocole de transport permettant la communication entre la plateforme serveur et les différents clients. Le fait de créer un nouveau protocole dédié apporte certains avantages lors de l utilisation d une plateforme mobile nécessitant un haut niveau de sécurité. En effet, le fait de créer l intégralité du protocole, que ce soit au niveau des méthodes de parsing ou du contenu, permet de respecter au mieux les objectifs fixés. Premièrement, au niveau des performances, le fait d utiliser notre propre parser de type pull, permet de garantir un résultat optimal lors de la lecture des différents éléments. En effet, il offre la possibilité à une application d interpréter le contenu du document XML sans avoir à en charger l intégralité en mémoire. De plus, cela permet de lire les éléments dès leur réception, ce qui évite de perdre la totalité des données lors d une coupure de 48/105

49 connexion. Au niveau de la taille, le protocole est relativement léger par rapport à SOAP, ce qui permet un gain en vitesse lors de l utilisation d une ligne de mauvaise qualité. Un autre avantage important se situe au niveau du contenu des données. En effet, grâce à cela, notre plateforme devient l environnement de chargement et d exécution des diverses applications, en vue de garantir la sécurité et le respect du protocole. Au niveau de la sécurité, le protocole contient exactement les données permettant d établir une connexion sécurisée. Cela dans le but de garantir la protection et l authenticité des données médicales. Les autres données permettent le chargement précis de l application désirée avec la liste des paramètres d initialisation. La faiblesse réside dans la compréhension des données entre applications. Le protocole ne permet pas de définir clairement les données qu il contient. De ce fait, c est à l application de savoir quel élément va être traité et à quel moment. Cela peut causer des soucis de compatibilité lors d échanges entre applications différentes. Le langage de description défini permet d une certaine manière de répondre à cette problématique en définissant «de quelle manière appeler le service d une application». Un autre point faible est qu il n est pas répandu comme les protocoles SOAP, XML-RPC ou REST. De ce fait, un programmeur aura besoin d un certain temps d adaptation afin de se familiariser avec ce protocole. De plus, étant à ce jour utilisé uniquement dans notre plateforme, il ne sera pas possible de l utiliser via les applications existantes sans adaptation. Ce protocole est donc idéal dans le cadre d une plateforme propriétaire complète mais ne pourra pas être utilisé à grande échelle de manière libre par la majorité des personnes. Le fait d avoir défini la structure en couche de l application favorise nettement sa compréhension ainsi que sa conception. Il est donc maintenant possible de passer à la phase conceptuelle du projet en réalisant l intégralité des fonctionnalités définies. 49/105

50 6 Serveur d applications : Réalisation 6.1 Présentation Après l étude théorique de la problématique, il est temps de passer à la réalisation. Les étapes sont nombreuses et le niveau des objectifs est relativement élevé. 6.2 Structure Plateforme La plateforme va suivre une certaine structure dans le but de définir les emplacements où seront stockés les différentes configurations et éléments. L environnement d exécution de notre servlet étant tomcat, il est possible grâce à java de connaître le chemin d accès de l installation du serveur. La variable CATALINE_HOME est définie par tomcat et peut être lue grâce à la commande suivante : System.getProperty("catalina.home") Une fois le chemin d accès au répertoire d installation de tomcat connu, il est possible de définir la location de notre serveur. En effet, les fichiers WAR déployés par tomcat se trouvent dans le répertoire \webapps. Le répertoire du serveur tomcat o CATALINA_HOME = (String)System.getProperty("catalina.home"); Notre répertoire HOME: CATALINE_HOME\webapps\ServicesServer o \bin o \javadoc o \META-INF o \WEB-INF o Fichiers Web Jsp, css etc Les fichiers de configuration : HOME\bin\conf o Containers.xml o Diary.xml o Users.xml Les fichiers utilisés pour l interface Web : HOME\bin\web o Diary.xsl o Manager.xsl Les fichiers de configuration de sécurité : HOME\bin\ssl o truststoreauth o truststoreclient 50/105

51 6.3 Fonctionnement Voici le schéma de base représentant le fonctionnement du serveur. La Servlet est appelée lors d une requête. Les modules sont utilisés afin de réaliser les différentes tâches au niveau des grandes parties : l analyseur et les applications. 51/105

52 6.4 Analyseur Présentation L analyseur ou logique métier est l élément permettant d analyser la requête et de réaliser les différentes tâches nécessaires à son traitement. Dans ce but, il va utiliser les différents modules proposés comme la sécurité, la couche transport et différents outils. Il va permettre aussi de traiter les différentes exceptions afin de gérer lui-même les actions à entreprendre. Cela permet de garantir la sécurité et la structure tout en simplifiant la vie du développeur d applications qui ne va pas avoir besoin de s occuper de ces différentes tâches. En résumé, l analyseur s occupe des tâches suivantes : Lire l entête de la requête Authentifier la requête Sauvegarder l événement Charger une application dans l environnement serveur Ecrire l entête de la réponse Exécuter une application Gérer les exceptions Lors de sa création par la Servlet, l analyseur reçoit en paramètre le module de transport. De ce fait, il peut directement accéder au contenu de la requête XML afin de lire ou écrire les différents éléments. Il reçoit aussi la requête sous son format ServletRequest dans le seul but de connaître les différents éléments liés à la connexion comme le nom de l utilisateur, son adresse IP ou autre. public LogiqueMetier(Transport transport,servletrequest request){ 6.5 Couche Transport Présentation La couche transport permet l échange d informations entre le client et le serveur. Elle va être utilisée à deux niveaux, premièrement par le serveur et deuxièmement par les applications. Les deux environnements étant totalement indépendants, il est utile de séparer les fonctionnalités réservées à une entité par rapport à une autre. Java permet de limiter l accès aux ressources d une classe grâce à certains mots clés, comme «protected» qui permet de restreindre l accès d un élément aux classes d'un package et à ses classes filles. De ce fait, il est possible de rendre certaines méthodes accessibles uniquement par le serveur. Il existe deux versions de cette couche transport. L une dédiée au serveur et l autre pour le client. Ces deux versions offrent les mêmes possibilités, afin de garantir le format et la compréhension du protocole. La version serveur intègre la réception et l envoi de données dans la même classe. Tandis que sur le client, il y a deux classes, l une pour l envoi et 52/105

53 l autre pour la réception, cela afin de permettre au client d avoir un contrôle sur l entête du transfert lors de l envoi et de la réception Méthodes destinées au serveur Le serveur va devoir créer la couche transport et initialiser ses différents paramètres. De plus, il doit avoir accès aux différentes ressources concernant l entête d une requête. Les méthodes suivantes lui seront donc réservées : La création de la couche transport et des différents parsers o new Transport() : Constructeur o initstreamreader(inputstream in) o initstreamwriter(outputstream out) L accès aux ressources de l entête o readheader() : Lecture de l entête, méthode à effectuer avant les get o getid() : pour l accès à la ressource ID o getapplication() : pour l accès à la ressource Application o getservice() : pour l accès à la ressource Service o writeheader(string id, String application, String service) La fermeture des différents parsers o closereader() o closewriter() Méthodes destinées aux applications Les applications, pour leur part, auront uniquement accès aux ressources concernant les arguments. Les méthodes suivantes seront donc disponibles pour les développeurs d applications : La lecture des arguments o String getargument() o List<String> getarguments() o String getbase64() o Void readxmlargument(xmlsectionreader xsr) L écriture des arguments o writeargument(string arg) o writearguments(list<string> list) o writearguments(string[] list) o writebase64(byte[] bytes, int fragmentsize) o writebase64(file file, int fragmentsize) o writecharacters(string arg) o writecharacterslist(list<string> list) o writecharacterslist(string[] list) o writexml(xmlsectionwriter xsw) o initloopbackrequest(string application, String service) Données complexes : Base64 Base64 permet l encodage de bytes. Une des problématiques découle du fait que les 53/105

54 éléments encodés avec base64 peuvent être relativement volumineux, ce qui risque de causer des problèmes de performances sur notre plateforme mobile lors du décodage. Une solution est de fragmenter les fichiers trop volumineux en plusieurs arguments. De ce fait, le parser n aura pas besoin de charger l intégralité des données en mémoire. Un autre moyen permettant de gagner du temps est de pouvoir directement spécifier la taille finale des données afin d éviter le re-dimensionnement dynamique. La solution mise en place permet de spécifier la taille des données base64 à envoyer. Le décodage se fait de manière totalement transparente par la fonction correspondante. Le protocole d envoi de données base64 a été défini de la manière suivante : <arguments> <arg>taille finale des données [int]</arg> <arg>n fragments[int]</arg> <arg>base64 1 er fragment[cdata]</arg>.. <arg>base64 N eme fragment[cdata]</arg> </arguments> Lors de l appel de la méthode getbase64(), l argument courant va être traité comme la taille finale des données, le second comme le nombre d arguments à lire et les suivants en tant que fragments de données Base64. L envoi et la réception se fait donc de manière totalement transparente pour l utilisateur, du moment qu il respecte l ordre des données établi par l application. Données complexes : XML L envoi de données XML est une facette intéressante du protocole, car elle permet de spécifier une nouvelle structure tout en gardant les avantages du parser. Notre parser utilisant une API curseur, il n est malheureusement pas possible d intervenir dans la structure des données depuis une application. Pour palier à ce problème, une solution est de donner la main du parsing à l application, qui va devoir respecter la structure afin de ne pas générer des incompatibilités au niveau du protocole. Cela n aurait aucun impact sur la sécurité, vu que l entête n est pas contrôlé par l application. Sinon, une meilleure solution serait d implémenter un parser basé sur une API itérateur offrant la possibilité à une application d envoyer ses propres données XML, sans avoir à se préoccuper de la structure du protocole. Vu que le choix de parser a déjà été fait, la première solution a été retenue. De plus, vu la compatibilité des parsers, elle pourra être implémentée directement sur le client riche mobile. Ainsi, Les deux interfaces XMLSectionWriter et XMLSectionReader utilisables par la couche transport permettent à une application de définir sa propre structure de données. Ces deux interfaces définissent les méthodes suivantes afin d utiliser le flux XML : public interface XMLSectionReader{ public void read(xmlstreamreader reader) throws XMLStreamException; public interface XMLSectionWriter{ public void writexml(xmlstreamwriter xsw) throws XMLStreamException; Ces deux méthodes prenant en paramètre le parser StAX, c est donc à elles d écrire ou de lire directement dans le flux. Il est très important que le programmeur respecte la structure lors de l envoi et de la réception, car dès la fin de l exécution du parser externe, le transfert sera à nouveau appliqué par la plateforme serveur. 54/105

55 <arguments> <arg> <complexe> <c>argumentcomplexe<c> <complexe> </arg> <arg>argumentsimple</arg> </argument> Prise de contrôle par l application Parsing effectué par l application Reprise du contrôle par la couche transport Communication interservices Une des problématiques découle de la communication entre services d applications différentes. En effet, il peut être très pratique de pouvoir utiliser les données d une autre application, afin de pouvoir effectuer une synchronisation entre elles. Il faut définir une solution permettant d échanger les données sans avoir à effectuer des modifications dans les applications existantes. Une solution élégante et rapidement intégrable est de permettre à une application d effectuer une requête en «loopback», afin de ne pas «court-circuiter» le serveur. Cela a pour avantage de conserver le fonctionnement de base de la plateforme au niveau du protocole d échange et de la sécurité. Par contre, il faut re-parser les informations, ce qui prend un certain temps. Une application va donc avoir la possibilité d en appeler une autre, tout en gardant exactement la même méthode d échange. C est la couche transport qui va offrir cette fonctionnalité, car elle est la seule à posséder une interconnexion entre le serveur et l application, cela afin de conserver l identité cryptée du client, dans le but de pouvoir le re-authentifier. La méthode proposée permet d utiliser une nouvelle couche transport entre les applications du serveur, utilisable de manière semblable à celle réservée à un échange client-serveur. Voici la méthode java qui permet de spécifier l application distante et le service désiré : TransportModule initloopbackrequest(string application, String service) throws Exception; Une fois la couche de transport créée, il suffit d utiliser les fonctions connues comme writeargument() afin d envoyer les données à l application voisine. Une fois l envoi terminé, il suffit simplement d exécuter getargument(), par exemple, pour obtenir les différents résultats Parser Le parser a un rôle important. C est lui qui va se charger de lire et d écrire dans le flux XML. Le parser effectue la passerelle entre les données XML et la couche transport. Les parsers devront implémenter les interfaces suivantes qui permettront de remplir les différentes fonctionnalités : Lecture : ReaderParserInterface String getid (); String getapplication (); 55/105

56 String getservice (); String getargument () throws EOAException,XMLStreamException; void readstartsequence() throws XMLStreamException; void readendsequence () throws XMLStreamException; void readxmlargument (XMLSectionReader gpr) throws XMLStreamException,EOAException; Ecriture : WriterParserInterface void writeinitsequence (String id, String app, String service) throws XMLStreamException; void writeendsequence () throws XMLStreamException; void writeargument (String value) throws XMLStreamException; void writecharacters (String value) throws XMLStreamException; void writexml (XMLSectionWriter gpw) throws XMLStreamException; 6.6 Sécurité Présentation Le module d authentification est une des parties les plus importantes au niveau de la sécurité, car il permet d authentifier les requêtes de manière sûre. M.Badan s occupant de la partie sécurité de la plateforme, il ne m est pas possible de tester cette fonctionnalité sans effectuer la liaison entre nos deux serveurs. J ai donc décidé de développer un second module de sécurité avec un niveau de sécurité nettement plus faible, mais qui me permet d effectuer certains tests. Bien entendu, ce module sera remplacé au final par un autre, ayant accès au serveur d authentification et garantissant ainsi la sécurité de l ensemble. L authentification va se faire au niveau de l id d une requête. Le module doit pouvoir authentifier cette id et définir si elle est valide ou non. La définition d une interface de sécurité permet de passer de manière simple d un module à un autre sans modifier beaucoup de code. Les seules méthodes à incorporer dans l interface sont : Le contrôle d une id de requête int checkid(string id) throws SecurityException; La lecture du nom du créateur de la requête String getclientid(); Module de sécurité local Ce module servant uniquement aux tests, il n est pas nécessaire d effectuer des fonctions d authentification lourdes. Je vais donc simplement générer des id valides grâce à un document XML. Ce document va me permettre de valider les diverses requêtes. Il peut aussi être utilisé pour une authentification Web basée sur un simple mot de passe lors de la connexion à l interface de management : 56/105

57 <?xml version="1.0" encoding="utf-8" standalone="yes"?> <users> <admin> <user id="admin" password="admin"/> <user id="manager" password="manager"/> <user id="jp" password="jp"/> </admin> <client> <user id="client" password="client"/> </client> </users> Ce document définit deux types d utilisateurs, soit les administrateurs et les clients. Ces deux types de personnes auront des droits d accès différents, ce qui permet d effectuer une séparation entre les différentes applications disponibles Module de sécurité distant Le module de sécurité distant nécessite une connexion SSL avec le serveur d authentification, qui va permettre d analyser directement un id ; il suffit donc de se connecter et de l envoyer. Une fois l id envoyée, le serveur d authentification va retourner différents éléments selon sa validité. Si l id est correct, il retourne le nom de l utilisateur o valid : userlogin Si l id est incorrect, il retourne une erreur o error : invalid id Si il y a une erreur interne o error : «error type» Il faut donc créer un parser permettant d analyser le contenu de la réponse. Cela fait, il est très simple de définir si une requête est valide ou non SSL Au niveau de la connexion, il est important de crypter les données afin de garantir la sécurité lors de la communication entre le client et le serveur. Le protocole SSL répond à cette problématique en proposant l encryption des données via un échange de clé symétrique. Voici le fonctionnement d un échange SSL : 57/105

58 18 Java propose des outils afin de générer les certificats et d exporter les clés publiques. Il faut donc installer sur le client le «truststore» contenant la clé publique de notre serveur. Une explication détaillée de l installation SSL se trouve en annexe. Un des problèmes lors de l utilisation provient d une erreur de compatibilité entre les plateformes PDA et serveur. En effet, lors de certains envois, le PDA génère une erreur «Invalid padding». M.Badan s est penché sur le problème et propose une solution : il faut envoyer des paquets de bytes multiples de 8. Cela implique une modification au niveau du parser, qui ne doit plus écrire directement dans le flux mais passer par un buffer externe, afin de contrôler l envoi. 6.7 Applications Présentation Le but d une application est de pouvoir échanger des données avec le client de manière la plus simple et la plus transparente possible. Pour cela, l interface «ApplicationMobile» a été créée dans le but de définir la méthode suivante nécessaire à l initialisation d une application : public void selectservice(string service, TransportModule transport) throws ServiceException; Après authentification de la requête, l application va être initialisée par la plateforme via cette méthode. Elle permet de définir le service désiré et surtout la couche transport utilisée pour l échange. L application a donc en main les objets nécessaires pour exécuter son service interne qui va interpréter la requête et générer l élément de réponse via le module de transport /105

59 6.7.2 Utilisation Premièrement, une application doit implémenter l interface «aplicationmobile» et ainsi définir la méthode selectservice. Lors de son exécution, l application va analyser le service demandé et le charger : (exemple) public void selectservice(string service, TransportModule transport) throws ServiceException{ if(service.compareto( Service1 )==0){ service1(transport); }else if(service.compareto( Service2 )==0){ service2(transport); }else{ throw ne ServiceException( Service not found ); } } Puis, le service chargé va s occuper de la couche transport d une manière totalement transparente en utilisant simplement les méthodes offertes de cette manière : public void service1(transportmodule transport) throws ServiceException{ String arg1 = transport.readargument(); byte[] picture = transport.readbase64();... transport.writebase64(file); transport.writeargument(response); } L établissement d un échange est ainsi vraiment simple à mettre en oeuvre au niveau applicatif. 6.8 Conteneur d applications Présentation Un conteneur d applications peut être assimilé à un simple répertoire se trouvant sur le disque dur contenant des fichiers. L administrateur du système doit pouvoir interagir avec les conteneurs sans avoir à effectuer des changements de code au niveau du serveur. Une solution est de décrire le conteneur grâce à un document XML qui sera interprété automatiquement par le serveur. La description du conteneur doit contenir les informations suivantes : Location sur le disque dur Les applications disponibles Le fait d intégrer le nom des applications disponibles directement dans le fichier de description permet d avoir un contrôle sur les différentes ressources pouvant être exécutées depuis notre serveur. Ainsi, lors d une requête, ce module va permettre d obtenir le chemin d accès à une application selon son nom. Deux types de conteneurs 59/105

60 pourront être définis, afin d offrir la possibilité de séparer les types d applications administrateur et client. Voici les méthodes principales proposées par le module : Obtenir le nom du conteneur d une application administrateur ou publique public String getpublicapplicationcontainer(string name){ public String getadminapplicationcontainer (String name){ Obtenir la référence d un conteneur selon son nom et son type admin ou public public String getcontainerref(string type, String name){ XML Le conteneur public nommé «public package» pointe sur le répertoire c:\applications\ et offre les applications «FichePatient», «Contact» et «Alarm» : <containers> <public> <container ref="c:\applications\" name="public package"> <file name="fichepatient"/> <file name="contact"/> <file name="alarm"/> </container> </public> </containers> 6.9 Chargeur d applications Présentation Le chargeur d applications permet de créer de nouvelles instances des applications mobiles, selon leurs noms et leurs chemins d accès. Il offre la possibilité d ajouter des applications de la même manière que des plugins, c'est-à-dire qu elles pourront être insérées sans modification du code source. Les applications devant être chargées devront impérativement implémenter l interface «ApplicationMobile». Une autre facette de ce module est de pouvoir charger une méthode spécifique d une classe. Cela permet d automatiser l exécution des services génériques lors d une requête. Voici une liste des méthodes principales de ce module : Charger une application selon son nom et selon le niveau d accréditation (0=admin) ApplicationMobile loadapplication(int level, String application) throws LoaderException{ Exécuter une application en lui passant le service et la couche transport void executeapplication(applicationmobile app, String service, 60/105

61 Transport throws transport) ServiceException{ Exécuter le service d une application selon son nom et lui donner la couche transport void getservice(applicationmobile application, TransportModule transport, String name) throws ServiceException { JAR Loader Le JAR loader va permettre de charger un fichier JAR ne se trouvant pas dans l environnement courant. Pour cela, il va devoir connaître le chemin d accès au fichier et le «ClassLoader» dans lequel charger la classe. Le chargement du JAR s effectue selon son fichier «manifest» représentant la configuration de l application. Il est donc important que le fichier indique quelle est la classe principale et quelles sont les librairies à utiliser. public Object loadjar(string file,classloader cl)throws Exception{ Service Loader Le service loader permet de charger les services (méthodes) proposées par une application de manière automatique. Pour cela, ils doivent respecter la structure suivante : public void «nom application»(transportmodule transport) throws Exception ; Dès que cette forme est respectée, l application peut être appelée par le chargeur de services qui va lui passer en paramètre le module de transport. La classe AutoServiceLoader implémente l interface ApplicationMobile et définit la méthode selectservice( ). De ce fait, une application qui «extends» AutoServiceLoader va voir toutes ses méthodes chargées automatiquement selon leurs noms sans avoir à surcharger la méthode de chargement de service (selectservice). Ainsi, lors de la création d une nouvelle application, il est possible de définir uniquement les entêtes suivants : //L application mobile public class Contact extends AutoServiceLoader implements ApplicationMobile{ //Le 1 er service public void Service1(TransportModule transport) throws Exception{ } //Le 2 eme service public void Service2(TransportModule transport) throws Exception{ } public String getname(){ return Application1 ; } } 61/105

62 6.10 Package et classes Vue globale 62/105

63 Distribution Le package suivant représente les modules utilisables par les applications : Distribution Distribution.applicationsInterface : Les interfaces importantes ApplicationMobile TransportModule Interface qu une nouvelle application mobile doit impérativement implémenter Le module de transport permettant à une application de lire et d envoyer des données de types suivants : Texte : Integer, Double, String etc Listes, tableaux Binaires XML XMLSectionReader Méthode qu un nouveau parser doit implémenter afin de lire des données XML grâce à la couche de transport XMLSectionWriter Méthode qu un nouveau parser doit implémenter afin d écrire des données XML grâce à la couche de transport 63/105

64 Distribution.serverException : Les exceptions utilisés par le serveur EOAException ExceptionInfo ServiceException Exception de fin d arguments, levée par la couche transport Correspondance des Exceptions afin de pouvoir les traiter depuis l application Exception à lever lors d une exception interne de l application Distribution.Service : Les services proposés aux applications AutoServiceLoader Service permettant à une application de charger automatiquement ses services selon leurs noms. Il faut que l application «extends» AutoServiceLoader ServicesDB Service permettant d accéder de manière simplifiée à une base de données SQL via JDBC 64/105

65 Servlet Package contenant les différentes servlet et la logique métier représentant la base de notre architecture : Servlet Server La servlet Server.java va s occuper uniquement de gérer les différentes requêtes. Elle crée directement la couche transport lors de la réception d un message. Puis, elle crée la logique métier qui va s occuper d analyser la requête grâce à la couche transport LogiqueMetier La logique métier extrait, grâce à la couche transport, quatre éléments à la requête : l'id du client, l'application, le service et la liste d'arguments. Puis, la logique métier exécute différents composants tels que : l'enregistrement de l'événement avec l'ip, le nom et les paramètres de la requête, l authentification de la requête, le chargement de l'application, l exécution de l'application en lui donnant en paramètre le service et les arguments ainsi que la gestion des différentes exceptions Transport Cette classe représente la couche transport. Elle va être utilisée par le serveur et par les différentes applications. Les deux entités ont accès à des informations différentes : Serveur : l entête du transport, id, application et service Application : Le corps du transport, la liste d arguments 65/105

66 Servlet.configuration : La configuration du serveur Constantes Cette interface contient toutes les différentes constantes nécessaires au serveur : HOME : La location du serveur sur la machine LOOPBACK : l addresse loopback de la machine CONFIGURATION_FILE_LOCATION : la location des fichiers de config WEB_FILE_LOCATION : la localisation des fichiers web AUTHENTIFICATION_SERVER : l adresse du serveur d authentification TRUSTSTORE_LOCATION : la localisation des truststores TRUSTSTORE_PASSWORD : le password du truststore SERVER_AUTHENTIFICATION_REQUIRED : Mode d authentification Utils Ce package représente tous les modules utilitaires pouvant servir aux couches principales. Utils DBConnector ServicesServer connecteur avec la base de données. Offre différentes possibilités, comme exécuter une requête ou effectuer une mise à jour. En plus de proposer les fonctions de base d accès à une base de données, il propose des fonctions utilitaires permettant de manipuler plus facilement les données. Cette classe offre différents services internes au serveur. 66/105

67 Utils.diary : Journal d événements Historique XMLDiaryParser Classe permettant de stocker un événement. Cela permet de garder un suivi des différentes transactions effectuées. L'historique est stocké dans un document XML. L enregistrement d un évènement se fait de façon synchronisée afin d éviter l accès concurrent à la ressource. Ce parser est utilisé pour lire, créer et afficher le journal d événements. Il s occupe uniquement de l interaction avec le document XML correspondant. Utils.containers : Conteneur d applications ContainersAnalyser Cette classe analyse les conteneurs d applications grâce au document XML de description. Elle permet d obtenir toutes les informations relatives à un conteneur et de vérifier à quoi correspond une application. 67/105

68 Utils.http : Modules Web Authentification XMLDiaryParser C est le module d authentification à l interface Web. Il permet d authentifier un utilisateur selon son nom et son mot de passe définis dans le document XML users.xml Ce parser est utilisé pour lire, créer et afficher le journal d événements. Il s occupe uniquement de l interaction avec le document XML correspondant. Utils.loader : Chargeur d applications JarLoader LibraryLoader LoaderException Module de chargement dédié aux applications mobiles sous format JAR Le chargeur d application qui permet d instancier les différentes applications. Il offre aussi la possibilité de charger un service lié à une application Exception de chargement d application 68/105

69 Utils.transport : Couche de transport ReaderParserInterface WriterParserInterface Base64 L interface représentant un parser XML de lecture L interface représentant un parser XML d écriture Le module créé par Robert Harder, permettant d encoder et de décoder des données grâce à base64 XMLStreamReaderParser Le parser XML de lecture permettant d analyser un document XML respectant le protocole de transport établi XMLStreamWriterParser Le parser XML d écriture permettant de générer document XML respectant le protocole de transport établi 69/105

70 Security Ce package contient tous les outils nécessaires à garantir la sécurité de la plateforme Security SecurityInterface UserLevelMapping L interface représentant un module de sécurité. Elle définit les deux méthodes suivantes : checkid(string id) afin d authentifier l id getclientid() afin d obtenir le nom du client Définit deux niveaux d utilisateurs, les administrateurs et les clients. Cela permet de limiter l accès aux différentes ressources SecurityServerModule Le module de sécurité serveur nécessitant une connexion SSL avec le serveur d authentification distant Niveau de sécurité élevé SecurityModule XMLUsersParser Le module de sécurité local utilisé pour les différents tests et pour l authentification web Niveau de sécurité faible Parser permettant de lire les différentes informations relatives aux utilisateurs, authentifiables via le module de sécurité locale. Il permet de lire un nom et le mot de passe défini dans users.xml 70/105

71 6.11 Client lourd fixe Présentation Afin de tester le serveur, il est utile de développer un client lourd basique permettant de structurer une requête et de supporter des applications. Ce client lourd va donc utiliser J2SE et une plateforme fixe. Les contraintes du PDA ne seront donc pas testables, mais il sera possible de contrôler le fonctionnement au niveau du protocole de requête. Le client lourd fixe sera capable de : Supporter diverses applications Effectuer une requête Analyser une réponse Démontrer les possibilités du serveur Le but au final est de pouvoir porter les différentes fonctionnalités testées sur le client lourd fixe au client lourd mobile. Il faut par contre toujours garder à l esprit que les fonctions doivent être compatibles avec l environnement du PDA, ce qui devrait être le cas, vu l analyse effectuée préalablement Fonctionnement Le but est de pouvoir implémenter directement la même couche transport que celle existant sur le serveur. Cela permet de garder une concordance entre le fonctionnement du client et celui du serveur. Coté client, la seule modification à effectuer concerne le parser. En effet, StAX n étant pas disponible sur J2ME, il faudra en utiliser un autre comme kxml. L implémentation d une interface spécifique permet d effectuer ce changement de manière rapide et sans causer des ennuis de compatibilité. Pour faciliter le développement du client lourd fixe, je vais quand même utiliser StAX, car toutes les fonctionnalités de parsing sont déjà réalisées. Le client lourd fixe va offrir les mêmes fonctionnalités que le serveur au niveau du protocole, c'est-à-dire : o Connection SSL o o Envoi de données simples Textes : String, Integer, Doubles, etc Listes Tableaux Envoi de données complexes Données binaires sous format Base64 Données XML complexes Je ne vais pas approfondir le fonctionnement, car le client lourd fixe n est pas une priorité de la présente étude. Mais les différents résultats seront analysés lors du développement des applications au point suivant. 71/105

72 6.12 Conclusion Les différents modules développés permettent d atteindre les objectifs fixés, que ce soit au niveau de la sécurité ou des performances. Ces modules sont utilisés par les différentes couches afin d effectuer le traitement des étapes nécessaires à un échange entre le client et le serveur. Le fait de développer des modules offre l avantage de pouvoir modifier leur fonctionnement sans toucher à la structure du serveur. Cela permet donc d effectuer des mises à jour aussi souvent que désiré et de manière ciblée. En ce qui concerne les objectifs de sécurité, un module dédié est utilisé par la couche analyse dans le but d authentifier les requêtes de manière sûre. De cette façon, les applications n ont plus besoin de se soucier de la validité des requêtes, qui sera contrôlée au niveau du serveur. Le module actuel utilise le serveur d authentification développé par M.Badan, mais peut facilement être remplacé par un autre en utilisant l interface de sécurité. De ce fait, il est possible de customiser sa propre méthode d authentification comme je l ai fait pour le module de sécurité local destiné aux différents tests. Du coté des communications, la couche transport destinée à supporter l échange est très facilement utilisable et offre de nombreuses possibilités. Elle sépare les fonctions offertes aux applications et à la plateforme serveur. En effet, la plateforme serveur analyse uniquement l entête afin d authentifier la requête, charger l application et exécuter le service désiré. Puis, l application aura la possibilité d interagir avec le corps en utilisant des méthodes très flexibles permettant d échanger des informations variées. Typiquement, l envoi XML qui permet à une application d envoyer ses propres données XML ou encore, la possibilité d envoyer des données binaires comme des images, des textes, des chiffres et des listes. Les applications ont donc à disposition une couche permettant d échanger les différentes informations de manière très transparente. Au niveau technique, lors de l analyse des documents XML, des parsers de type pull sont utilisés : StAX sur le serveur et kxml sur le client. De ce fait, les performances sont optimales, spécialement sur le PDA ; cela permet donc d envoyer des données plus importantes sans risque de surcharge. Afin de tester les différentes fonctionnalités, un client lourd fixe a également été développé. Il va permettre de simplifier les tests et démontrer le bon fonctionnement du serveur. 72/105

73 7 Applications 7.1 Développement d applications : X2JWS Description de l application L outil indispensable à la génération d une nouvelle application mobile est X2JWS. Cet outil permet de générer le squelette d une application en se basant sur le document de description d application mobile défini précédemment. X2JWS se résume en un fichier XSL permettant la transformation XSLT avec la description XML de l application. Un petit module utilitaire a aussi été développé afin de faciliter l utilisation. Actuellement, X2JWS ne permet pas de générer des structures complexes, mais offre la possibilité de créer un squelette basique permettant de comprendre le fonctionnement. Il propose de générer la structure serveur mais aussi client, du client lourd fixe. Dans le cadre de la présente étude, j ai renoncé à développer cette fonctionnalité pour le client lourd mobile. Pour débuter, il faut utiliser le langage de description présenté précédemment, afin de définir la nouvelle application. Je me limite à présenter le cas d un seul service basique, n utilisant que des Strings comme arguments d échange : <?xml version="1.0" encoding="utf-8"?> <application name="contact"> <service name="getcontact"> <requestarguments type="fixed"> <arg type="string">id</arg> </requestarguments> <responsearguments type="fixed"> <arg type="string">name</arg> <arg type="string">lastname</arg> <arg type="string">birthdate</arg> <arg type="string">phone</arg> <arg type="string">address</arg> <arg type="string">place</arg> <arg type="string">file</arg> </responsearguments> </service> </application> Génération du code Maintenant, il faut générer le code grâce à l outil «DevelopperTools». Voici le code après transformation XSLT : package adminapplications; import distribution.services.*; import distribution.applicationsinterface.*; import distribution.serverexception.serviceexception; import java.util.*; import java.sql.*; 73/105

74 import java.io.*; public class Contact extends AutoServiceLoader implements ApplicationMobile { private final String APP_SERVER_NAME = "Contact"; public void getcontact(transportmodule transport)throws Exception{ // // Request -- // String id= (String)transport.getArgument(); //Response elements String name=null; String lastname=null; String birthdate=null; String phone=null; String address=null; String place=null; String file=null; // // *** INSERT FONCTIONNALITY HERE *** // } // // Response -- // //Writing the response transport.writeargument(name); transport.writeargument(lastname); transport.writeargument(birthdate); transport.writeargument(phone); transport.writeargument(address); transport.writeargument(place); transport.writeargument(file); } public String getname(){ return "Contact"; } Le squelette généré est fonctionnel et peut être intégré directement dans l environnement de développement. La seule partie à insérer est la partie concernant le traitement des données, indiqué par le commentaire «Insert fonctionnality». Ce squelette représente les lignes de codes nécessaires à la configuration de l application. La phase d élaboration est donc rapidement achevée, et il est possible de passer directement à la phase logique. 7.2 Application : Test Présentation L application de test coté client est la première à mettre en place. Elle va permettre de générer des requêtes sur notre serveur, puis d en afficher le résultat. Il sera donc possible d atteindre les différentes applications disponibles et de les débugger de façon optimale. Cette application va offrir les possibilités suivantes : Générer une requête en spécifiant l id, l application, le service et les arguments Afficher le résultat XML Afficher le résultat au format texte 74/105

75 Télécharger le résultat Du coté serveur, l application Manager est ajoutée, qui va utiliser certaines facettes de notre couche transport, comme l envoi de texte ou de données binaires. Cela, dans le but de tester la fonctionnalité du protocole établi. Il sera aussi possible d utiliser le module de connexion à la base de données, afin d effectuer certains tests. Cette application va offrir les possibilités suivantes : Envoyer le contenu d un fichier spécifique Accéder à la base de données Accéder à une autre application Réception d un fichier Dans ce premier cas, l application client va accéder à l application serveur et exécuter le service permettant de télécharger un fichier spécifique. A gauche, il est possible de voir le contenu XML de la réponse en base 64. Il est possible de décoder ce résultat grâce à la méthode fournie par la couche transport. A droite, il est possible de lire le contenu des informations base64 en clair Exécution d une requête sur la BD Maintenant, je vais tester le module d accès à la base de données. La connexion se fait de manière très simple, en précisant le nom du serveur puis la requête à effectuer. 75/105

76 7.2.4 Exécution d une requête «loopback» Cette fois, le but est de tester la fonctionnalité de la requête loopback, afin d appeler une application différente. Dans cet exemple, je vais appeler l application ParserTest disposant des mêmes fonctionnalités que le manager. Le résultat est tout à fait concluant. 7.3 Application : Démo Présentation Cette première application a pour but d utiliser certaines fonctionnalités offertes par le serveur, afin de démontrer ses fonctionnalités. Cette application va utiliser le client lourd fixe, car le client léger n était pas encore terminé lors des premiers tests. Cette application va permettre ce qui suit : Envoyer des fichiers sur le serveur Supprimer des fichiers sur le serveur Afficher des documents textes (base64) Afficher des images (base64) Utilisation 76/105

77 7.4 Application : FichePatient Présentation L application fiche patient va permettre d effectuer une interaction avec la base de données afin d obtenir des informations relatives à un patient. Elle va donc permettre de : Obtenir la liste des patients (XML) Obtenir un patient précis (Texte) Obtenir la photo d un patient (Base64) La liste de patients va utiliser la méthode d envoi XML, et sera représentée sous cette forme Requête 1. Name 2. Le nom à chercher 1. LastName 2. Le prénom 1. all (la liste entière) Réponse 1. <patients> <patient> <id>1</id> <name>probst</name> <lastname>julien</lastname> <illness>maladie</illness> </patient> <patients> Le patient précis va simplement utiliser des arguments en respectant la structure ciaprès : Requête 77/105

78 1. L id du patient Réponse 1. Dossier 2. Prénom 3. Nom 4. Date de naissance 5. Téléphone 6. Adresse 7. Location Pour sa part, lors de l envoi d une photo, la structure suivante va être respectée : Requête : 1. L id du patient Réponse : 1. La photo en base Base de données La base de données du patient va contenir les informations suivantes : Résultats Les tests seront effectués avec l application de test et les résultats seront directement copiés afin de rendre le contenu plus lisible. getpatientlist Requête : 1. LastName 2. Julien Réponse : OK 78/105

79 <transfert> <id>server ID</id> <application>fichepatient</application> <service>getpatientlist</service> <arguments> <arg> <patients> <patient> <id><![cdata[1]]></id> <name><![cdata[probst]]></name> <lastname><![cdata[julien]]></lastname> <illness><![cdata[maladie]]></illness> </patient> </patients> </arg> </arguments> </transfert>getpatientlist GetPatientList Requête : 1. 1 (=id) Réponse : OK <transfert> <id>server ID</id> <application>fichepatient</application> <service>getpatient</service> <arguments> <arg><![cdata[dossier A]]></arg> <arg><![cdata[probst]]></arg> <arg><![cdata[julien]]></arg> <arg><![cdata[6 mai 1983]]></arg> <arg><![cdata[ ]]></arg> <arg><![cdata[av.des Colleges 44]]></arg> <arg><![cdata[1009 Pully]]></arg> </arguments> </transfert> getpatientphoto Requête : 1. 1 (=id) Réponse : OK <transfert> <id>server ID</id> <application>fichepatient</application> <service>getpatientphoto</service> <arguments> <arg>6739</arg> <arg>14</arg> <arg><![cdata[/9j/4aaqskzjrgabagaaaqabaad/ 79/105

80 </arg> (14x <arg>) <arguments> </transfert> 2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSE etc (BASE64) Améliorations M.Wulliamoz va améliorer cette application en élargissant ses possibilités, dans le but de proposer une application complète permettant d effectuer une démonstration depuis la plateforme mobile. 7.5 Application : Web Présentation L interface Web représente la partie management du serveur. Elle va donc offrir certaines fonctionnalités permettant d interagir directement sur la configuration du serveur ainsi que la possibilité de réaliser divers tests. L interface Web utilise des JSP, car elles permettent de faire le pont entre notre plateforme et la page visuelle affichée chez l utilisateur. Elle va proposer les fonctionnalités suivantes : Authentification selon le fichier users.xml Ajout, Suppression d applications Journal d événements Test manuel des applications Authentification L authentification Web dispose d une fonction d authentification légère, basée sur un login et un mot de passe. Le module de sécurité local permet de contrôler les utilisateurs. Il suffit de l appeler depuis la jsp en lui passant les valeurs du formulaire HTML. L utilisateur doit être présent dans le document XML users.xml afin de passer cette phase. 80/105

81 7.5.3 Management Ce menu permet d ajouter ou de supprimer des applications de manière très simple, au moyen du module «conteneur d applications» et à son fichier de configuration containers.xml. L ajout ou la suppression d applications entraîne directement la modification du fichier de configuration et l affichage de la page, grâce à une transformation XSLT Journal d événements Le journal d événements est un simple outil permettant de stocker les différentes actions qui ont été effectuées sur le serveur. Cette page utilise le module Historique, afin de réaliser une transformation XSLT avec le fichier XML source diary.xml. 81/105

82 7.5.5 Utils Cette page est la plus intéressante car elle permet de générer des requêtes sur le serveur, afin de tester les différentes applications. Il est possible de spécifier un id, une application et le service désiré, ainsi que la liste d arguments nécessaires à son initialisation. Le résultat de retour est affiché comme une liste d arguments sur le coté droit de la page. Il est ainsi facile d interpréter les résultats. La méthode utilisée est celle proposée par la couche transport, permettant d effectuer une requête «loopback». 7.6 Conclusion Le développement de nouvelles applications est vraiment simplifié du coté du serveur, grâce aux outils mis à disposition. De plus, le résultat correspond tout à fait à celui désiré. Il est très facile d échanger des données texte, des données binaires ainsi que des fichiers tels des images ou autres, et même l envoi de données XML est simplifié via les méthodes disponibles. Au final, les applications ont pu démontrer l efficacité du serveur au niveau de la gestion des applications et des services proposés. Il est même possible, directement depuis l interface Web, d effectuer des tests sur les applications installées afin de contrôler le contenu des différentes réponses. 82/105

83 7.7 Etude : Synchronisation du PDA Présentation Une problématique intéressante a été soulevée par des banques genevoises lors d un meeting. Elle concerne le contenu des rendez-vous et des contacts du PDA. En effet, lors de voyages à l étranger, il se peut que l intégralité des informations d un PDA soient analysées par les douaniers. Pour les banques, cela pause un gros souci de confidentialité, raison pour laquelle il serait utile de proposer une solution permettant de sécuriser de manière efficace ces diverses données. Je présente une ébauche de solution réalisable à l aide de notre plateforme, une solution complète sortant du cadre de l étude. L objectif à atteindre est de synchroniser les données concernant les contacts et les rendez-vous avec le serveur et ce, de manière totalement transparente pour l utilisateur. Vu que les données seraient synchronisées avec le serveur, il serait par exemple possible, avant de passer la douane, de supprimer toutes les données sensibles du PDA. Puis, une fois le contrôle terminé, il suffirait de synchroniser le tout via une connexion gprs ou wifi. Le temps d envoi pourrait cependant s avérer relativement long sur une connexion bas débit, de même que pour le parsing de la totalité des données Problématique Lors de l élaboration, il faut prendre en compte les aspects suivants : Maintenir les données à jour Gérer les déconnexions de manière optimale Conserver une fluidité constante lors de la synchronisation Garantir la sécurité des données Afin de maintenir les données à jour, il est nécessaire d effectuer une vérification entre celles contenues sur le serveur et celles du client, ainsi que de définir quelle entité est reconnue comme étant valide dans le cas d un conflit. Le maintien des données nécessite un traitement lourd qui peut pénaliser les performances du PDA. La connexion étant généralement de mauvaise qualité, il faut s attendre à des coupures fréquentes. Afin de palier à ce problème, il faudrait générer des requêtes et des réponses courtes ou encore, savoir exactement à quel moment une coupure est intervenue de manière à reprendre le traitement dès que possible. En utilisant un parser de type pull, il est possible de lire les données dès qu elles arrivent, ce qui évite d attendre la réception de l intégralité des données pour les interpréter. Voici un exemple de déconnexion : <arg> <contact> <id>1</id> <nom>probst</nom> <prenom>julien</prenom> <tel> </tel> </contact> <contact> <id>2</id> <nom>wulliamoz</nom> >sauvegarde ID >sauvegarde nom >sauvegarde prénom >sauvegarde tel >Enregistrement du contact >sauvegarde ID >sauvegarde du nom 83/105

84 *Déconnexion* >Exception : nouvelle requête en partant après l id du dernier contact enregistrer De cette manière, un contact est enregistré dès qu il est intégralement reçu et il est aussi possible de garder un contrôle sur le suivi des données, afin de garantir la reprise lors d une déconnexion. La fluidité est à gérer depuis l application elle-même. En effet, c est elle qui va effectuer les requêtes et les interpréter de la façon dont elle le désire. Elle a donc le pouvoir de laisser ou non des ressources libres pour l utilisateur. La sécurité est prise en charge directement par la plateforme. Il n y a donc pas besoin d effectuer des tests au niveau applicatif. Solutions Pour ma part, je proposerai la solution suivante basée sur notre plateforme : Etablir la liaison entre le carnet d adresse et les rendez-vous avec Java grâce à JINI Définir une structure XML pour les rendez-vous et le carnet d adresse Lors de la synchronisation avec le serveur, il faut utiliser des fonctions permettant d identifier un contact ou un rendez-vous de manière optimale. Comme une fonction de hachage ou autre Si un rendez-vous ou un contact manque : effectuer une mise à jour grâce à un envoi de données XML respectant le schéma établi Lors d une synchronisation complète : effectuer une requête de mise à jour permettant de spécifier quelle partie recevoir. 84/105

85 8 Tests du serveur 8.1 Scénarios Présentation Le but de cette étape est de présenter différents types de scénarios pouvant se présenter lors de l exécution d une requête. Le but est de démontrer le fonctionnement du serveur dans diverses circonstances. Que ce soit quand l authentification échoue, ou que le chargement d une application soit impossible ou encore, une erreur liée directement au fonctionnement de l application. Les différents scénarios seront exécutés sur l application «FichePatient» définie par le document XML suivant : <application name="fichepatient"> <service name="getpatient"> <requestarguments type="fixed"> <arg type="string">id</arg> </requestarguments> <responsearguments type="fixed"> <arg type="string">dossierpatient</arg> <arg type="string">name</arg> <arg type="string">lastname</arg> <arg type="string">birthdate</arg> <arg type="string">phone</arg> <arg type="string">address</arg> <arg type="string">place</arg> </responsearguments> </service> </application> Scénario A : Echange correct Requête <?xml version="1.0" encoding="iso "?> <transfert> <id>admin</id> <application>fichepatient</application> <service>getpatient</service> <arguments> <arg>1</arg> </arguments> </transfert> 85/105

86 Etapes théoriques Enregistrement de l'événement Authentification locale de la requête [ok] Chargement de l'application [ok] Exécution du service de l application [ok] Résultat Tomcat Réponse <?xml version="1.0" encoding="iso "?> <transfert> <id>server ID</id> <application>fichepatient</application> <service>getpatient</service> <arguments> <arg><![cdata[dossier A]]></arg> <arg><![cdata[probst]]></arg> <arg><![cdata[julien]]></arg> <arg><![cdata[6 mai 1983]]></arg> <arg><![cdata[ ]]></arg> <arg><![cdata[av.des Colleges 44]]></arg> <arg><![cdata[1009 Pully]]></arg> </arguments> </transfert> Test : OK Scénario B : Erreur d authentification Requête <?xml version="1.0" encoding="iso "?> <transfert> <id> pirate </id> 86/105

87 <application>fichepatient</application> <service>getpatient</service> <arguments> <arg>1</arg> </arguments> </transfert> Etapes Théoriques Enregistrement de l'événement Authentification locale de la requête [Echec] Résultat Tomcat Réponse <?xml version="1.0" encoding="iso "?> <transfert> <id>server ID</id> <application>servererrorapplication</application> <service>servererrorservice</service> <arguments> <arg><![cdata[security Exception]]></arg> <arg> <![CDATA[java.lang.SecurityException: ID not found : pirate]]> </arg> </arguments> </transfert> Test : OK Scénario C : Erreur de chargement d Application Requête <?xml version="1.0" encoding="iso "?> <transfert> <id>admin</id> <application>nouvelle_application</application> <service>getpatient</service> <arguments> <arg>1</arg> </arguments> </transfert> 87/105

88 Etapes théoriques Enregistrement de l'événement Authentification locale de la requête [ok] Chargement de l'application [Echec] Résultat Tomcat Réponse <?xml version="1.0" encoding="iso "?> <transfert> <id>server ID</id> <application>servererrorapplication</application> <service>servererrorservice</service> <arguments> <arg><![cdata[application Exception]]></arg> <arg> <![CDATA[Application not found : Nouvelle_Application]]> </arg> </arguments> </transfert> Test : OK Scénario D : Erreur de chargement de service Requête <?xml version="1.0" encoding="iso "?> <transfert> <id>admin</id> <application>fichepatient</application> <service>nouveau_service</service> <arguments> <arg>1</arg> </arguments> </transfert> Etapes théoriques Enregistrement de l'événement Authentification locale de la requête [ok] 88/105

89 Chargement de l'application [ok] Exécution du service de l'application [Echec] Résultat Tomcat Réponse <?xml version="1.0" encoding="iso "?> <transfert> <id>server ID</id> <application>fichepatient</application> <service>nouveau_service</service> <arguments> <arg><![cdata[service Exception]]></arg> <arg><![cdata[service not found :nouveau_service]]></arg> </arguments> </transfert> Test : OK Scénario E : Erreur interne de service Requête <?xml version="1.0" encoding="iso "?> <transfert> <id>admin</id> <application>fichepatient</application> <service>getpatient</service> <arguments> <arg>xxxxx</arg> </arguments> </transfert> Etapes Enregistrement de l'événement 89/105

90 Authentification locale de la requête [ok] Chargement de l'application [ok] Exécution du service de l'application [Echec] Résultat Tomcat Réponse Test : OK <?xml version="1.0" encoding="iso "?> <transfert> <id>server ID</id> <application>fichepatient</application> <service>nouveau_service</service> <arguments> <arg><![cdata[service Exception]]></arg> <arg><![cdata[no Result]]></arg> </arguments> </transfert> 8.2 Analyse du transport But Le but de cette analyse est de tester l implémentation de notre protocole, en envoyant une liste d'arguments à la suite depuis le serveur, et d analyser à quel moment le client peut commencer à les lire. Grâce à cette analyse, il est possible de montrer le fonctionnement de StAX et du gain de performance qu'il peut apporter par rapport à un modèle DOM, ainsi que son fonctionnement lors de l utilisation d une plateforme à faibles performances comme le PDA. Les deux clients lourds vont être testés, à savoir le fixe et le mobile, ce qui va permettre d effectuer une comparaison entre les deux environnements et d analyser les différences de fonctionnement. N ayant pas accès à la plateforme mobile de manière constante (vu son élaboration constante), je ne vais pas pouvoir effectuer tous les tests désirés. 90/105

91 L analyse va se dérouler en trois phases, dans le but de démontrer plusieurs facettes du protocole. Premièrement, le fonctionnement du parser au niveau TCP-IP. Deuxièmement, les avantages de l implémentation actuelle par rapport aux autres. Et finalement, la comparaison entre les plateformes fixe et mobile Configuration du test N Arguments envoyés : 1000 Délai entre l'envoi des arguments : 1ms Délai entre de traitement des arguments coté client : 0ms Taille des arguments fixée à 13 caractères représentant une date Java Temps de référence : 1er Argument envoyé depuis le serveur Connexion HTTPs : SSL Qualité de la connexion : bonne, câblée Résultats Client lourd fixe Ce graphique nous montre de nombreux éléments intéressants sur le fonctionnement du parser StAX. Il est possible de remarquer la lecture par «escaliers», résultant de l'envoi du document XML via un paquet TCP de taille définie. La taille des paquets TCP est gérée par l OS. Il n est donc pas vraiment possible d interagir depuis l environnement java sur l envoi des paquets. Il faut par conséquent attendre qu un paquet TCP soit complet avant l envoi des données. Dans ce cas, le paquet TCP permet de stocker environ 50 arguments de 13 caractères encodés via SSL. Le client ne peut donc lire le contenu avant la réception du premier paquet TCP. Le grand avantage de ce parser est de permettre au client de lire les éléments le plus rapidement possible. En comparaison, un modèle DOM ne pourra pas être envoyé avant que tous les arguments ne soient initialisés. C'est à dire qu'avec un modèle DOM, on ne peut pas lire le document avant qu'il ne soit totalement reçu. Examinons maintenant 91/105

92 l impact lors de l ajout d un traitement du coté du client Résultats Stream Parser VS DOM Modification du test Délai entre de traitement des arguments coté client : 1ms La réception en streaming permet de lire le document en parallèle à son envoi. A contrario, un modèle DOM ne va pas pouvoir être lu avant la réception totale du document. De plus, son chargement en mémoire va très nettement ralentir la machine client. Dans un cas optimal le modèle DOM va avoir en tout cas 1500 ms de retard. Résultats client lourd mobile VS client lourd fixe 92/105

Institut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique

Institut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique Institut Supérieure Aux Etudes Technologiques De Nabeul Département Informatique Support de Programmation Java Préparé par Mlle Imene Sghaier 2006-2007 Chapitre 1 Introduction au langage de programmation

Plus en détail

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines)

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Module 1 : Programmer une application informatique Durée

Plus en détail

Compte Rendu d intégration d application

Compte Rendu d intégration d application ISMA 3EME ANNEE Compte Rendu d intégration d application Compte Rendu Final Maxime ESCOURBIAC Jean-Christophe SEPTIER 19/12/2011 Table des matières Table des matières... 1 Introduction... 3 1. Le SGBD:...

Plus en détail

Formation : WEbMaster

Formation : WEbMaster Formation : WEbMaster Objectif et Description : Centre Eclipse vous propose une formation complète WebMaster, vous permettant de : Utiliser dès maintenant les nouveautés du web2, ainsi alléger les besoins

Plus en détail

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application Architecture Multi-Tier Traditionnellement une application informatique est un programme exécutable sur une machine qui représente la logique de traitement des données manipulées par l application. Ces

Plus en détail

CAHIER DES CHARGES D IMPLANTATION

CAHIER DES CHARGES D IMPLANTATION CAHIER DES CHARGES D IMPLANTATION Tableau de diffusion du document Document : Cahier des Charges d Implantation EVRP Version 6 Etabli par DCSI Vérifié par Validé par Destinataires Pour information Création

Plus en détail

Hébergement de sites Web

Hébergement de sites Web Hébergement de Solutions complètes et évolutives pour l hébergement de sites Web dynamiques et de services Web sécurisés. Fonctionnalités Serveur Web Apache hautes performances Apache 1. et.0 1 avec prise

Plus en détail

Langage HTML (2 partie) <HyperText Markup Language> <tv>lt La Salle Avignon BTS IRIS</tv>

Langage HTML (2 partie) <HyperText Markup Language> <tv>lt La Salle Avignon BTS IRIS</tv> Langage HTML (2 partie) «Je n'ai fait que prendre le principe d - hypertexte et le relier au principe du TCP et du DNS et alors boum! ce fut le World Wide Web!» Tim Berners-Lee

Plus en détail

XML, PMML, SOAP. Rapport. EPITA SCIA Promo 2004 16 janvier 2003. Julien Lemoine Alexandre Thibault Nicolas Wiest-Million

XML, PMML, SOAP. Rapport. EPITA SCIA Promo 2004 16 janvier 2003. Julien Lemoine Alexandre Thibault Nicolas Wiest-Million XML, PMML, SOAP Rapport EPITA SCIA Promo 2004 16 janvier 2003 Julien Lemoine Alexandre Thibault Nicolas Wiest-Million i TABLE DES MATIÈRES Table des matières 1 XML 1 1.1 Présentation de XML.................................

Plus en détail

Java pour le Web. Cours Java - F. Michel

Java pour le Web. Cours Java - F. Michel Java pour le Web Cours Java - F. Michel Introduction à JEE 6 (ex J2EE) Historique Qu'est-ce que JEE JEE : Java Entreprise Edition (ex J2EE) 1. Une technologie outils liés au langage Java + des spécifications

Plus en détail

DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova

DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova I. Introduction Dans une période où la plasticité peut aider à réduire les coûts de développement de projets comme des applications mobile,

Plus en détail

Programmation des Applications Réparties. Parsers XML DOM et SAX

Programmation des Applications Réparties. Parsers XML DOM et SAX Programmation des Applications Réparties Parsers XML DOM et SAX Luiz Angelo Steffenel luiz-angelo.steffenel@univ-reims.fr Steffenel Programmation des Applications Réparties Master M1-2007-2008 1 Comment

Plus en détail

Mise en œuvre des serveurs d application

Mise en œuvre des serveurs d application Nancy-Université Mise en œuvre des serveurs d application UE 203d Master 1 IST-IE Printemps 2008 Master 1 IST-IE : Mise en œuvre des serveurs d application 1/54 Ces transparents, ainsi que les énoncés

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Zimbra. S I A T. T é l : ( + 2 1 6 ) 7 1 7 9 9 7 4 4. F a x : ( + 2 1 6 ) 7 1 7 9 8 3 6 3

Zimbra. S I A T. T é l : ( + 2 1 6 ) 7 1 7 9 9 7 4 4. F a x : ( + 2 1 6 ) 7 1 7 9 8 3 6 3 Zimbra Zimbra est un logiciel serveur collaboratif qui permet à ses utilisateurs de stocker, organiser et partager rendez-vous, contacts, courriels, liens, documents et plus. Zimbra est un logiciel développé

Plus en détail

Éléments de programmation et introduction à Java

Éléments de programmation et introduction à Java Éléments de programmation et introduction à Java Jean-Baptiste Vioix (jean-baptiste.vioix@iut-dijon.u-bourgogne.fr) IUT de Dijon-Auxerre - LE2I http://jb.vioix.free.fr 1-20 Les différents langages informatiques

Plus en détail

Applications distribuées: le retour du client "riche"

Applications distribuées: le retour du client riche Applications distribuées: le retour du client "riche" Markus Jaton, Olivier Liechti Olivier Liechti / Markus Jaton /1 Agenda Java a-t-il un avenir sur le "desktop"? Swing vs. AJAX: idées préconçues? Architecture

Plus en détail

7.0 Guide de la solution Portable sans fil

7.0 Guide de la solution Portable sans fil 7.0 Guide de la solution Portable sans fil Copyright 2010 Sage Technologies Limited, éditeur de ce produit. Tous droits réservés. Il est interdit de copier, photocopier, reproduire, traduire, copier sur

Plus en détail

Livre Blanc WebSphere Transcoding Publisher

Livre Blanc WebSphere Transcoding Publisher Livre Blanc WebSphere Transcoding Publisher Introduction WebSphere Transcoding Publisher vous permet d'offrir aux utilisateurs des informations Web adaptées à leurs besoins. Il vous permet, par exemple,

Plus en détail

Technologies du Web. Créer et héberger un site Web. Pierre Senellart. Page 1 / 26 Licence de droits d usage

Technologies du Web. Créer et héberger un site Web. Pierre Senellart. Page 1 / 26 Licence de droits d usage Technologies du Web Créer et héberger un site Web Page 1 / 26 Plan Planification Choisir une solution d hébergement Administration Développement du site Page 2 / 26 Cahier des charges Objectifs du site

Plus en détail

Bien architecturer une application REST

Bien architecturer une application REST Olivier Gutknecht Bien architecturer une application REST Avec la contribution de Jean Zundel Ce livre traite exactement du sujet suivant : comment faire pour que les services web et les programmes qui

Plus en détail

Architecture JEE. Objectifs attendus. Serveurs d applications JEE. Architectures JEE Normes JEE. Systèmes distribués

Architecture JEE. Objectifs attendus. Serveurs d applications JEE. Architectures JEE Normes JEE. Systèmes distribués Architecture JEE. Objectifs attendus Serveurs d applications JEE Systèmes distribués Architectures JEE Normes JEE couches logicielles, n-tiers framework JEE et design patterns 2007/02/28 Eric Hébert.eheb@yahoo.fr

Plus en détail

les techniques d'extraction, les formulaires et intégration dans un site WEB

les techniques d'extraction, les formulaires et intégration dans un site WEB les techniques d'extraction, les formulaires et intégration dans un site WEB Edyta Bellouni MSHS-T, UMS838 Plan L extraction des données pour un site en ligne Architecture et techniques Les différents

Plus en détail

XML par la pratique Bases indispensables, concepts et cas pratiques (3ième édition)

XML par la pratique Bases indispensables, concepts et cas pratiques (3ième édition) Présentation du langage XML 1. De SGML à XML 17 2. Les bases de XML 18 2.1 Rappel sur HTML 18 2.2 Votre premier document XML 19 2.3 Les avantages de XML 21 3. La syntaxe XML 21 3.1 La première ligne du

Plus en détail

Programmation Web. Madalina Croitoru IUT Montpellier

Programmation Web. Madalina Croitoru IUT Montpellier Programmation Web Madalina Croitoru IUT Montpellier Organisation du cours 4 semaines 4 ½ h / semaine: 2heures cours 3 ½ heures TP Notation: continue interrogation cours + rendu à la fin de chaque séance

Plus en détail

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation Base de données S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Présentation du module Contenu général Notion de bases de données Fondements / Conception Utilisation :

Plus en détail

1 JBoss Entreprise Middleware

1 JBoss Entreprise Middleware 1 JBoss Entreprise Middleware Les produits de la gamme JBoss Entreprise Middleware forment une suite de logiciels open source permettant de construire, déployer, intégrer, gérer et présenter des applications

Plus en détail

Java et les bases de données: JDBC: Java DataBase Connectivity SQLJ: Embedded SQL in Java. Michel Bonjour http://cuiwww.unige.

Java et les bases de données: JDBC: Java DataBase Connectivity SQLJ: Embedded SQL in Java. Michel Bonjour http://cuiwww.unige. : JDBC: Java DataBase Connectivity SQLJ: Embedded SQL in Java Michel Bonjour http://cuiwww.unige.ch/~bonjour Plan JDBC: API bas niveau pour l accès aux BD (SQL) - Introduction - JDBC et : Java, ODBC, SQL

Plus en détail

Technologies Web. Ludovic Denoyer Sylvain Lamprier Mohamed Amine Baazizi Gabriella Contardo Narcisse Nya. Université Pierre et Marie Curie

Technologies Web. Ludovic Denoyer Sylvain Lamprier Mohamed Amine Baazizi Gabriella Contardo Narcisse Nya. Université Pierre et Marie Curie 1 / 22 Technologies Web Ludovic Denoyer Sylvain Lamprier Mohamed Amine Baazizi Gabriella Contardo Narcisse Nya Université Pierre et Marie Curie Rappel 2 / 22 Problématique Quelles technologies utiliser

Plus en détail

THEME PROJET D ELABORATION D UNE BASE DE DONNEES SOUS LE SERVEUR MYSQL

THEME PROJET D ELABORATION D UNE BASE DE DONNEES SOUS LE SERVEUR MYSQL . THEME PROJET D ELABORATION D UNE BASE DE DONNEES SOUS LE SERVEUR MYSQL Mr MEZRED MOHAMED Ingénieur météorologue INTRODUCTION Il existe de nombreuses manières de construire une base de données. En effet,

Plus en détail

4. SERVICES WEB REST 46

4. SERVICES WEB REST 46 4. SERVICES WEB REST 46 REST REST acronyme de REpresentational State Transfert Concept introduit en 2000 dans la thèse de Roy FIELDING Est un style d architecture inspiré de l architecture WEB En 2010,

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Dispositif e-learning déployé sur les postes de travail

Dispositif e-learning déployé sur les postes de travail Résumé : Ce document fait l inventaire du matériel et des moyens nécessaires à la production de sessions de formation à distance à partir des postes de travail des salariés bénéficiant d une connexion

Plus en détail

Qu est-ce que ArcGIS?

Qu est-ce que ArcGIS? 2 Qu est-ce que ArcGIS? LE SIG ÉVOLUE Depuis de nombreuses années, la technologie SIG améliore la communication, la collaboration et la prise de décision, la gestion des ressources et des infrastructures,

Plus en détail

Avantic Software Présentation de solutions GED pour mobiles (Gestion Electronique de Documents)

Avantic Software Présentation de solutions GED pour mobiles (Gestion Electronique de Documents) Avantic Software Présentation de solutions GED pour mobiles (Gestion Electronique de Documents) Les prestations et les applications présentées : Apportent un accès et une mise à jour simplifiés aux documents

Plus en détail

Auteur LARDOUX Guillaume Contact guillaume.lardoux@epitech.eu Année 2014 DEVELOPPEMENT MOBILE AVEC CORDOVA

Auteur LARDOUX Guillaume Contact guillaume.lardoux@epitech.eu Année 2014 DEVELOPPEMENT MOBILE AVEC CORDOVA Auteur LARDOUX Guillaume Contact guillaume.lardoux@epitech.eu Année 2014 DEVELOPPEMENT MOBILE AVEC CORDOVA Sommaire 1. Introduction 2. Installation 3. Fonctionnement 4. Développement 5. Démonstration 2

Plus en détail

Programmation Web. Introduction

Programmation Web. Introduction Programmation Web Introduction 1 Introduction 10 séances 1 h cours + 1h TD Notes : contrôle continu DS 1 TP : note de groupe : rapport + code source + démo TD : note personnelle (=0 si 2 absences non justifiées)

Plus en détail

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement COREYE CACHE Solution d absorption de charge pour une disponibilité et une performance optimales des applications Web En bref Architecture technique La plateforme Coreye Cache délivre la majeure partie

Plus en détail

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

SQL Server Installation Center et SQL Server Management Studio

SQL Server Installation Center et SQL Server Management Studio SQL Server Installation Center et SQL Server Management Studio Version 1.0 Grégory CASANOVA 2 SQL Server Installation Center et SQL Server Management Studio [03/07/09] Sommaire 1 Installation de SQL Server

Plus en détail

Petite définition : Présentation :

Petite définition : Présentation : Petite définition : Le Web 2.0 est une technologie qui permet la création de réseaux sociaux, de communautés, via divers produits (des sites communautaires, des blogs, des forums, des wiki ), qui vise

Plus en détail

Les Architectures Orientées Services (SOA)

Les Architectures Orientées Services (SOA) Les Architectures Orientées Services (SOA) Ulrich Duvent Guillaume Ansel Université du Littoral Côte d Opale 50, Rue Ferdinand Buisson BP 699 62228 Calais Cedex Téléphone (33) 03.21.46.36.92 Télécopie

Plus en détail

Refonte front-office / back-office - Architecture & Conception -

Refonte front-office / back-office - Architecture & Conception - Refonte front-office / back-office - Architecture & Conception - GLG204 - Architectures Logicielles Java 2008/2009 Nom : Cédric Poisson Matricule : 06-49012 Version : 1.0 Jeudi 28 mai 2009 1 / 23 Table

Plus en détail

Cours 3 : L'ordinateur

Cours 3 : L'ordinateur Cours 3 : L'ordinateur Abdelkrim Zehioua 2éme année Licence Gestion Faculté des sciences Économiques et sciences de Gestion Université A, Mehri - Constantine 2 Plan du cours 1.Définitions de l'ordinateur

Plus en détail

INTERNET est un RESEAU D ORDINATEURS RELIES ENTRE EUX A L ECHELLE PLANETAIRE. Internet : interconnexion de réseaux (anglais : net = réseau)

INTERNET est un RESEAU D ORDINATEURS RELIES ENTRE EUX A L ECHELLE PLANETAIRE. Internet : interconnexion de réseaux (anglais : net = réseau) CS WEB Ch 1 Introduction I. INTRODUCTION... 1 A. INTERNET INTERCONNEXION DE RESEAUX... 1 B. LE «WEB» LA TOILE, INTERCONNEXION DE SITES WEB... 2 C. L URL : LOCALISER DES RESSOURCES SUR L INTERNET... 2 D.

Plus en détail

Introduction à Microsoft InfoPath 2010

Introduction à Microsoft InfoPath 2010 Introduction à Microsoft InfoPath 2010 Couplé à Microsoft SharePoint Designer 2010, InfoPath 2010 simplifie la création de solutions de bout en bout sur SharePoint Server 2010, qui contiennent des formulaires

Plus en détail

Développer des Applications Internet Riches (RIA) avec les API d ArcGIS Server. Sébastien Boutard Thomas David

Développer des Applications Internet Riches (RIA) avec les API d ArcGIS Server. Sébastien Boutard Thomas David Développer des Applications Internet Riches (RIA) avec les API d ArcGIS Server Sébastien Boutard Thomas David Le plan de la présentation Petit retour sur les environnements de développement ArcGIS Server

Plus en détail

Tutoriel: Création d'un Web service en C++ avec WebContentC++Framework

Tutoriel: Création d'un Web service en C++ avec WebContentC++Framework Tutoriel: Création d'un Web service en C++ avec WebContentC++Framework Gaël de Chalendar CEA LIST / LIC2M Journée de Présentation des Technologies WebContent INSTN 14/12/2009 Présentation de gsoap Plan

Plus en détail

Architecture Orientée Service, JSON et API REST

Architecture Orientée Service, JSON et API REST UPMC 3 février 2015 Précedemment, en LI328 Architecture générale du projet Programmation serveur Servlet/TOMCAT Aujourd hui Quelques mots sur les SOA API - REST Le format JSON API - REST et Servlet API

Plus en détail

Formation en Logiciels Libres. Fiche d inscription

Formation en Logiciels Libres. Fiche d inscription République Tunisienne Ministère de l'industrie et la Technologie - Secrétariat d'état de la Technologie Unité des Logiciels Libres Formation en Logiciels Libres Fiche d inscription (Une fiche par candidat)

Plus en détail

Architectures web/bases de données

Architectures web/bases de données Architectures web/bases de données I - Page web simple : HTML statique Le code HTML est le langage de base pour concevoir des pages destinées à être publiées sur le réseau Internet ou intranet. Ce n'est

Plus en détail

Quel logiciel DE CRM choisir pour votre force de vente terrain?

Quel logiciel DE CRM choisir pour votre force de vente terrain? Quel logiciel DE CRM choisir pour votre force de vente terrain? plusieurs études démontrent que les projets CRM sont des échecs dans 40 à 80% des cas. Les principales causes d échec sont : Le rejet par

Plus en détail

DÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques

DÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques livre blanc DÉVELOPPEMENT INFONUAGIQUE MEILLEURES PRATIQUES ET APPLICATIONS DE SOUTIEN DÉVELOPPEMENT INFONUAGIQUE - MEILLEURES PRATIQUES 1 Les solutions infonuagiques sont de plus en plus présentes sur

Plus en détail

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

http://www.linea21.com info@linea21.com

http://www.linea21.com info@linea21.com Livre blanc http://www.linea21.com SOMMAIRE SOMMAIRE... 1 PRESENTATION... 2 TIC ET DEVELOPPEMENT DURABLE... 3 PUBLIER ET COMMUNIQUER... 4 LES GROUPES DE TRAVAIL...5 LE TABLEAU DE BORD PERSONNALISE... 6

Plus en détail

Plate formes mobiles. Utilisation. Contexte 9/29/2010 IFC 2. Deux utilisations assez distinctes :

Plate formes mobiles. Utilisation. Contexte 9/29/2010 IFC 2. Deux utilisations assez distinctes : Plate formes mobiles IFC 2 Markus Jaton Utilisation Deux utilisations assez distinctes : Téléphones évolués (Nokia, Motorola) Smartphones (Apple,, Windows) La téléphonie est en stagnation, alors que les

Plus en détail

Fiche méthodologique Rédiger un cahier des charges

Fiche méthodologique Rédiger un cahier des charges Fiche méthodologique Rédiger un cahier des charges Plan de la fiche : 1 : Présentation de la fiche 2 : Introduction : les grands principes 3 : Contenu, 1 : positionnement et objectifs du projet 4 : Contenu,

Plus en détail

Bénéficiez d'un large choix d'applications novatrices et éprouvées basées sur les systèmes d'exploitation i5/os, Linux, AIX 5L et Microsoft Windows.

Bénéficiez d'un large choix d'applications novatrices et éprouvées basées sur les systèmes d'exploitation i5/os, Linux, AIX 5L et Microsoft Windows. 1. Le nouveau eserver i5 en bref Gérez plusieurs systèmes d'exploitation et environnements d'applications sur un seul serveur pour simplifier votre infrastructure et réduire les frais de gestion Simplifiez

Plus en détail

Application web de gestion de comptes en banques

Application web de gestion de comptes en banques Application web de gestion de comptes en banques Objectif Réaliser une application Web permettant à un client de gérer ses comptes en banque Diagramme de cas d'utilisation 1 Les cas d'utilisation Connexion

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

Modernisation et gestion de portefeuilles d applications bancaires

Modernisation et gestion de portefeuilles d applications bancaires Modernisation et gestion de portefeuilles d applications bancaires Principaux défis et facteurs de réussite Dans le cadre de leurs plans stratégiques à long terme, les banques cherchent à tirer profit

Plus en détail

Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2.

Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2. Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2. Le test aux limites 3. Méthode 2.1. Pré-requis 2.2. Préparation des

Plus en détail

Tarification comparative pour l'industrie des assurances

Tarification comparative pour l'industrie des assurances Étude technique Tarification comparative pour l'industrie des assurances Les technologies de l'information appliquées aux solutions d'affaires Groupe CGI inc., 2004. Tous droits réservés. Aucune partie

Plus en détail

Chapitre I Notions de base et outils de travail

Chapitre I Notions de base et outils de travail Chapitre I Notions de base et outils de travail Objectifs Connaître les principes fondateurs et l historique du langage Java S informer des principales caractéristiques du langage Java Connaître l environnement

Plus en détail

Application Web et J2EE

Application Web et J2EE Application Web et J2EE Servlet, JSP, Persistence, Méthodologie Pierre Gambarotto Département Informatique et Math appli ENSEEIHT Plan Introduction 1 Introduction Objectfis

Plus en détail

Programmation de services sensibles au contexte en téléphonie sur IP

Programmation de services sensibles au contexte en téléphonie sur IP Programmation de services sensibles au contexte en téléphonie sur IP Présentation de mémoire Grégory Estienne Sous la supervision du Dr. Luigi Logrippo Introduction La téléphonie sur IP comme support à

Plus en détail

Sommaire. Systèmes d Exploitation... 3. Intégration Sage 100 Sage CRM... 3. Disponibilité Client... 3. Bases de données... 3

Sommaire. Systèmes d Exploitation... 3. Intégration Sage 100 Sage CRM... 3. Disponibilité Client... 3. Bases de données... 3 Communiqué de Lancement Sage CRM v. 6.5 Editions Standard et Avancée Sommaire Systèmes d Exploitation... 3 Intégration Sage 100 Sage CRM... 3 Disponibilité Client... 3 Bases de données... 3 Nouveautés

Plus en détail

Surveiller et contrôler vos applications à travers le Web

Surveiller et contrôler vos applications à travers le Web Surveiller et contrôler vos applications à travers le Web Valérie HELLEQUIN Ingénieur d application Internet permet aujourd hui la diffusion d informations et de ressources que chaque utilisateur peut

Plus en détail

Utiliser Access ou Excel pour gérer vos données

Utiliser Access ou Excel pour gérer vos données Page 1 of 5 Microsoft Office Access Utiliser Access ou Excel pour gérer vos données S'applique à : Microsoft Office Access 2007 Masquer tout Les programmes de feuilles de calcul automatisées, tels que

Plus en détail

Serveur de travail collaboratif Michaël Hoste -

Serveur de travail collaboratif Michaël Hoste - Serveur de travail collaboratif Michaël Hoste - Table des matières 1. Qu'est ce qu'un serveur de travail collaboratif?...2 2. Pourquoi ce projet?...2 3. Possibilités d'utilisation dans le cadre de l'université...3

Plus en détail

Devenez un véritable développeur web en 3 mois!

Devenez un véritable développeur web en 3 mois! Devenez un véritable développeur web en 3 mois! L objectif de la 3W Academy est de former des petits groupes d élèves au développement de sites web dynamiques ainsi qu à la création d applications web

Plus en détail

SITE WEB E-COMMERCE ET VENTE A DISTANCE

SITE WEB E-COMMERCE ET VENTE A DISTANCE Développement d une application JAVA EE SITE WEB E-COMMERCE ET VENTE A DISTANCE PLAN PROJET Binôme ou monôme (B/M): M Nom & Prénom : AIT NASSER Btissam Email : aitnasser.btissam123@gmail.com GSM : Organisme

Plus en détail

Qlik Sense Desktop. Qlik Sense 2.0.2 Copyright 1993-2015 QlikTech International AB. Tous droits réservés.

Qlik Sense Desktop. Qlik Sense 2.0.2 Copyright 1993-2015 QlikTech International AB. Tous droits réservés. Qlik Sense Desktop Qlik Sense 2.0.2 Copyright 1993-2015 QlikTech International AB. Tous droits réservés. Copyright 1993-2015 QlikTech International AB. Tous droits réservés. Qlik, QlikTech, Qlik Sense,

Plus en détail

Avant-propos 1. Avant-propos...3 2. Organisation du guide...3 3. À qui s'adresse ce guide?...4

Avant-propos 1. Avant-propos...3 2. Organisation du guide...3 3. À qui s'adresse ce guide?...4 Les exemples cités tout au long de cet ouvrage sont téléchargeables à l'adresse suivante : http://www.editions-eni.fr. Saisissez la référence ENI de l'ouvrage EP5EJAV dans la zone de recherche et validez.

Plus en détail

Configuration matérielle et logicielle requise et prérequis de formation pour le SYGADE 6

Configuration matérielle et logicielle requise et prérequis de formation pour le SYGADE 6 Configuration matérielle et logicielle requise et prérequis de formation pour le SYGADE 6 DMFAS6/HardwareSoftware/V4 Octobre 2013 2 Configuration matérielle et logicielle requise et prérequis de formation

Plus en détail

L essentiel. Coopérative, flexible, très performante : la plateforme Engineering Base. web aucotec.com

L essentiel. Coopérative, flexible, très performante : la plateforme Engineering Base. web aucotec.com L essentiel Coopérative, flexible, très performante : la plateforme Engineering Base web aucotec.com Les défis La globalisation des structures d ingénierie avec le travail en réseau sur des sites dispersés

Plus en détail

Java et les bases de données

Java et les bases de données Michel Bonjour http://cuiwww.unige.ch/~bonjour CENTRE UNIVERSITAIRE D INFORMATIQUE UNIVERSITE DE GENEVE Plan Introduction JDBC: API SQL pour Java - JDBC, Java, ODBC, SQL - Architecture, interfaces, exemples

Plus en détail

PRIMAVERA P6 ENTERPRISE PROJECT PORTFOLIO MANAGEMENT WEB SERVICES

PRIMAVERA P6 ENTERPRISE PROJECT PORTFOLIO MANAGEMENT WEB SERVICES PRIMAVERA P6 ENTERPRISE PROJECT PORTFOLIO MANAGEMENT WEB SERVICES DÉCOUVREZ DES POSSIBILITÉS ILLIMITÉES GRÂCE A L INTÉGRATION À DES SYSTÈMES D ENTREPRISE EXISTANTS FONCTIONNALITÉS Connectivité des systèmes

Plus en détail

Vulgarisation Java EE Java EE, c est quoi?

Vulgarisation Java EE Java EE, c est quoi? Paris, le 1 Février 2012 Vulgarisation Java EE Java EE, c est quoi? Sommaire Qu est ce que Java? Types d applications Java Environnements Java Versions de Java Java EE, c est quoi finalement? Standards

Plus en détail

Point sur les solutions de développement d apps pour les périphériques mobiles

Point sur les solutions de développement d apps pour les périphériques mobiles Point sur les solutions de développement d apps pour les périphériques mobiles Par Hugues MEUNIER 1. INTRODUCTION a. Une notion importante : le responsive web design Nous sommes en train de vivre une nouvelle

Plus en détail

PG208, Projet n 3 : Serveur HTTP évolué

PG208, Projet n 3 : Serveur HTTP évolué PG208, Projet n 3 : Serveur HTTP évolué Bertrand LE GAL, Serge BOUTER et Clément VUCHENER Filière électronique 2 eme année - Année universitaire 2011-2012 1 Introduction 1.1 Objectif du projet L objectif

Plus en détail

Chapitre 01 Généralités

Chapitre 01 Généralités Chapitre 01 Généralités I- Introduction II- Windows Server 2008 R2 1. Historique 2. Caractéristiques 3. Les différentes éditions 4. Outils d administration 4.1. Gestionnaire de serveur 4.2. Utilisateurs

Plus en détail

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Version utilisée pour la Debian : 7.7 Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Caractéristiques de bases : Un service web (ou service de la toile) est

Plus en détail

2 Grad Info Soir Langage C++ Juin 2007. Projet BANQUE

2 Grad Info Soir Langage C++ Juin 2007. Projet BANQUE 2 Grad Info Soir Langage C++ Juin 2007 Projet BANQUE 1. Explications L'examen comprend un projet à réaliser à domicile et à documenter : - structure des données, - objets utilisés, - relations de dépendance

Plus en détail

Le test automatisé des applications web modernes

Le test automatisé des applications web modernes Le test automatisé des applications web modernes Résumé : Aujourd hui, les applications Web sont développées au moyen de différentes technologies AJAX et Web 2.0. Des outils nouveaux et puissants offrent

Plus en détail

Projet de Veille Technologique

Projet de Veille Technologique Projet de Veille Technologique Programmation carte à puce - JavaCard Ing. MZOUGHI Ines (i.mzoughi@gmail.com) Dr. MAHMOUDI Ramzi (mahmoudr@esiee.fr) TEST Sommaire Programmation JavaCard Les prérequis...

Plus en détail

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e :

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e : CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE Projet 2 Gestion des services enseignants G r o u p e : B E L G H I T Y a s m i n e S A N C H E Z - D U B R O N T Y u r i f e r M O N T A Z E R S i

Plus en détail

Chapitre 3 : Les technologies de la communication. I- Les TIC de la PME

Chapitre 3 : Les technologies de la communication. I- Les TIC de la PME Chapitre 3 : Les technologies de la communication I- Les TIC de la PME La PME est soumise a deux grandes évolutions du domaine des TIC. D une part la nomadisation des outils et d autres part le développement

Plus en détail

Qu'est-ce que le BPM?

Qu'est-ce que le BPM? Qu'est-ce que le BPM? Le BPM (Business Process Management) n'est pas seulement une technologie mais, dans les grandes lignes, une discipline de gestion d'entreprise qui s'occupe des procédures contribuant

Plus en détail

FileMaker 13. Guide ODBC et JDBC

FileMaker 13. Guide ODBC et JDBC FileMaker 13 Guide ODBC et JDBC 2004-2013 FileMaker, Inc. Tous droits réservés. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, Californie 95054 FileMaker et Bento sont des marques commerciales de

Plus en détail

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. EJB : les fondamentaux. Enterprise Java Bean. Enterprise Java Bean.

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. EJB : les fondamentaux. Enterprise Java Bean. Enterprise Java Bean. Plan du cours 2 Introduction générale : fondamentaux : les fondamentaux Michel Buffa (buffa@unice.fr), UNSA 2002, modifié par Richard Grin (version 1.1, 21/11/11), avec emprunts aux supports de Maxime

Plus en détail

Java 7 Les fondamentaux du langage Java

Java 7 Les fondamentaux du langage Java 184 Java 7 Les fondamentaux du langage Java 1.1 Les bibliothèques graphiques Le langage Java propose deux bibliothèques dédiées à la conception d'interfaces graphiques. La bibliothèque AWT et la bibliothèque

Plus en détail

WEB & DÉVELOPPEMENT LES BASES DU WEB LE LANGAGE HTML FEUILLES DE STYLES CSS HISTORIQUE D INTERNET ET DU WEB LES DIFFÉRENTS LANGAGES

WEB & DÉVELOPPEMENT LES BASES DU WEB LE LANGAGE HTML FEUILLES DE STYLES CSS HISTORIQUE D INTERNET ET DU WEB LES DIFFÉRENTS LANGAGES WEB & DÉVELOPPEMENT LES BASES DU WEB HISTORIQUE D INTERNET ET DU WEB LES DIFFÉRENTS LANGAGES LE LANGAGE HTML STRUCTURE D UNE PAGE En-tête et corps Syntaxe INSÉRER DES CONTENUS Texte : formatage (titre,

Plus en détail

emuseum PUBLIEZ VOS COLLECTIONS SUR INTERNET Pourquoi choisir emuseum? Intégration facile avec TMS Puissante fonction de recherche

emuseum PUBLIEZ VOS COLLECTIONS SUR INTERNET Pourquoi choisir emuseum? Intégration facile avec TMS Puissante fonction de recherche emuseum emuseum PUBLIEZ VOS COLLECTIONS SUR INTERNET emuseum est un système de publication Web qui s intègre de façon transparente avec TMS pour la publication d informations sur Internet et les appareils

Plus en détail

Systèmes d'informations historique et mutations

Systèmes d'informations historique et mutations Systèmes d'informations historique et mutations Christophe Turbout SAIC-CERTIC Université de Caen Basse-Normandie Systèmes d'informations : Historique et mutations - Christophe Turbout SAIC-CERTIC UCBN

Plus en détail

Programme scientifique Majeure ARCHITECTURE DES SYSTEMES D INFORMATION. Mentions Ingénierie des Systèmes d Information Business Intelligence

Programme scientifique Majeure ARCHITECTURE DES SYSTEMES D INFORMATION. Mentions Ingénierie des Systèmes d Information Business Intelligence É C O L E D I N G É N I E U R D E S T E C H N O L O G I E S D E L I N F O R M A T I O N E T D E L A C O M M U N I C A T I O N Programme scientifique Majeure ARCHITECTURE DES SYSTEMES D INFORMATION Mentions

Plus en détail

BES WEBDEVELOPER ACTIVITÉ RÔLE

BES WEBDEVELOPER ACTIVITÉ RÔLE BES WEBDEVELOPER ACTIVITÉ Le web developer participe aux activités concernant la conception, la réalisation, la mise à jour, la maintenance et l évolution d applications internet/intranet statiques et

Plus en détail

EXTENSION de Microsoft Dynamics CRM 2013. Réf FR 80452

EXTENSION de Microsoft Dynamics CRM 2013. Réf FR 80452 EXTENSION de Microsoft Dynamics CRM 2013 Réf FR 80452 Durée : 3 jours A propos de ce cours : Ce cours offre une information interactive et détaillée sur le développement d extensions pour Microsoft Dynamics

Plus en détail

Types d applications pour la persistance. Outils de développement. Base de données préexistante? 3 modèles. Variantes avec passerelles

Types d applications pour la persistance. Outils de développement. Base de données préexistante? 3 modèles. Variantes avec passerelles Types d applications pour la persistance Université de Nice Sophia-Antipolis Version 0.9 28/8/07 Richard Grin Toutes les applications n ont pas une complexité qui nécessite une architecture n- tiers Ce

Plus en détail