Bonjour,
 
Ci-dessous VendrEDI n° 86.
 
Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Appel à retour d'expériences (ou annonces de projets ou même simples commentaires) sur le recours aux Services Web en mode EDI
 
Certes, les Services Web sont censés commencer par la "découverte" du service recherché décrit en WSDL dans un répertoire UDDI.
 
Mais, une fois le service découvert, et son "invocation" ayant donné satisfaction, peut se poser la question de le réutiliser régulièrement et automatiquement. Par exemple, comme en EDI, quand l'application de gestion des stocks émet des messages de réapprovisionnement à l'attention des applications des fournisseurs.
 
Pour préparer et véhiculer, d'application à application, de tels messages répétitifs, les outils des Services Web peuvent être utilisés, en particulier BPEL et SOAP, plus, si besoin, certains des standards de la gamme WS*. Sans qu'il y ait besoin de passer à ebXML, RosettaNet et autres frameworks.
 
Afin d'étayer un prochain article de VendrEDI sur ce sujet, je suis preneur de tout commentaire sur cette possibilité d'utiliser directement les Services Web en mode EDI.
 
Merci d'avance !
 
Cordialement
 
Claude Chiaramonti
 
 
 
 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
           Numéro 86      19 novembre 2004
   Reliable Messaging 
  Téléprocédures : 
   en Services Web comme en EDI
     EDI+EFI et Edifact+XML
Les messages EDI bénéficient d'une garantie de bon acheminement assurée par le RVA par lequel ils transitent. Les messages des Services Web (SW), comme ceux de l'EDI en AS1-AS2, passant simplement par Internet ne bénéficient donc pas a priori de cette garantie : d'où l'importance, pour la confiance dans les SW, puisqu'il n'y a rien de prévu, ni dans HTTP, ni dans SOAP, qui l'assure, d'un standard supplémentaire (du type WS-*) assurant que le messaging sera bien reliable.
En effet, les messages d'un SW complexe, allant au-delà d'une simple demande de cours de Bourse, doivent être échangés dans un ordre spécifique scrupuleusement respecté, chacun de ces messages ayant une répercussion sur les suivants : demande de prix, offre de prix, commande, acceptation de commande par exemple. Et en l'absence de contrôle humain, des SW automatisés supposent qu'un mécanisme saura bien assurer ce bon ordre, et que les applications émettrices et réceptrices de ces messages seront bien informées, et en phase, à leur sujet. Cela suppose, en conséquence que les outils utilisés des deux côtés aient bien recours au même standard pour ainsi pouvoir mettre automatiquement en oeuvre des services à distance !
Et, comme souvent dans les WS-*, il y a deux propositions de protocoles standards concurrents :
    - WS-Reliable Messaging, proposition de BEA, IBM, Microsoft et Tibco ;
    - WS-Reliability de Sun, Sonic, Fujitsu, Hitachi, NEC et autres, proposition se référant à ebXML, et depuis ce mois standard Oasis.
Les deux ne garantissent pas le bon acheminement des messages, mais simplement que l'information sur cet acheminement sera identique des deux côtés, par exemple qu'un message n'a bien été envoyé et reçu qu'une seule fois. Malgré cette  convergence, ces deux propositions de standards ne sont pas interopérables ! Si cette concurrence n'est pas une mauvaise chose au départ, il faudrait que le marché tranche, et qu'une seule de ces proposi-tions, ou une combinaison des deux, finisse par s'imposer ! Pour faciliter les SW. Et il est dommage que  "l'amitié" de Microsoft et Sun en matière de standards WS-* ne leur ait pas permis de se "relier" à ce sujet !
 
Les téléprocédures fiscales, sur la TVA et l'impôt sur les sociétés représentent déjà plus de la moitié des encaissements du Minefi. Non seulement des grandes entreprises et des PME, mais même des TPE, au besoin par l'intermédiaire de leur cabinet d'expert-comptable. La télédéclaration peut être soit automatique en EDI (machine to machine de l'entreprise à la DGI), ou semi-automatique (human to machine) avec ressaisie de ses données par l'entreprise sur un formulaire EFI. Si l'entreprise est déjà "édifiée", cette ressaisie des données en EFI est, bien sûr peu astucieuse. Mais, à l'inverse, passer à l'EDI pour économiser la ressaisie de quelques données, c'est recourir à un marteau pour écraser une mouche ! Par contre, en EFI, il faut autant de certificats électroniques de confiance (30 à 100 euros chacun pour deux ans) que de personnes pouvant intervenir (congés etc.) alors qu'en EDI c'est l'application seule qui est certifiée.
In fine, EDI et EFI sont donc complémentaires et n'ont pas à être opposés. Parmi les portails de déclaration, si Net-entreprises.fr s'est spécialisé dans le social en EFI, d'autres, comme le portail   jedeclare.com (experts-comptables, SSII et banques) reçoit social ou fiscal,  aussi bien des entreprises que des cabinets d'experts-comptables qui déclarent pour le compte de centaines d'entre-prises, et donc ne peuvent le faire qu'en EDI auto-matisé. Ce qui simplifie d'ailleurs le mandatement des cabinets par les entreprises quant aux certificats de confiance intuitu personnae exigés par la DGI !
Le portail jedeclare.com respecte le cahier des charges de l'association Edificas qui a mis au point les messages Edifact de télédéclaration comme leurs équivalents XML. Selon son fondateur, Michel Lesourd, d'autres téléprocédures fiscales que la TVA ou l'impôt sur les sociétés devraient d'ailleurs être mises en oeuvre par les experts-comptables :
- communication aux banques  des comptes annuels des entreprises (les greffes les attendent également)
- déclaration des revenus IRPP des artisans à partir des données comptables. Ces téléprocédures à venir étant faites suivant le format Edifact ou selon son équivalent XML, suivant ce que souhaitera la DGI.
Donc EDI ou EFI, Edifact ou XML, la technique peut s'adapter aux besoins !
 
Pour que "le message passe" il faut être d'accord sur le sens des données   Petit Glossaire du B2Bfr

    Global ET local : 
 
 Sémantique XML : 
     pour vendre à tous dans Babel
 
noyau ebXML CCTS + chair RDF
Si les plus unilatéralistes de nos amis américains se préoccupent de connaître la diversité des cultures mondiales, c'est d'abord pour mieux assurer la vente de leurs produits en les adaptant aux "goûts" de leurs acheteurs étrangers. En effet, les ventes des majors US sont désormais localisées en majorité hors des USA et leurs produits s'y vendront d'autant mieux qu'ils ne heurteront pas les usages. C'est vrai pour MacDo, mais aussi pour Microsoft, par exemple, qui accompagne .Net d'un système de glo-balisation avec RegionInfo, CultureInfo etc.
C'est pour cela que la localisation, d'origine et à usage US, est ainsi octroyée top down aux indigènes locaux. Edifact, au contraire avait réglé le problème du locale en bottom up : les données transmises sont codées (sauf noms et adresses), et c'est à chaque destinataire de se confectionner un affichage "localisé" en clair dans sa langue à partir du répertoire officiel, bien sûr, en anglais.
Le recours à des données localisées est propre à chaque type de produit, du hamburger aux notices d'utilisation des logiciels et à l'habillage des jeux vidéo. Cela commence néanmoins par les données universelles, valables pour tous les produits : langue, devise, unité de mesure, taxes et autres réglemen-tations. Certes, il y a les normes ISO en la matière. Mais elles peuvent être complétées et précisées, par exemple par la proposition de Phillips à l'IETF concernant la norme identifiant les langues.
A noter que si la localisation (ou localization aux USA) va bien au-delà de la simple traduction, il faut d'abord rendre hommage au standard Unicode qui permet d'utiliser toutes les langues et alphabets connus, latins ou non, avec accents ou non.
Pour la localisation des standards XML, le groupe de XML.org  Focus Area on Localisation avec un centre de recherche irlandais et un projet européen, passent en revue l'existant pour son adaptation "culturelle", et d'abord pour la traduction en utilisant XLIFF (XML Localisation Interchange File Format) d'Oasis comme format intermédiaire (cf un Livre Blanc). A citer aussi le projet CDLR lancé par IBM, Sun, Linux et OpenOffice.
Un article d'IBM explique la mise en oeuvre de XLIFF en liaison avec d'autres formats d'aide à la traduction comme TMX ou TBX de Lisa (Locali-zation Industry Standards Association), dont le Forum du mois dernier, au Dysneyland de Marne la Vallée, a réaffirmé l'enjeu économique et social du multilinguisme et de la "localisation". Pas seulement pour les majors US, mais aussi pour les sites Web ou les notices des entreprises francophones.
 
La liberté de création de langages métiers avec le métalangage XML sera d'autant plus efficace si elle peut s'appuyer sur l'existant : inutile de réinventer la définition de la roue si on peut la trouver formulée dans un directory accessible ! Mais ce n'est pas si simple : on peut, en effet, constater qu'il y a bien toujours la partie sémantique du  directory TDID d'Edifact, mais sa suite attendue, les Core Components ebXML du Cefact-Onu, n'est pas  complétée. Et c'est le chaînon manquant qui con-tinue de faire bien défaut à ceux qui définissent un vocabulaire XML vertical, comme le fait remarquer
Nicolas Maurin d'Arcelor. Seule la spécification technique  ebCCTS a été adoptée comme telle par l'ISO TC154 ; le groupe d'Oasis UBL,Universal Business Language, s'y réfère déjà dans ses Naming and Design Rules, adoptées ce mois par des contributeurs très anglo-américains, à la notable exception de Fabrice Desré de France Télécom. Et UBL fournit bien un directory de définitions qui a été validé comme standard par Oasis sans attendre le Cefact. Bien qu'ayant été adopté par le Danemark (VendrEDI n°73), ce standard ne comprend pas toutes les définitions de la supply chain : il y manque des définitions, ne serait-ce que pour les appels d'offres électroniques européens.
Mais un directory, même incomplet, présente quand même l'intérêt de fournir le noyau, le core, sur les informations universelles, adresses, identifiants etc. qui ne sont pas à réinventer. Du type des définitions que la Dublin Core Metadata Initiative (DCMI) propose pour le core des documents de l'édition etc.
Mais la DCMI utilise RDF, ce qui permet à tous d'enrichir librement le core en tant que de besoin. La sémantique des Services Web, elle aussi peut utiliser RDF avec OWL-S (VendrEDI n°83) et peut donc s'étendre par adjonctions successives de défi-nitions reliées au core par RDF. D'ailleurs Oasis, parallèlement à ses groupes ebXML/UBL, poursuit aussi un projet XDI (VendrEDI n°73) pour localiser et partager toutes les données du Web exprimées en RDF, comme prévu par le Semantic Web du W3C.
Il devrait en être de même pour ebXML pour qu'il ne reproduise pas le splendide isolement d'Edifact ! Il ne suffit pas de "faire son marché" parmi les "articles" Core Components isolés dans leur rayon : la sémantique XML bénéficie avec RDF et les namespaces de la possibilité de relier les "notices explicatives" de tous les articles ! Chacun peut ainsi agréger au noyau des Core Components la chair des données spécifiques à son langage métier, explicitées avec RDF.
Ce numéro 86 de VendrEDI a été adressé à 1355 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés à  http://www.actimum.com/acvendredi.htm