VendrEDI | ![]() |
lettre de Claude Chiaramonti | ||
sur les
données de l'échange électronique | ||||
Numéro 64 6 juin 2003 |
WS-I un an après : |
EDI, Internet, SW : | |
pédagogie de mise en
place |
une évolution sans
rupture |
Avant les travaux pratiques, un cours
théorique sur les Services Web : la dernière
version
de
Web Services Architecture
publiée par le W3C. Ensuite la pédagogie de mise en place
: lancée en février 2002 par Microsoft, IBM, SAP, Oracle
et autres,
WS-I
(Web Services Interoperability Organiza-tion) entend
devenir un forum d'où fournisseurs et end users,
d'une part exprimeraient leurs besoins communs aux instances
de standardisation, d'autre part aideraient à
l'implémentation des Services Web. WS-I a fini par
admettre Sun à son Board et peut
donc désormais prétendre qu'elle recherche pour tous
l'interopérabilité ! Y compris avec propositions de
Sun, concernant Java par exemple, pas for-cément alignées
sur les premiers travaux.
Les quelques 170 membres de WS-I (dont
20% de non-vendors) ne cherchent pas à produire
de nou-velles spécifications pour les Services Web, mais
seulement à vérifier que la mise en oeuvre des standards,
estampillés séparément IETF, W3C, Oasis ou
autres, aboutit bien à
l'interopérabilité.
WS-I a commencé par publier un
Basic Profil 1.0, recommandant comment bien
articuler ensemble, SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0 et XML
Schema, pour le messaging, la description de
services, la discovery et la sécurité.
Ce profil de base comprend des cas de scénarios, par exemple
concernant le Supply Chain Management, des best
practices et des outils de tests. Extension prévue, un
Basic Security Profile pour aider à
l'interopérabilité entre les différents
mécanismes de sécurité proposés (cf
VendrEDI
n° 60).
Développeurs et utilisateurs sont
invités à tester leurs Services Web à partir des
requirements et de rendre publics les
résultats. Les outils de ces tests sont le
Monitor, qui stocke les messages adressés ou revenant
d'un Service Web, pour que l'Analyzer vérifie la
conformance au Basic Profile de ces messages ainsi
que des schémas XML ou aspects UDDI et WSDL du Service
Web ayant été invo-qués. Sans pour le
moment de procédure formelle de certification , tous les
autres aspects du service Web n'étant pas vérifiés
systématiquement. Ces outils de tests peuvent aussi être
utilisés en phase de développement ou pour identifier une
cause d'échec de transaction. Une pédagogie
concrète. |
Si l'EDI traditionnel est toujours la partie
essentielle du B2B, la montée en charge, même
lente, de XML pour le format des messages et d'Internet
pour leur transport, par exemple en Services Web (SW) sans RVA,
fait apparaître des filières parallèles
appelées à se rejoindre. C'est le cas, par exemple, du
fer et de l'acier en Europe. D'une part, Eurofer continue à
créer de nouveaux subsets de
messages Edifact, traduits ensuite dans une version XML (gamme
ESIDEL). D'autre part, la place de marché
électro-nique (hub) du secteur, STEEL24-7,
complète l'EDI par une possibilité d'intégrer à
moindres frais ache-teurs et vendeurs du secteur en Services Web.
Mais Eurofer et STEEL24-7 travaillent à une conver-gence de
leurs processus d'intégration dans le cadre d'ebXML,
grâce notamment au recours à ebMS (ebXML Messaging
Service) qui est un standard Oasis. En considérant
qu'il y a peut-être là une manière d'améliorer
la reliability insuffisante des Services Web. D'ailleurs,
ebXML se présente main-tenant comme le meilleur
framework pour une mise en oeuvre fiable des Services Web
!
Autre cas de figure d'une évolution sans
révolution : le passage de l'EDI sur Internet en utilisant le
protocole EDIINT AS2 du W3C qui divise par 10 le coût des RVA,
tout en supposant que les parte-naires soient capables de
s'assurer les mêmes ser-vices. Mais il n'y a pas
forcément rupture : GXS, (Global eXchange Services,
anciennement GEIS), RVA mondial s'il en est, annonce en effet une
offre AS2 qui, d'une part représente une économie pour
les majors, et d'autre part comprend pour leurs petits partenaires
un préparamétrage de leurs spécifica-tions pour
faciliter l'implémentation.
Evolution et non rupture révolutionnaire,
c'est ce que les utilisateurs souhaitent. Ceux qui ont
déjà investi en EDI, et ne veulent pas en faire table
rase, les nouveaux, qui veulent pouvoir être liés à
tout le monde, quelque soit la technologie, le protocole etc.
Ce qui veut dire qu'il faut en finir avec
l'esprit de chapelle : il n'y a pas qu'une filière, il n'y a
pas qu'un framework. Il faut aussi intervenir dans les
con-sortiums proposant les
standard
![]() sectorialité qui ne soit pas seulement
US. |
![]() |
Pour que "le message passe" il faut bien être d'accord sur le sens des données à transmettre |
Web distribué |
InfoPath et eDocs : | |
de
manière personnalisée |
|
du formulaire aux Services
Web |
RSS, RDF Site Summary, est un
outil XML d'as-semblage personnalisé de descriptions de
contenus de sites Web : titre, URL,
résumé, etc. en utilisant RDF :
RSS 1.0. Mais RSS existe aussi sans RDF (RSS 2.0) et
peut se lire Rich Site Summary ou Really Simple
Syndication. Eric van der Vlist, qui est membre du groupe
international de développement du "RSS avec RDF" et
l'utilise pour la gestion du site
XMLfr, pense que
c'est bien l'utilisation de l'outil sémantique RDF
(Resource
Description Framework) qui permet à RSS
d'avoir une valeur ajoutée sémantique pour
l'invocation automatique et personnalisée de contenus
Web. Le W3C est d'ailleurs convaincu que c'est ce type
d'applications de RDF qui fera démarrer le Semantic
Web qui vise précisément à automatiser
l'accès aux données du Web. RSS est d'ailleurs un vrai
"liant" sémantique puisqu'il peut recourir aussi
aux namespaces et à la syntaxe
Dublin Core. De même, les RSS
channels utilisés décrivant une source en
tant que feed peuvent être transformés en
XTM (XML Topic Maps) pour faire ressortir
statistiques et associations. De même, encore, les RSS
feeds pourraient être enregistrés en
UDDI, en plus des registres RSS spécifiques.
Au départ, RSS a été surtout
utilisé pour la syndication de news, c'est
à dire leur "publication simultanée dans plusieurs
journaux" (Harrap's) avec une organisation facilitant ensuite
l'interrogation. Donc une automatisation de la distribution en
push ou de l'invocation en pull, grâce
à un outil Aggregator, isolé ou inclus dans
Outlook etc.
Et pourquoi pas de même
utiliser RSS dans le B2B en général ? Pour les
catalogues électroniques en remplaçant les metadata sur
des news par celles sur des items ou
des services, y compris leur disponibilité :
en diffusant ainsi les mises à jour de ses
catalogues (ou tout autre contenu de site Web) à
ses clients en fonction de leurs habitudes
d'achat, en permettant aussi aux clients de com-mander la
visualisation des catalogues contenant des mises à jour les
intéressant.
Des acteurs majeurs du B2B utilisent
déjà ainsi RSS pour leur e-marketing clients ou
prospects. RSS permet en effet d'avoir des portails plus dynamiques
et personnalisés et complète (sans spam) les
e-mails. A côté de l'e-marketing,
cette fonctionnalité de RSS permettant une distribution
personnalisée de contenus web est sûrement utilisable
dans d'autres secteurs où le push d'une information
ciblée est importante. Comme des mises à jour
diverses, lo-giciels, textes officiels et
réglementaires, notices etc. |
InfoPath, qui sera utilisable
séparément ou inclus dans Microsoft Office 2003 pour
entreprises, peut transcrire en XML des informations natives
en Word etc. Et notamment assurer la présentation en XML
du contenu de formulaires électroniques pour leur utilisation
dans le cadre de Services Web. Deux exemples en cours de
développement :
-
UNeDocs de la
CEE-Onu,
à laquelle est ratta-ché le Cefact, vise à
procurer aux PME un moyen plus économique que l'EDI ou ebXML
pour passer au sans papier dans le trade. Un document
XML UNeDocs, par exemple commande, déclaration en
douanes, document d'expédition FIATA etc. pourra ainsi,
d'abord être rempli (en ligne ou non) en uti-lisant les
listes de codes UN, ensuite vérifié, signé (par le
Service Web de US Postal Service et Canada Post), soumis aux
Douanes etc. Le tout en utilisant des Services Web. Les
responsables d'UNeDocs, envisagent de recourir aussi à Adobe
PDF, en plus d'InfoPath.
- ACORD, association des
assureurs US qui en standardise notamment les formulaires et est
membre de WS-I, annonce également l'utilisation d'InfoPath et
XML pour relier, par des Services Web, des formulaires
d'assurance remplis à d'autres formulaires, bases de
données et autres applications. Les données des
formulaires remplis avec Infopath peuvent aussi être
réutilisées en Word, imprimées, faxées etc.
ACORD utilisera aussi d'autres produits comme Web Edits de Hartford
ou Mediator et Tamino de Software AG.
InfoPath est à la
mode, car construit sur XML et assurant la liaison avec
des Services Web, il facilite donc l'intégration des
données dans les processus d'affaires, permettant aux
utilisateurs d'agir direc-tement sur le traitement de
l'information, sur le mode WYSIWYG (What You See Is What You
Get). InfoPath est basé
(VendrEDI
n° 60) sur le schéma XSD du W3C et sur une gamme de
formulaires courants. L'adaptation d'un de ces formulaires est
facile, InfoPath créant alors automatiquement un nouveau
schéma qui pourra lui-même être ensuite
modifié. De même InfoPath permet de dessiner des
formulaires à partir d'un schéma XSD existant en dehors
de lui.
Alliant visibilité pour l'homme et
automaticité de liaison aux processus métiers, la
promesse initiale de XML, InfoPath semble être l'outil
dont avaient be-soin les
PME ![]() |
Ce numéro 64 de VendrEDI a été adressé à 1105 abonnés Pour écrire |
Tous les numéros de VendrEDI peuvent être téléchargés zippés à http://www.actimum.com/acvendredi.htm |