| (Anterior) EAR's y Deployment Descriptors |
| Messaging Beans (Siguiente) |
|
Surgimiento y Consideraciones .
El surgimiento de CMP "Entity Beans" además de la generación del código automático de acceso (JDBC) tiene sus raíces en las diversas empresas que apoyan EJB's, específicamente aquellas que desarrollan EJB's para terceros ("ISV" Independent Software Vendors). Suponga que su empresa ha desarrollado un "proceso lógico" en "Entity EJB's" lo suficientemente productivo que decide comercializarlo a otras empresas en el ramo, en este caso la portabilidad de Java hacia diversos Application Servers no es suficiente, por la simple razón que no sabe como esta definido el modelo de datos en otras empresas.
Una solución a este problema sería distribuir el código fuente de cada "Entity EJB" para ser modificado, sin embargo , esto no sólo daría acceso total a un proceso que pudo costar miles de dolares en refinar sino que también haría difícil el actualizar dichos "Entity EJB's" en versiones futuras debido a la falta de control en código fuente.
A través de CMP "Entity Beans" es posible dividir efectivamente la lógica de negocios del EJB del acceso al depósito de información, en efecto ofreciendo la posibilidad de distribuir binarios de EJB's con la facilidad de definir acceso a Bases de Datos transparentemente, sin embargo, esta transparencia no es del todo gratis.
SuperClase/SubClase, "Abstract Schema" y EJB-QL.
La primer distinción entre un BMP y CMP "Entity Bean" es que la clase principal del EJB en sí (aquella que contiene la implementación) esta subdividida en dos : una SuperClase definida por el programador del EJB y una SubClase que es generada por el Application Container/"EJB Container", las diferencias entre ambas serán descritas en el siguiente ejemplo; vale mencionar que esta subdivisión de clases es algo especifico de EJB 2.0 -- en EJB 1.1 esta subdivisión no existía.
La generación de código automático para accesar el deposito de información debe surgir de ciertas definiciones forzosamente, puesto que como sabrá el Application Server/"EJB Container" que la función insertarSaldo es distinta de insertarNombre ? o que la función cuentaBancaria se refiere a la tabla llamada tarjetahabientes ?, esta tarea recae sobre lo que es conocido como "Abstract Schema" el cual será descrito en el ejemplo que continua.
La última diferencia entre "CMP" y "BMP" se debe a una cualidad especifica de un "Entity EJB" que son los métodos de búsqueda; al implementarse estos métodos de búsqueda en "BMP" se define la lógica directamente, sin embargo, surge la misma incógnita mencionada anteriormente: Como sabe el Application Server/"EJB Container" que significa findPorApellido ? o findByPrimaryKey ? para esto se utiliza EJB-QL ("Enterprise Java Bean-Query Language") que también será descrito en la siguiente sección.
La codificación del siguiente "CMP Entity EJB" esta basado en el mismo contexto del "BMP Entity EJB" descrito anteriormente, esto con la intención que sean ilustradas las diferencias entre ambas alternativas.
Creación de Interfases ("Home Interface" y "Remote Interface").
Las interfases utilizadas para CMP EJB's son idénticas a las utilizadas en BMP EJB's, esto permite alternar entre implementaciones de CMP y BMP puesto que el cliente (JSP/Servlet/Applet/Programa de Terminal) interactúa únicamente con dichas interfases; una variación que puede ser empleada para interfases es la utilización de interfases locales ("Local Interfaces"), aunque su uso no es exclusivo de "Entity Beans" es una buena opción para ciertos diseños, sin embargo, para este "Entity CMP" se utilizarán las interfases clásicas, el uso de Interfases Locales ("Local Interfaces") será descrito en otra sección de este curso.
- "RemoteInterface" CuentaBancariaCMP.java
- "HomeInterface" CuentaBancariaHomeCMP.java
- Clase auxiliar SaldoInsuficiente.java
Creación del EJB ("CuentaBancaria").
La clase que implementa un "CMP Entity EJB" a diferencia de aquella empleada en un "BMP Entity EJB" se encuentra prácticamente nula de código, la generación de éste es delegado al Application Server/"EJB Container". Como fue mencionado anteriormente, este código es colocado en una SubClase, sin embargo, para el programador del EJB el contenido final de esta SubClase no debe influenciar en ningún aspecto.
A continuación se describe la implementación de la SuperClase empleada por el "CMP Entity EJB".
Deployment Descriptor del EJB.
En "CMP Entity Beans" el uso del Deployment Descriptor toma mayor importancia debido a que es aquí donde se define la lógica de acceso hacia la Base de Datos, dicha lógica es definida a través de lo que es conocido como Abstract Schema el cual es descrito en el siguiente "Deployment Descriptor":
Otro detalle relevante es el mapeo Objeto/Relacional que debe ser llevado acabo para el "CMP EJB", en JBoss este mapeo se lleva acabo a través de JAWS y un archivo de configuración; otros Application Servers/"EJB Containers" utilizan herramientas similares para realizar este mapeo las cuales fueron mencionadas en la sección inicial de "Entity EJB's".
Finalmente para este "CMP EJB" se utilizará un archivo de configuración especifico a JBoss que permite alterar el nombramiento JNDI que es otorgado a EJB's.
Creación del Cliente.
A continuación se diseñan los Clientes que interactúan con el "CMP EJB", las operaciones que realizan son muy similares a aquellas utilizadas en el "BMP EJB" salvo la diferencia de nombre JNDI otorgado al "CMP EJB" la interacción es igual.