VendrEDI | ![]() |
lettre de Claude Chiaramonti | ||
sur les
données de l'échange électronique | ||||
Numéro 66 29 août 2003 |
SOAP 1.2 ratifiée |
EDIINT en Europe : | |
recommandation du
W3C |
l'offre de Sterling
Commerce |
Mises au point dès 2000 par
Microsoft, IBM et alii, les versions SOAP 1.0 puis 1.1 n'avaient
jamais été formellement ratifiées par un
standard body, même
si le framework ebXML avait bien
été obligé de s'y rallier : c'est enfin
le cas aujourd'hui pour la version
SOAP 1.2 qui, après tests rigoureux et
implémen-tation, est devenue en juin une proposition de
recom-mandation du W3C. SOAP était déjà
standard de facto, et va donc le devenir maintenant de
jure. Mais pas encore norme ISO ! Et la politique du W3C ne
voulant pas de droits d'auteur sur les stan-dards du Web marque un
point.
Le W3C est fier de montrer que SOAP 1.2 est
très officiellement
soutenue par les grands offreurs qui vont l'incorporer
dans leurs produits, depuis Micro-soft, IBM, BEA et SAP
jusqu'à Sun et Oracle, plus WS-I qui va l'inclure
dans son Basic Profile (cf VendrEDI n°
64). Le principal standard de base des Services Web
est donc maintenant théoriquement assez stable pour que
les hésitants se décident !
Le W3C explique en
9 points quelles sont les amé-liorations de cette
nouvelle version SOAP 1.2 : elle est cleaner,
les ambiguïtés du processing model ayant
été supprimées, ce qui assure une meilleure
interopérabilité ; elle est basée sur
l'Infoset XML, ce qui la rend plus indépendante des moyens de
transport et plus performante ; elle tient compte des
dernières technologies et standards du Web et en tire profit ;
son extensibilité est mieux formalisée.
Le W3C montre ainsi qu'il ne s'intéresse
pas seu-lement au futur Semantic Web, mais aussi aux
besoins actuels des entreprises concernant l'archi-tecture et les
core technologies des Services Web. Tout autant
qu'Oasis ! Le W3C développe ainsi une importante
Web
Services Activity avec plusieurs groupes de travail
coordonnés : architecture des Services Web, XML
protocol en liaison avec l'IETF, SOAP, WSDL et
choreography. Leurs travaux peuvent être
suivis publiquement.
Après SOAP 1.2, prochaine étape pour
le W3C : les companion standards de SOAP et notamment
WSDL. La prochaine version WSDL 1.2 tiendra compte de
l'extensibilité de SOAP 1.2, mais les services de SOAP 1.2
peuvent être dès maintenant décrits avec WSDL 1.1.
Restera la choreography où Oasis, rejoint par
Microsoft, mène la danse ! |
Le protocole
EDIINT (EDI Internet Integration) AS2 de l'IETF
pour un EDI sécurisé sur Internet débarque en Europe
après s'être répandu aux USA. Voir les
numéros
42,
55
et
58
de VendrEDI. Son avantage est l'économie substantielle qu'il
procure en permettant de se passer des échanges asynchrones
d'un RVA grâce à une connexion directe et permanente
sécurisée : en plus du "real-time,
point-to-point connections", AS2 assure ainsi "data
integrity, privacy, authenticity and non-repudiation". C'est
à dire que chiffrement et certificats numériques
permettent d'être sûr de l'intégrité
du document, dont seuls l'expéditeur et le
destinataire peuvent lire les données, la provenance
étant garantie avec, en retour, accusé de réception.
Mais comme en EDI classique où un accord d'interchange
préalable est nécessaire, l'échange préalable
des certificats est indispensable.
Comme aux USA avec Wal-Mart ou Coca-Cola,
c'est en Europe la grande distribution, du fait de ses volumes
importants de messages, qui est le vecteur principal d'une
très réelle diffusion d'AS2. Ainsi, Auchan a
décidé de passer en AS2 l'ensemble de ses relations EDI
avec ses fournisseurs.
De même que Wal-Mart, Auchan a
choisi pour cette
migration
Sterling Commerce qui a, en effet, été parmi les
premiers, dès 2000, a être certifié AS2. Sterling
Commerce propose des outils AS1 (SMTP) et AS2 (HTTPS) pour
tout type de docu-ment, EDI, Word etc. Les options AS2 vont de
la gestion de communauté EDI à l'externalisation en
passant par des Sterling Integrator pour un grand ou petit
nombre de partenaires. Cette
offre AS2 complète la gamme
de Sterling Commerce : la plate-forme de communication
Gentran qui permet d'intégrer, par exemple pour SEB,
flux EDI et applicatifs internes passant en SAP, ou, pour
Saint-Gobain par exemple, eTransaction Manager, qui permet
d'envoyer des messages EDI par e-mail.
Encore une fois, dommage que les instances
Edifact, au lieu de seulement s'enliser dans un framework
ebXML pour après-demain (au mieux), n'aient pas aussi
milité p ![]() |
![]() |
Pour que "le message passe" il faut être d'accord sur le sens des données Petit Glossaire du B2Bfr |
WS-* pour la
sécurité |
Core Components | |
Qui standardise les WS ? |
|
ou données contextuelles
? |
Misant beaucoup sur les Services Web
(WS), Microsoft, IBM, Sun et les autres ont bien
perçu l'enjeu d'une sécurité et d'une
"maniabilité" des Services Web enfin convaincantes pour
les utilisa-teurs. Les annonces de nouveaux WS-*, en juillet
dernier, montrent que les vendors n'ont pas
chômé :
- WS-F : en même temps que Novell, qui a
publié son NSure Audit, Microsoft, IBM, Verisign et
RSA Security ont annoncé WS-Federation qui doit
compléter WS-Trust et WS-Security comme
outil d'authentification des différentes identités
utilisées par les entreprises ou les particuliers. Le but
étant de sécuriser la mise en oeuvre d'un Service
Web par la fédération des identifications des
intervenants. Microsoft et IBM expliquent leur vision dans un livre
blanc commun
téléchargeable. Du
coup, les anti-Microsoft regroupés au sein de Liberty
Alliance ont vite, eux aussi, annoncé un guide pour
fédérer les identités : il faut espérer que
SAML d'Oasis pourra continuer
à jouer les go-between !
- WSE
version 2 : annoncé
par Microsoft seul. Lui aussi basé sur les
précédents WS-* qu'il met en oeuvre (cf
VendrEDI
n°60), WS-Enhancement est un outil
(seulement en preview) qui doit notamment permettre aux
développeurs de vérifier que des Services Web
internes à l'entreprise peuvent être proposés sans
risques à l'extérieur.
-
WS-CAF : Web Services Composite Applica-tion
Framework, a été annoncé
par Sun, Oracle, IONA, Fujitsu et Arjuna et vise à
permettre la mise en oeuvre combinée de Services Web
différents dans le cadre de processus métiers complexes.
Le principal outil de WS-CAF fournit un contexte commun, par
exemple assister à une conférence, pour lier ensemble
l'achat du billet d'avion et les réservations d'une voiture et
d'une chambre d'hôtel. Certaines de ces
fonctionnalités étant déjà incluses dans
des propositions de Microsoft, en particulier BPEL4WS, WS-CAF est
donc une tentative d'équi-librage des anti-Microsoft : en
effet, ni Microsoft, ni IBM, ni BEA, n'en sont partie
prenante. Mais cela risque de rendre inopérante la
soumission de WS-CAF à un standard body. Car
Microsoft et ses alliés (IBM et BEA, SAP et
Siebel) ont déjà soumis BPEL4WS à Oasis dont le TC
WSBPEL a com-mencé ses travaux et paraît
incontournable.
En effet, malheureusement, comme les
standards bodies font double emploi en matière
de Services Web, et donc ne jouent pas bien leur rôle, le
marché est, en fait, vendor driven, et c'est le
standard body qui a Microsoft et ses alliés dans
son camp qui peut prétendre standardiser les Services
Web. |
L'idée des Core Components (CC)
ebXML est de parvenir à distinguer, dans chaque donnée de
l'e-business, l'information qui est son "coeur" en le
dégageant de la gangue de ses contextes,
géo-graphique et sectoriel. Ensuite, on désignera
les organismes habilités à enregistrer les CC de
leur domaine et chaque utilisateur pourra ainsi se
référer à un réseau de répertoires de CC,
pour y trouver celui dont il a besoin, quitte
à préciser ses contextes d'utilisation à lui.
La question est de savoir si une information sans contexte a
un sens ! La théorie de la relativité nous dit que non !
A quoi bon alors enregistrer ce qui a été privé de
son sens ?
Deux exemples : l'identification des
entreprises et leur chiffre d'affaires, données simples qui,
pourtant, n'ont aucun sens sorties de leur contexte ! Des
identifiants d'entreprises EAN, Insee, Swift ou Dun &
Bradstreet se réfèrent à des contextes
spécifiques qui sont la seule réalité du
business. Dégager le CC "entreprise" de ces contextes
n'aura guère d'intérêt pratique : retrouver la
même entre-prise dans plusieurs de ces contextes se fera
toujours par un mapping direct entre identifiants
contextuels pour être sûrs de ne pas se tromper
! Donc sans avoir besoin d'aller chercher dans un
répertoire de CC, le "coeur" informationnel abstrait d'un
identifiant sans ses contextes concrets.
De même y a-t-il 27 définitions du
chiffre d'affaires
pour autant d'applications
administratives, comp-tables ou statistiques. Quel
intérêt d'en dégager le "coeur" pour savoir que
l'une est égale à une autre, moins les travaux en cours,
plus les travaux faits par l'entreprise pour elle-même
etc. ? Il n'y a pas de "chiffre d'affaires" en dehors du
contexte d'une réglementation : c'est pourquoi il restera 27
défini-tions du chiffre d'affaires pour autant d'applications,
tant que le législateur ne voudra pas simplifier.
Justement, l'argument de l'utilité des CC
pour ne pas en recréer qui existent déjà n'est pas
convain-cant. Ou bien le contexte est équivalent et c'est
la donnée contextuelle entière qui sera reprise, ou bien
il faudra créer une nouvelle donnée ! Autrement dit, ce
dont on a besoin, c'est de répertoires de données avec
leurs contextes, sans que leur décortication en CC + contextes
ait la moindre utilité pratique !
Le concept des CC ebXML n'est donc pas
adapté à la réalité de l'e-business
dont les données sont contextuelles : et c'est
plutôt le langage RDF
et ses
assertions
en triplets (sujet, propri
![]() |
Ce numéro 66 de VendrEDI a été adressé à 1117 abonnés Pour écrire |
Tous les numéros de VendrEDI peuvent être téléchargés zippés à http://www.actimum.com/acvendredi.htm |