Dans la même logique que ton article, une autre initiative orientée "modularité/archi ouverte" marche aussi sur les plates-bandes J2EE: le projet Apache Tuscany, l'implémentation officielle de la norme SCA (spécification de l'open OASIS pour le packaging/assemblage/environnement d'exéc d'applis SOA – initiative soutenue par les acteurs majeurs du marché – RedHat, WebLo, IBM, SAP…). Tuscany propose justement, pour sa version 1.2, une implém' OSGi de sa plateforme (http://apache-tuscany.blogspot.com/2008/04/apache-tuscany-sca-java-11-released.html).

SCA, c'est: un mode d'assemblage "récursif" de services, une ouverture à différents langages d'implém' (javascript, java, python, BPEL), des modes de transport interchangeables (JSon, WService, EJB, JMS), un accès unifié aux données (SDO), des services d'infra "comme les grands" (sécu, transac, archi répartie, logs, monitoring, synchrone/asynchrone). C'est d'la bombe de balle, bébé !

Des implém's de plateforme SCA sont en Beta ou en distrib optionnelle chez certains gros (IBM, WebLo), des boites ont déjà commencé à mettre Tuscany en environnement d'exéc, il reste encore à valider/terminer des specs… Bientôt un appServer parfum SCA ? Qui sait ?

Pour revenir à OSGi/Spring, un white-paper de l'open-soa (http://www.osoa.org/download/attachments/250/Power_Combination_SCA_Spring_OSGi.pdf?version=3) mets en exerge le trio SCA/Spring/OSGi comme solution complète pour déployer, exécuter et maintenir des applications orientées "service". OSGi viendrait sous la couche SCA, offrir des "extensions" (versionning/déploiement à chaud j'imagine). On se demande même pourquoi on n'y avait pas pensé plus tôt, on espère bien sûr que cette archi de rêve soit "poussée", grâce au support de la norme SCA, dans le monde des "grands" serveurs applicatifs, et qu'on puisse enfin arrêter de blinder nos sources de code qui n'a rien à voir avec du business.