Qué puedes hacer con EJB3 (Primera Parte)

El artículo original en inglés puede encontrarse aquí, y su traducción original realizada por Nicolas Cornaglia y cedida generosamente a jugar, puede encontrarse aquí.

Ahora que el primer borrador de EJB 3.0 está publicado, definitivamente es el momento para dejar atrás toda la política reciente, y comenzar a pensar lo que podemos hacer realmente con todo esto. EJB es el único estándar Java que se ocupa de la lógica de negocio del lado del servidor, y esto es fundamental para J2EE. El comité de especificación de EJB reconoce que EJB se ha quedo corto en alcanzar algunas de sus ambiciosas metas, y necesita una modernización. Esta modernización está muy enfocada en la facilidad de uso, principalmente mediante la simplificación de los requerimientos de los implementadores de beans. Sin embargo, el comité de especificación también ha identificado un número de mejoras funcionales críticas que facilitan el uso y la eliminación de ciertos anti-patrones J2EE.

Afortunadamente, la comunidad Java conoce ahora mucho mas los problemas relacionados a la construcción de aplicaciones web y empresariales que hace cinco años. Hemos "aprendiendo haciendo". Una forma poderosa, fácil de utilizar y estándar de construir objetos de negocio del lado del servidor ahora esta mas a nuestro alcance!

El comité de especificación pensó mucho como simplificar ciertos casos de usos extremadamente comunes, especialmente dos casos que especificaré a continuación:
Actualizando datos

  1. Recuperar un dato
  2. Mostrarlo en pantalla
  3. Aceptar la entrada del usuario
  4. Actualizar el dato
  5. Comunicar el éxito al usuario

Ingresando nuevos datos
  1. Recuperar un dato
  2. Mostrarlo en pantalla
  3. Aceptar la entrada del usuario
  4. Crear un nuevo dato, con una asociación al primer dato
  5. Comunicar el éxito al usuario

Cada uno de estos casos involucra dos ciclos request/response de aplicación completos. Ambos demuestran que el bloqueo optimista es esencial en una aplicación que requiere alta concurrencia (ambos casos necesitarían ser implementados como una sola comunicación atravesando dos transacciones ACID de base de datos/JTA distintas).

Un caso de uso adicional muy común, que es especialmente difícil de hacer en EJB 2.1, dadas las limitaciones del lenguaje de consultas es el siguiente:
Listando datos

  1. Recuperar una lista de datos sumarizada o agrupada
  2. Mostrarla al usuario

Finalmente, consideramos dos arquitecturas físicas reconocidas. El caso co-localizado - al que consideramos mas importante, al menos para aplicaciones web típicas - tiene una capa de presentación actuando como cliente local de la capa de negocio. El caso remoto tiene un cliente remoto (por ejemplo, un motor de servlets o un cliente swing ejecutándose en diferentes capas físicas) accediendo a la capa de negocio.

Primero necesitamos datos. La interacción con datos relacionales es fundamental en casi cualquier aplicación web o empresarial. Las aplicaciones que implementan lógica de negocio no trivial se benefician de una representación orientada a objetos de los datos (un modelo de dominio) que tiene todos los beneficios de las técnicas de orientación a objetos como herencia y polimorfismo. Por varias razones (No quiero repetir los argumentos que he expresado largamente en Hibernate in Action), aplicaciones que usan modelos de dominio totalmente orientados a objetos necesitan una solución automatizada al problema de adaptación OR. EJB3 incorpora una especificación ORM muy sofisticada que se basa fuertemente en la experiencia en CMP 2.1, Hibernate y TopLink de Oracle.

Ver artículo completo en: http://www.cricava.com/java/detalleArticulos.php?id=407