Skip to content.

Boost Industrie et Services

Sections
Personal tools
You are here: Home » Librairie » Architecture Technique I

Architecture technique

Groupe thématique 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.

modele_conceptuel

Le premier est de l’ordre de la sémantique et couvre la définition et la spécification :

  • Des processus d’affaires ou scénarios d’échange
  • Des documents, improprement appelés messages, et que nous appellerons ici des e-docs (documents électroniques) et qui sont utilisés par les processus d’affaires
  • Des données contenues dans les e-docs

 

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. 
Suivant la terminologie de l’ISO, on traite ici de Vue Fonctionnelle des Services ou Functional Service View (FSV).

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).
ebXML ebMS: ISO 15000-2 Spécification d’un système de messagerie eBusiness
ebXML RIM: ISO 15000-3 Modèle d’information d’un registre pour les systèmes eBusiness
ebXML RS: ISO 15000-4 Spécification d’un registre pour les systèmes eBusiness
ebXML CCTS: ISO 15000-5 Spécification des composants de données essentielles.

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 :

  • Modèle - Publication d’un service Web (Web Publishing) suivant les modalités d’une ressource ordinaire du Web et de façon comparable à celles bien connues Amazon, eBay ou Google.

web_publication

  • Modèle - Interface d’application d’affaire distante (Remote Business Application Interface) suivant lequel un service Web est rendu publiquement disponible à des partenaires pré sélectionnés afin de leur permettre d’interconnecter leurs processus d’affaires.

interface_application

 

  • Modèle – Passerelle d’intermédiation (Gateway-Mediated deployment pattern), au moyen de laquelle un système de messagerie découple l’échange B2B déclenchant une invocation de service et l’invocation d’un service Web proprement dite qui reste opérée sur le plan interne et est donc non accessible à des tiers. La passerelle agit ainsi comme un point d’entrée vers une architecture interne orientée services (SOA).

passerelle


Les utilisateurs et les filières face aux choix d’architectures techniques
 
Le fait de disposer d’une variété de solutions présente un avantage.
Il permet aux utilisateurs de faire un choix le plus en adéquation avec leur besoin, tantôt simple à satisfaire (envoi d’e-docs de quelques types, à quelques partenaires avec une fréquence faible et peu ou pas de scénario d’échange complexe) tantôt complexe et exigeant des Architectures riches de fonctionnalités.

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):

  1. Les standards eux-mêmes en distinguant :
  1. Les solutions adoptées et adaptées par les grandes communautés d’intérêt, sans prétendre à une couverture exhaustive mais en réunissant un échantillon représentatif d’implantations d’envergure ou appelées à le devenir.
  1. Les évaluations et expertises, partie appelée à être augmentée de nouveaux avis d’experts.

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.
Ces plateformes peuvent être proposées en tant que services hébergé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

  


comparaison

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.

  • La première permettra de publier pour le public le plus large possible certaines informations essentielles, par exemple un catalogue de produits.
  • La seconde permettra des interactions distantes entre des processus d’affaires de deux ou plusieurs partenaires, généralement peu nombreux et étroitement liés à l’entreprise.
  • La troisième facette est une passerelle d’intermédiation, prenant en charge des invocations de services et y répondant mais ne les traitant pas directement.

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).
On pourrait dire qu’AS2 est un ebMS2 simplifié.

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.
L’existence d’une variété de solutions permet de faire face à la variété des besoins et à la diversité des intervenants, par leur taille et la nature de leur activité.

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

Created by Admin AFNeT
Contributors :
Last modified 2007-08-02 02:35 PM
« September 2017 »
Su Mo Tu We Th Fr Sa
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
 
 

Powered by Plone

This site conforms to the following standards: