Sistemas de Informacion

REST vs SOAP

Aunque REST y SOAP son arquitecturas muy similares de intercambio de información entre aplicaciones web y de escritorio con servidores, antes de decidirse por uno de ambas es importante tener en cuenta las siguientes consideraciones. Trataré de ser objetivo en este artículo ya que hasta hace poco empecé a utilizar REST (4 meses), todo lo que aprendí sobre websvices esta basado en SOAP.

Primeramente hay que entender que REST esta basado en una arquitectura donde se identifican los recursos claves a consumirse.. veámoslo como una forma semántica de escritura ante la web donde hay métodos que al ser interpretados nos retornan información… Algo como por ejemplo utilizando el método GET del protocolo HTTP (digo GET porque también se puede utilizar POST, PUT, HEAD, DELETE, etc.. ) haría una petición de la siguiente manera: “http://servidor.com/api/proyecto/1/tarea/5″ .. donde api es el contenedor de mi webservice y lo que sigue sería equivalente a decir.. Del proyecto con identificador no. 1 seleccionar la tarea con identificador no. 5 y mostrar el resultado en formato json o xml.

Así de fácil es REST, mientras que SOAP es un poco más complicado por que lo que se consumen son métodos o funciones almacenadas igualmente en un servidor.. entonces si quisiera hacer lo mismo.. en SOAP tendría que escribir algo como lo siguiente: “http://miservidor.com/api/calcula” donde calcula contiene una definición de funciones (sumar y restar) que se pueden implementar mediante la creación de un objeto, un concepto de la programación orientada a objetos .. del uso de alguno de los métodos listados en el servicio calcula como respuesta obtendría una salida en xml con una definición del tipo de datos que respondió el servidor..

Si se fijan ambos tipos de conexión ya sea REST o SOAP se parecen mucho, ya que sirven para solicitar información a un servidor, pero distan de implementarse de una manera similar.. verán que REST es mucho más fácil y SOAP conlleva escribir un poco más de código..

En la actualidad muchos de los servicios que utilizamos a diario como twitter, facebook, fourquare, delicious, flickr, etc.. estan basados en REST por la facilidad de imlementación y la simplesa que se obtiene en los resultados.

SOAP ya que tiene una arquitectura de respuesta más compleja, es utilizado comunmente en corporaciones, hasta me atrevería a decir que la mayoría de empresas que utilizan sistemas basados en .NET o Java tienen sus servicios de comunicación basados en SOAP .. porque ha decir verdad es muy fácil implementar esos objetos y consumir esos métodos.. porque claro!! hay personas que ya hicieron todo el trabajo pesado de crear librerías que se usan casi con un par de líneas. Además que en estos lenguajes se tienen componentes visuales que se conectan casi de manera transparente a webservices basados en SOAP por lo que como dije.. ya todo lo interesante ya se hizo.

Entonces ya que tenemos una mejor idea de que hace REST vs SOAP podemos hacer comparaciones y obtener una conclusión..

REST

En lo que es genial

Es muy ligero, sus respuestas contienen exactamente la información que necesitamos.
Para los nosotros los humanos es muy fácil y simple de interpretar.
Es sencillo de desarrollar y no se necesita mucho código extra.
Es flexible en cuanto al tipo de respuesta que se necesita, ya que puede ser xml o json.

En lo que falla

Creo que la seguridad es un problema y puede llegar a ser una tarea muy difícil implementarla correctamente.
No hay un estándar en sus respuestas por lo que no se definen tipos de datos.

SOAP

En lo que es genial

Si trabajas con componentes y utilizas .NET o Java es muy sencillo de consumir.
El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto.
Se dice que es más seguro porque su implementación siempre o la mayoría de las veces se hace del lado del servidor.

En lo que falla

Una vez implementado, si se desea cambiar algo en el servidor impacta de forma negativa en los clientes ya que estos tienen que hacer muchas modificaciones al código.
Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las herramientas correctas para hacerlo.

Conclusión

Creo que ambas arquitecturas de intercambio de información tienen sus nichos bien definidos, cuando se trata de aplicaciones públicas refiriéndome a servicios de uso masivo es mucho mejor utilizar REST por la sencillez en su implementación y respuestas, inclusive en clientes móviles es mucho más fácil utilizar REST. Por otro lado si se esta pensando en webservices para corporaciones donde se manejan datos complejos y se necesita una presición detallada en las respuestas se debe de utilizar SOAP, entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.

Compartir y Disfrutar

Sistemas de Informacion / tecnologia / Tendencias — 1 Comment
25
ene 12

El nuevo protocolo de internet que nos promete más tiempo de vida a Internet

IPv6 es el nuevo Protocolo de Internet (IP) que actualmente ya está conviviendo y sustituyendo en algunos casos progresivamente a IPv4 por pruebas realizadas con anterioridad en el World IPv6 Day, donde algunas empresas demostraron las mejoras de este protocolo entre las características más destacadas son :

Espacio de direcciones prácticamente infinito;

Posibilidad de autoconfiguración de varios dispositivos con puertos de red (computadoras ruteadores, agendas electrónicas,

Teléfonos inteligente, computación móvil, calidad de servicio; un mejor diseño para el transporte de tráfico multimedia en tiempo real;

Así como diversos mecanismos de transición gradual de IPv4 a IPv6 y de comunicación entre equipos de ambas versiones.

La transición total a IPv6 durará varios años ha establecido una fecha oficial de lanzamiento mundial, actualmente grades empresas de comunicaciones, búsqueda y entretenimiento entre ellas Facebook, Google, Microsoft o Yahoo! se han unido para integrarse en este ambicioso proyecto, ya que en la actualidad el moribundo protocolo IPv4, apenas se da abasto para mantener una sustentabilidad adecuada para el amplio uso de internet donde se integran día a día nuevos equipos, como son teléfonos inteligentes, tablets, dispositivos móviles, laptops, servidores etc.

Este protocolo de internet proporcionará un número de direcciones casi infinito (2128: 3,4 x 1020 para sextillones de direcciones) teniendo un direccionamiento de 32 a 128 bits, con soporte mejorado para extensiones, capacidades de autenticación, integridad y confidencialidad de datos.

Pero no hay que olvidar como fue que surgió IPv4, que fue el que nos permitió desenvolvernos, esta gran era de la información, recordemos que TCP/IP fue presentado en 1972 como un sistema que permitía 4.300 millones de direcciones, cuando este se presentó nunca se pensó que esa enorme cantidad se vería sobrepasada en algún momento, simplemente en ese tiempo jamás nos imaginamos con tantos dispositivos como los que usamos actualmente que fueran capaces de interconectarse en un espacio que rompería fronteras, idiomas, o creencias.

El 6 de junio se llevará a cabo la activación y reconocimiento de IPv6, trayendo con él una nueva etapa en nuestra era de las comunicaciones y de la información.

Fuentes:

http://www.worldipv6launch.org/participants/

http://www.muycomputerpro.com/2011/06/08/world-ipv6-day-a-prueba-el-protocolo-ipv6/

Compartir y Disfrutar

Sistemas de Informacion — No Comments
16
abr 10

Análisis y Tratamiento de Información

Este blog queda dedicado al área de sistemas olvidada por la mayoría de las empresas que conozco. El análisis y tratamiento de la información apoyada por el área de Sistemas.

El tratamiento de la información es el proceso analítico y temático que realiza el área de sistemas para obtener un resultado dado a partir de un conjunto de datos y archivos (definición personal).

Es importante, no perder de vista que para este tipo de procesos, el área de sistemas depende de la información requerida de otras áreas de la empresa. Es decir, imaginemos un proceso que requiere hacer el área de ingeniería, el cual consiste en obtener de un universo de 10000 archivos, una lista de archivos modificados a partir de cierta fecha. Bueno, hasta este momento cualquier usuario mortal puede realizar este proceso utilizando únicamente el buscador de Windows. Pero la cosa no termina allí. Adicionalmente, el área de ingeniería requiere que a partir de esa lista resultante se coteje con la información contenida en una base de datos. Si el archivo existe se debe de remplazar. En caso de que el archivo no exista, se debe de subir con toda la información relacionada al archivo (metadatos).

Bueno, una vez planteado el problema enumeremos los pasos que se tendría que hacer en caso de que no se tuviera la ayuda del área de sistemas.

Como ya mencione, utilizar el buscador de Windows y, en caso de que Windows no falle como me sucedió a mí, buscar aquellos archivos modificados a partir de una fecha. Tiempo estimado de búsqueda 40 minutos.
Copiar la lista de archivos resultado (3000) a una carpeta determinada. Tiempo estimado del proceso 4 horas (en caso de que Windows marque error por ruta demasiada larga se puede duplicar o triplicar el tiempo).
Si ya tenemos al personal que va a realizar el engorroso proceso de buscar en la base de datos de la empresa y cotejar archivo por archivo (3000 archivos) y reemplazar los archivos que ya existen y en caso de que no exista subirlo a la base de datos con toda la información relacionada (metadatos). Si consideramos que la persona ya domina la aplicación que sube a la base de datos, y que se tarda en promedio en reemplazar 200 archivos por día. En caso de que no exista el archivo se tarde en subir 300 archivos por día con todo y sus metadatos. Si tomamos que de los 3000 archivos el 25% no existe en la base de datos, el resultado sería 2250/200=11.25 días para reemplazar y 750/300=2.5 para subirlos completamente.

El total de tiempo requerido para hacer este proceso es 1 (paso 1,2) + 11.25 + 2.5 = 14.75 días.

Ahora bien, enumeremos el tiempo requerido utilizando el área de sistemas para realizar este proceso.

Hacer una aplicación que verifique los archivos que hayan sido modificados a partir de la fecha dada. De la lista resultado compararla con la información contenida en la base de datos. Si el archivo existe, lo debe de reemplazar, en caso de que no exista debe copiar el archivo en una carpeta determinada. Tiempo estimado, 1 día de desarrollo. Tiempo estimado del proceso 1 día (recordemos que el día para un proceso ejecutándose dura 24 hrs y no 8 horas como es el caso de una persona).
Tomando los datos anteriores solo quedarían por subir 750 archivos. Tiempo estimado 750/300=2.5 días.

El total de tiempo requerido para hacer este proceso es 1 (programador) + 1 (proceso) + 2.5 (auxiliar) = 4.5 días.

Bueno, como pueden apreciar en los resultados, por obvias razones es mejor el tiempo que el área de ingeniería obtendría su información apoyándose en el área de sistemas que realizarlo de forma independiente. Ahora, muchos podrán decir, que lo que se le paga a un programador no es lo mismo que lo que se la paga a un auxiliar. Pues sí, pero eso será tema de otro blog que posiblemente le llameré “Es sustentable tener un área de sistemas”.

Twiter @QBit_Mike

Qbit Mexhico BlogLo que hacemos y pensamos se escribe aqui