Sans parler des plates-formes de Microsoft, IBM ou Sun, de nombreux offreurs proposent maintenant l'approche SOA (Services Oriented Architecture) à des utilisateurs dont la demande est prévue par Gartner comme devant être très forte en 2005. Sont mentionnés aujourd'hui deux des leaders de cette offre SOA, BEA et webMethods :

 - BEA s'est associé depuis le départ à la maturation des Services Web (SW) qui sont au cœur de la SOA. Et c'est avec des SW que BEA améliore son produit d'intégration,  WebLogic. BEA offre aussi son  Tuxedo, qui est un produit dont les connecteurs permettent de développer une plate-forme globale à partir du mainframe existant, donc sans Big Bang ni nouvelles interfaces applicatives.  La vision de BEA pour la SOA est maintenant basée sur  Liquid Com-puting visant à fluidifier les rapports IT-business pour une adaptation plus rapide aux changements.

S'étant associé avec la société BMC, leader des solutions d'administration, BEA Systems, leader des logiciels d'infrastructures, peut ainsi intégrer BPM (process) et BSM (services) dans une solution globale d'administration  des  processus  métier qui intègre une stratégie  de  gestion  commune, à la fois des infrastructures, des applications, des événe-ments et des impacts sur les services.

 -  webMethods a comme "maître-mot" Faster, et sa suite logicielle  Fabric reste son  produit de base avec des outils très "Smart". Initiateur de WSDL, outil descriptif des SW, webMethods est un pure player (n'offrant que des logiciels d'intégration) et siège à ce titre au WS-I pour l'interopérabilité des SW. Selon Régis Mauger, directeur technique pour l'Europe du Sud, l'intégration métier de webMethods assure l'assemblage rapide, sous forme de SW inscrits dans un répertoire UDDI, de nouveaux processus à partir de composants métiers existants.  Mais le préalable est que les gens des "métiers" définissent d'abord les services qu'ils souhaitent offrir ou "invoquer". Alors, il est possible d'éviter tout Big Bang, ou tout nouvel EAI "propriétaire", et cela autorise la reprise de ce qui marche dans l'entreprise. Y compris l'EDI pour lequel le même service que le RVA peut être fourni en SW. Parmi les derniers clients de webMethods, le CNRS et Fujifilm France ( ).

Pour un service simple,  REST suffit, par exemple pour consulter automatiquement tous les matins les catalogues de ses fournisseurs. D'ailleurs 80% des utilisateurs des Services Web (SW) d'Amazon le préfèrent à SOAP, qu'Amazon offre aussi. Mais pour offrir ou rechercher plusieurs services pouvant devenir des business process complexes, en interne comme en externe, REST ne semble pas être une alternative sérieuse aux SW.

Sans s'embarquer d'emblée dans la table des standards WS-* (cf VendrEDI n°85), il vaut mieux démarrer en SW par leur socle : ainsi, un article d'une revue fédérale US s'en tient à la recomman-dation des seuls " 5 Web Services that matter" :

1/ WSDL décrit en XML le service et précise les données de mise en oeuvre du SW, comme un contrat entre un service et un client. La version WSDL 2.0 (cf. le Primer) devrait être assez stable puisque comportant les améliorations attendues.

2/ SOAP proposé par Microsoft et à la base de .Net comporte une version SOAP 1.2, stable depuis deux ans ou presque, avec l'ajout de MTOM pour les attachements (cf. VendrEDI n°84).

3/ WS-Security, première étape importante vers la sécurité des SW externes, mais pas complète.

4/ UDDI, répertoire des SW, pas vraiment Univer-sal, est surtout testé à titre interne. Mais son format est stable et utilisé pour tous les répertoires des offreurs d'outils proposés pour bâtir des SW.

5/ WS-Interoperability, qui n'est pas un standard, mais un consortium qui réunit tous les offreurs pour vérifier que leurs produits SW seront bien interopérables, grâce à WS-I Basic Profile ou bien WS-I Security profile.  

Enfin le Federal Computer News mentionne BPEL

comme prometteur  pour standardiser l'automatisa-tion du traitement des business process en SW. Mais sans attendre BPEL, si les 5 standards de base sont utilisables pour démarrer en SW, les utilisateurs souhaitent que leur stabilité, et donc leur interopérabilité, soient maintenues : en assurant, par exemple, que SOAP 1.2 relié à XML 1.0 sera bien compatible avec le nouveau XML 1.1 ! Cette stabi-lité est d'autant plus importante que l'on dispose avec XML, WSDL, SOAP et WS-Security d'un core opérationnel pour les SW. Et il a été conclu à la Conférence XML 2004 qu'il valait mieux  limiter le recours aux standards des SW en fonction des besoins réels, notamment pour démarrer, quitte à faire appel ensuite à tout le WS-*, mais progressivement.