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