Communication client/serveur: recherche d'une solution

Bonjour,

Je suis actuellement sur un projet où l'on veut mettre en place une architecture regroupant un serveur développé en Java accédant à une base de donnée et effectuant la plus part du métier conjointement avec la base de données.

Et d'autre part des clients viennent se connecter au serveur pour voir ces informations (et modifier certaines configurations comme les gestions d'alertes, etc.), plus une ou plusieurs interfaces d'administration du serveur.
Les clients peuvent être du client lourd type standalone swing ou du client léger via un serveur d'application qui serait connecté avec le serveur.

Ma grosse problèmatique étant de trouver une solution viable pour mettre en place ces communications... Dois-je utiliser un framework particulier ? (Spring?) Mettre ne place une communication basé sur du RMI ou du JMS ?
Y a t il des solutions pour mettre en place une sorte de "bus de communication" entre mon serveur et mes différents clients ?(multi-client /multi-type de client ^_^)

Je commence à patoger entre les différentes solutions qui peuvent exister sans savoir où je devrais orienter mon regard, toutes les idées sont les bienvenues !

D'avance merci beaucoup pour votre aide.

Cdt,
Raz.

Tout dépend de la taille de l'application.

Si elle est raisonnable, RMI peut être suffisant. Par contre, si elle commence à devenir importante, tu vas te noyer dans RMI et il vaut mieux passer par un Framework qui fera le travail d'encapsulation RMI.

Spring est une bonne solution pour ça, et le temps investi à la formation Spring sera vite rentabilisé en n'ayant pas à développer toute la structure d'échanges en RMI.
Par contre, au niveau du déploiement, Spring nécessitera un serveur Tomcat alors qu'en utilisant directement RMI, tu aurais pu t'en passer.

Une autre idée, c'est d'utiliser un serveur d'application complet (JBoss), et de coder tes classes métiers qui attaquent la base de données sous la forme d'EJBs. La aussi, le temps investi en formation est généralement rentabilisé.
Cette dernière solution est en général dimentionnée pour de très grosses applications.

Déjà merci pour ta réponse rapide :-)

En fait la taille de l'application pour le moment n'est pas énorme (loin de là même...), mais sujette à grossir (plus c'est jeune plus ça peut grossir vite).

D'autre part, dans cette problèmatique de communication, je ne peux pas considèrer les solutions en parties webeuse. je n'aurais pas la possibilité d'avoir de serveur d'application pour rendre disponible les informations du serveur.
Donc s'il est nécessaire d'avoir Tomcat avec Spring la solution n'est plus viable de mon côté.

C'est du full standalone en fait, mais il faut que je puisse aussi le faire évoluer pour le connecter avec une servlet par exemple ou d'autre serveur qui aurait besoin des informations générées.

Je ne sais pas si c'est super clair, mais j'ai certaine contrainte pour trouver en terme de mise en place et d'intégration qui empêche l'utilisation de serveur applicatif.