400440306. SOA + WOA = ROA

Estamos en un momento muy interesante para los desarrolladores. Muchos equipos de programadores están trabajando en exponer los servicios en Arquitecturas Orientadas a Servicio (SOA) o, al menos, en exponer los proyectos de integración con las aplicaciones basadas en SOA como Office 2007 o BizTalk.

A medida que estos planes se ponen en marcha, algunos de los equipos de desarrolladores detectan un fallo importante: no existe una interfaz de usuario lo suficientemente completa e interactiva como para aprovechar todos los servicios ofrecidos gracias a la implementación del SOA.

Los analistas han acuñado el término de Arquitectura Orientada a Web (WOA) para describir las tecnologías en desarrollo para las aplicaciones Web. Si hemos adoptado XAML de Windows Vista o AJAX de ASP.NET, seguramente habremos descubierto WOA. No obstante, es poco probable que hayamos anticipado los verdaderos efectos que tiene WOA sobre el rendimiento de las aplicaciones basadas en SOA.

Realizando conexiones

La causa principal del pobre rendimiento en WOA es un incremento en la tasa y tamaño de peticiones y respuestas. Los patrones de uso – en teoría previsibles – se convierten súbitamente en un montón de solicitudes erráticas. En lugar de seguir el flujo diseñado por la aplicación, los usuarios se encuentran de repente cargando datos sin orden ni concierto y clickando sin parar con el ratón, mientras que el buscador actualiza los datos y se encarga de las peticiones del usuario.

El servidor que ha podido atender de forma simultánea a miles de usuarios, de repente sólo es capaz de revisar una parte de su capacidad anterior. La red se atasca con un tráfico tres o cuatro veces superior al anterior, transmitiendo la impresión – tanto al servidor como a la infraestructura de gestión – de sobrecarga que proviene de atender sólo una petición más.

El servidor va más despacio y por ende, la aplicación. Agravado por el hecho de atender más peticiones y con mayor frecuencia de lo habitual, la inversión de medios adicionales para la gestión por un lado, y las peticiones en curso por otro, destruyen los recursos. El buscador comienza a lanzar las preguntas acerca del status de su última petición.
El Protocolo de Control de Transmisión (TCP) adicional retransmite una mayor congestión en la red a medida que los dispositivos intermediarios intentan mantener que el flujo del tráfico de la forma menos problemática posible.

Seguidamente la aplicación comienza a perder conexiones. Estas desconexiones en el servidor originadas por la sobrecarga de peticiones y la congestión en la red provocan fallos en las actualizaciones. Las peticiones generadas por el usuario se pierden o sufren retrasos considerables, provocando así problemas en el rendimiento de la aplicación.

Desatascando la red

Hay varias formas de solucionar el ROA, pero la mejor solución para el entorno, la infraestructura de la aplicación y, cómo no, el presupuesto, depende de múltiples factores propios de cada organización. Es probable que se requiera coordinación entre nosotros, el servidor y los administradores de redes, puesto que los factores que repercuten sobre el rendimiento de la aplicación se reparten entre diversas áreas de especialización.
– Sintonización del rendimiento. Algunos ajustes en el servidor de la aplicación pueden resolver los problemas inherentes a la hora de ejecutar aplicaciones basadas en Web 2.0. Hay que incrementar el valor de la desconexión de TCP hasta igualarlo con la tasa de peticiones procedentes del cliente. De esta forma, se reducirá el número de cortes de conexión debido a la congestión de la red y también se reducirán notablemente los recursos utilizados en las conexiones TCP debido a que las conexiones existentes puedan reutilizarse.
– Modificar los intervalos de monitorización. Si nuestra aplicación monitoriza los datos actualizados, hay que comprobar el tiempo de los intervalos y valorar el incremento o decremento de chattiness (el exceso de comunicación entre sí de las aplicaciones) de tu aplicación. Esto reduce el número de peticiones y alivia parcialmente la carga del servidor.
– Incrementa las conexiones del buscador. Hay que intentar modificar los límites de la configuración en base al número de conexiones simultáneas permitidas por el buscador. Esto requiere una edición de registro para Internet Explorer, que no siempre constituye una opción aceptable. Incrementando las conexiones disponibles se eliminarán retrasos surgidos sobre las aplicaciones basadas en la Web. Algunos switches disponen de características incorporadas para mejorar la seguridad, aceleración, compresión y optimización de aplicaciones.
– Ejecutar las aplicaciones del switch. Estos dispositivos de red – algunos de los cuales están basados en .NET – están diseñados para dirigir de forma eficaz las conexiones de las aplicaciones basadas en Web. Algunos switches disponen de características incorporadas para mejorar la seguridad, aceleración, compresión y optimización de aplicaciones.

Si hemos experimentado estos problemas, es posible que una o más de una de las opciones enumeradas puedan ayudarnos. Si nos preocupa el ROA, la mejora del hardware en la red antes de ejecutar las aplicaciones basadas en WOA y SOA pueden ayudarnos sin duda a garantizar un rendimiento óptimo.

DDJ