Bonjour,
 
Ci-dessous VendrEDI n° 99. Comme d'habitude, me signaler par retour de courrier votre souhait de ne plus recevoir VendrEDI.
 
Voir un très pédagogique article d'Eric van der Vlist sur les namespaces : http://xmlfr.org/documentations/tutoriels/050912-0001
NB Je m'en tiens à namespace tant que l'on n'aura pas trouvé un équivalent en français : "espace de noms" n'étant, à mon avis, qu'une traduction mot à mot scolaire, et non pas un équivalent. Il y a bien "espace de nommage" qui est un peu mieux, mais pas vraiment joli ! Mais je vais peut-être adopter "espace nominatif", proposé notamment par la SRCI...
 
Par ailleurs des sociétés spécialisées en EDI, dématérialisation etc. signalent leurs produits :
 
    - Voir les produits de Prologue e-Process pour les échanges de données inter-entreprises, les téléprocédures administratives ou les échanges spécifiques du secteur santé-social à  http://www.eprocess.prologue.fr
 
    - Voir les produits de la SRCI pour les fiches produits et le B2A (dématérialisation de formulaires, comptabilité publique et contrôle de légalité) à  http://www.srci.fr/
 
Cordialement
 
Claude Chiaramonti
 
 
 
 
   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 encryptionXML 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 sera 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