Bonjour,
 
Ci-dessous VendrEDI n° 72. Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Suite au message d'envoi du n° précédent de VendrEDI remerciant les sites référençant les articles de VendrEDI, P.Y. Lefort mentionne son site http://www.auditlogfrance.com destiné notamment à ses étudiants.
 
De même, suite à l'article de ce précédent n° sur RELAX NG, est disponible la  version française du tutorial sur la spécification RELAX NG du 3/12/2001.
 
Cordialement
 
Claude Chiaramonti
 
 


 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
           Numéro 72      23 janvier 2004
      Standards de SW  
 
  ebXML et Cefact :
      pour une large mise en oeuvre
chronique d'un échec annoncé
Le développement des Services Web (SW) est encore lent, du fait de l'expectative des utilisateurs. D'où le "cessez le feu" des offreurs réunis au WS-I pour garantir l'interopérabilité de leurs produits dans la mise en oeuvre des standards de SW. Ce qui ne les empêche pas de poursuivre une saine (?) concurrence dans la mise au point de nouveaux standards destinés à bien rassurer les utilisateurs. Et pour ce faire,  c'est toujours Microsoft, IBM et Sun qui composent autour d'eux des équipes à géométrie variable. On avait pour la sécurité, plutôt concur-rents, SAML, WS-Reliability et WS-Security.
Aujourd'hui,  peut-être un peu moins concurrents, on trouve WS-CAF, WS-Eventing, WS-Manageability, sans oublier le CC/PP du W3C, tous destinés à une large mise en oeuvre des SW.
Le groupe d'Oasis WS-CAF (plutôt Sun etc.) vise à la mise en oeuvre combinée de SW différents dans un contexte commun  (VendrEDI n° 66) et prétend donc élargir le management prévu par WS-BPEL,  autre groupe d'Oasis, lui plutôt Microsoft.
WS-Eventing est aussi plutôt Microsoft et porte sur le partage d'informations sur des "événements" réels (commande etc.) entre SW, tenant compte de con-textes complexes. Une "souscription" permet ainsi à un SW d'être informé (avec SOAP) pendant une période donnée de certains événements d'un autre SW, mise à jour de catalogue etc. Mais IBM vient d'annoncer une autre proposition : WS-Notification.
WS-Manageability vient d'IBM et CA, avec une concurrence de HP, et est notamment destiné à la traçabilité des SW exécutés.
Enfin la recommandation CC/PP du W3C, soutenue par Sun, Boeing etc. vise à faciliter l'accès au Web et à ses services à partir de tout type de terminal, y compris les téléphones mobiles. Noter que le W3C n'a pas voulu développer pour le CC/PP des Core Components pour décrire tous les types de termi-naux, mais utilise RDF pour relier les langages de description propres à chaque type de terminal.
Au total, la concurrence entre standards devrait s'atténuer : comme le montre l'oecuménisme du WS-I, ou l'accord Microsoft-IBM, les offreurs savent qu'ils gagneront plus à une large mise en oeuvre de SW fondés sur des standards ouverts, qu'à des droits sur des standards inutilisés...
 
Lancé à la rentrée 1999 par Oasis et le Cefact-Onu, le framework ebXML devait remplacer l'EDI com-me standard de l'e-commerce B2B. Mais Microsoft, étant resté en dehors d'ebXML soutenu par Sun, a réussi à entraîner, dès 2000 IBM etc. dans la promotion de ce qui allait s'appeler SW (Services Web) et concurrencer ebXML comme paradigme d'avenir. Car, de même que TCP a fait oublier OSI, les Services Web font oublier un ebXML beaucoup trop complexe si l'on se rappelle du repository de profils d'entreprises devant permettre (en 11 étapes) à des PME de se lancer dans un scénario commun d'e-business ! D'ailleurs peu de produits et donc  d'implémentations sont apparus.
Deuxième étape, le couple Oasis-Cefact devait avoir une garde séparée de leur "enfant" ebXML. Oasis devait développer de son coté une partie technique, qu'il a mise au point et vient de soumettre en fast-track au TC 154 de l'ISO. Le contenu métier, BP (Business process) et CC (Core Components) devant rester de la responsabilité du Cefact. Comme le Cefact n'avance pas vite, Oasis a créé en 2003 un groupe BP et son groupe UBL reprend les CC avec les spécifications du Cefact. S'ensuit la double annonce  par la direction du Cefact de la fin de sa collaboration avec Oasis et du BCF (Business Collaborative Framework). D'où des protestations diverses et, fin 2003, l'annon-ce alambiquée que le Cefact continue de soutenir ebXML et, début 2004, une renégociation avec Oasis. Mais peu importe ! C'est sans doute trop tard, l'industrie passe en EDIINT AS2, n'attend plus ebXML et s'est rassemblée au WS-I pour faci-liter la mise en place des SW.
Avec le contenu métier ebXML, le Cefact voulait conserver un processus top down  Edifact adapté aux outils d'Internet. Dés le 1er octobre 1999, un article intitulé "PrEDIcation" du VendrEDI n° 8 exprimait du scepticisme quant à l'opportunité de "corseter" ainsi XML et son eXtensibilité par un framework trop top down. Opinion maintenue, même si le très "top down" DoD (Département de la Défense US) annonce son recours à la technique ebXML pour son portail d'achats. Pour, soit-disant, en terminer avec l'EDI ! Et voilà le DoD avec une guerre intérieure !
  Pour que "le message passe" il faut être d'accord sur le sens des données   Petit Glossaire du B2Bfr

   EDI ou Edifact :
   Apprendre RDF
            de  quoi  parle -t-on ? 
 
pour prolonger l'EDI classique
Les terminologies à la mode donnent parfois une impression de déja vu du temps des débuts de l'EDI ! Par exemple, on utilise l'expression de loose coopling pour montrer que les systèmes à relier par des Services Web doivent rester les plus décon-nectés et indépendants possibles : mais c'était déjà tout à fait la définition première de l'EDI ! Le langage intermédiaire des messages, type Edifact, étant justement là pour laisser les applications complètement déconnectées au prix d'un mapping au départ et à l'arrivée des messages. Ce qui permettait de dire que l'EDI était indépendant des matériels, des logiciels, des protocoles etc.
Mais l'EDI est forcément ringard ! En fait, on a fa-cilement tendance à confondre la fonction permanente de l'EDI avec la syntaxe utilisée pour la construction des messages, Edifact ou autre. La fonction de l'EDI, c'est de relier des applications informatiques d'entreprises différentes avec des messages dont les formats et les informations véhiculées ont été convenus à l'avance. La fonction EDI est donc très générale et indépendante de la syntaxe utilisée. Comme le faisait remarquer Jean-Louis Jouffroy lors d'une discussion à ce sujet à l'association crEDIble, remplacer Edifact par XML, c'est comme changer un moteur sur un avion : il pourra quand même effectuer son trajet habituel et donc mener à bien sa fonction ! Ainsi quand on annonce la mort de l'EDI en raison des autoroutes de l'information, de l'e-commerce, de XML ou des Services Web, ne parle-t-on pas plutôt d'Edifact et non de l'EDI en général ? Les messages EDI peuvent très bien circuler sur les autoroutes de l'information, participer de l'e-commerce B2B, utili-ser la syntaxe XML à la place d'Edifact, et être considérés comme des Services Web automatisés.
Et de toute façon, l'EDI, y compris dans ses syn-taxes classiques Edifact ou Ansi X12 aux USA, est loin d'être mort et se développe toujours : lors de la conférence XML 2003 en décembre dernier, il a pu être constaté que l'immense majorité du B2B aux USA est toujours en EDI classique avec RVA ou AS2, mais pas encore en XML avec SOAP. Ainsi que le faisait observer Michel d'Araujo lors de la discussion à crEDIble, les utilisateurs ne se préoc-cupent pas vraiment des contenants et ne s'intéres-sent qu'au contenu métier. Alors on peut laisser dire, peu importe, ce qui compte c'est que l'EDI, en Edifact ou XML, soit sans intervention humaine, d'où un gain de productivité pour des transactions répétitives, commandes quotidiennes passées par un supermarché etc.
 
Le 19 janvier 2004 s'est, en principe, terminée la période de review de la proposition de recomman-dation publiée le 15 décembre 2003 par le W3C concernant RDF (Resource Description Frame-work). Cette recommandation a été publiée en six parties complémentaires : Primer, Concepts, Syntax, Semantics, Vocabulary, et Test Cases. La partie Primer est suffisante pour simplement comprendre l'intérêt de RDF.
Destiné au départ à décrire les resources, c'est à dire les pages Web, RDF peut, en fait, servir à tout décrire, objets physiques ou données abstraites, articles en vente, news, personnes physiques ou concepts, cette description étant conçue pour être machine processable. D'où son intérêt pour l'EDI, forme automatisée du B2B, surtout quand il s'exprime en XML, puisque RDF est aussi en XML.
Le sens de ces metadata RDF est exprimé dans des triplets (sujet>attribut>objet), chacun des trois élé-ments de ces triples étant identifié par des URI, Uniform Resource Identifier, donc non pas seule-ment des URL pour les pages Web. Les URI refe-rences de RDF doivent avoir un contenu, une des valeurs de la "propriété" identifiée pour chaque élément du triplet. Une déclaration (statement) RDF est alors un graphe composé d'un arc (l'attribut) reliant deux noeuds (le sujet et l'objet), un ensemble de statements se traduisant par le graphe complexe ou la  série correspondante de triplets. Les URIrefs
d'un même domaine peuvent constituer un "voca-bulaire" et être regroupés sous un URIref commun avec un namespace pour donner des informations sur ce vocabulaire. Mais toutes les passerelles sont possibles entre URIrefs de vocabulaires ayant à communiquer : des graphes ad hoc peuvent décla-rer les différences entre des données voisines de secteurs différents. Ce que ne pouvait pas faire Edifact dans lequel on ne peut pas expliciter en quoi deux valeurs codées  d'une même donnée sont différentes d'un secteur à l'autre. Et ce que ne peuvent non plus réussir ebXML ou UBL. Seul, un outil comme RDF  permet de sauvegarder la richesse de chaque langage métier tout en évitant  la Tour de Babel. Car RDF n'est qu'un outil qui ne contient pas au départ, et heureusement, de séman-tique centrale top down. Mais des déclarations RDF pouvant être ajoutées en tant que de besoin pour éviter toute ambiguïté, autant partir des vocabulaires existants comme les metadata Dublin Core ou, pour le B2B, le TDID Edifact. Donc en préservant l'acquis de l'EDI traditionnel. Allez voir le Primer !
Ce numéro 72 de VendrEDI a été adressé à 1136 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés à  http://www.actimum.com/acvendredi.htm