| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 99 23 septembre 2005 | ||||
|
Sécurité sans
RVA
|
RDF+ebXML CCTS
|
|
|
avec WS-Security et la
suite
|
pour le mapping en e-business
|
|
Pour Gartner, jusqu'à 65% des nouveaux
projets des très grandes entreprises (les Global 2000) vont
utiliser WS-Security d'ici 2010. Gartner recomman-de donc de se
familiariser dès maintenant avec ce standard de
sécurité qui répond à l'attente des
utilisateurs potentiels des Services Web (SW) et a
été ratifié par un
comité d'Oasis. WS-Security doit assurer
l'interopérabilité entre divers standards concourrant
à la sécurisation des échanges entre applications
through message integrity, message confidentiality, and single
message authentica-tion. Les grands offreurs, de Sun à
IBM, Oracle ou Microsoft, de même que des spécialistes,
VeriSign, Systinet etc. ont participé à une
démo de l'inter-opérabilité de leurs outils
utilisant WS-Security.
Si, pour un simple
SW point-to-point, on peut se contenter
de SSL (Secure Sockets Layer), il vaut
mieux recourir à WS-Security pour que les SOAP
headers puissent emmener XML
encryption, XML digital signatures, et
divers profils de sécurité comme Security Assertion
Markup Language (
SAML), X.509 ou Kerberos. De
plus, pour pouvoir automatiser un accord de
sécurité, WS-Security doit être complété
par WS-Federation, WS-Trust ou WS-SecurityPolicy que Microsoft et
IBM vont très bientôt présenter à Oasis. Assembler le tout
n'est pas forcément très simple, mais Gartner
prévoit que les offreurs présenteront bientôt
un produit qui englobera sécurité et gestion des
SW.
L'offre de sécurité pour que les SW
puissent bien se passer des RVA est donc en train de
s'harmoniser, par exemple au WS-I dans le prolongement de son
WS-I Basic Security Profile. Mais la
fédération et la gestion des identités : "qui,
individu ou application, est autorisé à faire quoi" est
encore un problème. Si tout le monde fait bien
référence à WS-Security, sa mise en oeuvre avec ou
sans SAML et
XACML n'est pas tout à fait
réglée : il y a d'un côté Sun
et le consortium Liberty
Alliance et de l'autre Microsoft. (cf. VendrEDI n°98).
En tout cas, Microsoft et IBM, avec RSA
Security, Verisign etc. proposent trois standards de
sécurité complémentaires de
WS-Security pour se passer de RVA :
WS-SecurityPolicy pour
préciser la sécurité attendue,
WS-Trust , jetons de
sécurité ou encore
WS-SecureConversation , suite
de messages.
|
Disposer d'un outil de traitement
automatisé de la sémantique est un
objectif essentiel, aussi bien pour maîtriser
l'explosion des "ressources" du Web que pour la gestion des
connaissances (KM) ou pour le niveau sémantique
de l'e-business. Le W3C a RDF (élargi avec OWL) pour le Semantic Web, et l'ISO
a TopicMaps pour le KM (à noter
que le W3C a publié une enquête sur les différentes
propositions faites pour assurer l'interopérabilité de
RDF et Topic Maps). Le e-business, lui, s'en
tient, dans le monde Cefact-Onu et ISO, à la
spécification des Core Components (ebXML CCTS) qui ne
peut fournir que des registres de données "à
plat", avec seulement la possibilité d'une hiérarchie
simple. Ces registres "à plat" sont utiles, certes, ne
serait-ce que pour les développeurs qui peuvent
réutiliser des données existantes. Mais ils sont
insuffisants pour le mapping entre sémantiques bien
établies de communautés voisines souhaitant automatiser
des échanges électroniques (cf. VendrEDI n°76). C'est ce que recherche le
Department of Defense US avec le projet
Core Taxonomy : son but est
d'aider deux COI (Community
Of Interest, du type Communauté EDI)
à rendre visibles l'une à l'autre leurs sémantiques,
à modéliser leur mapping d'une sémantique
à l'autre, en passant, par XML, RDF et OWL,
à un niveau supérieur commun, celui d'une Core
Taxonomy. Mais alors l'objectif n'est pas
Universal comme dans UBL ou les Core
Components, mais limité à un besoin de
business concernant deux ou plusieurs communautés
avec possibilité d'extension (cf. VendrEDI n°73, n°93).
Et la synergie entre RDF/OWL et les
Core Com-ponents ebXML (cf. VendrEDI n°76) est possible :
- la collecte des définitions
"à plat" des Core Com-ponents par les groupes
sectoriels du Cefact-Onu peut être le materiau de
départ des graphes RDF et d'une ontologie OWL
;
- ces graphes RDF rendraient bien plus utiles
les registres sémantiques ebXML "à plat" puisque,
avec taxinomie et ontologie modélisatrice des
données, on pourrait "mapper" les graphes
sémantiques de deux ou plusieurs domaines
en affaires.Ce qui permettrait, de plus, une synergie
entre le concret de l'e-business et le
côté futuriste du Semantic Web et du KM.
|
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
Vieil EDI
"Sabré" :
|
|
Name and Address :
|
|
Sabre passe aux
Services Web
|
|
pas si simple à
normaliser !
|
|
Le plus souvent, jusqu'à présent,
les Services Web (SW) ne se sont développés que là
où l'EDI n'exis-tait guère et, corollaire, les
utilisateurs satisfaits de leur EDI ne voyaient que peu
d'intérêt à passer en SW. Un exemple
récent de passage de l'EDI classique aux SW :
Sabre va remplacer son système EDI vieux
de 15 ans par une plate-forme SW pour faciliter la
réservation coordonnée de places d'avion, de chambres
d'hôtel ou de voitures. Cette plate-forme est la
SeeBeyond Technology Corp.'s Integrated Composite
Application Network (ICAN) suite. A noter l'acquisition
de SeeBeyond par Sun. sabre prévoit également
d'utiliser les SW a titre interne pour passer d'un
mainframe à un système distribué. Pour
Sabre, les SW sont moins chers et bien plus souples que l'EDI
classique : "A B2B connection that used to take two months to
set up with EDI can be set up in a couple of hours with Web
Services". D'après le Burton Group d'autres migrations de
l'EDI vers les SW devraient être constatées prochainement
pour les mêmes raisons.
EDI US en CICA
:
pas de Services Web
envisagés
Comme les Communautés EDI
européennes utilisant Edifact, les communautés EDI aux
USA qui utilisent leur standard X12 sont confrontées à la
question de la migration en XML. Son comité de standardisation
intersectorielle, ASC X12, entend assurer
l'interopérabilité entre X12, XML et les formats
UN/Edifact, mais en s'appuyant sur sa solide expérience en
matière de messages et de langages-métier. ASC X12 assure
le secrétariat de DISA (Data Interchange Standards
Association), membre du W3C, qui entend préparer le
passage à XML, en donnant un coup de chapeau aux
spécifications ebXML, mais en suivant surtout sa CICA, Context Inspired Component
Architec-ture (cf. VendrEDI n°63). Le but de CICA est, en
effet, de protéger l'investissement EDI classique au niveau
métier et sémantique pour le réutiliser au sein de
schémas XML, y compris avec des industry
specific implementation guides. Mais à côté de
cette migration de la syntaxe X12 vers XML, les Services Web (SW)
ne sont pas mentionnés. D'où le danger, aux USA comme en
Europe, de
ne pas
conforter l'investissement réussi des contenus de l'EDI
classique avec les SW, outil d'avenir pour la mise en
oeuvre. |
Pour l'interopérabilité, le nom et
l'adresse postale sont une des bases : après les
échanges électroni-ques, il faut être sûr de
livrer sans erreur ! Après la meilleure articulation des
adresses électroniques, qui est recherchée par Oasis
avec les XRIs, eXtensible Resource Identifiers
(cf. VendrEDI n°73), qui est au niveau des
"contenants". Au niveau des "conte-nus", il y a d'abord, pour
toutes les données, les formats du Naming and Design, qui sont
plutôt très variés. Pour les données de
l'adressage, le TC 154 de l'ISO avait commencé par la
liste des instances s'en préoccupant : UPU, ISO/TC215,
ISO/IEC JTC1/SC32, UNECE UNeDocs, UN/CEFACT Forum TBG, ISO/TC154,
CEN/TC331, Oasis UBL, OAGI et le groupe d'Oasis
CIQ (Consumer Infor-mation Quality) qui
vient de proposer ses nouvelles spécifications.
Le CIQ propose ainsi xNAL (Extensible Name and Address
Language) se décomposant en xNL (Extensible Name
Language), xAL (Extensible Address
Language), xCIL (Extensible Customer Information
Language) et xCRL (Extensible Cus-tomer Relationships
Language).
Quand on sait que, non seulement les
adresses, mais aussi les noms (fils de...) et les
civilités varient suivant les langues et les cultures, on peut
se demander si l'effort de normalisation ne doit pas rester
très modeste : tout le courrier n'est pas distribué par
UPS ! Rien qu'en France, l'adresse géo-postale doit
encore faire l'objet de notes complexes pour vérifier que les
prescriptions de l'Afnor, de La Poste et des administrations sont
bien cohérentes avant de constituer une entrée dans les
Core Components ebXML. Et le nom et l'adresse ne sont pas
les données les plus complexes !
Le monde Edifact a passé plusieurs
années pour savoir si le "concept d'ayant droit" de la
sécurité sociale devait être codé au sein du
segment NAD (Name and Address) ou s'il fallait un segment
spécial. Les "puristes", en particulier les juristes
australiens, se refusaient à voir 2 segments traiter à
peu près de la même chose. Les réalistes, qui ont
fini par l'emporter, ont fait valoir que juristes australiens et
Sécu française n'échangeraient jamais de message et
qu'il n'y avait donc aucun incon-vénient, autre
qu'esthétique, à ce qu'ils aient chacun leur segment
d'adressage. A chacun son métier et son langage propre et
la sémantique ser
a bien gardée ! Eviter Babel ne se fera qu'en
"mappant" les langages des métiers qui doivent collaborer
ensemble. |
| Ce numéro 99 de VendrEDI a été adressé à 2013 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |