jueves, 8 de agosto de 2013

WCF

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.

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. 


WebSphere MQ

Un sistema flexible para el transporte eficiente de mensajes y datos

WebSphere MQ puede transportar cualquier tipo de datos como mensajes, abriendo la posibilidad a las empresas de crear arquitecturas flexibles y reutilizables, como entornos de arquitectura orientada a servicios (SOA). Funciona con una amplia gama de plataformas informáticas, aplicaciones, servicios web y protocolos de comunicación para conseguir una entrega de mensajes altamente segura. WebSphere MQ proporciona una capa de comunicaciones para la visibilidad y el control del flujo de mensajes y datos dentro y fuera de su organización.

WebSphere MQ proporciona:
·       Integración de mensajería versátil desde mainframe a móvil, que ofrece una única base de mensajería sólida para entornos heterogéneos dinámicos.
·    Entrega de mensajes con características altamente seguras, que generan resultados auditables.
·        Transporte de mensajes de alto rendimiento, para entregar los datos con mayor velocidad y fiabilidad.
·         Características administrativas que simplifican la gestión de mensajería y reducen el tiempo dedicado a herramientas complejas.
·         Herramientas de desarrollo de estándares abiertos que dan soporte a la extensibilidad y al crecimiento del negocio.

Integración de mensajería versátil desde mainframe a móvil
·         Utiliza un único middleware de mensajería compartido por toda la empresa, que abarca sistemas mainframe, dispositivos móviles y cloud computing.
·        Se integra con un conjunto de aplicaciones heterogéneas con soporte a más de 80 configuraciones de plataforma, incluidos entornos nativos IBM z/OS, IBM CICS, IBM IMS, IBM DB2, Microsoft .NET y Java 2 Platform Enterprise Edition (J2EE).
·      Envía y recibe una amplia variedad de contenido proveniente de pequeños mensajes de transacciones o grandes archivos de vídeo.
·  Trabaja con mandatos independientes del lenguaje que no requieren conocimientos de programación de comunicaciones.
·         Utiliza la misma infraestructura de integración para trabajar con mensajes, archivos, servicios web, dispositivos móviles y dispositivos físicos remotos como sensores.

Entrega de mensajes con características altamente seguras
·    Firma de mensajes de forma digital para entregar mensajes a prueba de manipulaciones.
·         Presenta información de forma sincrónica o asíncrona.
·       Transporta mensajes como una única transacción completa para realizar el intercambio de datos de solo una vez.
·      Da soporte a los protocolos SSL (secure sockets layer) y TLS (transport layer security) para la autenticación, la comprobación de la integridad y el cifrado de datos.
·   Refuerza el cumplimiento con políticas de seguridad mediante el uso de cifrado completo, configuraciones seguras e informes de auditoría.

Transporte de mensajes de alto rendimiento
·   Utiliza modos de operación de multidifusión, transferencia de archivos, publicación y suscripción y punto a punto.
·         Aprovecha funcionalidades de agrupación en clúster que distribuyen cargas de trabajo de mensajería de forma dinámica.
·    Habilita aplicaciones con distintas características de rendimiento para operar de forma independiente, evitando cuellos de botella en el mismo clúster de WebSphere MQ.
·   Entrega mensajes desconectados de la actividad de las aplicaciones, de manera que las aplicaciones ya no tienen que comprobar el estado de entrega de los mensajes.
·         Envía y recibe mensajes incluso cuando las aplicaciones fallan o las redes caen.

Características administrativas
·      Integra las funcionalidades de IBM WebSphere MQ File Transfer Edition e IBM WebSphere Advanced Message Security en el servidor WebSphere MQ.
·         Obtiene una única vista de panel de instrumentos del tráfico de mensajería de la empresa para obtener información de la infraestructura y las operaciones de mensajería de toda la empresa de forma rápida.
·   Despliega WebSphere MQ en entornos distribuidos mediante un único proceso de instalación.
·         Define la configuración para entregar una calidad de servicio menos sólida, que incremente el rendimiento.
·       Simplifica las tareas de integración de aplicaciones mediante una interfaz de desarrollo de aplicaciones con muchas funciones y de fácil uso.

Herramientas de desarrollo de estándares abiertos
·      Permite el desarrollo  y despliegue nuevas aplicaciones de forma más rápida sin escribir código de comunicaciones específico de las aplicaciones.
·  Permite habilitar dispositivos como smartphones, sensores remotos, medidores inteligentes y etiquetas de identificación de frecuencia de radio (RFID), con un protocolo dedicado, ligero.
·         Permite configurar y gestionar aspectos individuales de su implementación de WebSphere MQ mediante WebSphere MQ Explorer.
·       Proporciona una base de mensajería para la arquitectura de bus de servicios de empresa (ESB).
·         Permite utilizar el estándar de programación de aplicaciones de interfaz de cola de mensajes (MQI) y Java Message Service (JMS).



Web Service - REST


Los web services permiten a los programas escritos en diferentes lenguajes y que se ejecutan sobre diferentes plataformas comunicarse entre ellos siguiendo estándares.

Hay casos en los que lo que se quiere resolver es el acceso a recursos provistos por otras aplicaciones haciendo especial énfasis en la optimización de tráfico HTTP (es importante cuando los clientes son dispositivos móviles por ejemplo). En ese caso entra REST como estilo de diseño de servicios web, que garantiza la interoperablidad bajo un paradigma de simplicidad y “ahorro de recursos”.

Básicamente el objetivo es exponer datos de una aplicación o lo que vamos a llamar “recursos” o entidades, en la web, con una salida con un formato estándar (XML, Json), para que sea interpretable por un programa que ejecute sobre cualquier plataforma o framework, e incluso sobre cualquier cliente HTTP.


Qué es REST?
Representational State Transfer o REST es un estilo de arquitectura de software, para ambientes distribuidos. No se trata de un protocolo.

REST es un modelo orientado a recursos. Básicamente significa que cada URL es la representación de un objeto - o recurso. Cada recurso se representa con una URI. Se puede hacer un GET de ese recurso usando el método GET de HTTP, modificar el mismo con el método HTTP PUT, crear una nueva representación con POST y borrar con el método DELETE (es decir que existe una interfaz uniforme para acceder a los recursos). Por su parte, cada recurso tiene n representaciones posibles, puede ser XML, Json.

Rest marca una serie de reglas o restricciones. Los seguidores de REST afirman que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave, justamente en base a estos fundamentos es que se crearon las principios o constraints que debe cumplir una arquitectura REST.


Web Services vs REST, Ventajas y desventajas.
Una de las dudas típicas a la hora de integrar dos subsistemas heterogéneos es si usar web services o REST. Evidentemente, si los dos subsistemas estuvieran desarrollados con el mismo lenguaje de programación, la integración obvia sería aprovechar lo que nos facilitase ese lenguaje, como puede ser RMI o .NET Remoting por citar sólo dos ejemplos.

Resulta que tenemos que integrar dos módulos que están desarrollados en dos entornos diferentes; o a lo mejor el requisito es que se comuniquen por internet, aunque compartan lenguaje de programación. En estos casos, hay que estudiar si es mejor realizar esta integración mediante web services o con llamadas REST. 

Ventajas y desventajas de hacerlo de una manera o de otra.
Los web services tienen como principal ventaja que cualquier entorno de desarrollo (Eclipse, Netbeans, Visual Studio, etc), dispone de herramientas para generar un cliente a partir de un WSDL o exponer los métodos de una clase como servicios web. No obstante, es muy recomendable hacer una prueba de concepto antes de decidirse porque si el cliente y el servidor de servicios web no están basados en las mismas librerías, se puede tener problemas de compatibilidad.

Como ejemplo, si tenemos un cliente .NET en una PDA y un servicio web en J2EE (que use las librerías Axis, por ejemplo), es posible que si tenemos un dato de tipo timestamp, el valor sea diferente en la parte Java y en la parte .NET

Pero quizá lo más fácil de detectar sea la compatibilidad a la hora de encapsular ficheros dentro de un web service: ya que hay varios mecanismos (SwA - SOAP with Attachments, DIME o MTOM), es posible que si las librerías son distintas en cliente y servidor, no exista una manera compatible de transferir un fichero, teniendo que recurrir a soluciones de contingencia como montar un servicio intermedio (desarrollado con el mismo lenguaje de programación y librerías que el servidor de servicios web) que reciba el fichero como parte de un form-multipart y que luego lo encapsule de forma compatible para el destinatario final (el servicio web).

Por otro lado, los web services proporcionan otras ventajas como el tipado fuerte (en el WSDL está definido de qué tipo son las variables, incluso en el caso de objetos complejos) o los estándares WS-*: WS-I BasicProfile, WS-Security, WS-Addressing, WS-RM o WS-Policy. De usarla es necesario asegurarse de la compatibilidad entre librerías si son distintas en cliente y servidor.

En el caso de utilizar REST, perdemos lo del tipado fuerte y los mecanismos estándares WS-* mencionados anteriormente, pero ganamos universalidad: muchos dispositivos programables son capaces de hacer peticiones HTTP. Eso significa que podemos integrar una aplicación desarrollada en J2ME con nuestro servidor sin necesidad de que soporte la JSR para web services.

Hasta hace poco, no había manera de generar clientes de manera automática para hacer invocaciones REST. Afortunadamente, existe la librería Jersey del proyecto GlassFish, que permite desarrollar tanto servicios de servidor basados en REST (simplemente con etiquetas en los lugares oportunos) como clientes que los consuman de manera automática. Esto es debido a que los servicios generados con esta librería despliegan un descriptor WADL muy similar al WSDL de los web services tradicionales, por lo que luego se puede partir de ahí para generar los clientes correspondientes.

Para subir o bajar ficheros si optamos por esta modalidad, basta con utilizar comunicaciones HTTP estándar como POST (con un form-multipart, por ejemplo) o GET (una simple petición a la URL de un fichero); ambos mecanismos son sencillos de implementar y hay muchos ejemplos en internet en casi cualquier lenguaje de programación.


Para implementar REST, debemos seguir los 4 principios básicos:

• utiliza los métodos HTTP de manera explícita: Una de las características claves de los servicios web REST es el uso explícito de los métodos HTTP, siguiendo el protocolo definido por RFC 2616.
Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP. De acuerdo a esta asociación:

    o   se usa POST para crear un recurso en el servidor
    o   se usa GET para obtener un recurso
    o   se usa PUT para cambiar el estado de un recurso o actualizarlo
    o   se usa DELETE para eliminar un recurso

• No mantiene estado: El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envíen peticiones completas e independientes; es decir, se deben enviar peticiones que incluyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan re direccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.

• Expone URIs con forma de directorios: Las URI de los servicios web REST deben ser intuitivas, hasta el punto de que sea fácil adivinarlas.

• transfiere XML, JavaScript Object Notation (JSON), o ambos: La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas.



Sistemas Distribuidos, ¿que es?, ¿para que?

Definición

(1) conjunto de computadores
(2) interconectados igual que un sistema en red
(3) que comparten un estado
(4) ofreciendo una visión de sistema único (SSI) igual que un sistema centralizado

Objetivo principal: compartir recursos / visión de sistema único

Ventajas respecto a un sistema centralizado
  • bajo coste: puede estar compuesto de PCs estándar
  • escalabilidad: consecuencia de su modularidad
  • flexibilidad: re utilización de máquinas “viejas”
  • disponibilidad: mediante replicación de recursos
  • ofrecen la posibilidad de paralelismo
  • permiten acceder a recursos remotos

Ventajas respecto a un sistema en red
  • uso más eficiente de los recursos (migración)
  • acceso transparente a los recursos

Desventajas respecto a un sistema centralizado
  • un sistema centralizado del mismo coste es más eficiente que cada uno de los componentes del sistema distribuido
  • si la distribución de recursos es inadecuada algunos recursos pueden estar desbordados mientras otros están libres
  • mantener la consistencia puede ser muy “costoso”
  • la red de interconexión es una fuente de problemas
  • la gestión de la seguridad es más compleja

Propiedades deseables
1.      Transparencia
2.      Escalabilidad
3.      Fiabilidad y tolerancia a fallos
4.      Consistencia

Transparencia
  • de identificación: los espacios de nombres de los recursos son independientes de la topología de la red y de la propia distribución de los recursos
  • de ubicación: los recursos pueden migrar entre nodos de replicación
  • de paralelismo: sin que la aplicación lo especifique y sin consecuencias negativas sobre la ejecución
  • de compartición: accesos simultáneos a recursos
  • de rendimiento: es necesario buscar soluciones de compromiso cuando la degradación del rendimiento hace impracticable implementar alguna de las propiedades

Escalabilidad
Capacidad de crecer sin disminuir su rendimiento
      ·        Basada en la modularidad
Espacios de nombres
      ·        identifican objetos de diferente naturaleza: ficheros, procesos, variables,     direcciones de memoria (DSM)…
      ·        espacios lineales (memoria): 32 bits insuficientes
      ·       en general los espacios de nombres son jerárquicos y por lo  tanto             escalables por naturaleza
Mantenimiento del rendimiento: replicación
      ·        mirroring, caching
      ·        obtener transparencia de replicación es complejo/costoso

Fiabilidad y tolerancia a fallos “Capacidad para realizar correctamente y en todo momento las funciones para las que se ha diseñado”

Disponibilidad
      ·        Fracción de tiempo que el sistema está operativo (%)
o   parámetros: MTBF (Mean Time Between Failures), MTTR…
o   componentes de alta calidad vs replicación (más barata)
Tolerancia a fallos
      ·      Capacidad para seguir operando correctamente ante el fallo de alguno de sus componentes
o   Replicación (pasiva, activa)

Consistencia
Problemas relacionados con la replicación
      ·         la red de interconexión es una nueva fuente de fallos
      ·         la seguridad del sistema es más vulnerable
      ·         la gestión del estado global es más compleja/costosa

Problemas para mantener la consistencia
      ·         distribución física: varias copias, cada una con su estado
      ·         errores y/o retardos en las comunicaciones
      ·         ausencia de reloj global: ¿cómo ordenar eventos?
Técnicas: transacciones, comunicación a grupos
      ·         Para un rendimiento aceptable: relajar consistencia

Aplicaciones distribuidas
      ·        Aplicaciones paralelas: muchas tareas a la vez
o   objetivo principal: disminuir el tiempo de ejecución
      ·        Aplicaciones distribuidas (motivaciones):
o   alto rendimiento: cluster computing
o   tolerancia a fallos: replicación, transacciones
o   sistemas informáticos bancarios
o   la gestión de la consistencia es crítica
      ·        Alta disponibilidad: caching, mirroring
o   bajo tiempo de respuesta: WWW, sistemas de ficheros…
o   a consistencia es importante, pero no crítica
      ·        Movilidad, ubicuidad: aplicaciones AmI