[Concept][Sérialisation] XML ou serializable

Bonjour

Je dois réalisé des applets échangeant des objets avec des servlets. Je pensais faire passer ces objets par serialisation XML comme je le lis partout. Et hier en trainant dans la javadoc je tombe sur java.io.ObjectInputStream et java.io.ObjectOutputStream.
Ces deux classes permettent de faire passer des objets dans des flux avec writeObject() et readObject(), à condition que ces objects implementent l'interface java.io.Serializable.
La question est donc : quel est alors l'interêt de la serialisation XML?
Je suis conscient que le XML sera lisible par une appli dans un autre language et que le DTD permet de s'assurer que le flux n'a pas été endommagé (et encore que partiellement). Mais dans le cas d'un echange entre 2 applis en java, XML ne fait-il pas marteau piqueur pour écraser une mouche?

Tout depend de la version du jdk que tu utilises mais je crois qu'a partir de la 1.4 il y a les classes XMLEncoder et XMLDecoder qui font ca tres bien ...

La difference dans ce cas n'est pas enorme vu que la serialization fait exectement la meme chose mais de maniere un poil plus proprietaire ..

Je te conseillerais XML, plus independant et plus lisible que la serialization ..

Bulbo :wink:

Bonjour,

Utiliser du XML permet a un autre programmeur ou a toi meme d'utiliser ta classe sans meme savoir comment elle marche, il suffit de lui donner son fichier XML formater et elle fonctionne correctement, il est naturellement plus facile de changer une configuration a partir d un fichier XML qu'a partir d un flux de donnees.

Donc il s'agit bien d un marteau mais l objectif est d'ecraser beaucoup de mouches en un seul coup :wink:

J'avais pas vu XMLEncoder non plus....
J'étais parti sur ce que j'avais lu dans les livres avec des Marshaller, mais je trouvais que ca faisait usine a gaz.
Par contre j'ai vu sur un site web que les applets pouvaient ne pas fonctionner avec les fonctions supérieures au jdk1.3. Est ce toujours vrai?
Enfin d'apres la javadoc il y a un algo sur XMLEncoder pour réduire la taille du message XML quand les valeurs sont par défaut. Cela doit permettre de gagner en temps de transfert réseau, mais on doit perdre en vitesse d'execution. Enfin la javadoc dit :

Citation:

---

The ObjectOutputStream continues to be recommended for interprocess communication and general purpose serialization.

---

Alors au final, je ne sais plus quoi faire :?

N'ayant jamais utilise d'XMLEncode/Decoder je ne pourrai pas te renseigner plus avant sur les performances ..

Par contre une chose est sure, la serialization depend de la version de VM utilisee et il est fort probable qu'une 1.4 ne communiquera pas avec une 1.3, la version des classes ayant changee ...

Quel est le but de cet echange d'objets :?: Il y a peut-etre moyen de trouver une solution generique et plus legere que ca :?:

Bulbo :wink:

L'objectif est d'echanger des informations concernant des containers entre le serveur et differents clients (chariot pour le site de stockage, balance pour le poids....).
Ainsi le chariot flashe un code barre sur le container et le serveur renvoie le descriptif du contenu a partir d'un base de données, ou la balance flashe le container et envoie le poids pour mise a jour de la base de données par le serveur.
Je voulais faire transiter mes objets container par serialisation entre le serveur et les applets sur les clients.

Dans ce cas tu peux definir un document XML qui decrit le container..

Du cote servlet tu crees la chaine XML qui correspond au containeret tu l'envoie
Du cote applet tu parses la chaine recue (avec SAX par exemple) et tu crees un objet Container a partir de ces infos

Tu es independant du langage, du type de VM ..

Tu peux meme gagner un temps fou en stockant directement la chaine XML decrivant le Container dans la base de donnee..

Bulbo :wink:

C'est ce que j'avais vu au depart avec l'API CastorXML. Mais depuis que j'ai vu l'ObjectOutputStream et le XMLEncoder, je trouve que même si c'est élégant et que c'est compatible avec d'autre language, ca représente quand meme quelques complications.... Je pense que je vais tester XMLEncoder et que je ferai SAX si j'ai le temps.

Citation:

---

Envoyé par bulbo

Tu peux meme gagner un temps fou en stockant directement la chaine XML decrivant le Container dans la base de donnee..

---

Le probleme est que ces données sont aussi partagées avec d'autres vieilles applications donc pas de XML dans le SGBD