L'approche SOA passe-t-elle nécessairement par des approches distribuées

Et des communications distantes inter-applicatives ?

Contexte : monde de la gestion....

Une petite réflexion sur tout ces moyens d'appel à distance : RMI, IIOP, WebServices, EJB, Corba,....

As-t-on réellement besoin de tout ça ? Pourquoi parle t-on toujours de distribution/appel distant quand on parle de SOA ?

Plus j'y pense et plus je me dis que tout cela ne sert peut-être pas tant que ça.

Bon, ok il faut expliquer un peu...

L'idée est : "quand a t-on vraiment besoin de distribution ?"

1- Ben quand une IHM doit appeler un serveur "métier". Dans des cas simple ou on fait du Web et que tout est sur le même serveur, ce n'est même pas nécessaire. Mais, ok, pour des question de sécurité et donc d'architecture, partons du principe qu'une IHM doit toujours faire appel à des services "distants" pour dialoguer avec le "métier".

Dans ce cas, quelle est la nature des "services" appelés par l'IHM ?
Si on a des règles d'architecture correctes, c'est à dire que l'on a pas de métier côté IHM et que l'on se doit de minimiser les aller/retour entre IHM et métier (pour les perfs !), eh bien ces "services" sont forcément des services dédiés à l'IHM. Ce que je veux dire c'est que ces services ne sont pas fondamentalement "métier" ou tout au moins pas réutilisables dans un autre contexte que cette IHM. Alors ok, comme on fait de la bonne conception, ces "services" font s'appuyer, "derrière", sur des composants de plus bas niveau qui eux seront indépendant de l'IHM et seront plus "métier".
Ces "services IHM" sont-ils alors des services au sens "SOA" ? Est-ce que ce ne seraient pas plutôt les composants de "derrière" qui sont les services au sens SOA ? Mais si oui, alors ces composants n'ont pas besoin de distribution car ils sont sur le serveur.

2- Bon, ok, toujours avec cette idée que les services "SOA" sont les composants de "derrière". Ces composants peuvent avoir besoin d'appeler des services d'autres applications. Ah bon ? Lesquels réellement ? Dans un SI, les applications ont des responsabilités claires et il est rare que le métier "transactionnel" soit beaucoup réparti entre plusieurs applications. Au "pire", on a des référentiels communs ou des "mécanismes généraux" qui sont partagés. Pour ces référentiels ou mécanismes, on peut très bien se passer de distribution en déployant les "librairies" qui les constituent sur les différents serveur métier. On a alors des composants locaux qui doivent simplement être déployés correctement sur plusieurs serveurs.
En dehors de ces "applications particulières", la communication avec d'autres applications est souvent asynchrone. Soit via des évènements temps réel soit via des fichiers et là il n'y a pas besoin de distribution.

Bref, je me demande si on ne devrait pas limiter l'importance des technos de distribution dans nos approches d'architecte et plus réfléchir à la modularité de nos applications et à leur mode de déploiement dans les serveurs d'application en fonction des liens qu'elles peuvent avoir.
Et au final, plus se concentrer sur des problématiques comme celles qui tournent autour d'OSGI (modularité, versioning) et des "nouveaux serveurs d'applications" (où la distribution n'est pas le coeur du discours)

Des avis ?

nb : j'ai mentionner que ces réflexions étaient faites dans le contexte d'un SI "Gestion" mais je me demande si ce n'est pas vrai dans l'absolu.