Java EE/Glassfish Application Logic

Question

Estoy tratando de entender a dónde debe ir parte de la lógica de mi aplicación en mi aplicación Java EE. Soy nuevo en Java EE y estoy buscando cargar una gran cantidad de datos no estructurados de una base de datos heredada y crear un modelo de objetos limpio para que lo use mi aplicación. De mi investigación veo que las aplicaciones Java EE tienen 2 componentes, Enterprise Bean y componentes de aplicaciones web. Esta parte de mi aplicación será responsable de cargar los datos, crear el modelo de objetos y enviar mensajes a través de JMS en función del estado actual de los datos a las partes interesadas. Los datos se actualizarán mediante la sincronización con la base de datos y los mensajes recibidos a través de JMS desde aplicaciones Java remotas.

¿Es un EJB el lugar correcto para este tipo de funcionalidad? ¿Cómo puedo comenzar la inicialización de mi modelo de objeto (método principal, equivalente a la aplicación Java)? ¿Cuál es la mejor práctica para crear un evento programado para revisar el modelo de objetos y enviar mensajes a través de JMS?

He leído varios artículos sobre Java EE, Glassfish, EJB ... pero todavía no siento que tengo una idea clara de dónde debería escribir esta funcionalidad. Todos los ejemplos que he visto de EJB tienden a estar relacionados con las llamadas a métodos directos en los beans de las aplicaciones cliente.

Por el momento siento que una aplicación Java puede hacer el trabajo, pero estamos buscando utilizar RMI y clientes web en el futuro.

Answer 1

Java EE se utiliza tradicionalmente para el estilo arquitectónico cliente/servidor. La lógica empresarial se implementa en beans de sesión EJB, que generalmente se invocan desde una solicitud web, un mensaje JMS o una llamada remota RMI-IIOP.

¿Es un EJB el lugar correcto para este tipo de funcionalidad ?

La lógica entra en el EJB. Pero hay diferentes tipos de EJB.

¿Cómo puedo comenzar la inicialización de mi modelo de objetos (método principal de Java App equivalente)?

No existe el método main. Pero todavía hay algunas maneras de realizar algún procesamiento correspondiente a la implementación y/o el despliegue de la aplicación. Puede mirar ServletContextListener, Glassfish lifecycle module (non-standard) o quizás los recién introducidos Singleton beans y @Startup anotación.

¿Cuál es la mejor práctica para crear un evento con hora de revisar el modelo de objetos y enviar mensajes a través de JMS?

Puede crear un EJB Timer que se llamará periódicamente. Si necesita que el modelo se cargue una vez en la memoria, le sugiero que consulte los granos Singleton también. Con EJB 3.0, el problema era cómo start the timer automatically, pero creo que mejoraron eso en EJB 3.1 y los temporizadores pueden ser started automatically by the application server cuando la aplicación se implementa utilizando la anotación @Scheduled. Por lo tanto, de alguna manera puede proporcionarle un punto de partida deseado como lo hizo en su pregunta anterior.

Puede enviar mensajes JMS desde cualquier bean. JMS un sistema externo al igual que la base de datos. Los mensajes JMS se reciben utilizando un tipo especial de EJB denominado bean controlado por mensaje (MDB).

Su aplicación no será una aplicación cliente-servidor web-EJB-base de datos tradicional, pero debería ser factible con Java EE, que es definitivamente un modelo muy flexible.

Answer 2

Como dijo, los ejemplos tienden a involucrar la invocación directa. En mi experiencia, esos no son solo los ejemplos. Ninguna de las aplicaciones Java EE * 1 que he visto utiliza un gráfico de objetos vivientes largos como el que describe, en su lugar, normalmente funcionan en un solo registro (+ hijos/relacionados) en respuesta a una solicitud web, llamada al servicio web o mensaje JMS .

Sus requisitos rompen ese molde y Java EE puede no ser la mejor opción. A su valor nominal, el tipo de código que describes pertenece al Contenedor EJB, pero ese contenedor carece de un buen contexto de larga duración para anclar tu gráfico objeto. El contenedor web tiene ese contexto, pero carece de facilidades para temporizadores y manejo de mensajes, y tal. El costo de abandonar J2EE y usar una aplicación Java simple en su lugar es, por supuesto, perder las instalaciones del servidor de aplicaciones para administración, implementación y monitoreo.

Una buena opción podría ser volver a lo que hizo que el Spring Framework sea grande. No sé si está familiarizado con la historia de J2EE, pero la repentina y enorme popularidad de Spring Framework e Hibernate fue esencialmente una rebelión comunitaria contra el contenedor EJB, versiones 1.x/2.x. Lo que Spring WebApplicationContext le dio fue un sólido back-end transaccional para una aplicación web, aprovechando los MDB y JTA mientras ignoraba la mayor cantidad posible de Contenedor EJB * 2 (y simplificaba enormemente las pruebas unitarias en el proceso). Podrías tomar este enfoque y construir tu aplicación como un único archivo WAR y arrancar tus servicios de back-end con Spring.

Una alternativa interesante es deshacerse por completo del servidor de aplicaciones Java EE y construir su aplicación sobre el marco OSGi. Este es el enfoque de la "aplicación Java normal", con el tiempo de ejecución OSGi que le brinda la consola de administración y las funciones de implementación en caliente que de otro modo tendría que transferir. Los bits faltantes de la infraestructura son el temporizador (use Quartz) y los beans controlados por mensaje (use la API JMS directamente). Una aplicación OSGi termina sintiéndose un poco como el kernel de Linux y el proceso de arranque, con servicios implementados e iniciados según los niveles de ejecución. Agarra Apache Felix y échale un vistazo.

No mencionó la escala. Si el gráfico de objetos es enorme, busque tecnologías como GigaSpaces o Coherence.

** 1) Sun tomó el '2' de la sigla con la introducción de EJB3 *

** 2) 2.x EJBs de entidad eran la peor parte. EJB 3 se puede ver como un esfuerzo mayormente "si no puedes vencerlos, únete a ellos" para estandarizar Hibernate. *