Desarrollo de Software basado en Componentes en la

1
Desarrollo de Software basado en Componentes en la Plataforma J2EE
Julio Ariel Hurtado Alegría, Lina María Castillo Paredes
Facultad de Ingeniería Electrónica y Telecomunicaciones, Universidad del Cauca, Popayán, Colombia
Resumen. Este articulo define los temimos más usados en el área
del Desarrollo de Software Basado en Componentes (DSBC)
como “componentes”, “interfaces”, “contratos”, “patrones”,
“modelos de componentes”, “arquitecturas software”,
y
“framework de componentes”. Basados en ellos, los modelos y
plataformas de componentes proporcionan los mecanismos
adecuados para tratar la complejidad de los problemas que
aparecen en los sistemas abiertos y distribuidos, de allí la
importancia de tratar de identificar cada uno de estos elementos
en las plataformas mas destacadas en desarrollo de aplicaciones
empresariales como son J2EE y .NET. Tomando como referencia
la plataforma J2EE, se identifican todos los conceptos que
involucra el DSBC terminando con algunas consideraciones
especiales para el diseño de aplicaciones J2EE.
componentes pueden ser construidos por distintos
desarrolladores utilizando diferentes lenguajes y plataformas.
A su vez, el DSBC, trata de sentar las bases para el diseño y
desarrollo de aplicaciones distribuidas basadas en
componentes software reutilizables. La motivación para el
uso de componentes fue la reducción del costo de desarrollo,
pero después fue más importante la reducción del tiempo de
construcción. En la actualidad el uso de componentes está más
motivado por las posibles reducciones en los costos de
desarrollo. El DSBC está muy relacionado con el reuso. La
idea del reuso de piezas de software se originó en los 60´s
cuando el término de la crisis del software fue mencionado
por primera vez. La reutilización en el desarrollo de software
puede verse desde varios puntos de vista:
Abstract. This paper defines commonly used terms within the
area of the Component Based Software Development (CBSD)
such as “components”, “interfaces”, “contracts”, “patterns”,
“components
models”,
“software
architectures”
and
“components frameworks ”. Based on them, the Components
models and platforms provide the appropriated mechanisms to
try the problems complexity that emerge in the open and
distributed systems, thence the importance to try of identify each
one of these elements in the most prominent platforms in the
business applications development such as J2EE and .NET.
Taking as reference the J2EE platform, all of the concepts that
involve the DSBC are identified, ending with some special
considerations for the applications J2EE design.
-
El punto de vista tecnológico: donde la reutilización
puede ser de componentes software en el reuso o para el
reuso, así como
la generación automática de
implementaciones a partir de una especificación dada, por
ejemplo, un modelo de clases completamente
especificado puede llevar de manera automática a código.
-
El punto de vista del objeto a reutilizar: aquí la
reutilización puede darse para cualquier artefacto del
proceso de desarrollo, a cualquier nivel de abstracción e
incluso puede hablarse
de la reutilización del
conocimiento.
Palabras Clave: J2EE, Arquitectura, Reutilización, Plataforma,
Componentes, contratos, interfaz, frameworks, EJB, Patrones.
Los sistemas basados en componentes resultan de la adopción
de una estrategia de diseño basada en componentes y la
tecnología de componentes software que incluye los productos
y conceptos que soportan esta estrategia de diseño. La
estrategia de diseño está muy relacionada con el estilo de
arquitectura, es decir, patrones de diseño de alto nivel
descritos por los tipos de componentes en un sistema y sus
patrones de interacción. La tecnología de componentes
software refleja estos patrones de diseño y esta reflexión es
debido al hecho de que esta tecnología no existe solamente en
herramientas de diseño, sino que se implementa como parte
del sistema. Este patrón es encontrado en tecnologías de
componentes de software comerciales tales como Enterprise
JavaBeans de Sun Microsystems, y COM+ de Microsoft, así
como prototipos de investigación tales como el SEI
WaterBeans y otros.
I. INTRODUCCIÓN
Los continuos avances en la Informática y las
Telecomunicaciones han cambiado la forma en la que se
desarrollan actualmente las aplicaciones software. En
particular, el continuo aumento de la potencia de los
computadores personales, el abaratamiento de los costos del
hardware y las comunicaciones, y la aparición de redes de
datos globales han disparado el uso de los sistemas abiertos y
distribuidos. Esto ha provocado que los modelos de
programación existentes se vean excedidos, siendo incapaces
de manejar de forma natural la complejidad de los requisitos
para este tipo de sistemas. Una de las soluciones mas
prometedoras es la estrategia del desarrollo software basado
en componentes (DSBC), que se basa en la idea de que los
sistemas software pueden ser desarrollados seleccionando los
componentes apropiados que luego son ensamblados tomando
como referencia arquitectura software bien definida. Estos
II. CONCEPTOS
Algunos de los conceptos que se manejan dentro del DSBCse
exponen a continuación:
2
Un componente (1) es una implementación software que
puede ser ejecutada en un dispositivo físico o lógico. Un
componente implementa una o más interfaces (2) y satisfacen
ciertas obligaciones o contratos (3). Un componente puede ser
desplegado en ambientes estándares en tiempo de ejecución
(4). Un sistema basado en componentes esta formado por
diferentes tipos de componentes, que desempeñan un papel
específico en el sistema (5). Un modelo de componentes (6) es
el conjunto de tipos de componentes, sus interfaces y una
especificación de los patrones de interacción permitidos entre
los diferentes tipos de componentes. Un framework de
componentes (7) provee una variedad de servicios en tiempo
de ejecución (8) para soportar e implementar el modelo de
componentes. La siguiente Ilustración presenta un modelo de
referencia para estos conceptos.
3
2
1
C. Contratos
6
4
Son los puntos de acceso a un componente. Es una colección
de operaciones que son utilizadas para especificar un servicio
de un componente [3]. En una interfaz, cada semántica de una
operación es especificada, para que los proveedores de
componentes la implementen. Los componentes pueden
implementar (exportar) una o mas interfaces y pueden utilizar
(importar) interfaces de otros componentes. Así, interfaces
exportadas corresponden a servicios que un componente
proporciona, e interfaces importadas corresponden a servicios
que un componente necesita para implementar los servicios a
exportar [4]. Las interfaces de un componente deben
proporcionar un contrato que declara los servicios que un
componente ofrece y los servicios que este requiere para
cumplir a cabalidad sus funciones. Es importante distinguir la
interfaz abstracta, que es independiente de una
implementación y la interfaz de frontera que está asociada con
una implementación
y por consiguiente debe exhibir
propiedades que no son encontradas en las interfaces
abstractas.
5
8
7
A. componentes
Actualmente existe una gran discrepancia entre la mayoría de
los ingenieros de software sobre el concepto de componente.
La polémica suscitada recientemente entre Szyperski y Meyer
[1] sobre el concepto de componente, sus propiedades y su
naturaleza, podemos considerarla como uno de los ejemplos
mas recientes y representativos sobre la confusión que genera
el propio concepto de componente. En el contexto del DSBC,
un componente es una unidad o elemento con propósito bien
definido que, trabajando en conjunto con otros, puede ofrecer
alguna funcionalidad compleja. En términos formales, un
componente es una pieza de software que cumple con dos
características: no depende de la aplicación que la utiliza y, se
puede emplear en diversas aplicaciones [2]. Según los
asistentes a la ECOOP961, un componente es una unidad de
composición con interfaces contractualmente especificadas y
dependencias explícitas con el contexto. Un componente
software puede ser desplegado independientemente y estar
sujeto a la composición por parte de terceros [1].
B. Interfaces
1
10th European Conference for Object-Oriented Programming. Linz,
Austria, July 8-12, 1996.
Especificación que se añade a la interfaz de un componente y
que establece las condiciones de uso e implementación que
ligan a los clientes y proveedores del componente. Los
contratos cubren aspectos tanto funcionales (semántica de las
operaciones de la interfaz) como no funcionales (calidad de
servicio, prestaciones, fiabilidad o seguridad).
Hay dos sentidos de contratos que son necesarios en el DSBC:
los contratos de componentes y los contratos de interacción.
Los contratos de componentes describen los patrones de
interacción que tiene sus orígenes en un componente. Los
contratos de interacción especifican las obligaciones
recíprocas entre los tipos de interfaces que deben ser
implementadas por componentes arbitrarios. Los modelos de
componentes tales como EJB™ definen modelos de
interacción (y por lo tanto contratos) entre, por ejemplo,
contenedores y beans de sesión.
D. Patrones
Cuando hablamos de patrones nos ubicamos en la
reutilización de experiencias y conocimientos adquiridos por
el mismo desarrollador o por otros. Un patrón es una solución
a un problema en un contexto dado, que puede ser repetida
con éxito en problemas similares. La idea de los patrones es
recoger las prácticas de soluciones que han dado mejores
resultados, expresarlas de una manera general y ejemplarizada
con el fin de que sirvan de esquema para que otros la
solucionen de una manera más rápida y eficaz. De igual
manera, las soluciones que llevan a malos resultados pueden
esquematizarse y a
estos esquemas se les denomina
antipatrones. Los patrones en la construcción de software
pueden ser de diferentes tipos dependiendo de la etapa dentro
del proceso de desarrollo y dentro del proceso mismo. De esta
manera tenemos: modelos de dominio, patrones
arquitecturales (estilos), patrones de diseño, patrones de
código específicos a una tecnología (idioms), patrones de
3
diseño implementados en una API (Frameworks), patrones de
procesos, entre otros.
E. Modelos de Componentes
Un modelo de componentes especifica los estándares y
convenciones impuestas en el desarrollo de componentes que
pueden ser clasificados de la siguiente manera:
-
-
-
Tipos de Componentes. Un tipo de componente debe ser
definido en términos de las interfaces que éste
implementa. Un modelo de componentes requiere que los
componentes implementen una o más interfaces y de esta
forma un modelo de componentes puede ser visto para
definir uno o más tipos de componentes.
Esquemas de interacción. Los modelos de componentes
deben especificar cómo son localizados los componentes,
cuales protocolos de comunicación son utilizados y cómo
las calidades de servicios asociadas a la seguridad y al
manejo de transacciones son alcanzadas. El modelo de
componentes debe describir cómo interactúan los
componentes entre ellos o cómo éstos interactúan con el
framework de componentes.
Enlace de recursos. El modelo de componentes describe
cuales recursos están disponibles para los componentes y
cómo y cuando los componentes se enlazan a estos
recursos.
F. Arquitecturas Software
Existen numerosas definiciones de arquitecturas software y el
núcleo de todas ellas es la noción de que la arquitectura
software de un sistema define su estructura en bruto. Esta
estructura clarifica decisiones de alto nivel, incluyendo
aspectos de cómo el sistema está compuesto de partes
interactivas, donde están los principales caminos de
interacción, y cuales son las propiedades claves de las partes.
Adicionalmente una descripción de la arquitectura incluye
suficiente información para permitir análisis de alto nivel y
valoración crítica. Para proveer una descripción abstracta de
un sistema, la arquitectura expone ciertas propiedades,
mientras esconde otras. Idealmente, esta representación
proporciona una guía para todo el sistema, permite a los
diseñadores razonar acerca de la habilidad de un sistema para
satisfacer ciertos requerimientos, y sugiere un plano para la
construcción y composición del sistema.
La documentación de la arquitectura describe la estructura de
un sistema a través de una o más vistas, cada una de las cuales
identifica una colección de componentes de alto nivel y las
relaciones entre ellos. Un componente arquitectural representa
una unidad coherente de funcionalidad. Las relaciones entre
estos componentes arquitecturales indican que aspectos de un
componente son usados por otros componentes y cómo la
comunicación entre componentes procede sobre el tiempo.
Algunos investigadores consideran que el estilo de
arquitectura de las aplicaciones empresariales basadas en
componentes debería ser en capas y modular.
Las aplicaciones multicapa se dividen generalmente en 3
capas:
- Una capa cliente, que incluye clientes basados en un
navegador, otras aplicaciones empresariales y aplicaciones
cliente.
- Una capa media, que soporta módulos que proporcionan los
servicios de la aplicación empresarial a los clientes y que
implementan la lógica de negocios.
- Una capa del sistema de información empresarial (EIS), que
soporta los sistemas de información empresariales que
gestiona y almacena las funciones y los datos críticos.
Las tres plataformas empresariales más importantes en el
momento son: J2EE, .NET y CORBA.
G. Plataformas para aplicaciones distribuidas
El disponer de componentes software no es suficiente para
desarrollar aplicaciones, ya provengan estos de un mercado
global o sean desarrollados a medida para la aplicación. Un
aspecto crítico a la hora de construir sistemas complejos es el
diseño de la arquitectura del sistema, y por ello el estudio de la
Arquitectura Software se ha convertido en una disciplina de
especial relevancia en la ingeniería del software [5]. La
reutilización de arquitecturas software se realiza a través de un
framework, que se puede definir como un diseño reutilizable
de todo o parte de un sistema, representado por un conjunto de
clases abstractas y la forma en la cual sus instancias
interactúan.
Un framework distribuido está diseñado para integrar
componentes y aplicaciones software en ambientes
distribuidos, permitiendo la modularidad y reutilización en el
desarrollo de nuevas aplicaciones [6]. En la terminología de la
programación orientada a componentes, este término es
sinónimo de Plataforma de Componentes Distribuidos (PCD).
Este tipo de marcos ofrecen un entorno de desarrollo y de
ejecución de componentes software que permite aislar la
mayor parte de las dificultades conceptuales y técnicas que
conlleva la construcción de aplicaciones basadas en
componentes. Cada plataforma se apoya en los estándares y
mecanismos definidos por su modelo de componentes base; en
este sentido, podemos definir una plataforma como una
implementación de los mecanismos del modelo, junto con una
serie de herramientas asociadas. Ejemplos de estas
plataformas son .NET, J2EE y Bonobo, que se apoyan en los
modelos de componentes COM, Enterprise JavaBeans y
CORBA, respectivamente.
H. Framework de componentes
Es una implementación de servicios que soportan o
implementan un modelo de componentes. Una buena forma de
pensar en un framework de componentes es como un minisistema operativo. Con esta analogía, los componentes son a
los frameworks lo que los procesos son a los sistemas
operativos. El framework gestiona los recursos compartidos
por los componentes, y proporciona los mecanismos
fundamentales para permitir la comunicación entre
componentes. Sin embargo, a diferencia de los sistemas
operativos de propósito general como Unix, que soporta una
4
gran colección de mecanismos de interacción, los frameworks
de componentes son especializados para soportar un rango
limitado de tipos de componentes y sus interacciones. Algunos
ejemplos de frameworks de componentes pueden ser vistos en
la práctica. La especificación Enterprise JavaBeans™ (EJB),
define un framework de servicios y contenedores para
soportar el modelo de componentes EJB, con servidores
responsables de proporcionar servicios de persistencia,
transacción, seguridad, mientras los contenedores son
responsables de gestionar el ciclo de vida de los componentes,
el framework de componentes WaterBeans es especializado en
interacciones de componentes para visualización de cadenas
de datos en tiempo real y visualización de composición de
componentes, el framework de VisualBasic, que es
especializado en la composición visual de componentes, entre
otros.
parte de los contenedores es, junto con la independencia de
plataforma, una de las ventajas más destacables de J2EE.
III. LA PLATAFORMA J2EE
Los contenedores que encontramos en la arquitectura J2EE
son:
Lo primero que hay que decir de la plataforma J2EE es que es
una especificación para el desarrollo de aplicaciones
empresariales basadas en web que corren en ambientes
multicapa. J2EE proporciona un modelo de programación que
consiste en un conjunto de APIs y dirige la manera de
construir aplicaciones. Por otra parte, J2EE especifica cómo
debe ser la infraestructura de la aplicación sobre la cual
puedan correr las aplicaciones. Esta infraestructura de la
aplicación es proporcionada por los contenedores de las
implementaciones de J2EE. La plataforma J2EE es
esencialmente un ambiente de servidor de aplicaciones
distribuidas que proporciona:
-
-
Un conjunto de API´s de extensión Java para construir
aplicaciones y que definen un modelo de programación
para aplicaciones J2EE.
Una infraestructura en tiempo de ejecución
hospedar y gestionar aplicaciones.
La siguiente ilustración muestra la arquitectura J2EE en
función de sus contenedores:
Contenedor del
applet
APPLET
APIs de J2EE
A. Arquitectura de J2EE
Las aplicaciones distribuidas requieren acceso a un conjunto
de servicios empresariales como procesamiento de
transacción, acceso a bases de datos, mensajería, etc. La
arquitectura J2EE unifica el acceso a estos servicios en sus
APIs de servicios empresariales y las aplicaciones acceden a
estas APIs a través de un contenedor. Un contenedor es el
software que en tiempo de ejecución permite que las
aplicaciones J2EE accedan al conjunto de APIs de J2EE y
gestiona los componentes de la aplicación desarrollados según
las especificaciones. Esta gestión de los componentes por
Base de
Datos
Contenedor web
SERVLETS
JSPs
Contenedor de la
aplicación cliente
Contenedor EJB
RMI
EJB
APIs de J2EE
APIs de J2EE
Aplicación Cliente
APIs de J2EE
RMI
-
Un contenedor web para hospedar Java Servlets y
páginas JSP.
-
Un contenedor EJB para hospedar componentes
Enterprise JavaBean.
-
Un contenedor de applet para hospedar los Java
applets.
Un contenedor de la aplicación cliente para hospedar
aplicaciones Java estándar.
-
Cada uno de estos contenedores provee un ambiente en
tiempo de ejecución para los componentes respectivos. En ésta
arquitectura hay principalmente dos tipos de clientes:
-
Clientes Web, que normalmente corren en navegadores
Web. Estos clientes usan HTTP para comunicarse con el
contenedor Web. Los contenedores Web son responsables
de aceptar las solicitudes de los clientes Web, y generar
respuestas con la ayuda de los componentes de la
aplicación. Los componentes de la aplicación en los
contenedores Web incluyen servlets Java y páginas JSP.
Estos componentes implementan la funcionalidad
requerida por los clientes Web.
-
Clientes EJB. Son aplicaciones que acceden a
componentes EJB en contenedores EJB. Hay tres tipos de
clientes EJB: La primera categoría son los clientes de la
aplicación, que son aplicaciones standalone que acceden a
componentes EJB utilizando el protocolo RMI-IIOP. La
segunda categoría, son los componentes en el contenedor
Web, tales como Servlets Java y páginas JSP que también
pueden acceder a los componentes EJB a través del
protocolo RMI-IIOP. La categoría final son otros EJB
corriendo en el contenedor EJB, que se comunican a
través de llamadas al método de java estándar, por medio
de una interfaz local [7].
para
En términos Java, el framework para el desarrollo de
aplicaciones distribuidas es J2EE. Las características y
funcionalidad de la plataforma permiten la creación de
aplicaciones basadas en componentes escalables, distribuidas
y flexibles.
HTTP
SSL
La arquitectura J2EE define dos tipos de contratos:
5
Contratos a nivel del sistema entre un servidor de aplicación y
un adaptador de recursos y Contratos de aplicación entre un
componente de aplicación y un adaptador de recursos.
Contratos a nivel del sistema. Definen un estándar de
conexión entre los servidores de aplicación y los sistemas de
información empresariales (EIS). Los vendedores del EIS o
proveedores de adaptadores de recursos implementan su parte
del contrato a nivel del sistema en un adaptador de recursos.
Un adaptador de recursos es una librería que es específica al
EIS y es diseñada para proveer conectividad al EIS. El
adaptador de recursos es el componente que se conecta al
servidor de aplicación. Un ejemplo de adaptador de recursos
es un driver JDBC que se conecta a una base de datos
relacional. La interfaz entre un adaptador de recursos y su EIS
particular es específica al tipo de EIS y debe ser una interfaz
nativa o de cualquier otro tipo. Desde el punto de vista de los
servidores de aplicación, los contratos a nivel de sistema son
considerados una Service Provider Interface (SPI) que
proporciona una forma estándar para que los vendedores
extiendan los contenedores para que soporten conexión a
múltiples EISs.
Actualmente hay tres tipos de contratos a nivel del sistema
(1) Contratos de gestión de conexión. Permiten al servidor de
aplicación combinar conexiones para un EIS subyacente,
mientras que al mismo tiempo permite a los componentes de
la aplicación conectarse a un EIS. (2) Contratos de gestión de
transacciones. Este contrato es entre el gestor de transacción
que es provisto con el servidor de aplicación y un EIS que
soporta transacciones externas y locales.(3) Contratos de
seguridad. Permiten acceso seguro a un EIS.
Contratos a nivel de aplicación. Son los contratos entre un
componente de aplicación y un adaptador de recursos. Este
contrato define la API cliente que un componente de
aplicación utiliza para acceder a un EIS. Esta API debe ser
una API específica para un tipo particular de adaptador de
recursos y el EIS subyacente. JDBC es una API cliente
específica para un tipo de adaptador de recurso específico, en
este caso, una base de datos relacional.
B. El modelo de componentes EJB
El estándar Enterprise Java Bean (EJB) es una arquitectura de
componentes para componentes desplegables del lado del
servidor en Java. Es un acuerdo entre componentes y
servidores de la aplicación que permite a cualquier
componente correr en cualquier servidor de aplicación. Los
componentes EJB son desplegables y pueden ser importados y
cargados en un servidor de aplicación, que almacena estos
componentes.
Físicamente, un EJB es dos cosas en una:
- Una especificación. Que define las reglas del acuerdo entre
los componentes y los servidores de aplicación.
- Un conjunto de interfaces Java. Los componentes y
servidores de aplicación deben adaptarse a estas interfaces.
Desde que todos los componentes sean escritos para las
mismas interfaces ellos significan lo mismo para el servidor
de aplicación.
EJB es específicamente utilizado para resolver problemas
empresariales, y debe realizar cualquiera de las siguientes
tareas:
- Hacer la lógica del negocio. Ejemplos de esto incluye:
computarizar los impuestos de una tarjeta de compra,
asegurarse de que el administrador tiene autorización para
aprobar la orden de compra, etc.
- Acceder a una base de datos: Por ejemplo, transferencia de
dinero entre dos cuentas bancarias, llamadas a
procedimientos almacenados para recuperar un tiquete en
un sistema de soporte de ventas, etc.
- Acceder a otros sistemas. Ejemplos incluyen, llamadas a
sistemas heredados de alto desempeño escritos en COBOL
que computariza el factor de riesgo para una nueva cuenta
de seguro, etc.
C. Tecnologías J2EE
Las tecnologías J2EE proveen los mecanismos necesarios para
la construcción de grandes aplicaciones empresariales
distribuidas. Estas tecnologías pueden ser clasificadas de
acuerdo a su uso en:
- Tecnologías de servicios. Estas tecnologías proveen los
componentes de la aplicación que soportan servicios para una
funcionalidad eficiente.
- Tecnologías de comunicaciones. Estas tecnologías
proveen los mecanismos para la comunicación entre las
diferentes partes de la aplicación, ya sean locales o remotas.
- Tecnologías de componentes. Estas tecnologías son
utilizadas para contener las lógicas de presentación, negocio y
persistencia.
Tecnologías de servicios
Algunos de los servicios de J2EE para los componentes de la
aplicación son gestionados por los mismos contenedores,
permitiendo de esta manera a los desarrolladores concentrarse
en la lógica de la aplicación. Sin embargo, algunas veces los
desarrolladores ven necesario invocar algunos de estos
servicios utilizando las diferentes tecnologías de servicios,
como son:
- Java Database Connectivity (JDBC). Esta API (un
estándar para conectividad de bases de datos) permite al
desarrollador conectarse a bases de datos relacionales.
Además permite consultas transaccionales, recuperación y
manipulación de datos desde una conexión JDBC. J2EE añade
una extensión al núcleo de la API JDBC para dar
características avanzadas tales como pooling de conexión2 y
transacciones distribuidas.
2
Pooling de conexión= conjunto de conexiones
6
- Java transaction API (JTA). Esta API es un medio para
trabajar con transacciones y especialmente con transacciones
distribuidas, independiente de la implementación del gestor de
transacción de Java, el Java Transaction Service (JTS).
- Java Naming and Directory Interface (JNDI). EL papel
de esta API dentro de la plataforma J2EE es proveer el medio
estándar para
- acceder a servicios de nombrado tales como: Servicios de
directorio Novell, o servicios de directorio Netscape. Una
aplicación J2EE utiliza JNDI para buscar interfaces utilizadas
para crear, entre otras cosas, EJB´s y conexiones JDBC.
- Java Message Service (JMS). Provee la funcionalidad
para enviar y recibir mensajes a través del uso del middleware
orientado a mensajes (MOM).
- Java Conector Architecture (JCA). Es un estándar a
través del cual las aplicaciones J2EE pueden acceder a una
variedad de aplicaciones heredadas, especialmente sistemas de
planeación de recursos empresariales tales como SAP R/3 y
PeopleSoft. Esta especificación define una arquitectura simple
en la cual los vendedores de servidores de aplicaciones J2EE y
de sistemas heredados colaboran para producir componentes
plug and play que permiten el acceso al sistema heredado sin
tener que saber nada específico de cómo trabajar con éste.
- Java Autentication and Autorization Service (JAAS). Esta
API provee un mecanismo para conceder permisos basados en
quien ejecuta el código. JAAS utiliza una arquitectura de
conexión de módulos de autenticación.
Tecnologías de comunicación
Son las tecnologías que proporcionan los mecanismos para
que varios componentes y servicios en una aplicación J2EE se
comuniquen unos con otros. Entre estas tecnologías tenemos:
Protocolos de Internet. Permiten la comunicación entre
solicitudes de clientes y respuestas de servidores. Se destacan:
- Hypertext Transfer Protocol (HTTP): es un protocolo
genérico, del nivel de aplicación, el cual tiene muchos usos
más allá de la simple capacidad de hipertexto. Este trabaja
en la filosofía solicitud/respuesta. Un cliente envía una
solicitud para el servidor, la cual incluye: un método de
solicitud, un Uniform Resource Identifier (URI), la versión
del protocolo, seguido por un MIME, información del
cliente, y posible contenido del cuerpo sobre una conexión
con un servidor. El servidor responde con una línea de
estado seguida por un mensaje MIME, entidad de metainformación y posible contenido de la entidad cuerpo.
- Transmisión Control Protocol over Internet Protocol
(TCP/IP): actualmente son dos protocolos separados que
están combinados en una entidad simple. IP es el protocolo
que asegura que los datos sean recibidos por ambos puntos
finales en una comunicación. TCP es el protocolo que sigue
las huellas de los paquetes y se asegura que éstos sean
ensamblados en el mismo orden en que fueron enviados y
que estén libres de errores. Sin embargo, TCP e IP trabajan
juntos para mover datos alrededor de Internet.
- Secure sockets Layer (SSL): Este protocolo utiliza
criptografía para dar seguridad al flujo de información entre
el cliente y el servidor.
Protocolos de objetos remotos. Son mecanismos que permiten
la comunicación de componentes remotos. Entre estos
tenemos:
- Remote Method Invocation (RMI). Es uno de los
mecanismos principales en las aplicaciones de objetos
distribuidos propio de la plataforma Java. Este permite el
uso de Interfaces para definir objetos remotos. Luego
podemos llamar métodos de estos objetos remotos como si
fueran locales.
- RMI-Inter ORB Protocol (IIOP). Es una extensión de RMI
sobre el protocolo IIOP, el cual permite definir una interfaz
remota de cualquier objeto remoto para que pueda ser
implementada en cualquier lenguaje que soporte mapeo
OMG y ORB.
- Java Interface Definition Language (IDL). A través del
uso de esta, un cliente Java puede invocar llamadas a
métodos sobre objetos CORBA. Estos objetos CORBA no
necesitan estar escritos en Java, pero deben implementar
una IDL.
Tecnologías de componentes
Las aplicaciones J2EE son construidas a partir de
componentes. La especificación J2EE define los siguientes
componentes J2EE: aplicaciones y applets que corren en el
lado del cliente, las tecnologías de componentes Servlets y
JSP, y los Enterprise Java Beans que corren del lado del
servidor.
El valor más importante que brinda la plataforma J2EE es que
dentro del proceso de desarrollo se programe solamente lo que
es particular de la aplicación, y los elementos comunes a la
mayoría de aplicaciones Empresariales sean provistos por el
contenedor. Así, el programador sede al contenedor la gestión
de transacciones, seguridad, colas de mensajes, grupos de
conexiones a bases de datos, y otros recursos. De esta
manera, el desarrollo parte del contenedor y no del sistema
operativo. Así, se facilita la implementación, y los diseños
ganan flexibilidad al permitir descomponer lógicamente una
aplicación en componentes altamente cohesivos y con un
menor acoplamiento.
La plataforma J2EE provee tres tecnologías para el desarrollo
de componentes agrupadas en dos tipos:
A. Componentes Web
La plataforma J2EE define dos tipos de tecnologías web y sus
componentes asociados: Los Java Servlets y las Java Server
Pages (JSP). Los servlets son clases Java que en forma
dinámica habilitan sus instancias para procesar peticiones y
construir respuestas. Las páginas JSP son documentos basados
en texto que se ejecutan como servlets, pero de una manera
muy similar a la creación del contenido estático. Aunque los
7
servlets y las páginas JSP pueden ser usadas de forma
indistinta, cada uno de estos tipos de componentes Web tiene
sus fortalezas. Los servlets se ubican mejor manejando el
control de funcionalidad de una aplicación, tales como
despachar peticiones y manejar información no textual. Las
páginas JSP son documentos apropiados para la generación de
texto basado en Marcado como HTML, SGVL, WML y XML.
Los Servlets
Un servlet es una clase en el lenguaje de programación Java
usado para extender las capacidades de servidores que
hospedan aplicaciones cuyo acceso se realiza siguiendo el
modelo de programación petición-respuesta. Aunque un
servlet puede responder a cualquier tipo de petición, estos son
comúnmente usados para extender las aplicaciones
hospedadas en servidores Web. Para estas aplicaciones, la
tecnología Java Servlet define clases servlets específicas al
protocolo HTTP. Los servlets permiten extender la
funcionalidad de servidor web para generar contenido
dinámico en HTML, XML, WML u otros lenguajes de
marcado.
La API para trabajar los servlets se provee en los paquetes
javax.servlet y javax.servlet.http. El servicio provisto por un
servlet es implementado en el método service() de un
GenericServlet, los métodos doMetodo(), donde Método
puede tener el valor de Get, Delete, Options, Post, Put o Trace
de un HttpServlet, o cualquier otro método específico a una
clase definida para un protocolo en particular, la cual
implementa la interface Servlet. El ciclo de vida de un servlet
es controlado por el contenedor en el cual el servlet ha sido
desplegado. La siguiente Ilustración muestra parte del paquete
javax.servlet.
servlet
(from javax)
GenericServlet
(from servlet)
service(ServletRequest req, ServletResponse res)
Servlet Config
(from servlet)
ServletRequest
Servlet
(from servlet)
(from servlet)
ServletResponse
(from servlet)
http
(from servlet)
Los servlets HTTP son clases que heredan la clase HttpServlet
y están diseñados específicamente para peticiones HTTP. Los
dos tipos más comunes de peticiones son la petición GET y la
petición POST. La petición GET adiciona la información de la
petición a la cadena del URL, mientras que la petición POST
encripta la información en el cuerpo de la petición. POST es
considerado más seguro, pero GET permite hacer la solicitud
desde la barra de dirección en el browser.
Los componentes Web son colaborativos y comparten
información vía objetos que se manipulan como atributos de
diferentes tipos de alcance: aplicación, sesión, petición y
página. De esta forma, un atributo con alcance de aplicación
podrá ser visto por cualquier componente web que pertenezca
a la aplicación, mientras que una atributo con alcance de
sesión existirá y será visto únicamente por los componentes
que sean involucrados en una misma sesión, así como los
atributos con alcance de petición serán visto por aquellos
componentes que se vean involucrados dentro de una misma
petición del cliente. Los atributos de página sólo serán vistos
en la página en los que son declarados.
Dado que el protocolo HTTP es un protocolo sin estado, Los
servlets permiten hacer el seguimiento de los clientes web
mientras estos permanecen en el sitio web. Para ello puede
usar Cookies o el seguimiento a la Sesión, entre otras
opciones.
Las Java Server Pages (JSP)
Las Java Server Pages (JSP) proveen una forma de embeber
componentes en una página, y generan de manera dinámica la
página enviada al cliente. El objetivo que cumplen es el de
simplificar la creación y gestión de páginas Web. Una página
JSP puede contener elementos HTML, código Java, y
componentes Java Beans.
Las JSP son una extensión del modelo de programación de
servlets. Cuando un usuario solicita una página JSP, el
contenedor web compila la página JSP a un servlet. El
contenedor web después invoca el servlet y retorna el
contenido resultante al browser. Una vez el servlet ha sido
compilado desde la página JSP, el contenedor web puede
simplemente retornar el servlet sin tener que volverlo a
compilar. De esta forma, las páginas JSP proveen un
mecanismo poderoso y dinámico para ensamblado de páginas
que se benefician de muchas ventajas de la plataforma Java.
HttpServlet
(from http)
HttpServletRequest
doGet()
doPost()
(f ro m ht tp)
HttpServletResponse
(from http)
El patrón general para un método de servicio es extraer la
información de la petición, acceder a recursos externos y
luego producir la respuesta basada sobre esta información.
Mientras los servlets son código java puro, las páginas JSP
son documentos basados en texto hasta que el contenedor web
los compila en los servlets correspondientes, lo que permite al
programador concentrarse en la presentación de la aplicación.
Los elementos para encapsular código Java en páginas JSP se
clasifican en declaraciones, scriplets y expresiones. Una
declaración permite definir elementos, un scriplet es un
fragmento de expresión java, y una expresión es una
expresión completa de código cuya respuesta es enviada como
elemento de información de la página.
8
servidor termina. Estos beans son útiles para encapsular
los procesos del negocio que maneja la aplicación. Estos
se pueden clasificar en beans de sesión con estado o sin
estado según manejen o no estado conversacional.
En JSP cada elemento empieza con “<%”. La sintaxis para
cada uno de ellos es la siguiente:
<%! declaración %>
<% scriptlet %>
<%= expresión %>
-
Entity EJB: representan entidades de información
persistente, las cuales deben ser almacenadas en una base
de datos. Todos los clientes acceden a la misma
información, de esta forma se puede decir que el bean es
encontrado en lugar de creado. Según quién maneje la
persistencia del bean, un Entity EJB se puede clasificar en
Entity EJB con persistencia manejada por el contenedor (
CMP – Container Managment Persistent) y Entity EJB
con persistencia manejada por el Bean(BMP – Bean
Managment Persistent).
-
Message Driven Bean: representa componentes que
responden a la llegada de mensajes provenientes de
canales de eventos (Tópicos) o de colas de mensajes. Para
el origen de los mensajes, el procesamiento se realiza de
manera asincrónica de tal forma que no tiene que ceder el
control y esperar a que se lo devuelvan.
Los Enterprise Java Beans (EJB)
Son las componentes del modelo de desarrollo de aplicaciones
empresariales de Sun. Un Enterprise Java Beans es elemento
de lógica o de persistencia, que acompañado de los
componentes para armar la presentación, Servlets y Java
Server Pages, forman lo que son los componentes java
programables del modelo J2EE.
Los EJB han ganado terreno con el surgimiento de servidores
de aplicaciones y con el desarrollo de aplicaciones multi-nivel.
Una de las grandes ventajas de esta arquitectura es el poder
dividir a nivel de arquitectura el código, lo que da como
resultado código más mantenible y menos propenso a errores.
El EJB es la unidad de composición de una aplicación
empresarial J2EE, el contexto en el que vive es el contenedor,
sus interfaces son especificadas en el lenguaje Java y su
dependencia con el contexto a través de un descriptor xml:
entre las dos se forma el contrato entre el EJB y el contenedor
que lo hospeda.
El contenedor permite comunicar a los clientes con el EJB. El
contenedor provee los siguientes servicios:
-
Soporte a transacciones
-
Seguridad
-
Persistencia
Un EJB tiene al menos una clase y dos interfaces, la
implementación del bean, la interfaces Home y la de los
servicios que presta el bean. La interfaz de servicios puede ser
de dos tipos desde la especificación EJB 2.0: remota o local.
La diferencia es que la remota utiliza RMI/IIOP para hacer
llamadas a los métodos, y la local no, obviamente la local
necesita que los objetos estén en la misma máquina virtual. La
interfaz home por un lado es una fábrica de objetos que
permiten acceder al componente y por ello aquí se definen los
métodos de creación, encontrado y destrucción del EJB.
Existen tres clases de EJBs: sesión, entidad y los manejados
por mensajes. Los de sesión implementan la lógica de la
aplicación. Los de entidad son persistentes, por lo que
representan elementos que corresponden a registros en las
tablas de bases de datos. Los manejados por mensajes, son
beans cuya ejecución ocurre mediante la llegada mensajes,
permitiendo así interacciones asincrónicas.
-
Session EJB: normalmente representa objetos temporales
dentro de una aplicación. Estos pueden o no tener estado.
El objeto desaparece cuando el cliente se desconecta o el
Las interfaces definidas para los EJBs en la especificación
J2EE, y para su acceso, se presentan en la siguiente
Ilustración.
ejb
javax.ejb
E spec ific ación
de los
c om ponentes y
s us tipos
S es s ion
B ean
(fro m e j b )
E JB Local
Home
(fro m e j b )
E nterpris e
B ean
(fro m e j b )
E nt ity B ean
(fro m e j b )
E JB Loc al
Objec t
(fro m e j b )
Int erfaces para el
ac ces o al com ponent e
de m anera remot a
M es s age
DrivenB ean
(fro m e j b )
Interfaces para el
acc es o al
c om ponente de
m anera local
EJ BHom e E JB Objec t
(fro m e j b )
(fro m e j b )
Para construir un EJB se debe: (1) Especificar sus interfaces
de creación y de servicios, para ello debe heredar de las
interfaces EJBHome y EJBObject. Si el acceso al EJB va a
realizarse desde la misma máquina virtual, se recomienda usar
EJBLocalHome y EJBLocalObject. (2) Construir la clase del
bean, esto se realiza implementando una de las interfaces
especificadas en la jerarquía de la ilustración anterior
dependiendo del tipo de bean deseado. En el momento del
9
despliegue del EJB se debe seleccionar las interfaces de
creación y de servicios y la clase del bean, junto con la
información adicional del bean, tal como el manejo de estado,
de persistencia y de transacciones.
requieren que su información persista en el tiempo. Su
persistencia puede ser manejada por el contenedor, en este
caso el bean se conoce como un bean Entity CMP, o por el
mismo bean en este caso se le conoce como un bean Entity
BMP.
Acceso a los servicios de los EJBs
Un cliente utiliza el servicio de nombrado provisto por JNDI
para alcanzar una instancia del objeto home el cual se
especifica por medio de la interface home del componente.
Este objeto permite alcanzar el objeto que maneja los servicios
del bean, el cual se especifica por medio de las interface local
o remota del componente.
Ventajas de trabajar con EJBs:
-
División de trabajo: el contenedor es el encargado de
ofrecer los servicios de modo que el diseñador del
componente se centra exclusivamente en el desarrollo de
la funcionalidad principal. La interoperabilidad entre
servicios y componentes se define en las especificaciones
correspondientes que forman parte del estándar J2EE.
-
Diversos vendedores: existen diversos vendedores tanto
de contenedores, servidores de componentes, servidores
web, así como de EJBs que resuelven algún tipo de lógica
concreta.
Si se cumple con la especificación, la compatibilidad está
garantizada, y se puede ejecutar cualquier EJB en
cualquier contenedor, aunque ambos hayan sido
desarrollados por distintas empresas proveedoras.
Procedimientos remotos: el diseño de los EJB gira
alrededor de la tecnología RMI, lo que permite la
operación en sistemas distribuidos.
Diversos clientes: un EJB puede interactuar con una gran
gama de clientes: servlets, sistemas de gestión, bases de
datos, applets, sistemas heredados.
El contenedor es responsable de gran parte de la
programación, ya que de manera declarativa se puede
manejar la persistencia y la participación en
transacciones.
-
-
Utilidad de los diferentes tipos de EJBs:
Los EJBs de sesión son útiles para encapsular la lógica del
negocio y para ello puede manejar procesos con estado
conversacional con el cliente o sin estado. Se utilizan con
estado cuando la respuesta a una petición depende de lo que
haya sucedido en las peticiones anteriores, por ejemplo
brindar el costo total de una reserva de hotel después de que
se ha seleccionado entre varias peticiones el tipo de
habitación, el número de personas y el número de días. Se
utilizan EJB de sesión sin estado cuando cada petición se debe
tratar siempre de la misma forma, independiente de que haya
sucedido antes, por ejemplo, en un cálculo el proceso recibe a
su inicio toda la información y con ella puede dar respuesta.
Los EJBs de Entidad son útiles para manejar conceptos
correspondientes al modelo del mundo del problema y que
Los EJBs manejados para desacoplar el control entre
componentes de aplicación, un componente puede enviar el
mensaje a otro a través de una cola o un canal de eventos.
Otro bean, el bean manejado por mensajes, tiene la posibilidad
de ser un oyente de la cola o del canal de eventos, de esta
forma se convierte en un suscriptor de mensajes. Esto puede
resultar útil cuando cierta parte de una aplicación, por ejemplo
en una tienda virtual cuando se realiza una venta y se necesita
avisarle a inventario que se actualice, se requiere llamar a un
proceso pero no se puede esperar a que de respuesta para
continuar. Como solución se le puede avisar a inventario y
este recibe la petición en un cola de espera y luego utiliza
beans manejados por mensajes para avisar a inventario y este
recibe la petición en un cola de espera y luego utiliza beans
manejados por mensajes para realizar las actualizaciones
dejadas en la cola.
IV. CONSIDERACIONES ESPECIALES PARA EL
DESARROLLO DE APLICACIONES J2EE
Los componentes ingresan al mundo de la computación con el
fin de brindar una forma de crear activos reutilizables de una
granularidad mayor a las clases. Su objeto es permitir la
construcción de componentes para el reuso y de aplicaciones
con reuso, por ello está ligado a otros conceptos de la
ingeniería del software tales como, Ingeniería de dominio,
Arquitectura de Software, Líneas de Productos, Patrones de
Diseño, Frameworks y Mecanos.
Una de las principales soluciones para el trabajo con
componentes la da J2EE para el desarrollo de aplicaciones
empresariales en la Web, la cual es un claro ejemplo de
construcción para reutilización en un gran dominio, el
dominio empresarial. Para este dominio se trabaja un estilo
arquitectónico en capas que permite desacoplar la
presentación de la aplicación, que generalmente es dinámica y
está en continua transformación de la capa de negocio la cual
cambia con las políticas, reglamentos y normas que rigen a las
organizaciones y esta a su vez de la capa de persistencia que
generalmente se mantiene más estable a lo largo del ciclo de
vida de la aplicación. De igual manera, los proveedores de
soluciones en dominios empresariales más específicos, donde
las empresas colombianas tienen una gran oportunidad,
deberán recurrir a la reusabilidad para asegurar su
supervivencia. Pero este trabajo con el reuso no puede ser a la
ligera, debe estar asociado a unas políticas y compromisos de
la empresa por facilitar este tipo de desarrollo, a un adecuado
entrenamiento no sólo en tecnologías sino en ingeniería y lo
más importante un proceso de desarrollo que se ajuste a las
características particulares de la empresa. Para el proceso de
desarrollo se debe realizar un trabajo de ingeniería de dos
tipos: Ingeniería de Dominio e Ingeniería de Aplicación. La
10
ingeniería de dominio permite obtener para una línea de
productos una arquitectura de referencia y un conjunto de
activos reutilizables: componentes, frameworks, patrones, o
combinaciones organizadas entre estos como lo son los
mecanos. La Ingeniería de la aplicación sigue el proceso de
desarrollo que normalmente se ha usado para una aplicación,
pero utiliza, valida y actualiza la arquitectura de referencia, así
como de componentes y demás elementos reutilizables. Con
cada nueva aplicación se crece en experiencia, en arquitectura
y en activos reutilizables, lo cual tiene implicaciones directas
sobre la calidad y la productividad de la empresa.
CMP o una herramienta de mapeo objeto-relacional
convencional.
-
Los recursos utilizados deben ser reciclables con el fin de
mejorar el desempeño, se debe manejar pooling de acceso
a recursos, en muchos casos J2EE ya los tiene
disponibles, por ejemplo pooling de conexiones a bases
de datos, esto es muy útil para crear un conjunto pequeño
de objetos de acceso y estarlos usando y liberando en
lugar de crear un objeto de acceso a recurso cada vez que
se necesita de él.
Tanto el proceso de ingeniería de dominio, como el de
aplicación debe tener los siguientes principios básicos:
Iterativo e incremental y centrado en la Arquitectura. De
manera particular para el proceso de Ingeniería de dominio se
tienen los siguientes principios: guiado por los casos de uso de
negocio, basado en el conocimiento y representación de un
dominio y construcción para el reuso. Para el proceso de
ingeniería de aplicación se tienen en cuanta adicionalmente
los siguientes principios: guiado por los casos de uso de la
aplicación y construcción con reuso.
-
Usar caché cuando se necesite optimizar el uso del ancho
de banda. Un caso particular donde se puede utilizar es en
el proceso de acceso a un EJB a través de JNDI, este
proceso es costoso en desempeño ya que los clientes
requieren de una conexión de red al servidor de JNDI y si
se recurre a esto cada vez que se necesita el componente,
esto resulta redundante y más costoso. Para solucionarlo
se puede usar un componente del lado del cliente que
permita localizar, acceder y mantener en caché objetos de
servicios sin tener que recurrir frecuentemente a JNDI.
A. Las mejore prácticas en el Diseño de aplicaciones
Empresariales J2EE
-
Utilizar los patrones de diseño que brinda la experiencia
industrial. Los patrones de diseño es una solución
estándar para un problema en el diseño. Un patrón de
diseño ofrece una solución abstracta a un problema de
diseño que aparece muy frecuentemente, expresada
mediante un conjunto de relaciones e interacciones entre
componentes. Para las aplicaciones J2EE existe un
repositorio de patrones en la página oficial de Sun
Microystems. Se pueden aplicar patrones para diseñar el
comportamiento, la estructura, y otras áreas funcionales y
no funcionales de la aplicación. Entre los patrones
principales descritos en el catálogo de Sun están: el de
fachada con bean de sesión, objeto valor, objeto de
acceso a datos, localizador de servicios, proxy de
negocios, controlador frontal y vista compuesta.
-
Es recomendable automatizar los procesos de
construcción, a través de scripts o herramientas de ayuda
a la construcción y despliegue, ya que la cantidad de
archivos y de descriptores puede generar grandes
confusiones.
-
A través de cada iteración se debe integrar las nuevas
funcionalidades con el fin de depurar y mantener lo más
correcta posible la aplicación en desarrollo. Para ello debe
realizarse pruebas de integración.
-
Es importante optimizar el uso del ancho de banda y
mejorar el desempeño de la comunicación. Si el cliente
del EJB está en la misma máquina se debe usar llamadas
locales y no a través de la interfaz remota. Se recomienda
minimizar el llamado a métodos remotos, para ello se
debe usar objetos compuestos para formar una petición
y/o retornar una respuesta. El desempeño puede mejorarse
haciendo uso de una sola fachada del lado del servidor a
través de un bean de sesión, minimizando el número de
Uno de los elementos más críticos en el desarrollo de una
aplicación es la metodología utilizada. Las metodologías para
desarrollar aplicaciones empresariales J2EE son diversas. Sin
embargo todas presentan unos pasos genéricos necesarios para
soportar el desarrollo: captura de requerimientos, análisis,
diseño, implementación, pruebas y despliegue. Las mejores
prácticas están distribuidas a lo largo de estos pasos y se
condensan a continuación particularmente sobre el diseño.
-
-
-
Se debe atacar el riesgo lo más pronto posible, hay que
combinar las técnicas de modelado con las de
prototipado. Se puede utilice como unidad de trabajo el
caso de uso, deben ser definidos, priorizarlos. Es
recomendable seguir los pasos básicos por grupos de
casos de uso iniciando con los de más alta prioridad. Los
casos de uso de alta prioridad son aquellos que presentan
mayor riesgo y que tienen un impacto significativo sobre
la arquitectura. Con esto se adelanta el riesgo a las fases
tempranas del desarrollo.
Es recomendable usar un lenguaje de modelado estándar,
por ejemplo el UML – Unified Modeling Language, con
el objeto de facilitar la comunicación del sistema entre los
diferentes participantes del proyecto de desarrollo. El
UML provee un lenguaje y una variedad de diagramas
que arquitectos, diseñadores y demás participantes
pueden fácilmente construir y entender.
El diseño es un paso fundamental en el desarrollo, ya que
contribuye a la calidad, la escalabilidad y la confianza de
las aplicaciones. Debe ser hecho para soportar el cambio
con un modelo conceptual dinámico y las principales
formas de hacerlo es usando los beans de entidad de tipo
11
interacciones y dependencias del cliente con los EJBs del
lado del servidor. También es útil en la optimización del
desempeño usar del lado del cliente un proxy que le
permita al cliente continuar con sus procesos sin esperar a
que el servidor de una respuesta completa.
-
Los casos de prueba deben ser construidos antes de
codificar. Al escribir los casos de prueba inicialmente se
logra dar al programador más información sobre los
requerimientos a satisfacer, se crea más cultura sobre el
valor de la prueba y las pruebas de integración pueden
darse de una manera más organizada. Adicionalmente, se
puede incluir dentro del plan de trabajo del proyecto la
planificación, el diseño y la ejecución de las pruebas. Es
de gran utilidad un Framework de prueba con el fin de
automatizar ciertos casos de pruebas y mejorar la
productividad en este paso dentro del proceso de
desarrollo. Una forma de hacerlo es utilizar JUnit, un
framework de pruebas que brinda flexibilidad,
consistencia, facilidad de implementación y de
automatización, aunque presenta dificultades en el
desempeño. JUnit es una herramienta de código abierto
construido en Java, permite definir casos de pruebas,
agruparlos en suites de pruebas y realizar aserciones
acerca de los resultados.
Los patrones de diseño de J2EE que se describen a
continuación están basados en la información brindada por el
Sun Java Center de J2EE, los cuales por estar orientados al
estilo arquitectónico en capas, se clasifican según la capa a la
que pertenece: presentación, de negocio o de integración a
otros sistemas.
1) Patrón Controlador Frontal- patrón de la capa de
presentación
La presentación que se genera al usuario debe tener el mínimo
código de lógica de negocio, de tal forma que este código sea
compartido por múltiples vistas y además que pueda ser
cambiado independientemente de la presentación. Los
servicios comunes, tales como seguridad y gestión de estado,
no deben ser replicados a mútiples vistas, esto traería
problemas de mantenimiento e inconsistencias al usarlos. El
control de un proceso que implica diferentes vistas puede
dificultar el mantenimiento del código. El patrón controlador
frontal aplica un componente que intercepta la petición del
cliente y tiene una o varias de las siguientes responsabilidades:
(1) Aplicar servicios comunes tales como autenticación y
control de acceso, (2) Determinar la vista adecuada para
atender la petición y (3) Iniciar las conexiones a otros recursos
necesarias para atender la petición.
El siguiente diagrama de clases muestra los participantes de la
solución:
<<ClientPage>>
InicioPeticion
Request
<<Servlet>>
Controladorfrontal
Enruta Petición
<<Java Server Page>>
Vista1
<<Java Server Page>>
Vista2
2) El patrón Sesión de Fachada – Patrón de la capa de
Negocio
Cuando el desarrollador usa EJBs como repositorios para la
información y pequeños servicios de lógica de negocio, la
mayoría de la lógica del negocio de grano grueso queda
escrita del lado del cliente. Esto puede ser perjudicial debido a
que el cliente queda fuertemente ligado a la lógica del
negocio, puede sobrecargar la red con muchas peticiones a la
hora de manejar un proceso de negocio y adicionalmente tiene
que interactuar con muchos componentes de una manera
remota para un mismo proceso, lo que genera gran
dependencia entre las capas arquitectónicas. La solución es
una variación del patrón Fachada. En el patrón fachada un
objeto o componente, la fachada, se coloca entre el cliente y
un subsistema complejo. El componente fachada expone los
servicios requeridos por el cliente y agrega servicios de
granularidad gruesa a partir de los servicios de granularidad
fina. Para el patrón fachada J2EE, el componente de sesión de
fachada se comporta como un componente de negocio que
encapsula los servicios de varios EJBs.
El siguiente diagrama muestra un componente sesión de
fachada como un control de acceso a otros EJBs u otros
recursos.
Cliente
1..* <<Session EJB>>
SessionFacade
1..*
ObjetoNegocio
<<Session EJB>>
ComponenteSesion
<<Entity EJB>>
ComponenteEntidad
ObjetoAccesoRecurso
3) Patrón localizador de servicios – Patrón de la capa de
negocio
En términos de programación, la sobrecarga del uso de
métodos sobre una interface de un EJB es relativamente
pequeña, tan solo es manejar excepciones remotas. Sin
embargo, la creación de EJBs requiere específicamente,
código basado en JNDI para descubrir la interface home y así
crear el EJB requerido. Esto obliga al programador a incluir
código que utiliza JNDI para manejar la creación de contexto,
la búsqueda y la verificación de las referencias.
12
El patrón localizador de servicios define cómo un objeto
puede desempeñar las tareas de búsqueda y creación asociadas
a varios EJB desde distintos clientes. El cliente sólo tiene que
encontrar el localizador de servicios y preguntar por la
referencia al EJB requerido. Todas las interacciones con JNDI
y las interfaces Home son delegadas al localizador de
servicios. El siguiente diagrama de secuencia muestra la
interacción entre el cliente, el localizador de servicios, la
implementación home y la implementación de negocio:
: Cliente
: Service
Locator
: InitialContext
fabrica :
Fabrica
oNegocio :
ObjetoNegocio
getInstancia()
[3] Kruchten, P., Modeling Component Systems with the
Unified Modeling Language In Proceedings of
International Workshop on Component Based
Engineering, Kyoto, Japan, April 25-26, 1998.
[4] Bent, K., Patterns Generate Architectures In
Proceedings of the 8th European Conference for
Object-Oriented Programming, Bologna, Italy, July 48, 1994.
[5] Shaw, M., Software Architecture: Perspectives on an
Emerging Discipline, First Edition ed. New Jersey:
Prentice Hall, 1996.
[6] Fayad, M. E. and Schmidt, D. C., "Object-Oriented
Application Frameworks," Communications of the
ACM, vol. 40, no. 10, pp. 32-38, Oct.1997.
new()
getObjetoNegocio()
lookup
fabrica:=new()
return fabrica
oNegocio:=getObjetoNegocio()
new()
return oNegocio
usa servivios de negocio
V. CONCLUSIONES
La tecnología de componentes surge como una necesidad de
mejorar la calidad y la productividad de las empresas
dedicadas al desarrollo de software. Sin embargo, este nuevo
paradigma y sus soluciones tecnológicas traen consigo una
serie de nuevas oportunidades y dificultades. La tecnología
Java brinda una de las opciones para generar soluciones, pero
no es por sí misma una solución, para lograrlo debe hacerse un
uso adecuado de ella. Por tanto, es importante aprovechar sus
oportunidades ubicadas del lado de la reutilización en un
marco de ingeniería de dominio, en conjunto con el desarrollo
de activos reutilizables como lo son las arquitecturas de
referencia, los frameworks, patrones, entre otros. De otro lado,
se deben vencer las debilidades que se ubican del lado de las
limitantes que la tecnología Java presenta, y entre ellas, la más
visible y que comparte con las otras tecnologías de
componentes, es su problema en la eficiencia reflejado en el
consumo de recursos, el cual se puede solventar con el uso de
prácticas de diseño adecuadas que permitan mejorar el
desempeño de las aplicaciones desarrolladas en la plataforma
J2EE.
VI. REFERENCIAS
[1] Szyperski, C., Gruntz, D., and Murer, S., Component
Software: Beyond Object-Oriented Programming
Pearson Education, 2002.
[2] Liskov, B., Program Development in Java:
Abstraction, Specification, and Object-Oriented Design
Pearson Education, 2000.
[7] Allamaraju, S., Beust, C., Davies, J., Jewell, T.,
Johnson, R., Longshaw, A., Nagappan, R., O'Connor,
D., Sarang, P. G., Toussaint, A., Tyagi, S., Watson, G.,
Wilcox, M., and Williamson, A., Professional Java
Server Programming J2EE Wrox Press Inc., 2001.