Bonjour,
 
Ci-dessous VendrEDI n° 96.
 
Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Et bonnes vacances aux "juillettistes" !
 
Cordialement
 
Claude Chiaramonti
 
 
 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
           Numéro 96     24 juin 2005
    XML lingua franca :
   Moderniser l'EDI,    
      pourrait encore mieux faire !
mais par des voies progressives
Issu de SGML, comme HTML, XML a été accueilli avec scepticisme en 1998, mais a vite été décrété "lingua franca" des échanges électroniques de docu-ments et de données. La plupart des anglo-américains qui emploient volontiers cette expression ignorent que "lingua franca" signifiait "langage sommaire des marchands Francs" (français) dans les ports de Méditerrannée..
Mais même consacré, le métalangage XML peut-il encore s'améliorer ? Le succès même de XML a suscité des recherches d'améliorations qui ont reçu des réponses mitigées, discutées, mais qui laissent la place à des améliorations à venir :
- les bases de données en XML "natif" ne semblent utiles que pour quelques cas particuliers.
- un XML "binaire" étudié par le W3C, (par exemple en ASN1 cf. VendrEDI n°81) serait moins verbeux, surtout pour l'EDI, avec des balises compressées. Et selon le W3C, cela ne devrait pas aboutir à des versions de XML incompatibles.
- tous les fournisseurs, Microsoft en tête, ont leurs outils basés sur le langage de schéma XML officiel du W3C, le WXS (W3C XML Schema Definition Language), destiné à remplacer les DTD. Mais bien que présentée clairement, la recommandation du WXS a paru compliquée et l'ISO a proposé le langage DSDL (cf. VendrEDI n°87), qui isole les fonctions du schéma avec, pour chacune, un standard simple. Et la gamme d'outils de XML permet des passerelles entre tous ces schémas.
- chaque balise XML peut contenir un namespace, une "ressource" sur le Web ou l'on peut trouver la définition de la balise. Reste à mieux organiser les namespaces en ontologies, qui relient les définitions entre elles. Mais les langages de ces liaisons logiques, RDF et OWL, font l'objet de scepticisme.
- faut-il modéliser XML avec UML ? Pourquoi pas, notamment pour générer des schémas XML et réutiliser des définitions existantes.
- enfin, XML étant une  syntaxe sans sémantique, alors qu'Edifact offrait les deux, les langages-métiers XML autonomes ont fleuri : bonne manière de coller au terrain ou risque de Tour de Babel ?
Pour suivre l'évolution de ces questions, comme celle de XML en général, voir XMLfr, le site francophone animé par Eric van der Vlist.
 
Le B2B est toujours, pour l'essentiel, en EDI très  classique, suivant la norme Edifact, ou même des standards antérieurs. On ne change pas un système que l'on a mis du temps à bien faire marcher ! Mais l'irrésistible ascension de XML dans toutes les autres fonctions du SI finira sans doute par se tra-duire aussi dans un EDI en XML. Simplement, la modernisation de l'EDI continuera à être lente, et empruntera des voies très progressives.
On peut rappeller le Web EDI, qui est d'ailleurs né avant XML dans la grande distribution, puis l'auto-mobile, et est adapté pour des transactions avec des fournisseurs occasionnels ne souhaitant pas un EDI automatisé rentable surtout pour grands donneurs d'ordres et fournisseurs réguliers.
On peut garder son EDI en Edifact, mais sans RVA onéreux, remplacé par un des  protocoles sécurisés EDIINT (EDI sur Internet), AS1, AS2 ou AS3, qui ont des fonctionnalités complémentaires.
La simple traduction "à la volée" des messages Edifact en XML (et l'inverse) est aussi une moder-nisation, ne serait-ce que pour permettre à des nouveaux venus dans une communauté EDI d'éviter Edifact s'ils pratiquent déjà XML. D'ailleurs toutes les plates-formes EDI sont depuis longtemps multi-formats, depuis les formats de l'EDI classique jusqu'à XML et à ses langages-métiers.
On peut, de plus, migrer d'un Edifact "rigide" vers un langage-métier XML existant, en pouvant l'adapter à son business avec ses partenaires, XML étant un métalangage "eXtensible". Mais sans avoir besoin d'un "traducteur" ni de  spécialistes en Edifact, Windows ou Linux, de même que les développeurs "parlant" déjà XML.
Modernisation d'avenir, ne pas se contenter du seul format des messages, mais passer aux  Services Web (SW), outils XML du Web, grâce auxquels des services "découverts" sur le Web peuvent être stabi-lisés et automatisés en EDI. EDI qui n'est plus isolé puisque les SW sont aussi l'outil de la SOA interne.
C'est avec la souplesse des outils des SW, SOAP, WSDL, UDDI, et en particulier BPEL, que l'EDI peut se mettre en scène avec des scénarios et une choreography moderne. Et reconnus par les ERP, les SW seront plus "agiles" que les frameworks RosettaNet, ebXML etc.
 
Pour que "le message passe" il faut être d'accord sur le sens des données   Petit Glossaire du B2Bfr

    BPEL + WS-CDL :
 
 SW automatisés : 
   orchestration + chorégraphie
 
vers l'ontologie des services
Les échanges électroniques de données, sous forme de Services Web (SW), sont au coeur de la SOA (Service Oriented Architecture) en interne et  de l'entreprise étendue à ses partenaires habituels en externe. Il peut s'agir de messages SOAP isolés déclenchés par les applications. Mais, dans le cadre d'un business process (BP) et en collant à chacune de ses étapes, il peut s'agir d'un enchaînement, d'une "orchestration" de messages et des suites données pour une application. Les "partitions",  pour une application, peuvent être établies avec le standard BPEL (Web Services Business Process Execution Language) du consortium d'offreurs Oasis, auquel il a été présenté sous le nom de BPEL4WS par Microsoft, IBM, BEA, SAP et Siebel. Mais comme il faut être au moins deux pour un BP, il faut être sûr de ne pas se marcher sur les pieds en "dansant" : le W3C propose donc WS-CDL (Web Services Choreography Description Language), peer to peer, qui complète des BPEL en les aidant
à danser ensemble. C'était le rôle de l'interchange agreement de l'EDI classique que WS-CDL permet de formaliser et de réutiliser sans avoir besoin de s'abonner à un produit comme RosettaNet.
Toutes les étapes à définir pour la satisfaction d'un BP, une commande entre un donneur d'ordres et un fournisseur, sont détaillées dans une illustration avec les "orchestrations" propres à chaque entreprise et la "chorégraphie" définie en commun. Pour le moment, c'est le plus souvent BPEL qui est utilisé seul par les deux "danseurs". D'ailleurs, pour certains, la distinction entre orchestration et chorégraphie apparaît purement académique. Voir une illustration de cette utilisation de BPEL dans le tourisme pour toutes les opérations de "service" liées à la recherche d'un hôtel près d'un aéroport et à la réservation d'une chambre en utilisant le langage XML OTA du secteur.
Exemple, en cours d'implémentation de l'utilisation de BPEL à grande échelle, dans le secteur santé aux USA, avec le programme fédéral State Children's Health Insurance Programs (Schip) qui a pu s'adapter aux particularités de chaque Etat avec autant de BPEL combinant des étapes "application à application" et des interventions humaines de vérification et confirmation.
Voir le  BPEL Learning Guide qui rassemble défi-nitions et descriptions des outils des offreurs : mieux vaut apprendre à danser pour ne pas faire tapisserie quand l'orchestre des SW se mettra à jouer pour de bon !
 
Il y a deux niveaux distincts de sémantique pour un SW (Service Web ou Web Service), le niveau du "métier" et  le niveau "service". WSDL est un outil ambitieux de description d'un SW  au niveau du  "métier". Il peut rester sectoriel ou fonctionnel pour coller au terrain et est donc orienté human. La sémantique de description du "service", y compris les actions qui sont demandées et/ou offertes par un SW est orientée machine, au contraire, pour que le SW entre les applications puisse être automatisé.
Même problématique pour le Semantic Web du W3C qui vise aussi à ce que les exponentielles pages Web, ingérables même par Google (qui ne trie que des caractères sans leur signification, réservée à l'human), puissent avoir un "sens" perçu machine. En passant ainsi d'un Web "document" à un Web "données". D'où la convergence entre Semantic Web et sémantique des services du web (SW) : pour certains il ne s'agit que d'une addition d'utopies à la recherche de problèmes à résoudre, pour d'autres, dont le W3C, c'est au contraire une synergie très prometteuse puisque les SW seraient ainsi un outil du Semantic Web. Et la sémantique et ses outils de base, RDF et OWL, sont aussi intéressants pour le business, sans parler du knowledge management. D'ailleurs, les plus grands comme IBM ont une offre semantics.
Parmi les standards de l'e-sémantique, OWL-S était un premier essai d'ontologie des SW, permettant aux applications d'avoir un langage commun pour que la définition et "l'invocation" d'un service soient compréhensibles par toutes les plates-formes. Dans ce but, la modélisation étant  incontournable, il fallait une spécification pour modéliser les SW et leur on-tologie : cinq institutions et entreprises européennes (dont BT et SAP) viennent de faire une proposition en ce sens au W3C, intitulée WSMO (Web Services Modeling Ontology). Qui prend place à côté d'autres travaux.
Certes, WSMO est plutôt destiné aux développeurs de SW, mais les responsables de business devraient quand même se familiariser avec sa présentation, toute illustrée par un exemple de réservation de billet. Ne serait-ce que pour être capable de bien collaborer avec les informaticiens pour le niveau sémantique des SW.
Cela en interne, pour assouplir l'EAI, comme en externe, pour moderniser l'EDI. Ce pourrait faire de WSMO l'outil de modélisation de tous les
échanges électroniques de données de la SOA et de l'entreprise étendue.
Ce numéro 96 de VendrEDI a été adressé à 2035 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés à  http://www.actimum.com/acvendredi.htm