Otros Conceptos

Transacciones y JTS/JTA

Las transacciones juegan un papel muy importante en cualquier sistema de cómputo y en EJB's no son la excepción ; a través de transacciones es posible garantizar la integridad de ciertas operaciones llevadas acabo en un sistema; esta integridad es la parte fundamental ofrecida por una base de datos también denominada prueba del "ACIDo" ("Atomicity-Consistency-Isolation-Durability").

Omitiendo una gran cantidad de datalles, una Transacción es la que permite:

No sea enviado un producto hasta que haya sido actualizado el Inventario del mismo.
Al intentarse abonar "x" cantidad de dinero ésta no sea realizada hasta que se haya realizado la respectiva deducción de otra cuenta.
Actualizar diversos depósitos de información al mismo tiempo.

En términos más triviales una transacción representa un todo o nada, es decir, o se realizan todos los pasos definidos en ésta o no se realiza ninguno; en un EJB las transacciones son definidas en el "Deployment Descriptor" para cada método a ser ejecutado, esto permite que si ocurre algún error ("Exception") dentro del método todas sus acciones sean invalidadas, esto es conocido como "Rollback".

Por lo general todas las transacciones en un EJB son definidas a través del parámetro REQUIRED, esto implica que al invocarse el método se inicie una transacción exclusiva para éste, el definir una transacción como REQUIRED es una manera muy segura de mantener la integridad de información, sin embargo, es conveniente saber que una transacción puede recibir otros parámetros que se mencionan a continuación:

REQUIRESNEW: Este tipo de parámetro permite al método en cuestión crear una transacción exclusiva; al utilizarse REQUIRED si ya existe una transacción de por medio y ocurre un error ("Exception") todas las operaciones tanto del método en cuestión así como las del que inicio la transacción serán retractadas ("Rolledbacked"); al utilizarse REQUIRESNEW se evita este comportamiento "anidado" de transacciones.
SUPPORTS: Esta transacción permite al método del EJB participar en una transacción siempre y cuando el cliente ( JSP/Servlet/Applet ) la haya iniciado, de otra manera no participa en ninguna transacción.
MANDATORY: A través de MANDATORY se le indica al método que debe existir una transacción en progreso, si no existe el "Application Server/EJB Container" genera un error (javax.ejb.TransactionRequiredException)
NOTSUPPORTED: Indica que el método no participará en ninguna transacción, en dado caso de encontrarse una transacción en progreso será suspendida y reanudada una vez que el método sea invocado.
NEVER: Permite que un método jamás participe en una transacción, inclusive si el cliente (JSP/Servlet) llama este tipo de métodos cuando esta en proceso una transacción se genera un error.

El uso de cualquiera de los parámetros anteriores para Transacciones en EJB's no se recomienda al menos que haya sido realizado un análisis exhausto acerca de sus consecuencias en el EJB.

JTS/JTA

JTS "Java Transaction Service" y JTA "Java Transaction API" son un juego de librerías ("packages") utilizadas en el lenguaje Java para definir transacciones programáticamente, esto es, definir manualmente el uso de transacciones; JTS es el API utilizado por los diversos vendedores, éste rara vez es utilizado por un programador al diseñar aplicaciones; JTA puede ser utilizado para definir transacciones en cualquier programa Java, sin embargo, su uso para aplicaciones de EJB's y sus clientes (JSP/Servlets) es fuertemente desanimado.

Lo anterior se debe que al ser definida una transacción programáticamente (manualmente) se pueden generar resultados inesperados, que varían desde operaciones congeladas ("deadlocks") hasta los efectos de propagación que pueda tener la transacción en todo el sistema; además de lo anterior estaría dando un paso atrás en el mundo de EJB's!, puesto que la intención de EJB's es precisamente el ahorro de escribir este tipo de código complejo ("Middleware").

Interfases Locales

Una "Interfase Local" es un concepto nuevo para EJB's 2.0 que ofrece una alternativa a utilizar las clásicas interfases "Home" y "Remote", para entender interfases locales es necesario recordar como es llevada acabo la comunicación entre un EJB y su Cliente (JSP/Servlet/Applet), al observar el ciclo de Ejecución de un "Session EJB" y el ciclo de Ejecución de un "Entity EJB" se puede notar que existe una comunicación remota entre el EJB y su cliente, esta comunicación es llevada acabo a través de RMI ("Remote Method Invocation"), esta interacción ocupa de "Stubs" y "Skeletons" (componentes medulares de operaciones remotas) lo cual implica una capa adicional de procesamiento y complejidad, además se requiere que el cliente (JSP/Servlet/Applet) realice una búsqueda remota vía JNDI por el EJB, lo anterior trajo como resultado la creación de "Interfases Locales".

A través de "Interfases Locales" la comunicación entre el Cliente del EJB y éste es llevada acabo (como su nombre lo indica) "Localmente", se ahorran las operaciones de búqueda JNDI remotas, uso de "Stubs" y "Skeletons" (con esto la "Serialización y Deserialización" de objetos) y procesamiento, esta comunicación local implica que todo proceso es llevado acabo en el mismo JVM ("Java Virtual Machine"); aunque de momento parece ideal utilizar "Interfases Locales" para todo diseño, no se puede asumir que un "Application Server/EJB Container" utilice un JVM ("Java Virutal Machine"), inclusive quien puede asegurar que en un futuro no vayan a ser agregados 2 o 5 "Application Server/EJB Containers" para formar un "Cluster".

Tomemos el simple caso de la Cuenta Bancaria que ha sido utilizado en los diseños anteriores, es muy probable que los diversos EJB's residan en un "Host" (Computadora Física) de múltiples procesadores y Gigas de Memoria en la matriz bancaria, mientras los diversos Clientes (JSP/Servlets) que interactúan con estos EJB's estén localizados en distintas regiones geográficas en distintos "Hosts" (Computadoras Físicas) en su propio "Application Server/EJB Container", aquí no es posible utilizar "Interfases Locales".

Afortunadamente la especificación de EJB's permite que tanto "Interfases Locales" así como las clásicas interfases "Home" y "Remote" residan en el mismo diseño y puedan ser utilizadas según convenga; el diseño de las interfases locales en sí es muy similar a las interfases clásicas "Home" y "Remote":

Además del diseño de estas interfases es necesario declararlas en el "Deployment Descriptor" del EJB, ambas interfases son declaradas a través de los elementos <home> y <local-home>, el Deployment Descriptor para el "Entity CMP EJB" utilizó estas declaraciones.

Para que el cliente (JSP/Servlet) interactúe con el EJB a través de interfases locales, basta que se llame al EJB por el nombre JNDI asociado con estas interfases, el archivo jboss.xml para el "Entity CMP EJB" define el elemento <local-jndi-name> para estas interfases, en otras palabras, si el cliente(JSP/Servlet) llama el EJB con el nombre BancoLocal la comunicación será llevada acabo localmente y de llamarse a través de BancoNacional se utilizaran las interfases clásicas.

CORBA/IDL

CORBA ("Common Object Request Broker") fue uno de los primeros mecanismos utilizados para lograr interoperabilidad entre Sistemas Empresariales, a través de CORBA es posible insular un sistema del lenguaje en el que esta diseñado, en otras palabras la comunicación se lleva acabo a través de objetos CORBA, obviamente lo anterior implica que un sistema debe ser diseñado con CORBA, lamentablemente para efectos de este curso no se entraran en los detalles de como se realiza el diseño, sin embargo, es probable que una empresa posea algún sistema que opere en CORBA y por ende es conveniente saber que un "Application Server/EJB Container" es capaz de comunicarse con éste.

Una parte medular de CORBA es denominada IDL ("Interface Definition Language") a través de este lenguaje neutro se definen interfases las cuales son utilizadas para generar objetos vía CORBA, el funcionamiento de IDL es actuar como un puente entre determinado lenguaje y el mundo CORBA, esto es, a partir de un mismo IDL es posible generar interfases para otros lenguajes como C++, Smalltalk y Java; en Java existen dos distinciones de esta terminología IDL.

IDL-a-Java implica que es posible generar interfases Java a partir de cierto IDL, suponga que le proporcionan las definiciones IDL de "x" sistema CORBA a partir de estas definiciones IDL se generan las respectivas interfases Java las cuales pueden ser utilizadas en EJB's, esto permite que sus EJB's interactúen con el sistema CORBA.

El término Java-a-IDL significa que partiendo de definiciones Java (EJB's) es posible generar un IDL, una vez obtenido este IDL es posible utilizarlo para implementar objetos CORBA en otros lenguajes C++, Ada, Smalltalk ,etc; lo anterior permite que una aplicación escrita en estos lenguajes sea capaz de invocar métodos (en efecto actuando como cliente) en un "Enterprise Java Bean".

Serie "Connector" (JCA)

La Serie Connector fue un componente incorporado al juego de especificaciones J2EE 1.3, a través de esta especificación también denominada JCA ("Java Connector Arquitecture") se establecen los standares para lograr la comunicación entre un "Application Server" y un "EIS"("Enterprise Information System") donde éste último puede incluir sistemas "Mainframes","ERP's", "Base de Datos" y otros sistemas críticos para una empresa.

Debido a que esta especificación J2EE se encuentra en sus etapas iniciales muchos vendedores tanto de "Application Servers" como aquellos de "EIS" aún no ofrecen soporte para esta interactividad. Algunas empresas productoras de ERP's como SAP ( http://www.sap.com ) , JDEdwards ( http://www.jdedwards.com ) y PeopleSoft ( http://www.peoplesoft.com ) son las que se encuentran más adelantadas en diseños de este tipo y la razón es muy sencilla, a través de esta Serie "Connector" será posible que EJB's interactuen uniformemente con información residente en los sistemas ERP's que hoy en día al parecer son imprescindibles para cualquier industria.

[Cerrar Ventana]