FR2836568A1

FR2836568A1 - Procede iteratif de serialisation d'objets logiciels structures

Info

Publication number: FR2836568A1
Application number: FR0202570A
Authority: FR
Inventors: Olivier Fambon; Andre Freyssinet; Serge Lacourte
Original assignee: Bull SA; Institut National de Recherche en Informatique et en Automatique INRIA
Current assignee: Bull SA; Institut National de Recherche en Informatique et en Automatique INRIA
Priority date: 2002-02-28
Filing date: 2002-02-28
Publication date: 2003-08-29
Also published as: CN1301462C; WO2003073390A8; EP1481377A2; CN1643552A; AU2003207871A1; WO2003073390A2; AU2003207871A8; JP2005519376A; JP2009289272A; WO2003073390A3

Abstract

La présente invention concerne un procédé itératif de conversion d'objets logiciels structuré en un flux de données brutes et inversement, permettant leur transfert direct par des moyens de communication simples comme ceux d'une station informatique embarquée, ainsi qu'une remise à zéro de tels objets logiciels ou une réutilisation de l'espace mémoire qui leur est alloué.Ce procédé est utilisable par une plate-forme embarquée (2) ou un objet portable incluant au moins un processeur apte à échanger des informations avec un terminal sous la forme de successions linéaires de données. Le procédé comporte une étape de conversion d'un ensemble de données, dans un sens ou dans l'autre, entre d'une part un agencement en une succession linéaire de données et d'autre part un agencement structuré décrivant ou représentant un objet logiciel orienté objet.

Description

Procédé itératif de sérialisation d'obiets loaiciels structurés
La présente invention concerne un procédé itératif de conversion d'objets logiciels structuré en un flux de données brutes et inversement, permettant leur transfert direct par des moyens de communication simples comme ceux d'une station informatique embarquée, ainsi qu'une remise à zéro de tels objets logiciels ou une réutilisation de l'espace mémoire qui leur est alloué.

Au sein d'une application programmée dans un langage de haut niveau, et en particulier dans le cas des langages structurés ou orientés objets comme par exemple Java&commat;, une grande part des données utilisées ou traitées sont organisées et mémorisées sous la forme d'objets logiciels comportant une structure précise, plus complexe qu'une simple succession d'octets. De tels objets peuvent regrouper plusieurs variables ou groupes de données, par exemple sous la forme de types simples, caractères (type"char"), entier (type "int"), ou de types d'objets de base ou définis par le programmeur, chaîne de caractères (type"String"), ou de tableaux (type"array") à une ou plusieurs dimensions des types précédemment définis. De tels objets structurés peuvent donc être définis ou représentés par une arborescence regroupant différents objets eux-mêmes de différents types, l'organisation d'une telle structure étant parfois appelée le graphe de composition de l'objet. Un type d'objet peut être défini"par héritage"à partir de la définition d'un autre type (généralement appelé"super-type"), l'ensemble des types peut être représenté sous la forme d'une arborescence nommée le graphe d'héritage.

Selon les cas, il peut être utile de pouvoir transférer, créer, ou supprimer les objets logiciels maniés par une application informatique, dans des environnements matériels ou logiciels où ces fonctionnalités de sont pas toujours possibles ou pratiques.

De nombreuses applications informatiques, par exemple, comportent une communication entre d'une part un terminal informatique et éventuellement un réseau informatique, et d'autre part un objet portable ou plate-forme embarquée ayant des capacités de traitement de données, comme par exemple une carte à puce de gestion bancaire, d'abonnement téléphonique ou de santé, ou un dispositif de repérage, de marquage, ou de péage informatisé.

De tels objets portables comportent en particulier un processeur associé à des moyens de mémorisation, contenant au moins un programme d'application, et à des moyens de communication, avec un ou plusieurs terminaux. Ces moyens de communication sont basés par exemple sur une transmission d'informations électroniques par différents types de technologies, telles que contact électrique, antenne radio, transmission lumineuse ou autre, plusieurs types de transmissions pouvant être combinées dans le même objet portable. Pour des raisons d'encombrement ou parfois d'ordre historique, les moyens de communications utilisés de façon courante fonctionnent selon des protocoles simples, par exemple APDU selon la norme ISO 7816 pour les cartes à puces. Ces protocoles ne permettent parfois le transfert que d'objets de types simples (sous forme d'entiers, voire de caractères simples) en tant que paramètres de commande transmis à l'objet ou obtenus en réponse de sa part, ou seulement à l'initiative du terminal, ou les deux. Dans le cas de la norme ISO 7816, le protocole APDU ne permet que le transfert d'objets sans types en tant que données brutes, sous forme d'octets transmis à l'objet portable informatisé en tant que paramètres de commande, ou obtenus en réponse de sa part, et seulement à l'initiative du terminal.

En l'état actuel de leur évolution, ces objets portables de traitement de données sont pour certains dotés d'un fonctionnement interne, par exemple JavaCard&commat;, apte à exploiter directement des éléments d'applications programmés dans des langages de haut niveau voire orientés objet, par exemple Java (D, et à être intégrés dans des applications centralisées ou distribuées communiquant de façon étendue. Pour communiquer avec des applications situées à l'intérieur d'une telle plate-forme embarquée, le programmeur d'une telle application doit alors s'abstenir d'utiliser des objets

logiciels structurés, ou prévoir de traiter directement et au cas par cas le transfert de ces objets avec cette plate-forme embarquée.

Pour bénéficier des performances et de la souplesse d'un tel langage lors de la programmation d'une application exécutable dans le processeur d'un tel objet portable, il devient donc utile que cette application puisse communiquer facilement avec d'autres applications externes à cet objet. Il est donc utile pour cela qu'elle puisse échanger avec elles les objets qu'elles traitent, sans perte de l'organisation et de la structure de ces objets.

Dans des langages de programmation tels que Java (marque déposée), les procédés utilisés pour la sérialisation ou désérialisation d'objets structurés peuvent compter sur des ressources matérielles et logicielles importantes. Ces procédés sont utilisés en particulier pour sauvegarder un objet structuré dans un fichier, ou pour transmettre un objet structuré entre deux processus de programme s'exécutant dans deux zones mémoires de travail différentes.

Ces procédés utilisent toutefois des ressources logicielles et matérielles qui ne sont pas disponibles dans certaines plates-formes embarquées, en particulier Javacard (marque déposée). A titre d'exemple, les classes de bases utilisées par une plate-forme Java classique occupent une taille mémoire supérieure au méga-octet (Java Developpement Kit : 9 Mo), alors qu'une carte à puce au standard Javacard peut ne disposer que de 16 kilo-octets.

Les procédés classiques de sérialisation utilisent les ressources classiques de l'environnement Java et leurs algorithmes sont conçus avec des objectifs de facilité d'emploi et de maintenance informatique. Ils sont donc beaucoup trop gourmands en mémoire et beaucoup trop complexes pour pouvoir être transposés dans une plate-forme embarquée d'aussi faible performance en termes de capacité mémoire et de puissance et vitesse de processeur.

Par ailleurs, en Java par exemple, les procédés de sérialisation utilisent un gestionnaire générique de types d'objets ( type manager ), implémenté au

sein de la machine virtuelle (VM) Java s'exécutant sur chaque plate-forme matérielle.

Du fait de la concision nécessaire pour être adaptée à une plate-forme embarquée, l'environnement Javacard dans ses versions actuelles ne comporte pas de gestionnaire de types. Un procédé de sérialisation tel qu'utilisé en Java standard ne disposerait donc pas des informations représentant la structure des objets structurés à reconstituer à partir des données reçues en format APDU.

Par ailleurs, dans un environnement informatique classique, les ressources en mémoire sont telles que les procédés de sérialisation implémentés dans les langages de programmation orientés objets, comme Java, ne se préoccupent pas de la taille des objets structurés à transmettre. Les objets à envoyer sont sérialisés par l'émetteur indépendamment de leur réception par le destinataire, et les objets reçus peuvent être désérialisés par le destinataire indépendamment de l'émetteur ou du moment de leur transmission. Les flux linéaires de données sont alors transmis et gérés entre émetteur et destinataire par des mécanismes logiciels qui sont extérieurs à l'environnement de programmation. Ces flux peuvent ainsi transiter par des zones tampons en mémoire ( buffers ) de capacités importantes, et sont gérés par d'autres couches logicielles, par exemple par un protocole tel que TCP/IP.

Dans le cas d'une plate-forme embarquée, les mécanismes logiciels permettant d'échanger des données avec l'extérieur n'offrent pas de fonctionnalités de gestion de flux assurant l'intégrité et la continuité des données transmises. Les faibles ressources en mémoire d'une plate-forme embarquée ne permettent pas non plus de mémoriser des flux linéaires donc des objets de taille importante au cours de la transmission et des conversions.

Un des buts de la présente invention est donc de proposer un procédé permettant au programmeur d'une application utilisant une plate-forme embarquée de disposer d'outils logiciels automatisés permettant à un agent logiciel, ou élément d'application, mémorisé ou exécuté dans un tel objet

portable, de recevoir ou d'envoyer à un autre agent, situé sur une autre station informatique, des données organisées sous la forme d'objets logiciels structurés, lorsque les moyens de communications entre eux ne permettent pas le transfert en tant que telles des structures qui les composent, mais seulement le transfert de données sous une forme plus simple, et que les ressources logicielles et matérielles de cette plate-forme embarquée ne sont pas suffisantes pour permettre l'utilisation d'un procédé classique de sérialisation.

Cet objectif est atteint par un procédé de conversion de données utilisable par une station informatique, dite plate-forme embarquée, comprenant un objet portable incluant au moins un processeur, des moyens de mémorisation, et des moyens de communication aptes à échanger des informations avec un terminal sous la forme d'une ou plusieurs successions linéaires de données, caractérisé en ce qu'il comporte une étape de conversion d'un ensemble de données, dans un sens ou dans l'autre, entre d'une part un agencement en une succession linéaire de données et d'autre part un agencement structuré décrivant ou représentant un ou plusieurs objets logiciels structurés ou hiérarchisés suivant les critères d'un langage de programmation orienté objet.

Selon une particularité, le procédé comporte des étapes de : - conversion, ou sérialisation, d'un premier ensemble de données à transmettre comportant ou représentant un ou plusieurs objets logiciels structurés ou hiérarchisés suivant les critères d'un langage de programmation orienté objet, depuis un agencement structuré décrivant ou représentant cet objet vers une succession linéaire de données représentant ce premier ensemble de données ; - transmission de cette succession linéaire de données par des moyens de communication, depuis la plate-forme embarquée vers au moins un hôte, c'est à dire un terminal ou une station informatique reliée au terminal, ou de cet hôte vers la plate-forme embarquée ; - conversion après transmission, ou dé-sérialisation, de cette succession linéaire de données vers un ensemble de données agencé en un ou

plusieurs objets logiciels structurés reproduisant ou représentant le premier ensemble de données.

Selon une particularité, le terminal hôte envoie des informations à la plate-forme embarquée en utilisant un agent logiciel, dit fonction de transmission, ces informations étant reçues dans la plate-forme embarquée par une fonction de réponse apte à déclencher un traitement de ces données par au moins un agent logiciel destinataire mémorisé dans la plate-forme embarquée et faisant partie d'au moins une application, le procédé comprenant des étapes de : - réception, par un agent de communication en lieu et place de l'agent destinataire, d'un ensemble de données reçues par la fonction de réponse à l'intention de cet agent logiciel destinataire, cet ensemble de données étant agencé en une succession linéaire de données ; - conversion de cet ensemble de données en au moins un objet logiciel, structuré ou hiérarchisé suivant les critères d'un langage de programmation orienté objet ; - transmission de cet objet logiciel structuré à l'agent destinataire et déclenchement d'un traitement en fonction de cet objet par cet agent destinataire.

Selon une particularité, le procédé comporte des étapes de : - réception par la fonction de réponse, en provenance de la fonction de transmission de l'hôte, d'au moins une donnée sous forme d'au moins un paramètre d'envoi, et transmission de ce paramètre à un agent de communication mémorisé ou exécuté dans la plate-forme embarquée ; - conversion, ou concaténation, par l'agent de communication d'au moins un paramètre d'envoi, transmis par l'agent de réponse, en un ensemble de données agencé en une succession linéaire de données et mémorisation de ces données dans un flux d'entrée dans la plate-forme embarquée ; - conversion, ou dé-sérialisation, par un agent de sérialisation, mémorisé ou exécuté dans la plate-forme embarquée, d'au moins une partie des données mémorisées dans ce flux d'entrée vers un ensemble de données comprenant ou représentant au moins un objet logiciel structuré ;

- réception de cet objet logiciel structuré ou de ses références par l'agent destinataire.

Selon une particularité, le procédé comporte des étapes de : - transmission d'un objet logiciel structuré ou de sa représentation depuis un agent logiciel faisant partie d'une application exécutée ou mémorisée dans une plate-forme embarquée vers un agent de sérialisation exécuté ou mémorisé dans cette plate-forme embarquée ; - conversion, ou sérialisation, par cet agent de sérialisation de cet objet logiciel structuré vers un ensemble de données agencé en une succession linéaire de données et mémorisation de ces données dans un flux de sortie dans la plate-forme embarquée ; - conversion par un agent de communication, mémorisé ou exécuté dans la plate-forme embarquée, d'au moins une partie des données mémorisées dans ce flux de sortie vers un ensemble de paramètres de réponse aptes à être transmis par la fonction de réponse ; - transmission de ces paramètres de réponse depuis la plate-forme embarquée vers le terminal hôte par la fonction de réponse, de sa propre initiative ou en réponse à la fonction de transmission du terminal hôte.

Selon une particularité, la succession linéaire de données mémorisée dans le flux d'entrée ou le flux de sortie représente un ou plusieurs objets logiciels structurés ou hiérarchisés en utilisant une ou plusieurs données, dites balises, ayant une ou plusieurs valeurs déterminées représentant chacune une action déterminée à effectuer lors de la désérialisation de cette succession linéaire de données.

Selon une particularité, au moins une balise est définie comme représentant une des actions suivantes : - ajout d'un nouvel élément à la structure de l'objet structuré représenté par la succession linéaire de données ; - référence à un élément ou objet, dit objet source, en tant que source de la valeur de tout ou partie d'un élément composant l'objet structuré ; - indication que la ou les données suivantes représentent le contenu d'un élément composant l'objet structuré ;

- indication d'une absence de contenu d'un élément composant l'objet structuré.

Selon une particularité, l'agent de sérialisation effectue la sérialisation d'un objet structuré, dit objet de départ, en un ensemble linéaire de données suivant un procédé, dit procédé de sérialisation, traitant au moins un des objets, dits éléments, composant la structure ou l'arborescence de cet objet structuré de départ, selon des étapes de : - détection, par l'agent de sérialisation du type d'un élément, dit objet en cours, composant la structure ou l'arborescence de cet objet structuré ; - mémorisation dans le flux de sortie d'une donnée représentant une balise indiquant l'ajout d'un nouvel élément, suivie d'une donnée représentant le type de l'objet en cours ; - mémorisation dans le flux de sortie, à la suite des éléments qui y sont déjà présents, par un agent de sérialisation de type associé au type de l'objet en cours, 'soit d'au moins une donnée représentant la valeur de tout ou partie de l'objet structuré ; 'soit d'au moins une donnée représentant une balise indiquant une référence à un objet en tant que source de la valeur de tout ou partie de l'objet structuré, cette balise étant suivie d'une donnée identifiant ledit objet source ;
Selon une particularité, le procédé de sérialisation effectue la conversion d'un objet structuré vers le flux de sortie en mémorisant au fur et à mesure de ses itérations le type de chaque objet en cours dans une pile mémoire, dite pile de types, dont les emplacements sont lus dans l'ordre inverse de leur ordre de mémorisation.

Selon une particularité, l'agent de sérialisation effectue la désérialisation d'un ensemble linéaire de données en au moins un objet structuré résultat, suivant un procédé, dit procédé de désérialisation, traitant chacune des données mémorisées dans le flux d'entrée, selon des étapes de : - lecture par l'agent de sérialisation d'au moins une donnée mémorisée dans le flux d'entrée à la suite des données précédemment traitées ;

- analyse de cette donnée et réalisation d'une action correspondant à cette donnée.

Un des buts de l'invention est également de proposer un tel procédé de transfert d'objets structuré permettant le transfert d'objets logiciels entre un hôte et une plate-forme embarquée lorsque l'environnement de fonctionnement de cette plate-forme embarquée ne comporte pas d'agent gestionnaire de types pour de tels objets structurés.

Ce but est atteint par le procédé de conversion de données décrit cidessus, caractérisé en ce que le procédé de désérialisation comprend le remplissage d'un élément, dit objet en cours, c'est à dire l'affectation d'une valeur directe ou indirecte à tout ou partie de cet objet en cours, cet élément composant tout ou partie de la structure de l'objet structuré résultat, la fin du remplissage de l'objet en cours déclenchant - la lecture d'une donnée représentant un type d'objet mémorisé dans le prochain emplacement d'une structure de mémoire, dite pile de types, et l'effacement de cette donnée de cet emplacement ; - la mémorisation, comme type d'un nouvel objet en cours, du type représenté par la donnée lue dans la pile de types.

Selon une particularité, l'objet structuré créé par le procédé de désérialisation est considéré comme complet et transmis à l'agent logiciel ou l'application qui en est destinataire lorsque la pile de types est vide.

Selon une particularité, l'action de désérialisation correspondant à une donnée représentant une balise, dite balise NEW , indiquant un nouvel élément comprend des étapes de : - lecture d'au moins une donnée suivante dans le flux d'entrée ; - mémorisation du type d'objet, représenté par cette même donnée suivante, dans une pile mémoire, dite pile de types, à la suite des types qui y sont déjà éventuellement mémorisés ;
Selon une particularité, la pile de types utilisée par le procédé de désérialisation comprend une pile de type LIFO, c'est à dire dont les emplacements sont lus dans l'ordre inverse de leur ordre de mémorisation.

Selon une particularité, le procédé de désérialisation comprend une étape de création d'un élément composant la structure de l'objet logiciel structuré résultat, par allocation d'un nouvel espace mémoire ou par réutilisation d'une allocation libre, cette création étant réalisée par un agent de contrôle de type correspondant au type de l'élément à créer.

Selon une particularité, l'étape de création d'un élément composant la structure de l'objet logiciel structuré résultat a lieu entre l'étape de lecture d'une donnée indiquant la création de cet élément et la première étape de remplissage de ce même élément.

Selon une particularité, l'action correspondant à une donnée, dite donnée simple, c'est à dire ne représentant pas une balise, comprend une étape de mémorisation de la valeur de cette donnée dans l'espace mémoire alloué à l'objet en cours.

Selon une particularité, au cours du procédé de désérialisation, un index d'objet est attribué à au moins un élément composant la structure de l'objet structuré résultat, cet index d'objet identifiant cet élément de façon unique et lui permettant d'être désigné ou référencé par d'autres objets ou éléments.

Selon une particularité, l'action correspondant à une donnée représentant une balise, dite balise REF , indiquant une référence comprend des étapes de : - lecture d'au moins une donnée suivante dans le flux d'entrée ; - mémorisation dans l'espace mémoire alloué à l'objet en cours, à la suite des données déjà mémorisées, d'une donnée désignant un objet comme source de la valeur de tout ou partie de l'objet en cours, cet objet ou élément source étant identifié par ladite donnée suivante.

Selon une particularité, le remplissage de l'objet en cours est considéré comme terminé lorsque les données mémorisées dans l'espace mémoire qui lui est alloué correspondent à une longueur déterminée, cette longueur étant lue en mémoire dans la carte par un agent de contrôle de type ou par un agent gestionnaire de types mémorisé dans la plate-forme embarquée.

Selon une particularité, l'envoi par la plate-forme embarquée, vers l'hôte, d'une succession linéaire de données d'une longueur déterminée, s'effectue selon un procédé itératif, dit de lecture de données, comprenant des étapes récursives de : - envoi par l'hôte d'une commande de communication avec passage d'au moins un paramètre d'envoi représentant la longueur des données déjà reçues ; - réception par la plate-forme embarquée du paramètre d'envoi et comparaison avec la succession linéaire de données à transmettre ; - réponse à la commande de communication par l'envoi d'au moins un paramètre de retour représentant la ou les données suivant immédiatement les données déjà reçues par l'hôte ; - réception par l'hôte du paramètre de retour de la commande de communication et mémorisation des données qu'il représente à la suite des données déjà reçues.

Selon une particularité, la réception par la plate-forme embarquée, en provenance de l'hôte, d'une succession linéaire de données d'une longueur déterminée, s'effectue selon un procédé itératif, dit d'écriture de données, comprenant des étapes récursives de : - envoi par l'hôte d'une commande de communication avec passage d'au moins un premier paramètre d'envoi représentant la ou les données suivant immédiatement la partie déjà transmise de la succession linéaire de données à transmettre, ainsi éventuellement qu'un deuxième paramètre d'envoi représentant la position, dans la succession à transmettre, des données représentées par le premier paramètre d'envoi ou la longueur des données déjà transmises ; - réception par la plate-forme embarquée du ou des paramètres d'envoi de la commande de communication ; - mémorisation dans un flux d'entrée dans la plate-forme embarquée des données représentées par le premier paramètre d'envoi à la suite des données déjà reçues.

Selon une particularité, le procédé d'écriture de données comprend en outre les étapes suivantes : - comparaison par la plate-forme embarquée du deuxième paramètre d'envoi et comparaison avec la longueur des données déjà reçues ; - retour par la plate-forme embarquée d'au moins un paramètre de réponse représentant soit la longueur des données déjà reçues soit une donnée représentant le résultat de cette comparaison soit les deux ;
Un des buts de l'invention est également de proposer un tel procédé de transfert d'objets structuré permettant le transfert d'objets logiciels d'une taille importante par rapport aux possibilités des moyens de communication en matière de transfert ou de stockage provisoire, ou d'objets logiciels de taille illimitée.

Ce but est atteint par le procédé de conversion de données décrit cidessus, caractérisé en ce qu'au moins deux des procédés de sérialisation, désérialisation, lecture de données, ou écriture de données sont effectués en parallèle ou de façon entrelacée par répétition d'une étape comprenant l'exécution successive d'au moins une étape de chacun de ces procédés.

Selon une particularité, le flux d'entrée ou le flux de sortie ou les deux sont mémorisés sous la forme de structures circulaires de mémoire, ces deux flux pouvant partager la même structure circulaire.

Selon une particularité, la plate-forme embarquée comporte un environnement programmable apte à mémoriser et exécuter au moins une application réalisée par un programmeur, la fonction de communication étant compatible avec le format APDU défini dans la norme ISO 7816.

Selon une particularité, des opérations de désérialisation puis traitement d'un objet reçu sont déclenchées par la réception d'au moins une commande au format APDU comprenant au moins une donnée indiquant la réception d'un objet structuré.

Selon une particularité, la plate-forme embarquée comporte un environnement programmable compatible avec le standard JavaCard (marque déposée).

Selon une particularité, au moins une des applications exécutées sur l'hôte ou la plate-forme embarquée est programmée en langage Java&commat;.

Selon une particularité, le procédé est utilisé pour la communication entre au moins un agent logiciel, dit agent de carte, mémorisé ou exécuté dans la plate-forme embarquée et au moins un agent logiciel, dit agent proxy de moteur de carte mémorisé ou exécuté dans au moins un hôte appartenant à un réseau informatique communiquant par messages asynchrones selon une infrastructure logicielle de type AAA-MOM, cet agent proxy de moteur de carte servant d'intermédiaire à l'agent de carte dans ses communications avec d'autres agents de ce réseau, ces agents fonctionnant selon les spécifications de cette infrastructure logicielle et appartenant à au moins une application distribuée.

Par ailleurs, dans certains environnements ou systèmes d'exploitation, par exemple de type embarqué comme JavaCard&commat;, il n'existe pas de procédure, ou seulement des procédures complexes et coûteuses en termes de ressources, pour supprimer un tel objet logiciel une fois qu'il n'est plus utilisé ou libérer l'espace qu'il occupe dans les moyens de mémorisation. Cette suppression doit alors être faite manuellement , c'est à dire être prévue directement et au cas par cas par le programmeur de l'application.

Un des buts de la présente invention est donc de proposer un procédé permettant au programmeur d'une application utilisant une plate-forme embarquée de disposer d'outils logiciels permettant la réutilisation de l'espace mémoire occupé par tout ou partie de certains objets logiciels structurés utilisés par une application dans une station de traitement de données portable ou non.

Il peut également être utile de disposer d'outils logiciel permettant de réaliser aisément la duplication d'un objet logiciel comportant une structure non linéaire, par exemple sous forme d'arborescence.

Un des buts de la présente invention est donc de proposer un procédé permettant au programmeur d'une application utilisant une plate-forme embarquée de disposer d'outils logiciels permettant la duplication d'un objet logiciel structuré, dit de départ, vers un autre objet, dit résultat, contenant les

mêmes valeurs que l'objet de départ mais constituant un objet différent en mémoire.

De même, pour des raisons de sécurité, lorsque l'espace occupé par un tel objet logiciel se libère, il peut être important d'effacer de cet espace les informations provenant de cet objet, pour éviter que ces informations puissent être lues par un autre objet ou une autre application réutilisant ce même espace plus tard. Cet effacement doit alors être fait manuellement , c'est à dire être prévu directement et au cas par cas par le programmeur de l'application.

Un des buts de la présente invention est donc de proposer un procédé permettant au programmeur d'une application utilisant une plate-forme embarquée de disposer d'outils logiciels permettant l'effacement ou l'uniformisation des informations contenues dans l'espace mémoire utilisé par un tel objet logiciel lors de la suppression de celui-ci ou de la réutilisation de cet espace.

L'invention propose alors un procédé comme décrit plus haut, caractérisé en ce que les procédés de lecture de données, d'écriture de données, de dé-sérialisation ou de sérialisation sont mis en oeuvre à travers leur implémentation dans au moins une classe mémorisée dans l'hôte ou dans la plate-forme embarquée, cette implémentation comprenant au moins l'une des commandes suivantes : - une commande d'écriture d'objet, effectuant la transmission d'un objet structuré à au moins un agent de la plate-forme embarquée, par utilisation du procédé de sérialisation de cet objet, puis du procédé d'écriture de données, puis du procédé de dé-sérialisation ; - une commande de lecture d'objet, effectuant la lecture d'un objet structuré depuis au moins un agent de la plate-forme embarquée, par utilisation du procédé de sérialisation puis du procédé de lecture de données, puis du procédé de désérialisation ; - une commande de désallocation d'un objet structuré mémorisé dans la plate-forme embarquée, par utilisation du procédé de sérialisation, celui-ci comprenant en outre une étape de mémorisation de la libération ou

désallocation de l'espace mémoire alloué à chaque composant de cet objet, après analyse de la structure de ce composant ; - une commande de nettoyage ou effacement d'un espace mémoire libéré par un objet structuré, par utilisation du procédé de désérialisation pour créer un objet de contenu sans signification à partir d'une succession linéaire de données déterminée ; - une commande de duplication d'un objet structuré dit de départ, par utilisation du procédé de sérialisation, sans désallocation de cet objet de départ, pour créer une succession linéaire de données représentant ce même objet, puis par utilisation du procédé de désérialisation à partir de cette succession linéaire de données pour créer un autre objet structuré de contenu identique à l'objet de départ.

Selon une particularité, le langage de programmation de la plate-forme embarquée comporte une première classe (IOApplet) décrivant une méthode abstraite ProcessAPDU lançant, lors de la réception d'un message APDU, un traitement paramétrable dans l'application ; le code programme réalisant les opérations de désérialisation dans la plate-forme embarquée étant mémorisé dans la plate-forme embarquée, en tant qu'implémentation de cette méthode abstraite ProcessAPDU, dans une deuxième classe (ObjectlOApplet) héritant de la première classe (IOApplet), ce même code programme faisant appel à une méthode ProcessObject elle-même décrite comme une méthode abstraite dans cette même classe (ObjectIOApplet) d'implémentation.

Selon une particularité, le langage de programmation de la plate-forme embarquée comporte une première classe (IOApplet) décrivant une méthode SendAPDU émettant vers l'hôte un message au format APDU ; le code programme réalisant les opérations de sérialisation dans la plate-forme embarquée étant mémorisé, en tant qu'implémentation d'au moins une méthode SendObject faisant appel à la méthode SendAPDU, dans une deuxième classe (ObjectIOApplet) de carte héritant de la classe (IOApplet).

Un autre but de l'invention est de proposer un système informatique incluant un tel objet portable et comportant de tels outils logiciels.

Cet objectif est atteint par un système informatique comprenant une station informatique, dite plate-forme embarquée, comprenant un objet portable incluant au moins un processeur, des moyens de mémorisation, et des moyens de communication aptes à échanger des informations avec un terminal sous la forme d'une ou plusieurs successions linéaires de données, caractérisé en ce que la plate-forme comprend un agent de sérialisation apte à effectuer une étape de conversion d'un ensemble de données, dans un sens ou dans l'autre, entre d'une part un agencement en une succession linéaire de données et d'autre part un agencement structuré décrivant ou représentant un ou plusieurs objets logiciels structurés ou hiérarchisés suivant les critères d'un langage de programmation orienté objet.

Selon une particularité, la plate-forme embarquée comprend un agent de communication apte à : - recevoir en lieu et place de l'agent destinataire un ensemble de données reçues par la fonction de réponse à l'intention d'un agent logiciel destinataire mémorisé dans la plate-forme embarquée, cet ensemble de données étant agencé en une ou plusieurs successions linéaires de données ; - convertir cet ensemble de données en au moins un objet logiciel, structuré ou hiérarchisé suivant les critères d'un langage de programmation orienté objet ; - transmettre cet objet logiciel structuré à l'agent destinataire et déclencher un traitement en fonction de cet objet par cet agent destinataire.

Selon une particularité, la succession linéaire de données représentant un objet logiciel structuré est mémorisée dans la plate-forme embarquée dans un flux d'entrée ou un flux de sortie, la plate-forme embarquée comportant un agent logiciel dit agent de sérialisation apte à créer dans la plate-forme embarquée le ou les objets structurés représentés par le flux d'entrée, c'est à dire à désérialiser ces objets structurés, ou à écrire dans le flux de sortie des données représentant le ou les objets structurés à transmettre, c'est à dire à sérialiser ces objets structurés.

Selon une particularité, le flux d'entrée ou le flux de sortie sont mémorisés sous la forme d'une ou plusieurs structures circulaires de mémoire.

Selon une particularité, l'agent de sérialisation utilise une pile mémoire, dite pile de types, pour mémoriser le type d'au moins un objet composant tout ou partie de la structure d'un objet structuré à sérialiser ou désérialiser, cette pile de type comportant des emplacements mémoires qui ne sont chacun accessible qu'après que les emplacements mémorisés plus récemment aient été lus et effacés.

Selon une particularité, les données contenues dans les flux d'entrée ou de sortie représentent un ou plusieurs objets structurés en utilisant un codage comprenant un jeu de balises, ces balises représentant chacune une action déterminée à effectuer lors de la désérialisation de cette succession linéaire de données.

Selon une particularité, au moins une balise est définie comme représentant une des actions suivantes : - ajout d'un nouvel élément à la structure de l'objet structuré représenté par la succession linéaire de données ; - référence à un élément ou objet, dit objet source, en tant que source de la valeur de tout ou partie d'un élément composant l'objet structuré ; - indication que la ou les données suivantes représentent le contenu d'un élément composant l'objet structuré ; - indication d'une absence de contenu d'un élément composant l'objet structuré.

Selon une particularité, la plate-forme embarquée comprend un objet portable fonctionnant selon la norme IS07816 et utilisant des commandes au format APDU.

Selon une particularité, au moins un agent ou application mémorisé dans la plate-forme embarquée est programmé en langage Java&commat;, la plateforme embarquée comportant un environnement informatique selon le standard JavaCard&commat;.

Selon une particularité, le système comporte dans l'hôte ou dans la plate-forme embarquée, ou les deux, au moins une classe logicielle implémentant au moins l'une des commandes suivantes : - une commande d'écriture d'objet, effectuant la transmission d'un objet structuré à au moins un agent de la carte, par sérialisation de cet objet structuré en un flux de données dans l'hôte, puis envoi de ce flux de données dans la plate-forme embarquée, puis dé-sérialisation de ce flux de données en un objet structuré dans la plate-forme embarquée ; - une commande de lecture d'objet, effectuant la lecture d'un objet structuré depuis au moins un agent de la carte, par sérialisation de cet objet structuré en un flux de données dans la plate-forme embarquée, puis réception depuis la plate-forme embarquée de ce flux de données, puis désérialisation de ce flux de données en un objet structuré dans l'hôte ; - une commande de désallocation d'un objet structuré mémorisé dans la plate-forme embarquée, par une sérialisation de cet objet selon une option comprenant une libération ou désallocation de l'espace mémoire alloué à chaque composant de cet objet, après analyse de la structure de ce composant ; - une commande de nettoyage ou effacement d'un espace mémoire libéré par un objet structuré dans la plate-forme embarquée, par désérialisation d'une succession linéaire de données déterminée pour créer un objet de contenu sans signification ; - une commande de duplication dans la plate-forme embarquée d'un objet structuré dit de départ, par sérialisation en une succession linéaire de données représentant ce même objet, sans désallocation de cet objet de départ, puis par désérialisation à partir de cette succession linéaire de données en un autre objet structuré de contenu identique à l'objet de départ.

Selon une particularité, la plate-forme embarquée communique au moins un hôte appartenant à un réseau informatique communiquant par messages asynchrones selon une infrastructure logicielle de type AAA-MOM, cet hôte comprenant un agent logiciel, dit agent proxy de moteur de carte, apte

à gérer les communications de cette plate-forme embarquée avec d'autres agents de ce réseau, ces agents fonctionnant selon les spécifications de cette infrastructure logicielle et appartenant à au moins une application distribuée.

L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faite en référence aux dessins annexés dans lesquels : ta figure 1 représente un schéma symbolique partiel des transferts d'objets et de leurs conversions lors d'opérations d'écriture et de lecture d'un hôte ou terminal vers et depuis un agent logiciel d'une plate-forme embarquée, dans un mode de réalisation de l'invention où la carte ne comporte qu'une seule application ; la figure 2 représente un schéma symbolique plus détaillé des transferts d'objets et de leurs conversions lors d'opérations d'écriture et de lecture d'un hôte ou terminal vers et depuis un agent logiciel d'une plate-forme embarquée, dans un mode de réalisation de l'invention où la carte ne comporte qu'une seule application ; la figure 3 représente un schéma symbolique partiel des transferts d'objets et de leurs conversions lors d'opérations d'écriture et de lecture d'un hôte ou terminal vers et depuis un agent logiciel d'une plate-forme embarquée, dans un mode de réalisation de l'invention où la carte comporte plusieurs applications ; la figure 4 représente un schéma symbolique partiel des objets et agents mis en oeuvre lors de la désérialisation d'un objet logiciel structuré, à partir d'un flux de données ;

la figure 5 représente un schéma symbolique partiel des objets et agents mis en oeuvre lors de la sérialisation d'un objet logiciel structuré, vers un flux de données.

Dans certains ouvrages (par exemple Java embarqué -EyrollesParis 1999), le terme d'ordinateur embarqué est utilisé pour désigner un ordinateur qui n'est pas visible en tant que tel mais intégré dans un équipement doté d'une autre fonction. Ce terme serait une traduction approximative de l'anglais embedded computer , qui signifie littéralement ordinateur enfoui ou enchâssé .

Cette caractéristique, de remplir une fonction particulière au sein d'un autre dispositif, explique grandement le fait que de tels ordinateurs embarqués disposent souvent de ressources matérielles ou logicielles limitées, et utilisent souvent un système d'exploitation ou un environnement logiciel rudimentaire.

Bien que des évolutions soient prévisibles, les ressources de tels ordinateurs peuvent typiquement être de l'ordre de 512 kilo-octets de mémoire statique à quelques kilo-octets, pour un processeur de 8 ou 16 bits. Dans le cas d'une carte à puce, la mémoire vive (RAM) disponible peut être d'environ 4 kilooctets, et aller actuellement jusqu'à 32 kilo-octets pour les modèles les plus performants.

De façon générale en informatique, le terme de plate-forme désigne un dispositif de traitement de données comprenant au moins un processeur et des moyens de mémorisation. Par extension à la définition ci-dessus, et pour la présente description, le terme de plate-forme embarquée sera utilisé pour désigner un objet portable incluant une telle plate-forme, cet objet étant portable ou de faible taille, ou ayant de faibles capacités de traitement ou de mémorisation.

La présente description expose le procédé selon l'invention dans des modes de réalisation comportant une répartition déterminée des tâches et opérations entre les différents agents et applications concernés. La flexibilité de

l'organisation d'une application informatique permet bien sûr de présenter différemment cette répartition, en particulier lorsque les distinctions entre les différents agents et leurs dénominations sont des notions abstraites n'influant pas sur leurs caractéristiques principales de fonctionnement. Il est donc évident que le procédé selon l'invention peut également être mis en oeuvre dans d'autres modes de réalisation non décrits ici, sans sortir de l'esprit de l'invention, en particulier en combinant différemment les diverses variantes exposées pour chaque tâche ou agent. De même, la répartition abstraite des tâches entre des agents ou applications mémorisés en un même lieu et temps, peut être combinée en diverses variantes non décrites ici sans sortir de l'esprit de l'invention.

Dans la présente description, le procédé selon l'invention sera illustré principalement dans le cas d'une plate-forme embarquée comprenant une carte à puce (souvent appelée smartcard en anglais) utilisant un environnement système de type JavaCard&commat;, communiquant avec un terminal comprenant une station de traitement de données exécutant une application programmée en langage Java&commat;.

1/doit toutefois être évident que le procédé selon l'invention peut être appliqué à d'autres environnements dont les fonctions de transmission de données ne permettent pas de transmettre des objets logiciels structurés de façon transparente pour le programmeur. 1/peut ainsi s'agir de cartes à puce selon la norme ISO 7816 utilisant un autre environnement de programmation, par exemple Windows for Smart Cards&commat; , ou programmable avec un autre langage de programmation, par exemple Visual Basic&commat;. Il peut également s'agir de cartes à puce selon une autre norme comportant des limites similaires dans leurs fonctions de communication, ou d'objets ou terminaux portables utilisant une telle plate-forme
De même, il peut aussi bien s'agir d'objets portables quelconques comprenant une station de traitement de données embarquée, amovible ou non, comme par exemple un composant électronique automobile, un marqueur de repérage, un téléphone cellulaire, ou un terminal de saisie portable.

De même, le procédé selon l'invention sera illustré principalement comme appliqué à l'utilisation d'une plate-forme embarquée communiquant avec une station de traitement de donnée, dite terminal ou hôte. Ce procédé peut bien sûr également être utilisé dans le cas ou le terminal est une station faisant partie d'un réseau informatique de quelque type que ce soit, sans sortir de l'esprit de l'invention. Ainsi, les différentes fonctions présentées comme réalisées par ce terminal peuvent aussi bien être réparties sur plusieurs dispositifs différents, voire selon une répartition variant dans le temps. Bien sûr, le procédé décrit peut également être appliqué au cas où la plate-forme embarquée communique directement ou indirectement avec une ou plusieurs autres plates-formes embarquées, sans sortir non plus de l'esprit de l'invention.

De façon générale, l'hôte ou le terminal hôte sera donc défini comme l'application ou la station communiquant avec la plate-forme embarquée.

Le procédé selon l'invention peut en particulier être appliqué à la communication d'une carte à puce, par exemple au standard JavaCard, avec un réseau informatique, par exemple programmé en Java&commat;, communiquant par messages asynchrones selon une infrastructure logicielle de type AAA-MOM.

Dans ce cas, les communications de la carte avec le reste du réseau sont typiquement gérées par un agent logiciel, dit agent proxy d'agent de carte, qui sert d'intermédiaire pour chacun des agents logiciels, dits agents de carte, mémorisés dans la carte. Dans l'environnement de la carte, ces agents de cartes sont gérés ou animés, ou les deux, par un agent logiciel dit agent moteur de carte.

Le procédé selon l'invention permet alors à cet agent moteur de carte de communiquer avec l'agent proxy de moteur de carte en s'échangeant des objets logiciels structurés selon les normes du langage Java ou de l'infrastructure AAA. Le fait de pouvoir échanger des objets structurés avec l'extérieur permet ainsi à la carte d'être mieux compatible avec l'infrastructure AAA, et d'être vue elle-même comme un agent de type MA par le reste des agents AAA de ce réseau.

Le procédé selon l'invention peut également être appliqué à la communication d'une carte à puce, par exemple au standard JavaCard, avec un réseau informatique, par exemple programmé en Java&commat;, communiquant utilisant un protocole RPC ( Remote Procédure Call ) orienté objet, par exemple selon une infrastructure logicielle de type Java RMI ( Remote Method Invocation ) ou CORBA (marque déposée).

Lorsqu'une application nécessite de transférer des objets logiciels depuis un terminal vers une plate-forme embarquée constituée d'une carte à puce, ce transfert s'effectue souvent sous la forme d'une communication de type maître/esclave. C'est à dire que c'est le terminal qui prend l'initiative d'exécuter une fonction de transmission vers la plate-forme embarquée. Pour communiquer, cette fonction envoie à cette plate-forme une commande de communication assortie de paramètres d'envoi. Cette commande est alors capable de déclencher un ou plusieurs traitements au sein de la plate-forme, et de recevoir en retour des paramètres de retour ou de réponse.

Dans le cas d'une carte à puce fonctionnant selon la norme ISO 7816, les paramètres de cette commande sont transmis suivant un format de type APDU ( Application Protocol Data Unit ), qui consiste en une succession de données organisées comme suit :
Paramètres d'envoi transmis avec la commande :

<tb>
<tb> en-tête <SEP> corps
<tb> CtATNS'P1'P2leDataTle
<tb>
CLA : un octet désignant la classe ou l'application destinataire INS : un octet désignant une instruction à exécuter P1, P2 : deux octets apportant des précisions sur la commande APDU Lc : longueur des données envoyées Data : données envoyées Le : longueur des données attendues en retour

Paramètres de réponse retournés par la carte :

<tb>
<tb> corps <SEP> fin
<tb> DataRSW1SW2
<tb>
Data : données répondues SW1, SW2 : deux octets constituant des messages ou codes de contrôle renvoyés par la carte
On voit que ce format APDU ne permet d'envoyer ou de recevoir de données que sous forme d'une succession linéaire de données, c'est à dire une simple suite d'octets. Lorsqu'une application est programmée dans un langage ou pour une plate-forme embarquée dont le système ne dispose que des commandes APDU pour communiquer, le programmeur qui veut transférer des objets plus structurés ne dispose donc pas d'outils logiciels simples. Il est obligé de prévoir dans son application de convertir de tels objets structurés en une suite d'octets, puis d'utiliser la commande APDU pour les transmettre, puis de reconvertir ces objets dans le sens inverse. Il s'agit là de réaliser manuellement , c'est à dire de programmer dans les moindres détails, la sérialisation, transmission, puis désérialisation de ces objets.

Dans le cas d'un programmeur utilisant le langage Java&commat; pour développer une application utilisant des plates-formes embarquées au standard JavaCard&commat;, les outils disponibles dans JavaCard consistent en une transmission de données linéaires au format APDU, avec les commandes JavaCard suivantes : - process (APDU) : la carte reçoit des données au format APDU et lance le traitement des paramètres d'envoi qu'elles contiennent, par l'agent logiciel, ou applet , destinataire désigné dans ces données ;

- sendAPDU () ou APDU. sendbyteso : après ou au cours du traitement déclenché précédemment, la carte retourne vers l'hôte d'autres données au format APDU, contenant les paramètres de retour.

La commande SendAPDU () est implémentée au sein de l'environnement JavaCard dans la classe IOApplet , sous la forme d'une méthode applicable à un objet non typé contenant des données brutes.

La commande Process (APDU) , par contre, est déclarée au sein de l'environnement JavaCard dans la classe IOApplet , sous la forme d'une méthode abstraite. C'est à dire que la méthode existe dans l'environnement Javacard, mais que le code réalisant son fonctionnement doit être écrit par le programmeur d'une application voulant utiliser cette commande. Le programmeur va par exemple créer dans son application une sous-classe héritant de la classe IOApplet , cette sous-classe contenant alors une méthode recevant le code du traitement à exécuter par cette méthode Process (APDU) . L'environnement JavaCard se contente d'appeler la méthode Process (APDU) lors de la réception d'un message, et donc de lancer le traitement que le programmeur a prévu dans son code ajouté.

De façon à fournir à un tel programmeur des outils lui permettant de transmettre directement des objets logiciels structurés, le procédé selon l'invention fournit des commandes similaires mais acceptant directement des objets logiciels structurés, selon les spécificités orientées objet du langage Java&commat;. Ces commandes sont alors utilisables dans l'environnement JavaCard&commat; et peuvent être par exemple du type : process (Object) et sendObjectQ .

Pour permettre au programmeur, également ici désigné comme utilisateur, d'utiliser ces commandes directement sans se préoccuper de la syntaxe des commandes APDU, c'est le procédé selon l'invention qui va prendre en charge les opérations de sérialisation, transmission, et désérialisation des objets et données, entre l'application ou agent émetteur et l'agent destinataire.

Dans le cas d'un environnement JavaCard, ces opérations peuvent alors être réalisées par l'exécution d'un code programme contenu dans la méthode Process (APDU) appartenant à une sous-classe de la classe OApp ! et , par exemple nommée ObjectIOApplet . Ce code est donc automatiquement lancé par l'environnement lors de la réception d'un message APDU, et contient lui-même les opérations de conversions ainsi que l'appel d'une autre méthode abstraite Process (Object) . Grâce à un tel mode de réalisation de l'invention, le programmeur n'a plus qu'à écrire le code des traitements qu'il veut voir réalisés par la carte lors de la réception d'un objet structuré. Il va alors écrire ce code dans une sous-classe héritant de la classe ObjectlOApplet , en tant qu'implémentation de la méthode abstraite Process (Object) .

Dans la présente description, seules les opérations de conversion, sérialisation ou désérialisation, effectuées du côté de la carte seront décrites. Il est bien sûr évident que le procédé décrit peut être utilisé aussi bien pour réaliser les mêmes opérations du côté de l'hôte. Les ressources matérielles et logicielles du terminal hôte étant le plus souvent bien supérieures à celles disponibles sur la carte, ces opérations pourront toutefois également être programmées ou organisées de façon différente du côté de l'hôte, sans sortir de l'esprit de l'invention.

Dans un mode de réalisation représenté en figure 1, un terminal hôte (1) communique avec une plate-forme embarquée, par exemple une carte à puce (2) au standard Javacard&commat;. L'hôte (1) exécute au moins une application (11) comprenant au moins un agent logiciel (111), et communique avec la carte (2) par une fonction de communication (101) au format APDU mettant en oeuvre des moyens de communication comportant par exemple un emplacement de connexion (100). Cet emplacement de connexion comporte des moyens de connexion, par exemple par contact électrique, par liaison hertzienne, par liaison infrarouge, par piste magnétique, ou une combinaison de plusieurs de ces types.

La carte (2) exécute une application (22) comprenant au moins un agent logiciel (221), et communique avec l'hôte (1) en utilisant une fonction de réponse (201) faisant partie de l'environnement système JavaCard&commat;. Cette fonction de réponse (201) utilise pour cela des moyens de communication (200) d'un type compatible avec les moyens de communication (100) du terminal hôte (1).

Lorsque l'agent (111) de l'application (11) hôte veut envoyer des données à l'agent (221) de la carte, ou lui faire exécuter un traitement (2210), ou lui demander des informations qu'elle a en mémoire, il exécute une instruction d'écriture d'objet lançant le procédé dans le sens de l'envoi vers la carte d'un objet logiciel structuré (31), cette instruction étant par exemple dénommée WriteObjectQ . Cet objet logiciel (31) est alors sérialisé, c'est à dire converti en un ensemble de données au format APDU, par un agent hôte de conversion (12). Cet agent hôte de conversion utilise alors la fonction de communication (101) pour transmettre ces données à la carte (2) à travers l'emplacement de connexion (100) de l'hôte et les moyens de communication (200) de la carte.

Une fois reçues dans la carte par la fonction de réponse (201) gérant les moyens de communication (200), cette fonction de réponse transmet ces données à un agent de conversion de carte (21). Cet agent de conversion de carte (21) désérialise ces données, c'est à dire les convertit dans le sens inverse de façon à leur redonner leur structure d'origine, sous la forme d'un objet logiciel (34). Cet objet logiciel structuré (34) est alors transmis à l'agent (22) destinataire grâce à une instruction de traitement d'objet qui va effectuer le traitement (2210) correspondant aux données reçues, cette instruction étant par exemple dénommée Process (Object) .

Lorsque l'agent (221) de l'application (22) de la carte (2) veut envoyer des données à l'agent (111) de l'hôte (1), ou des informations sur un traitement effectué, il exécute une instruction d'envoi d'objet lançant le procédé dans le sens de l'envoi vers l'hôte d'un objet logiciel structuré (41), cette instruction étant par exemple dénommée SendObject . Cet objet logiciel (41) est alors sérialisé, c'est à dire convertit en un ensemble de données au format APDU,

par exemple par l'agent de conversion de carte (21). Cet agent de conversion de carte utilise alors la fonction de réponse (201) pour renvoyer ces données à la carte (2) à travers les moyens de communication (200) de la carte et l'emplacement de connexion (100) de l'hôte.

Une fois reçues dans l'hôte par la fonction de communication (101) gérant l'emplacement de connexion (100), cette fonction de communication transmet ces données à l'agent hôte de conversion (12). Cet agent hôte de conversion (12) désérialise ces données, c'est à dire les converti dans le sens inverse de façon à leur redonner leur structure d'origine, sous la forme d'un objet logiciel (44). Cet objet logiciel structuré (44) est alors transmis à l'agent (11) destinataire par une instruction de lecture d'objet qui va lire les

données reçues, cette instruction étant par exemple dénommée ReadObjectQ .

La figure 2 représente un mode de réalisation de l'invention où les opérations de sérialisation/désérialisation et transmission réalisées par les agents (12,21) de conversion respectivement d'hôte et de carte sont effectuées par deux agents différents (121,122, respectivement 211,212).

L'agent (21) de conversion de carte comprend ainsi un agent (211) de communication et un agent (212) de sérialisation. L'agent (211) de communication gère les opérations de conversion au niveau de l'octet, en échangeant des données sous forme de paramètres d'envoi (32) et de réponse (43) avec la fonction (201) de réponse. En réception de données, cet agent (211) de communication vérifie que les données reçues sont complètes, et effectue une concaténation des paramètres d'envoi (32) en une succession linéaire de données, mémorisée dans un flux (33) d'entrée. En envoi de données, cet agent (211) de communication lit une succession linéaire de données dans un flux (42) de sortie et sépare ces données pour les répartir en paramètres (43) de réponses, compatibles avec les possibilités de transmission de la fonction (201) de réponse.

L'agent (212) de sérialisation gère les opérations de conversion au niveau de l'objet, en réalisant la sérialisation/désérialisation proprement dite.

Lors d'un envoi de données, donc en sérialisation, l'agent (212) de sérialisation, analyse la structure et le contenu d'un objet (41) logiciel structuré à transmettre, et réalise un codage de cet objet sous la forme d'une succession linéaire de données, mémorisée dans le flux (42) de sortie. Lors d'une réception de données, donc en désérialisation, l'agent (212) de sérialisation lit une succession linéaire de données dans le flux (33) d'entrée. Il analyse alors les données qui s'y trouvent et reconstitue l'objet (34) logiciel structuré qu'elles représentent.

La figure 3 représente un mode de réalisation de l'invention, où la carte peut comporter plusieurs agents (221,222, 223,231) susceptibles d'être destinataire pour le procédé selon l'invention, ces agents pouvant être répartis dans une ou plusieurs applications (22,23). De façon à pouvoir traiter tous les échanges de données entre la carte (2) et l'hôte (1), le procédé selon l'invention prévoit un agent (210) d'interposition par qui transitent tous les échanges de données structurées entre la carte (2) et l'hôte (1).

Dans ce mode de réalisation, l'agent (210) d'interposition reçoit toutes les données transmises à la carte, en lieu et place de l'application (22) ou l'agent (221) destinataire, et quel que soit ce destinataire. Cet agent (210) d'interposition va alors faire effectuer la concaténation des paramètres (32) d'envoi par l'agent (211) de communication, et faire ensuite désérialiser les données (33) résultantes par l'agent (212) de sérialisation, comme décrit cidessus. Une fois ces données reconstituées en un objet (34) logiciel structuré, c'est ce même agent (210) d'interposition qui va transmettre cet objet (34) structuré à l'agent (221) logiciel qui était destinataire des données (32) lors de leur réception. Dans un mode de réalisation (non représenté), les données (32) reçues par l'agent (210) d'interposition contiennent une information représentant l'identification de l'agent (221) destinataire, ou bien l'agent (210) d'interposition ajoute une telle information à ces mêmes données (32) avant de les transmettre. L'objet (34) structuré résultant de la désérialisation est alors directement adressé par l'agent (212) de désérialisation ou par un agent de distribution (non représenté).

De la même façon, l'agent (210) d'interposition reçoit toutes les données (41) envoyées vers l'hôte par une application (22) ou un agent (221) émetteur. Cet agent (210) d'interposition va alors faire sérialiser ces données par l'agent (212) de sérialisation en un flux (42) de sortie, puis faire concaténer ce flux (42) de sortie par l'agent (211) de communication, comme décrit cidessus. Les données obtenues seront alors envoyées par la fonction (201) de réponse vers le terminal (1) à travers les moyens de communication (200,100) sous la forme de paramètres (43) de réponse.

Dans un mode de réalisation (non représenté), l'agent (210) d'interposition s'intercale au sein de la chaîne (201, 211, 212,221) de transmission et de conversion. En réception dans la carte (commande d'écriture de la part de l'hôte), l'agent (210) d'interposition dirige les données ou objets reçus vers leur destinataire (221,222, 223,231) au sein de la carte à partir d'informations inclues dans les données reçues. En émission depuis la carte (commande de lecture de la part de l'hôte), l'agent (210) d'interposition peut également être prévu pour recevoir les données ou objets à émettre et leur affecte une information représentant leur émetteur (221,222, 223,231).

Entre d'une part l'hôte (1), que ce soit le terminal lui-même ou un agent logiciel quelconque capable de gérer ce terminal, et d'autre part un agent ou une application présent sur la carte, on peut considérer que les échanges d'informations se font donc sur deux niveaux différents : au niveau de l'octet d'une part, et au niveau de l'objet d'autre part.

Au niveau des objets, les données organisées en objets logiciels structurés à transmettre sont converties en un flux linéaire de données et réciproquement. Cette étape de sérialisation est celle qui gère la structure des objets et est réalisée à l'intérieur de chaque plate-forme par l'agent de sérialisation.

Au niveau des octets, ou suites d'octets, les données agencées en simples flux linéaires sont transmises par bribes par l'intermédiaire de la fonction de transmission, par exemple au format APDU, qui est le seul moyen d'échange d'informations entre la carte et le monde extérieur. Ces échanges

sont gérés par les agents de communication hôte et de la carte, qui communiquent entre eux en s'envoyant des paramètres grâce à cette fonction de transmission.

De façon à fournir à l'utilisateur des commandes transparentes, les différents processus sont implémentés dans une ou plusieurs classes, au moins une fonctionnant dans la carte et une fonctionnant dans le terminal ou l'hôte en général. Dans le langage Java&commat;, le procédé selon l'invention peut ainsi fournir une classe ObjectIOApplet pour la carte et une classe ObjectlOProxy pour l'hôte, par exemple selon la syntaxe suivante :

<tb>
<tb> class <SEP> ObjectIOProxy <SEP> {
<tb> void <SEP> writeObject <SEP> (Object <SEP> o) <SEP> ;
<tb> Object <SEP> readObject <SEP> () <SEP> ;
<tb> }
<tb>

La classe ObjectIOProxy définissant une classe dans l'hôte, fournissant à l'application de l'utilisateur les commandes d'écriture d'objet writeObject (Object) et de lecture d'objet readObject () .

<tb>
<tb> class <SEP> ObjectIOApplet <SEP> {
<tb> void <SEP> process <SEP> (Object <SEP> o) <SEP> ;
<tb> void <SEP> sendObject <SEP> (Object <SEP> o) <SEP> ;
<tb> }
<tb>

La classe ObjectIOApplet définissant une classe dans la carte, fournissant à l'application de l'utilisateur les commandes de traitement d'objet process (Object) et d'envoi d'objet sendobjecto ; et
La carte étant essentiellement passive, l'ensemble de ces conversions et transmissions se fait sur initiative de l'hôte, par une instruction dans le code déclenchant l'envoi d'une commande APDU. C'est cette commande qui va déclencher l'opération de conversion demandée auprès de l'agent concerné.

Les commandes process (Object) et sendobjecto , lorsqu'elles sont exécutées dans le code de l'application de carte, ne déclenchent donc pas directement les opérations de conversion correspondantes. La commande sendobjecto va mémoriser l'objet à envoyer dans une queue ou file de sortie, par exemple qout , où les objets à sérialiser pour transmission seront

introduits par une commande d'introduction du type qout. push (object) . Lors du déclenchement d'une opération de sérialisation, ces objets à transmettre seront alors extraits de cette file de sortie dans l'ordre où ils y ont été introduits.

De même, la commande va extraire d'une file d'entrée, par exemple qin , un objet sérialisé lors d'une opération précédente déclenchée par

l'hôte. Cette extraction se fera alors par une commande d'extraction du type qin. pOP .

Les opérations de lecture, écriture, sérialisation et désérialisation sont alors gérées depuis l'hôte par la classe ObjectIOProxy , grâce à des commandes transparentes à l'utilisateur. Ces commandes peuvent être implémentées dans le code de cette classe, par exemple sous la forme suivante : - card. Serialize out : lance dans la carte la sérialisation, comme décrit ci- dessous, des objets à envoyer. Ces objets peuvent avoir été mémorisés dans une file d'attente de sortie lors de l'exécution d'une instruction sendobjecto par l'application de la carte.

- card. Read : lance dans la carte la lecture des données du flux de sortie et leur transmission vers l'hôte, comme décrit ci-dessous.

- card. Write : lance l'envoi de données vers la carte et leur écriture dans le flux d'entrée, comme décrit ci-dessous.

- card. Serialize In : lance dans la carte la dé-sérialisation, comme décrit ci-dessous, des objets présents dans le flux d'entrée.

Dans le mode de réalisation décrit ici, le flux de sortie et le flux d'entrée de la carte sont mémorisés dans une même structure mémoire circulaire.

D'autres modes de réalisation sont bien sûr possibles utilisant une structure mémoire différente pour chaque flux, ou utilisant d'autres types de structures mémoires.

Une structure de mémoire circulaire signifie en l'occurrence un ensemble d'emplacements de mémoire se suivant, dont le premier emplacement est considéré par le système comme étant immédiatement à la

suite du dernier emplacement. C'est à dire qu'une succession linéaire de données peut être mémorisée dans une telle structure en commençant à n'importe quel emplacement sans perdre sa continuité, du moment que la longueur de cette succession n'est pas supérieure au nombre total d'emplacements.

Le fait que les flux d'entrée et de sortie partagent la même structure circulaire consiste à mémoriser les données qu'ils contiennent dans des zones différentes de cette même structure circulaire. Les données contenues dans ces flux étant effacées au fur et à mesure de leur lecture, immédiatement ou lors d'une opération, la longueur et la position de ces deux flux varient à l'intérieur de cette structure circulaire. Lorsque l'un des deux flux n'a plus de place pour mémoriser de nouvelles données parce qu'il est bloqué par les données non effacées de l'autre flux, il suffit alors de traiter cet autre flux pour libérer la place qu'il occupe.

Une telle structure circulaire permet de n'utiliser que peu de ressources mémoire tout en traitant des flux d'une longueur non déterminée à l'avance. Il suffit pour cela que les différentes opérations agissant sur ces deux flux s'intercalent de façon suffisamment équilibrée.

Au niveau des octets, depuis le flux de sortie d'une plate-forme vers le flux d'entrée de l'autre plate-forme, et réciproquement, les échanges de données se font de la façon suivante.

Lorsque l'hôte veut obtenir des données se trouvant dans le flux de sortie de la carte, il émet une commande de lecture, par exemple selon la syntaxe Java&commat; : card. Read . Cette commande lance une session de lecture, qui est typiquement divisée en plusieurs transactions, représentant chacune une itération du processus.

Pour initier la session de lecture, à travers son agent de communication et sa fonction de transmission, l'hôte émet une commande au format APDU, assortie de paramètres d'envoi (P1 et P2, soit un entier court) représentant la longueur de données qu'il veut recevoir. A réception de cette commande, de

l'agent de communication de carte lit un premier bloc de données dans le flux de sortie de la carte et le transmet à la fonction de réponse de la carte. Ce premier bloc de données est alors retourné à l'hôte en tant que données retournées (DataR) dans la réponse à la commande APDU.

Chaque itération successive du processus de lecture comprend alors l'envoi par l'hôte d'une commande APDU assortie de paramètres d'envoi (P1 et P2, soit un entier court) représentant la longueur des données déjà reçues. Une fois reçue par l'agent de communication de carte, cette longueur fait office d'accusé de réception pour les envois précédents. Ainsi, l'agent de communication retourne comme données de réponse (DataR) les données du flux de sortie suivant immédiatement la longueur indiquée par l'hôte. Il est à noter que la lecture des données dans le flux de sortie se fait sans effacement de celles-ci, ce qui permet leur ré-envoi en cas de besoin. On comprend bien qu'ainsi aucune donnée ne peut être oubliée dans cette transmission.

La session de lecture se termine lorsque la longueur demandée par l'hôte a été bien reçue, par arrêt des itérations de la part de l'hôte. La session peut également se terminer, ou s'interrompre, si l'agent de communication de carte renvoie une donnée (par exemple un champ DataR de longueur nulle) ou un code (SW1 ou SW2) signifiant que toutes les données disponibles dans le flux de sortie ont déjà été envoyées. Dans le cas d'un flux de sortie vide dans la carte, il incombe alors à l'hôte de déclencher dans la carte une nouvelle

opération de sérialisation d'objets depuis la file de sortie qout de la carte vers le flux de sortie de la carte, pour que ce flux de sortie reçoive de nouvelles données.

Lorsque l'hôte veut envoyer à la carte des données se trouvant, il émet une commande d'écriture, par exemple selon la syntaxe Java&commat; : card. Write . Cette commande lance une session d'écriture, qui est typiquement divisée en plusieurs transactions, représentant chacune une itération du processus.

Pour initier la session d'écriture, à travers son agent de communication et sa fonction de transmission, l'hôte émet une commande au format APDU,

assortie de paramètres d'envoi (P1 et P2, soit un entier court) représentant la longueur des données qu'il veut transmettre. Le champ de données (DataT) de cette première commande APDU contient alors le premier groupe ou bloc de données à envoyer, ce bloc de données étant lu dans le flux de sortie de l'hôte.

A réception de cette commande, la fonction de réponse de la carte transmet ce premier bloc de données à l'agent de communication de carte. L'agent de communication de carte écrit alors ce premier bloc de données dans le flux d'entrée de la carte.

Chaque itération successive du processus d'écriture comprend alors l'envoi par l'hôte d'une commande APDU assortie de paramètres d'envoi (P1 et P2, soit un entier court) représentant la longueur des données déjà envoyées. Le champ de données (DataT) de cette première commande APDU contient alors le groupe ou bloc de données suivant, lu dans le flux de sortie de l'hôte. A réception de cette commande, la fonction de réponse de la carte transmet ces paramètres et ce bloc de données à l'agent de communication de carte. L'agent de communication de carte compare alors la longueur de données annoncées dans les paramètres d'envoi (P1 et P2) avec la longueur des données déjà reçues depuis le début de la session d'écriture. On comprend bien qu'ainsi aucune donnée ne peut être oubliée dans cette transmission.

Si cette comparaison ne relève pas d'erreur, l'agent de communication de carte écrit alors ce bloc de données dans le flux d'entrée de la carte. En cas d'erreur, l'agent de communication retourne à l'hôte un code ou un indice indiquant une erreur et/ou représentant la nature de cette erreur. Ce code ou indice peut être retourné à travers les paramètres de réponse (SW1 et SW2) de la fonction de réponse, ou à travers le champ de données retournées (DataR) ou la longueur de ce champ, ou une combinaison de ces éléments.

La session d'écriture se termine lorsque la longueur annoncée par l'hôte a été bien transmise, par arrêt des itérations de la part de l'hôte. La session peut également se terminer, ou s'interrompre, si l'agent de communication de carte renvoie un code ou indice signifiant que le flux d'entrée de la carte ne peut plus accueillir de nouvelles données. Il incombe

alors à l'hôte de déclencher dans la carte une ou plusieurs opérations permettant de libérer de l'espace dans la structure mémoire qui contient ce flux d'entrée.

Il peut s'agir de déclencher dans la carte une nouvelle opération de désérialisation de données depuis le flux d'entrée vers la file d'entrée qin d'objets accessibles à l'application carte. Il peut s'agir également de déclencher une nouvelle session de lecture pour recevoir des données contenues dans le flux de sortie de la carte, et libérer ainsi de l'espace dans la structure circulaire qui contient ces deux flux.

Au niveau des objets, les opérations de sérialisation et désérialisation se font entre les flux de données et les agents ou applications de la carte, et réciproquement, de la façon suivante.

Au sein de la carte, les objets sont désérialisés depuis le flux (33) d'entrée vers la file d'entrée qin où ils sont directement accessibles à l'instruction Process (Object) , fournie par la classe ObjectIOApplet > et utilisée par l'agent ou l'application destinataire.

Dans l'implémentation du procédé selon l'invention, lorsque l'hôte veut déclencher dans la carte une opération de désérialisation, il utilise une instruction, par exemple selon la syntaxe Java&commat; card. Serialize In .

Dans la figure 4 est illustrée la désérialisation d'un objet (34) logiciel structuré, à travers le décodage des données du flux (32) d'entrée correspondant à cet objet (34), et les opérations de mémorisation et de création des composants de la structure de ce même objet (34) structuré, ou objet résultat.

En lisant l'une après l'autre les données mémorisées en une succession linéaire dans le flux (33) d'entrée, l'agent (212) de sérialisation interprète ces mêmes données selon un codage déterminé et crée un objet (34) logiciel structuré en fonction de cette interprétation. Dans cette succession de données mémorisée dans ce flux d'entrée, certaines données peuvent avoir une valeur déterminée qui sera interprétée comme marquant la

présence d'une balise de codage. Ce décodage peut se faire par appel d'une méthode d'allocation propre à chaque type d'objet structuré à décoder, par exemple selon la syntaxe suivante :
Typeobject : : decode (Object, InputStream) pour le décodage d'un objet Object de type Typeobject à partir du flux d'entrée Input Stream .

Ce codage comprend un jeu de balises ayant chacune une signification déterminée, et correspondant chacune à au moins une valeur spécifique d'une donnée dans le flux d'entrée. Ainsi, dans le flux d'entrée, chaque donnée d'une valeur correspondant à une de ces balises est interprétée par l'agent de sérialisation lors du processus de désérialisation.

Selon les applications du procédé selon l'invention, l'agent (212) de sérialisation pourra être prévu pour reconnaître plusieurs jeux de balises, ou des balises pouvant être représentées chacune par plusieurs valeurs différentes de données, sans sortir de l'esprit de l'invention. Une telle diversité pourra en particulier être utilisée pour permettre une compatibilité d'une même carte (2) ou type de carte avec plusieurs terminaux ou environnements hôtes différents.

Dans le mode de réalisation décrit ici, le codage comprend des balises de type NULL , NEW , REF et DATA .

- Une balise NULL représente une absence de donnée, tout en occupant un emplacement dans la structure en cours de construction par l'agent sérialisation.

- Une balise NEW indique à l'agent de sérialisation le début de la description d'un nouvel objet, cet objet pouvant être soit un objet (34) logiciel structuré résultant de la conversion, soit un objet, dit élément, composant une partie d'un tel objet (34) structuré.

- Une balise REF indique la désignation d'un objet, un autre ou le même, en tant que source de la valeur de tout ou partie de l'objet ou élément en cours de description. Il s'agit d'affecter une valeur par référence.

- Une balise DATA indique que les données suivantes représentent la valeur, ou contenu, de l'objet ou élément en cours de description. Ce contenu peut

être constitué de données brutes représentant directement une ou des valeurs à affecter à cet objet, ou inclure d'autres balises indiquant à nouveau des objets ou références définissant ce contenu.

Selon son type, une balise peut être suivie d'une ou plusieurs données, dont l'interprétation sera déterminée par la signification de cette même balise.

- Ainsi, à la lecture d'une balise NEW, l'agent de sérialisation saura qu'il doit interpréter la donnée suivante comme représentant le type du nouvel objet décrit.

- De même, à la lecture d'une balise REF, l'agent de sérialisation saura qu'il doit interpréter la donnée suivante comme représentant un identifiant de l'objet désigné comme source de cette valeur par référence.

Dans le mode de réalisation décrit ici, les balises comme les identificateurs de type et de référence sont codés sur un octet, mais il est évident que le procédé selon l'invention permet aussi bien d'utiliser d'autres codages, différents voire plus complexes ou explicites, en fonction des besoins et des possibilités de l'environnement informatique concerné.

Au fur et à mesure de sa lecture des données du flux (32) d'entrée, l'agent (212) de sérialisation analyse la valeur de chacune de ces données, et effectue la création puis le remplissage des objets ou éléments (340,341, 342, 343,344) composant l'objet (34) résultat. Cette lecture du flux (32) d'entrée se répètera alors jusqu'à la reconstruction complète de l'objet (34) représenté par ce flux d'entré. Cette création peut se faire par appel d'une méthode d'allocation propre à chaque type d'objet, par exemple selon la syntaxe suivante :
Typeobject : : malloc () pour la création ou allocation d'un objet de type Typeobject lors de la désérialisation.

Du fait que de tels objets peuvent présenter une structure différente, la gestion de cette création et de ce remplissage se font, directement ou non, par un agent (TMO, TM1, TM2) de contrôle de type spécifique au type de l'objet à créer, par exemple un agent type marshaller du langage Java&commat;. Cet agent de contrôle de type est spécifique à un ou plusieurs types d'objets, et peut être

géré par un agent (TMG) gestionnaire de types, par exemple un agent type manager du langage Java&commat;. Cet agent gestionnaire de types mémorise en particulier les identifiants des différents types d'objets créés au cours du processus de désérialisation. Cet agent (TMG) gestionnaire de types comprend également le code et les procédures, ou méthodes, spécifiques à ces différents types d'objets et utilisés pour sérialiser/désérialiser ces mêmes objets. C'est également lui qui gère la liste des objets et leurs allocations, ce qui permet de réaliser de nouvelles allocations de réutiliser une allocation libre pour créer un nouvel objet lors du décodage.

De façon typique, cet agent (TMG) gestionnaire de types comprend des informations sur tous les différents types d'objets pouvant être gérés dans la carte. Ces informations peuvent être générées par un hôte, par exemple lors d'une phase de programmation de la carte. Elles sont alors transmises avec les classes ( apples ) utilisées par les applications, sous forme de code programme ( glue code ) s'ajoutant au code de l'agent (TMG) gestionnaire de types.

Par l'utilisation d'un tel agent gestionnaire de type, ainsi que d'agents de contrôle de type décrits ci-dessous, le procédé selon l'invention permet de gérer la sérialisation et la désérialisation d'objets structurés, de types de base ou de types construits, dans une plate-forme embarquée dont l'environnement de programmation, comme JavaCard par exemple, ne comporte pas un tel gestionnaire de type.

Au cours du décodage, la création d'un objet ou élément correspond à une allocation de cet objet, c'est à dire la réservation d'un espace mémoire déterminé et l'attribution de cet espace à cet objet. Certains environnements embarqués, et en particulier Javacard&commat;, ne disposent pas d'outils logiciels permettant de rendre à nouveau disponible l'espace mémoire auparavant occupé par un objet qui a été supprimé, comme par exemple un agent garbage collector du langage Java&commat; classique. Lors de la création d'un objet par l'agent (212) de sérialisation, le procédé selon l'invention peut prévoir

la possibilité de réaliser cette création en allouant à cet objet un espace mémoire précédemment occupé par un autre objet devenu inutile, par exemple de même type que l'objet à créer. Il est ainsi possible d'une fois sur l'autre de réutiliser l'espace mémoire de la carte, qui est une ressource précieuse dans de nombreux cas, car peu abondante.

Dans l'exemple illustré en figure 4, le flux (32) d'entrée correspond à un objet (34) structuré résultat dont la structure, ou graphe, peut être décrite en langage Java&commat; sous la forme suivante :

<tb>
<tb> Typel <SEP> : <SEP> class <SEP> B <SEP> {boolean <SEP> bo <SEP> ;}
<tb> Type2 <SEP> : <SEP> Typel+ <SEP> {int, <SEP> byte, <SEP> TypeO} <SEP> class <SEP> X <SEP> extends <SEP> B <SEP> {
<tb> int <SEP> i <SEP> ;
<tb> byte <SEP> by <SEP> ;
<tb> Y <SEP> y <SEP> ;
<tb> }
<tb> TypeO <SEP> : <SEP> {Typel} <SEP> class <SEP> Y <SEP> {B <SEP> b <SEP> ;}
<tb>

Lors de la lecture du flux (33) d'entrée, l'agent de sérialisation lit tout d'abord une balise (321) NEW. Il lit donc la donnée (322) suivante et mémorise alors la demande de création d'un objet de type 2. Conformément à cette balise (321) NEW d'identifiant 2, l'agent de sérialisation va créer un nouvel objet, x (340) de classe X dans l'exemple, par l'intermédiaire de l'agent (TM2) de contrôle de type correspondant à ce même type (Type2). S'agissant du début de la description d'un objet résultat, ce nouvel objet sera l'objet racine de l'arborescence du graphe de cet objet résultat.

Lors de cette création, l'agent de sérialisation va attribuer à l'objet (340) créé un index (3402), cet index valant 0 dans l'exemple. Cet index (3402) peut ainsi servir de référence à d'autres éléments ou parties d'éléments lors de la construction de cet objet (34) résultat, et permettre de savoir si le contenu de cet élément à ou non été rempli.

L'agent de sérialisation va alors mémoriser le type et l'index de cet objet dans une structure mémoire, dite pile de types (TYST). Cette pile de types

est une structure de type pile mémoire, c'est à dire où l'on peut mémoriser (action dite push en anglais) des données l'une sur l'autre, et dont on ne peut lire et extraire (action dite pop en anglais) une donnée que lorsque ceux mémorisés après lui ont déjà été extraits. Les données quittent cette pile dans l'ordre inverse de celui où elles y ont été mémorisées ( dernier entré

premier sorti , ou LIFO pour Last In First Out ).

L'agent de sérialisation va également mémoriser le type de ce nouvel objet (340) ainsi que son index, comme correspondant à l'objet, dit objet (OBJ) en cours, qui sera rempli par les données suivantes du flux d'entrée.

La balise suivante est une balise DATA suivie de deux données (324, 325) brutes, qui ne sont pas des balises ni des identifiants. Ces deux données vont donc être mémorisées dans l'objet (OBJ) en cours, c'est à dire x (340), en tant que valeur des éléments (342,343) suivants. Ces deux éléments suivants étant respectivement de types entier (int) dénommé i et octet (byte) dénommé by , ces éléments vont donc prendre respectivement les valeurs contenues dans ces deux données (324,325) du flux d'entrée.

La balise suivante est une balise NEW, suivie d'une donnée indiquant un type 0. Cette séquence indique que l'élément suivant de l'objet x est un objet de type 0. L'agent de sérialisation va donc affecter à cet objet (344) un index (3442), 1 dans l'exemple, et ajouter ( push ) l'index et le type, à savoir 0, de ce nouvel objet (344) sur la pile (TYST) de types. L'agent de sérialisation va également faire créer un objet de type 0, dans l'exemple y (344) de type Y, par l'agent (TMO) de contrôle de type correspondant au type 0.

A travers l'agent (TM2) de contrôle de type correspondant à l'objet (OBJ) en cours, l'agent de sérialisation sait que cet objet (OBJ) en cours, à savoir x , n'est pas rempli complètement. La balise suivante, une balise DATA suivie d'une donnée (329) brute, sera donc affectée comme valeur de l'élément (341) suivant de l'objet en cours, c'est à dire comme valeur de l'élément dénommé bo et de type booléen qui est le dernier élément de l'objet x .

Maintenant, à travers l'agent (TM2) de contrôle de type correspondant à l'objet (OBJ) en cours, l'agent de sérialisation sait que cet objet (OBJ) en cours, à savoir x (340), est complètement rempli. L'index (3402) de cet objet (340) rempli est donc mémorisé dans la pile (OBJST) d'objets, avec l'identifiant de cet objet (340) au sein de la carte. L'agent de sérialisation va alors clore le remplissage de l'objet en cours et dépiler, ou extraire ( pop ), le type et l'index mémorisés sur le dessus de la pile (TYST) de types. Le dessus de la pile doit bien sûr être compris comme l'emplacement de cette pile accessible en premier. Le type et l'index extrait de la pile de types, 0 et respectivement 1 dans l'exemple, vont alors être mémorisés comme correspondant à un nouvel objet (OBJ) en cours.

La balise suivante est une balise DATA, qui indique donc un remplissage de l'objet en cours, c'est à dire y . Cette balise est suivie d'une balise (3211) REF et d'une donnée (3312), 0 dans l'exemple. L'agent de sérialisation va donc affecter à l'objet y (344) une valeur par référence, c'est à dire une simple liaison avec la valeur de l'objet dont l'index (3402) est désigné par cette référence (3212). L'objet y aura donc une valeur définie comme faisant référence à l'objet x qui porte l'index 0 au sein du processus de désérialisation. Cette liaison pourra alors être définie dans l'objet (34) résultat par la mémorisation de l'identifiant de cet objet x dans la carte, cet identifiant étant lu dans la pile (OBJST) d'objets grâce à cet index.

Maintenant, à travers l'agent (TMO) de contrôle de type correspondant à l'objet (OBJ) en cours, l'agent de sérialisation sait que cet objet (OBJ) en cours, à savoir y , est complètement rempli. L'index (3442) de cet objet (344) rempli est donc mémorisé dans la pile (OBJST) d'objets, avec l'identifiant de cet objet (344) au sein de la carte. L'agent de sérialisation va alors clore ce remplissage et consulter la pile (TYST) de types.

Du fait que la pile (TYST) de types est vide après extraction du type de l'objet y , c'est à dire qu'il n'y a plus de types construits à reconstituer, l'agent de sérialisation conclut que l'objet (34) résultat est complètement créé.

Dans une variante, la création ou allocation d'un nouvel objet peut se faire à n'importe quel moment du processus de désérialisation, à partir de la lecture de la balise NEW indiquant ce nouvel objet, jusqu'au début du remplissage de cet objet.

Dans une variante, l'index utilisé lors de la désérialisation d'un objet est identique à l'identifiant de l'objet dans la carte.

Au sein de la carte, les objets sont sérialisés vers le flux (42) de sortie depuis la file de sortie qout , qui est directement accessible à l'instruction SendObject fournie par la classe ObjectlOApplet et utilisée par l'agent ou l'application destinataire.

Dans l'implémentation du procédé selon l'invention, lorsque l'hôte veut déclencher dans la carte une opération de sérialisation, il utilise une instruction, par exemple selon la syntaxe Java&commat; card. Serialize Out .

Dans la figure 5 est illustrée la sérialisation d'un objet (41) logiciel structuré, ou objet de départ, à travers l'analyse des composants de la structure de ce même objet (41) structuré puis le codage sous forme de données mémorisées dans le flux (42) de sortie correspondant à cet objet (41) de départ.

Cette fonctionnalité de sérialisation est implémentée dans une méthode, c'est à dire une action ou procédure disponible pour un objet d'un type déterminé, et peut présenter la syntaxe Java&commat; suivante :
Typeobject : : (Object, OutputStream) étant une méthode utilisée pour le codage d'un objet Object de type Typeobject vers le flux de sortie OutputStream .

Typeobject : : getSuper () étant une méthode utilisée pour obtenir les informations concernant le type et les types construits d'un objet, lors du codage d'un l'objet de type Typeobject .

Les types de bases sont en général des types prévus et gérés par l'environnement ou le langage de programmation, par opposition à des types,

dits types construits, définis comme une combinaison de plusieurs objets. Des types de base courants sont par exemple les types entier, booléen, octets ( integer , boolean , byte ) pour un environnement embarqué, et également entier long, réel, réel long, caractère ( long , real , double , char ) pour des environnements plus complets.

Pour cette sérialisation, l'agent (212) de sérialisation parcourt de façon récursive l'ensemble de la structure, ou du graphe, de l'objet (41) de départ à sérialiser, et en analyse les éléments (410,412, 413,414, 411), en

commençant par l'objet ou élément racine , x dans l'exemple. Le graphe de l'objet (41) de départ présenté dans l'exemple est le même que décrit cidessus pour la figure 4. Pour chacun des éléments du graphe présentant un type construit, l'agent de sérialisation fait appel à un agent (TMO, TM1, TM2) correspondant à ce même type construit.

La description dans le flux (42) de sortie de l'objet (41) de départ commence par l'écriture d'une balise NEW suivie de l'identifiant du type de l'élément racine, l'objet x de type 2 dans l'exemple. Cet objet racine est alors désigné comme objet (OBJ) en cours. Par ailleurs, cet objet reçoit un index, 0 dans l'exemple, puis son type et son index sont introduits (action push ) dans la pile (TYST) de types.

La description se poursuit ensuite par l'écriture d'une balise DATA, suivie des données indiquant les valeurs ou références correspondant au contenu de cet objet racine. Du fait que l'objet racine x contient un objet y (414), qui est d'un type construit, la description de l'objet racine comprendra une balise NEW suivie du type de cet objet y , NEW 0 dans l'exemple, en lieu et place de la valeur de cet objet y . Lors de l'écriture de cette balise NEW, un index (4142) lui est attribué, 1 dans l'exemple. Puis l'index et le type de ce nouvel objet sont introduits (action push ) dans la pile (TYST) de types.

Une fois terminée la description du contenu de l'objet (OBJ), c'est à dire t'objet x (410), son index est mémorisé dans la pile (OBJST) d'objets

avec l'identifiant de cet objet. L'agent de sérialisation consulte alors la piles de types, en extrait (action pop ) le type et l'index de l'objet y Il mémorise cet objet y comme nouvel objet (OBJ) en cours, et commence alors la description du contenu de cet objet y . Cet objet étant constitué d'une simple référence (4141) à l'objet racine x , les données écrites dans le flux de sortie seront constituées d'une balise REF suivie d'une donnée valant l'index de l'objet à désigner en référence, c'est à dire l'objet x d'index 0 dans l'exemple.

Une fois terminée la description du contenu de cet objet en cours, c'est à dire l'objet y (414), son index est mémorisé dans la pile (OBJST) d'objets avec l'identifiant de cet objet. L'agent de sérialisation consulte alors la piles de types, en extrait (action pop ) le type de l'objet x qui étaient mémorisés

sous l'objet y dans cette pile de types. Du fait que l'index de l'objet x est déjà mémorisé dans la pile (OBJST) d'objets, l'agent de sérialisation sait que cet objet x a déjà été sérialisé, ou décrit. Il consulte donc à nouveau la pile de types, constate qu'elle est vide, et conclue donc que l'ensemble des éléments composants de l'objet (41) de départ ont été entièrement décrits dans le flux (42) de sortie.

Du fait de la récursivité de ces algorithmes, il est ainsi possible de réaliser ces opérations de sérialisation et désérialisation à travers un code programme occupant suffisamment peu de place en mémoire pour pouvoir être mémorisé dans une plate-forme embarquée, par exemple une carte à puce ou un objet informatisé portable au standard JavaCard. La concision de ces algorithmes permet également d'exécuter ces opérations dans un processeur de faible puissance, comme ceux dont disposent de telles plates-formes embarquées.

De façon à équilibrer les quantités de données stockées sous forme intermédiaire, les différentes opérations de lecture, écriture, sérialisation et désérialisation demandées par l'application (11) hôte peuvent être entrelacées

dans une ou plusieurs boucles de programme Une telle boucle exécute à chaque itération une commande de chacune de ces opérations, par exemple selon la syntaxe Java&commat; suivante :
Do
Do card. Serialize out While (ok out)
Do card. Read While (data read)
While (data in) card. Write
While (ok in) card. Serialize in
Loop
Dans cet exemple, les première et dernière lignes ( Do et Loop ) détermine la répétition d'une boucle constituée des quatre lignes de code qu'elles encadrent. Une telle boucle peut bien sûr être combinée avec d'autres opérations, et comporter diverses conditions d'interruption de la répétition.

A l'intérieur de la boucle, la première ligne indique de déclencher dans la carte une session de sérialisation, vers le flux de sortie de la carte, des objets précédemment mémorisés dans la file de sortie qout par une commande SendObjectQ . Cette session est ensuite répétée tant qu'une condition dénommée ok out est remplie, par exemple tant qu'il y a des

objets à envoyer dans la file qout et que le flux de sortie n'est pas plein.

La deuxième ligne indique de déclencher une session de lecture par l'hôte des données contenues dans le flux de sortie de la carte. Cette session est ensuite répétée tant qu'une condition dénommée data read est remplie, par exemple tant que des données sont reçues depuis la carte.

La troisième ligne indique d'effectuer et répéter une session d'écriture dans le flux d'entrée de données venant de l'hôte. Cette session ne s'effectue et ne se répète que si et tant qu'une condition dénommée data in est remplie. Par exemple, tant qu'il y a des données à envoyer à la carte, et que le flux d'entrée de la carte n'est pas plein.

La quatrième ligne indique d'effectuer et répéter une session de désérialisation des données contenues dans le flux d'entrée de la carte, vers la file d'entrée qin d'objets structurés, d'où ils sont extraits par une commande process (Object) . Cette session ne s'effectue et ne se répète que si et tant

qu'une condition dénommée ok in est remplie. Par exemple, tant qu'il y a des données à désérialiser dans le flux d'entrée de la carte.

Dans le cas d'une carte passive, par exemple au standard JavaCard&commat;, c'est typiquement la fin de l'opération de sérialisation d'un objet qui déclenchera son traitement, par exemple en appelant automatiquement la méthode process (Object) .

Il est à noter que seules les opérations à effectuer du côté de la carte sont illustrées dans cet exemple. Les opérations symétriques effectuées du côté de l'hôte peuvent être réalisées de façon similaire comme de façon totalement différente, selon les ressources matérielles et logicielles disponibles, sans sortir de l'esprit de l'invention.

Du fait que ces différentes opérations complémentaires sont entrelacées dans une boucle logicielle pouvant se répéter de façon récursive, les différentes phases constituant le transfert d'un objet structuré peuvent être réalisées en parallèle, dans le cadre d'une seule exécution ou d'une seule commande de transfert. En utilisant des flux de données mémorisés de façon circulaire réutilisant indéfiniment un même espace mémoire comme décrit plus haut, une même commande peut déclencher le transfert complet d'un objet structuré sans limite de taille malgré les capacités limitées de la plate-forme embarquée.

Lorsque l'ensemble des opérations de conversions décrites ci-dessus est implémenté, c'est à dire programmé, dans une ou plusieurs procédures chargées dans t'hôte et dans la plate-forme embarquée. Ces procédures peuvent alors être accessibles à l'utilisateur à travers quelques commandes simples.

Dans le mode de réalisation décrit ici, appliqué au langage Java&commat; et à l'environnement JavaCard&commat;, le programmeur d'une application n'a ainsi qu'à utiliser ces quelques commandes simples pour réaliser son application. Ces commandes réalisent l'ensemble des opérations intermédiaires de façon

transparente pour l'utilisateur, c'est à dire sans qu'il ait besoin de se préoccuper du fonctionnement interne de leur mécanisme.

A titre d'exemple, la a classe ObjectlOProxy , chargée dans la station de traitement ou le terminal hôte, fournit ainsi les commandes WriteObjectQ et ReadObjectQ .

De même, la classe ObjectlOApplet , chargée dans la plate-forme embarquée, fournit les commandes Process (Object) et SendObject . De façon typique, la classe ObjecttOApptet imp ! émente ces commandes par une technique connue de d'extension, c'est à dire par héritage de la classe

IOApplet qui contient la méthode process (APDU) . C'est à dire en ajoutant à cette méthode du code programme qui vient s'ajouter à la méthode initiale et modifier ou remplacer son fonctionnement tel que prévu dans la méthode initiale.

L'instruction WriteObjectQ est utilisée par l'utilisateur dans son application hôte pour réaliser l'envoi d'un objet structuré à l'application de la carte et y déclencher un traitement.

La méthode Process (Object) est appelée automatiquement par la carte à la fin de la réception et dé-sérialisation d'un objet structuré. Le contenu de cette méthode est alors programmé par l'utilisateur dans la partie de son application chargée dans la plate-forme embarquée pour réaliser les opérations souhaitées à partir de cet objet. Cette méthode est alors utilisée de façon similaire à la commande standard process (APDU) existant en JavaCard# pour les seules données au format APDU.

L'instruction SendObject est utilisée par l'utilisateur dans la partie de son application chargée dans la plate-forme embarquée, par exemple à l'intérieur du code de la méthode Process (Object) , pour préparer l'envoi d'un ou plusieurs objets structurés de la plate-forme embarquée vers l'hôte.

Cette instruction est alors utilisée de façon similaire à la commande standard SendAPDU () existant en JavaCard&commat; pour les seules données au format APDU.

L'instruction ReadObjecto est utilisée par l'utilisateur dans son application hôte pour réaliser la réception depuis la plate-forme embarquée du ou des objets structurés que l'application de la carte à préparé dans ce but.

On comprend bien qu'ainsi il est plus aisé à un programmeur, réalisant une application comportant une telle plate-forme embarquée, de transmettre des objets logiciels structurés entre cette plate-forme embarquée et un hôte ou terminal, même si les moyens de communication de cette plate-forme embarquée ne sont aptes qu'à transmettre des données sous forme d'octets ou d'entiers.

Pour le programmeur d'une application embarquée, il peut être utile de disposer de quelques commandes simples permettant de réaliser la désallocation d'un objet logiciel structuré ou la remise à zéro ou effacement de l'espace mémoire correspondant, ainsi que la duplication d'un objet logiciel structuré. Cela est particulièrement vrai lorsque l'environnement de programmation de la plate-forme embarquée ne comprend pas d'outil logiciel ( garbage collector en anglais) gérant la réutilisation de l'espace mémoire déjà alloué, par exemple dans l'environnement JavaCard&commat;.

Dans un mode de réalisation du procédé selon l'invention, l'étape d'analyse de chacun des composants d'un objet logiciel structuré au cours de sa sérialisation peut effectuer selon différentes options. Plusieurs de ces options peuvent être prévues dans l'implémentation d'une même commande de sérialisation, chaque exécution de cette commande étant assortie d'un paramètre indiquant quelle option doit être utilisée. Ces différentes options peuvent également être utilisées séparément dans différentes implémentations de la commande de sérialisation.

Dans une de ces options, lors de l'analyse de chacun des composants d'un objet logiciel structuré au cours de sa sérialisation, l'agent (212) de sérialisation effectue une désallocation de l'espace mémoire contenant ce composant, ou marque ce même composant comme pouvant être réutilisé pour

une nouvelle allocation. Ainsi, une sérialisation selon cette option, dite sérialisation destructive, effectue une conversion d'un objet structuré suivie d'une libération de son espace mémoire.

Dans un mode de réalisation, le procédé selon l'invention peut prévoir une option ou une commande réalisant une telle sérialisation destructive d'un objet structuré mémorisé dans la carte, hors de toute transmission, par exemple dans l'implémentation de ! a ctasse ObjecttOApptet ?. On comprend bien qu'ainsi le procédé selon l'invention permet à l'utilisateur de réaliser aisément la réutilisation de l'espace mémoire occupé par tout ou partie de certains des objets logiciels de son application.

Dans un mode de réalisation (non représenté), le procédé selon l'invention prévoit une option ou une commande réalisant la désérialisation d'un objet structuré en ré-utilisant l'espace mémoire dans la carte d'un objet structuré précédemment détruit, comme décrit ci-dessus. Cette désérialisation est effectuée hors de toute transmission, à partir d'un flux de données contenant des données toutes identiques ou sans signification. Après allocation et écriture d'un tel objet, l'espace mémoire réutilisé ne contiendra plus aucune donnée provenant de l'objet qui l'occupait précédemment. Lorsque cette opération est implémentée par exemple dans la classe ObjecttOApptet , on comprend bien qu'ainsi le procédé selon l'invention permet à l'utilisateur de programmer aisément l'effacement complet d'un espace mémoire correspondant à une allocation déterminée.

Dans un mode de réalisation (non représenté), le procédé selon l'invention prévoit une option ou une commande réalisant la sérialisation d'un objet structuré de départ vers une succession linéaire de données, hors de toute transmission. Cette même succession linéaire de données est alors désérialisée en un objet résultat identique à l'objet de départ mais utilisant un autre espace mémoire. Lorsque cette opération est implémentée par exemple

dans la classe (ObjectlOApplet , on comprend bien qu'ainsi le procédé selon

l'invention permet à l'utilisateur de programmer aisément la duplication à l'identique d'un objet logiciel structuré.

Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.

Claims

REVENDICATIONS

1. Procédé de conversion de données utilisable par une station (2) informatique, dite plate-forme embarquée, comprenant un objet portable incluant au moins un processeur, des moyens de mémorisation, et des moyens de communication aptes à échanger des informations avec un terminal sous la forme d'une ou plusieurs successions linéaires de données, caractérisé en ce qu'il comporte une étape de conversion d'un ensemble de données, dans un sens ou dans l'autre, entre d'une part un agencement en une succession linéaire de données et d'autre part un agencement structuré décrivant ou représentant un ou plusieurs objets logiciels structurés ou hiérarchisés suivant les critères d'un langage de programmation orienté objet.

2. Procédé selon la revendication précédente, caractérisé en ce qu'il comporte des étapes de : - conversion, ou sérialisation, d'un premier ensemble de données à transmettre comportant ou représentant un ou plusieurs objets (31,41) logiciels structurés ou hiérarchisés suivant les critères d'un langage de programmation orienté objet, depuis un agencement structuré décrivant ou représentant cet objet vers une succession linéaire de données représentant ce premier ensemble de données ; - transmission de cette succession linéaire de données par des moyens (200, respectivement 100) de communication, depuis la plate-forme (2) embarquée vers au moins un hôte (1), c'est à dire un terminal ou une station informatique reliée au terminal, ou de cet hôte (1) vers la plate- forme (2) embarquée ; - conversion après transmission, ou dé-sérialisation, de cette succession linéaire de données vers un ensemble de données agencé en un ou plusieurs objets (34, respectivement 44) logiciels structurés reproduisant ou représentant le premier ensemble de données.

3. Procédé selon l'une des revendications précédentes, caractérisé en ce que le terminal hôte (1) envoie des informations à la plate-forme (2) embarquée en utilisant un agent (101) logiciel, dit fonction de transmission, ces informations étant reçues dans la plate-forme embarquée par une fonction (201) de réponse apte à déclencher un traitement (2210) de ces données par au moins un agent (221) logiciel destinataire mémorisé dans la plate-forme embarquée et faisant partie d'au moins une application (21), le procédé comprenant des étapes de : - réception, par un agent (211) de communication en lieu et place de l'agent (221) destinataire, d'un ensemble (32) de données reçues par la fonction (201) de réponse à l'intention de cet agent logiciel destinataire, cet ensemble de données étant agencé en une succession linéaire de données ; - conversion de cet ensemble de données en au moins un objet (34) logiciel, structuré ou hiérarchisé suivant les critères d'un langage de programmation orienté objet ; - transmission de cet objet (34) logiciel structuré à l'agent (221) destinataire et déclenchement d'un traitement (2210) en fonction de cet objet par cet agent destinataire.

4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte des étapes de : - réception par la fonction (201) de réponse, en provenance de la fonction (101) de transmission de l'hôte (1), d'au moins une donnée sous forme d'au moins un paramètre (32) d'envoi, et transmission de ce paramètre à un agent (211) de communication mémorisé ou exécuté dans la plate-forme (2) embarquée ; - conversion, ou concaténation, par l'agent (211) de communication d'au moins un paramètre (32) d'envoi, transmis par l'agent (201) de réponse, en

un ensemble de données agencé en une succession linéaire de données et mémorisation de ces données dans un flux (33) d'entrée dans la plate- forme (2) embarquée ; conversion, ou dé-sérialisation, par un agent (212) de sérialisation, mémorisé ou exécuté dans la plate-forme (2) embarquée, d'au moins une partie des données mémorisées dans ce flux (33) d'entrée vers un ensemble de données comprenant ou représentant au moins un objet (34) logiciel structuré ; - réception de cet objet (34) logiciel structuré ou de ses références par l'agent (221) destinataire.

5. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte des étapes de : - transmission d'un objet (41) logiciel structuré ou de sa représentation depuis un agent (221) logiciel faisant partie d'une application (22) exécutée ou mémorisée dans une plate-forme (2) embarquée vers un agent (212) de sérialisation exécuté ou mémorisé dans cette plate-forme embarquée ; - conversion, ou sérialisation, par cet agent (212) de sérialisation de cet objet (41) logiciel structuré vers un ensemble de données agencé en une succession linéaire de données et mémorisation de ces données dans un flux (42) de sortie dans la plate-forme embarquée ; - conversion par un agent (211) de communication, mémorisé ou exécuté dans la plate-forme (2) embarquée, d'au moins une partie des données mémorisées dans ce flux (42) de sortie vers un ensemble de paramètres (43) de réponse aptes à être transmis par la fonction (201) de réponse ; - transmission de ces paramètres (43) de réponse depuis la plate-forme (2) embarquée vers le terminal hôte (1) par la fonction (201) de réponse, de sa

propre initiative ou en réponse à la fonction (101) de transmission du terminal hôte (1).

6. Procédé selon l'une des revendications précédentes, caractérisé en ce que la succession linéaire de données mémorisée dans le flux (33) d'entrée ou le flux (42) de sortie représente un ou plusieurs objets (31, respectivement 41) logiciels structurés ou hiérarchisés en utilisant une ou plusieurs données, dites balises, d'une ou plusieurs valeurs déterminées représentant chacune une action déterminée à effectuer lors de la désérialisation de cette succession linéaire de données.

7. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'au moins une balise est définie comme représentant une des actions suivantes : - ajout d'un nouvel élément à la structure de l'objet structuré représenté par la succession linéaire de données ; - référence à un élément ou objet, dit objet source, en tant que source de la valeur de tout ou partie d'un élément composant l'objet structuré ; - indication que la ou les données suivantes représentent le contenu d'un élément composant l'objet structuré ; - indication d'une absence de contenu d'un élément composant l'objet structuré.

8. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'agent (212) de sérialisation effectue la sérialisation d'un objet (41) structuré, dit objet de départ, en un ensemble (42) linéaire de données suivant un procédé, dit procédé de sérialisation, traitant au moins un des objets (410 à 414), dits éléments, composant la structure ou l'arborescence de cet objet (41) structuré de départ, selon des étapes de :

9. Procédé selon l'une des revendications précédentes, caractérisé en ce que le procédé de sérialisation effectue la conversion d'un objet (41) structuré vers le flux (42) de sortie en mémorisant au fur et à mesure de ses itérations le type de chaque objet en cours dans une pile (TYST) mémoire, dite pile de types, dont les emplacements sont lus dans l'ordre inverse de leur ordre de mémorisation.

détection, par l'agent (212) de sérialisation du type (4100) d'un élément (410, 414), dit objet en cours, composant la structure ou l'arborescence de cet objet (41) structuré ; - mémorisation dans le flux (42) de sortie d'une donnée représentant une balise indiquant l'ajout d'un nouvel élément, suivie d'une donnée représentant le type (TYOBJ) de l'objet en cours ; - mémorisation dans le flux de sortie, à la suite des éléments qui y sont déjà présents, par un agent de sérialisation de type (TMO, TM1, TM2) associé au type (TYOBJ) de l'objet en cours, 'soit d'au moins une donnée représentant la valeur de tout ou partie (412,413, 411) de l'objet (41) structuré ; 'soit d'au moins une donnée représentant une balise indiquant une référence à un objet (410) en tant que source de la valeur de tout ou partie (414) de l'objet (41) structuré, cette balise étant suivie d'une donnée identifiant ledit objet (410) source ;

10. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'agent (212) de sérialisation effectue la désérialisation d'un ensemble linéaire de données en au moins un objet (34) structuré résultat, suivant un procédé, dit procédé de déséria ! isation, traitant chacune des données mémorisées dans le flux (33) d'entrée, selon des étapes de :

- lecture par l'agent de sérialisation d'au moins une donnée mémorisée dans le flux d'entrée à la suite des données précédemment traitées ; - analyse de cette donnée et réalisation d'une action correspondant à cette donnée.

11. Procédé selon l'une des revendications précédentes, caractérisé en ce que le procédé de désérialisation comprend le remplissage d'un élément, dit objet en cours, c'est à dire l'affectation d'une valeur directe ou indirecte à tout ou partie de cet objet en cours, cet élément composant tout ou partie de la structure de l'objet (34) structuré résultat, la fin du remplissage de l'objet en cours déclenchant - la lecture d'une donnée (TYT2) représentant un type d'objet mémorisé dans le prochain emplacement d'une structure de mémoire, dite pile (TYST) de types, et l'effacement de cette donnée de cet emplacement ; - la mémorisation, comme type (TYOBJ) d'un nouvel objet en cours, du type représenté par la donnée (TYT2) lue dans la pile de types.

12. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'objet (34) structuré créé par le procédé de désérialisation est considéré comme complet et transmis à l'agent (221) logiciel ou l'application (22) qui en est destinataire lorsque la pile (TYST) de types est vide.

13. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'action de désérialisation correspondant à une donnée (321,326) représentant une balise, dite balise NEW , indiquant un nouvel élément comprend des étapes de : - lecture d'au moins une donnée (322,327) suivante dans le flux d'entrée ;

327) suivante, dans une pile mémoire, dite pile (TYST) de types, à la suite des types qui y sont déjà éventuellement mémorisés ;

- mémorisation du type d'objet, représenté par cette même donnée (322,

14. Procédé selon l'une des revendications précédentes, caractérisé en ce que la pile (TYDT) de types utilisée par le procédé de désérialisation comprend une pile de type LIFO, c'est à dire dont les emplacements sont lus dans l'ordre inverse de leur ordre de mémorisation.

15. Procédé selon l'une des revendications précédentes, caractérisé en ce que le procédé de désérialisation comprend une étape de création d'un élément (410 à 414) composant la structure de l'objet (34) logiciel structuré résultat, par allocation d'un nouvel espace mémoire ou par réutilisation d'une allocation libre, cette création étant réalisée par un agent (TMO, TM1, TM2) de contrôle de type correspondant au type de l'élément à créer.

16. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape de création d'un élément (410,414) composant la structure de l'objet (34) logiciel structuré résultat a lieu entre l'étape de lecture d'une donnée (322,327) indiquant la création de cet élément et la première étape de remplissage de ce même élément.

17. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'action correspondant à une donnée (324,325, 329), dite donnée simple, c'est à dire ne représentant pas une balise, comprend une étape de mémorisation de la valeur de cette donnée dans l'espace mémoire alloué à l'objet en cours.

18. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'au cours du procédé de désérialisation, un index (4102) d'objet est attribué à au moins un élément (410) composant la structure de l'objet (34) structuré résultat, cet index d'objet identifiant cet élément de façon unique et lui permettant d'être désigné ou référencé par d'autres objets ou éléments (414).

19. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'action correspondant à une donnée (3211) représentant une balise, dite balise REF , indiquant une référence comprend des étapes de : - lecture d'au moins une donnée (3212) suivante dans le flux (32) d'entrée ; - mémorisation dans l'espace (3441) mémoire alloué à l'objet (344) en cours, à la suite des données déjà mémorisées, d'une donnée désignant un objet (340) comme source de la valeur de tout ou partie de l'objet en cours, cet objet ou élément (340) source étant identifié par ladite donnée (3212) suivante.

20. Procédé selon l'une des revendications précédentes, caractérisé en ce que le remplissage de l'objet en cours est considéré comme terminé lorsque les données mémorisées dans l'espace mémoire qui lui est alloué correspondent à une longueur déterminée, cette longueur étant lue en mémoire dans la carte (2) par un agent (TMO, TM1, TM2) de contrôle de type ou par un agent (TMG) gestionnaire de types mémorisé dans la plate-forme embarquée.

21. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'envoi par la plate-forme embarquée (2), vers l'hôte (1), d'une succession (42) linéaire de données d'une longueur déterminée, s'effectue selon un procédé itératif, dit de lecture de données, comprenant des étapes récursives de : - envoi par l'hôte d'une commande de communication avec passage d'au moins un paramètre d'envoi représentant la longueur des données déjà reçues ; - réception par la plate-forme embarquée du paramètre d'envoi et comparaison avec la succession linéaire de données à transmettre ;

- réponse à la commande de communication par l'envoi d'au moins un paramètre (43) de retour représentant la ou les données suivant immédiatement les données déjà reçues par l'hôte ; - réception par l'hôte du paramètre (43) de retour de la commande de communication et mémorisation des données qu'il représente à la suite des données déjà reçues.

22. Procédé selon l'une des revendications précédentes, caractérisé en ce que la réception par la plate-forme embarquée (2), en provenance de l'hôte (1), d'une succession (43) linéaire de données d'une longueur déterminée, s'effectue selon un procédé itératif, dit d'écriture de données, comprenant des étapes récursives de : - envoi par l'hôte d'une commande de communication avec passage d'au moins un premier paramètre (32) d'envoi représentant la ou les données suivant immédiatement la partie déjà transmise de la succession linéaire de données à transmettre, ainsi éventuellement qu'un deuxième paramètre d'envoi représentant la position, dans la succession à transmettre, des données représentées par le premier paramètre d'envoi ou la longueur des données déjà transmises ; - réception par la plate-forme embarquée du ou des paramètres (32) d'envoi de la commande de communication ; - mémorisation dans un flux (33) d'entrée dans la plate-forme embarquée des données représentées par le premier paramètre (32) d'envoi à la suite des données déjà reçues.

23. Procédé selon l'une des revendications précédentes, caractérisé en ce que le procédé d'écriture de données comprend en outre les étapes suivantes :

24. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'au moins deux des procédés de sérialisation, désérialisation, lecture de données, ou écriture de données sont effectués en parallèle ou de façon entrelacée par répétition d'une étape comprenant l'exécution successive d'au moins une étape de chacun de ces procédés.

- comparaison par la plate-forme embarquée du deuxième paramètre d'envoi et comparaison avec la longueur des données déjà reçues ; - retour par la plate-forme embarquée d'au moins un paramètre de réponse représentant soit la longueur des données déjà reçues soit une donnée représentant le résultat de cette comparaison soit les deux ;

25. Procédé selon l'une des revendications précédentes, caractérisé en

ce que le flux d'entrée ou le flux de sortie ou les deux sont mémorisés sous la forme de structures circulaires de mémoire, ces deux flux pouvant partager la même structure circulaire.

26. Procédé selon l'une des revendications précédentes, caractérisé en ce que la plate-forme embarquée comporte un environnement programmable apte à mémoriser et exécuter au moins une application réalisée par un programmeur, la fonction de communication étant compatible avec le format APDU défini dans la norme ISO 7816.

27. Procédé de conversion selon la revendication précédente, cecq des opérations de désérialisation puis traitement d'un objet reçu sont déclenchées par la réception d'au moins une commande au format APDU comprenant au moins une donnée indiquant la réception d'un objet structuré.

28. Procédé selon l'une des revendications précédentes, caractérisé en ce que la plate-forme embarquée comporte un environnement programmable compatible avec le standard JavaCard (marque déposée).

29. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'au moins une des applications exécutées sur l'hôte ou la plate-forme embarquée est programmée en langage Java&commat;.

30. Procédé selon l'une des revendications précédentes, caractérisé en ce que les procédés de lecture de données, d'écriture de données, de désérialisation ou de sérialisation sont mis en oeuvre à travers leur implémentation dans au moins une classe mémorisée dans l'hôte ou dans la plate-forme embarquée, cette implémentation comprenant au moins l'une des commandes suivantes : - une commande d'écriture d'objet, effectuant la transmission d'un objet (31) structuré à au moins un agent (221) de la plate-forme embarquée, par utilisation du procédé de sérialisation de cet objet, puis du procédé d'écriture de données, puis du procédé de dé-sérialisation ; - une commande de lecture d'objet, effectuant la lecture d'un objet (41) structuré depuis au moins un agent (221) de la plate-forme embarquée, par utilisation du procédé de sérialisation puis du procédé de lecture de données, puis du procédé de désérialisation ; - une commande de désallocation d'un objet structuré mémorisé dans la plate-forme embarquée, par utilisation du procédé de sérialisation, celui-ci comprenant en outre une étape de mémorisation de la libération ou désallocation de l'espace mémoire alloué à chaque composant de cet objet, après analyse de la structure de ce composant ; - une commande de nettoyage ou effacement d'un espace mémoire libéré par un objet structuré, par utilisation du procédé de désérialisation pour créer un objet de contenu sans signification à partir d'une succession linéaire de données déterminée ; - une commande de duplication d'un objet structuré dit de départ, par utilisation du procédé de sérialisation, sans désallocation de cet objet de

départ, pour créer une succession linéaire de données représentant ce même objet, puis par utilisation du procédé de désérialisation à partir de cette succession linéaire de données pour créer un autre objet structuré de contenu identique à l'objet de départ.

31. Procédé selon la revendication précédente, cecq le langage de programmation de la plate-forme embarquée comporte une première classe (IOApplet) décrivant une méthode abstraite ProcessAPDU, lançant lors de la réception d'un message APDU, un traitement paramétrable dans l'application ; le code programme réalisant les opérations de désérialisation dans la plateforme embarquée étant mémorisé dans la plate-forme embarquée, en tant qu'implémentation de cette méthode abstraite ProcessAPDU, dans une deuxième classe (ObjectIOApplet) héritant de la première classe (IOApplet), ce même code programme faisant appel à une méthode ProcessObject elle-même décrite comme une méthode abstraite dans cette même classe (ObjectIOApplet) d'implémentation.

32. Procédé selon la revendication (Javacard), cecq le langage de programmation de la plate-forme embarquée comporte une première classe (lOApplet) décrivant une méthode SendAPDU émettant vers l'hôte un message au format APDU ; le code programme réalisant les opérations de sérialisation dans la plate-forme embarquée étant mémorisé, en tant qu'implémentation d'au moins une méthode SendObject faisant appel à la méthode SendAPDU, dans une deuxième classe (ObjectIOApplet) de carte héritant de la classe (IOApplet).

33. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est utilisé pour la communication entre au moins un agent logiciel, dit agent de carte, mémorisé ou exécuté dans la plate-forme embarquée et au moins un agent logiciel, dit agent proxy de moteur de carte mémorisé ou exécuté dans au moins un hôte appartenant à un réseau informatique communiquant par messages asynchrones selon une infrastructure logicielle de type AAA-MOM, cet agent proxy de moteur de carte servant d'intermédiaire à

l'agent de carte dans ses communications avec d'autres agents de ce réseau, ces agents fonctionnant selon les spécifications de cette infrastructure logicielle et appartenant à au moins une application distribuée.

34. Système informatique comprenant une station (2) informatique, dite plate-forme embarquée, comprenant un objet portable incluant au moins un processeur, des moyens de mémorisation, et des moyens de communication aptes à échanger des informations avec un terminal sous la forme d'une ou plusieurs successions linéaires de données, caractérisé en ce que la plateforme comprend un agent (212) de sérialisation apte à effectuer une étape de conversion d'un ensemble de données, dans un sens ou dans l'autre, entre d'une part un agencement en une succession linéaire de données et d'autre part un agencement structuré décrivant ou représentant un ou plusieurs objets logiciels structurés ou hiérarchisés suivant les critères d'un langage de programmation orienté objet.

35. Système selon la revendication précédente, caractérisé en ce que la plate-forme embarquée (2) comprend un agent (211) de communication apte à : - recevoir en lieu et place de l'agent (221) destinataire un ensemble (32) de données reçues par la fonction (201) de réponse à l'intention d'un agent (221) logiciel destinataire mémorisé dans la plate-forme embarquée, cet ensemble de données étant agencé en une ou plusieurs successions linéaires de données ; - convertir cet ensemble de données en au moins un objet (34) logiciel, structuré ou hiérarchisé suivant les critères d'un langage de programmation orienté objet ; - transmettre cet objet (34) logiciel structuré à l'agent (221) destinataire et déclencher un traitement (2210) en fonction de cet objet par cet agent (221) destinataire.

36. Système selon l'une des revendications précédentes, caractérisé en ce que la succession linéaire de données représentant un objet logiciel structuré est mémorisée dans la plate-forme embarquée dans un flux d'entrée ou un flux de sortie, la plate-forme embarquée comportant un agent logiciel dit agent (212) de sérialisation apte à créer dans la plate-forme embarquée le ou les objets structurés représentés par le flux d'entrée, c'est à dire à désérialiser ces objets structurés, ou à écrire dans le flux de sortie des données représentant le ou les objets structurés à transmettre, c'est à dire à sérialiser ces objets structurés.

37. Système selon l'une des revendications précédentes, caractérisé

en ce que le flux d'entrée ou le flux de sortie sont mémorisés sous la forme d'une ou plusieurs structures circulaires de mémoire.

38. Système selon l'une des revendications précédentes, caractérisé en ce que l'agent (212) de sérialisation utilise une pile mémoire, dite pile de types, pour mémoriser le type d'au moins un objet composant tout ou partie de la structure d'un objet structuré à sérialiser ou désérialiser, cette pile de type comportant des emplacements mémoires qui ne sont chacun accessibles qu'après que les emplacements mémorisés plus récemment aient été lus et effacés.

39. Système selon l'une des revendications précédentes, caractérisé en ce que les données contenues dans les flux d'entrée ou de sortie représentent un ou plusieurs objets structurés en utilisant un codage comprenant un jeu de balises, ces balises représentant chacune une action déterminée à effectuer lors de la désérialisation de cette succession linéaire de données.

40. Système selon l'une des revendications précédentes, caractérisé en ce qu'au moins une balise est définie comme représentant une des actions suivantes :

- ajout d'un nouvel élément à la structure de l'objet structuré représenté par la succession linéaire de données ; - référence à un élément ou objet, dit objet source, en tant que source de la valeur de tout ou partie d'un élément composant l'objet structuré ; - indication que la ou les données suivantes représentent le contenu d'un élément composant l'objet structuré ; - indication d'une absence de contenu d'un élément composant l'objet structuré.

41. Système selon l'une des revendications précédentes, caractérisé en ce que la plate-forme embarquée comprend un objet portable fonctionnant selon la norme IS07816 et utilisant des commandes au format APDU.

42. Système selon l'une des revendications précédentes, caractérisé en ce qu'au moins un agent ou application mémorisé dans la plate-forme embarquée est programmé en langage Java&commat;, la plate-forme embarquée comportant un environnement informatique selon le standard JavaCard&commat;.

43. Système selon l'une des revendications précédentes, caractérisé en ce qu'il comporte dans l'hôte ou dans la plate-forme embarquée, ou les deux, au moins une classe logicielle implémentant au moins l'une des commandes suivantes : - une commande d'écriture d'objet, effectuant la transmission d'un objet (31) structuré à au moins un agent (221) de la carte, par sérialisation de cet objet structuré en un flux de données dans l'hôte, puis envoi de ce flux de données dans la plate-forme embarquée, puis dé-sérialisation de ce flux de données en un objet structuré dans la plate-forme embarquée ; - une commande de lecture d'objet, effectuant la lecture d'un objet (41) structuré depuis au moins un agent (221) de la carte, par sérialisation de cet objet structuré en un flux de données dans la plate-forme embarquée, puis

réception depuis la plate-forme embarquée de ce flux de données, puis désérialisation de ce flux de données en un objet structuré dans l'hôte ; - une commande de désallocation d'un objet structuré mémorisé dans la plate-forme embarquée, par une sérialisation de cet objet selon une option comprenant une libération ou désallocation de l'espace mémoire alloué à chaque composant de cet objet, après analyse de la structure de ce composant ; - une commande de nettoyage ou effacement d'un espace mémoire libéré par un objet structuré dans la plate-forme embarquée, par désérialisation d'une succession linéaire de données déterminée pour créer un objet de contenu sans signification ; - une commande de duplication dans la plate-forme embarquée d'un objet structuré dit de départ, par sérialisation en une succession linéaire de données représentant ce même objet, sans désallocation de cet objet de départ, puis par désérialisation à partir de cette succession linéaire de données en un autre objet structuré de contenu identique à l'objet de départ.

44. Système selon l'une des revendications précédentes, caractérisé en ce que la plate-forme embarquée communique au moins un hôte appartenant à un réseau informatique communiquant par messages asynchrones selon une infrastructure logicielle de type AAA-MOM, cet hôte comprenant un agent logiciel, dit agent proxy de moteur de carte, apte à gérer les communications de cette plate-forme embarquée avec d'autres agents de ce réseau, ces agents fonctionnant selon les spécifications de cette infrastructure logicielle et appartenant à au moins une application distribuée.