MENSAJERIA MSMQ

·         Un sistema d mensajes es un método de comunicación entre componentes de SW o aplicaciones.

·         Un cliente puede enviar, recibir, crear y leer mensajes de otros clientes, conectándose a un agente de mensajería.

·         No es necesario que estén disponibles al mismo tiempo para comunicarse

·         El que envía y recibe no necesitan saber nada uno del otro, solo el formato del mensaje y el destino a usar.

·         Hoy en día se tiene la necesidad de implementar arquitecturas de software que brinden la integración de las plataformas heterogéneas de tecnología, dadas las constantes necesidades  de cambio, muy particulares a cada industria.

·    Dicha área de la integración de sistemas de cómputo se denomina Middleware, el cual puede ser clasificado en tres grandes categorías:

v  Remote Procedure Call – RPC middleware. Permite hacer el llamado de procedimientos remotos como si fuesen locales.

v  Object Request Broker – ORP middleware. Capaz de distribuir y compartir los objetos de una aplicación a través de redes heterogéneas.

v  Message-Oriented Middleware – MOM middleware. Permite a aplicaciones distribuidas comunicar e intercambiar información a través del envío y recepción de mensajes. utiliza los mensajes como método de integración y provee mecanismos para crear, manipular, almacenar y transmitir esos mensajes. Estos sistemas permiten que las aplicaciones intercambien información en forma de mensajes compuestos por cabeceras y dato.

·         Un sistema de mensajes es un método de comunicación entre componentes de SW o aplicaciones.

·         Un cliente puede enviar, recibir, crear y leer mensajes de otros clientes, conectándose a un agente de mensajería.

·         No es necesario que estén disponibles al mismo tiempo para comunicarse

·         El que envía y recibe no necesitan saber nada uno del otro, solo el formato del mensaje y el destino a usar.

Dominios: Punto a punto:

·         Construido alrededor del concepto de colas, remitentes y destinatarios.

·         Cada mensaje está dirigido a una determinada cola

·         Los destinatarios cogen los mensajes de las colas destinadas a recogerlos.

·         Cada mensaje solo contiene un consumidor

·         El destinatario notifica el procesamiento correcto del mensaje.

Dominio orientado a suscripción(Publish/Subscribe):

·         Es un producto o aplicación orientado a suscripción

·         Los clientes direccionan los mensajes a un topic(tema)

·         Editores (Publisher) y Suscriptores (subscribers) son anónimos y pueden publicar o suscribir determinados temas.

·         El sistema cuida en distribuir los mensajes que llegan de múltiples emisores para sus múltiples suscriptores

·         Cada mensaje puede tener múltiples consumidores.Emisores y suscriptores tienen dependencia temporal

Consumo del mensaje:

v  Síncrona: Un suscriptor o receptor puede tomar el mensaje llamando al método de recepción. Este método puede bloquearse hasta que el mensaje llegue o se genere un timeout

v  Asíncrona: Un cliente puede registrarse con un consumidor un oyente de mensajes(message listener). Cuando un mensaje llega a su destino, el proveedor entrega el mensaje llamando al método de recepción.

MSMQ

·         Es una herramienta de Microsoft para realizar la administración de colas de mensajes. La función principal de las colas de mensajes es la de permitir la comunicación asincrónica entre procesos. Muchas veces, se tiene un proceso que invoca una rutina que lleva mucho tiempo, pero que no interesa el resultado de la misma. En la programación tradicional, el proceso llamador queda esperando a que el invocado termine para poder continuar su ejecución, aunque no se vea afectado por los resultados. La ventaja que tienen los mensajes asincrónicos es que el llamador no sabe cuando se ejecuta el proceso y además puede continuar su ejecución una vez enviado el mensaje.

·         Puede enviar objetos (serializados) a la cola, donde permanecerán hasta que reciba. Normalmente se utiliza para enviar mensajes u objetos entre aplicaciones de forma disociada

·         No tiene nada que ver con webservices, son dos cosas diferentes

Message Broker: Una implementación de MQ Broker permite establecer un ESB (Enterprise Service Bus) que básicamente sirve de middleware para la comunicación entre diferentes plataformas que no necesariamente sean JAVA a través de un motor de intercambio de mensajes. MQ Broker se encarga de la conversión y adaptación de estos mensajes para permitir dicha interacción entre aplicaciones.

Message Queue: Message Queue es un middleware orientado a mensajería que a nivel elemental es un servidor de colas, colas que podrían considerarse como canales donde pueden viajar mensajes, canales donde una aplicación X envía un mensaje a una cola y otra aplicación Z está pendiente de esa cola en espera de nuevos mensajes. Cuando el mensaje llega a la cola, la aplicación Z puede leerlo. Las implementaciones y posibilidades de un sistema de mensajería permiten la comunicación entre plataformas distintas mediante el intercambio de mensajes, en donde el servidor asegura la entrega de dichos mensajes, pudiendo ser esta entrega de manera síncrona o asíncrona. Nuestros servicios relacionados con la plataforma de IBM son el de desarrollo de aplicaciones que envíen o reciban mensajes a traves de Websphere MQ, o modificación de aplicaciones existentes para que puedan enviar o recibir mensajes, además de servicios de administración y soporte de Websphere MQ para tareas tales como administrar las colas del servidor, configuración de seguridad y demás.

XML vs JSON

XML & JSON 

XML

·         Es un lenguaje de metamarcado que ofrece un formato para la descripción de datos estructurados. Esto facilita unas declaraciones de contenido más precisas y unos resultados de búsquedas más significativos en varias plataformas. Además, XML habilitará una nueva generación de aplicaciones para ver y manipular datos basadas en el Web.

Ventajas

·         Fácilmente procesable tanto por humanos como por software.

·         Es un lenguaje muy simple(Mas que SGML)

·         Es un lenguaje de marcado muy extensible(Flexibilidad en adición de nuevos servicios, Debe soportar crecimiento en hardware y software)

·         Separa radicalmente la información o el contenido de su presentación o formato.

·         Diseñado para ser utilizado en cualquier lenguaje o alfabeto.

·         Su análisis sintáctico es fácil debido a las estrictas reglas que rigen la composición de un documento.

·         Garantizada por consorcios como W3C.

·         Tiene soporte a cualquier tipo de datos (Cualquier tipo clásico y otros(Multimedia, ejecutables))

·         Estructura Jerárquica

·         El No. De marcas es ilimitado

Desventajas

·         La posibilidad de construir sistemas acordes a nuestras necesidades para el intercambio de datos podría llevarnos a la proliferación de versiones incompatibles y si esto llegase a suceder, entonces la solución que plantea el XML ante la búsqueda de intercambio universal de información, lo llevaría a su opuesto; en vez de unificar todo un lenguaje, nos encontraríamos con lenguajes muy específicos y cada vez más alejados de la “universalidad”.

·         Complejidad de analizador(parser)

·         Es de muy baja preferencia por parte de los programadores debido a su complejidad,  a no ser que usen herramientas externas.

·        
Es una tecnología sencilla y fácil de entender, además se aplica un razonamiento lógico a su estructura.

JSON

·         JSON (JavaScript Object Notation) es un formato bastante ligero empleado para el intercambio de datos, siendo un subconjunto de la notación para objetos empleada en JavaScript. La sencillez de esta formato le ha aventajado permitiendo una gran difusión de la tecnología como alternativa a XML.

·         Una de las grandes ventajas de JSON sobre XML como formato de intercambio de datos (según los expertos) se trata de que escribir un analizador sintáctico mediante JSON es mucho más sencillo que utilizando XML, además de procesarse más rápido que  el primero en cualquier navegador.

Ventajas:

·         JSON va reemplazando a XML poco a poco como medio preferido a la hora de intercambiar datos entre aplicativos de distintas plataformas. Los motivos por los que se argumenta que JSON es mejor son casi siempre los mismos:

·         JSON es más fácil de leer que XML.

·         JSON es más ligero (bytes) en las transmisiones (desde luego que no hay etiqueta de cierre, pero sí de apertura).

·         JSON se parsea más rápido.

Desventajas:

·         No aplica una característica que posee XML, Extensibilidad.

·         No hay consorcios que la garanticen, pero  si comunidades como Linux.

·         No soporta grandes cargas, solo datos comunes.

·         Para la seguridad requiere de mecanismos externos como expresiones regulares

Ejemplo Comparativo en XML y JSON

Regiones del Perú

                    XML

<?xml version="1.0" encoding="UTF-8" ?>  

<regiones>  

  <region id="0">Costa</ region >  

  < region id="1">Sierra</ region >  

  < region id="2">Selva</ region >  

</ regiones >  

                                   JSON

{"regiones":[  

    {" region ": { "@id": "0", "#text": "Costa" }}  

,  

    {" region ": { "@id": "1", "#text": "Sierra" }}  

,  

    {"region": { "@id": "2", "#text": "Selva" }}  

]}  

·         Si bien XML tiene mucho más soporte y herramientas de desarrollo JSON tiene suficientes: al menos una para cada lenguaje. En casos como Java o PHP tenemos varias implementaciones donde escoger. Con JavaScript el análisis del documento se realiza de forma nativa con la función eval(). Ninguno de los dos ofrece un método para representar grandes objetos binarios: normalmente información multimedia. JSON representa mejor la estructura de los datos y requiere menos codificación y procesamiento.

Message Broker: Arquitectura, Aplicacion, Propositos y Ventajas

Muchos patrones presentan formas de enrutar los mensajes al destino apropiado sin la aplicación de origen sea consciente del destino final del mensaje. La mayoría de los patrones se centró en los tipos específicos de lógica de encaminamiento. Sin embargo, en conjunto, estos patrones a resolver un problema mayor.

Un bróker de mensajería es un patrón arquitectónico para la validación, la transformación y el ruteo de mensajes. Es un mecanismo mediador de la comunicación entre aplicaciones, permitiendo minimizar el grado de conocimiento mutuo que estas aplicaciones necesitan tener, para poder intercambiar mensajes, implementando así efectivamente su desacoplamiento.

Proposito: 
recibir mensajes entrantes desde las aplicaciones y llevar a cabo determinadas acciones con ellas. 


Aplicacion:
Puede recibir mensajes de varios destinos, determinar el destino correcto y la ruta del mensaje en el canal correcto. Implementar el funcionamiento interno de la Message Broker usando los patrones de diseño.

El uso de un Message Broker central se refiere a veces como hub-and-spoke estilo arquitectónico, que parece ser un nombre descriptivo cuando se mira en el diagrama anterior.

Ejemplos:
Rutear mensajes a una o más destinaciones distintas
Transformar mensajes a una representación alternativa
Realizar una agregación de mensajes, descomponer mensajes en varios mensajes componentes, reenviándolos a sus respectivos destinos, para posteriormente recomponer las respuestas en un único mensaje que será remitido al usuario
Interactuar con un depósito externo para aumentar un mensaje o almacenarlo
Invocar un servicio Web para consultar datos
Responder a eventos o errores
Proveer un ruteo de los mensajes basado en su contenido o en sus tópicos empleando el modelo de publica/suscribe


Ventajas:

• Ruta un mensaje a varios destinos, usando las reglas que actúan sobre el contenido de uno o más de los campos en el mensaje o el mensaje de encabezado.
• Transformar un mensaje, por lo que las aplicaciones que utilizan diferentes formatos pueden intercambiar mensajes en sus propios formatos.
• Guardar un mensaje o una parte de un mensaje, a una base de datos.
• Recuperar un mensaje, o parte de un mensaje, a partir de una base de datos.
• Modificar el contenido de un mensaje, por ejemplo, mediante la adición de los datos extraídos de una base de datos.
• Publicar un mensaje para que esté disponible para otras aplicaciones. Otras aplicaciones pueden elegir recibir las publicaciones que se refieren a temas específicos, o que tienen un contenido específico, o ambos.
• Crear nombres estructurados tema, las funciones de control de acceso basadas en temas, las suscripciones basadas en el contenido, y los puntos de suscripción.

Tips de ayuda para desarrollo de RESTService

Consideraciones a tomar en cuenta al momento de desarrollar un servicio REST:

Vamos hacer un ejemplo que se encarga una entida CITA, que cumplirá con todos los mantenimientos, para ello creamos un wcf de Nombre: CitaService; por default se generan el archivo CitaService.svc y el ICitaService.cs

Primer caso, posicionarse sobre el archivo wcf (CitaService.svc) y vamos a indicarle el modelo de servicio que va a tener nuestro WCF configurándolo de la siguiente manera

Al momento de crear el servicio, darle click derecho (1) y seleccionar la opción Ver marcado (2).

Cuando se abra el editor, se tiene que agregar el siguiente código(3):

Factory= "System.ServiceModel.Activation.WebServiceHostFactory"

(*) WebServiceHost es un tipo derivado de ServiceHost, lo que simplifica los escenarios de auto alojamiento de extremos RESTful.

Esta optimización evita el código repetitivo de agregar WebHttpBinding y WebHttpBehavior manualmente. La clase WebServiceHost automáticamente crea el extremo final y configura con el WebHttpBinding y WebHttpBehavior.

Controlador de excepciones:

En la capa de servicios, declara el webexception que va a utilizar como regla de negocio.

El código seria el siguiente

Apoyado en una clase personalizada ERROR, para poder obtener el error serializado y desde la capa de presentación, en la clase controladora específicamente, poder capturar y mostrar lo que mandamos:

throw new WebFaultException<[ClaseError]>(

   new [ClaseError] ()

   {

    IsValid = false,

    txtMensaje = "Mensaje de Error

    PkReference = 0

   },                        HttpStatusCode.InternalServerError);

Luego, en la vista controladora ponemos el método en un try catch(webexception) y hacemos lo siguiente:

catch (WebException wex)

            {

                if (wex.Response != null)

                {

                    using (var errorResponse = (HttpWebResponse)wex.Response)

                    {

                        using (var reader = new StreamReader(errorResponse.GetResponseStream()))

                        {

                            MensajeRetornoWS error = JSONDeserialize<MensajeRetornoWS>(reader.ReadToEnd());

                            //string error = reader.ReadToEnd();

                            ModelState.AddModelError("", error.txtMensaje);

                        }

                    }

                }

            }