•Definición de webservices XML/SOAP, e introducción de los clientes y llamadas asociados a estos webservices.
•Definición de las reglas de identificación de webservice, cliente, llamada, documento de entrada y documento de respuesta.
•Análisis del documento XML/SOAP entrante a partir de la generación de elementos índice (aquellos elementos del documento que deben considerarse para establecer el criterio de caché), los cuales identifican de manera única un determinado documento a través de un identificador de documento único (IDU). Se cachea el documento de respuesta solicitado, asociándolo al IDU.
•Hasta 3 criterios diferentes para caducar documentos de la caché: por tiempo de caché de la llamada, por reglas de caducidad y por eventos externos.
•Es capaz de balancear a nivel de servidor y puerto.
•Es capaz de balancear a nivel de webservice: es decir, se pueden definir conjuntos distintos de servidores de balanceo para cada webservice.
•Es capaz de reescribir la url de destino antes de redirigirla a los servidores.
•Es capaz de balancear por cookie y por un elemento del documento de entrada
•La regla de balanceo que se aplica es un round-robin por llamada.
•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.
•VPFW es capaz de decidir si una petición determinada, que no se encontró en caché, debe o no debe ser enviada a los servidores del webservice. Existen hasta 4 diferentes criterios para restringir el acceso de peticiones a los servidores del webservice, y estas restricciones pueden aplicarse tanto a nivel de servicio (llamada) del webservice como a nivel de cliente:
-
1. Restricción de acceso por cuota media de peticiones simultáneas.
2. Restricción de acceso por cuota máxima de peticiones simultáneas.
3. Restricción de acceso por cuota nominal de peticiones.
4. Restricción de acceso por franja horaria.
•Capacidad para validar documentos XML o SOAP usando esquemas xsd.Los servidores del webservice delegan en VPFW la validación de los documentos de entrada, liberándose así de esta tarea.
•Capacidad de desencriptar la petición segura recibida del cliente y transformarla en una petición no segura antes de redirigirla a los servidores del webservice, liberando a éstos de esta tarea.
•Capacidad de encriptar la petición no segura recibida de la aplicación del cliente y transformarla en una petición segura antes de redirigirla a los servidores del webservice, liberando así a dicha aplicación de esta tarea.
•Capacidad de devolver comprimida la respuesta al cliente si éste así lo solicitó mediante la cabecera accept-encoding de la petición, liberando así a los servidores del webservice del proceso de compresión.
Algoritmos gzip y deflate soportados.
•Capacidad de solicitar la respuesta comprimida a los servidores del webservice del proveedor mediante la modificación de la cabecera accept-encoding de la petición. Si el proveedor es capaz de entregar la respuesta comprimida en el formato solicitado (algoritmos gzip y deflate soportados), entonces VPFW automáticamente descomprime dicha respuesta antes de entregarla a la aplicación del cliente, liberando así a ésta del proceso de descompresión.
Capacidad para tracear todas las peticiones entrantes a través de la generación de hasta 4 diferentes archivos de log:
-
1. Log de sistema: dónde se registran todos los eventos del sistema (el detalle de una arrancada o parada, el resultado de la ejecución de una determinada tarea, etc.)
2. Log de acceso: dónde se registran los accesos de los clientes a VPFW, es decir, cada una de las peticiones entrantes al sistema.
3. Log de errores: dónde se registran todos los errores producidos en las peticiones, dando información sobre la IP de origen que provocó el error, interface y/o cliente y/o llamada donde se ha producido el error, descripción del error (con información adicional si es el caso) y documento de entrada y/o respuesta que provocó el error (si es el caso).
4. Log de debug: este es un log que puede activarse desde la administración del interface. Una vez activo, registra una serie de tiempos de respuesta correspondientes a los distintos procesos que se ejecutan en VPFW para cada petición entrante.
A partir del análisis del log de acceso, se generan estadísticas detalladas de toda la actividad generada por los webservices: información de acceso de los clientes, de uso de las llamadas de los webservices, tiempos de respuesta de los servidores, volumen de transferencia de datos de entrada y salida, análisis de errores generados por los webservices, etc.
La monitorización testea el correcto funcionamiento de los webservices. Las alertas se configuran a nivel de interface o bien a nivel de llamada de cada interface. Funciona de la siguiente manera:
- Se introducen los datos generales de la alerta: interface y/o llamada a monitorizar, código y descripción de la alerta, y el nº de peticiones que se procesarán cada vez (se testean paquetes de N peticiones).
- Se determina el motivo por el cual se disparará la alerta: bien porque se ha excedido un determinado umbral de peticiones consideradas "erróneas", o bien porque un determinado número de peticiones han sobrepasado un tiempo de respuesta considerado "no aceptable".
- Se indican los errores por los cuales consideraremos que una petición no es correcta: por ejemplo, porque la petición ha provocado un timeout de respuesta, o bien porque la petición ha provocado un error de "tarjeta de crédito caducada", etc.
- Si se sobrepasa alguno de los límites indicados anteriormente, se envía una alerta al administrador del interface (o a la persona que se indique) vía email o SMS y, opcionalmente, tenemos la posibilidad de desconectar el interface durante un determinado periodo de tiempo, tras el cual VPFW intentará volver a reconectar.
A partir de este análisis se generan estadísticas detalladas de toda la monitorización de webservices, donde podemos visualizar datos como el número de alertas provocados, tiempo que se han desconectado los interfaces, documentos que han provocado los errores, etc. Estas estadísticas derivan en informes en formato html que pueden ser generados diaria, semanal o mensualmente.
•Dentro de VPFW se pueden definir dos modalidades de webservice: modalidad servidor, que quiere decir que el webservice actúa como proveedor de datos para sus clientes, y modalidad cliente, que quiere decir que el webservice actúa como cliente que consulta datos de otro webservice.
Con VPFW se pueden tener indistintamente tantos webservice como se quiera en la modalidad que corresponda en cada caso.
•En el caso más óptimo, en el cual el propietario del webservice proveedor de datos disponga de un VPFW y los clientes de este proveedor también dispongan de VPFW, dichos VPFW se reconocerán entre sí y activarán de manera automática (y transparente a las aplicaciones de los usuarios) una serie de funcionalidades añadidas como son:
- La compresión automática de la comunicación: el VPFW servidor comprime la respuesta, el VPFW cliente la descomprime y la sirve a la aplicación cliente.
- 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.
•La desactivación del VPFW servidor no afecta al funcionamiento del VPFW cliente, y viceversa.
•VPFW es no intrusivo: se instala dentro de la infraestructura del cliente sin necesidad de modificar código alguno de las aplicaciones que ya están funcionando.
•Despliegue fácil y rápido: al no tener que modificar las aplicaciones existentes, se podría activar un VPFW en un entorno de producción el mismo día de la instalación.
•Administración y configuración vía web: con VPFW se suministra una potente herramienta web que, de una manera muy sencilla e intuitiva, permite la administración y configuración de todos sus componentes.
•Actualizaciones sin paradas de servicio: VPFW puede actualizarse sin necesidad de parada del sistema del cliente.