Consideraciones sobre el diseño de aplicaciones

En este tema se describen las sugerencias de arquitectura para el diseño y el ajuste de aplicaciones.

La información de diseño de aplicaciones contiene las sugerencias arquitectónicas y la implementación de aplicaciones. Para las aplicaciones actuales, las sugerencias pueden requerir el cambio de las implementaciones existentes. El ajuste del servidor de aplicaciones y los parámetros de recursos puede tener un gran efecto sobre el rendimiento de las aplicaciones que estén bien diseñadas.

Utilice las consideraciones de diseño de aplicaciones en este tema para obtener consejos para asegurarse de que las aplicaciones se diseñen y ajusten cuidadosamente. Estas consideraciones incluyen sitios web y otras ideas para encontrar la mejor forma de diseñar aplicaciones WebSphere, en particular en el dominio de las ampliaciones de WebSphere de la especificación Java™ Platform, Enterprise Edition (Java EE).

procedimientos recomendados: Utilice la siguiente información como guía de arquitectura cuando implemente las aplicaciones:

Las aplicaciones Java EE cargan, almacenan, crean y eliminan datos de las bases de datos relacionales, un proceso conocido normalmente como persistencia. La mayor parte de las aplicaciones de empresa tienen un acceso importante a la base de datos. La arquitectura y el rendimiento de la capa de persistencia es fundamental para el rendimiento de una aplicación. Por lo tanto, es importante tener en cuenta la persistencia cuando se toman decisiones sobre arquitectura que requieren equilibrar el rendimiento. En esta guía se recomienda centrarse primero en una solución con una arquitectura limpia. La arquitectura limpia tiene en cuenta la coherencia de los datos, la seguridad, el mantenimiento, la portabilidad y el rendimiento de esa solución. Aunque este enfoque podría no ofrecer el rendimiento máximo absoluto que puede obtener al codificar manualmente una solución que ignore las calidades de servicio citadas anteriormente, este enfoque puede lograr el equilibrio adecuado entre la coherencia de los datos, la capacidad de mantenimiento, la portabilidad, la seguridad y el rendimiento.

Existen muchas opciones disponibles para la persistencia en Java EE: los beans de sesión que utilizan beans de entidad que incluyen persistencia gestionada por contenedor (CMP) o persistencia gestionada por bean (BMP), beans de sesión que utilizan JDBC (Java Database Connectivity) y beans Java que utilizan JDBC. Por los motivos ya citados, tenga en cuenta la persistencia de entidad CMP, ya que ofrece la máxima seguridad, mantenimiento y portabilidad. También se recomienda CMP para obtener un buen rendimiento. Consulte el apartado Ajuste el contenedor de EJB en el tema de ajuste de servidores de aplicaciones sobre el ajuste de enterprise beans y, más específicamente, CMP.

Si una aplicación requiere el uso de enterprise beans que no utilicen entidades EJB, el mecanismo de persistencia implica normalmente la API JDBC. Como JDBC requiere codificación manual, el Lenguaje de consulta estructurada (SQL) que se ejecuta en una instancia de base de datos es fundamental para optimizar las sentencias SQL que se utilizan en la aplicación. Asimismo, configure el servidor de base de datos para que dé soporte al rendimiento óptimo de estas sentencias SQL. Por último, tenga en cuenta el uso de API JDBC específicas, incluidas las sentencias preparadas y el proceso por lotes.

Independientemente del mecanismo de persistencia que se elija, utilice transacciones gestionadas por contenedor, donde el bean delega la gestión de las transacciones al contenedor. Para las aplicaciones que utilizan JDBC, esto se consigue fácilmente utilizando el patrón de fachada de sesión, que envuelve todas las funciones de JDBC con un bean de sesión sin estado.

Por último, encontrará información sobre cómo ajustar la conexión en la que se comunican los beans de entidad EJB o JDBC en la sección Ajuste de los orígenes de datos del tema de ajuste de servidores de aplicaciones.

Una de las arquitecturas de programación Java EE estándar es la arquitectura MVC (controlador de vista de modelos), donde las llamadas a servlets de controladores podrían incluir uno o más archivos JSP (JavaServer Pages) secundarios para construir la vista. El patrón MVC es un patrón recomendado para la arquitectura de aplicaciones. Este patrón requiere una clara separación de la vista (los archivos JSP o la lógica de presentación), el controlador (los servlets) y el modelo (la lógica de la empresa). El uso del patrón MVC permite la optimización y la escalabilidad de cada capa por separado.

Las implementaciones que evitan almacenar el estado de usuario del cliente son las que mejor rinden y se escalan. Diseñe implementaciones que no almacenen estados. Si se necesita el almacenamiento de estados, compruebe que el tamaño de los datos de estado y el tiempo que el estado permanece almacenado se reducen a los valores más pequeños posibles. Asimismo, si se necesita el almacenamiento de estados, considere la posibilidad de reconstruir el estado si se produce una anomalía, en lugar garantizar la sustitución del estado por anomalía mediante la duplicación.

El ajuste específico del estado afecta el estado de la sesión HTTP, la memoria caché dinámica y los enterprise beans. Consulte las siguientes guías de ajuste para obtener información sobre cómo ajustar el tamaño, la duplicación y la temporización del almacenamiento del estado:
  • Ajuste de gestión de sesiones
  • Sugerencias para el ajuste de EJB
  • Ajuste de la antememoria dinámica con el supervisor de antememoria

La mayor parte de las cargas de trabajo de las aplicaciones Java EE tienen más operaciones de lectura que operaciones de grabación. Las operaciones de lectura requieren pasar una solicitud por varios niveles de topología que constan de un servidor web frontal, el contenedor web de un servidor de aplicaciones, el contenedor de EJB de un servidor de aplicaciones y una base de datos. WebSphere Application Server ofrece la posibilidad de colocar en la memoria caché los resultados en todos los niveles de la topología de red y el modelo de programación Java EE que incluye servicios web.

Los diseñadores de aplicaciones deben considerar la colocación en memoria caché al diseñar la arquitectura de la aplicación, ya que la colocación en memoria caché se integra en la mayoría de niveles del modelo de programación. La colocación en memoria caché es otro motivo para imponer el patrón MVC en las aplicaciones. La combinación de colocación en memoria caché y MVC puede proporcionar una colocación en memoria caché independiente de la tecnología de presentación y en aquellos casos en los que no haya presentación a los clientes de la aplicación.

Los diseñadores de redes deben tener en cuenta la colocación en memoria caché al realizar la planificación de la red, ya que la colocación en memoria caché también se integra en la mayoría de niveles de la topología de red. Para las aplicaciones disponibles en Internet de forma pública, los diseñadores de redes deben tener en cuenta la colocación en memoria caché de Edge Side Include (ESI) cuando la colocación en memoria caché del WebSphere Application Server se amplíe a la Internet pública. Los servicios de colocación en memoria caché de la red están disponibles en el servidor proxy para WebSphere Application Server, WebSphere Edge Component Caching Proxy y el plug-in WebSphere.

Las cargas de trabajo de Java EE suelen constar de dos tipos de operaciones. Debe realizar el primer tipo de operación para responder a una solicitud del sistema. Puede realizar el segundo tipo de operación de forma asíncrona cuando la solicitud de usuario que inició la operación se ha completado.

Un ejemplo de esta diferencia es una aplicación que le permita someter un pedido de compra, que le permita continuar mientras el sistema valida el pedido, que consulte a sistemas remotos y que en el futuro le informe del estado del pedido de compra. Este ejemplo puede implementarse de forma síncrona con el cliente esperando la respuesta. La implementación síncrona necesita recursos del servidor de aplicaciones y deberá esperar hasta que se completen las operaciones. Si el proceso le permite continuar mientras se calcula el resultado de forma asíncrona, el servidor de aplicaciones puede planificar que se ejecute el proceso cuando sea el momento óptimo respecto a las demás peticiones. La notificación que se le entregará puede desencadenarse mediante correo electrónico o cualquier otra interfaz dentro de la aplicación.

Como el enfoque asíncrono permite una planificación óptima de las cargas de trabajo y un uso mínimo de los recursos del servidor, utilice siempre que pueda arquitecturas asíncronas. WebSphere Application Server da soporte a la programación asíncrona a través de Java EE Java Message Service (JMS) y de los beans controlados por mensajes (MDB), así como Concurrency Utilities para Java EE que se explican en los temas Ajuste de Java Message Service y Ajuste de MDB.

Compruebe que todas las bibliotecas que utilizan las aplicaciones también están diseñadas para el rendimiento del lado del servidor. Algunas bibliotecas estás diseñadas para funcionar correctamente dentro de una aplicación de cliente y no tienen en cuenta el rendimiento del lado del servidor, por ejemplo, la utilización de la memoria, la sincronización y las agrupaciones. Se recomienda que todas las bibliotecas no desarrolladas como parte de una aplicación pasen por pruebas de rendimiento utilizando las mismas metodologías de prueba que se utilizan para la aplicación.

Referencia adicional:IBM® WebSphere Developer Technical Journal: The top 10 Java EE best practicesImprove performance in your XML applications, Part 2


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprf_appdesign
File name: cprf_appdesign.html