1. JSP y Servlets
1.1 JSPs
La tecnología JavaServer Pages (JSP) pertenece a la plataforma Java Enterprise Edition (Java EE). Esta tecnología permite la generación dinámica de contenidos web, como HTML, DHTML, XHTML y XML.
Un JSP es un documento de tipo texto que describe la manera de procesar una solicitud para crear una respuesta utilizando la plataforma Java, siendo el resultado final de la ejecución de la JSP, un documento con código HTML.
En una JSP se escribe el código HTML combinado con código Java, pero el código Java, normalmente, va encerrado entre "<%" y "%>".
Los JSP tendrán extensión .jsp, y serán ubicados dentro de un proyecto web. A pesar de parecerse a documentos HTML, detrás del escenario, una JSP se convierte en un programa compilado donde el HTML estático;simplemente se imprime en el stream de salida estándar asociado. Esto normalmente solo se hace la primera vez que se solicita la página y los desarrolladores pueden solicitar la página ellos mismos cuando la instalan, si quieren estar seguros de que el primer usuario real no tenga un retardo momentáneo cuando la página JSP sea traducida y compilada.
La siguiente figura es una página JSP en el servidor web y cuando se ejecute, se generará un documento con contenido HTML que será recibido por el cliente:
La siguiente figura muestra el documento HTML, recibido por el cliente al ejecutarse la JSP:
El cliente verá la ejecución del HTML en su PC de la siguiente forma:
Realmente, el cliente siempre recibirá un código HTML, por eso puede, inclusive, acceder desde un teléfono celular si este le permite navegar por Internet.
En un patrón de desarrollo Model - View – Controller las JSPs estarán en la View y los servlets en el lado de Controller.
Ejemplo:
Crear JSP en NetBeans.
Clic derecho al nombre del proyecto New-JSP.
Con los servlets se involucran muchas clases, a continuación, se señalan las clases más importantes de cada paquete. Para entender mejor la relación entre las clases notar que en las líneas punteadas en rojo se encuentran las herencias directas de clases o interfaces, y en negro, se encuentran las relaciones de uso entre clases.
Cuando un Servlet acepta una llamada de un cliente, recibe los dos objetos siguientes:
HttpServletRequest y HttpServletResponse son interfaces definidos en el paquete javax.servlet.http.
HttpServletRequest
Permite al Servlet acceder a la información como los nombres de los parámetros pasados por el cliente, el protocolo (esquema) que está siendo utilizado por el cliente, el nombre del host remoto que ha realizado la petición y la del server que la ha recibido.
HttpServletResponse
Proporciona al Servlet métodos para responder al cliente. Ejemplo Request,dopost,doget.
Usar sesiones en servlets es bastante sencillo: envolver la búsqueda del objeto sesión asociado con la petición actual, crear un nuevo objeto sesión cuando sea necesario, buscar la información asociada con una sesión, almacenar la información de una sesión, y descartar las sesiones completas o abandonadas.
Buscar el objeto HttpSession asociado con la petición actual.
Esto se hace llamando al método getSession de HttpServletRequest. Si devuelve null, se podrá crear una nueva sesión, pero es tan comúnmente usado que hay una opción que crea automáticamente una nueva sesión si no existe una ya. Solo se pasa true a getSession. Así, el primer paso, se parecerá a esta línea:
HttpSession session = request.getSession(true);
Buscar la información asociada con un Sesión
Los objetos HttpSession viven en el servidor, están asociados automáticamente con la petición de los clientes y cada cliente tiene su respectivo objeto Session. Estos objetos sesión tienen una estructura de datos interna, que permite almacenar un número de claves y valores asociados. Por ejemplo: asumiendo que CarritoVentas es alguna clase definida y que almacena información de ítem para su venta.
HttpSession session = request.getSession(true);
CarritoVentas item = (CarritoVentas) session.getAttribute("item");
if (item != null) {
calculosVenta(item);
}
Ejemplo Session
Se usa (él o alguna de sus variantes) en la gran mayoría de las interfaces de usuario.
Modelo
Vista: Se presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.
Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona específicamente esta capa de acceso a datos porque supone que está encapsulada por el modelo.
El objetivo primordial del MVC es la reutilización del código ya implementado. Esta tarea se facilita mucho si a la hora de programar tenemos la precaución de separar el código en varias partes que sean susceptibles de ser reutilizadas sin modificaciones.
Ejemplos
MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la página HTML, y el Controlador es el código que reúne la data dinámica y genera el contenido de la página.
El Modelo es representado por el contenido actual, que usualmente se encuentra almacenado en una base de datos o en archivos XML.
Fortalezas del MVC
El cliente verá la ejecución del HTML en su PC de la siguiente forma:
Realmente, el cliente siempre recibirá un código HTML, por eso puede, inclusive, acceder desde un teléfono celular si este le permite navegar por Internet.
En un patrón de desarrollo Model - View – Controller las JSPs estarán en la View y los servlets en el lado de Controller.
Ejemplo:
Crear JSP en NetBeans.
Clic derecho al nombre del proyecto New-JSP.
1.2 Servlet
Un Servlet es un documento que siempre se ejecuta por el lado del servidor y permite atender las peticiones de los clientes. Es el intermediario entre la vista y las operaciones que el cliente solicita se realicen con la base de datos. En los servlets se pueden apreciar claramente los 3 sucesos siguientes:- Inicializar un Servlet: Cuando un servidor web carga un Servlet, se ejecuta el método init del Servlet. La inicialización se completa antes de manejar peticiones de clientes y antes de que el Servlet sea destruido. Aunque muchos Servlets se ejecutan en servidores multi-thread, no tienen problemas de concurrencia durante su inicialización. El servidor llama solo una vez al método init, cuando carga el Servlet y no lo llamará de nuevo, a menos que se vuelva a recargar el Servlet. El servidor no puede recargar un Servlet sin primero haber destruido el Servlet llamando al método destroy.
- Interactuar con clientes: Después de la inicialización, el Servlet puede manejar peticiones de clientes. Estas respuestas son manejadas por la misma instancia del Servlet, por lo que hay que tener cuidado con acceso a variables compartidas por posibles problemas de sincronización entre requerimientos concurrentes.
1.3 Destruir un Servlet
Los servlets se ejecutan hasta que el servidor los destruye, por cierre del servidor o bien a petición del administrador del sistema. Cuando un servidor destruye un Servlet, ejecuta el método destroy del propio Servlet. Este método se ejecuta una sola vez y puede ser llamado cuando aún queden respuestas en proceso, por lo que hay que tener la atención de esperarlas. El servidor no ejecutará de nuevo el Servlet, hasta haberlo cargado e inicializado de nuevo.Con los servlets se involucran muchas clases, a continuación, se señalan las clases más importantes de cada paquete. Para entender mejor la relación entre las clases notar que en las líneas punteadas en rojo se encuentran las herencias directas de clases o interfaces, y en negro, se encuentran las relaciones de uso entre clases.
Cuando un Servlet acepta una llamada de un cliente, recibe los dos objetos siguientes:
- Un HttpServletRequest que encapsula la comunicación desde el cliente al servidor.
- Un HttpServletResponse que encapsula la comunicación de vuelta desde el Servlet hacia el cliente.
HttpServletRequest y HttpServletResponse son interfaces definidos en el paquete javax.servlet.http.
HttpServletRequest
Permite al Servlet acceder a la información como los nombres de los parámetros pasados por el cliente, el protocolo (esquema) que está siendo utilizado por el cliente, el nombre del host remoto que ha realizado la petición y la del server que la ha recibido.
HttpServletResponse
Proporciona al Servlet métodos para responder al cliente. Ejemplo Request,dopost,doget.
1.4 HttpSession
Una sesión se inicia cuando un cliente ingresa con su navegador al Site y termina cuando se cierra el navegador o se dirige a otro Site. Para esta sesión, existe un objeto Session el cual, permite manejar recursos de memoria, a fin de guardar y recuperar datos en él, además de algunos métodos que facilitan las operaciones.Usar sesiones en servlets es bastante sencillo: envolver la búsqueda del objeto sesión asociado con la petición actual, crear un nuevo objeto sesión cuando sea necesario, buscar la información asociada con una sesión, almacenar la información de una sesión, y descartar las sesiones completas o abandonadas.
Buscar el objeto HttpSession asociado con la petición actual.
Esto se hace llamando al método getSession de HttpServletRequest. Si devuelve null, se podrá crear una nueva sesión, pero es tan comúnmente usado que hay una opción que crea automáticamente una nueva sesión si no existe una ya. Solo se pasa true a getSession. Así, el primer paso, se parecerá a esta línea:
HttpSession session = request.getSession(true);
Buscar la información asociada con un Sesión
Los objetos HttpSession viven en el servidor, están asociados automáticamente con la petición de los clientes y cada cliente tiene su respectivo objeto Session. Estos objetos sesión tienen una estructura de datos interna, que permite almacenar un número de claves y valores asociados. Por ejemplo: asumiendo que CarritoVentas es alguna clase definida y que almacena información de ítem para su venta.
HttpSession session = request.getSession(true);
CarritoVentas item = (CarritoVentas) session.getAttribute("item");
if (item != null) {
calculosVenta(item);
}
Ejemplo Session
2. Modelo – Vista - Controlador (MVC)
Este patrón fue descrito por primera vez por Trygve Reenskaug en 1979, y la implementación original fue realizada en Smalltalk en los laboratorios Xerox. MVC se basa en la separación de la aplicación en tres capas principales: modelo, vista y controlador.Se usa (él o alguna de sus variantes) en la gran mayoría de las interfaces de usuario.
Modelo
- Es la representación específica del dominio de la información sobre la cual funciona la aplicación.
- El modelo es otra forma de llamar a la capa de dominio.
- La lógica de dominio añade significado a los datos; por ejemplo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o portes en un carrito de la compra.
Vista: Se presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.
Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona específicamente esta capa de acceso a datos porque supone que está encapsulada por el modelo.
El objetivo primordial del MVC es la reutilización del código ya implementado. Esta tarea se facilita mucho si a la hora de programar tenemos la precaución de separar el código en varias partes que sean susceptibles de ser reutilizadas sin modificaciones.
Ejemplos
- Los datos de una hoja de cálculo pueden mostrarse en formato tabular, con un gráfico de barras, con uno de sectores.
- Los datos son el modelo.
- Si cambia el modelo, las vistas deberían actualizarse en consonancia.
- El usuario manipula el modelo a través de las vistas (en realidad, a través de los controladores).
MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la página HTML, y el Controlador es el código que reúne la data dinámica y genera el contenido de la página.
El Modelo es representado por el contenido actual, que usualmente se encuentra almacenado en una base de datos o en archivos XML.
Fortalezas del MVC
- Se presenta la misma información de distintas formas.
- Las vistas y comportamiento de una aplicación deben reflejar las manipulaciones de los datos de forma inmediata.
- Debería ser fácil cambiar la interfaz de usuario (incluso en tiempo de ejecución).
- Permitir diferentes estándares de interfaz de usuario o portarla a otros entornos no debería afectar al código de la aplicación.
3. Objetos de transferencia de datos
En el patrón de arquitectura Model View Controller (MVC), se necesita pasar datos encapsulados entre las diversas capas de programación, para ello se podrá utilizar lo siguiente:- Data Transfer Object (DTO)
- Object Domain (OD)
- View Object (VO)