Web Tiers: Explicación

publicado a la‎(s)‎ 31 ago. 2012 9:44 por Eliu Montoya   [ actualizado el 20 sept. 2012 21:54 ]
Tema
: Explicación sobre el concepto "tiers" en proyectos web.
Categoría: Explicación concreta / Diseño en Java Web
Tecnologías / Componentes: Servlets
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.


1. Justificación

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.

2. Introducción

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.

3. 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.

Importante

Los "tiers" no son capas, son hileras

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.

3.1 Modelos

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

3.1.1 Web Centric

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

3.1.2 EJB Container

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.

3.1.3 Otros Modelos

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.

4 Componentes de un Web Tier

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



4.1 Jsp

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.



4.2 Servlets

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:



4.3 Pojos

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.




4.4 Daos




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.



Por lo que las ventajas de los DAOs son:

  • La lógica del neogocio con la del acceso a la base de datos están separadas.
  • Promueven el reuso y la flexibilidad de ser cambiadas o modificada



4.5 Servicios

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.

5. Conclusión

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.

6 Referencias


Componentes:

 

Post Similares

TituloDescripciónCategoriaTecnologíasTipoFecha de publicación
Subversión y Jenkins: cómo comunicarse entre ellos Como poder indicarle a Jenkins iniciar una actividad cuando Subversion ha sido actualizado Integración continua Subversion, Jenkins Tip 17 de septiembre de 2012 
Jenkins & Sonar: Status en jenkins refleje alertas de sonar Cómo poder mostrar en Jenkins el status real dependiendo de las alertas de Sonar Integración continua Subversion, Jenkins Tip 29 de agosto de 2012 
Web Tiers: Explicación Explicación sobre el concepto "tiers" en proyectos web. Diseño Servlets Explicación 1 de septiembre de 2009 
Tipo de Pruebas para Desarrollo de Software Explicación sobre los diferentes tipos de pruebas que se pueden hacer en el desarrollo de software Calidad XUnit, Sonar, PMD, Findbugs, Thucydides, Checkstyle, Cobertura Explicación 11 de septiembre de 2012 
Integración Continua: Promociones y Líneas de Producción  Explicación del concepto de promociones y pipelines en Integración Continua Integración continua Jenkins y plugins Explicación 27 de septiembre de 2012 
Mostrando 5 elementos de la página Indice de posts ordenados por hora de edición. Ver más »

Ċ
Eliu Montoya,
31 ago. 2012 9:44
Comments