Bonjour,
 
Ci-dessous VendrEDI n° 80. Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
A découvrir, la nouvelle version du site francophone ServicesWeb.org qui a pour but de réunir et d'organiser des informations et des ressources autour des Services Web : 
http://www.servicesweb.org/
 
Cordialement
 
Claude Chiaramonti
 

 
 
   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 XML, encore faut-il un outil permettant de décrire et lire cette sémantique accessible à  tous grâce aux URI de namespaces.
 
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 temps de l'EDI, il faudra bien se mettre autour d'une table avant de lancer du applica-tion to application automatisé.
 
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