L’annonce du jour en matière d’ECM concerne l’officialisation du nouveau standard CMIS à l’initiative des principaux acteurs du marché de l’ECM.
CMIS, Content Management Interoperability Standard, est donc une spécification technique conçue pour favoriser l’interaction entre les systèmes de Gestion de Contenus, via Web Services. A la différence de JSR 170, CMIS inclut la prise en compte de SOAP et REST/ATOM.
CMIS est le fruit d’un travail commun entre les principaux acteurs du marché, à l’origine IBM, EMC et Microsoft, rejoints ensuite par Oracle, OpenText, SAP et Alfresco.
La validation de la norme par OASIS est attendue d’ici 12 à 18 mois. D’ici là les premiers produits compatibles vont voir le jour, c’est déjà le cas dans la gamme IBM avec l’intégration Lotus / FileNet P8 / Content Manager 8.
Le choix d’un tel standard ouvert correspond à la demande de plus en plus pressante des clients, on peut en effet s’attendre à un choix plus important en matière de Gestionnaires de Contenus intégrables dans une infrastructure documentaire d’Entreprise, et à une plus grande interopérabilité entre les systèmes.
Tel que présenté, CMIS ne vient pas remplacer JSR170 mais fournit un modèle différent pour le partage des contenus (basé sur REST et Web Services au lieu de Java seulement). Ceci dit, on peut légitimement penser qu’il va sonner le glas de JSR 170 vu son faible taux d’adoption (avis bien personnel). En effet, CMIS n’impose pas de modification du code du progiciel ECM en question, mais le simple ajout d’un connecteur à base de Web Services. De plus, JSR 170 n’a jamais franchement reçu le support de Microsoft (!), ce qui n’est pas le cas de CMIS puisque Microsoft en est un des acteurs initiaux.
Plus d’infos sur CMIS sur les différents sites suivants : IBM, EMC, Alfresco, Microsoft …
Enfin un peu de lucidité dans ce monde informatique où standard rime avec technologie utilisée. CMIS est une bonne nouvelle pour ceux qui voulaient une véritable norme de gestion de contenu.
Et oui effectivement, il vaut mieux que CMIS ne remplace pas JSR.. mais fasse oublier rapidement qu’un jour une norme fut associé à un langage de dév.
Tous ce qui va dans le sens de l’interopérabilité est souhaitable 🙂
Hello 🙂
J’ai la même vision de JSR-170 et son adoption très relative (doux euphémisme).
La faute de la lettre J d’abord, trop restrictive, mais aussi à des implémentations variées (la faute à une spécification qui décrit une API au lieu de décrire un protocole) et plein de petits défauts qui font qu’on peut très vite regretter ce choix !
L’approche CMIS est vraiment intéressante. D’abord parce que avoir réussi à laisser le choix entre REST et SOA, ça ne frustrera pas les développeurs. Ensuite parce que à défaut d’être parfaite (ça reste une version 0.5), la spécification attaque les choses du bon coté. Spécifier à haut niveau, c’est laisser toute la latitude pour la mise en œuvre et ça va faciliter grandement l’adoption sans forcer à revoir l’application sous-jacente de fond en comble.
Ça ouvre pas mal de nouvelles possibilités, et une fois que les principaux acteurs auront leur implémentation on pourra enfin faire cohabiter des entrepôts variés et peut être surtout penser de nouvelles applications.
Bien sûr il reste un peu de chemin avant que CMIS tienne toutes ses promesses et soit LA norme, mais ça pourrait aller assez vite (déjà les acteurs du groupe de travail ont tous une version très avancée, voir finalisée).
Alors oui, il parait que CMIS ne vient pas remplacer JSR170 … mais je crois que c’est justement ce qui rend la nouvelle approche plus crédible :p