Para los que ya tenemos mas experiencia en la arquitectura SOA y comprendemos perfectamente que es un Enterprise Service Bus este tema las ha de parecer muy simple pero para todos aquellos que no han tenido la oportunidad de adentrarse a los obscuros territorios de lo que es SOA les tengo buenas noticias pues en esta Entrada hablaremos que es la virtualización.

Para empezar virtualizar viene de la palabra virtual como cuando hablamos de maquinas virtuales, pues esto es algo parecido pues un servicio virtual no es mas que una mascara que lo único que hace es exponer un WebService que por dentro hace la llamada a otro u otros WebServices para dar una funcionalidad nuevo o extendida.

Imaginemos que estamos desarrollando una aplicación móvil para una empresa la cual dentro de sus sistemas ya tiene un conjunto de webservices desarrollados para las principales tareas que realiza, sin embargo hasta el momento no tiene ningún desarrollo para móviles y le preocupa la seguridad ya que al exponer sus webservices tema que alguna persona mal intencionada pueda entrar y hacer algún mal.

Por lo que desarrollo un WebService para que el usuario se Autentifique cuando entre a la aplicación, sin embargo eso no es todo, también requiere que cuando el usuario realice alguna acción se validen sus privilegios para denegar cualquier acción no permita para ese usuario.

Otro punto importante es que el cliente quiere que cuando una persona intente hacer una acción no autorizada o falle en el Login se registre tal acción para poder auditar y detectar situaciones sospechosas.

El cliente nos brinda los siguientes WebServices con los que debemos diseñar nuestra aplicación:

SecurityService  //WebServices que expone el sistema de seguridad centralizado.

• login(usuario, password) : boolean: Operación que autentifica al usuario y nos dice indica si el login fue exitoso o no.
• autorization(usuario,password, accion ):boolean: Operación que nos indica si un usuario tiene privilegios para realizar una acción determinada, El parámetro acción representa el ID de la operación a ejecutar.

AuditService //WebService que expone el sistema de Auditoria Informática

• intentoAccion(usuario, accion, DateTime, autorizationResult): void: Operación que registra cuando una acción es solicitada

ClienteService //WebService para consultar los datos del cliente

• consultaDatosPersonales(idCliente): Cliente: Operación que regresa los datos básicos del cliente como nombre,apellido, sexo, CURP, etc.
•  consultaSaldo(idCliente): double: Operación que regresa el saldo del cliente

Desarrollando la solución

Imaginemos que la aplicación lo único que hace es consultar los datos del cliente y su saldo sin embargo no todos los usuarios pueden saber el saldo de un cliente por lo que el servicio se separa y se consulta de forma independiente.

Lo primero que se nos ocurre es hacer una pantalla de login y autenticarnos con el servicio de login pasandole el nombre de usuario y password. Si el login se realiza correctamente entramos a la aplicación, sin embargo el cliente quiere que cuando un login falle o se de correctamente notifiquemos el evento al departamento de Auditoria mediante la operación de intentoAccion y pesarla el ID de la operación Login y la fecha y hora del intento.

Esto desde luego nos implicaría dos llamadas a Webservices, uno para Login y otro para Auditoria:

 Fig.1: Muestra la comunicación con los dos webservices de forma separada.

Para la pantalla de datos del cliente tendríamos que implementar nuevamente un sistema de llamadas donde primero verificaríamos si tenemos privilegios para leer los datos del cliente con el webservices de autorizacion, de darse los privilegios entonces se consulta el Webservices de consultaDatosPerosnales, seguido de consultar los privilegios para autorizar al usuario para leer el saldo del cliente y consultar el servicio de  consultaSaldo. Nuevamente si alguna autorización falla es requerido notificar al departamento de Auditoria mediante el Webservices intentoAccion. Este esquema quedaría algo a sí.

 Fig.2: Fugura que muestra el número de acción a realizar solo para completar la consulta de los datos del cliente y saldo.

Un esquema con Virtualización:

Una vez que examinamos como tendríamos que desarrollar una aplicación sin virtualización podemos empezar a examinar el esquema con virtualización.

La primera acción que deberíamos hacer es crear un proxy que cumpla casi exactamente con el contrato(WSDL) que sirve como punto de entrada a nuestra aplicación pero que ademas de esto le estaríamos pasando los datos de autenticación y autorización en el Header del mensaje SOAP de tal forma que el proxy tomara el header lo enviara al servicio de autorization en caso de autorización continuara con la llamada al servicio de consultaDatosPerosnales y regresara el resultado.Pero en caso de haber fallado la autorización llamaría al servicio de Auditoria y regresaría un Throw para indicar que el servicio ha fallado por seguridad.

La aplicación se viera de esta manera para el escenario de consulta de datos del suscriptor:

Fig.3: Escenario con virtualización

Si nos damos cuenta en este escenario ya solo tenemos una invocación a un único servicio el cual se encarga de realizar las operaciones previas a la consulta de los datos del cliente y también notificar al departamento de Auditoria en caso de haber fallado la autorización.

Este enfoque tiene las siguientes ventajas:

• Se reduce el numero de llamadas al servidor
• Aumentan los tiempos de respuesta
• Las operaciones se realizan desde la misma infraestructura del cliente por lo que la seguridad es mucho mejor.
• El implementar un Enterprice Service Bus nos da la cualidad de poder medir el performance (KPI o Key Performance Indicator).
• Definir los acuerdos de nivel de servicio o SLA.