Compatibilité

Le Document Object Model (DOM) permet de représenter un document XML sous la forme d'un arbre en mémoire et de manipuler cet arbre de façon programmatique. L'architecture Cocoon 1 sous-jacente à SDX utilise le DOM pour manipuler et transférer les documents XML (réels ou virtuels) d'une étape à l'autre. Il est donc naturel que le DOM soit aussi utilisé par SDX pour le même genre d'opérations.

Le principal avantage du DOM, c'est que le document étant accessible en mémoire dans une structure d'objets, il est possible de le manipuler de façon très sophistiquée, dans l'ordre que le programmeur souhaite. Le principal inconvénient, c'est que le document doit être en mémoire et qu'il doit être complet avant de passer à une autre étape de la chaîne interne de SDX/Cocoon.

L'architecture Cocoon 2 sous-jacente à SDX 2 utilise quant à elle le standard Simple API for XML (SAX) pour représenter les documents XML comme des flux d'événements plutôt que comme un arbre en mémoire. Le principal avantage de cette approche est la facilité avec laquelle on peut chaîner différentes opérations sur les structures XML et aussi le fait que le document complet n'a pas besoin d'être en mémoire. Le principal inconvénient est que certaines manipulations des documents pourront être plus difficiles à réaliser.

Le passage à SDX 2 implique donc un passage du traitement par DOM à un traitement par SAX. Si une application SDX 2 ne manipule pas le DOM directement, il n'y aura aucun impact, car les API XSP et URL de SDX seront refaites en interne pour traiter du SAX plutôt que du DOM (les parties de l'API qui traitent du DOM seront conservées mais seront marquées comme dépréciées).

Si une application manipule le DOM dans une page XSP, ou encore utilise des API DOM de SDX, alors il faudra porter un peu plus de soin au passage à SDX 2.

Dans le but d'intégrer de façon plus propre le multilinguisme, SDX utilisera la toute nouvelle API 2.3 des servlets. La version 4 du moteur de servlets Tomcat implante cette version, alors il sera nécessaire d'utiliser au moins cette version avec SDX, ou un autre moteur de servlets qui supporte cette version de l'API.

Ce changement devrait surtout faire une différence lors de l'installation de SDX. Toutefois, si une application fait appel à des fonctionnalités propres au moteur de servlets ou à l'API 2.2 des servlets, alors elle risque de ne plus fonctionner en SDX 2.

La norme Java API for XML Processing (JAXP) est maintenant incontournable dans les applications Java/XML. JAXP unifie les API d'accès aux parseurs XML et processeurs XSLT. Ainsi, toute application Java qui désire utiliser de tels outils peut être programmée de manière à fonctionner avec n'importe quel processeur XSLT ou parseur XML qui supporte cette norme. Actuellement, les parseurs XML Xerces et Crimson de même que les processeurs XSLT Saxon et Xalan la respectent.

SDX 2 utilisera les services JAXP pour tout ce qui touche au traitement XSLT ou XML dans ses différentes fonctionnalités. Ce changement aura un impact sur les applications actuelles seulement si celles-ci supposent la présence d'un parseur XML ou processeur XSLT spécifique. Par exemple, si vous importez directement des classes des packages org.apache.xerces dans une page XSP, il y a de fortes chances que vous deviez modifier votre code pour travailler directement avec JAXP.

Toutes les librairies utilisées par SDX seront mises à jour ou remplacées. Ces librairies sont stockées sous la forme d'archives Java (fichiers .jar) dans le répertoire webapps/sdx/WEB-INF/lib de l'installation de Tomcat. Si une application fait directement appel à l'une ou l'autre de ces librairies, elle risque de ne plus fonctionner en SDX 2.

Les applications SDX 1 reposent toutes sur la présence d'un SGBD relationnel, qui sert surtout au stockage des documents, mais également à la manipulation des informations de gestion de SDX (utilisateurs, privilèges, groupes, bases de documents). La version 2 de SDX n'utilisera pas un SGBD relationnel pour ses informations de gestion, mais plutôt une utilisation adéquate de documents XML et du moteur de recherche Lucene. Ainsi, toute application qui fait appel directement aux informations stockées dans le SGBD relationnel devra être modifiée en conséquence. Ceci étant une pratique à éviter, cette incompatibilité ne devrait pas affecter beaucoup d'applications.

Par ailleurs, le SGBD relationnel est actuellement le seul type d'entrepôt de documents géré par SDX. En version 2, d'autres types seront possibles, ce qui impliquera qu'une application SDX pourrait ne plus avoir besoin d'un SGBD relationnel derrière. C'est pourquoi toutes les applications SDX actuelles qui supposent la présence de ce SGBD devront être déployées sur une installation SDX derrière laquelle un tel SGBD est installé. Encore une fois, il est déconseillé d'utiliser directement le SGBD dans les applications SDX, alors cela devrait affecter peu d'applications.

L'API Java de SDX 2 sera complètement revue par rapport à celle de SDX 1. Ainsi, toute application SDX 1 qui utilise directement l'API Java risque sera probablement incompatible avec SDX 2. Lorsque les détails de cette nouvelle API seront connus, des informations seront fournies sur la migration des applications qui utilisent l'API de SDX 1.