servidor novedades instalar descargar aplicaciones animal java tomcat java-ee application-server

java - novedades - tomcat animal



Además de EAR y EJB, ¿qué obtengo de un servidor de aplicaciones Java EE que no obtengo en un contenedor de servlets como Tomcat? (5)

Usamos Tomcat para alojar nuestras aplicaciones basadas en WAR. Somos aplicaciones J2EE compatibles con el contenedor de servlet con la excepción de org.apache.catalina.authenticator.SingleSignOn.

Nos piden que nos cambiemos a un servidor de aplicaciones comercial Java EE.

  1. La primera desventaja de cambiar que veo es el costo. Sin importar cuáles sean los cargos para el servidor de aplicaciones, Tomcat es gratuito.
  2. El segundo es la complejidad. No usamos las funciones EJB ni EAR (por supuesto que no, no podemos), y no las hemos omitido.

¿Cuáles son entonces los beneficios que no estoy viendo?

¿Cuáles son los inconvenientes que no he mencionado?

Mencionado fueron ...

  1. JTA - Java Transaction API - Controlamos la transacción a través de procedimientos almacenados en la base de datos.
  2. JPA - API Java Persistence - Usamos JDBC y nuevamente procedimientos almacenados para persistir.
  3. JMS - Java Message Service: utilizamos XML a través de HTTP para enviar mensajes.

Esto es bueno, por favor más!

A menos que desee EJB correctamente, no necesita un servidor J2EE de pila completa (comercial o no).

Puede tener la mayoría de las características J2EE (como JTA, JPA, JMS, JSF) sin un servidor J2EE de pila completa. El único beneficio de una j2ee completa es que el contenedor administrará todo esto en su nombre de manera declarativa. Con la llegada de EJB3, si necesita servicios administrados por contenedor, usar uno es algo bueno.

También puede tener un servidor de pila completa sin costo, como Glasfish, Geronimo o JBoss.

También puede ejecutar servicios administrados de contenedor j2ee incrustados con Glasfish incrustado, por ejemplo, dentro de Tomcat.

Es posible que desee un contenedor EJB si desea utilizar beans de sesión, beans de mensaje, beans de temporizador bien administrados, incluso con clustering y fail over.

Sugeriría a la gerencia que considere las actualizaciones basadas en la necesidad de funciones. Algunos de estos contenedores EJB podrían usar Tomcat integrado como su servidor web, ¡así que qué ofrece!

Algunos gerentes solo quieren pagar por las cosas. Pídales que consideren la donación de un refugio de la ciudad o simplemente vayan a BEA.

Cuando partimos con el objetivo de certificar a Java EE 6 Apache Tomcat como Apache TomEE , estos son algunos de los vacíos que tuvimos que completar para aprobar finalmente el Java EE 6 TCK.

No es una lista completa, sino algunos aspectos destacados que pueden no ser obvios incluso con las respuestas existentes.

Sin TransactionManager

La gestión de transacciones es definitivamente necesaria para cualquier servidor certificado. En cualquier componente web (servlet, filter, listener, jsf managed bean) deberías poder obtener una UserTransaction inyectada así:

  • @Resource UserTransaction transaction;

Debería poder usar javax.transaction.UserTransaction para crear transacciones. Todos los recursos que toque en el alcance de esa transacción deberían estar inscritos en esa transacción. Esto incluye, pero no se limita a, los siguientes objetos:

  • javax.sql.DataSource
  • javax.persistence.EntityManager
  • javax.jms.ConnectionFactory
  • javax.jms.QueueConnectionFactory
  • javax.jms.TopicConnectionFactory
  • javax.ejb.TimerService

Por ejemplo, si en un servlet inicia una transacción, entonces:

  • Actualiza la base de datos
  • Disparar un mensaje JMS a un tema o cola
  • Crea un temporizador para hacer el trabajo en algún punto posterior

.. y luego una de esas cosas falla o simplemente eliges llamar a rollback() en UserTransaction , luego todas esas cosas se deshacen.

Sin agrupación de conexiones

Para ser muy claros, hay dos tipos de agrupación de conexiones:

  • Conjunto de conexiones con conexión transaccional
  • Agrupación de conexiones no transaccionalmente consciente

Las especificaciones de Java EE no requieren estrictamente la agrupación de conexiones; sin embargo, si tiene una agrupación de conexiones, debe tener en cuenta las transacciones o perderá la administración de transacciones.

Lo que esto significa es básicamente:

  • Todos en la misma transacción deben tener la misma conexión del grupo
  • La conexión no se debe devolver al grupo hasta que la transacción se complete (confirmación o reversión) independientemente de si alguien llamó close() o cualquier otro método en el DataSource .

Una biblioteca común utilizada en Tomcat para la agrupación de conexiones es commons-dbcp. También queríamos usar esto en TomEE, sin embargo, no era compatible con la agrupación de conexiones con reconocimiento de transacciones, por lo que realmente agregamos esa funcionalidad a commons-dbcp (yay, Apache) y está ahí desde commons-dbc versión 1.4.

Tenga en cuenta que agregar commons-dbcp a Tomcat aún no es suficiente para obtener la agrupación de conexiones transaccionales. Aún necesita el administrador de transacciones y aún necesita el contenedor para realizar la instalación de las conexiones de registro con el TransactionManager través de los objetos de Synchronization .

En Java EE 7 se habla de agregar una forma estándar de cifrar contraseñas de BD y empaquetarlas con la aplicación en un archivo seguro o en un almacenamiento externo. Esta será una característica más que Tomcat no admitirá.

Sin integración de seguridad

La seguridad de WebServices, el JAX-RS SecurityContext, la seguridad de EJB, el inicio de sesión de JAAS y JAAC son conceptos de seguridad que, por defecto, no están "conectados" en Tomcat incluso si se agregan bibliotecas como CXF, OpenEJB, etc.

Por supuesto, se supone que estas API trabajan juntas en un servidor Java EE. Hubo bastante trabajo que tuvimos que hacer para que todo esto cooperara y lo hiciera sobre la API de Tomcat Realm para que las personas pudieran usar todas las implementaciones existentes de Tomcat Realm para impulsar su seguridad "Java EE". Realmente es la seguridad de Tomcat, está muy bien integrada.

Integración JPA

Sí, puede colocar un proveedor de JPA en un archivo .war y usarlo sin la ayuda de Tomcat. Con este enfoque no obtendrás:

  • @PersistenceUnit EntityManagerFactory inyección / búsqueda
  • @PersistenceContext EntityManager Inyección / búsqueda de @PersistenceContext EntityManager
  • Un EntityManager conectado a un grupo de conexiones con EntityManager de transacciones
  • Soporte de EntityManager administrado por EntityManager
  • Contextos de persistencia ampliados

JTA-Managed EntityManager significa básicamente que dos objetos en la misma transacción que desean usar un EntityManager verán el mismo EntityManager y no es necesario pasar explícitamente el EntityManager . Todo este "paso" lo realiza el contenedor.

¿Cómo se logra esto? Simple, el EntityManager que EntityManager del contenedor es falso. Es un envoltorio. Cuando lo usa, busca en la transacción actual para el EntityManager real y delega la llamada a ese EntityManager . Esta es la razón del misterioso método EntityManager.getDelegate() , por lo que los usuarios pueden obtener el EntityManager real si lo desean y hacer uso de cualquier API no estándar. Hágalo con gran cuidado, por supuesto, y nunca guarde una referencia al delegado EntityManager o tendrá una fuga de memoria grave. El delegado EntityManager normalmente se EntityManager , cerrará, limpiará y desechará cuando se complete una transacción. Si aún conserva una referencia, evitará la recolección de basura de ese EntityManager y posiblemente todos los datos que contenga.

  • Siempre es seguro mantener una referencia a un EntityManager que obtuvo del contenedor
  • No es seguro mantener una referencia a EntityManager.getDelegate()
  • Tenga mucho cuidado con una referencia a un EntityManager que creó usted mismo a través de una EntityManagerFactory : usted es 100% responsable de su gestión.

Integración CDI

No quiero simplificar demasiado el CDI, pero me parece demasiado grande y mucha gente no lo mira con seriedad. Está en la lista de "algún día" para mucha gente :) Así que aquí hay solo un par de detalles que Creo que un "chico de la red" querría saber.

¿Sabes todo lo que te pones y haces en una aplicación web típica? ¿Sacando cosas de HttpSession todo el día? Usando String para la clave y continuamente lanzando objetos que obtienes de HttpSession . Probablemente vayas con el código de utilidad para hacer eso por ti.

CDI también tiene este código de utilidad, se llama @SessionScoped . Cualquier objeto anotado con @SessionScoped se coloca y rastrea en HttpSession por usted. Usted solo solicita que el objeto sea inyectado en su Servlet a través de @Inject FooObject y el contenedor CDI rastreará la instancia "real" de FooObject de la misma manera que yo describí el rastreo transaccional de EntitityManager . Abracadabra, ahora puedes borrar un montón de código :)

Hacer cualquier getAttribute y setAttribute en HttpServletRequest ? Bueno, puedes eliminar eso también con @RequestScoped de la misma manera.

Y, por supuesto, está @ApplicationScoped para eliminar las llamadas getAttribute y setAttribute que podría estar haciendo en ServletContext

Para hacer las cosas aún más @PostConstruct , cualquier objeto rastreado como este puede implementar un @PostConstruct que se invoca cuando se crea el bean y un método @PreDestroy para ser notificado cuando dicho "alcance" finaliza (la sesión finaliza, la solicitud termina, la aplicación se está cerrando).

CDI puede hacer mucho más, pero eso es suficiente para que cualquiera quiera volver a escribir una vieja aplicación web.

Algunas cosas exigentes

Hay algunas cosas agregadas en Java EE 6 que están en la caseta de gobierno de Tomcats que no fueron agregadas. No requieren grandes explicaciones, pero explican una gran parte del "relleno de las lagunas".

  • Soporte para @DataSourceDefinition
  • Soporte para Global JNDI ( java:global , java:app , java:module )
  • Inyección de Enum a través de @Resource MyEnum myEnum y
  • Inyección de clase a través de @Resource Class myPluggableClass y
  • Soporte para @Resource(lookup="foo")

Puntos menores, pero puede ser increíblemente útil definir DataSource en la aplicación de una manera portátil, compartir entradas JNDI entre webapps, y tener el poder simple de decir "mira esto e instálalo"

Conclusión

Como se mencionó, no es una lista completa. No se mencionan EJB, JMS, JAX-RS, JAX-WS, JSF, Validación de frijoles y otras cosas útiles. Pero al menos una idea de las cosas que a menudo se pasan por alto cuando las personas hablan sobre lo que Tomcat es y lo que no es.

También tenga en cuenta que lo que podría haber pensado como "Java EE" podría no coincidir con la definición real. Con el perfil web, Java EE se ha reducido. Esto fue deliberadamente para abordar "Java EE es demasiado pesado y no necesito todo eso".

Si eliminas a EJB del perfil web, esto es lo que te queda:

  • Servlets de Java
  • Java ServerPages (JSP)
  • Java ServerFaces (JSF)
  • Java Transaction API (JTA)
  • API Java Persistence (JPA)
  • Injertos de Java e Inyección de Dependencia (CDI)
  • Validación de frijol

Es una pila muy útil.

El costo no es necesariamente un inconveniente ya que hay algunos servidores J2EE gratuitos, por ejemplo, JBoss y Glassfish.

Su pregunta asume que (J2EE = Servlet + EJB + EAR) y, por lo tanto, no tiene sentido usar nada más que un contenedor de servlet si no está utilizando EJB o EAR. Simplemente, este no es el caso, J2EE incluye mucho más que esto. Ejemplos incluyen:

  • JTA - API de transacción de Java
  • JPA - API de persistencia de Java
  • JMS: especificación de mensajería Java
  • JSF: tecnología para construir interfaces de usuario sin componentes

Saludos, Donal

En verdad, con la gran variedad de paquetes y bibliotecas disponibles, hay poco que proporciona un contenedor EJB que no se pueda agregar a un contenedor de servlet moderno (como Tomcat). Entonces, si alguna vez quisiste alguna de esas características, puedes obtenerlas a "carta", por así decirlo, siendo el costo el proceso de integración de esa función en tu aplicación.

Si no "pierde" ninguna de estas características ahora, entonces, desde un punto de vista práctico, es probable que no las necesite.

Dicho todo esto, los modernos contenedores EJB son realmente agradables, y vienen con todos esos servicios preintegrados, haciéndolos, de alguna manera, más fáciles de usar si alguna vez los quisieran. A veces, tener la función cerca y útil es suficiente para que alguien la explore por su potencial en su aplicación, en lugar de ver el proceso de integración de una característica como un obstáculo para la adopción.

Con la calidad de los contenedores EJB gratuitos, es realmente difícil imaginar cómo comprar uno puede ser útil, especialmente teniendo en cuenta que no tiene una demanda real de uno en este momento.

Sin embargo, sí lo animo a que obtenga uno y juegue con él y explore la plataforma. Glassfish es muy fácil de usar y muy bueno, y debe tomar tus WARs como está (o con ajustes muy pequeños).

Como regla, cuando se trata de ejecutar Tomcat frente a un contenedor EJB, la pregunta es, ¿por qué NO utilizar uno? Hablando específicamente para Glassfish, me resulta más fácil de usar que Tomcat, y su principal diferencia es que puede tener un tamaño de memoria moderadamente más grande (particularmente para una pequeña aplicación) que Tomcat, pero en una aplicación grande ni siquiera notarás que . Para mí, el golpe de memoria no es un gran problema, para otros puede ser un problema.

Y me da una fuente única de toda esta funcionalidad agradable sin tener que rastrear la red para una opción de terceros.

Si se le solicita que se mude a un servidor J2EE comercial, las razones pueden no tener nada que ver con la pila J2EE, pero con consideraciones no técnicas.

Una cosa que obtienes con una oferta comercial de J2EE que no obtienes con Tomcat es el soporte técnico.

Esto puede no ser una consideración para usted, dependiendo de los niveles de servicio que supuestamente deben cumplir sus aplicaciones web. ¿Tus aplicaciones pueden estar caídas mientras intentas resolver un problema con Tomcat, o será un gran problema?