Este articulo lo realice en el año 2009 como una presentación - explicación de algo tan básico que muchos consideramos como "commodity", sin embargo en muy pocas escuelas, cursos etc, logran explicar realmente el concepto. Así que apesar que el escrito ya tiene sus años, quisiera  redocumentarlo para cualquier referencia que se le pueda dar.

Como estudiante de tecnología java en todas sus facetas, siempre he encontrado modelos y patrones de arquitectura, por lo cual, para mí, está excelente. El único problema que tuve al inicio

fue la definición "Tier" y cómo en la vida práctica se dividen.Es por eso, que he hecho este escrito, ya que puede ayudar a alguien a entender un poco mejor la

arquitectura empresarial, y en específico, la arquitectura para Web.

Por lo tanto, explicaré que son los Tiers (Web Tier, Client Tier, etc.), cuales son sus responsabilidades y como en la vida práctica de un programador podría mejorar su desarrollo, todo esto, enfocado al desarrollo web.

Aunque hay mucho tema que abarcar en cada punto, éste escrito únicamente está intencionado a ser una introducción y comprensión rápida sin llegar a ser muy técnica. Por lo que al final habrá referencias especializadas para una mayor lectura. 

En caso que alguien quiera comentar, dar sugerencias, correcciones, agregaciones o de plano

contradecir, con todo gusto pueden contactarme.

Durante los años la arquitectura de las redes y los sistemas ha evolucionado.

En el inicio solo existían terminales tontas conectadas a un Main Frame.

Después surgieron las computadoras personales, las cuales corrían aplicaciones siendo totalmente

autistas, esto es, que no se compartían los datos de una con otra. En los 90s se extendieron las aplicaciones de escritorio para que pueda comunicarse y guardar datos

en un servidor central; Sin embargo, conforme fue evolucionando la tecnología, fueron surgiendo

varios tipos de clientes, lo cual evolucionó a la arquitectura de Internet.

Ahora, con la perspectiva empresarial, han surgido muchas teorías, patrones y modelos de arquitectura, las cuales son usadas en casos específicos, no obligando a que una sola sea totalmente

efectiva o totalmente errónea. Y una de éstas tantas es la que está enfocada en desarrollo java Web,

la cual está basada en Tiers.

Primeramente, considero importante aclarar la terminología "tier" ya que con una mejor comprensión de su significado, muchas ideas se pueden aclarar. En ingles se llaman "tiers" y en español se traduce muchas veces como "capas" lo cual está un tanto incorrecto. Si imaginamos una cebolla, donde existe una capa superior y se quita, hay una capa interna, etc. Esta traducción es correcta cuando hablamos de capas lógicas en un servidor: existe la capa de la aplicación, que debajo de esa está la de servicio y debajo de ésta la del protocolo, y debajo la del sistema operativo, etc... Pero cuando hablamos de tiers, no son capas, son más bien filas o hileras.

Haciendo una similitud, como en el cine hay hileras de butacas donde están las hileras de enfrente, luego las de en medio y las de atrás, pero no están en forma de capas. Así es como debemos

entender los tiers; y de esta manera, existe un tier de cliente, un tier de web, de aplicación, de persistencia y de base de datos; y dentro de cada una de estas hileras existe una función específica.

Así que durante este escrito usaré hileras o filas indistintamente.

Para empezar tenemos que entender cómo funcionan las filas (tiers) y cuáles son sus responsabilidades, ya que es básico para un desarrollo profesional; esto cumplirá la regla de alto acoplamiento (tight coupling) lo cual significa que cada clase debe tener un nicho de funciones únicamente, en otras palabras, deberá hacer ciertas tareas y no varias; entre más especializado esté una clase, mejor diseñado está el sistema y tendrá menos problemas y será más fácil de solucionar situaciones futuras.

Existen dos modelos para desarrollar Web: web centric y ejb container

Es un modelo basado en 3 "tiers", hileras:

1. Una para el cliente,
2. otra donde se juntan la de presentación y la de negocio, a ésta se le conoce como Web Tier; 
3. y otra para los recursos (base de datos o cualquier repositorio).

La fila de Cliente (Client Tier) es la hilera donde se ejecutan procesos del lado del usuario; aquí se encuentra lo que corre en el navegador; esto puede ser javascript, applets, Ajax, web start, etc.

La hilera de Presentación es lo que se ejecuta del lado del servidor web que está manejado por un contenedor Web, como Tomcat.

Aquí se encuentran los archivos jsp y servlets.

Business Tier es la hilera que ejecutará procesos de negocio, pero debido a que se encuentra en el mismo Web Tier, junto con la de Presentación, entonces, en este caso, deberá haber una

carpeta o paquetes donde estén los servlets y otros paquetes donde estén los servicios. Esto se encuentra manejado dentro del mismo contenedor web (tomcat, etc).

Por lo tanto, cuando una petición del navegador llega al servidor, ésta la recibe un servlet que su función es únicamente la recolección de los datos del navegador, y decidir a que clase de servicio

llamará, y por último decidir que jsp de respuesta mandará al navegador.

Aunque explicaré el otro modelo también (EJB Contrainer), el resto de este documento será específico para este modelo Web Centric, por lo que no usaremos ejbs sino clases Javas como

servicios; aunque, en otro escrito ya se evolucionará esta presentación a EJB 3.0 y JPA

Este modelo consiste en la división del Web Tier en dos hileras más, por lo que tenemos 4 hileras:

1. La hilera de Cliente sigue siendo para el navegador y los procesos que corren dentro de él.
2. La de Presentación está asignada para el contenedor Web y aquí residirán los jsp y servlets.
3. La hilera de Negocio está reservada para clases de negocio, ejbs de sesión, de mensajes, o web service, etc. Éstos componentes tendrán la responsabilidad de ejecutar las reglas de negocio. En esta hilera vive un contenedor de aplicaciones como JBoss, Glassfish, etc.
4. Por último está la hilera de Recursos, en la cual vive el repositorio de datos, ya sea una base de datos, archivos, ftp, ldap, etc.

En la práctica esto funciona de la siguiente manera:

1) El navegador manda una petición al contender web.

2) El contenedor web detecta la petición y se lo manda a un servlet para su ejecución.

3) El servlet obtiene los datos de la petición, y por medio de JNDI hace una búsqueda al servicio (ya

sea ejbean o web service).

4) Por medio de RMI manda objetos y ejecuta remotamente el método.

5) En la hilera de negocio, el ejbean hace todas las validaciones de negocio y ejecuta las reglas.

6) Llama a clases DAO, asignadas para la intervención con la base de datos.

7) Los daos hacen la tarea especifica dentro de la bd.

8) El ejbean termina su ejecución y manda una respuesta al servlet.

9) El servlet recibe o no, la respuesta del ejbean y decide que jsp regresa como respuesta al

navegador.

Obviamente existen muchos otros modelos, que pueden usarse fuera o dentro del concepto web, así que para mayor referencia se puede consultar una excelente página de Chad Z. Hower: http://www.codeproject.com/KB/architecture/TierPressure.aspx

Pero en general el modelo EJB Container puede ser la base para los demás, ya que éste puede

crecer para que se pueda hace una aplicación de escritorio, la cual residirá en la hilera de Cliente y se

pueda comunicar directamente con los ejbs del lado del Negocio.

O expandir el lado del negocio para crear una capa de web services, los cuales expondrán al mundo

entero las funcionalidades de negocio de los ejbs pero en formato XML; así que cualquier cliente

pueda comunicarse con el sistema.

Como habíamos dicho, el web container está compuesto por:

• servlets que su función será de controladores de la vistas,
• Jsp, que serán las vistas,
• EJB o clases de servicio que realizarán el negocio,
• Pojos que serán las entidades de negocio,
• DAOS las cuales serán las responsables de la conexión a la base de datos y realizar el CRUD (create,
• retrieve, update, delete).
• Y clases de utilería y librerías.

Como recomendación, se puede dividir en las siguientes carpetas:

1) /web/*

en esta carpeta estarán los html, imágenes, .js, .css

2) /web/jsp/*

Aquí vamos a meter los jsp

3) /src/servlets

Únicamente servlets

4) /src/pojos

Meteremos las clases pojos

5) /src/daos

Meteremos las clases responsables de la persistencia en la base de datos

6) /src/services

Clases que harán la lógica del negocio (como si fuera el business tier)

7) /src/utils

Clases extras

Los Jsp son las vistas para el cliente dentro del modelo MVC.

Estos JSP están compuesto de html y acciones o comandos de java, pero que sufren una transformación de la JVM para que al llegar al navegador no se vea nada de código java, sino que ya se haya ejecutado en el lado del servidor.

Se usan como páginas html dinámicas, aunque en el fondo son "servlets modificados", pero eso es otro tema y que seguramente se abarcará en otro escrito.

Por lo tanto, se pueden ver a los jsp, que cuando están del lado del servidor son documentos html con comandos java los cuales se ejecutarán antes de enviarse al navegador como una respuesta; y del lado del navegador, son páginas HTML puras.

Los servlets tienen la responsabilidad únicamente de recopilar los datos del navegador, validar que se tengan los necesarios y el tipo correcto y después mandar a llamar al servicio correspondiente (los

que están en /src/services o al ejb o webservice de la Business Tier) y finalmente mostrar el jsp de respuesta. Así que en general fungirán como Controladores del modelo MVC; por lo que serán el

único punto de comunicación con el cliente.

Ej. En el navegador llenas un formulario para crear un Cliente nuevo, con campos Nombre, apellidos, sexo y edad. Entonces el servlet debe obtener estos valores del httpRequest y llenar un Pojo Cliente (cliente.setNombre(request.getParameter("nombre")); )

Una vez lleno el pojo se lo mandas al servicio:

ClienteServicio.crear(cliente);

Al final regresará el jsp que queremos:

Los pojos se traducen como Plain Old Java Objects y únicamente son clases de negocio: Clientes, Categorias, Productos, etc.. aunque también son conocidos como Entities, o entidades.

En caso que necesitemos crear clases extras como MyException, esa se meteria en /src/utils, ya que no serían parte del negocio.

Hay que recordar que cuando se habla de clases de negocio o de clases de persistencia, significa que son objetos que se guardarán en la base de datos, osea que hay una tabla para cada pojo, etc.

Algo muy importante de los pojos es que TODAS sus propiedades son prívate y se tienen que hacer funciones de acceso y modificación por cada propiedad, a lo que se les conoce como getter y setters.

Además que debe tener el constructor sin argumentos.

Son clases responsables de la conexión a la bd y llamadas en sql. Una de sus practicidades es que si en algún momento se cambia de framework de ORM, como hibernate, NO habrá que cambiar nada más, únicamente estas clases.

Existe un DAO para cada Pojo (por lo regular) y contiene métodos especializados para cada acción que se quiera realizar en la bd con esa clase de negocio. Además, estas clases son responsables de abrir y cerrar la conexión a la base de datos; y para crear una conexión se puede usar una clase Factory la cual contendrá el string, búsqueda en el contexto, etc, para iniciar el data source.

Los servicios son las clases encargadas de realizar la lógica de negocio y es recomendable tener una clase servicio por cada Pojo que existe y dentro habrá funciones específicas para cada acción que se

puede hacer con ese pojo; o por otro lado, tener un servicio por cada caso de uso y métodos por cada escenario.

EJ. La clase ClienteServicio tendrá las funciones crear, modificar, eliminar, clonar, buscar, obtenerTodos, verificar, etc.

Estos servicios NO accesan directamente a la bd, sino que usa a los daos para eso.

Así que para finalizar, hemos visto los 2 diferentes tipos de modelos de arquitectura para web, los cuales se resumen en tener componentes especializados para cada una de las hileras del proceso. Jsp para el cliente, servlets para el web tier que sean la cara al cliente, los servicios que son parte del proceso de negocio y los de acceso a la base de datos, los cuales están encargados la conexión y acceso al repositorio.

Por lo que es muy importante tener siempre en cuenta esta división de trabajo, al momento de diseñar nuestros sistemas, ya que serán mucho más confiables, seguros, mantenibles y al seguir estándares de arquitectura, son escalables.

Componentes: