Vers une généralisation des applications distribuées?

Depuis plusieurs années, les technologies distribuées ont tenté de s'imposer. Si cela marche très bien dans le cas d'applications spécifiquement adaptées (les ERP par exemple), ce type d'architecture n'a jamais été vraiment pertinent dans le cadre d'applications plus traditionnelles (la grosse majorité des applications). J'ai l'impression que ça change.

Globalement, j'ai vu passer 3 étapes:

Etape 1: une première grosse tentative plus ou moins viable
Les concepts intéressants de CORBA (trop complexe pour une application lambda) ont amené un intérêt (surtout de la curiosité) dans le monde de l'entreprise pour ce type d'applications. Cette curiosité a été renforcée par les EJB 1 et 2, un véritable engouement s'est créé.
Malheureusement, CORBA est trop complexe et complètement inadapté pour une application lambda (ça n'a jamais été son but), de même que l'étaient les EJB 1 et 2, inadaptés dans 95% des cas (design Sun de référence pour les applications Web, mais les limites de l'architecture sont trop contraignantes et la complexité est abusive).

Etape 2: de la curiosité à la solution élégante
Faisant suite au rejet des EJB par la communauté des développeurs nouvelles technos, les conteneurs plus léger d'inversion de contrôle (ou injection de dépendance), ont apporté une architecture claire et saine sur ces concepts déjà intéressants.
De manière similaire, la remise en cause de CORBA mène à l'apparition des Web Services, plus légers, basés là encore sur une technologie qui suscite beaucoup de curiosité de la part des décideurs: le XML (dont on parle à tort et à travers, et qui devient la solution miracle à tous les problèmes d'interconnexion - du moins dans la tête des directions informatiques...).
Les technologies de bus de messages se répandent et maturent.

On commence à parler de SOA, architecture orientée services, qui remet en cause le principe d'encapsulation des langages orientés objets ("les attributs des objets et les méthodes sur ces attributs sont dans la classe" devient "l'objet contient uniquement les données - POJO ou Javabean, les traitements sont déportés dans des classes de service"). Cette architecture entraine pour toute application, distributée ou non, de grands bénéfices en terme de maintenabilité et d'évolutivité).

Etape 3: Généralisation

Tout s'intègre très bien: SOA se généralise et bénéficie très bien des concepts de conteneurs légers, se prête très bien à la mise en place de Web Service et cerise sur le gateau, permet une évolution très transparente vers un style distribué: à partir du moment où les services sont clairement et proprement définis, on peut selon les besoins en distribuer certains très facilement.

Les concepts de grilles de calcul et de caches répartis sont connus et les décideurs informatiques s'y intéressent et investissent dessus, le plus souvent avec grand succès. Des startups qui ont développé ces produits enregistrent des succès flamboyants (Datasynape pour les grilles de calcul, Gigaspaces et Tangosol Coherence - racheté par Oracle il y a peu - pour les caches distribués avec haute valeur ajoutée).

J'ai l'impression que ce type d'application est enfin suffisamment simple pour la mise en place, suffisamment bien vu pour l'investissement des décideurs dans ces solutions et suffisamment mature pour se généraliser.

Par contre, cette évolution entraine un autre style de programmation; l'ordonnancement et la synchronisation des process, parfois asynchrones, exigent pour les programmeurs d'être plus malins et de voir l'application de plus loin, les transformant progressivement en architectes logiciel.