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 !

 

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.