Architecture technique
La mise en place par le ministère de l’Economie, des finances et de l’emploi d’un plan d’action TIC-PME 2010 a eu pour objectif de renforcer la compétitivité des PME par un meilleur usage des technologies de l’information et de la communication. Une des orientations fondamentales du programme TIC PME est de veiller à ce que le plus grand nombre possible de développements puissent résulter de travaux communs et être effectués avec la vision de la plus grande inter opérabilité possible entre les projets de filières voisines et avec les projets dits transverses. Nous savons depuis que les travaux de l’ISO l’ont formalisé que les systèmes d’échanges électroniques reposent sur deux piliers. Le premier est de l’ordre de la sémantique et couvre la définition et la spécification :
Suivant la terminologie de l’ISO, on traite ici de la Vue Opérationnelle des Affaires ou Business Operations View (BOV). Le deuxième pilier concerne les systèmes matériels et logiciels qui permettent d’opérer les systèmes d’échanges électroniques. Assemblés en Architectures Techniques, ils permettent de réaliser les échanges de manière fiable et sécurisée, de gérer les suites d’e-docs (ou chorégraphies) spécifiées dans les scénarios d’échanges. Autant les travaux de standardisation relatifs à la Vue Opérationnelle des Affaires sont connus, autant ceux relatifs à la Vue Fonctionnelle des Services font l’objet de peu de réflexions. Pourtant, dans le prolongement des travaux de l’ISO relatifs au Modèle Conceptuel pour l’EDI ouvert, UNCEFACT et OASIS (Organization for the Advancement of Standardized Information Systems) ont défini un ensemble de standards destinés à fournir un cadre de référence pour établir des Services d’échanges électroniques au sens FSV. Ce cadre est connu sous le nom d’ebXML, et a conduit à l’enregistrement de cinq Recommandations ISO : ebXML CPP/A: ISO 15000-1 Capacités de Collaboration (CPP) et Accord de collaboration (CPA). Le présent groupe thématique traite des Recommandations ISO (ebXML) relevant de la Vue Fonctionnelle des Services (ISO 15 000 / 1-2), mais fait aussi le point des services conçus antérieurement par l’IETF (AS1, AS2, AS3) et de ceux qui tentent d’apporter de nouvelles possibilités aux utilisateurs de systèmes e-Business : les Web services. La série des recommandations ebXML comporte des éléments relevant de la vue opérationnelle des affaires (Spécification des composants essentiels ou CCTS), de la vue fonctionnelle des services (Spécification de messagerie fiable e-Business) et des éléments de négociation électronique d’accords d’inter change, encore peu utilisés (CPP/CPA), car des accords d’inter change prédéterminés (gabarits de CPA) définis et adoptés tels quels par les utilisateurs leur sont préférés. En revanche la Recommandation ISO 15000-2 Spécification d’un système de messagerie eBusiness fait l’objet de nombreuses utilisations convaincantes dont les plus significatives sont décrites dans la rubrique DiversUtilisateurs accessible infra depuis ce document. S’agissant des Web services, trois types de déploiement sont possibles :
Les utilisateurs et les filières face aux choix d’architectures techniques Le choix d’une architecture technique peut être opéré par une filière toute entière (exemple : le Center for Control Disease avec ebMS2 ou GS1 avec AS2) mais il peut aussi être décidé au niveau d’une entreprise. Un tel choix peut ne pas être unique. Ainsi le programme Rosettanet utilise un MMS (ou Multiple Messaging Service) qui propose non pas un choix unique mais une gamme de choix, adapté à différents types d’usage et à des types de relations plus ou moins intimes et confiantes entre les partenaires. Toutefois, disposer d’une variété de solutions ne signifie pas que les projets utilisent n’importe quoi, ce qui serait un réel obstacle à l’inter opérabilité souhaitable des systèmes e-Business. Cela signifie que les projets utilisent des solutions adaptées à leur besoin mais prises dans un ensemble fini de solutions possibles. C’est cet ensemble de solutions qui est ici rassemblé, présenté et commenté : Plan de l'atelier "Architecture Technique" Le présent CD contient donc entre autres (cliquez ici pour le contenu complet du CD):
A partir du matériau réuni dans ce CD ROM, le programme TIC PME et les projets qui le constituent seront en mesure de disposer des éléments de décisions rationnels. La notion de plateforme à possibilités multiples tend à s’imposer dans la mesure où elle permet de mettre en place des dispositifs d’inter connexion capables d’être utilisés par des partenaires plus ou moins aptes à gérer des échanges sophistiqués. Il est ainsi possible de contenir le nombre de solutions à quelques unes et qu’elles soient bâties à partir des standards les plus reconnus. Chaque projet, lorsqu’il aura défini ses processus d’affaires, devra inévitablement se poser la question des architectures techniques devant être employées pour les activer. Une étude cas par cas sera indispensable mais elle peut être éclairée dès à présent par le tableau suivant : Comparaison des solutions d’architecture techniques B2B Ce tableau donne une vision suffisante des possibilités offertes par chaque choix possible mais il ne peut être pris comme seule base de référence du choix d’un projet. Nous avons vu plus haut que la notion de Web service comporte au moins trois facettes bien distinctes.
Nous constatons que de nombreux échanges s’accommodent de solutions simples pour réaliser des échanges électroniques professionnels. AS3 sera adapté à des envoie importants et peu fréquents de lots d’e-Docs entre deux partenaires et sans intermédiaires (pair à pair). Le transfert de fichiers FTP convient dans ce cas précis. AS1 sera adapté pour des envois simples et sécurisés en mode messagerie. Un accusé de réception, qui peut être signé, peut être demandé. AS2 sera adapté pour des envois simples et sécurisés en mode http. Un accusé de réception peut être obtenu de manière synchrone. Dès lors qu’il faut gérer des échanges électroniques plus complets, ebMS2 devient utile car il permet de gérer – grâce à l’extension SOAP qui le caractérise - des flots de documents, des suites ordonnées de messages, des aiguillages de messages (Service et action sur le message). La spécification, à venir, de messagerie ebXML ebMS3 partage autant que faire se peut des briques de base avec les Web services tels que définis pas le consortium WS-I. Enfin les Web Services ont des avantages notamment celui de permettre – sous certaines conditions – un fonctionnement externe assez voisin d’un fonctionnement interne. Mais c’est aussi un inconvénient qui s’analyse en termes de difficulté d’étendre les Web services à un nombre trop important de partenaires. Pour conclure, les Architectures Techniques pouvant être confortablement utilisées par les projets B2B, car conçues à leur intention, ne sont pas si nombreuses que cela. Une même entreprise peut souhaiter disposer de passerelles multifonctions ou « versatiles ». Certains projets définissent différents profils relatifs aux différentes options possibles. Le CD ROM ici joint donne des exemples de tels profils pour AS2, ebMS2 et Web services. D’autres viendront probablement s’y ajouter. Les projets TIC PME pourront s’appuyer sur ce premier travail lorsque le moment sera venu pour eux de faire leur choix. Ils pourront aussi compter sur le soutien technique.
Contact : Rémy Marchand, AFNeT, remy.marchand@afnet.fr, Tél. +33 1 53 43 82 70 |
Contributors :
Last modified 2007-08-02 02:35 PM