Sérialisation et serialVersionUID

Ceux d’entre nous qui se sont déjà heurtés aux problématiques de sérialisation d’objets java, savent qu’il est important de spécifier l’attribut statique serialVersionUID sur les classes sérialisables pour permettre à deux applications de continuer à pouvoir s’échanger des données même si elles ont des versions légèrement différentes des classes en question.

En effet, lorsqu’un objet est sérialisé, Java commence à envoyer dans le flux le nom de sa classe puis son serialVersionUID. Lorsque l’objet est désérialisé depuis ce flux, Java charge la classe puis vérifie que son serialVersionUID correspond à celui qui est dans le flux. Lorsqu’il n’est pas spécifié explicitement, le serialVersionUID est calculé à partir des caractéristiques de la classe. La plupart des modifications d’une classe modifie le serialVersionUID ainsi calculé. (J’ai longtemps cru que les modifications dans l’implémentation d’une méthode n’influençait pas ce calcul. J’avais tord, certaines modifications, comme utiliser la notation <classname>.class ont des effets de bord avec certains compilateurs qui peuvent changer ce calcul)

Ainsi, je pensais jusqu’à récemment que deux versions d’une classe donnée ne pouvaient être compatibles pour la sérialisation java que si leur serialVersionUID (spécifié ou calculé) était le même. (Ce qui est facilement vérifiable avec l’utilitaire serialver du jdk)

Trouver des structures de base de données est un domaine qui a donné lieu à de nombreuses recherches dans le domaine de l’ingénierie logicielle. On peut citer les B-Tree et ses variantes, les BSP, le RB Tree, et enfin le R-Tree, qui est une structure assez nouvelle, sa découverte datant de 1984 par A. Guttman.

J’ai eu le plaisir de développer un tel moteur à base de R-Tree lors de ma mission chez Viamichelin pour l’indexation du réseau routier français ainsi que de ses informations de trafic. Le R-Tree commence désormais à outrepasser son domaine de départ, qui était l’indexation géo-spatiale des données, pour arriver dans des branches de compétence comme le classement d’archives multimédias, ou bien la géo-indexation d’objets en mouvement, popularisée par l’arrivée en masse de GPS bon marché.

Le R-Tree a de nombreux avantages qui retiennent l’attention :

  • Même si le R-Tree original visait à organiser de façon efficace une large base de données 2-dimensionnelles, il a évolué pour inclure des données d’ordre plus élevées grâce à ses variantes (MVR-Tree pour les 4 dimensions par exemple). Ses variantes sont, à l’heure actuelle, les structures les plus efficaces pour stocker des données à grandes dimensions.
  • La structure est dynamique permettant l’insertion, la destruction et des requêtes dans n’importe quel ordre, tout en utilisant des heuristiques pour minimiser les temps de requête. Il existe quelques prototypes qui lient des techniques d’Intelligence Artificielle pour pouvoir prévoir et agencer la structure de la base en fonction des requêtes.
  • La complexité de la recherche et donc le temps de réponse est analogue à la taille de la base de données même avec de grands nombre d’éléments. De même, cette structure est entièrement adaptée pour le parallélisme d’I/O ou CPU.

Son autre avantage étant qu’il est très documenté, et aussi qu’il existe un nombre très grand de variantes qui peuvent répondre à beaucoup de besoins différents. Au terme de ma mission, j’ai choisi une variante baptisée R* Tree, qui est l’une des plus connues et des plus robustes, associée à une méthode de bulk loading par méthode de Hilbert, étant donné que j’avais des données strictement deux dimensionnelles.

Il existe de nombreuses librairies Open source sur Internet qui implémente ces arbres. A noter particulièrement :

  • SaIL : la librairie C++/Java que je recommande, malgré la concision de sa documentation. A noter le plug-in java pour la visualisation en 3D de la base. Elle est très portable et permet de changer rapidement les méthodes d’accès ou de bulk load.
  • GiST : est la librairie qui a servi de base au RTree de PostGreSQL mais en C++.
  • XXL : une librairie Java qui est une très bonne initiation au R-Tree mais que j’ai trouvé trop rigide pour s’adapter au demande du client.

A noter aussi un portail spécialisé dans les RTree avec de nombreux code sources sur http://rtreeportal.org/, ainsi qu’une très bonne documentation disponible. Le livre RTrees : Theory and Applications chez Springer fait partie de mes recommandations fortes pour quiconque commençant dans ce domaine. Il y a, bien sûr, la possibilité d’utiliser postgres pour ses R-Tree.

J’ai eu la chance de passer 2 jours en compagnie de Ross Mason, le créateur de l’ESB Mule. Ross est non seulement fort sympathique, mais a conservé l’immense qualité de toujours chercher à comprendre et à résoudre les problèmes qu’on lui soumet, le tout avec beaucoup de didactisme. Ross Mason Au delà de ces aspects, qu’ai-je retenu de sa venue sur Paris ? Pas mal de choses, dont quatre principales que je vous livre en vrac :

  • Mule 2.0 est vraiment une grosse avancée pour les utilisateurs de Mule. Les fichiers de configuration sont notamment bien plus simples à rédiger. Et la roadmap est déjà bien achalandées avec notamment le rechargement à chaud de ces fameux fichiers de configuration !
  • Mule Galaxy, tout juste releasé, semble un produit très prometteur. Il s’agit d’une solution pompeusement intitulée de "Gouvernance SOA", en ce sens qu’elle permet de gérer un registre de services avec application d’un cycle de vie ou de règles.
  • Les produits Mule HQ et Mule NetBoot deviennent une aide puissante au déploiement au management des applications. NetBoot est en particulier capable de télécharger à distance des composants d’applications à partir du repository Galaxy.
  • La non conformité à JBI de Mule s’explique par le fait que cette spécification oblige à passer par une description XML des données qui transitent dans l’ESB. Mule, de son côté, peut très bien s’appuyer sur des copies Cobol ou sur des flux binaires, sans demander d’encapsulation XML. Cela lui permet d’être beaucoup plus rapide et également d’être utilisé pour des solutions de streaming.

Par ailleurs, les discussions avec Ross Mason ont bien confirmé la volonté de cette solution de se positionner au niveau des problématiques d’intégration technique, et pas nécessairement sur l’approche BPM, souvent mise en avant par les architectures SOA. En ce sens, on est plus dans une approche bottom-up que top-down, même si un moteur jBPM ou Intalio peuvent toujours se coupler à la solution et apporter ainsi un aspect workflow ou BPM.

Ca y est la roadmap post acquisition est dévoilée :

Et force est de constater qu’elle n’a pas beaucoup d’écho dans la communauté (RAS sur TSS, JavaLobby et QCon). Et pourtant cette roadmap va faire grands bruits chez nos grands comptes préférés. Sans parti pris :

  • L’abandon d’Oracle 10g AS se fera sans regrets,
  • Le stack AS avec JRockit + Weblogic + Toplink + Coherence a vraiment de la gueule,
  • Le nouvel ESB Oracle Service Bus est vraiment prometteur surtout avec l’apport du BPEL Engine d’Oracle,
  • Coté Portails la mise en "sommeil" de WLP et ALUI va laisser de la place à la concurrence,
  • Idem sur WLI, solution mature, transactionnelle et robuste qui ne va pas être remplaçable par le stack SOA immédiatement,

Au final les "modernes" l’emportent sur les "anciens" et Oracle n’a surtout pas oublié de publier la liste de prix 2 semaines avant la roadmap. Dans tous les cas j’espère avoir un peu de feedback clients et partenaires sur cette nouvelle offre. La présentation complète Oracle : cliquez ici