| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 85 29 octobre 2004 | ||||
|
Traçabilité en EDI
|
Patchwork WS-* :
|
|
|
avec les
outils d'Influe
|
WS se lit encore Wait and See !
|
|
La gamme de produits d'Influe (déjà
évoquée dans le VendrEDI n° 57) lui permet notamment
d'être en mesure de proposer aux industriels,
transporteurs et distributeurs de se mettre en conformité
avec le règlement européen sur la sécurité des
produits alimentaires qui entre en vigueur le 1er janvier
2005. Ce règlement impose aux acteurs de la filière
agro-alimentaire de pouvoir retracer le cheminement de leurs
produits (production, transport, distribution) pour
d'éventuels retraits précisément ciblés.
Ce qui impose d'identifier dès le
départ les produits et leurs conditionnements et de
reporter ces identi-fiants dans le flux d'informations
accompagnant le flux des produits. Les outils
d'Influe assurent cette traçabilité
amont-aval et utilisent pour la filière
industrie-commerce les différents standards du système
international EAN-UCC : standards d'iden-tification des produits,
des lieux et des objets gérés par
la logistique, standards divers d'échanges
d'in-formations inter-entreprises.
Pour les grands opérateurs, la
plate-forme d'échan-ges inter-entreprises SynchroLink, qui
peut être utilisée sous forme de progiciel ou en
hébergement chez Influe, permet l'échange des
informations conformément aux standards de
traçabilité du système EAN-UCC :
numéros uniques séquentiels de colis (SSCC),
étiquettes logistiques EAN 128, message Edifact DESADV d'avis
d'expédition. Le numéro SSCC est ainsi intégré
au message DESADV et reporté sur l'étiquette EAN 128 ce
qui assure l'interopérabilité entre flux d'informations
et flux de produits.
Pour les flux moins importants, Influe propose
aux entreprises sa solution Web EDI, E.D.I.One, qui
répond aux prescriptions de Gencod EAN France et est
implantée chez plus de 1000 fournisseurs. E.D.I.One
reçoit les commandes des distributeurs et permet aux
fournisseurs d'émettre sans ressaisie le
message EDI DESADV. La génération
automa-tique des numéros de SSCC, ainsi que l'impression
des étiquettes de colisage, font partie des
fonction-nalités standards de E.D.I.One.
Si Influe pratique XML et les Services
Web, l'EDI classique en Edifact lui permet aussi de
répondre aux besoins d'aujourd'hui. Et pour les
utilisateurs, if it works, don't fix it...
|
La série quasi-innombrable des WS-*,
standards relatifs aux Services Web (SW), ne se simplifie pas.
Depuis la liste du VendrEDI n°77 sont ainsi apparus
notamment
WS-Enumeration,
WS-Transfer et
WS-management. L'utilité de tous
ces standards n'est pas contestée : c'est leur mise en oeuvre
combinée qui n'est pas évidente. De ce point de vue, par
contre, des progrès :
Sun a rejoint WS-Adressing et propose avec
Microsoft une
interopérabilité de
leurs produits pour WS-Security.
Pédagogies utiles : voir une
analyse de pas moins de 15
WS-* (ou produits) pour le BPM, Business Process
Modelling, point de départ souhaitable de SW
complexes. De même, CBDi analyse dans une roadmap la
série des WS-* et Orchestra Networks publie
une
synthèse des WS-* en français.
Quant à Microsoft, il s'efforce
aussi de faire oeuvre pédagogique avec des exposés clairs
(en anglais) qui, certes, mettent ses produits en avant, mais
constituent aussi une référence pour dépasser
le hype ambiant (je ne dis plus b. car un
firewall pudibond a rejeté le n° de VendrEDI
dans lequel j'avais osé employer ce mot). Après un
article de juillet sur la SOA (cf VendrEDI n°82), la
Library MSDN de Microsoft propose ainsi un
article sur l'architecture des
WS-* qui en décline le rôle.
Mais à côté de la
pédagogie, la critique d'une "WS-Opposition" monte aussi. Il
reste des doubles emplois, par exemple IBM maintient son
WS-Notification malgré la
reconnaissance de WS-Eventing, et le W3C publie une
nouvelle version de WS-CDL alors que BPEL d'Oasis s'impose et
pourrait peut-être suffire pour la choreography d'un
Business Process.
De même que XML devait tout simplifier et
a abouti à un schéma XSD très complexe, les SW
aboutissent à un patchwork de standards WS-* rebutant. On
ne peut que répéter que les SW ne se développeront
que lorsque leurs standards seront accompagnés d'une
notice claire, pour les monter en kit plus ou moins complexes
suivant le profile dont on a
besoin. Comme
Devices Profile de
Microsoft pour des SW de base, ou
les profiles
proposés par tous les offreurs au sein du WS-I. En
attendant, on en restera à l'EDI : WS-* se lit
encore Wait and See ! |
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
Fédérer les
identités
|
|
Langages XML :
|
|
pour savoir qui peut
faire quoi
|
|
les pionniers EDI en retard !
|
|
Quand on retire des billets à
l'étranger dans un DAB, on met en oeuvre un système
international de fédération des identités
des cartes bancaires, où chaque banque accepte les
identités délivrées par les autres. Avec
la mondialisation de l'e-business et des Services Web, de
telles "fédérations" deviennent indispensables si on veut
mettre en oeuvre des systèmes ouverts, sans conventions
face to face du type convention d'interchange EDI, mais
avec le même degré de confiance "entre ordinateurs".
Cela suppose, par définition, des standards solides et
acceptés par tous. Ce qui devient aujourd'hui le cas.
Si
SAML (Security Assertion Markup Language)
d'Oasis, socle de départ, n'était pas
contesté, il a néanmoins fait l'objet de
développements parallèles :
- d'une part
ID-WSF (et ID-FF) de Liberty
Alliance, consortium lancé par Sun et comprenant
presque tout le gratin des TIC (sauf Microsoft ou BEA) et
avec France Télécom, l'ADAE ou l'US
DoD ;
- d'autre part
WS-Federation avec Microsoft et
BEA plus Verisign, RSA Security et IBM (qui sont aussi à
Liberty Alliance), qui semble plus centré sur les
Services Web avec référence à
WS-Security.
La "fédération" ne pouvant
qu'être globale, Microsoft et Sun ont alors fini par faire de
l'interopérabilité de leurs outils en la matière
("solve single sign-on" and facilitate interoperability between
the LDAP model of the directory and identity management products in
Sun's Java Enterprise System and Microsoft Active
Directory") la première
étape (
Phase One) de leur
récent accord décennal de collaboration. De même,
IBM vient de rejoindre Liberty Alliance pour son accord avec France
Télécom Orange, qui, comme AOL et autres, a un
impérieux besoin de global federation des
identités pour ses abonnés.
On va donc vers
une "confédération" qui devra garantir une confiance
"automatisée" en ce qui concerne les législations
(privacy etc.) et les droits de chaque intervenant
(personne ou application) d'une même entreprise d'un pays
à l'autre.
Car confédérer les identités
d'intervenant ne résout pas tout : encore faut-il bien savoir
quels sont les pouvoirs de chacun. Si SAML résout ainsi les
"simples" (oui ou non) authentication and authori-zation
assertions, c'est le rôle de
XACML qui est,
à Oasis, un
prolongement de SAML, de préciser ces
"assertions simples" et les règles qui sont
sous-jacentes. Rassemblées en une XACML policy,
ces règles permettent de savoir qui (individu ou
application) est autorisé à se connecter pour faire quoi.
Première des sécurités !
|
Comme d'habitude, "les premiers seront les
derniers" ! D'un côté, on a les
Communautés bien établies de l'EDI, qui s'en
tiennent à leurs échanges en Edifact, et ne sont pas
persuadées de l'intérêt de migrer vers XML ; et
rares sont les traductions en XML de messages Edifact,
les partenaires occa-sionnels ou nouveaux étant
plutôt associés par un Web EDI plus léger qu'Edifact
ou XML.
D'un autre côté, on a des domaines
nouveaux qui expriment d'emblée leurs langages
métiers en XML pour leurs échanges
électroniques. En dehors de la supply chain et
de la logistique, où l'EDI classique s'est surtout
développé, on peut ainsi citer, dans un
désordre très XML : MathML
maths,
AdsML pub, CAP
alertes,
PIDX pétrole, FpML,
FIX, RIXML et IFX sur différents aspects de la finance,
MatML matériels, XCBF biométrie, GML géo, OTA
touris-me, Timed Text et SMIL multimedia, InkML manuscrits, XBRL
entreprises, AgMES agriculture, SDMX stats,
LegalXML, GJXDM et autres, justice, HR-XML, ressources humaines,
GMSL génome, SportsML sports, Acord
assurances, VoiceXML et SSML reconnaissance vocale, et bien d'autres
en cours de mise au point, par exemple dans les nombreux
comités d'Oasis. Il y a aussi des "sous-langages", comme
mpXML, adaptant à la volaille les
standards EAN-UCC. Les langages métiers sont XMLisés
avec des statuts différents, de l'open standard
au standard payant ou au "produit propriétaire" imposé
par un grand donneur d'ordre (comme l'étaient souvent les
"subsets propriétaires" des messages Edifact).
Certains de ces langages, purement US,
ne seront jamais implémentés que de manière
très confiden-tielle, mais peuvent n'avoir jamais eu d'autre
ambition ! Car la souplesse de XML permet de se mettre d'accord
assez facilement, sans que cela soit une affaire d'Etat
nécessitant l'accord de la terre entière comme dans
Edifact, ou ebXML s'il est finalisé. Souplesse voulue par Tim
Bray, un des in-venteurs du métalangage XML : "make it as
easy as possible for people to come up with their special languages
for their specific problems".
Ce qui n'interdira pas aux
Communautés EDI de réutiliser un jour dans un
"special language" leur subset Edifact, au besoin
élargi. A cet effet, la réunion des Core
Components ebXML peut être une aide de type documentaire.
Mais sans aucune prétention inutile, ni universelle ni
normalisa
trice : pour
des échanges d'un domaine à l'autre, les outils de
traduction (mapping) sont maintenant d'un usage trivial, paraît-il ! |
| Ce numéro 85 de VendrEDI a été adressé à 1354 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |