VendrEDI | ![]() |
lettre de Claude Chiaramonti | ||
sur les
données de l'échange électronique |
||||
Numéro 80 18 juin 2004 |
RDDL pour du sens
|
Cefact au "boulot" :
|
|
dans les URI de namespaces
|
retour au business et au trade
|
L'idée d'utiliser des URI pour les
namespaces était fruste, à l'origine : il
s'agissait simplement de distin-guer, grâce à des URI
différents, deux balises de même libellé
coexistant dans le même schéma ou, à
l'inverse, d'être certain que, dans deux schémas
différents, des balises se réfèrent bien au
même concept puisqu'elles ont le même URI. Mais cette
URI pour une "balise x" n'était souvent qu'une URL vide
du type "xmlns= http://www.balise-x", soit une adresse
fictive (d'où l'erreur 404 Not Found quand
on cliquait sur une telle URL vide) qui ne pointait donc pas sur un
contenu réel, par exemple donnant des informations sur la
signification sémantique de la "balise x" en
question.
Pour "donner du sens" à ce mécanisme
fruste, dès 2001, le langage RDDL, Resource Directory
Des-cription Language, a été proposé,
pour que le mécanisme des URI de namespaces soit
porteur d'informations sur les balises identifiées, grâce
à un langage lisible aussi bien par l'homme que par une
application. L'URL doit alors pointer non pas simplement sur
une page Web ou un schéma XML, mais sur un directory of
resources. Basé sur XHTML, donc accessible par les
navigateurs, le langage RDDL permet d'avoir accès, sous un
même namespace, aux définitions diverses
d'un domaine de business. Par exemple le
namespace réalisé par Eric van der Vlist pour
les données de base de l'INSEE (cf VendrEDI n°75).
La version
2.0 de RDDL a été publiée pour
discus-sion au début de l'année avec comme objectif de
simplifier encore le langage. Mais Eric van der Vlist, grand
promoteur de RDDL, observe dans son
Weblog que cette simplification réduit en fait
l'intérêt de cette version par rapport à la
précédente. Plus simple oui, mais pas simpliste ! Il est
donc souhaitable qu'un consensus se dégage pour un RDDL qui
puisse répondre aux attentes : s'il semble impossible de
corseter l'usage de XML, encore peut-on essayer de le rendre
"lisible". C'est à dire que si une démarche top
down du type ebXML ne paraît pas réaliste
pour enregistrer quelque part toute la sémantique des
balises des schémas
![]() |
La dissolution du CSG (Cefact String
Group), créé en 1996, marque la fin d'une
époque. Le CSG restera associé au lancement d'ebXML, puis
du BCF, et de l'association controversée de Microsoft à
la standardisation de l'e-business à l'Onu. Avec trop
d'accent mis sur la technique aux dépens de la facilitation du
commerce international, terreau d'ori-gine d'Edifact.
Nouvelles structure et équipe diri-geante du Cefact souhaitent
donc rééquilibrer les travaux du Forum vers le niveau
business, à savoir vocabulaires et processus
métiers, en liaison avec la trade facilitation et les
enjeux de l'OMC.
La plénière du Cefact a alors
demandé que les spé-cifications des Core
Components (CC) et Business Process (BP) ebXML, dont
le Cefact avait la char-ge, soient présentées au TC
154 de l'ISO, comme Oasis l'a fait pour les six
spécifications techniques dont il avait la
responsabilité. En vérifiant que l'ap-proche n'avait pas
été trop technicienne et que les besoins de
business des divers acteurs avaient bien
été pris en compte, en particulier pour les BP.
Donc le maintien de l'investissement du Cefact
dans le niveau business d'ebXML est confirmé. On peut
penser que le représentant de Microsoft, s'il reste
liaison rapporteur du Cefact avec les instances de
standardisation, s'attachera à ce que le pont entre les
Services Web et ebXML que représente le BCF reste bien la clef
de voûte de l'édifice.
L'intérêt du Cefact serait en
effet de veiller à ce que le niveau business
d'ebXML puisse être utilisé par les Services Web. Mais
peut-être faudrait-il pour cela que les "spécs" CC
et BP ebXML fassent appel aux mêmes outils qui servent
déjà à décrire le niveau business des
Services Web au lieu de se contenter d'Excel pour les CC !
Autrement dit que le Cefact-Onu se concentre bien sur le
business, où se trouve sa légitimité,
puisqu'il associe les utilisa-teurs privés et publics pour
faire face aux offreurs. Cela en utilisant ses
outils de modélisation du type UMM, pour permettre une
description systématique et cohérente du
business et de la facilitation du commerce. L'objectif
étant de coordonner les visions e-business et
trade facilitation, en parti-culier pour permettre aux
entreprises de rejoindre les grandes supply chains
internationales et ainsi améliorer leur efficacité.
|
![]() |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
WSDL et UDDI
v3 :
|
De Rest à la SOA
:
|
|
vers une "découverte"
prudente
|
|
des Services Web
progressifs
|
Le discovery est le maillon faible
des Services Web (SW), comme de ebXML, avec de nouveaux
parte-naires inconnus. Si l'on ne voit pas encore de
registres de CPP-CPA ebXML, il y a beaucoup de
registres UDDI (Universal Description,
Discove-ry & Integration) pour les SW.
Mais si on utilise UDDI comme un registre de SW à
l'intérieur d'une entreprise ou entre partenaires habituels,
on ne peut encore parler de discovery puisqu'on est
déjà en terrain bien connu. Selon la Web Services Archi-tecture du
W3C, le discovery est en effet : "the act of locating
a machine-processable descrip-tion of a Web service that may have
been previously unknown and that meets certain functional
criteria". Qu'il s'agisse d'une découverte humaine ou
d'une discovery "entre applications", il faut
dans tous les cas, puisque le SW recherché peut être
inconnu, que le registre qui le localise et le
décrive comporte bien toutes les informations
nécessaires pour une mise en oeuvre confiante. Et de fait, en
plus du basique "qui assure tel SW et comment ?",
les registres UDDI peuvent comporter de nombreuses
informations permettant de décou-vrir, et ensuite aussi
"suivre" la fourniture d'un SW. Voir la spécification de
UDDI v3, très complète et comportant
de nombreuses fonction-nalités comme les relations entre
registres et les clés identifiant un service
(cf VendrEDI n°59), ou la signature
électronique des offreurs de services pour authentifier
ainsi leur catalogue. Voir une note résumée dont les
éditeurs sont de Microsoft et Sun ;-) sur la UDDI Version 3 Features List.
De plus, une
note
technique d'Oasis montre ce que l'on peut
attendre d'une utilisation de WSDL (qui décrit un SW)
dans un registre UDDI : par exemple, la qualité ou
le versioning d'un SW donnant aux offreurs de SW
l'assurance que UDDI sera bien à même d'exposer
toute la spécificité et l'évolution de leurs
prestations. D'autres notes techniques pour-raient, par exemple,
proposer l'enregistrement des access permissions à
chaque SW, car c'est bien la question de la sécurité qui
sera déterminante pour que les
entreprises développent des SW pouvant être
"exposés" et "découverts" par tous.
Mais si on imagine bien la
"découverte" de SW basiques, cours de Bourse ou
catalogues de produits à jour, la discovery
de SW complexes d'e-business ne paraît pas
encore proche : comme au tem
![]() |
Le modèle est connu : toute nouvelle
technologie suscite d'abord un enthousiasme délirant, puis une
déception profonde et finit quand même par un pla-teau
d'implantations réelles, lentement progressives. Plus une
tendance à rationaliser, donc complexifier, ce qui
était simple dans l'idée de départ ! Cela a
été le cas pour XML avec les schémas, cela le
devient pour les Services Web (SW). Les premiers
déve-loppements de SW ont été
développés en REST sans trop d'incidence sur les
applications. Puis est venue l'intérêt de se
référer à SOAP et WSDL (impactant les "applis")
lorsqu'un nombre suffisant de parte-naires pouvaient les pratiquer.
Voir Eric van der Vlist pour le choix
entre REST et SOAP.
Un appel par SW isolé à une
application externe ne nécessite pas forcément de SOA
(Services Orien-ted Architecture) : par exemple un
voyagiste ou un transporteur transférant, à
l'occasion, sur un pri-cing et une souscription
d'assurance fournie par un assureur-partenaire. Dans ce cas,
les informations sur le transport à assurer seront
envoyées par message sur le site de l'assureur pour qu'il n'y
ait pas besoin de les ressaisir, et en retour l'application
intégrera les références du paiement
de l'assurance conclue. Sans SOA. Mais si ce SW n'est
plus isolé et que l'application coeur de métier doit en
gérer systématiquement plusieurs, la question du passage
à une architecture basée sur les services appelés se
pose. Etant entendu, que refonder son SI sur une approche SOA
doit conduire à la business agility avec
comme mots-clés loose coupling, coarse
granularity et asynchrony selon un
Livre Blanc sur la SOA
Implementation Framework.
Et implanter une SOA sera d'autant plus
efficace qu'elle permettra alors, non seulement de gérer
l'appel à des services externes, mais aussi de rationaliser
les relations entre applications internes rendues ainsi
plus indépendantes et modulaires. La SOA devant alors
être souple et ne fournir que les fonctionnalités utiles
: la validation de chaque mes-sage, coûteuse, peut
être évitée pour des services basiques sûrs, de
même que le cryptage etc.
Si la plupart des grands offreurs se
positionnent déjà, (cf VendrEDI n°75) ce n'est que dans
quel-ques années que la SOA commencera à vraiment se
répandre. Mais de même que l'on affirmait il y a 20 ans
"EDI or die", on entend dire aujourd'hui que la SOA sera la
condition de maîtrise de son SI par les entreprises
qui seront de plus en plus obligées, soit de faire appel
à des services gérés par des sites partenaires, soit
d'offrir les leurs.
|
Ce numéro 80 de VendrEDI a été adressé à 1305 abonnés Pour écrire |
Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |