Upload
jordi-figueras
View
805
Download
1
Embed Size (px)
DESCRIPTION
VPFW es un servidor proxy de Webservices XML/SOAP con las siguientes características: - Validación de documentos XML / SOAP - Compresión, Cache y balanceo de carga - Tratamiento de peticiones SSL
Citation preview
22
Sumario1. 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
33
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.
44
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
55
2. Características generales
Estadísticas de uso de los webservices
Monitorización
Seguridad
QoS: protección de servidores
66
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.
77
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
88
4. Posibles escenarios con VPFW
SITUACION PASADA
xmlrq
Internet
xmlrq xmlrs
xmlrs
CLIENTE
SERVIDOR
99
4. Posibles escenarios con VPFW
SITUACION ACTUALCLIENTE
xmlrq
Internet
SERVIDORxmlrq
xmlrs
xmlrs
xmlrq xmlrs
Ventus Proxy for Webservices
--- En caché ---
--- No En caché ---
1010
4. Posibles escenarios con VPFW
SITUACION FUTURACLIENTE
xmlrq
SERVIDORxmlrq xmlrs
xmlrs
xmlrq xmlrs
Ventus Proxy for Webservices
--- En caché ---
--- No En caché ---
Ventus Proxy for Webservices
--- En caché ---
--- No En caché ---
Internet
1111
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:
1212
Otras peticiones
Firewall
Balanceador de carga
SA SB
SWS1 SWS2 SWS3 SWS4
VPFW
INTERNET
Peticiones al webservice ( PASIVO)
VPFW
Peticiones al webservice (ACTIVO)
4. Posibles escenarios con VPFW
1313
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????
1414
5. VPFW es NO INTRUSIVO.• POR REGLA NAT DE FIREWALL:
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/...
1515
5. VPFW es NO INTRUSIVO.• Si desactivo la regla NAT:
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/...
1616
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).
1717
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.
1818
7. Puntos clave de la gestión de caché:
7.1. Identificación del interface
El interface se identifica por una lista de URLs.
1919
7. Puntos clave de la gestión de caché:
7.1. Identificación del cliente, llamada y documento de entrada.
2020
7. Puntos clave de la gestión de caché:
7.1. Identificación de los documentos de error/alerta.
2121
Pestaña CONFIGURACIÓN
Se define:
1. Los elementos índice para este documento de entrada, en base a los cuales se genera el IDU.
2. 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.
2222
Pestaña CONFIGURACIÓN
Añadir “Elemento índice”
7. Puntos clave de la gestión de caché:
7.2. Nuevo elemento índice
2323
Pestaña CONFIGURACION
Añadir “Sustitución”
7. Puntos clave de la gestión de caché:
7.2. Nueva sustitución
2424
Pestaña CACHE
Tiempo de caché
7. Puntos clave de la gestión de caché:
7.2. Tiempo de caché.
2525
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.
2626
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’.
2727
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.
2828
8. Estadísticas
Formulario de consulta
2929
8. Estadísticas
Resultado general
3030
8. Estadísticas
Acceso al servidor
3131
8. Estadísticas
Más información
3232
8. Estadísticas
Errores
3333
8. Estadísticas
Desglose por fecha
3434
8. Estadísticas
Desglose por fecha y hora
3535
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.
3636
9. Gestor cuotas
Lista de llamadas del webservice
3737
9. Gestor cuotas
Gestor de cuotas para la llamada “OTA_HotelAvailRQ”
3838
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.
3939
9. Balanceador de carga
Configuración global de balanceo
4040
9. Balanceador de carga
Configuración de balanceo para un interface
4141
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.
4242
11. Monitorización
Datos generales
4343
11. Monitorización
Peticiones erróneas
4444
11. Monitorización
Desconexión y reconexión
4545
11. Monitorización
Mensajes
4646
11. Monitorización
Programación de un envío