Message QEUE RabbitMQ

Probablemente muchos desarrolladores (me incluyo), hemos oido poco sobre cola de mensajes es una perspectiva distinta a lo que comúnmente estamos acostumbrados : las peticiones y respuestas que suceden en la red. Me enfocare en describir el uso MQ con la herramienta RabbitMQ.

Primero que es Message Qeue
Por concepto es la comunicación via mensajes entre sistemas  donde los emisores producen mensajes y para que estos lleguen a su destinatario deben ser entregados a un intercambiador que los colocará en la cola del respectivo destinatario, finalmente el destinatario puede ir progresivamente desencolando y procesando los mensajes o dejar que el intercambiador se los haga llegar, esto por medio de diferentes tipos de rutas.


¿Por qué utilizar RabbitMQ? 

Sirve como una buena herramienta backend de mensajería para hacer PUB/SUB, etc en nuestro middleware. 

• Muy robusta 
• Se puede configurar para utilizar mensajes persistentes 
• Fácil de utilizar 
• Tiene enlaces para todos los idiomas principales 
• Open Source 
• Un montón de plugins 
• Ampliamente utilizado 
• Una buena documentación 
• Un montón de tutoriales
• Un montón de patrones de uso  
• oportunidades de expansión

Uso

1. Instalar el backend en un server
2. Conectarse a el usando su lenguajes de edicion.
3. Definir los intercambios y sus políticas directamente en el código 
4. Enviar mensajes

Patrones comunes de uso

Simple Messaging

Simple usado  para desacoplar los componentes 
Un productor P produce mensajes, mientras que el consumidor C lo consume. 
At-most-once semántica para colas persistentes 
At-least-once semántica si se utilizan reconocimientos


Work Queues

Múltiple consumidores comparten cargas de trabajo
Los mensajes pueden ser o bien prebuscados por los workers o entregarse cada vez que un worker está a disposición


Pub Sub

Aquí el intercambio X se encarga de la entrega de mensajes igual que en el caso típico, se utiliza la entrega de conductores de salida 


Las colas se generan para los consumidores, en los que será enviado sus mensajes relevantes.


Routing

(Pub/sub + topics)
Si varios consumidores escuchan el mismo topic a continuación se utiliza fanout delivery
Temas jerárquicos también se pueden utilizar: 
fridge.context. * 
*. *. error 
meetingroom.projector 

meetingroom. *


RPC

Las solicitudes y las respuestas son coincidentes por un ID de correlación 

El cliente también especifica que el servidor debe enviar la respuesta





Gracias

Ejemplo simple de una Arquitectura Orientada a Servicios - SOA para un banco

El funcionamiento de un banco se divide en dos tareas principales:

1.  Conseguir recursos monetarios, mediante las cuentas o servicios que ofrecen a sus clientes, por ejemplo  las cuentas de cheques, cuentas de ahorro, inversiones etc.
2. Colocar los recursos obtenidos dentro del ambito comercial mediante créditos ya sea a las empresas o a particulares, las ganancias de un banco se provienen de la diferencia entre los intereses pagados y los intereses obtenidos. 

Entonces identificamos  de un banco:

• Clientes 
• Cuentas 
• Transferencias 
• Declaraciones 
• Pagos en linea 
• Estadísticas / Reportes

Una plataforma de software tradicional de banco, tiene   

• Muchos modelos 
• Controladores de administrador 
• Controladores para los clientes 
• Dificultas para la rehabilitación ante los errores o caida del sistema. 

El Banco en una Arquitectura Orientada a Servicios 

SOA rompe grandes plataformas de software en pequeños servicios, componentes y aplicaciones reutilizables. Cada servicio puede almacenar datos en su propia base de datos o usar otros servicios de datos.

Segun Wikipedia :

Un servicio es una unidad autónoma de funcionalidad, por ejemplo la recuperación de un estado de cuenta bancariaen línea. Los servicios pueden ser combinadas por otras aplicaciones de software para proporcionar la funcionalidad completa de una aplicación de software grande. SOA facilita a los computadoras conectados en una red para que cooperen entre ellas. 

Los servicios son unidades no asociadas, formados con flexibilidad de funcionalidad independientes del ambiente. Cada servicio implementa al menos una acción, como por ejemplo la presentación de una solicitud en línea para una cuenta banaria, la recuperación de un estado de cuenta en línea o la modificación de una orden de compra de entradas online o línea aérea.

Servicios

• Cuentas
• Autenticaciones
• Estadisticas / Reportes
• Cambio de moneda
• Notificaciones WebHooks

Componentes

• Gems (persistencia, intercambio de mensajes)
• Rails engines (REST APIs, Autenticacion)
• etc .......

Data

• Cada servicio puede tener su propia base de datos.
• Diferentes tipos de base de datos (SQL, NoSQL,etc..)

Aplicaciones

• Interfaz de usuario (uno o mas ..)
• Banca en linea
• Website del Banco
• Aplicaciones mobiles
• Servicios de terceros (como los pagos de Bitcoin)

Introduccion a los Web Services

Un servicio web nos permite utilizar la funcionalidad de una aplicación sin necesidad de visitar el sitio de esa aplicación. ha sido diseñado para apoyar las interacciones de máquina a máquina sobre una red.

Interoperabilidad

Una API se utiliza para mejorar las características y la funcionalidad a una o ambas aplicaciones, reciben llamadas que incluyen: 

• Las instrucciones sobre cómo interactuar con la aplicación 
• Parámetros (qué tipo de información se pasa) 
• Valores (cada parámetro tiene un valor que se le atribuye)

Para que usamos un Web service

Lo usamos para exponer nuestros datos a otros programas, por ejemplo Yo deseo que haya otra aplicación que consulte mi API como lo hace el API de FB TW INSTAGRAM, quiero ofrecer mi información para que hagan algo adicional por ejemplo lo mas común quiero que me suban información de manera automatizada.

Usamos WS para facilitar el desarrollo del frontend últimamente tenemos esta tendencia, donde el programador frontend usa una api rest para consumir los datos que va a mostrar en sus interfaces.
Por ejemplo: si estamos usando un stack de desarrollo MEAN (MongoDB, Express, Angular.js, Node.js),  con angular.js del lado del frontend podemos consumir web services para desarrollar aplicaciones integradas y muy dinamicas (RIA web).

Usamos WS para crear arquitecturas orientadas a servicios, las aplicaciones modernas ya no son monolíticas que quiere decir que una aplicación contenía todo el código que servia a toda nuestra app, ahora lo que se hace en proyectos grandes,es crear aplicaciones pequeñas que exponen un API/Web service para comunicarse entre ellas, se hace esto por que son muchos mas fáciles de mantener ,distribuimos la complejidad y cada sistema se mantiene y opera sola. 

Que significa RESTafarian

Un restafarian es un sostenedor, defensor de la arquitectura REST propuesta por Roy Fielding, la profecia RESTafarian sostiene que todas las aplicaciones (menos las RESTfull) tendrán dificultades para gestionar el cambio y evitar la ruptura de clientes fuertemente acoplados. Esto tendrá un impacto negativo en la velocidad y el costo de la innovación esto los hara menos competitivo a través del tiempo.

Que es REST ?  (Representational State Transfer)

Es un estilo de arquitectura para sistemas distribuidos,el término se originó en el año 2000 en la tesis doctoral Architectural Styles and the Design of Network-based Software Architectures escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP.


Los principios de REST

Identificación de recursos
Los recursos se separan para ser enviados al cliente

Manipulación de recursos
El cliente puede manipular los recursos con la representación. El diseño debe estar orientado  a los recursos.

        http://api.zonajobs.com/users/create?userId=235

        http://api.zonajobs.com/users/retrieve?userId=235

        http://api.zonajobs.com/users/update?userId=235

        http://api.zonajobs.com/users/delete?userId=235

        http://api.zonajobs.com/users/retrieveAll

        http://example.com/customers/1234

        http://example.com/orders/2007/10/776654

        http://example.com/product/4554

        http://example.com/processes/sal-increase-234

Mensaje auto descriptivo
Cada mensaje incluye suficiente información descriptiva sobre su procesamiento

HATEOAS 

Hypertext As The Engine Of Application State, es el motor de estado de la aplicación, este principio sostiene que un cliente debe interactuar con una aplicación enteramente a través de referencias hypermedia provistas dinámicamente por el servidor,un cliente dentro de un contexto REST no debe tener nigún conocimiento previo de la API más alla de un punto de entrada y un entendimiento general del funcionamiento de un sistema hypermedia. 

Figura 1

Figura 2

Las restrincciones (constraints) REST recomendable para construir una API RESTfull 

1. Interfaz uniforme

La restricción de interfaz uniforme define la interfaz entre clientes y servidores. Simplifica y desacopla la arquitectura, que permite a cada parte a evolucionar de forma independiente 

Verbos HTTP (CRUD) 
URI (nombre del recurso) 
Respuesta HTTP (estado, cuerpo)


2. Sin estado

• El Server no almacena ningún estado cliente
• Cada petición (request) contiene suficiente contexto para procesar el mensaje (auto mensajes descriptivos)
• Cualquier estado de sesión se lleva a cabo en el cliente proporcionándonos : - - Visibilidad, Confiabilidad y Escalabilidad.

Visibilidad : se mejora debido a que no se tiene que mirar una sola solicitud de fin de determinar su naturaleza.
Confiabilidad : la mejora por que facilita la tareas de recuperación de fallos parciales.
Escalabilidad : se mejora debido a que no tenemos que almacenar el estado entre peticiones , esto permite que el server reparta sus recursos rápidamente.

3. Cache

Como en la World Wide Web, los clientes/CDN puede almacenar en caché las respuestas. 

Esto nos da la ventaja de tener el potencial para eliminar parcial o completamente algunas interacciones, mejorando la eficiencia 

Cada solicitud debe declarar sus propias regla de caché: 
     Implícitamente 
     Explícitamente 

     Negocio

4. Cliente - Servidor

• La separacion de las responsbilidades es el principio detras de la restriccion cliente-servidor.
• Al separar las preocupaciones de la interfaz de usuario de las preocupaciones de almacenamiento de datos, mejoramos la portabilidad de la interfaz de usuario a través de múltiples plataformas y mejoramos la escalabilidad mediante la simplificación de los componentes del servidor.
• Componentes para evolucionar de forma independiente

5. Sistema de capas

Un cliente no necesita conocer con quien esta conectado.

La principal desventaja de los sistemas de capas es que añaden sobrecarga y la latencia para el tratamiento de datos.

6. Codigo en las demandas

El server son capaces de extenderse de manera temporal o personalizar la funcionalidad de un cliente por la logica de transferencia.
La replica puede ser un archivo javascript o java applet.

HTTP

REST utliza este protocolo de peticion y respuesta (request/response)

Figura 3

Request / Response :

HTTP verbos

Recurso	GET	POST	PUT	DELETE
URI	Read	Create	Update	Delete
api.mydomain.com/formularios	Traer todas los Formularios	Error	Error	Borrar todos los Formularios
api.mydomain.com/formularios/1234	Traer un Formulario pagina	Create Formulario	Si existe actualiza el Formulario	Borrar un Formulario

Tipos de respuestas

Generalmente utilizando los codigos de estado HTTP para describir el resultado :

1xx: Infomration (100: continute...)

2xx: Success (200:ok, 201: created...)

3xx: Redirection (301: moved permanently)

4xx: Client error (400: bad request, 404: not found...

5xx: Server error (500: internal error, 501: not impl...)

REST web service API's populares 

https://developer.linkedin.com/apis

http://developers.facebook.com/docs/reference/api/

https://dev.twitter.com/docs/api

http://docs.amazonwebservices.com/AmazonS3/latest/API/APIRest.html

http://developer.nytimes.com/docs/article_search_api

https://developers.google.com/translate/v2/using_rest

Figura 5