resultado=${var1}_$(date "+%d/%m/%Y_%H:%M:%S")
echo $resultado
La salida de este script es:
textoAConcatenar_03/07/2014_20:19:09
Se puede ejecutar el script on line desde http://www.compileonline.com/execute_bash_online.php
jueves, 3 de julio de 2014
Linux Script - Concatenar fecha y hora actual a un string
resultado=${var1}_$(date "+%d/%m/%Y_%H:%M:%S")
echo $resultado
La salida de este script es:
Se puede ejecutar el script on line desde http://www.compileonline.com/execute_bash_online.php
viernes, 27 de abril de 2012
Java Servlet
Servlet
Un servlet es una clase de Java que se utiliza para extender
las capacidades de lo servidores que alojan aplicaciones accesibles a través de
un modelo de programación request-response.
Aunque los servlets pueden responder a cualquier tipo de solicitud, se
utilizan comúnmente para extender las aplicacioens alojadas en servidores web.
Los paquetes javax.servlet y javax.servlet.http proveen
interfaces y clases para escribir servlets. Todos los servlets deben
implementar la interface Servlet que define los métodos del ciclo de vida. Cuando
implementamos un servicio genérico, se puede utilizar o extender la clase
GenericServlet con la API Java Servlet. La clase HTTPServlet proporciona
métodos, tales como doGet y doPost, para el manejo de los servicios específicos
de HTTP.
Ciclo de
vida del Servlet
El ciclo de vida del servlet está controlado por el
contenedor en donde el servlet ha sido desplagado. Cuando una solicitud es
mapeada a un servlet, el contenedor realiza los siguientes pasos:
1. Si una instancia del servlet no existe, el
contenedor web
a.
Carga la clase servlet
b.
Crea una instancia del servlet
c.
Inicializa la instancia del servlet llamando al
método init.
2. Invoca al método service,
pasando objetos request y response.
Si el contenedor necesita remover el servlet, llama al
método destroy.
Manejando
eventos en el ciclo de vida del Servlet
Se puede monitorear y reaccionar ante los eventos en el ciclo
de vida del servlet, definiendo objetos
listener cuyos métodos sean invocados cuando el evento ocurra. Para usar estos
objetos listener, se debe definir y especificar la clase listener.
Definiendo
la clase Listener
Se define una clase listener como una implementación de una
interfaz listener. La siguiente tabla muestra los eventos que pueden ser
monitoreados y las correspondientes interfases que deben ser implementadas. Cuando un método listener es invocado, se le
pasa un evento que contiene información apropiada para el evento. Por ejemplo,
los métodos en la interfase HttpSessionListener son pasados a HttpSessionEvent,
que contiene a HttpSession.
viernes, 26 de agosto de 2011
Seam - Capítulo 7
7 The conversation:Seam’s unit of work
Aquí el libro da un ejemplo sobre un llamado telefónico para hacer un reclamo donde en primer lugar el usuario es atendido por un telefonista y explica su problema, pasan su llamada a la sección Reclamos y nuevamente tiene que explicar todo desde el principio.
Así es exactamente como se manejan las solicitudes de una aplicación web, que descansa sobre un protocolo sin estado(HTTP). El resultado es que los datos tienden a caerse entre solicitudes de páginas, ciegos ante el caso de uso continuo.Seam reconoce que todas las solicitudes se producen en el ámbito de una conversación, una conversación que puede abarcar múltiples solicitudes, y que las conversaciones son subconjuntos de una sesión de usuario, como se ilustra en la figura 7.1.
Usted puede pensar en una unidad de trabajo en términos de una transacción de base de datos. Esta unidad de corta duración es problemática porque no tiene estado (en el sentido de larga duración). Seam redefine la unidad de trabajo mirándolo desde la perspectiva del usuario, acuñando lo que se conoce como una conversación. Durante una conversación, las transacciones de bases de datos, solicitudes de página, y otras unidades atómicas de trabajo pueden ir y venir, pero el proceso en general no se considerará completo hasta que el objetivo del usuario es llevado a cabo. En una conversación, el estado se dice que es extendido. El vínculo entre las solicitudes de página en una conversación es establecido mediante el uso de una ficha especial y una partición de la sesión HTTP. La vida de la conversación es controlada por las condiciones de frontera. En primer lugar, quiero centrarme en el reto de establecer un contexto de estado bien definido en una aplicación web y cómo esta tarea ha sido tradicionalmente manejada.
Todas las aplicaciones tienen estado, incluso aquellas clasificadas como sin estado (por ejemplo, las aplicaciones RESTful[1]).
Algunas aplicaciones esconden el estado fuera de los contextos del lado del servidor, tales como el ámbito de sesión HTTP o el ámbito de la página JSF. El llamado estado de las aplicaciones sin estado sólo tejen en la URL o esconden la basura en los campos de formulario oculto. La mayoría de las aplicación es probable que utilicen una combinación de estas estrategias. La verdadera pregunta es, ya que los usuarios navegan de una página a la siguiente, ¿cuánto apoyo reciben del framework para la gestión y el acceso a ese estado?
Estoy seguro de que en el pasado han trabajado muy duro para guardar los datos entre las solicitudes y, posteriormente, se preparan para su uso en la lógica de negocio. Ya sea que usted escribió una de esas aplicaciones que tiene campos de la forma más oculta de las visibles o uno con el mayor número de clases Struts ActionForm como componentes de negocio, ha sentido el peso de la gestión de estado. Eso no quiere decir que las URLs REST, campos de formulario ocultos, parámetros de la petición, o las cookies no son viables. Es sólo que cuando son medios para un fin, donde el fin es restaurar el estado de la solicitud anterior, causan un montón de trabajo. Seam intenta que el estado sea fácilmente disponible en los contextos que se acercan al ciclo de vida de ese estado (es decir, un caso de uso). No sólo el contexto de estado de la conversación se mezcla entre las solicitudes en la duración de un caso de uso, sino que evita la destrucción de la identidad de los objetos como resultado de la serialización, que es el principal problema con los enfoques tradicionales.
Algunas aplicaciones esconden el estado fuera de los contextos del lado del servidor, tales como el ámbito de sesión HTTP o el ámbito de la página JSF. El llamado estado de las aplicaciones sin estado sólo tejen en la URL o esconden la basura en los campos de formulario oculto. La mayoría de las aplicación es probable que utilicen una combinación de estas estrategias. La verdadera pregunta es, ya que los usuarios navegan de una página a la siguiente, ¿cuánto apoyo reciben del framework para la gestión y el acceso a ese estado?
Estoy seguro de que en el pasado han trabajado muy duro para guardar los datos entre las solicitudes y, posteriormente, se preparan para su uso en la lógica de negocio. Ya sea que usted escribió una de esas aplicaciones que tiene campos de la forma más oculta de las visibles o uno con el mayor número de clases Struts ActionForm como componentes de negocio, ha sentido el peso de la gestión de estado. Eso no quiere decir que las URLs REST, campos de formulario ocultos, parámetros de la petición, o las cookies no son viables. Es sólo que cuando son medios para un fin, donde el fin es restaurar el estado de la solicitud anterior, causan un montón de trabajo. Seam intenta que el estado sea fácilmente disponible en los contextos que se acercan al ciclo de vida de ese estado (es decir, un caso de uso). No sólo el contexto de estado de la conversación se mezcla entre las solicitudes en la duración de un caso de uso, sino que evita la destrucción de la identidad de los objetos como resultado de la serialización, que es el principal problema con los enfoques tradicionales.
PASAR DATOS A TRAVÉS DEL REQUEST
Un enfoque para propagar el estado es enviarlo como parte del request en una de las siguientes formas:
Un enfoque para propagar el estado es enviarlo como parte del request en una de las siguientes formas:
■ parámetros del request (es decir, campos de formulario ocultos o en la cadena de consulta)
■ Como parte de la URL (por ejemplo, / course/view/9)
■ Las cookies del navegador
Todas estas opciones de trabajo implican el desmontaje de un objeto del lado del servidor en pequeñas tiradas, un túnel a través de aquellas partes de la solicitud como valores string y a continuación, volver a montar los objetos en el servidor, como ilustra la figura 7.2.
Hay momentos en que una URL REST, un parámetro en la petición, o una cookie es la herramienta adecuada para el trabajo. Sin embargo, si se trabaja con cualquier sistema decente en el tamaño de los datos, tener que preparar esta traducción en cada petición es francamente aburrido.
Usted aprendió en el capítulo 3 que los parámetros de página Seam ofrecen algún alivio traduciendo automáticamente los objetos en parámetros de la petición HTTP en función de cada página.
La desventaja de los parámetros de página es que están atados a la definición de página. Pero como una página se puede utilizar en más de un conjunto de circunstancias, la configuración podría resultar en que se propagan los datos incluso cuando usted no lo necesita, o peor aún, se interpone en el camino.
El mayor inconveniente de parámetros basados en la propagación, en general, es que el objeto del lado del servidor pierde su identidad cuando se pasa a través de este embudo.El objeto que se construye en el servidor, más allá del límite de la solicitud, es un clon del objeto original, posiblemente un clon parcial.
La desventaja de los parámetros de página es que están atados a la definición de página. Pero como una página se puede utilizar en más de un conjunto de circunstancias, la configuración podría resultar en que se propagan los datos incluso cuando usted no lo necesita, o peor aún, se interpone en el camino.
El mayor inconveniente de parámetros basados en la propagación, en general, es que el objeto del lado del servidor pierde su identidad cuando se pasa a través de este embudo.El objeto que se construye en el servidor, más allá del límite de la solicitud, es un clon del objeto original, posiblemente un clon parcial.
Este proceso de clonación no permite la transferencia de un recurso que se basa en su identidad, como un gestor de persistencia o instancia de la entidad administrada. Para preservar la identidad de un objeto, el objeto debe ser almacenado en el lado del servidor, tal como el árbol de componentes JSF UI (que requiere guardar el estado del lado del servidor), la sesión HTTP, o como usted aprenderá pronto, la conversación. A continuación, sólo es necesario pasar un token en el servidor para restaurar el contexto y los objetosque contiene.
CÓMO GUARDAR EL ESTADO EN EL ÁRBOL DE COMPONENTES JSFI UI
Usted aprendió en el capítulo 4 que la raíz del árbol de componentes JSF UI tiene un mapa de atributos que se pueden utilizar para guardar los datos a través de una devolución de datos JSF.
Con el contexto de página de Seam y la etiqueta del componente de la biblioteca MyFaces Tomahawk
Usar el árbol de componentes UI como un contexto de estado tiene problemas que coinciden con los citados anteriormente. En primer lugar, se debe reestablecer el conjunto de variables en el contexto de la página cuando el árbol de componentes UI se vuelve a generar (lo que ocurre durante cualquier respuesta a una solicitud que hace una redirección o dibuja una vista diferente). El segundo problema es que el árbol de componentes UI no garantiza que la identidad de los objetos se mantiene. JSF puede guardar el estado ya sea en el lado del cliente o el lado del servidor. Cuando se guarda el estado del lado del cliente, los objetos restaurados son clones de los originales, teniendo el mismo problema que el paso de parámetros a través de la solicitud. Si usted no tiene control sobre la configuración que guarda el estado, lo mejor es no dejar el manejo de la identidad de un objeto en un terreno inestable.
El desafío de mantener la identidad del objeto a menudo se resuelve mediante el uso de la HttpSession.
Usar el árbol de componentes UI como un contexto de estado tiene problemas que coinciden con los citados anteriormente. En primer lugar, se debe reestablecer el conjunto de variables en el contexto de la página cuando el árbol de componentes UI se vuelve a generar (lo que ocurre durante cualquier respuesta a una solicitud que hace una redirección o dibuja una vista diferente). El segundo problema es que el árbol de componentes UI no garantiza que la identidad de los objetos se mantiene. JSF puede guardar el estado ya sea en el lado del cliente o el lado del servidor. Cuando se guarda el estado del lado del cliente, los objetos restaurados son clones de los originales, teniendo el mismo problema que el paso de parámetros a través de la solicitud. Si usted no tiene control sobre la configuración que guarda el estado, lo mejor es no dejar el manejo de la identidad de un objeto en un terreno inestable.
El desafío de mantener la identidad del objeto a menudo se resuelve mediante el uso de la HttpSession.
ALMACENAMIENTO DE DATOS EN LA SESIÓN HTTP
La sesión HTTP se puede utilizar para almacenar objetos arbitrariamente complejos preservando su identidad. Este contexto es compartido por todas las pestañas del navegador y las ventanas que restauran la misma sesión y dura típicamente del orden de horas o días. Si bien este mecanismo de almacenamiento parece ideal, es por desgracia, demasiado bueno para ser cierto. La principal desventaja de la sesión HTTP es que rápidamente se convierte en una maraña de datos que consume cantidades excesivas de la memoria y complica el uso de múltiples ventanas de la aplicación. Vamos a explorar estas cuestiones.
La sesión HTTP se puede utilizar para almacenar objetos arbitrariamente complejos preservando su identidad. Este contexto es compartido por todas las pestañas del navegador y las ventanas que restauran la misma sesión y dura típicamente del orden de horas o días. Si bien este mecanismo de almacenamiento parece ideal, es por desgracia, demasiado bueno para ser cierto. La principal desventaja de la sesión HTTP es que rápidamente se convierte en una maraña de datos que consume cantidades excesivas de la memoria y complica el uso de múltiples ventanas de la aplicación. Vamos a explorar estas cuestiones.
La sesión HTTP se adapta bien a los datos que desea conservar a través de todas las solicitudes realizadas por un usuario determinado, como la identidad del usuario. Sin embargo, la sesión no es un lugar bueno para almacenar los datos de un caso de uso específico. Puede parecer inofensivo cuando el usuario accede a la aplicación de una sola ventana, pero ¿qué ocurre cuando el usuario genera varias pestañas o ventanas? Debido a que el identificador de sesión se almacena como una cookie en el navegador del usuario, y la mayoría de las cookies se comparten entre las pestañas y ventanas (en adelante en forma de tabs), el resultado es que los múltiples tabs de comparten los mismos datos de la sesión. Si la aplicación no reconoce este hecho, puede ocurrir que los datos sean manipulados de maneras contradictorias.
NOTA: El identificador de sesión también se puede transmitir a través de la URL, conocida como la reescritura de URL. Cuando se utiliza la reescritura de URL, los enlaces que contienen el mismo identificador de sesión, restauran la misma sesión, incluso si se abre en una nueva pestaña.
Considere el caso de uso de actualizar un registro de un curso de golf (el libro trabaja con un ejemplo de una aplicación para un campo de golf). Supongamos que el curso de golf se almacena en la sesión HTTP, mientras que está siendo modificado. Si selecciona un curso a modificar en una pestaña del navegador y seleccionar un curso distinto a modificar en una pestaña en segundo lugar, la segunda selección de cursos en el servidor sobrescribe los primeros. Al hacer clic en Guardar en la primera pestaña, asumiendo que los cambios se aplican directamente en el registro de la sesión, sin darse cuenta, modificará la instancia de segundo curso. Las cosas se ponen aún más difícil si estás trabajando con un asistente de varias páginas, ya que la pérdida de datos puede ser menos evidente. Sin embargo, otro problema es que los datos de la sesión no están protegido contra el uso simultáneo, por lo que si dos solicitudes intentan acceder a datos de la sesión al mismo tiempo, puede llevar a una condición de carrera.
El problema más grave con el ámbito de la sesión es que en su mayoría no son administrados. Si los objetos siguen acumulándose en la sesion, y la aplicación no provee un recolector de basura, las pérdidas de memoria impactarán en el rendimiento de la aplicación, lo que afecta a todos los usuarios.
Es posible evitar los problemas antes mencionados mediante la sincronización y bloqueo para evitar colisiones, pero eso es una carga para usted como desarrollador. En general, un uso intensivo del ámbito de sesión es una fuente común de errores, y el comportamiento inesperado que causa es a menudo difícil de reproducir en un entorno de prueba.
Es posible evitar los problemas antes mencionados mediante la sincronización y bloqueo para evitar colisiones, pero eso es una carga para usted como desarrollador. En general, un uso intensivo del ámbito de sesión es una fuente común de errores, y el comportamiento inesperado que causa es a menudo difícil de reproducir en un entorno de prueba.
NOTA: Las cookies tienen el problema combinado de parámetros de request y datos de la sesión. Sólo almacenan strings con un tope de un tamaño fijo (~ 4K), y no pueden estar divididas por casos de uso. Su utilidad está en la identificación de un visitante recurrente o almacenar las preferencias generales del usuario.
A pesar de que las opciones de almacenamiento existentes son viables, no son muy adecuadas para el mantenimiento de un conjunto aislado de datos para un caso de uso. Es evidente que hay espacio para una mejor solución. Sorprendentemente, la solución radica en la sesión HTTP. A pesar de haber golpeado a la sesión por sus debilidades, no todo es malo. Simplemente tiene que ser dividida y mejor gestionada. Eso es exactamente lo que hace Seam. El contexto de la conversación está diseñado para ser una capa de abstracción sobre la sesión HTTP de buen comportamiento.
Tallando un espacio de trabajo en la sesión HTTP
El contexto de la conversación está tallado en la sesión HTTP para formar un segmento de memoria aislada y administrada, como se ilustra en la figura 7.3.
El contexto de la conversación está tallado en la sesión HTTP para formar un segmento de memoria aislada y administrada, como se ilustra en la figura 7.3.
Seam utiliza el contexto de la conversación como el hogar de un conjunto de trabajo de las variables de contexto.
Es posible que tiemblan ante la sola mención de la utilización dela sesión HTTP para almacenar la conversación, teniendo en cuenta los problemas citados en el apartado anterior.
Sin embargo, una conversación, no sufre los mismos problemas que sus ancestros. En primer lugar, la vida útil de una conversación típica es del orden de minutos, mientras que una sesión
puede durar del orden de horas.
Es posible que tiemblan ante la sola mención de la utilización dela sesión HTTP para almacenar la conversación, teniendo en cuenta los problemas citados en el apartado anterior.
Sin embargo, una conversación, no sufre los mismos problemas que sus ancestros. En primer lugar, la vida útil de una conversación típica es del orden de minutos, mientras que una sesión
puede durar del orden de horas.
Esta diferencia se hace posible por el hecho de que una conversación tiene su propio ciclo de vida que gestiona Seam. Cada conversación puede tener su propio período de tiempo de espera (timeout), que por defecto se setea con la configuraciónde tiempo de espera global, cubierto en la sección 7.3.5. Además, las conversaciones simultáneas se mantienen aisladas, a diferencia de los atributos de la sesión.
Dado que las conversaciones se almacenan en la sesión, dos requisitos deben cumplirse:
■ Los componentes con alcance de conversación deben implementar java.io.Serializable.
■ El tiempo de espera de sesión, que se define en el web.xml, debe superar todos los tiempos de espera de la conversación.
Una conversación tiene un conjunto claro de los límites del ciclo de vida, que coinciden con los límites de un caso de uso. Cuando el usuario activa una condición que comienza una conversación, una nueva zona administrada de la sesión HTTP es seccionada y dedicada a la conversación.
Un identificador único, conocido como el identificador de conversación, se genera y se asocia con esta región de la sesión. El identificador de conversación se pasa a la siguiente petición como un parámetro, campo de formulario oculto, o atributo raíz de vista JSF. Afortunadamente, la propagación de la Identificación de una conversación es manejada de forma transparente en una aplicación de Seam. Como resultado de la identificación de la conversación y el ID de sesión que se envían juntos al servidor, la conversación se recupera de la sesión y se asocia con la solicitud.
Dado que las conversaciones se almacenan en la sesión, dos requisitos deben cumplirse:
■ Los componentes con alcance de conversación deben implementar java.io.Serializable.
■ El tiempo de espera de sesión, que se define en el web.xml, debe superar todos los tiempos de espera de la conversación.
Una conversación tiene un conjunto claro de los límites del ciclo de vida, que coinciden con los límites de un caso de uso. Cuando el usuario activa una condición que comienza una conversación, una nueva zona administrada de la sesión HTTP es seccionada y dedicada a la conversación.
Un identificador único, conocido como el identificador de conversación, se genera y se asocia con esta región de la sesión. El identificador de conversación se pasa a la siguiente petición como un parámetro, campo de formulario oculto, o atributo raíz de vista JSF. Afortunadamente, la propagación de la Identificación de una conversación es manejada de forma transparente en una aplicación de Seam. Como resultado de la identificación de la conversación y el ID de sesión que se envían juntos al servidor, la conversación se recupera de la sesión y se asocia con la solicitud.
NOTA: A pesar de que la sesión HTTP se utiliza como mecanismo de almacenamiento para una conversación, el consumo de memoria es sorprendentemente bajo, porque las conversaciones hacen un tratamiento agresivo. No hay posibilidades de que subsisten las causas de pérdidas de memoria.
El contexto de la conversación es un lugar ideal para almacenar los datos que se necesita sobre la extensión de varias páginas. Se aprovecha la capacidad de la sesión para almacenar objetos arbitrariamente complejos, preservando la identidad del objeto, sin sufrir pérdidas de memoria o de concurrencia. Lo que hace que las conversaciones sean verdaderamente únicas es que se mantienen aislados unas de otras.
RESOLVER EL PROBLEMA DE CONCURRENCIA MÚLTIPLES VENTANAS
Vamos a revisar el escenario en el que diferentes registros del curso de golf se están editando en las pestañas del navegador. En esta ocasión, vamos a suponer que una conversación se está utilizando para gestionar cada caso de uso. El usuario comienza con la selección de un campo de golf en la primera pestaña, que inicia una nueva conversación y presenta al usuario un formulario de actualización. Después, el usuario pasa a la segunda pestaña y selecciona un curso diferente, una vez más con el mismo resultado, una nueva conversación y la prestentación de un formulario de actualización. Cada tab tiene ahora su propia conversación. Después, el usuario vuelve a la primera pestaña y hace click en Guardar. Los valores se forman a partir del tab y se envían al servidor junto con el identificador de conversación. En el servidor, el contexto de la conversación se recupera de la sesión utilizando el ID de conversación. La instancia del curso se saca de la conversación, los valores del formulario se aplican a él, y, finalmente, se sincroniza con la base de datos.
Aunque las dos pestañas están sirviendo al mismo caso de uso con las mismas variables de contexto, los datos se mantienen aislados. Las conversaciones no sufren de fugas, ya que no son compartidos por todas las pestañas y ventanas como la sesión. En su lugar, una conversación puede ser reservada para una sola pestaña y restaurada en cada petición pasando el identificador de conversación.
Vamos a revisar el escenario en el que diferentes registros del curso de golf se están editando en las pestañas del navegador. En esta ocasión, vamos a suponer que una conversación se está utilizando para gestionar cada caso de uso. El usuario comienza con la selección de un campo de golf en la primera pestaña, que inicia una nueva conversación y presenta al usuario un formulario de actualización. Después, el usuario pasa a la segunda pestaña y selecciona un curso diferente, una vez más con el mismo resultado, una nueva conversación y la prestentación de un formulario de actualización. Cada tab tiene ahora su propia conversación. Después, el usuario vuelve a la primera pestaña y hace click en Guardar. Los valores se forman a partir del tab y se envían al servidor junto con el identificador de conversación. En el servidor, el contexto de la conversación se recupera de la sesión utilizando el ID de conversación. La instancia del curso se saca de la conversación, los valores del formulario se aplican a él, y, finalmente, se sincroniza con la base de datos.
Aunque las dos pestañas están sirviendo al mismo caso de uso con las mismas variables de contexto, los datos se mantienen aislados. Las conversaciones no sufren de fugas, ya que no son compartidos por todas las pestañas y ventanas como la sesión. En su lugar, una conversación puede ser reservada para una sola pestaña y restaurada en cada petición pasando el identificador de conversación.
Como tal, la actividad que se produce en una pestaña no afecta a otras pestañas (que utilizan diferentes conversaciones). Aunque las conversaciones evitan que se compartainformación no deseada entre los casos de uso, el intercambio de datos a través de múltiples peticiones en el caso de uso mismo es una meta deseable.
CAPA DE NEGOCIO ATADA AL CACHÉ
El contexto de la conversación ofrece un mecanismo de caché natural que es fácilmente controlado desde la aplicación, permitiendo que los datos almacenados en caché sean descartados o actualizados de acuerdo con la lógica de negocio. Incluso se puede proporcionar al usuario controles que obligan a actualizar los datos bajo demanda. Si la conversación se abandona, no pasa mucho tiempo antes de que este estado sea limpiado por Seam (a diferencia con el estado almacenado en la sesión HTTP).
El almacenamiento en caché de datos es fundamental, ya que evita consultas de datos redundantes. Si los resutados de una consulta a la base de datos es cacheado, significa que usted no tiene que consultar la base de datos de nuevo cuando no hay expectativa de que los datos hayan cambiado. Usted debe tomar ventaja de esta oportunidad, ya que, de todos los niveles en su aplicación, el nivel de base de datos es el menos escalable. No abuse de la base de datos pidiendo que recupere los mismos datos una y otra vez. Cuando la aplicación falla en el seguimiento de los datos que ya estaban alimentados, perjudica el rendimiento tanto de la base de datos como de la aplicación.
Reducir la carga en la base de datos es una de las principales preocupaciones de un ORM. Un ORM admite dos niveles de almacenamiento en caché. El caché de primer nivel, conocido como el contexto de persistencia, alberga la colección de todas las entidades recuperadas por un gestor de persistencia único, que usted aprenderá en los capítulos 8 y 9. Si el gestor de persistencia está en el ámbito de la conversación, el ORM funciona de forma natural para reducir la carga de base de datos.
La memoria caché de segundo nivel ORM es compartida por los administradores de la persistencia y sostiene objetos persistentes cargados previamente a través de cualquier contexto de persistencia. Se utiliza como una forma de reducir el tráfico entre la aplicación y la base de datos. Empleando un algoritmo inteligente, se trata de mantener la memoria caché en sincronía con los cambios introducidos en la base de datos.
Sin embargo, independientemente de lo buena que sea esta lógica, en el marco de un caso de uso, carece de la visión del nivel de negocio para saber exactamente cuando los datos deben ser considerados obsoletos.
Esperar que el caché de segundo nivel compense la incapacidad de la aplicación de retener los datos es un mal uso de la tecnología.
La necesidad de un contexto con estado actuando como intermediario entre el navegador y la base de datos es especialmente importante en el mundo de la Web 2.0, donde las peticiones Ajax se envían al servidor a una velocidad que supera con creces el patrón de uso anterior de las aplicaciones web.
Las peticiones que aprovechan los accesos guardados de la base de datos en el contexto de la conversación son más rápidos, ya que la devolución de datos está a la mano. La conversación se juega otro papel importante en Ajax: la prevención de las solicitudes de acceso a los datos concurrentemente.
El contexto de la conversación ofrece un mecanismo de caché natural que es fácilmente controlado desde la aplicación, permitiendo que los datos almacenados en caché sean descartados o actualizados de acuerdo con la lógica de negocio. Incluso se puede proporcionar al usuario controles que obligan a actualizar los datos bajo demanda. Si la conversación se abandona, no pasa mucho tiempo antes de que este estado sea limpiado por Seam (a diferencia con el estado almacenado en la sesión HTTP).
El almacenamiento en caché de datos es fundamental, ya que evita consultas de datos redundantes. Si los resutados de una consulta a la base de datos es cacheado, significa que usted no tiene que consultar la base de datos de nuevo cuando no hay expectativa de que los datos hayan cambiado. Usted debe tomar ventaja de esta oportunidad, ya que, de todos los niveles en su aplicación, el nivel de base de datos es el menos escalable. No abuse de la base de datos pidiendo que recupere los mismos datos una y otra vez. Cuando la aplicación falla en el seguimiento de los datos que ya estaban alimentados, perjudica el rendimiento tanto de la base de datos como de la aplicación.
Reducir la carga en la base de datos es una de las principales preocupaciones de un ORM. Un ORM admite dos niveles de almacenamiento en caché. El caché de primer nivel, conocido como el contexto de persistencia, alberga la colección de todas las entidades recuperadas por un gestor de persistencia único, que usted aprenderá en los capítulos 8 y 9. Si el gestor de persistencia está en el ámbito de la conversación, el ORM funciona de forma natural para reducir la carga de base de datos.
La memoria caché de segundo nivel ORM es compartida por los administradores de la persistencia y sostiene objetos persistentes cargados previamente a través de cualquier contexto de persistencia. Se utiliza como una forma de reducir el tráfico entre la aplicación y la base de datos. Empleando un algoritmo inteligente, se trata de mantener la memoria caché en sincronía con los cambios introducidos en la base de datos.
Sin embargo, independientemente de lo buena que sea esta lógica, en el marco de un caso de uso, carece de la visión del nivel de negocio para saber exactamente cuando los datos deben ser considerados obsoletos.
Esperar que el caché de segundo nivel compense la incapacidad de la aplicación de retener los datos es un mal uso de la tecnología.
La necesidad de un contexto con estado actuando como intermediario entre el navegador y la base de datos es especialmente importante en el mundo de la Web 2.0, donde las peticiones Ajax se envían al servidor a una velocidad que supera con creces el patrón de uso anterior de las aplicaciones web.
Las peticiones que aprovechan los accesos guardados de la base de datos en el contexto de la conversación son más rápidos, ya que la devolución de datos está a la mano. La conversación se juega otro papel importante en Ajax: la prevención de las solicitudes de acceso a los datos concurrentemente.
PREVENCIÓN DE PROBLEMAS DE CONCURRENCIA
Seam serializa las peticiones concurrentes que acceden a la misma conversación. Esto significa que sólo un hilo puede acceder a una conversación en un momento dado. En aplicaciones pre-Web 2.0, esto podría ayudar a tratar con un doble submit, pero cuando Ajax comienza a disparar peticiones como las que van fuera del negocio, la probabilidad de que los datos entren en un estado inconsistente como resultado de acceso concurrente aumenta dramáticamente. Seam mantiene las peticiones Ajax en línea, así que usted puede estar seguro de que los datos en el alcance de la conversación no serán modificados por una segunda petición de entrada mientras que la primera petición está siendo despachada.
Las conversaciones se ajustan muy naturalmente con Ajax. La combinación del acceso serializado y el comportamiento de estado reduce al mínimo el riesgo de usar Ajaxen su aplicación.
Con estos mecanismos en su lugar, usted puede estar seguro de que el rendimiento y la consistencia de los datos no se verán afectados. Usted aprenderá más acerca de lo bien que Seam y Ajax encajan en el capítulo 12.
Después de haber explorado formas en que el contexto conversación resuelve la necesidad de un contexto de estado centrado en el usuario, vamos a examinar los tipos de datos que normalmente se pueden almacenar en una conversación mientras te preparas para su uso.
Seam serializa las peticiones concurrentes que acceden a la misma conversación. Esto significa que sólo un hilo puede acceder a una conversación en un momento dado. En aplicaciones pre-Web 2.0, esto podría ayudar a tratar con un doble submit, pero cuando Ajax comienza a disparar peticiones como las que van fuera del negocio, la probabilidad de que los datos entren en un estado inconsistente como resultado de acceso concurrente aumenta dramáticamente. Seam mantiene las peticiones Ajax en línea, así que usted puede estar seguro de que los datos en el alcance de la conversación no serán modificados por una segunda petición de entrada mientras que la primera petición está siendo despachada.
Las conversaciones se ajustan muy naturalmente con Ajax. La combinación del acceso serializado y el comportamiento de estado reduce al mínimo el riesgo de usar Ajaxen su aplicación.
Con estos mecanismos en su lugar, usted puede estar seguro de que el rendimiento y la consistencia de los datos no se verán afectados. Usted aprenderá más acerca de lo bien que Seam y Ajax encajan en el capítulo 12.
Después de haber explorado formas en que el contexto conversación resuelve la necesidad de un contexto de estado centrado en el usuario, vamos a examinar los tipos de datos que normalmente se pueden almacenar en una conversación mientras te preparas para su uso.
Qué se puede almacenar en una conversación?
La conversación proporciona un camino para que los datos sean guardados durante el tiempo en que el usuario piensa (el texto original dice: user “think” time, creo que sería el tiempo en el que el usuario no hace nada) -el tiempo después de que una respuesta se envía al navegador pero antes de que el usuario activa un link o envía un formulario. Información adicional es acumulada en la conversación mientras el usuario se mueve de una pantalla a otra. Hay cuatro clasificaciones de datos que un conjunto de trabajo utiliza para almacenar, todos los cuales se muestran en este capítulo:
La conversación proporciona un camino para que los datos sean guardados durante el tiempo en que el usuario piensa (el texto original dice: user “think” time, creo que sería el tiempo en el que el usuario no hace nada) -el tiempo después de que una respuesta se envía al navegador pero antes de que el usuario activa un link o envía un formulario. Información adicional es acumulada en la conversación mientras el usuario se mueve de una pantalla a otra. Hay cuatro clasificaciones de datos que un conjunto de trabajo utiliza para almacenar, todos los cuales se muestran en este capítulo:
■ Datos no persistentes. Un ejemplo de datos no persistente es un conjunto de criterios de búsqueda o una colección de identificadores de registro. El usuario puede establecer el estado de una petición y luego utilizarlo para recuperar datos en el siguiente. Esta categoría también incluye los datos de configuración (tales como la definición de flujo de la página).
■ Datos de entidad (transient) -Una instancia de entidad transient puede ser construida y llenada como parte de un asistente. Una vez finalizado el asistente, la instancia de entidad se extrae del conjunto de trabajo y persiste.
■ Datos de entidad administrada – El conjunto de trabajo proporciona una forma ideal para trabajar con datos de la entidad de base de datos administrada para el propósito de actualizar sus campos. La instancia de entidad se coloca en el espacio de trabajo y luego se superpone en un formulario. Cuando el usuario envía el formulario, los valores del formulario son aplicados a la instancia de entidad que está almacenada en el conjunto de trabajo (cuyo objeto con identidad ha sido preservado) y los cambios se vuelcan en la base de datos de forma transparente.
■ Recurso sesiones -El contexto de la conversación ofrece un mecanismo ideal para mantener una referencia a un recurso. Por ejemplo, el contexto de persistencia (un EntityManager JPA o Hibernate Session) se puede almacenar en la conversación para evitar los casos en que la entidad se “desatache” prematuramente.
Los siguientes capítulos se centran en cómo las conversaciones benefician la gestión de la persistencia.
■ Datos de entidad (transient) -Una instancia de entidad transient puede ser construida y llenada como parte de un asistente. Una vez finalizado el asistente, la instancia de entidad se extrae del conjunto de trabajo y persiste.
■ Datos de entidad administrada – El conjunto de trabajo proporciona una forma ideal para trabajar con datos de la entidad de base de datos administrada para el propósito de actualizar sus campos. La instancia de entidad se coloca en el espacio de trabajo y luego se superpone en un formulario. Cuando el usuario envía el formulario, los valores del formulario son aplicados a la instancia de entidad que está almacenada en el conjunto de trabajo (cuyo objeto con identidad ha sido preservado) y los cambios se vuelcan en la base de datos de forma transparente.
■ Recurso sesiones -El contexto de la conversación ofrece un mecanismo ideal para mantener una referencia a un recurso. Por ejemplo, el contexto de persistencia (un EntityManager JPA o Hibernate Session) se puede almacenar en la conversación para evitar los casos en que la entidad se “desatache” prematuramente.
Los siguientes capítulos se centran en cómo las conversaciones benefician la gestión de la persistencia.
En esta sección aprendió lo que queremos decir cuando hablamos de la conversación: un contexto para mantener los datos en el alcance de la duración de un caso de uso y un medio para permitir el comportamiento con estado en sus aplicaciones. El siguiente paso es aprender sobre el ciclo de vida de la conversación y la forma de controlar las conversaciones mediante la definición de los límites de la conversación.
Estableciendo límites de conversación
El contexto de la conversación se distingue de otros contextos Seam que ha utilizado hasta el momento en que tiene límites explícitos dictados por la lógica de aplicación, en contraposición a los límites implícitos que se correlacionan con una demarcación en el ciclo de vida del servlet o JSF. Los límites del contexto de la conversación se controlan mediante directivas de propagación de conversación. Esta sección presenta estas directivas y demuestra cómo se utilizan para la transición del estado de una conversación de manera efectiva administrando su ciclo de vida.
El contexto de la conversación se distingue de otros contextos Seam que ha utilizado hasta el momento en que tiene límites explícitos dictados por la lógica de aplicación, en contraposición a los límites implícitos que se correlacionan con una demarcación en el ciclo de vida del servlet o JSF. Los límites del contexto de la conversación se controlan mediante directivas de propagación de conversación. Esta sección presenta estas directivas y demuestra cómo se utilizan para la transición del estado de una conversación de manera efectiva administrando su ciclo de vida.
El estado de una conversación
Una conversación en realidad tiene dos estados: temporal y de larga duración.
Una conversación en realidad tiene dos estados: temporal y de larga duración.
También hay un tercer estado, anidado, el cual es una característica del estado de larga duración. Las conversaciones anidadas se tratan en la sección 7.4.2.
En este momento, quiero centrarme en los dos primeros estados.
Cambiar el estado de una conversación se le conoce como la propagación de la conversación. Al establecer los límites de una conversación usando las directivas de propagación de la conversación, usted no está el inicializando ni destruyendo la conversación, sino que está cambiando la transición entre un estado temporal y uno de larga duración.
Cambiar el estado de una conversación se le conoce como la propagación de la conversación. Al establecer los límites de una conversación usando las directivas de propagación de la conversación, usted no está el inicializando ni destruyendo la conversación, sino que está cambiando la transición entre un estado temporal y uno de larga duración.
CONVERSACIONES TEMPORALES VS. LARGA DURACIÓN
La mayoría de las veces, cuando se habla de conversaciones Seam, se está refiriendo a la conversación larga. La discusiónen en la primer parte de este capítulo se refiere a las conversaciones de larga duración. Una conversación de larga duración se mantiene activa en una serie de peticiones en relación con la transferencia de la Identificación conversación. En ausencia de una conversación de larga duración, Seam crea una conversación temporal para atender la petición actual. Una conversación temporal se inicia inmediatamente después de la fase de ciclo de vida JSF de restauración de Vista y se destruye después de la fase de respuesta de procesamiento.
Usted puede pensar en una conversación temporal como un transporte de datos a través de una redirección.
En Seam, la conversación temporal acarrea variables en el alcance de la conversación a través de una redirección que puede ocurrir durante un evento de navegación JSF. Esto funciona mediante el mantenimiento de la conversación temporal hasta que la redirección se ha completado. Así que para aclarar, una conversación temporal se destruye después de que termina la fase de procesamiento de respuesta, incluso si es precedida por una redirección. El uso más popular de una conversacióntemporal es para mantener los mensajes JSF vivos durante el patrón de redirección (redirect-after-post), asumiendo que esos mensajes son registrados utilizando Seam’s built-in, componente de alcance de conversación FacesMessages.
El otro propósito de una conversación temporal es la de servir como semilla para una conversación larga. Una conversación de larga duración no es más que una conversación de temporal cuya finalización se ha pospuesto. Este aplazamiento se extiende desde el momento en el que se encuentra la directiva begin conversation hasta el final de la conversación end conversation.
En lugar de simplemente sobrevivir a una navegación de redirección, una conversación de larga duración es capaz de sobrevivir a toda una serie de interacciones de usuario. Sólo cuando la conversación vuelve a adquirir el estado temporal se ha programado para ser terminada. En Seam, cada petición es parte de una conversación. Sólo tienes que decidir cuánto tiempo deseas que la conversación dure.
El otro propósito de una conversación temporal es la de servir como semilla para una conversación larga. Una conversación de larga duración no es más que una conversación de temporal cuya finalización se ha pospuesto. Este aplazamiento se extiende desde el momento en el que se encuentra la directiva begin conversation hasta el final de la conversación end conversation.
En lugar de simplemente sobrevivir a una navegación de redirección, una conversación de larga duración es capaz de sobrevivir a toda una serie de interacciones de usuario. Sólo cuando la conversación vuelve a adquirir el estado temporal se ha programado para ser terminada. En Seam, cada petición es parte de una conversación. Sólo tienes que decidir cuánto tiempo deseas que la conversación dure.
DIRECTIVAS DE PROPAGACIÓN DE CONVERSACIÓN
Aprender a usar las conversaciones de larga duración implica aprender las directivas de la propagación de la conversación, que se enumeran en la tabla 7.1, y cómo se transforman una conversación temporal desde y en una conversación de larga duración.
Las directivas de propagación de conversación se pueden aplicar utilizando los siguientes medios:
■ Anotaciones a nivel de método
■ Etiquetas de componentes UI
■ Descriptor de página Seam
■ Seam conversation API
■ Página de descriptor de flujo con estado (sólo fin de conversación)
■ Anotaciones a nivel de método
■ Etiquetas de componentes UI
■ Descriptor de página Seam
■ Seam conversation API
■ Página de descriptor de flujo con estado (sólo fin de conversación)
Estas variantes se proporcionan para dar cabida a diferentes usos y escenarios de diseño, lo que le permite establecer los límites de la conversación donde tiene más sentido en tu aplicación. Usted aprenderá a utilizar las directivas de propagación de la conversación en la
siguiente sección.
Las directivas de propagación de la conversación dictan el ciclo de vida de la conversación.
La Figura 7.4 diagrama este ciclo de vida, mostrando cómo el estado de la conversación cambia durante la solicitud como consecuencia de encontrarse con una directiva de propagación de conversación.
Vamos a paso a través del diagrama en la figura 7.4. Al inicio de la petición, una conversación de larga duración se restaura si el identificador de conversación se detecta entre los parámetros de la petición. Si el identificador de conversación está ausente o es inválido, Seam inicia una nueva conversación temporal. En cualquier punto durante el procesamiento de la petición, la conversación puede cambiar de estado como resultado de encontrarse con una directiva de propagación de conversación. La directiva begin hace una transición de una conversación temporal a una de larga duración. La directiva de unión (join) tiene el mismo efecto que la directiva begin, salvo que pueda entrar en una conversación ya existente de larga duración, mientras que la directiva begin lanza una excepción en este caso. La directiva nido (nest) también puede iniciar una conversación de larga duración, pero si existe, una nueva conversación se crea, suspendiendo temporalmente la existente. La directiva end envía la conversación de larga duración de vuelta a su estado temporal.
siguiente sección.
Las directivas de propagación de la conversación dictan el ciclo de vida de la conversación.
La Figura 7.4 diagrama este ciclo de vida, mostrando cómo el estado de la conversación cambia durante la solicitud como consecuencia de encontrarse con una directiva de propagación de conversación.
Vamos a paso a través del diagrama en la figura 7.4. Al inicio de la petición, una conversación de larga duración se restaura si el identificador de conversación se detecta entre los parámetros de la petición. Si el identificador de conversación está ausente o es inválido, Seam inicia una nueva conversación temporal. En cualquier punto durante el procesamiento de la petición, la conversación puede cambiar de estado como resultado de encontrarse con una directiva de propagación de conversación. La directiva begin hace una transición de una conversación temporal a una de larga duración. La directiva de unión (join) tiene el mismo efecto que la directiva begin, salvo que pueda entrar en una conversación ya existente de larga duración, mientras que la directiva begin lanza una excepción en este caso. La directiva nido (nest) también puede iniciar una conversación de larga duración, pero si existe, una nueva conversación se crea, suspendiendo temporalmente la existente. La directiva end envía la conversación de larga duración de vuelta a su estado temporal.
Al final de la petición, la conversación temporal se destruye, mientras que la conversación de larga duración está ubicada en la sesión HTTP para ser recuperado por una petición posterior. Aunque no se muestra, si la conversación que está siendo restaurada no es válida o ya ha caducado, el usuario es notificado y enviado a una página de error (fallback) si se ha configurado.
Seam utiliza un componente integrado para realizar un seguimiento del estado de la conversación, incluyendo sus relaciones con las conversaciones anidadas y los padres. Es importante saber que existe este componente ya que a menudo encontrará que necesita referenciarlo.
Seam utiliza un componente integrado para realizar un seguimiento del estado de la conversación, incluyendo sus relaciones con las conversaciones anidadas y los padres. Es importante saber que existe este componente ya que a menudo encontrará que necesita referenciarlo.
EL COMPONENTE CONVERSACIÓN
Seam mantiene el estado de la conversación en una instancia del componente integrado en el alcance de la conversación llamado conversation. Este componente proporciona una gran cantidad de información acerca de la conversación en curso en forma de propiedades y expone los métodos para actuar sobre la conversación. Estas propiedades y métodos se enumeran en la tabla 7.2. La propiedad más importante en el componente de la conversación es el identificador de conversación, al que normalmente se accede mediante la expresión de valor # {conversation.id}. El identificador de conversación se utiliza para restaurar la conversación de la sesión al principio de una solicitud. Verá esta expresión utilizada a menudo en este capítulo.
Seam mantiene el estado de la conversación en una instancia del componente integrado en el alcance de la conversación llamado conversation. Este componente proporciona una gran cantidad de información acerca de la conversación en curso en forma de propiedades y expone los métodos para actuar sobre la conversación. Estas propiedades y métodos se enumeran en la tabla 7.2. La propiedad más importante en el componente de la conversación es el identificador de conversación, al que normalmente se accede mediante la expresión de valor # {conversation.id}. El identificador de conversación se utiliza para restaurar la conversación de la sesión al principio de una solicitud. Verá esta expresión utilizada a menudo en este capítulo.
Las propiedades en el componente conversación ayuda en la toma de decisiones sobre la navegación o la representación de marcado condicional (rendering markup conditionally). Los métodos en el componente de conversación puede cambiar el estado de la conversación y se utilizan a menudo como acciones de página o como método de acción en links y botones.
Con este componente en la mano, usted está listo para aprender a definir los límites de la conversación. A medida que lea el próximo par de secciones, le animo a estudiar las opciones que tiene para la definición de estos límites, decidir sobre un enfoque favorito, y tratar de adherirse a ella la mayoría de las veces. El hecho de que se puede definir cada uno de los límites de un puñado de maneras no significa que usted debe utilizar todas las variaciones individuales, al menos no sin una buena razón.
Con este componente en la mano, usted está listo para aprender a definir los límites de la conversación. A medida que lea el próximo par de secciones, le animo a estudiar las opciones que tiene para la definición de estos límites, decidir sobre un enfoque favorito, y tratar de adherirse a ella la mayoría de las veces. El hecho de que se puede definir cada uno de los límites de un puñado de maneras no significa que usted debe utilizar todas las variaciones individuales, al menos no sin una buena razón.
[1] La Transferencia de Estado Representacional (Representational State Transfer) o REST es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.
Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo de servicios web SOAP. Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de REST.
Los sistemas que siguen los principios REST se llaman con frecuencia RESTful
Suscribirse a:
Entradas (Atom)