Bonjour,
 
Ci-dessous VendrEDI n° 62 pouvant être imprimé pour un meilleur confort de lecture (cocher pages 2 à 3).
 
Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Hervé Schauer Consultants, cabinet de conseil et d'expertise en sécurité, informe qu'il a publié les transparents de son support de cours "Fonctionnement des PKI" :   http://www.hsc.fr/ressources/cours/pki/  Ce cours est dispensé régulièrement et les prochaines sessions seront les 28 Juin à Toulouse et le 22 Septembre à Paris : http://www.hsc..fr/services/formations/pki.html.fr
 
La dernière version du Petit  Glossaire des échanges électroniques date d'un an et vieillit donc très vite. Un lecteur m'ayant proposé de collaborer à sa mise à jour, j'accepte bien volontiers cette offre aimable et indique à tous les destinataires de VendrEDI que leur aide sera également la bienvenue ! Me signaler les concepts, sigles, développements génériques etc. à définir, avec, si possible, sinon une proposition complète de définition, au moins des éléments ou une référence. Merci d'avance !
 
Cordialement
 
Claude Chiaramonti
 
 
 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
        Numéro 62       25 avril 2003
OAG admis au MoU :
 
SOA=EDI>XML>SW
  aussi bien  BizTalk qu' ebXML !
  une évolution inéluctable
Le consortium Open Applications Group, OAG Incorporated, a été fondé en 1995. Son but est de proposer des spécifications aux fournisseurs de software ou middleware pour qu'ils facilitent l'inter-opérabilité Plug and Play des produits. Cela aussi bien pour les ERP, la supply chain ou le CRM, que pour l'intégration interne. La devise d'OAG est ainsi : "Best Practices and XML Content for Everywhere-to-Everywhere Integration".
La dernière version 8-1 Beta  d'Oagis (OAG Integration Specification) vient de sortir et com-porte 545 schémas XML et 430 BOD, Business Object Document, apport original d'OAG. Ces BOD participent d'un canonical business lan-guage intersectoriel pour éviter que chaque secteur ne réinvente sa commande et sa facture. Le secteur des ressources humaines a ainsi considéré ses besoins d'échanges HR-XML comme des BOD.
Une souplesse de type API qui fait qu'Oagis peut être utilisé aussi bien par ebXML que RosettaNet ou BizTalk. Et Microsoft est vu par OAG comme l'un de ses major contributors. Or OAG venant, après Oasis, d'être admis fin 2002 comme membre du MoU sur l'e-business,  on aura bien là un Memorandum of Understanding "comprenant" même indirectement Microsoft ! Mais "comprendre" ne signifie pas forcément être très volontariste pour se répartir les rôles et le MoU pouvait s'épeler Momentum of Unwilling !
En effet, Oasis y dispute la sémantique d'ebXML au Cefact-Onu et l'ITU vient de se lancer lui aussi dans la normalisation de l'e-commerce et l'e-Health ! Cela ne donne pas beaucoup d'autorité au Management Group du MoU, par exemple pour demander à l'IETF de mieux expliquer comment s'articule son Electronic Commerce Modeling Language avec les travaux déjà entrepris !
Seuls les BOD et les autres spécifications d'Oagis semblent modeler une "API de contenu-action" qui ne contrarie personne. L'arrivée d'OAG au MoU représenterait-elle alors un petit espoir de voir enfin se réaliser l'ambition du MoU : éviter les approches concurrentes entre les offreurs pour que les utilisateurs de l'e-business puissent disposer d'un jeu de standards cohérents et sans double emploi ?
 
D'après le Census, le B2B représente 93% de l'e-commerce aux USA, avec 86,3% en EDI classique (surtout en Ansi X12) dans la vente de gros. Et la charge des messages SOAP n'y représente encore que 2% d'après Zapthink. En France 1% seulement des entreprises utilisant l'EDI ont aussi recours à XML. Le rythme de migration de l'EDI vers XML et les Services Web (SW) est donc encore bien lent, d'abord pour deux raisons : pourquoi changer ce qui marche, et mieux vaut attendre de voir quel va être le résultat de la guerre des standards !
Mais l'évolution est néanmoins inéluctable, pour des raisons de technique et de business :
1/ Du point de vue business, on aura une utilisation simultanée de toutes les techniques d'échange pour mieux faire face à des besoins différents, notam-ment quant au caractère plus ou moins loosely coupled et interactif des transactions. Si les échanges répétitifs et peu évolutifs des flux tendus resteront longtemps assurés en EDI, les nouveaux partenaires seront reliés par des messages XML, par exemple envoyés par e-mail. Et comme pour le Web EDI, la réponse à ces messages sera transformée en message EDI par une passerelle.
De même, les flux liés à de nouveaux processus seront créés en XML et non plus par de nouveaux messages EDI. Les places de marché sectorielles B2B remplaceront aussi l'EDI comme élément fédérateur autour d'un dialecte XML. Et une fois stabilisés et sécurisés, des Services Web business driven se développeront alors de la simple recher-che d'information à la transaction complexe.
2/ Cette évolution ne sera pas contrariée d'un point de vue technique. Outre l'économie procurée par Internet par rapport aux RVA, ou l'arrivée des nouveaux PGI communicants (ERP 2) la pression de la SOA, Services Oriented Architecture, pour la réutilisation des intégrations de processus accé-lérera la migration de l'EAI vers le concept de service interne : et si l'architecture interne  du SI des entreprises est basée sur le concept de service à couplage lâche, type Services Web, l'architecture de leurs relations externes suivra ! Alors, sans vouloir forcer son rythme, autant accompagner cette évolution inéluctable !
 
Pour que "le message passe" il faut bien être d'accord sur le sens des données à transmettre

 Metadata Registries :
 
 Microsoft à Oasis :
     vers une articulation ? 
 
  quadrille ou convergence ?
En EDI classique, on connaissait ses partenaires et on se mettait d'accord avec eux, souvent en one to many, sur une déclinaison personnalisée des Guides d'utilisation des messages Edifact ou ANSI X12.
 En Services Web, cela continuera à être du one to many, mais chacun pouvant être le one, pas seulement les grands donneurs d'ordres. Cela, grâce à des metadata registries de référencement où l'on trouvera le profil d'une entreprise avec laquelle on prévoit une transaction. C'est la définition d'UDDI où sont référencés, pour chaque entreprise, les produits et les services qu'elle offre, où et comment. La version 3 d'UDDI (cf le  n°59 de VendrEDI) marque des progrès vers l'universalité.
Mais à côté d'UDDI, il y a d'autres metadata registries, portant sur les formats, la sémantique, les composants, les schémas et autres "objets" :
- un coup de chapeau d'abord à l'ISO 11179, norme éprouvée sur la manière de nommer, décrire, identifier et enregistrer les données. Elle facilite grandement les comparaisons entre sources ;
- il y a ensuite la DCMI, Dublin Core Metadata Initiative (Dublin dans l'Ohio) qui a abouti récem-ment à la norme ISO 15836 pour réaliser un réseau coordonné de vocabulaires de description séman-tique des données (vocabulaires basés sur RDF, Ressource Description Framework ; 
- pour la sémantique, avec RDF, il faut citer OWL, les TopicMaps et même le projet XFML, eXchangeable Faceted Metadata Language, sans oublier un possible réseau de namespaces regis-tries enregistrant et reliant les vocabulaires ;
- il y a enfin les registries prévus par ebXML pour enregistrer tous les "objets" de l'e-business, codes, best practices, description de Services Web en WSDL, profils d'entreprises etc. General Motors, entre autres, gère en extranet un registry ebXML qui inclue des BOD d'OAG (cf 1ère page).
Tout cela n'est pas évident ! Les "données sur les données" étant censées faciliter la tâche des déve-loppeurs et utilisateurs potentiels pour le décollage de l'e-business, on attend une road map qui montre à tous où trouver des metadata registries cohérents et complémentaires.
Les différents consortiums de standardisation dev-raient d'abord s'inspirer des normes existantes :  la sémantique partant de la norme Dublin Core et la gestion de contenu et les procédures d'enre-gistrement étant assurées suivant l'ISO 11179. UDDI serait alors chargé de la discovery, mais y compris celle des "objets" ebXML, parmi lesquels seraient inclus les schémas XML pour tout boucler.
 
 
Le but des Services Web est l'interopérabilité universelle entre applications, grâce au modèle loosely coupled assurant une intégration souple entre systèmes hétérogènes. Ce qui suppose, au-delà de WSDL,  de savoir modéliser et conduire les séquences de messages peer to peer, synchrones et asynchrones, représentant un business process. D'où l'importance, afin de pouvoir exécuter en commun chaque business process, d'un langage standardisé  indispensable à l'interopérabilité de bout en bout des Services Web.
Où en est-on de cette convergence vers un langage d'exécution des business process ? Si comme pour les autres domaines de standardisation des Services Web, sémantique métier, sécurité et reliability des échanges, on était jusqu'à présent dans une situation de guerre paralysante, la situation semble avoir récemment évolué de manière positive.
En effet, après avoir quitté la réunion inaugurale du groupe de standardisation du W3C sur le Business Process management, Microsoft, IBM et BEA viennent de soumettre à Oasis  BPEL4WSV1.1, nouvelle version améliorée à laquelle se sont joints SAP et Seibel. Première réunion le 15 mai du nou-veau WSBPEL TC d'Oasis sous une co-présidence Microsoft-IBM.
Après la valse-hésitation, la choreography passe donc au quadrille avec changement de partenaires ! En effet, le projet rival de Sun, WSCI, reste bien, lui, soumis au W3C ! Et jusqu'à présent, on voyait Sun animer à Oasis des armes anti-Microsoft : ebXML ou l'utilisation dans SAML de Liberty Alliance, spécification opposée à Passport de Microsoft pour la gestion des identités dans les Services Web. Chassé croisé type java-vache, ou reflet de l'orien-tation business d'Oasis qui laisse chacun créer son groupe alors que le W3C essaye d'abord de main-tenir une cohérence d'ensemble ?
Certains, comme Oracle, sont déçus et espèrent encore que les groupes du W3C et d'Oasis pourront être complémentaires. Pour la majorité, au contraire, il s'agit d'un signal fort de convergence vers un stan-dard accepté par tous dans un domaine essentiel pour l'essor des Services Web. BEA, qui en plus de ses propres propositions, était co-auteur de BPEL, tout en participant au groupe du W3C, a déclaré que c'était désormais le groupe d'Oasis qui était l'avenir. De même SAP qui était co-auteur de WSCI, soumis au W3C, soutient désormais le groupe BPEL TC d'Oasis. Il restera alors à ce groupe à veiller à l'arti-culation avec la spécification BPSS d'ebXML, suite à la norme EDI ouvert.
Ce numéro 62 de VendrEDI a été adressé à 1092 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés zippés à    http://www.actimum.com/acvendredi.htm