martes, 11 de octubre de 2016

Protocol Buffers

¿Que es protocol buffers?

Es un método desarrollado por google que se centra en la serialización y deserialización de información estructurada de manera independiente al lenguaje de programación e inclusive al sistema operativo. Es útil para la comunicación entre programas o almacenamiento de datos. este método implica un lenguaje de descripción de la interfaz que describe la estructura de la información y un programa que genera el código fuente de esta descripción para poder interpretar, generar o analizar una corriente de bytes que representa la información estructurada. Esto nos ofrece una forma sencilla de crear nuestro propio protocolo de comunicaciones, adaptado a las necesidades de un problema concreto.

¿Cómo funciona?

Se especifica como es que se quiere la información a serializar en una estructura, En la cual se define los tipos de mensaje del protocol buffers en archivos de tipo .proto. Cada mensaje representa una pequeña unidad del registro de datos que contiene una serie de claves y valores (similar tal vez a JSON).

Ejemplo:
message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}
Como se puede apreciar el formato del mensaje es bastante sencillo, cada tipo de mensaje tiene uno o mas campos numerados y cada campo tiene su nombre, un tipo de dato y su correspondiente valor asignado. También es posible definir la estructura de manera jerárquica, especificar opciones por campo, campos obligatorios.

Luego de haber definido los mensajes, se ejecuta el compilador de protocol buffers para generar las clases de acceso a datos. Lo cual proporciona algunos accesorios para cada campo como por ejemplo query(), set_query(), además de métodos para serialización.

¿Por que no hacer uso de XML?

Protocol buffers es ventajoso en comparación a XML a la hora de serializar datos estructurados, podemos mencionar lo siguiente:
  • Son más sencillos
  • Son desde 3 hasta 10 veces más pequeños
  • Son desde 20 hasta 100 veces más rápidos
  • Son menos ambiguos
  • Generan accesos de datos que pueden ser fáciles desde el punto de vista de la programación

Realizando una comparación sin resaltar las ventajas de protocol buffers nos encontramos con lo siguiente:
  • Protocol buffers es menos amigables que XML, en el sentido de que no se entienden por sí sólos y es necesario definir el fichero .proto.
  • Protocol buffers es mucho más eficiente, ocupa menos espacio, tiene más rapidez de ejecución, y es más accesibles desde programación.
  • Protocol buffers es una alternativa mejor que XML en el caso de que se pueda definir el fichero .proto que defina la entidad y se quiera ganar en rapidez y facilidad de acceso.
  • Protocol buffers no se recomienda en el caso de lenguajes que requieran ser entendibles por sí solos, como puede ser XML (sin el fichero .proto, no es posible interpretar el contenido).

WCF y ASP.NET Web API

WCF: es un modelo unificado de programación propuesto por Microsoft para aplicaciones orientadas a servicios. Este modelo permite a los programadores compilar soluciones con transacción seguras y de confianza, que se integren en diferentes plataformas y que además interoperen con las inversiones existentes.

ASP.NET Web API: es un framework que tiene como objetivo facilitar la construcción de servicios HTTP que llegan a una gran variedad de clientes, incluidos los exploradores y los dispositivos móviles. Este framework es ideal para la compilación de aplicaciones RESTful orientadas a ofrecer servicios.

Se habla mucho de las Web Api de .Net como alternativa para desarrollo de aplicaciones orientadas a servicios. Pero para poder tomar una decisión adecuada en el contexto que nos encontremos será necesario tener en cuenta algunas puntualizaciones de estas dos opciones.

¿Que me ofrece ASP.Net. Web Api?.
  • Funciona en la forma de HTTP usando verbos estándares como GET, POST, PUT, DELETE para operaciones CRUD (crear, reportar, actualizar, eliminar).
  • Soporte completo para enrutamiento.
  • Respuesta generada en formato JSON o XML usando MediaTypeFormatter.
  • Tiene la habilidad de ser hospedado en IIS (Internet Information Services).
  • Soporta enlace de modelos y validación.
  • Soporte para OData.
Bueno eso ofrece ASP.Net Web Api, pero tenemos que puntualizar algunas cosas.


WFC está diseñado para intercambiar mensajes estándares basados en SOAP usando una variedad de protocolos de transporte como HTTP, TCP, Named Pipes, MSMQ, etc.

ASP.NET Web API es un framework para construir servicios que no están basados en SOAP, solamente sobre HTTP.

Como podemos notar existen claras diferencias que no se detallan en este blog pero que de seguro no darán un buen punto de partida para adentrarnos mas en el tema.

Bueno antes de terminar quisiera dejar en claro algo mas que leí y escuche en mi centro de labores. Decián que las Web Api de .Net reemplazarian a WCF el cual ya se debería extinguir. Bueno esto no es algo acertado de acuerdo a la documentación encontrada podría decir lo siguiente.

Existen algunas ventajas pero WCF es aún la mejor opción para los siguientes escenarios.
  • Si vamos a usar un transporte diferente a HTTP como por ejemplo TCP, UDP o Named Pipes.
  • Escenario de encolamiento de mensajes usando MSMQ.
  • Comunicación de una sola vía o comunicación dúplex.
Por lo tanto son dos formas de construir servicios y seria totalmente errado decir que las Web Api de .net reemplazaran a WCF.






RMI

¿Qué es RMI?

Es una implementación independiente de la plataforma JAVA, la cual permite que tanto los objetos remotos como las aplicaciones cliente, residan en sistemas heterogéneos. Sin embargo es necesario resaltar que el lenguaje no es independiente, tanto el objeto servidor RMI como el objeto cliente tienen que ser escritos en Java.

* para un programador Java el uso de RMI le resultara muy natural por que ya no tiene que aprender una tecnología totalmente diferente.

Objetivos de RMI

Proporcionar una lógica de intercambio de información (middleware) para el desarrollo de aplicaciones distribuidas manteniendo el estilo de programación utilizado en Java:
  • Mecanismos para crear servidores y objetos cuyos métodos se puedan invocar remotamente.
  • Mecanismos que permiten a los clientes localizar los objetos remotos.
Arquitectura RMI

A través de la siguiente podemos entender como se estructura una solución RMI.


De acuerdo a la ilustracion tenemos lo siguiente:

Nivel de transporte: en esta capa gestiona todo lo referente a las comunicaciones
Nivel de gestión de referencias remotas: trata los aspectos relacionados con el comportamiento esperado de las referencias remotas (mecanismos de recuperación, etc.)
Nivel de resguardo/esqueleto (proxy/skeleton): que se encarga del aplanamiento (serialización) de los parámetros
  • proxy: resguardo local. Cuando un cliente realiza una invocación remota, en realidad hace una invocación de un método del resguardo local.
  • Esqueleto (skeleton): recibe las peticiones de los clientes, realiza la invocación del método y devuelve los resultados.
Ventajas y desventajas de RMI

Ventajas
  • En entorno Java permite distribuir una aplicación de forma muy transparente, sin realizar demasiados cambios ene el código.
  • Las invocaciones remotas son mas eficientes que las peticiones via http que se usan con CGIs o son servlets.
Desventajas
  • Se consume tiempo para realizar la serialización y descerialización de parámetros.
  • Solo funciona con Java.


lunes, 10 de octubre de 2016

CORBA

Para poder comprender adecuadamente los retos planteados cuando se habla de sistemas distribuidos, es necesario tener en claro una serie de términos clasificándolos en el ámbito que corresponde para incursionar en su implementación y aún mas si deseamos hacer comparaciones durante una evaluación.

¿Que es CORBA?

Es un estandar la OMG (Object Managment Group), el cual establece las especificaciones para construir software interoperativo utilizando tecnología orientada a objetos.

La especificación puede ser implementada o no en su totalidad por cada plataforma. Pero debemos considerar para aquello que se implemente, que debe hacerse de la manera que está especificado.

¿Que nos brinda CORBA?

  • Independencia en el lenguaje de programación y sistema operativo: CORBA fue diseñado para liberar a los ingenieros de las limitaciones en cuanto al diseño del software. 
  • Posibilidad de interacción entre diferentes tecnologías: uno de los principales beneficios de la utilización de CORBA es la posibilidad de normalizar las interfaces entre las diversas tecnologías y poder así combinarlas.
  • Transparencia de distribución: ni cliente ni servidor necesitan saber si la aplicación está distribuida o centralizada, pues el sistema se ocupa de todo eso.
  • Transparencia de localización: el cliente no necesita saber donde ejecuta el servicio y el servicio no necesita saber donde ejecuta el cliente.
  • Integración de software existente: se amortiza la inversión previa reutilizando el software con el que se trabaja, incluso con sistemas heredados.
  • Activación de objetos: los objetos remotos no tienen por qué estar en memoria permanentemente, y se hace de manera invisible para el cliente.
Arquitectura de un sistema CORBA



Un sistema CORBA es un conjunto de objetos que interactúan entre ellos, los cuales pueden interactuar también con servicios y utilidades CORBA:
  • La interacción real se da a través del ORB (Object Request Broker)
  • Si en el sistema intervienen distintos ORBs, estos interactuan mediante protocolo IIOP
  • Adaptador de objetos AO actua como interfaz entre ORB y objetos.
Esta especificación define la interfaz de una serie de servicios de utilidad para cualquier aplicación, los cuales, se comportan de forma similar a cualquier otro objeto del sistema.
  • Servicio de nombre: permite registrar y localizar objetos asociándole un nombre
  • Servicio de localización: permite localizar objetos a través de su interfaz
  • Servicio de eventos: permite enviar/recibir eventos entre objetos
  • Servicio de propiedades: permite añadir propiedades (pares nombre/valor) a los objetos en tiempo de ejecución
Alternativas a CORBA
  • Programación mediante interfaz de sockets
  • RPC (Remote Procedure Call)
  • DCE (Distributed Computing Environment)
  • DCOM (Distributed Component Object Model)
  • PVM (Parallel Virtual Machine)
  • SR (Synchronizing Resources)
  • MPD (Multithreaded, Parallel and Distributed)
  • Java RMI
  • .NET Remoting
  • Servicios Web