Servidor Swing y Java EE

Question

Tengo una aplicación Swing independiente que utiliza Hibernate para su capa de persistencia. Necesito extender esto a un sistema de tres niveles, para que haya múltiples instancias de la aplicación Swing y un servidor central. El cliente es una plataforma de negociación de acciones, por lo que contendrá mucha lógica comercial. El servidor será responsable principalmente de las operaciones de persistencia y algunas lógicas comerciales.

¿Cuál sería la mejor manera de implementar el servidor para mis necesidades? EJB3 o primavera? ¿Cuál es la mejor práctica para que las aplicaciones Swing interactúen con un servidor? No quiero ir con RMI, ya que no solo se está volviendo obsoleto, sino que tampoco hay garantía de que los clientes y el servidor estén en la misma red.

Answer 1

Si el cliente es un cliente de Java, no veo el sentido de usar servicios web (y por lo tanto tener la sobrecarga del objeto a la serialización XML) y me gustaría ir a EJB 3.x.

Para mí, los principales beneficios (más allá de rendimiento y escalabilidad) que se obtiene con un buen envase son tolerancia a fallos y fail-over (tanto en el lado del servidor y del lado del cliente, especialmente con las habas sin estado de sesión si son idempotentes). Para una plataforma de negociación de acciones, esto importa.

También tenga en cuenta que el uso de EJB3 no excluye necesariamente el uso de Spring para el pegamento (en el lado del cliente y/o del lado del servidor).

Y si debe surgir la necesidad de exponer sus servicios como servicios web (por ejemplo, para otro cliente que no sea Java), solo anótelos con anotaciones JAX-WS.

Answer 2

no quiero ir con RMI, ya que no sólo es quedando obsoleta

Esto no es cierto en absoluto. Mientras Java esté cerca, tendrás RMI.

¿Y qué crees que los EJB están usando para comunicarse? Es RMI.

pero también hay ninguna garantía de que los clientes y el servidor estarán en la misma red.

Personalmente, preferiría Spring. Puede exponer su capa de servicio utilizando servicios web o comunicación remota HTTP.

Answer 3

Vaya con Spring y RMI. Si su cliente y servidor son ambos Java, es la mejor solución con el mejor rendimiento y productividad.

Answer 4

Tenga en cuenta que los EJB no necesariamente utilizan RMI como protocolo de transporte. OpenEJB, por ejemplo, usa su propio protocolo personalizado. Tenemos aproximadamente 7300 TPS por cable, lo cual es bastante bueno. Hay una integración de la primavera, así que si quería, se podría construir el servidor con la primavera e inyectar granos resorte en EJB y viceversa:

http://openejb.apache.org/3.0/spring.html