Les standards Web Services sont-ils à SOA ce que les EJB furent à J2EE ?

Nous en parlions dans nos revues de presse (celles du 11 juin et celle du 18 juin), le débat est en ce moment très animé autour d’une hypothétique standardisation de la pile des standards SOA.

L’occasion de retomber sur un article d’Aurélien Pelletier : « SOAP is the EJB of XML???« . Ce billet à plus de deux ans mais la question est plus que jamais d’actualité à l’heure où de plus en plus de voix s’élèvent autour des solutions alternatives, aux EJB d’une part, aux Web Services d’autre part. Elle mérite d’être posée, élargie et remise en perspective : Les standards Web Services sont-ils à SOA ce que les EJB furent à J2EE ?

Ainsi posée, la question amène plusieurs axes de réflexion :

Standards Web Services et EJB : les mêmes écueils ?

Les points de comparaison soulevés par Aurélien Pelletier sont très pertinents et montrent que les Web Services et les EJB ont en commun une triste histoire :

• Des spécifications trop ambitieuses et trop complexes.
  Répondre de manière exhaustive et en une seule fois à des problématiques aussi larges ; L’ambition est noble, mais n’est-ce pas pêcher par orgueil ? Pourquoi ne pas avancer pas à pas en fonctionnant par itérations courtes dans une démarche résolument agile ?
  Le plus bel exemple des travers de ces ambitions tient dans l’existence même du WS-I.org (Web Services Interoperability Organization). N’est ce pas un comble qu’un organisme a été monté pour rendre interopérables les différentes implémentations d’un standard d’interopérabilité ?

• La promesse d’un outillage simplificateur.
  Que ce soit pour les EJB ou les Web Services, les débuts ont été plus que difficiles. L’outillage était là mais ne tenait pas ses promesses. Qui n’a jamais eu de problème avec un descripteur de déploiement EJB 1 généré par un IDE ? Pourquoi l’option « Générer un WSDL interopérable » n’a pas, pendant longtemps, été cochée par défaut ?

• Une machinerie trop lourde pour la majorité des besoins.
  Une grande partie des projets utilisant les EJB et/ou les Web Services n’utilisent qu’une toute petite partie des capacités de ces technologies. Tout simplement parce qu’ils n’en ont pas besoin. On rejoint ici le syndrome de « la pioche pour cueillir des pâquerettes » qui pousse à utiliser un WAS (WebSphere Application Server) ou un WLS (Weblogic Server) là où un Tomcat suffirait amplement.

Pourquoi parler des EJB au passé ?

La mort des EJB, un débat qui ne manque pas de piment ! Ce sujet fait partie des incontournables polémiques qui enflamment régulièrement notre communauté et plus modestement les échanges entre consultants Xebia. Voici quelques éléments de réflexion :

• Premièrement, les EJB existent-ils ?
  Oui, il n’y a qu’à regarder leur réputation sulfureuse pour s’en convaincre.

• Les EJB 3 ont-ils un avenir ?
  Rien n’est moins sûr. SpringFramework est un concurrent très sérieux qui a déjà plusieurs années d’avance et l’écart se creuse chaque jour. De plus, à la différence d’Hibernate qui joue la carte JPA, SpringFramework se présente comme une alternative (« We still believe EJB does not add value … » by Rod Johnson in Spring Pitchfork FAQ). On notera tout de même, comme nous le signalions en début de semaine, qu’Interface21 a rejoint la JSR 316 (Java EE 6).

• Enfin, qui supporte les EJB 3 ?
  A part JBoss et Sun, il n’y a pas grand monde prêt à se battre bec et ongle pour eux.
  De son côté BEA supporte EJB 3 depuis la sortie de WebLogic Server 10, il y a déjà quelques mois. Dans le même temps, chez IBM, les EJB 3 sous WebSphere ne sont pas attendus avant le premier trimestre 2008.
  En tout cas, les éditeurs portent actuellement plus d’attention à SCA (Service Component Architecture), SDO (Service Data Objects) et autre modèles en cours de standardisation.

En attendant, on n’a rien inventé de mieux et de plus simple et de plus performant pour propager un contexte transactionnel remote et un context de sécurité remote.

Nous reviendrons plus en détail dans un prochain billet sur l’avenir des EJB …

Quel avenir pour les WS-* ?

La mode du tout Web Service a rapidement mis en exergue les manques du triptyque de départ (WSDL, SOAP, UDDI) qui n’est plus qu’un diptyque (même si UDDI est censé se relever depuis la version 3). Par exemple les aspects transactionnels en sont absents ce qui impose de gérer des mécanismes de compensation.

C’est alors que se sont mis à fleurir les WS-*. Même après consolidation et épuration, la confusion autour de ces standards est palpable. Il suffit pour s’en convaincre de lire les articles « Making Sense of all these Crazy Web Service Standards«  publié par Michele Leroux Bustamante sur InfoQ ou « WS-Madness«  publié par Steve Craggs sur le blog de Lustratus Research.

Les WS-* ne devraient pas disparaître de si tôt, mais il faudrait que cela soit pour de bonnes raisons et pas uniquement parce que l’industrie logicielle y a massivement investi. Leurs promoteurs auront à relever les défis suivants :

• Finaliser les spécifications : Beaucoup des WS-* sont encore loin d’une version 1.0.
• Elaguer les spécifications redondantes ou inutiles.
• Fournir des implémentations interopérables.

Quoi qu’il en soit, l’adoption par tous d’une couche unique de standards Web Services reste une illusion comme l’explique Rich Seeley dans son article « Standard Web services stack remains illusive SOA goal« .

Pour finir

Enfonçons une porte pas si ouverte que cela : Quel est l’intérêt d’exposer ses services sur un standard interopérable (ou presque) :

• Dans le cadre d’un S.I. (ou d’un sous domaine de S.I.) mono-technologique ?
• Quand ces services n’ont pas vocation à être invoqués par des partenaires ?