Enterprise Integration Patterns

Actualmente los sistemas de una empresa son producto de sistemas hechos a la medida, componentes comprados de terceras partes, o forma parte de sistemas legados. Desde la perspectiva de un consumidor el pago de un producto o la realización de una operación parece ser una simple transacción, pero en la práctica y al interior de la organización pueden interactuar diferentes aplicaciones, que en muchas ocasiones se encuentran en diferentes plataformas, diferentes lenguajes, cuentan con fuentes de información en diferentes formatos, etc. De aspectos como estos, surge la necesidad de integrar para compartir sus recursos (datos, información, componentes, modulos) de forma eficiente, confiable y segura.

• Al enfrentar este proceso, se debe partir del hecho que muchas aplicaciones corren en diferentes plataformas y en diferentes ubicaciones, y utilizar software de EAI (Enterprise Application Integration) solo cubre una parte de las complejidades de integración. Por tal motivo se debe:
• Establecer comunicación entre grupos IT y unidades de negocio.
• La solución de integración tiene gran alcance y debe cubrir primero los las funciones de negocio más importantes y evitar cualquier cambio de comportamiento negativo.
• Ofrecer “endpoints” de comunicación para sistemas legados, que por sus idiosincrasias o por políticas no pueden ser conectadas de manera adecuada.
• Tener en cuenta estándares de integración como XML, XLS o Servicios Web. Siendo estos últimos los que más ofrecen puntos de extensión y nuevas interpretaciones de los estándares.
• Hay diferentes semánticas entre sistemas, estas diferencias implican grandes decisiones técnicas y de negocio.
• Desarrollar habilidades no solo para implementar soluciones EAI, sino también para manejarlas.

Acoplamiento
Con el fin de obtener una comunicación de bajo acoplamiento entre los diferentes sistemas a integrar se deben superar los siguientes obstáculos y dependencias con el fin de poder concebir una solución que sea tolerante a cambios:

• Plataforma Tecnológica
• Localización
• Time de disponibilidad
• Formato de Datos

Estilos de integración

En este aspecto, destacamos los siguientes criterios a ser aplicados:

• Acoplamiento de Integración: Las aplicaciones integradas debería minimizar sus dependencias para evolucionar por aparte sin causarle daño a las demás. La interfaz de integración debería contener información suficiente para la implementación.
• Simplicidad de Integración: El código que se utiliza para la integración debería ser mínimo, dando el menor impacto posible a la aplicación y ofreciendo la mejor integración en la empresa.
• Tecnología de Integración: Herramientas especializadas en integración pueden ser costosas, y sin ayuda del vendedor pueden incrementar el costo de tiempo y entendimiento entre los desarrolladores sobre estas herramientas.
• Formato de Datos: Las aplicaciones integradas deben acordar que tipos de datos van a intercambiar, cómo pueden evolucionar estos datos y afectar estas aplicaciones.
• Duración de Datos: Acuerdos para la duración de un dato y para que sea consumido apenas sea publicado.
• Datos o Funcionalidad: Las aplicaciones integradas pueden querer no solamente compartir datos sino también funcionalidades.
• Asincronicidad: las aplicaciones integradas pueden no querer que siempre sus invocaciones tengan respuesta inmediata.

File Transfer: Múltiples aplicaciones construidas independientemente con diferentes lenguajes y plataformas y entre ellas necesitan consumir información (En el caso de VehiAlpes la aplicación de inventarios, de gestión de clientes, garantías, etc.). Estas aplicaciones deciden en qué formato de archivo comparten la información (se podría estandarizar en XML el cual es el mas usado). Como la construcción de estos archivos requiere de un esfuerzo, es necesario configurar una periodicidad para su construcción, así como la frecuencia para eliminarlos.

Shared Database: Necesidad de tener la última versión de los datos, rápida y consistentemente. Se debe tener una base de datos centralizada para que las aplicaciones la puedan acceder cuando sea que la necesiten. Las aplicaciones no se preocupan por el formato de los archivos puesto todas conocen SQL a través de diferentes herramientas (clientes SQL). Sus desventajas:

• Necesidades reunidas de las aplicaciones, haciendo que se origine un esquema unificado difícil para trabajar entre los programadores.
• Conflictos humanos debido a las políticas establecidas en el esquema.
• Problemas al no querer trabajar con paquetes externos, sino con sus propios esquemas.
• Cuellos de botella y bloqueos debido a las modificaciones hechas por las múltiples aplicaciones.

Remote Procedure Invocation: Compartir datos a menudo no es suficiente; también se requiere compartir funcionalidad. Los datos se pueden enviar utilizando encapsulamiento al llamar a una función, haciéndolo un mecanismo poderoso. Las aplicaciones son susceptibles a los cambios continuos sobre una base de datos. Se requiere crear mecanismos con encapsulamiento de datos y proveer una o más interfaces que permita interactuar a las aplicaciones, manteniendo los datos de cada una consistentes (CORBA, Java RMI, COM, .NET Remoting, etc; siendo la moda actual Web Services a través de SOAP y XML).

Messaging: Los llamados remotos de “Remote Procedure Invocation” pueden ser lentos y pueden fallar. Existen organizaciones que no les gusta compartir los detalles de su estructura, inclusive si sus detalles son sus interfaces.
Messaging transfiere paquetes de datos de forma confiable, frecuente, inmediata y asíncronamente, utilizando formatos de datos personalizados. La desincronización es importante porque se pueden enviar datos sin estar listos para recibirlos aún. El desacoplamiento de los formatos de datos hace que múltiples sistemas puedan recibir mensajes.

¿Que es REST?

Lo primero es aclarar que REST no es una tecnología, ni siquiera una arquitectura, sino una familia de arquitecturas. Cualquier arquitectura de servicios distribuidos que cumpla con una serie de requisitos se puede considerar como una arquitectura REST. Estos requisitos o propiedades son los siguientes:

• No se publican servicios RPC. En arquitecturas REST, los servicios no publican un conjunto arbitrario de métodos u operaciones. Por ejemplo, en REST no podemos publicar una interfaz “IGestionEmpleados” con métodos “addEmpleado”, “removeEmpleado” o “buscarEmpleadosEnEdadDeJubilacion”. 
• En REST lo que se publica son recursos. Un recurso se puede considerar como una entidad que representa un concepto de negocio que puede ser accedido públicamente. Un ejemplo de recurso sería simplemente “EmpleadosDeLaEmpresa” y otro podría ser “Empleado número 33″ 
• Si no podemos definir operaciones arbitrarias sobre el recurso, ¿cómo podemos operar con él? En REST todos los recursos comparten una interfaz única y constante. Todos los recursos tienen las mismas operaciones. Las operaciones nos permiten manipular el estado público del recurso. En un sistema REST típico se definen cuatro operaciones. 
• CREATE. En esta operación el cliente manda al servidor una petición para crear un nuevo recurso. Opcionalmente el cliente puede mandar una representación del estado inicial de este recurso. El servidor responde con el identificador global del nuevo recurso. 
• DELETE. En esta operación el cliente elimina un recurso del servidor. El cliente necesita saber el identificador del recurso. 
• READ. Con esta operación el cliente puede leer una representación del estado de un recurso, identificado con su identificador global. El cliente puede especificar que tipos de representaciones entiende. Aquí lo que ocurre realmente es que se copia el estado del recurso en el servidor y se pega en el cliente. Ambas copias del estado no se mantiene sincronizadas. El servidor puede cambiar el estado real del recurso y el cliente, de forma independiente, puede modificar su copia local del estado del recurso. 
• UPDATE. Como el servidor y el cliente tienen una copia diferente del estado, el cliente puede usar esta operación para sobrescribir o grabar su copia del estado en el servidor. De esta manera se puede actualizar el estado del recurso con las modificaciones hechas en el cliente. 
• La implementación del servicio es libre de prohibir alguno de estos métodos para un recurso en concreto. También debe definir el modelo de datos que se va a publicar y que representaciones soporta. Lo que no puede hacer es inventarse operaciones de forma arbitraria. Las operaciones son siempre las mismas. 
• Los distintos recursos se pueden interrelacionar y referenciar entre si mediante sus identificadores globales.

Una confusión típica es pensar que REST no es más que un CRUD llevado a la web, ¿no será mi BBDD relacional un sistema REST? No exactamente. Es parecido, pero existen algunas diferencias sutiles e importantes entre un CRUD simple o una BBDD con una arquitectura REST:

• Al contrario que en un CRUD típico, como una BBDD, el servidor puede soportar muchas representaciones de un mismo recurso: xml, pdf, png, gif, excel, html, json, texto, etc.. Hay pocas BBDD que hagan esto. 
• No penséis que las operaciones REST se limitan a hacer CRUD tradicional, no se trata solo de persistir nuestros cambios. Cuando hacemos un UPDATE, nuestra implementación del recurso además de grabar el estado en soporte persistente, debe hacer otras cosas, como validaciones de negocio o actualizaciones en otros recursos para mantener la consistencia global del sistema. Esto sí que se parece a una BBDD con triggers e integridad referencial, pero no es CRUD en el sentido de que no nos limitamos a grabar y ya está. Una DAO es CRUD, un recurso REST no (excepto en los casos más simples). 
• Los recursos mantiene interrelaciones entre si. La topología de estas interrelaciones es compleja, puede ser un grafo arbitrario, con ciclos, o un simple árbol. Es más, los recursos de nuestro sistema se pueden interrelacionar con recursos en sistemas de terceras partes, ya que el identificador es único y global.

Pues resulta que REST es un enfoque maduro con un claro ejemplo existente en la actualidad: la world wide web. Veamos si la web tiene propiedades REST:

• La web está compuesta de recursos, cada página web puede considerarse un recurso. 
• Cada recurso tiene un identificador único global, que es su URI (o URL para los antiguos o IRI para los más modernos). Usando una URL podemos llegar a cualquier recurso en la web. 
• Dada una URI, y mediante el protocolo HTTP, podemos operar sobre estos recursos. La operación a realizar se especifica mediante el verbo HTTP. Mediante cabeceras especiales como Accept o Content-Type se puede especificar que representaciones entienden el servidor y el cliente y que representación se usa en un mensaje concreto para transporta el estado del recurso. 
• El verbo GET hace la operación READ. 
• El verbo DELETE hace la operación DELETE. 
• El verbo PUT se usa normalmente para hacer UPDATE 
• El verbo POST se usa normalmente para hacer CREATE. 
• Las representaciones a usar se especifican mediante los llamados tipos mime. La mayoría de los tipos mime son estándares, como xml o json. El usar tipos mime estándar facilita la interoperabilidad. 
• La aplicación cliente típica de la web es el navegador. Los navegadores se dedican a hacer GETs sobre URIs para obtener representaciones de las distintas páginas web. En el caso habitual cada página sólo admite una representación, típicamente HTML o PDF o texto plano o imágenes. Pero eso no significa que una misma URI no pudiera soportar distintas representaciones.

Lo interesante de todo esto es que la web es un ejemplo perfecto de servicios distribuidos a nivel global totalmente interoperable (o casi). La web, y el protocolo HTTP es una arquitectura REST. La web son servicios REST que en general sólo soportan HTML. Casi cualquier página HTML es interoperable con casi cualquier navegador, y casi cualquier página HTML puede interoperar (referenciar) con otra página HTML construida por un tercero. Es sorprendente que con este claro ejemplo, presente en nuestro día a día, llegada la hora de pensar en como hacer servicios web, no se viera lo que tenemos delante de la cara, sino que se inventara algo como SOAP y WSDL.

WCF

En mi trabajo se empezo a usar mucho el concepto WCF, sin embargo no entendia a que se queria referir, solo sabia que estaba enfocado a servicios. Yo he trabajado con servicios por casi un año, ya que era necesidad de mi empresa, pero cuando empezaron a hablar de este nuevo concepto me dio curiosidad, sin embargo no pude dedicarle mucho tiempo por mi trabajo y estudios, y este autoaprendizate nunca se daba. Sin embargo al llegar al curso de Sistema Distribuidos en la universidad UPC, nos dijeron que tocariamos este tema, al fin he logrado entender este concepto que paso a explicar.

Windows Communication Foundation (WCF) es un marco de trabajo para la creación de aplicaciones orientadas a servicios. Con WCF, es posible enviar datos como mensajes asincrónicos de un extremo de servicio a otro. Un extremo de servicio puede formar parte de un servicio disponible continuamente hospedado por IIS, o puede ser un servicio hospedado en una aplicación. Un extremo puede ser un cliente de un servicio que solicita datos de un extremo de servicio. Los mensajes pueden ser tan simples como un carácter o una palabra que se envía como XML, o tan complejos como una secuencia de datos binarios. A continuación se indican unos cuantos escenarios de ejemplo:

• Un servicio seguro para procesar transacciones comerciales.
• Un servicio que proporciona datos actualizados a otras personas, como un informe sobre tráfico u otro servicio de supervisión.
• Un servicio de chat que permite a dos personas comunicarse o intercambiar datos en tiempo real.
• Una aplicación de panel que sondea los datos de uno o varios servicios y los muestra en una presentación lógica.
• Exponer un flujo de trabajo implementado utilizando Windows Workflow Foundation como un servicio WCF.
• Una aplicación de Silverlight para sondear un servicio en busca de las fuentes de datos más recientes.

Si bien era posible crear tales aplicaciones antes de que existiera WCF, con WCF el desarrollo de extremos resulta más sencillo que nunca. En resumen, WCF se ha diseñado para ofrecer un enfoque manejable para la creación de servicios web y clientes de servicios web.

Características de WCF

---

WCF incluye el siguiente conjunto de características: 

• Orientación a servicios
  Como consecuencia del uso de los estándares de WS, WCF le permite crear aplicaciones orientadas a servicios. SOA, la arquitectura orientada a servicios es el uso de servicios web para enviar y recibir datos. Los servicios tienen la ventaja general de estar débilmente acoplados entre una aplicación y otra en lugar de incluidos en el código. Una relación de acoplamiento débil implica que cualquier cliente creado en cualquier plataforma puede conectar con cualquier servicio siempre y cuando se cumplan los contratos esenciales.
• Interoperabilidad
  WCF implementa los estándares del sector modernos para la interoperabilidad de servicios web.
• Varios modelos de mensajes
  Los mensajes se intercambian mediante uno de los distintos modelos. El más común es el de solicitud/respuesta, en que un extremo solicita datos de otro extremo. y el otro extremo responde. Existen otros modelos, como un mensaje unidireccional, en que un único extremo envía un mensaje sin esperar ninguna respuesta. Un modelo más complejo es el modelo de intercambio dúplex donde dos extremos establecen una conexión y envían datos hacia delante y hacia atrás, similar a un programa de mensajería instantánea.
• Metadatos de servicios
  WCF admite la publicación de metadatos de servicios utilizando los formatos especificados en los estándares de la industria, como WSDL, Esquemas XML y WS-Policy. Estos metadatos pueden utilizarse para generar y configurar automáticamente clientes para el acceso a los servicios de WCF. Los metadatos se pueden publicar sobre HTTP y HTTPS, o utilizando el estándar Intercambio de metadatos de servicios web.
• Contratos de datos
  Dado que WCF se basa en .NET Framework, también incluye métodos con código sencillo para proporcionar los contratos que desea aplicar. Uno de los tipos de contrato universales es el contrato de datos. Básicamente, mientras se escribe el código del servicio usando Visual C# o Visual Basic, la forma más sencilla de controlar los datos consiste en crear clases que representan una entidad de datos con propiedades que pertenecen a la misma. WCF incluye un completo sistema para trabajar con datos de esta manera fácil. Cuando se han creado las clases que representan los datos, el servicio genera automáticamente los metadatos que permiten a los clientes ajustarse a los tipos de datos que se han diseñado.
• Seguridad
  Es posible cifrar los mensajes para proteger la privacidad, así como obligar a los usuarios a que se autentiquen antes de permitirles recibir mensajes. La seguridad puede implementarse utilizando estándares conocidos como SSL o WS-SecureConversation.
• Varios transportes y codificaciones
  Los mensajes pueden enviarse con cualquiera de los protocolos y codificaciones integrados. La combinación más frecuente de protocolo y codificación consiste en enviar mensajes SOAP codificados de texto utilizando el Protocolo de transferencia de hipertexto (HTTP) usado en World Wide Web. WCF también le permite enviar mensajes sobre TCP, canalizaciones con nombre o MSMQ. Estos mensajes pueden codificarse como texto o utilizando un formato binario optimizado. Los datos binarios pueden enviarse de manera eficaz utilizando el estándar MTOM. Si ninguno de los transportes o codificaciones proporcionados satisface sus necesidades, puede crear uno personalizado. 
• Mensajes confiables y en cola
  WCF admite intercambio de mensajes confiable usando sesiones confiables implementadas sobre mensajería WS-Reliable y mediante MSMQ.
• Mensajes duraderos
  Un mensaje duradero es aquel que nunca se pierde debido a una interrupción de la comunicación. Los mensajes que forman parte de un modelo de mensajes duraderos siempre se guardan en una base de datos. Si se produce una interrupción, la base de datos le permite reanudar el intercambio de mensajes cuando se restablezca la conexión. También puede crear un mensaje duradero utilizando Windows Workflow Foundation (WF). 
• Transacciones
  WCF también admite las transacciones que usan uno de los tres modelos de transacción: las transacciones WS-Atomic, las API del espacio de nombres System.Transactions y Coordinador de transacciones distribuidas de Microsoft.
• Compatibilidad con AJAX y REST
  REST es un ejemplo de una tecnología de la Web 2.0 en evolución. WCF se puede configurar para procesar datos XML “sin formato” que no se ajustan en un sobre SOAP. WCF también se puede extender para admitir formatos XML concretos, como ATOM (un estándar popular de RSS), e incluso formatos no XML, como notación de objetos JavaScript (JSON).
• Extensibilidad
  La arquitectura de WCF tiene varios puntos de extensibilidad. Si se necesita una función adicional, existen una serie de puntos de entrada que le permiten personalizar el comportamiento de un servicio.

Integración de WCF con otras tecnologías de Microsoft

---

WCF es una plataforma flexible. Debido a esta flexibilidad extrema, WCF también se usa en varios otros productos Microsoft. Si comprende los fundamentos de WCF, tendrá una ventaja inmediata si también utiliza cualquiera de estos productos.

La primera tecnología en adaptarse a WCF fue Windows Workflow Foundation (WF). Los flujos de trabajo simplifican el desarrollo de aplicaciones encapsulando los pasos del flujo de trabajo como “actividades”. En la primera versión de Windows Workflow Foundation, un desarrollador tenía que crear un host para el flujo de trabajo. La versión siguiente de Windows Workflow Foundation se integró con WCF. Esto permitió hospedar cualquier flujo de trabajo fácilmente en un servicio de WCF; puede hacer esto si elige automáticamente el tipo de proyecto WF/WCF en Visual Studio 2012.

Microsoft BizTalk Server R2 también utiliza WCF como tecnología de comunicaciones. BizTalk está diseñado para recibir y transformar datos de un formato normalizado en otro. Los mensajes deben entregarse en su cuadro de mensajes central, donde es posible transformar el mensaje utilizando una asignación estricta o mediante una de las características de BizTalk, como su motor de flujo de trabajo. BizTalk ahora puede utilizar el adaptador de línea de negocio (LOB, Line Of Business) de WCF para entregar mensajes en el cuadro de mensajes.

Microsoft Silverlight es una plataforma para la creación de sofisticadas aplicaciones web interoperables que permiten a los desarrolladores crear sitios Web con uso intensivo de contenidos multimedia (como la transmisión de vídeo por secuencias). A partir de la versión 2, Silverlight incorpora WCF como tecnología de comunicaciones para conectar las aplicaciones Silverlight con los extremos de WCF.

Microsoft .NET Services es una iniciativa de computación en nube (cloud computing) que utiliza WCF para la creación de aplicaciones habilitadas para Internet. Utilice .NET Services para crear servicios WCF que funcionan a través de límites de confianza.

El servidor de aplicaciones características de hospedaje de Windows Server AppFabric se ha diseñado específicamente para implementar y administrar aplicaciones que utilizan WCF para las comunicaciones. características de hospedaje incluye sofisticadas opciones de configuración y herramientas diseñadas específicamente para las aplicaciones habilitadas para WCF.