java - libreria - para que sirve el ejb
Las mejores características de EJB 3 (6)
Bueno, esto realmente depende de qué EJB estamos hablando. Diría que los MDB aún pueden ser útiles incluso ahora. Para beans de entidad y beans de sesión seguramente puede encontrar un mejor enfoque. Tal vez una característica que todavía me gusta en EJB es la escalabilidad. Usando la opción "remota" puede implementar EJB en diferentes servidores si es necesario. Sin embargo, no creo que esto sea realmente necesario, y solo he visto un gran proyecto en el que fue realmente útil.
El escenario
- Ha desarrollado una aplicación web con EJBs versión 3.
- El sistema se implementa, entrega y es utilizado por el cliente.
Si tuviera que volver a escribir el sistema desde cero, ¿usaría EJB nuevamente?
No : no responda esta pregunta, responda esta en su lugar.
Sí : proporcione un problema importante y real que los EJB resuelvan, en función de su experiencia personal.
Deje que la respuesta contenga solo un problema. Esto permitirá que otros lectores voten por la mejor característica de los EJB.
Convención sobre configuración.
El comportamiento predeterminado de EJB 3 es más a menudo el deseado. Creo que el principal problema con EJB 2.1 fue la necesidad de los archivos de configuración detallados, la nueva configuración basada en anotaciones resuelve la mayor parte de este problema.
Creo que depende de la versión de los EJB de la que estés hablando. Discutamos las únicas dos versiones relevantes (IMO).
EJB 2.1 aún podría ser utilizado por algunas personas en un sistema heredado. Realmente tienen el mayor uso como abstracción RPC. También proporcionaron un sistema rudimentario ORM (Object Relational Mapping) también. Y como mencionó, se proporciona soporte de transacciones. Entonces, si estuviera construyendo un sistema en el que quisiera comunicarse con un sistema remoto, transfiera datos orientados a objetos y lo haga de forma transaccional, puede encontrar que los EJB valen la pena. De lo contrario, yo diría que se mantenga alejado.
EJB 3.0, sin embargo, se ha mejorado mucho. Tiene todas las características de la versión anterior, pero lo hace de una manera más directa. También proporciona un marco de Inversión de control bastante simple, similar a Spring, y un ORM bastante decente en forma de JPA (Java Persistence API). He utilizado EJB 3.0 y en realidad lo disfruté. Podría argumentar a favor del uso de EJB 3.0 de la misma manera que lo haría para Spring, además de que tiene algunas características más avanzadas o de enterprise-y disponibles.
Hice mucho trabajo en el pasado con EJB 2.1, feliz de dejarlo atrás.
La propuesta de valor EJB sigue siendo cierta para 3.0, y tiene un buen modelo de programación ligera. La gestión de transacciones, la concurrencia, el control de versiones de datos, la gestión del estado, estos son problemas no triviales para resolver correctamente y los marcos de Java EE continúan haciendo un excelente trabajo.
Es cierto que utilizo Hibernate y Seam para seguir desarrollando algunas de las características de Java EE, por lo que no es estrictamente justo para mí decir que EJB 3.0 es la meca. Sin embargo, hay demasiados desarrolladores que arrojan al proverbial bebé con el agua de la bañera cuando abandonan por completo a Java y pasan a algo más moderno como Rails.
Seam proporciona un buen marco de pegamento que mantiene la cantidad de esfuerzo del programador bastante baja. También le permite decidir proyecto por proyecto cuando EJB tiene sentido versus POJOs, SIN tener que cambiar su estilo de programación.
Una cosa que ha picado a muchos al usar EJB, o J2EE en general, es la dependencia del servidor de aplicaciones en el que está ejecutando sus EJB. El servidor de aplicaciones tiende a ser compatible con un conjunto particular de versiones de sistemas operativos y versiones de JVM. No tener el código fuente en una parte importante de su entorno de tiempo de ejecución también podría convertirse en un desafío.
Si bien, en principio, es posible migrar de un proveedor a otro, debe ser muy consciente de las pequeñas diferencias en la forma de implementar la especificación y mantenerse alejado de las extensiones específicas del proveedor.
Dicho esto, los servidores de aplicaciones a los que he estado expuesto pueden manejar mucho el abuso del código que se ejecuta en él y funcionar muy bien.
la razón principal para usar la plataforma java ee es por definición. necesita una plataforma que resuelva los problemas de concurrencia, disponibilidad, gestión de transacciones, mensajería y administración en una plataforma totalmente comprobada, compatible y compatible. sí, puede hacerlo todo usted mismo combinando una gran cantidad de bibliotecas y colocándolas encima de tomcat, pero ¿por qué desperdiciar todo ese tiempo examinando y administrando la compatibilidad y el conjunto de características cuando puede escribir en una plataforma que hace cumplir las normas y que es totalmente revisada? cualquier contenedor ee DEBE pasar el tck o no puede transportar el monicker Java EE.
las cosas que varias personas plantean sobre "peso ligero", "tipos" de ejbs, etc. son superfluas. si no necesita el conjunto de características de la plataforma o la garantía de la compatibilidad intra completa de sus bibliotecas apalancadas, entonces ejb (también conocido como la plataforma java ee) es excesivo. pero si realmente está resolviendo un problema de calidad empresarial (consulte el primer párrafo), entonces el ejb y la plataforma java ee le brindarán lo que necesita.