1. Introducción a Ventus Proxy For Webservices (VPFW) ……. 03 2. Características generales ……………………………………… 04 3. Beneficios de VPFW ………………………………………….... 06 4. Posibles escenarios con VPFW ………………………………. 08 5. VPFW es NO INTRUSIVO …………………………………….. 13 6. Interfaces clientes y servidores en el mismo software ……… 16 7. Puntos clave de la gestión de caché …………………………. 18 8. Estadísticas ……………………………………………………… 28 9. Gestor de cuotas ……………………………………………….. 35 10. Balanceador de carga ………………………………………… 38 11. Monitorización …………………………………………………. 41 Sumario

1. Introducción a Ventus Proxy For Webservices (VPFW) ……. 03

2. Características generales ……………………………………… 04

3. Beneficios de VPFW ………………………………………….... 06

4. Posibles escenarios con VPFW ………………………………. 08

5. VPFW es NO INTRUSIVO …………………………………….. 13

6. Interfaces clientes y servidores en el mismo software ……… 16

7. Puntos clave de la gestión de caché …………………………. 18

8. Estadísticas ……………………………………………………… 28

9. Gestor de cuotas ……………………………………………….. 35

10. Balanceador de carga ………………………………………… 38

11. Monitorización …………………………………………………. 41

1. Introducción a Ventus Proxy For Webservices VPFW es un servidor proxy de Webservices XML/SOAP que … … se instala delante de los servidores del webservice … … interceptando las peticiones entrantes de los clientes … … para proporcionar una serie de servicios adicionales … … con el objetivo de ofrecer un valor añadido al webservice y … … liberar de carga a los servidores de aplicaciones / BB.DD.

2. Características generales Validación de documentos XML / SOAP Tratamiento de peticiones SSL Caché de documentos XML y SOAP Compresión Balanceo de carga

2. Características generales Estadísticas de uso de los webservices Monitorización Seguridad QoS: protección de servidores

3. Beneficios de VPFW. Reducción de los tiempos de respuesta de las llamadas de webservices hasta en un 99% del tiempo de respuesta original. Porcentajes de caché globales sobre llamadas activas de hasta un 45% (entre un 15% y un 95% a nivel individual). Ahorros de CPU en servidores de aplicaciones y servidores de bases de datos de hasta un 30%. Disminución en el nº de sesiones abiertas contra BB.DD.

3. Beneficios de VPFW. Ahorros de ancho de banda de salida de hasta 40Gb. diarios. Reducción del tiempo en la localización y corrección de incidencias. Time to market: 3 días para la instalación, configuración, formación, tests en preproducción y paso a producción de Ventus Proxy. ROI’s estimados de entre 4 y 6 meses para instalaciones entre 60 y 120 mil euros

4. Posibles escenarios con VPFW SITUACION PASADA xml rq Internet xml rq xml rs xml rs CLIENTE SERVIDOR

4. Posibles escenarios con VPFW SITUACION ACTUAL CLIENTE xml rq Internet SERVIDOR xml rq xml rs xml rs xml rq xml rs Ventus Proxy for Webservices --- En caché --- --- No En caché ---

4. Posibles escenarios con VPFW SITUACION FUTURA CLIENTE xml rq SERVIDOR xml rq xml rs xml rs xml rq xml rs Ventus Proxy for Webservices --- En caché --- --- No En caché --- Ventus Proxy for Webservices --- En caché --- --- No En caché --- Internet

4. Posibles escenarios con VPFW Existen múltiples posibilidades de integrar VPFW dentro de la infraestructura del cliente. Evidentemente esto dependerá de los componentes hardware/software que ya existan y de la manera cómo estén interrelacionados. El siguiente es un ejemplo real de instalación de VPFW sin más pretensión que mostrar como, de una manera sencilla, VPFW puede integrarse en la infraestructura del cliente. El cliente dispone de firewall y de un balanceador de carga que reparte las peticiones entre distintos servidores (los 4 servidores destinados al webservice y otros servidores que realizan otras tareas). Con la inclusión de VPFW con balanceo de carga, la arquitectura definitiva es la siguiente:

Otras peticiones Firewall Balanceador de carga S A S B S WS1 S WS2 S WS3 S WS4 VPFW INTERNET Peticiones al webservice ( PASIVO) VPFW Peticiones al webservice (ACTIVO) 4. Posibles escenarios con VPFW

La caché se activa y funciona sin tener que tocar ni una sola línea de código de las aplicaciones que ya están corriendo. Actualizaciones sin parada de servicio. Después de una parada la caché recupera exactamente la misma información que tenía antes de dicha parada EXCEPTO los documentos que ya hayan caducado entre la parada y la consiguiente arrancada. CÓMO SE CONSIGUE ESTO???? 5. VPFW es NO INTRUSIVO.

La caché se activa y funciona sin tener que tocar ni una sola línea de código de las aplicaciones que ya están corriendo.

Actualizaciones sin parada de servicio. Después de una parada la caché recupera exactamente la misma información que tenía antes de dicha parada EXCEPTO los documentos que ya hayan caducado entre la parada y la consiguiente arrancada.

CÓMO SE CONSIGUE ESTO????

POR REGLA NAT DE FIREWALL: 5. VPFW es NO INTRUSIVO. SERVIDOR DE APLICACIONES interfaces.cliente.com [ 192.168.0.yyy ] VENTUS PROXY FOR WEBSERVICES VPFW [ 192.168.0.xxx ] REGLA DE NAT interfaces.cliente.com [ 192.168.0.xxx ] en lugar de [ 192.168.0.yyy ] Request: http:// interfaces.cliente.com /...

POR REGLA NAT DE FIREWALL:

Si desactivo la regla NAT: 5. VPFW es NO INTRUSIVO. SERVIDOR DE APLICACIONES interfaces.cliente.com [ 192.168.0.yyy ] VENTUS PROXY FOR WEBSERVICES queda fuera de línea VPFW [ 192.168.0.xxx ] Request: http:// interfaces.cliente.com /...

Si desactivo la regla NAT:

El proveedor tiene dado de alta en su VPFW un interface en modalidad servidor (como proveedor de los datos), que es el interface XXX usado por diferentes clientes (agencias online, …) El proveedor también tiene dado de alta en su VPFW un interface en modalidad cliente contra el proveedor X (en este caso se actua como el cliente que consulta los datos), para recoger disponibilidad de hoteles, o disponibilidad de alquiler de coches, o información metereológica, etc. Los interfaces cliente y servidor del mismo interface se reconocen entre sí, y activan de manera automática (y transparente a las aplicaciones de los usuarios) una serie de funcionalidades añadidas como son: a. La compresión automática de la comunicación : VPFW servidor comprime la respuesta, el VPFW cliente la descomprime y la sirve a la aplicación cliente (que ya se despreocupa de descomprimir). 6. Interfaces clientes y servidores en el mismo software

El proveedor tiene dado de alta en su VPFW un interface en modalidad servidor (como proveedor de los datos), que es el interface XXX usado por diferentes clientes (agencias online, …)

El proveedor también tiene dado de alta en su VPFW un interface en modalidad cliente contra el proveedor X (en este caso se actua como el cliente que consulta los datos), para recoger disponibilidad de hoteles, o disponibilidad de alquiler de coches, o información metereológica, etc.

Los interfaces cliente y servidor del mismo interface se reconocen entre sí, y activan de manera automática (y transparente a las aplicaciones de los usuarios) una serie de funcionalidades añadidas como son:

a. La compresión automática de la comunicación : VPFW servidor comprime la respuesta, el VPFW cliente la descomprime y la sirve a la aplicación cliente (que ya se despreocupa de descomprimir).

b. La sincronización de la caducidad de los documentos recibidos del servidor. Cuando el VPFW cliente graba en su caché el documento recibido del proveedor, siempre lo hace con la caducidad marcada por el VPFW de dicho proveedor. C. La desactivación del VPFW servidor no afecta al funcionamiento del VPFW cliente, y viceversa. 6. Interfaces clientes y servidores en el mismo software

b. La sincronización de la caducidad de los documentos recibidos del servidor.

Cuando el VPFW cliente graba en su caché el documento recibido del proveedor, siempre lo hace con la caducidad marcada por el VPFW de dicho proveedor.

C. La desactivación del VPFW servidor no afecta al funcionamiento del VPFW cliente, y viceversa.

7. Puntos clave de la gestión de caché: 7.1. Identificación del interface El interface se identifica por una lista de URLs.

7. Puntos clave de la gestión de caché: 7.1. Identificación del cliente, llamada y documento de entrada.

7. Puntos clave de la gestión de caché: 7.1. Identificación de los documentos de error/alerta.

Pestaña CONFIGURACIÓN Se define: Los elementos índice para este documento de entrada, en base a los cuales se genera el IDU. La sustitución de valores (si cabe) en el documento de respuesta antes de devolverlo al cliente 7. Puntos clave de la gestión de caché: 7.2. Elementos índice y sustituciones.

Pestaña CONFIGURACIÓN

Se define:

Los elementos índice para este documento de entrada, en base a los cuales se genera el IDU.

La sustitución de valores (si cabe) en el documento de respuesta antes de devolverlo al cliente

Pestaña CONFIGURACIÓN Añadir “Elemento índice” 7. Puntos clave de la gestión de caché: 7.2. Nuevo elemento índice

Pestaña CONFIGURACION Añadir “Sustitución” 7. Puntos clave de la gestión de caché: 7.2. Nueva sustitución

Pestaña CACHE Tiempo de caché 7. Puntos clave de la gestión de caché: 7.2. Tiempo de caché.

7. Puntos clave de la gestión de caché: 7.3. Reglas de exclusión e inclusión Con la regla de nuestra izquierda nunca cachearemos la respuesta de aquellas consultas de disponibilidad con fecha de entrada al hotel 25 de diciembre de 2008 para los hoteles con identificador 125 ó 342.

7. Puntos clave de la gestión de caché: 7.3. Reglas de caducidad Con la regla de nuestra izquierda, a la llegada de un documento “BuildSearchForm”, automáticamente caducaremos todos los documentos “GetAvailAccom” tales que coincidan el valor de los elementos ‘Language’ y ‘Product’.

7. Puntos clave de la gestión de caché: 7.3. Eventos externos Con el evento de nuestra izquierda, caducaremos todos los ‘OTA_HotelAvailRQ’ cuyos elementos ‘Requestor_ID’ y ‘Room_Quantity’ coincidan con los valores enviados desde nuestra aplicación (vía XML) a Ventus Proxy.

8. Estadísticas Formulario de consulta

8. Estadísticas Resultado general

8. Estadísticas Acceso al servidor

8. Estadísticas Más información

8. Estadísticas Errores

8. Estadísticas Desglose por fecha

8. Estadísticas Desglose por fecha y hora

Para proteger los servidores ante avalanchas de peticiones. Restringir el número de peticiones a enviar por distintos criterios, tanto a nivel de llamada como de cliente. 1. Restricción de envío por cuota media. 2. Restricción de envío por cuota máxima. 3. Restricción de envío por cuota nominal. 4. Restricción de envío por franja horaria. 9. Gestor de cuotas.

Para proteger los servidores ante avalanchas de peticiones.

Restringir el número de peticiones a enviar por distintos criterios, tanto a nivel de llamada como de cliente.

1. Restricción de envío por cuota media.

2. Restricción de envío por cuota máxima.

3. Restricción de envío por cuota nominal.

4. Restricción de envío por franja horaria.

9. Gestor cuotas Lista de llamadas del webservice

9. Gestor cuotas Gestor de cuotas para la llamada “OTA_HotelAvailRQ”

Sólo para interfaces en modalidad servidor. Elementos diferenciadores: 1. Es capaz de balancear a nivel de interface. 2. Es capaz de balancear por por cookie (jsessionid, aspsessionid, …) y por un elemento del documento de entrada . 3. Es capaz de transformar la url/puerto de destino antes de redirigirla a los servidores internos. 4. La regla de balanceo que se aplica es un round-robin por llamada . 5. Dispone de una herramienta gráfica de monitorización que nos indica qué clientes y qué llamadas hay abiertas en ese instante en cada servidor. 10. Balanceador de carga.

Sólo para interfaces en modalidad servidor.

Elementos diferenciadores:

1. Es capaz de balancear a nivel de interface.

2. Es capaz de balancear por por cookie (jsessionid, aspsessionid, …) y por un elemento del documento de entrada .

3. Es capaz de transformar la url/puerto de destino antes de redirigirla a los servidores internos.

4. La regla de balanceo que se aplica es un round-robin por llamada .

5. Dispone de una herramienta gráfica de monitorización que nos indica qué clientes y qué llamadas hay abiertas en ese instante en cada servidor.

9. Balanceador de carga Configuración global de balanceo

9. Balanceador de carga Configuración de balanceo para un interface

La monitorización testea el correcto funcionamiento de los webservices. Las alertas por incorrecto funcionamiento se configuran a nivel de interface o bien a nivel de llamada de cada interface. VPFW es capaz de determinar si se ha excedido un determinado umbral de peticiones consideradas "erróneas“ … .. o bien si los tiempos de respuesta del sistema para cada tipo de mensaje son o no "aceptables". Si alguna de estas dos premisas no se cumple, el sistema enviará un alerta (por correo, SMS, etc.) al administrador. 11. Monitorización.

La monitorización testea el correcto funcionamiento de los webservices.

Las alertas por incorrecto funcionamiento se configuran a nivel de interface o bien a nivel de llamada de cada interface.

VPFW es capaz de determinar si se ha excedido un determinado umbral de peticiones consideradas "erróneas“ …

.. o bien si los tiempos de respuesta del sistema para cada tipo de mensaje son o no "aceptables".

Si alguna de estas dos premisas no se cumple, el sistema enviará un alerta (por correo, SMS, etc.) al administrador.

11. Monitorización Datos generales

11. Monitorización Peticiones erróneas

11. Monitorización Desconexión y reconexión

11. Monitorización Mensajes

11. Monitorización Programación de un envío