Compte rendu de réunion PlugDB - smis
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).
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)
VM (.NET, JVM)
API
OMem
BSP
Hardware, API samsung
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 :
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 :
Client
Liste médecins
<img source=photo>
<script source=main.js
http get main.html
Renvoie le fichier
photo
fichier
Code
Javascript
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)
1
/
5
100%
