Serveur Swing et Java EE
J'ai une application Swing autonome qui utilise Hibernate pour sa couche de persistance. J'ai besoin d'étendre cela à un système à trois niveaux, de sorte qu'il y aura plusieurs instances de l'application Swing et un serveur central. Le client est une plate-forme de négociation d'actions, il contiendra donc beaucoup de logique métier. Le serveur sera responsable de la plupart des opérations de persistance et d'une certaine logique métier.
Quelle serait la meilleure façon d'implémenter le serveur pour mes besoins? EJB3 ou Printemps? Quelle est la meilleure pratique pour que les applications Swing interagissent avec un serveur? Je ne veux pas aller avec RMI car non seulement il devient obsolète, mais il n'y a aucune garantie que les clients et le serveur seront sur le même réseau.
4 answers
Si le client est un client Java, je ne vois pas l'intérêt d'utiliser des services Web (et donc d'avoir la surcharge de l'objet en sérialisation XML) et j'irais pour EJB 3.x.
Pour moi, les principaux avantages (au-delà des performances et de l'évolutivité) que vous obtenez avec un bon conteneur sont tolérance aux pannes et basculement (à la fois côté serveur et côté client, en particulier avec les Beans de session sans État s'ils sont idempotents). Pour une plate-forme de négociation d'actions, cela compte.
Aussi notez que l'utilisation d'EJB3 n'exclut pas nécessairement l'utilisation de Spring pour la colle (côté client et / ou côté serveur).
Et si le besoin d'exposer vos services en tant que services Web doit survenir (par exemple pour un autre client non Java), il suffit de les annoter avec des annotations JAX-WS.
Je ne veux pas aller avec RMI puisque non seulement, il devient obsolète
Ce n'est pas vrai du tout. Tant que Java est là, vous aurez RMI.
Et que pensez-vous que les EJB utilisent pour communiquer? C'est au RMI.
Mais il n'y a pas non plus de garantie que les clients et le serveur seront sur le même réseau.
Personnellement, je préférerais le printemps. Vous pouvez exposer votre couche de service à l'aide de services Web ou de HTTP remoting.
Allez avec Spring et RMI. Si votre client et votre serveur sont tous deux Java, c'est la meilleure solution avec les meilleures performances et productivité.
Notez que les EJB n'utilisent pas nécessairement RMI comme protocole de transport. OpenEJB par exemple utilise son propre protocole personnalisé. Nous obtenons environ 7300 TPS sur le fil, ce qui est assez bon. Il existe également une intégration Spring, donc si vous le souhaitez, vous pouvez construire le serveur avec Spring et injecter des beans Spring dans les EJB et vice versa: