J'ai fait une application Java Swing. Maintenant, je voudrais en faire une application client-serveur. Tous les clients doivent être notifiés lorsque des données sur le serveur sont modifiées, je ne cherche donc pas de service Web. L'application client-serveur sera exécutée sur un seul LAN, c'est une application commerciale. Le serveur contiendra une base de données, Javadb.
Quelle technologie et quelle bibliothèque est la plus facile à commencer? Dois-je le mettre en œuvre à partir de zéro à l'aide de sockets ou devrais-je utiliser Java Rmi, ou peut-être JMS? Ou y a-t-il d'autres alternatives qui sont plus faciles à commencer?
et y a-t-il une bibliothèque de serveur que je devrais utiliser? Est-ce que la jetée est une alternative?
5 Réponses :
Ceci est une grande partie de ce que J2EE fait, mais c'est une nouvelle courbe d'apprentissage, car elles ont pré-résolu de nombreux problèmes que vous rencontrerez et beaucoup vous risquez de ne pas et donc d'ajouter beaucoup de nouvelles technologies.
Mais à son point de base, J2EE répond à cette question.
Je vois, je n'ai jamais utilisé J2ee avant. Mais je pense qu'il est temps de le faire maintenant;) merci. S'il n'y a pas de solution léger.
Il y a beaucoup de solutions légères, mais vous rencontrerez de nombreux problèmes que J2EE a déjà rencontré et résolu. Je recommande de lire au moins sur un framework J2EE gratuit suffisamment pour connaître toutes les fonctionnalités - de cette façon, vous remarquerez des problèmes potentiels que vous risquez d'avoir déjà résolu. Si vous vous sentez toujours en sécurité, utilisez RMI. J2EE fournit des serveurs redondants (à peu près gratuits) et un basculement de la livraison de messages garantis et d'autres choses qui peuvent être très difficiles à obtenir si vous décidez que vous le souhaitez plus tard.
Le problème avec Java EE est que, en plus de résoudre les problèmes que vous avez, cela résout également une tonne de problèmes que vous n'avez pas, mais vous les soumet à eux.
@Ryan semble être si vous utilisez des outils à jour qui ne devraient pas être un problème. Je suppose que la plupart des problèmes dont vous parlez sont des problèmes de configuration qui devraient être surtout faciles avec de nouveaux outils et pas trop de mélange et de match. Beaucoup d'autres problèmes sont partis dans la version récente (les haricots sont beaucoup plus faciles à travailler avec, etc.), mais si vous avez des expériences différentes, je suis en fait curieux de savoir où vous avez rencontré des problèmes.
@Billk Fondamentalement, il y a juste beaucoup à apprendre et cela finit généralement sur la surkill. Vous devez vraiment comprendre comment Java EE travaille pour l'utiliser, mais c'est compliqué en raison de la grande puissance et de la grande flexibilité. Cela fait que vous ne vous souciez pas de la grappe. Il est difficile de décider de ce dont vous avez besoin lorsque vous ne savez même pas ce que vos choix sont - de sorte que vous finissez par trier à travers (et essayez) quelques-unes des technologies Java EE avant de pouvoir décider des utilisations. Ensuite, il y a un tas de technologies concurrentes qui prétendent être supérieures, alors vous finissez par les enquêter aussi.
Je comprends ce que tu veux dire. Je suppose que ma pensée était qu'une fois que vous avez atteint le point que Jonas a probablement la peine de commencer à mordre cette balle, sinon vous continuez à trouver "une autre technologie", vous devez ajouter à votre pile et vous vous retrouvez avec un gâchis.
J'ai travaillé dans un projet comme celui-ci. Nous avons mis en œuvre la balançoire côté client et le serveur avec J2EE. Nous avons utilisé EJB, des haricots apatrides et des haricots pilotés par message. Du projet de suivi des périphériques. Nos clients étaient des utilisateurs de camions + swing et nous avons utilisé des serveurs + TCP / UDP, Apache Mina Cadrework pour gérer et conserver les connexions.
MINA est un bon choix en tant que cadre d'application réseau pour la construction d'un serveur simple à cet effet - c'est une option bien meilleure que d'utiliser des prises brutes.
Si vous avez vraiment besoin d'un serveur d'applications, vous pouvez prendre votre avis sur JBoss . Il fournit également un composant de télécommande (comme alternative à quelque chose comme Mina):
http://www.jboss.org/jbossremoting
Vous n'aurez probablement pas beaucoup de besoin de Enterprise Java Haricots cependant. Dans la plupart des cas, un cadre simple
étant donné que vous avez déjà la demande, la chose la plus simple à faire est d'identifier l'interface dont vous avez besoin entre le client et le serveur, et tout d'abord pour refluter votre application pour utiliser cette interface pour parler entre le back-end / front-end dans le même processus .
Ensuite, vous pouvez commencer à scinder cela. Une solution simple serait de diviser cela à l'aide de RMI (puisque vous parlez d'objets Java et que vous avez des appels de méthode Java). Le ressort contient des outils utiles pour simplifier / automatiser l'exposition RMI d'interfaces.
pour l'exigence de notification, une simple multidiffusion UDP (ou diffusion) suffirait.
Notez que dès que vous avez divisé votre application, vous avez des problèmes. Maintenance des vues cohérentes des données, gérer les mises à jour opportunes, les cas de manipulation lorsque le serveur est en panne, des problèmes de chargement possibles lorsque vous obtenez de nombreux clients, etc. En un sens, la division de l'application dans un client et un serveur est juste le début d'une nouvelle architecture processus.
Je travaille dans les applications client / serveur Java Swing pendant près de 3 ans. Je vous suggérerais d'aller pour RMI / EJBS. La demande initiale que nous avons développée faisait cela en utilisant RMI / EJB pour la communication client-serveur avec Weblogic étant le serveur.
Mais nous avons découvert plus tard que de nombreuses fonctionnalités "liées au navigateur" doivent être incluses à l'application, telles que Session-Timeout, etc., nous avons donc utilisé le Brightside cadre qui enveloppe les appels RMI via HTTP. Une autre amélioration que nous avons faite est que nous avons remplacé Weblogic avec le serveur JBoss Open Source.
L'emballage des appels avec HTTP deviendra très pratique et vous pouvez rendre vos applications pivotantes vraiment riches. Plus tard, lorsque la situation demande à vous d'utiliser un site Web strictement, vous pouvez déployer votre swing à l'aide de JNLP .
J'espère que cela a aidé.
Mais en utilisant http, je ne peux pas pousser les notifications !?