domingo, 12 de abril de 2015

Construir un servicio WS SOAP for Dummies

Un servicio WS SOAP es un servicio SOAP sobre web. La idea es transferir la información mediante xml.



Hoy vamos a construir un servicio WS SOAP desde cero y tendremos un servicio de Pruebas para emular el consumo del servicio. Así mismo, trabajaremos con una persistencia simple DAO y así guardar/recuperar información de una base de datos SQL Server. Esto último solo es para aprovechar mejor el servicio.


El ejemplo a continuación es un servicio de vehículos, pero puede adaptarse para trabajar con usuarios, productos, animales y/o añadir más objetos.


En la vista observamos 2 proyectos: El servicio WS_SOAP y el WS_TEST_SOAP. En WS_SOAP hemos creado dos carpetas (Dominio y Persistencia) solo para mantener el orden. En Dominio se agregarán las clases de los objetos que iremos añadiendo y en Persistencia estará el archivo de conexión (ConexionUtil) y los métodos de cada clase.







En primer lugar definiremos los atributos de nuestra clase Vehiculo.cs. Nuestro Vehiculo contará con una Placa, será de una Marca y Modelo definidos.
Luego pasaremos a indicar que elementos serán serializados. Esta parte es importante porque a nivel de servicios no se envian variables con sus tipos, sino que pasan tramas de bits que luego serán interpretadas según los metadatos.

Así pues, el DataContract define un espacio de nombre XML para que la información pueda ser almacenada; mientras que los DataMember (uno por cada atributo) indican el nombre con que será representado y que dicho atributo será serializado.


Ahora crearemos una clase de apoyo para conectarnos a la base de datos: ConexionUtil.cs

Solo contiene un método que retorna una cadena de conexión a la base de datos. Recuerden poner el nombre de la base de datos con la que estén trabajando. Si la base de datos no es local, en Data Source cambien el punto por la IP del servidor correcto.

Ahora configuramos VehiculoDAO. Una clase que almacenará los métodos de Vehiculo. De momento usaremos 2: Crear y Obtener; pero se pueden añadir incluso los métodos para las validaciones (Documento válido, usuario NO repetido, etc).



























































Ahora configuremos nuestro servicio web con WS SOAP. Para esto, creamos un nuevo elemento dentro del proyecto.
Click derecho sobre el proyecto --> Agregar... --> Nuevo elemento.


Buscamos "Servicio WCF". Le damos un nombre apropiado y luego click en "Agregar"


Se generará más de 1 archivo:
IVehiculosSVC, VehiculosSVC y VehiculosSVC.svc, este último dependiente del anterior.


El primero tiene una I adelante porque es la Interfaz. Este es un archivo donde solo se declaran las operaciones y da la cara al servicio.


VehiculosSVC.svc.cs es donde se implementan las operaciones declaradas en la Interfaz; es decir, añadiremos aquí la lógica de cada operación.


Por defecto, se abrirá el archivo IVehiculosSVC. Analicemos su estructura.




En primer lugar veremos unas etiquetas llamadas ServiceContract y OperationContract.

El ServiceContract sirve para definir el servicio a brindar, mientras que los OperationContract indican que operaciones del servicio se van a exponer y podrán ser consumidas por terceros.

Esto es importante porque nos permite usar nuestros métodos sin exponerlos directamente.

Pasamos a borrar el OperationContract de Ejemplo y agregamos las nuestras (Crear y Obtener).


Para evitar confusiones, nuestras operaciones deben tener nombres distíntos a nuestros métodos. En nuestro caso los métodos tienen nombres básicos como Crear y Obtener mientras las operaciones son CrearVehiculo y ObtenerVehiculo.

Pasamos al archivo VehiculosSVC.svc.cs. Tenemos que implementar las operaciones declaradas en la interfaz. La forma más sencilla es ubicar el cursor sobre la Interfaz a quien implementamos, abrir el menú contextual y seleccionar "Implementar la interfaz..."



Ahora solo tenemos que reemplazar las excepciones indicadas por nuestro código.





sábado, 11 de abril de 2015

Message Bus - Conceptos

Antiguamente las aplicaciones se diseñaban a medida para cada escenario concreto. Con el uso intensivo de la red, se vió pertinente empezar a intercambiar información entre los distintos sistemas.

El reto consiste en que todas las aplicaciones se comuniquen entre sí de manera apropiada y con el menor costo posible.

En un primer acercamiento, se definió un patrón de canal punto a punto.

El problema es que a mayor número de aplicaciones, crece exponencialmente la cantidad de código a escribir, y así mismo, crece el consumo de recursos de la red si existe mucha demanda.


Para resolverlo, se llegó al patrón Bus de Mensajes

Con este patrón, definimos un sistema independiente que administrará todos los mensajes. De esta manera, la aplicación se deberá modificar como máximo una sola vez para enviar los mensajes a este bus. Luego, este se encargará de reenviar el mensaje a todas las aplicaciones consumidoras.

Cabe decir que la entrega de los mensajes es bajo el patrón Canal Publicador-Subscriptor, pues ciertamente habrán algunas aplicaciones que no requerirar los mensajes; ahorrando recursos de procesamiento y de red.

Fuentes:







Entendiendo Hadoop


Con la explosión de internet se empezaron a generar grandes cantidades de datos, sobre todo datos no estructurados. El problema es que analizar los datos se vuelve costoso, en primer lugar por la cantidad y luego por su falta de estructura.

Hadoop es un framework desarrollado en JAVA para sistemas de archivos distribuidos que permite el procesamiento de grandes volúmenes de datos, ya sean estructurados o no, de manera escalable mediante clusters. Además permite una alta disponibilidad. Puede migrar de unos cuantos nodos hasta miles de ellos de forma rápida y confiable.

Trabaja con una arquitectura maestro/esclavo donde existe un nodo maestro encargado de realizar el procesamiento y almacenar la información en múltiples nodos esclavos. También existe un nodo esclavo pasivo, que toma las funciones del nodo maestro cuando este falla.

Así mismo, los nodos están agrupados en Racks (Capaces de mantener hasta 40 nodos maestros) y estros se comunican con otros Racks para intercambiar información y procesos cliente, el cual es cualquier petición de un nodo maestro (almacenamiento o recuperación de data).

La idea subyacente está en los procesos cliente. Estos se dan en cada nodo maestro por demanda, lo que quiere decir que solo usa los recursos del nodo, o en su defecto, los del rack. Esto reduce el tráfico en la red troncal permitiendo máyor concurrencia.

Hadoop se aprovecha del uso de XML para intercambio de información, por lo que es muy sencillo agregar nuevos racks y nodos a un ecosistema.

Adicionalmente, permite trabajar con distinto hardware, incluyendo servidores económicos. Lo que viene bien pues abarata costos y distribuye aún más el procesamiento.



Fuentes:



HTTP/2 - Por una navegación más rápida

gizlogic.com

El protocolo HTTP 1.1 (su última actualización) tiene entre nosotros alrededor de 16 años, pues es un estandar desde 1999. Una eternidad en el espacio-tiempo tecnológico.

Desde Google pensaban que la navegación mediante este protocolo es lenta y podía acelerarse. Es por esto que desarrollaron SPDY (léase "Speedy"). Estamos hablando de noviembre de 2009 y este proyecto está en sus fases iniciales, aunque en pruebas de laboratorio ya presentaban una mejora de hasta 50% en velocidad de carga.

Luego de un proceso de mejora continua, el proyecto SPDY entra a una etapa de estandarización de la tecnología (Julio de 2012) y pasados 5 meses se convierte en un borrador de HTTP/2 en la IETF (Internet Engineering Task Force).

Hace algunos días, desde la IETF, mencionan que la especificación HTTP/2 por fin está concluida y empieza la fase en la cual los navegadores deben implementar el nuevo protocolo en su código.


¿Qué ventajas provee HTTP/2?

La más visible es la mejora en velocidad de carga de las webs y una reducción de consumo de ancho de banda.

Todos los elementos de una página web (imágenes, archivos CSS, JavaScripts y el propia página HTML) son considerados como objetos. Por lo tanto, para cada web podemos tener cientos si no miles de objetos.

En HTTP/1.x las conexiones apuntan a solicitar objetos únicos. Los navegadores pueden realizan una descarga en paralelo de todos los objetos que necesitan de un site, pero lo hacen generando múltiples conexiones hacia el mismo servidor. Esto genera consumo de red y tiempo adicional.

A nivel de desarrollo, esto significa un incremento significativo en la velocidad de transferencia de información entre servicios, ya sea por WS SOAP o por REST.



fuentes:
https://www.mnot.net/blog/2015/02/18/http2

http://arstechnica.com/information-technology/2015/02/http2-finished-coming-to-browsers-within-weeks/