MSMQ con C#

Primera Parte

Segunda Parte

WEB SERVIE CON .NET

Dentro de mi backup encontr este video creado por mi Profesor Giovani Bamaberen, donde explica claramente como crear un web services con SOAP.

Protocolo REST

El protocolo REST

REST son las siglas de Representation State Transfer. Los servicios web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT, POST y DELETE). Por tanto, este estilo se centra más en interactuar con recursos con estado que con mensajes y operaciones.

Como ya se mencionó, el término fue introducido en la tesis doctoral de Roy Fielding en el año 2000.

Cabe destacar que REST no es un estándar, pero está basado en estándares como los siguientes:

• HTTP

• URL

• Representación de los recursos: XML/HTML/GIF/JPEG etc.

• Tipos MIME: text/xml, text/html, etc.

REST es una colección de principios de arquitectura y un estilo de arquitectura de software para construir sistemas distribuidos basados en mecanismos que definen y acceden a recursos como internet.

El término REST siempre es empleado para describir un framework de trasmisión de datos sobre un protocolo como HTTP sin agregar capas semánticas adicionales o manejos de sesión.

Objetivos del estilo de arquitectura REST

Escalabilidad de la interacción con los componentes. La web ha crecido exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de clientes que pueden acceder a través de la web: estaciones de trabajo, sistemas industriales, dispositivos móviles, etc.

Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para los servicios web.

Puesta en funcionamiento independiente. Este hecho es una realidad que debe tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras con el uso de las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido.

Compatibilidad con componentes intermedios. Los más populares intermediarios son varios tipos de proxys para web. Algunos de ellos, las caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. Por último, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

El principio fundamental de REST es que emplea el Uniform Resource Identifier (URI) para ubicar y acceder a la representación de un recurso. La representación de un recurso (conocida como representational state) puede ser creada, recuperada, modificada y borrada. Se debe recordar que las conversaciones no mantienen estado.  

Como indica Roy Fielding, uno de los principios de REST es que éste explota las tecnologías existentes, estándares y protocolos de la Internet, como por ejemplo HTTP.

Esta confianza en las cosas existentes hace que REST sea fácil de aprender y simple de utilizar respecto a otros estándares de intercambio de mensajes web.

En un sistema REST basado en HTTP, se pueden emplear los métodos HTTP estándares como GET, PUT, POST y DELETE para acceder al estado representacional del recurso:

GET: Se utiliza éste método para transferir el estado representacional actual de un recurso desde el publicador hacia el consumidor.

PUT: Se utiliza éste método para transferir el estado representacional actual de un recurso desde el consumidor hacia el publicador.

POST: Se utiliza este método para transferir un nuevo estado representacional de un recurso desde el consumidor al publicador.

DELETE: Se utiliza éste método para transferir información necesaria para cambiar el estado representacional de un recurso al estado ―eliminado‖ (o borrado).

Se puede hacer una analogía como la siguiente:

Asimismo, REST emplea las siguientes restricciones:

Identificación de recursos y manipulación de ellos a través de representaciones. Esto se consigue mediante el uso de URIs. HTTP es un protocolo centrado en URIs. Los recursos son los objetos lógicos a los que se le envían mensajes. Los recursos no pueden ser directamente accedidos o modificados. Más bien, se trabaja con representaciones de ellos. Cuando se utiliza un método PUT para enviar información, se coge como una representación de lo que nos gustaría que fuera el estado del recurso. Internamente, el estado del recurso puede ser cualquier cosa desde una base de datos relacional a un fichero de texto.  

Mensajes autodescriptivos. REST dicta que los mensajes HTTP deberían ser tan descriptivos como sea posible. Esto hace posible que los intermediarios interpreten los mensajes y ejecuten servicios en nombre del usuario. Uno de los modos que HTTP logra esto es por medio del uso de varios métodos estándares, muchos encabezamientos y un mecanismo de direccionamiento. Por ejemplo, las cachés web saben que por defecto el comando GET es cacheable (ya que es side-effect-free); en cambio, POST no lo es. Además, saben como consultar las cabeceras para controlar la caducidad de la información. HTTP es un protocolo sin estado y, cuando se utiliza adecuadamente, es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes.

 Hipermedia como un mecanismo del estado de la aplicación. El estado actual de una aplicación web debería ser capturada en uno o más documentos de hipertexto, y residir tanto en el cliente como en el servidor. El servidor conoce sobre el estado de sus recursos, aunque no intenta seguirle la pista a las sesiones individuales de los clientes. Esta es la misión del navegador, el sabe como navegar de recurso a recurso y recoger información que él necesita o cambiar el estado que necesita cambiar.

Entidades básicas en REST

REST define las siguientes entidades:

Data elements: Consiste de datos, identificadores (URIs y URLs), y representaciones de datos, como documentos HTML, documentos XML e imágenes.

Components: Incluye servidores web, proxies, user agents (navegadores web) y dispositivos móviles.

Connectors: Conectores de clientes, de servidores, cache de navegadores, etc.

Un diseño basado en REST es adecuado cuando:

§ el servicio web no tiene estado. Se puede comprobar verificando si la interacción puede sobrevivir a un reinicio del servidor.

§ una infraestructura de caching puede mejorar el rendimiento. Si los datos que el servicio web devuelve no son dinámicamente generados y pueden ser cacheados, entonces la infraestructura de caching que los servidores web y los intermediarios proporcionan pueden incrementar el rendimiento.

§ tanto el productor como el consumidor del servicio conocen el contexto y contenido que va a ser comunicado. Ya que REST no posee todavía un modo estándar y formal de describir la interfaz de los servicios web, ambas partes deben estar de acuerdo en el modo de intercambiar de información.

§ el ancho de banda es importante y necesita ser limitado. REST es particularmente útil en dispositivos con escasos recursos como PDAs o teléfonos móviles, donde la sobrecarga de las cabeceras y capas adicionales de los elementos SOAP deben ser restringida.

§ la distribución de servicios web o la agregación con sitios web existentes puede ser fácilmente desarrollada mediante REST. Los desarrolladores pueden utilizar tecnologías como AJAX y toolkits como DWR (Direct Web Remoting) para consumir el servicio en sus aplicaciones web.

Repositorio GITHUB

Cuando me mencionaron de repositorios me quede intrigado......
What? una breve busque en San Google y se me refresco la memoria, bueno lo que recordaba de este tipo de aplicación, fue el que use en algún tiempo el famoso Google Code. Pero, que de sorprendente? tiene este igual de famoso https://github.com/.

    

para Winowns

y encontré un vídeo que contesto todas mis dudas y sobre todo me animo a jugar con el.

Luego de configurar mi PC, fue una verdadera solución para trabajar con mi equipo, no solo te permite tener tu código en la nube. También, cada miembro de tu equipo puede participar e integrar sus avances. Lo mas resaltaste es que no tienes que bajar y subir a toda la fuente, Github compara las diferencia entre versiones y solo actualizar los últimos cambios.

GIT - Guia rápida de GIT

Seguro que a más de uno le será útil estos comandos como a mí, aquí dejo un pequeño

Indicar tu información personal

Lo primero es configurar GIT en local:

[ $ ~  ] cat /home/MisterX/.gitconfig

[core]

      editor = vim

[user]

      name = MisterX

      email = misterx@apu.org

Así al hacer los commits saldrá nuestro nombre y correo.

Crear repositorio en el servidor

Si no existe nada en el repositorio del servidor, y lo tenemos que crear desde cero:

# mkdir nombreRepo

# cd nombreRepo

# git init

# git remote add origin ssh://gituser@apu.org/nombreRepo.git

Esta última linea es suponiendo que el acceso se hace por SSH.

Luego metes en el directorio nombreRepo el código inicial, y con

git add

añades todos los ficheros que quieras tener en el repositorio.

Luego haces:

# git commit -m "Initial commit blah blah blah"

# git push origin master:refs/heads/master

A partir de ahí ya tendrás el repositorio funcionando.

Clonar un repositorio existente

Si en vez de crear un repositorio desde cero, lo que quieres es trabajar con uno que ya esta en marcha:

# git clone ssh://gituser@apu.org/nombreRepo.git

Añadir ficheros al repositorio

Lo archivos que crees nuevos no se enviarán automáticamente al servidor, tienes que añadirlos con

git add nombreArchivo

Si son muchos los que has añadido, puedes hacer

git add .

en el directorio raiz del repositorio para que añada todos. Lo único es que debes tener cuidado con no añadir ficheros temporales o autogenerados. Se puede hacer que git ignore ciertos ficheros (los *.swp de vim, etc) añadiéndolos al fichero .gitignore en el directorio raíz.

Ver estado del directorio de trabajo

Puedes ver el estado actual de los ficheros (sin añadir, añadidos, modificados, etc):

git status

Si por accidente añades un fichero que no debes, puedes hacer que git lo olvide de nuevo con

git reset HEAD

Cuando te pase, git status te recuerda el comando.

Guardar modificaciones

Cuando modifiques ficheros, puedes, o bien hacer commit de todo lo que haya sido modificado o añadido con

git commit -a

o bien, si quieres
dividir los cambios en varios commits (porque no están relacionados
entre si), puedes hacer

git add

a unos cuantos ficheros que hayas
modificado y luego haz

git commit

Eso te abre el Vim con un resumen de los cambios para que introduzcas el mensaje de commit (una primera linea con un resumen, y opcionalmente, separado por una linea vacía, una explicación más extensa del commit). También puedes especificar un mensaje corto de commit directamente mediante

git commit -m Mensaje

Sincronizar el directorio de trabajo con el repositorio del servidor

Y finalmente para actualizar el repo:

git pull --rebase

y para enviar al servidor todos los commits locales:

git push

No se aplica ningún cambio en el repositorio del servidor hasta que haces el 'push', así que puedes trastear todo lo que haga falta con los diversos comandos en local.

Si quieres deshacer un commit:

git reset HEAD~1

Aprendiendo Web Service

Este blog cuenta las historias que hemos realizado para lograr realizar Web Service.

Una definición breve seria es la forma de establecer un comunicación entre sistemas o aplicaciones, sin dejar que el lenguaje de ellas sea un obstáculo, debido a que se comunican principalmente con legue XLM o JSON.