Para entender bien lo que es un Proxy nos iremos al ámbito de las Redes ya que es un tema casi todos comprendemos, Todos hemos escuchado de los proxy de red o Servidores Proxy los cuales nos impiden que entremos a una determinada pagina como por ejemplo las redes sociales o paginas de vídeos en streaming. Pues bien estos servidores implementa el patrón de diseño proxy, ya que antes de enviar la solicitud a la pagina que queremos entrar primero valida si la pagina no esta en la lista de paginas bloqueadas si no es a sí entonces manda el request a la pagina y el proxy antes de enviarnos la respuesta a nuestro navegador valida por ejemplo que la pagina no tenga contenido prohibido como por ejemplo paginas de adulo o vídeo juegos, Si el proxy detecta que la respuesta de la pagina regresa un contendido de estos entonces el proxy nos manda una pagina distinta a la solicitada diciendo que la pagina tiene contenido indeseado.

Los proxy tiene varias utilidades y podemos utilizarlo para lo que queramos, para este caso hablaremos de ejemplo prácticos los cuales son usados con regularidad.

Proxy de Seguridad: 

Cuando desarrollamos aplicaciones por lo general desarrollamos clases que utilizamos como BusinessService (Clases con operaciones de negocio) estas clases generalmente no requieren autenticación y los usuarios pueden invocar los métodos sin ningún problema, ¿pero que pasa si un día decidimos que estos métodos requieren de privilegios para ser ejecutados? una solución seria modificar los métodos para que recibieran las credenciales o modificar la aplicación para que valide los privilegios antes de mandar llamar los métodos de negocio, Sin embargo estos cambios son radicales ya que implicaría modificar la firma de los BusinessService impactando gran parte del proyecto o modificar cada parte en donde hacíamos un llamada a los BusinessService para agregar la validación antes de la llamada. Estas soluciones producirían un gran cambio en nuestra aplicación y afectaría los componentes ya desarrollados y probados para tener que volver a la etapa  de pruebas y validar nuevamente que la aplicación sigue funcionando correctamente.

Solución: En vez de lo anterior podríamos envolver la ejecución del BusinessService en un Proxy el cual antes de mandar llamar al BusinessService cheque las credenciales del usuario y posteriormente invoque al BusinessService, Pero no solo eso podemos hacer, También podría mandar llamar a otro servicio de Auditoria una vez que el servicio de negocio fue invocado, esto es posible por que un proxy puede hacer algo antes y después de realizar la tarea que realmente el cliente quiere realizar, sin embargo el cliente no es consciente de lo que pasa antes y después de la invocación del BusinessService.

Proxy de invocación remota.

Otro de los escenarios para los cuales se utilizan los proxy son para enmascarar la invocación de métodos remotos.

El procedimiento para realizar esto es creando una interfaz que contenga las operaciones que queremos invocar de forma remota, Luego creamos una un Proxy a través de la interfaz la cual delegue el comportamiento a una clase que se encargue de realizar la comunicación con el servicio remoto y al final regrese lo resultados al cliente de nuestra aplicación, De esta forma la invocación remota es invisible y no se dará cuenta de que detrás del proxy existe una conexión con algún servicio remoto.

Conclusión:

En resumen podríamos decir que un Proxy es un intermediario que puede interceptar una petición y hacer algo con ella antes y después de ejecutar la operación deseada por el usuario e incluso podemos cancelar la invocación como en el caso que no tenga los privilegios.

Es importante remarcar que los Proxy tiene muchas utilidades y estas que planteo a qui solo son alguno de la multitud de utilidades que tiene. Otro escenario para el cual se utilizan es para el Debug de aplicaciones de lo cual hablare en otra entrada.

Ya está a la venta mi nuevo libro “Introducción a los patrones de diseño“, en donde expongo los 25 patrones de diseño más utilizados y explicados desde un enfoque del mundo real, con ejemplos que pueden ser aplicados en tus proyectos. Sin duda es unos de los libros más completos de patrones de diseño en español.

The post Patrón de diseño – Proxy appeared first on Oscar Blancarte - Software Architecture.

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.

The post Que es la Virtualización de Servicios appeared first on Oscar Blancarte - Software Architecture.