¿Cuáles son las principales razones para usar Java EE (EJB) con una simple implementación de Servlet?Ventajas y desventajas de Java EE frente a los servlets
Estoy trabajando en el desarrollo de un nuevo proyecto que será principalmente un servicio web que debe ser muy rápido y escalable.
Disculpe las posibles confusiones, aunque tengo experiencia en Java, soy muy nuevo en el mundo de la Web de Java y es posible que no haga bien esta pregunta.
Los servlets son oyentes de solicitud HTTP; no pueden responder a nada más.
Si incorpora una gran cantidad de lógica en servlets, no estará disponible para ningún otro cliente.
Escriba su aplicación en POJOs. Haz que sea probado exhaustivamente sin un servidor de aplicaciones involucrado. Luego, preocúpese de cómo desea empaquetarlo e implementarlo. Servlet? EJB? ¿Servicio web? ¿Algo más? No hay problema, esos son solo problemas de empaque y despliegue. Obtenga primero el comportamiento que desea que funcione correctamente en POJO.
Spring puede darte un montón de opciones aquí. Lo recomendaría.
Los EJB en estos días son más o menos POJO, POJO + alguna anotación y pueden tener molestas interfaces RMI y de servicios web. Usar algo como Spring (o EJB 3 ;-) es un buen consejo. – djna
Es cierto acerca de EJB3. Open EJB hace posible ejecutarlos sin WebLogic o WebSphere, pero aún prefiero Spring. – duffymo
Gracias, me gusta su consejo sobre comenzar en POJO, y luego preocuparse por el paquete del servidor web. Eso suena como un gran plan, y es bueno saber que no es demasiado doloroso empaquetarlo para diferentes contenedores. –
¿El servicio web es sin estado? Si es así, no veo ninguna ventaja real al usar un servidor Java EE completo sobre algo ligero como Tomcat o Jetty. Puede implementar una implementación de jax-ws con cualquiera de ellos y hacer lo que necesita con bastante facilidad. Si hay algún tipo de estado involucrado, y terminas queriendo compartir eso en múltiples máquinas, es ahí donde tener Java EE puede ser útil.
Dicho esto, no creo que Java EE disminuya el rendimiento en absoluto. Los servidores de aplicaciones generalmente tardan más en arrancar y requieren más esfuerzo para administrarlos, pero una vez que estén funcionando, el rendimiento debería ser similar.
Acepto que los servidores de aplicaciones JEE agruparán las soluciones muy bien, pero esa no es la única razón para usarlas. Normalmente, los servicios web deberían ser apátridas (o no conversacionales) y, por lo tanto, el estado no es un controlador común para usar JEE. Creo que vemos la seguridad a nivel de método y los requisitos transaccionales no triviales como controladores más fuertes hacia las soluciones JEE EJB completas – djna
> 'Los servidores de aplicaciones generalmente tardan más en arrancar': Avance rápido 3 años, y ahora los servidores de aplicaciones tardan aproximadamente tanto tiempo en bota. JBoss AS 7, GlassFish V3, TomEE y Resin son todos uno o dos segundos. Incluso WebLogic está a solo unos segundos;) –
Si sus servicios web es probable que necesiten algún grado de características "empresariales", como seguridad por método o transacciones, utilice EJB.
Con EJB 3 esto no es muy difícil en absoluto, un par de anotaciones y listo.
De lo contrario, los POJO simples detrás de un servlet son suficientes.
"... Si sus servicios web es probable que necesiten algún grado de características" empresariales "como seguridad por método o transacciones, utilice EJB ..." - no es cierto en absoluto si estás usando Spring. Puede hacer ambas cosas y mucho más sin EJB. – duffymo
Sí, tienes razón acerca de Spring. ¿Está de acuerdo en que técnicamente podemos hacer servicios web con JEE, POJO, servlets listos para usar, pero para algunos requisitos nos beneficiaríamos de Spring? ¿Serían cosas como la seguridad y las transacciones por método dos de esos requisitos? – djna
La especificación 1.x y 2.x de EJB agregaba complejidad que para la mayoría de las aplicaciones web no era necesaria.
Debido a esta complejidad, los nuevos marcos parecían simplificar el desarrollo y la arquitectura de tiempo de ejecución (Hibernate/Spring/otros microcontenedores/otros marcos ORM).
EJB's 3.x coincide con estos cambios (a través de JDO y JPA) y ahora, usar servlets con estos marcos mejorados o Java EE con EJB 3 + le dará básicamente los mismos resultados.
El uso de un Servidor de aplicaciones Java EE le agregaría una serie de ventajas administrativas (GUI para administrar pools, registros, monitoreo, transacciones, etc.). Con ellas, puede obtener el mismo resultado pero debería hacerlo todo mano (es decir, editar archivos de configuración) Lo cual puede no parecer demasiado problemático, pero si planea tener un administrador para su aplicación web Sería mejor utilizar las herramientas de administración que vienen de la caja con estos servidores.
Gracias Oscar, ese es un buen consejo sobre las ventajas administrativas. –
Como los servlets y los servicios web forman parte de la especificación J2EE, no estoy 100% seguro de lo que está preguntando aquí ... Todo esto suena bastante parecido a "la sobrecarga adicional de HTML" causa un notable disminución en el rendimiento de mi sitio web? – ChssPly76
comparado con qué? ¿Con qué requisitos? Esta no es una pregunta muy bien pensada. Y los servlets son parte de J2EE ... –
Esto puede no estar bien redactado, pero está haciendo una buena pregunta. Existen al menos dos formas JEE de implementar un servicio web, como un POJO expuesto a través de un servlet eficaz y como un EJB que puede exponer una interfaz de servicio web. Hay ventajas para ambos. – djna