Compte rendu de réunion PlugDB 3 mai 2007, à l’ENST Participants : Gemalto : Jean-Jacques Vandewalle INRIA : Nicolas Anciaux (rédacteur), Luc Bouganim, Philippe Pucheral Ordre du jour : 1) Caractéristiques de la plateforme matérielle SSMSC 2) Définition de use-cases 3) Caractérisation de l’architecture/communications internes/externes 1) Plateforme S3J9CH La documentation a été demandée par P. Pucheral à Samsung (Zanghee Cho), mail resté sans réponse. J-J Vandewalle essaye de les contacter de son coté. cpu = ARM 7/SC200TDMI Mémoire interne, directement adressable par le cpu : RAM 28KB FLASH NOR 512KB Mémoire externe, accessible via la FTL : FLASH NAND 128MB ou 256MB IOs : 3 contrôleurs disponibles APDU, ISO 7816-4 USB MMC Génération suivante : S3J9CI cpu = ARM 7/SC100TDMI Mémoire interne, directement adressable par le cpu : RAM 48KB FLASH NOR 768KB Mémoire externe, accessible via la FTL : FLASH NAND 128MB à 256MB IOs : comme S3J9CH 2) Système d’exploitation « Cigale » Pour l’instant, nous travaillons à Meudon sur l’OS Zeplateform. L’OS choisi pour la plateforme PlugDB est « Cigale », ce choix de Gemalto est confirmé par Jean-Jacques. Le passage de code développé par SMIS pour Zeplateform vers Cigale peut-t-il poser problème ? Les lib C sont les mêmes (API identiques), donc a priori, seule la modification du link script est nécessaire. Le portage ne devrait pas poser problème. Allocation mémoire avec « Cigale » Cigale est un OS orienté objet (OMem) La persistance des objets (mise en NOR) est obtenue par « atteignabilité » (dite aussi persistance orthogonale) à partir d’un ensemble de racines de persistance fixées au départ. Les classes, donc les variables statiques, sont mises en NOR. Affecter un objet à une variable statique entraîne sa mise en NOR. Il y a un garbage collector (GC) pour les objets. Le GC est « mark and swip », non déplaçant et non compactant. Pour accéder à la NOR, Il faut voir d’après nos besoins si on utilise le système ou des API plus ou moins bas niveau (ex. on peut se mettre au niveau du BSP, Board Support Package, il gère l’arrachement). Si on passe par la gestion objet du système, on perd le contrôle (i) sur la taille réelle des structures (ex : « headers » ajoutés), et (ii) sur le placement en NOR (ex : la structure tombe sur une frontière de page). VM (.NET, JVM) API OMem BSP Hardware, API samsung Pour des infos complémentaires : contacter éventuellement Laurent Lagosanto pour voir à quel niveau se placer pour accéder la NVM. 3) Use case Philippe : rappel des réunions précédentes - 2 réunions plénières sans Gemalto - 1 réunion sans SMIS Description des informations du dossier (fichier excel – cf web). La partie tableau de bord est considérée par les partenaires comme une valeur ajoutée importante (en plus de l’informatisation du dossier) 4) Architecture envisagée Description de l’architecture utilisée pour PicoDBMS Terminal : application, JDBC, PC/SC Carte à puce : DBMS Une question ici : où mettre le JDBC ? Description des différentes plateformes Java CLDC : déclinaison de Java pour les téléphones Javacard : pour carte à puce J2EE : pour gros serveur d’appli (Servlets, JSP, EJB) J2SE : pour PC J2ME : pour les mobiles o Config CDC/Config CLDC Serveur Web de Gemalto : Ecrit en Java o Se programme avec le modèle de programmation Java Servlet o A terme : Servlet 2.4 Il y a une Web App comme pour Tomcat (on charge des .war = web archive) Conforme à terme à la spec. Javacard 3.0 (i.e., servlet, etc.) La connexion se fait par GCF (Generic connexion framework) Apparté : Fonctionnement des servlets Requête type : http://.../do?param. En tant que programmeur, on écrit une classe qui implémente Servlet (classe abstraite ou interface). Ex : Class MyServlet extends HTTPServlet { doGet ( HTTPRequest req, HTTPResponse resp){ req.getParameters() … pw = rep.getPrintWriter(…) pw.write(“<html><… <ul>callSGBD</.>) } } Avec JSP : les appels (code source) sont dans le html Ici : les appels sont dans le Servlet… Remarque : c’est la méthode “brute force”… Une méthode moins brute force : Client http get main.html Liste médecins <img source=photo> fichier Renvoie le fichier <script source=main.js photo Code Javascript Dans le Javascript : XHR (Xml Http Request) Sur certains évènements (clicks) envoie une requête http get (get http://.../do?...) L’appel rentre dans la méthode doGet(…) (voir avant) MAIS : ne renvoie pas du html, mais le résultat de la requête dans un format « pratique » Ex. de format pratique : JSON (Format Javascript sous la forme a=( (nom, valeur)… ) ; on récupère directement chaque valeur dans une variable Javascript. Communications entre l’extérieur et le chip : TCP/UDP -----------IP -----------Datalink (couches physiques, modèle OSI) - ISO 7816 - MMC - USB Remarque importante : Sur le client, il faut déployer un driver, même avec le serveur web. L’installation se déroule en mode administrateur. A terme (peut-être seulement quelques mois) cette contrainte pourrait disparaître. Architecture envisagée pour le projet PlugDB : La question est de savoir comment faire communiquer les applications avec le SGBD. Idéalement, on voudrait passer par JDBC pour assurer la portabilité mais le driver est complexe car il contient notamment le parsing SQL. - Solution statique : la carte contient l’application + driver JDBC, le tout est chargé sur le client puis installé. La carte exécute le code du SGBD qui est invoqué « à la PicoDBMS » (i.e., API ad-hoc). C’est simple mais peu élégant et peu performant (pour le chargement/install). - Solution dynamique : l’application communique avec un driver JDBC embarqué. C’est la solution décrite ci-dessous. Client : - browser (+ driver éventuellement nécessaire pour communiquer avec la carte) - Javascript Carte : HTTPServeur ---------------TCP/IP -------------Des pages HTML qui sont téléchargées et entraînent une exécution sur le client (java script). Elles contiennent - HTML + Javascript - XHR - Response handler (récupération de la réponse dans le format "pratique" utilisé) -------------Des Servlets qui gèrent les appels HXR et font les appels JDBC qui sont exécutées dans la clé -------------JDBC (light) -------------Driver PlugDB / Driver X / … -------------DBMS PlugDB / … Dans le cas où le driver JDBC ne tiendrait pas sur le chip, on peut découper le code applicatif en deux parties : (1) servlets application, (2) procédures d’accès aux données. Ces dernières sont pré-parsées et pré-compilées. Elles communiquent avec le SGBD avec un protocole « à la PicoDBMS » et sont donc dépendantes du SGBD. Par contre, la partie application reste indépendante du SGBD, facilitant les déploiements sur des cartes équipés de SGBD différents. La communication entre application et procédures d’accès aux données pourraient se faire par un JDBC ultra-light, type invocation de procédures stockées. Exemple de caractéristiques pour la plateforme au niveau de la consommation de ressources : (NB : c’est un autre chip, donc ne pas trop se fier à ces valeurs…) RAM = 16K ROM = 524K EEPROM = 145K En RAM Exec OS 5K Dump zone d’allocation dynamique, 16-5 = 11K En NVM Data OS (persistant) 6K En ROM (NB : on ne peut pas y écrire, pas de GC, stocke uniquement le code + objets en lecture = bytecode, class, etc., correspond à la section RO-data du linkscript) Code OS 134K Dump objets OMem, 173K qui dépend de ce qu’on a pris comme système (on peut configurer et prendre les composantes du noyau que l’on veut, ex. pas de load dynamique de classes) et comme applications. NB : vocabulaire Immutable = RO (read only) Immortel = update + read (mais ni delete ni move) Les objets du dump de la ROM sont immortels et immutables Les objets référencés par ceux du dump de la ROM sont immortels (et donc persistants)