Taller de Sistemas de

Informacin 2

Clase 5
Patrones J2EE

Patrones de Desarrollo

Existen mltiples patrones a la hora de desarrollar

componentes J2EE

No todos son necesarios para un desarrollo
eficiente y eficaz

Algunos de los mas destacados son:
 Business Delegate
 Session Facade
 Service Locator
 Data Access Object
 Transfer Object
 Front Controller
Data Access Object

El acceso a los datos varia mucho segn la

fuente de informacin

Puede ser relacional, orientada a objetos,
XML, archivos planos, etc.
 Aun dentro de la categora relacional, puede
variar la semntica del SQL para el acceso

SQL Server, Oracle, DB2, Informix, MySQL,
PostgreSQL
 Existen APIs como JDBC que permiten abstraer
este acceso a la informacin

Data Access Object

Las componentes J2EE pueden acceder a las APIs

apropiadas para acceder a la fuente de datos

Esta accin introduce alto acoplamiento entre el
componente y la fuente de datos subyacente

Este acoplamiento complica el mantenimiento y
posterior migracin a una nueva fuente de datos

Ejemplos de esto son componentes en los cuales el
cdigo SQL se encuentra embebido en el cdigo

Se necesita abstraer y encapsular todo esto
Data Access Object

Se define un componente, el DAO

Abstrae y encapsula TODO el acceso a una fuente
de datos

El DAO administra la conexin con la fuente de
datos a fin de obtener y guardar datos

Implementa el mecanismo de acceso requerido para
acceder a la fuente de datos
 Por lo general es SQL
 Pero puede ser cualquier tecnologa (LDAP)

El DAO acta de adaptador entre el componente y
la fuente de datos

Data Access Object

Data Access Object

Algunas consecuencias
 Aumenta la transparencia

Los objetos de negocio no conocen la fuente de datos

Los detalles de implementacin se esconden en el DAO
 Facilita la migracin

Debido al desacoplamiento de la fuente de datos

Si utilizamos estrategias como factories o generaciones
automticas, puede hacerse casi sin cambios de cdigo
 Reduce la complejidad en los objetos de negocio

Todo el cdigo relativo a la fuente de datos queda en el DAO

Las excepciones y casos particulares debido a estos, no
tienen porque considerarse
Data Access Object

Algunas consecuencias
 Centraliza todo el acceso a datos en una nueva capa

El conjunto de DAOs puede verse como una capa de
aislamiento para toda la aplicacin

Esta centralizacin facilita el cambio y migracin
 No es til si usamos CMP

No necesitan un DAO, ya que todo el acceso es resuelto por
el contenedor

Son tiles si usamos BMP o Session Beans con acceso a
datos
 Introducen una nueva capa

Esta capa produce un impacto en la performance del sistema

Data Access Object: Ejemplo

Data Access Object: Ejemplo

Transfer Object

Las aplicaciones cliente necesitan intercambiar

datos con las aplicaciones empresariales

Cuando un cliente invoca una funcionalidad en un
EJB, esta potencialmente es remota

Sin importar la proximidad del cliente, se crea una
conexin de red, con el costo que esto implica

A medida que este uso remoto de los mtodos de
negocio aumenta, la performance se degrada

En general, un cliente necesita un conjunto de
datos, y no atributos independientes
Transfer Object

Creamos un objeto, que sirve para acarrear

informacin entre cliente y servidor

Este objeto encapsula los datos de negocio

Cada llamada remota es usada para enviar y recibir
el Transfer Object

En general, cuando el cliente pide un dato a un EJB
 El EJB crea el Transfer Object
 Lo carga de datos
 Lo devuelve al cliente

El uso de estos objetos disminuye el costo por
mltiples pedidos de atributos relacionados
 Pero aumenta el costo si el tamao del objeto es grande

Transfer Object

Cuando el cliente accede a un TO, las llamadas a
sus mtodos son locales, por lo que el costo de red
no existe
Transfer Object

Consecuencias
 Simplifica las interfaces remotas y locales para los entity
beans

No necesita proveerse un setter/getter para cada atributo

Puede usarse un TO para actualizar y obtener todos los datos
del componente
 Transfiere mas datos, con menos llamadas remotas

Reduce el trafico de red
 Puede generar problemas con mltiples copias obsoletas
de lo TO
 Puede generar problemas si el nivel de aislamiento de las
transacciones no es Serializado
Session Facade

En J2EE, los EJB encapsulan datos y servicios,

exponiendo las interfaces a los clientes

Este proceso expone la complejidad de un sistema
distribuido a los clientes

Aparecen los siguientes problemas
 Alto acoplamiento, entre clientes y objetos de negocio
 Muchas invocaciones entre cliente y objetos de negocio

Esto lleva a alto consumo de red
 Falta de uniformidad al acceder a los objetos de negocio

Esto puede llevar a un mal uso de los objetos de negocio

Session Facade

Usamos un Session Bean como fachada

para encapsular las interacciones entre los
objetos de negocio

Administra los objetos de negocio y provee
una interfaz coarse-grained a los clientes

Solo se proveen las interfaces requeridas,
evitando complejidades innecesarias a los
usuarios de la misma
Session Facade

Session Facade
Session Facade

Existen variantes en la implementacin

 Stateless

Esta es la opcin cuando el cliente no requiere establecer una
conversacin con el EJB
 Stateful

Si el cliente requiere mas de una invocacin para llevar a
cabo una funcionalidad, debemos tener un EJB stateful

El rol de los objetos de negocio puede ser llevado a
cabo por mltiples tipos de objetos

Son todo equivalentes, pero cada uno tiene
ventajas y desventajas

Session Facade

Session Beans
 Los objetos de negocio pueden implementarse
como Session beans
 En general proveen servicios, pero pueden
tambin proveer datos

En este ultimo caso, podemos usar DAO
 La Session Facade puede agrupar varios de
estos Service Oriented o Data Oriented
session beans
Session Facade

Entity Beans
 Los objetos de negocio se representan como
Entity Beans
 Cuando mltiples Entity Beans participan en un
caso de uso, no es necesario exponerlos al
cliente
 La Session Facade los agrupa a todos, brindando
un mtodo para llevar a cabo la funcionalidad de
negocio planeada
 La complejidad de interaccin entre EB queda
escondida al cliente

Session Facade

Data Access Objects

 La Session Facade puede usar directamente uno
o mas DAOs para representar los datos de
negocio
 Este enfoque es comn cuando la aplicacin es
pequea y no requiere entity beans o posee
pocos session beans
 El uso de DAOs parcialmente simula la
persistencia a travs de entity beans
Session Facade

Consecuencias
 Introduce una capa de negocio que acta como
controller

Administra las interacciones entre cliente y objetos de
negocio

Si la aplicacin es pequea, puede parecer que no
aporta valor

A medida que la aplicacin crece, el uso de la fachada
favorecer la arquitectura del sistema
 Expone una interfaz uniforme al cliente

La complejidad subyacente se abstrae, y solo se
exponen los mtodos especficos que un cliente usa

Session Facade

Consecuencias
 Reduce el acoplamiento, por lo que aumenta la flexibilidad

Los clientes no conocen directamente a los objetos de
negocio

Mientras la fachada no cambie, los clientes no tienen porque
enterarse de cambios estructurales
 Aumenta la performance, ya que disminuye los mtodos
pequeos
 Provee acceso coarse-grained
 Centraliza la administracin de seguridad y transacciones
 Expone menos interfaces remotas a los clientes
Service Locator

La arquitectura J2EE es altamente desacoplada

Esto implica mltiples servicios, ejecutando en forma distribuida

Para llevar a cabo una funcionalidad, debemos localizar
servicios e invocarlos
 Estas son operaciones particularmente complejas

 Para localizar un EJB debemos

Establecer una comunicacin con un servicio de nombres (va JNDI)

Localizar la home interfase

Buscar el bean o crearlo
 Si este proceso se repite para cada tipo de bean y es solicitado
por mltiples clientes, las operaciones se tornan costosas

A esto debemos sumarle particularidades introducidas por el
proveedor de la herramienta

Service Locator

Creamos un objeto, que se encargue de:

 Abstraer todo el uso de JNDI
 Esconder la complejidad de:

Establecimiento del InitialContext

Lookup de la interfaz home

Creacin de EJBs
 Mltiples clientes pueden favorecerse de este objeto,
brindando un nico punto de acceso a los EJBs
 Si a esto sumamos una facilidad de cache, la performance
del sistema aumenta

Evitamos bsquedas repetidas del mismo EJB
Service Locator
Service Locator

Consecuencias
 Abstrae la complejidad
 Provee un acceso uniforme a los servicios por
parte de los clientes
 Facilita la incorporacin de nuevos componentes
de negocio
 Aumenta la performance de red (evitar la creacin
de home/remote)
 Aumenta la performance (cache)

Business Delegate

A pesar del uso de Session Facade, los clientes an

quedan expuestos a los componentes de negocio
distribuidos
 Mltiples fachadas implementadas como SB

En general, la capa de presentacin accede a los
servicios de negocio

Una interaccin directa entre la capa de
presentacin y estos componentes, hace vulnerable
la capa de presentacin
 Especialmente ante cambios de la capa de negocios
Business Delegate

Asimismo, no es deseable exponer la naturaleza

distribuida del negocio a la capa de presentacin

Un acceso directo a los componentes de negocio,
puede implicar un uso excesivo de red

Para esto, creamos un nuevo componente, el
business delegate

Reduce el acoplamiento entre la capa de
presentacin y los servicios de negocio

El Delegate esconde aspectos de la arquitectura
EJB a la capa de presentacin, como ser lookup y
acceso

Business Delegate
Business Delegate

Business Delegate

Consecuencias
 Reduce el acoplamiento, aumenta la flexibilidad
 Permite traducir excepciones a nivel de negocio
 Permite implementar recuperacin de fallas y
sincronizacin de hilos
 Simplifica y uniformiza aun mas la interfaz de
negocio
 Mejora la performance (si cachea)
 Impacta en la performance (+ capas)
 Esconde la naturaleza distribuida de un sistema
Front Controller

La capa de presentacin debe administrar y

coordinar el procesamiento de los usuarios

Este procesamiento suele involucrar mltiples
requests/responses

Este control puede realizarse en forma centralizada
o descentralizada

Se requiere un punto de acceso centralizado en el
sistema para:
 Acceso a servicios del sistema
 Recuperacin de contenidos
 Administracin de las vistas (MVC)
 Navegacin

Front Controller

Si un usuario accede directamente a la vista,

sin pasar por el mecanismo centralizado,
pueden existir dos problemas
 Cada vista debe proveer sus propios servicios del
sistema (duplicacin de cdigo)
 La navegacin es dejada en manos de la vista, lo
que dificulta la misma y su posterior
mantenimiento
 El control distribuido, es mas difcil de llevar a
cabo, ya que los cambios deben realizarse en
mltiples lugares
Front Controller

Creamos una clase (un controller) que oficie como

punto de atencin inicial para un request

Este procesa el request, invocando si se necesitan,
servicios de sistema
 Seguridad
 Autenticacin

Luego, delega a clases especializadas el
procesamiento relativo a:
 Negocio
 Seleccin de una vista apropiada
 Errores
 Seleccin de contenido

Front Controller
Front Controller

El sistema no esta limitado a utilizar un solo

controlador.

Para distintos tipos de servicios, se pueden
utilizar diferentes controladores.

Consecuencias
 Centraliza el control de la capa de presentacin
 Mejora la administracin, seguridad y
mantenimiento
 Aumenta la reutilizacin
Algunas arquitecturas J2EE

No siempre una aplicacin debe usar todo el stack

J2EE para ser exitosas

Existen alternativas, especialmente para las web
applications
 Con pocas modificaciones, podemos llevar estas a
cualquier tipo de aplicacin

Los elementos bsicos con que se construyen los
sistemas son
 Servicios de negocio
 Presentacin
 Acceso a datos

Capa de servicios de negocio

Expone la lgica de negocio a los clientes

Esta capa debera:
 Ser completa

Exponer todo lo que el cliente necesita

Pueden ser diferentes interfaces (API), segn el tipo de
cliente
 Ser simple:

Debe resolver la lgica de negocio

La complejidad solo debera provenir del negocio

No de la implementacin
Capa de servicios de negocio

Esta capa debera:

 Ser definida en base a interfaces

Bind to interface
 Ser independiente de la capa de presentacin
 Ser fcil de implementar
 No hacer asumpciones sobre la tecnologa de acceso a
datos subyacente
 Manejar transacciones
 Ser escalable horizontalmente

Nada debe impedir el clustering
 Ser fcil de testear

Capa de servicios de negocio

En general es implementada usando SLSB

 Son altamente escalables
 Si la situacin lo requiere, pueden llevarse en
SFSB o manejar los datos de sesin en la web
 Esta ultima opcin es mas escalable

En general los objetos de negocio y la capa
web deben estar en el mismo servidor
 A pesar de que se promueve la separacin,
hacerlo innecesariamente no presenta ventajas
 Lo que si queremos es una separacin fsica
Capa de presentacin

Cuidado con capas de presentacin muy cargadas

Se recomienda forzar el uso de capas delgadas

Uno de los frameworks mas comunes para la
construccin de una capa web, es MVC

Sin embargo, no existe un framework para los
objetos de negocio, como en el caso del MVC
 Los objetos de negocio tienden a ser agregado a la capa
de presentacin
 Esto altera el centro de gravedad de la aplicacio

Una solucin, es colocar los objetos de negocio en
la capa de presentacin
 Sin embargo, esto es un error de concepto

Capa de acceso a datos

Esta capa suele determinar la performance

de una aplicacin empresarial

Suele tambin ser un factor de xito o falla
de un proyecto

Los datos persistentes suelen estar en una
base de datos relacional
 Puede usarse mas de un repositorio
 Pueden usarse tecnologas alternativas (XML,
binarios, etc.)
Capa de acceso a datos

El uso de entity beans (1.1, 2.x) esta hoy dia

desaconsejado por la comunidad J2EE

Algunos problemas
 Dificultad en mantenimiento
 Complejidad excesiva
 Pobre performance
 Alta curva de aprendizaje

Algunas alternativas
 SQL
 Hibernate (O/R Mapping)
 JDO

Arquitecturas J2EE

J2EE clasica
 Existen mltiples clases, desparramadas en mltiples
JVMs
 Las clases, no se pueden co-localizar
 La capa de presentacin se resuelve usando MVC
 Los objetos de negocio son SLSBs ejecutando en un EJB
container, exponiendo interfaces remotas
 Los accesos a datos se resuelven usando entity beans

CMP con interfaces locales es lo actualmente aceptado
 Los datos sern almacenados en un manejador relacional
o en un sistema legado
Arquitecturas J2EE

Ventajas
 La interfaz remota provista por los EJB define
claramente la capa de servicios
 Los servicios declarativos en los SLSB son
beneficiosos
 Soporta varios tipos de clientes
 A veces, puede lograr escalabilidad al distribuir
los objetos de negocio
 La capa de negocios puede ser actualizada
independientemente de la capa de presentacin
Arquitecturas J2EE

Desventajas
 Tiene un overhead altsimo, tanto a nivel de desarrollo,
ejecucin y mantenimiento
 Sacrifica la OO frente a la distribucin
 Suelen ser difcil de testear

La clase de implementacin no se encuentra disponible

Es propietaria

Conclusin: No es una arquitectura recomendada

para la mayora de las web applications

Arquitecturas J2EE

J2EE local
 Existe una sola JVM
 Las clases se encuentran co-localizadas en esa JVM
 La capa de presentacin se estructura con MVC
 Los objetos de negocio se implementan con SLSBs
usando interfaces locales
 Debido a la simplificacin, la persistencia se realiza con un
O/R Mapper
 El almacenamiento de datos se hace igual que la anterior

DBMS

Sistemas legados
Arquitecturas J2EE

Ventajas
 Los problemas de distribucin desaparecen
 El acceso a los EJB es mas sencillo
 Se elimina la problemtica RMI

Desventajas
 No soporta distintos tipos de clientes, sin una
fachada de RMI
 Problemas de testing
 Continua la complejidad de la arquitectura en si
Arquitecturas J2EE

Adhoc, sin EJB

 Existe una sola JVM
 Las clases se encuentran co-localizadas en esa JVM
 La capa de presentacin se estructura con MVC
 Los objetos de negocio se implementan con objetos java
tradicionales (POJOs)
 Esto no afecta la separacin de conceptos (UI + lgica)
 El acceso a datos se hace a travs de O/R mapping o
DAOs (JDBC)
 Los datos se almacenan en RDBMS o aplicaciones
legadas
Arquitecturas J2EE

Ventajas
 Ejecutan en un servlet engine
 Mayor portabilidad (hardware, software, provider)
 Implementacin mas simple
 Pocos deployment descriptors
 Deployment mas gil

Desventajas
 Falta de soporte para remoting
 Falta de ambiente para manejo de servicios del sistema
 Falta de una clara capa de negocios (fachada)
 Transacciones, seguridad (manejadas por el usuario)