Rémy Marchand : Des échanges électroniques plus flexibles

Les discours sur l’interopérabilité sont nourris mais souvent confus, ne serait-ce qu’en ce qui concerne l’univers de ce discours. Dans ce blog, on ne parle pas de l’interopérabilité des environnements de développement d’applications ou « frameworks », ensemble d’outils et de composants logiciels organisés conformément à un plan d’architecture. On parle d’interopérabilité « externe » c’est-à-dire de l’aptitude de 2 ou n systèmes d’information indépendants d’échanger des paquets d’informations de la façon la plus eficace et efficiente, exactement comme si ces deux ou n systèmes n’en faisaient qu’un seul. S’imaginer que l’interopérabilité au sens qui vient d’être défini ne dépend que d’un travail sémantique consciencieux mené au niveau intersectoriel, comme ambitionnent de le faire les Nations Unies (UNCEFACT), est une attitude naïve. Dans un certain nombre des cas, l’interopérabilité est actuellement interne à des secteurs (le secteur du tourisme avec OpenTravel a bien avancé) et parfois elle couvre plusieurs domaines comme avec le National Information Exchange Model de plusieurs ministères du gouvernement fédéral de Etats Unis. De toute façon, l’interopérabilité a et aura besoin de solutions qui restent à inventer, mais – sauf à imaginer que « le marché fera les standards » – le rôle de la standardisation et des méthodes bien charpentées restera indispensable si on veut que l’interopérabilité touche de plus en plus de domaines voisins. Comme l’économie est en perpétuelle évolution, ainsi doit être gérée l’interopérabilité. Le Comité technique d’OASIS WS-Calendar décrit un jeu commun de composants destinés à spécifier des plans d’exécution et des intervalles ou rendez-vous de coordination de services Web d’échanges électroniques. Le draft 1.0 de WS-Calendar, cohérent avec le modèle de référence de l’architecture orientée services (SOA) d’OASIS est disponible pour commentaires publics. Jusqu’à présent, les processus d’échange ont été gérés comme s’ils étaient instantanés, mais dans les faits, ils ne le sont pas. Définir un processus cadencé correspond donc à un réel besoin. Il est ressenti notamment par des applications traitant d’échanges de données pour la meilleure utilisation de l’énergie ou pour la gestion des situations d’urgence (cf EDXL Emergency Data Exchange Language). Pour en savoir plus, www.oasis-open.org/committees/ws-calendar

D’autres moyens d’assurer la flexibilité d’applications d’échanges de données sont indispensables. UNCEFACT en traite en prenant en compte la notion de contexte (voir à ce sujet la CCTS ou Core Component Technical Specification). Le US Department of Justice qui a défini le National Information Exchange Model a de son côté anticipé le fait que ses modèles de données ne sont pas utilisés tels quels dans un échange concret mais que les documents résultaient d’une simplification contextuelle des modèles constitutifs du NIEM. A cette fin un générateur de messages simplifiés (Outil Build message subset) a été prévu. Il permet à des utilisateurs de définir des documents aussi simples qu’ils le souhaitent (en sélectionnant les propriétés et les types de données) tout en restant assuré que le résultat reste conforme au modèle standard.

Tagged:

Comments are closed.

Rémy Marchand : Des échanges électroniques plus flexibles

Les discours sur l’interopérabilité sont nourris mais souvent confus, ne serait-ce qu’en ce qui concerne l’univers de ce discours. Dans ce blog, on ne parle pas de l’interopérabilité des environnements de développement d’applications ou « frameworks », ensemble d’outils et de composants logiciels organisés conformément à un plan d’architecture. On parle d’interopérabilité « externe » c’est-à-dire de l’aptitude de 2 ou n systèmes d’information indépendants d’échanger des paquets d’informations de la façon la plus eficace et efficiente, exactement comme si ces deux ou n systèmes n’en faisaient qu’un seul. S’imaginer que l’interopérabilité au sens qui vient d’être défini ne dépend que d’un travail sémantique consciencieux mené au niveau intersectoriel, comme ambitionnent de le faire les Nations Unies (UNCEFACT), est une attitude naïve. Dans un certain nombre des cas, l’interopérabilité est actuellement interne à des secteurs (le secteur du tourisme avec OpenTravel a bien avancé) et parfois elle couvre plusieurs domaines comme avec le National Information Exchange Model de plusieurs ministères du gouvernement fédéral de Etats Unis. De toute façon, l’interopérabilité a et aura besoin de solutions qui restent à inventer, mais – sauf à imaginer que « le marché fera les standards » – le rôle de la standardisation et des méthodes bien charpentées restera indispensable si on veut que l’interopérabilité touche de plus en plus de domaines voisins. Comme l’économie est en perpétuelle évolution, ainsi doit être gérée l’interopérabilité. Le Comité technique d’OASIS WS-Calendar décrit un jeu commun de composants destinés à spécifier des plans d’exécution et des intervalles ou rendez-vous de coordination de services Web d’échanges électroniques. Le draft 1.0 de WS-Calendar, cohérent avec le modèle de référence de l’architecture orientée services (SOA) d’OASIS est disponible pour commentaires publics. Jusqu’à présent, les processus d’échange ont été gérés comme s’ils étaient instantanés, mais dans les faits, ils ne le sont pas. Définir un processus cadencé correspond donc à un réel besoin. Il est ressenti notamment par des applications traitant d’échanges de données pour la meilleure utilisation de l’énergie ou pour la gestion des situations d’urgence (cf EDXL Emergency Data Exchange Language). Pour en savoir plus, www.oasis-open.org/committees/ws-calendar

D’autres moyens d’assurer la flexibilité d’applications d’échanges de données sont indispensables. UNCEFACT en traite en prenant en compte la notion de contexte (voir à ce sujet la CCTS ou Core Component Technical Specification). Le US Department of Justice qui a défini le National Information Exchange Model a de son côté anticipé le fait que ses modèles de données ne sont pas utilisés tels quels dans un échange concret mais que les documents résultaient d’une simplification contextuelle des modèles constitutifs du NIEM. A cette fin un générateur de messages simplifiés (Outil Build message subset) a été prévu. Il permet à des utilisateurs de définir des documents aussi simples qu’ils le souhaitent (en sélectionnant les propriétés et les types de données) tout en restant assuré que le résultat reste conforme au modèle standard.

Tagged:

Comments are closed.