Formatos de intercambio de información: JSON y XML

¿Que es XML?

XML(Extensible Markup Language). Se usa ampliamente para enviar información en servicios webs y APIs Rest.  Uno de los lenguajes de programación que le da más soporte es Java.

Una de las fortalezas de XML es el soporte a Unicode, lo que permite escribir la información en cualquier idioma del mundo y otra es el amplio soporte que tiene en la actualidad. Pero por otra partes es criticado por su complejidad. Mapear una estructura básica XML usando tipos de datos de un lenguaje de programación o bases de datos a veces puede ser muy difícil y poco descriptivo. Además, para documentos muy grandes, suele requerir un uso más intensivo de memoria y procesador.

 Ventajas  Desventajas
 Tiene un formato muy estructurado y fácil de comprender. Es mas complicado de entender
 Puede ser validado fácilmente mediante Schemas(XSD)  Lleva mas tiempo procesarlo
 Se pueden definir estructuras complejas y re utilizables. Un error con los namespace puede hacer que todo el documento sea invalido

¿Que es JSON?

JSON(JavaScript Object Notation), también es ampliamente usado para intercambio de información entre servicios web y APIs REST. Su simplicidad y facilidad de implementación le otorgan un gran desempeño y lo convierten en una de las alternativas ideales al momento de reemplazar XML

Un objeto JSON es un objeto válido JavaScript por lo que es el formato perfecto para ese lenguaje pero también es empleado con mucha frecuencia por los desarrolladores Python. La mayoría de los navegadores web modernos incluyen funciones nativas para codificar y decodificar JSON, lo que le da un punto de ventaja en lo que se refiere a desempeño y disminuyen los riesgos de seguridad.

 Ventajas  Desventajas
 Formato sumamente simple Tiene una estructura enredosa y difícil de interpretar a simple vista
Velocidad de procesamiento alta
 Archivos de menor tamaño.

 

Referencias

https://blog.udemy.com/json-vs-xml-como-json -es-superior-a-xml/
http://magmax.org/blog/2010/7/20/xml-vs- json/
http://alexisrojascastro.blogspot.pe/2013/04/xml -vs-json.html

Web Services vs WCF

Web Service

El desarrollo de servicios Web con ASP.NET se basa en la definición de los datos, serializa y deserializa objetos en documentos XML. Esto gracias a la clase XmlSerializer que permite controlar el modo en que se codifican los objetos en XML para transformar los datos desde o hacia un servicio.

Adicionalmente se puede decir que puede ser usado internamente por  cualquier aplicación o externamente, a través de la internet por cualquier número de aplicaciones usando estándares como XML (Lenguaje de Marca Extensible) y HTTP (Protocolo de Transferencia de Hipertexto).

WCF

Es un conjunto de librerías que provee Microsoft en el Framework .NET para la construcción de aplicaciones orientadas a servicios.

Es también un modelo de programación unificado, el cual se define como un simple vía para escribir servicios y por tanto unifica elementos como Servicio Web (*.asmx), .NET Remoting, Message Queue (MSMQ), Enterprise Services (COM+) y Servicios web Mejorados. WCF no remplaza estas tecnologías sobre una base individual, más bien suministra un modelo simple de programación que puede usar para aprovechar todo estos elementos a la vez.

Diferencias

  1. Los datos de los Servicios web solo viajan por via HTTP , mientras que los componentes WCF pueden ser invocados por cualquier protocolo y para cualquier tipo de transporte.
  2. WCF es más flexible.  Con la API de programacion que proporciona podemos crear el servicio y la configuración que queramos para el mecanismo de comunicación que usemos como http, tcp, msmq, etc.
  3. Interoperabilidad: Mientras que con .NET Remoting el cliente y el servidor deben ser .NET

Ventajas de WCF sobre Servicios Web

  1. WCF ofrece comunicación con multiples plataformas
  2. WCF proporciona una un mecanismo de Logging que te ayuda a logear tus trazas
  3. Mecanismos de seguridad (como por ej. WSHTTPbinding)
  4. Integracion con XML/JSON
  5. Proporciona un mecanismo para la gestión de instancias.
  6. WCF utiliza como serializalizador DataContractSerializer que proporicona una mejor rendimiento que su equitativo en Web Services XmlSerializer

 

Referencias

https://msdn.microsoft.com/es-es/library/aa738737(v=vs.110). aspx
https://infoinnova.net/2011/11/wcfvsaspnet /
https:// tav1n.wordpress.com/2010/08/30/diferencias-entre-un-web-service-en-asp-net-y-wcf/

Debate: Soap VS REST

¿Que es REST?

Rest(Representational State Transfer), Es  un estilo de arquitectura de software para sistemas distribuidos tales como la web. Se centra en el uso de los estandares HTTP y XML para la transmisión de datos. Las operaciones se solicitan mediante GET, POST, PUT, DELETE, por lo que no requiere de implementaciones especiales para consumir estos servicios.

Además, con esta opción se podrá utilizar Json en en vez de XML como contenedor de la información, por lo que sería lo ideal en utilizar este protocolo cuando busquemos mejorar el rendimiento.

¿Que es SOAP?

SOAP(Simple Object Access Protocol), Es un protocolo muy común que es usado para el intercambio de mensajes sobre redes de computadoras, generalmente usando HTTP. Esta basado en formatos XML, esto facilita la lectura y a su vez  lo hace considerablemente mas lentos al transferir información.

¿Que ventajas tiene SOAP sobre REST?

  1. El lenguaje, la plataforma y el transporte son independiente entre sí, a diferencia de REST que si o si necesita de HTTP
  2. Funciona bien en entornos empresariales distribuidos
  3. Un excelente manejo de errores
  4. Automatización simplificada

¿Que ventajas tiene REST sobre SOAP?

  1. Accesible mediando código Javascript usando AJAX.
  2. No hay herramientas costosas que se requiera para utilizar con los webservices
  3. La curva de aprendizaje en la programación es más corta.
  4. Rest utiliza formato como JSON  que posee mensajes más pequeños y sencillos que los que puede brindar XML, con lo cual es más eficiente.
  5. Es más rápido.
  6. Más cerca de otras tecnológica gracias a la filosofía de su diseño

REST vs SOAP

 REST  SOAP
 Se centra en la escalabilidad y rendimiento a gran escala para sistemas distribuidos hipermedia.  Se centra en el diseño de aplicaciones distribuidas.
Usa protocolo HTTP GET, HTTP  POST, HTTP  PUT, HTTP DEL  Usa protocolo SMTP, HTTP POST, MQ
 Seguridad en HTTPS Seguridad en WS Securiy

Referencias:

http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf
http:// qbit.com.mx/blog/2012/02/14/rest-vs-soap
http://qode.pro/blog/web-services-rest-vs-soap/

 

Principios SOA

La función principa de los principios SOA es satisfacer con los objetivos de un negocio las cuales incluyen facilidad y flexibilidad de integración con sistemas legados, reduciendo costos de implementación, innovacion de servicios a clientes. Además permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización.

Para entender lo que realmente es SOA, es necesario revisar todos sus Principios:

  1. Contratos de servicio estandarizados: Es parte de la esencia misma de un servicio. Para que se considere un servicio,  su interfaz de entrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos  que forman parte de este interfaz deben estar correctamente tipados y ser conocidos. Con la ayuda de los estándares como WSDL y XSD, el contrato del servicio está autodescrito.
    Por consiguiente, los servicios web con un campo de entrada y otro de salida, en el que se inserta a su vez un XML como contenido (que no está descrito en ninguna parte) no puede considerarse un servicio web, a pesar de que parece que son los que más abundan.
  2. Servicios con bajo acoplamiento: Hace referencia al nivel de dependencia entre servicios, entre el proveedor y el consumidor. Cuanto menos acoplamiento se logra una mayor independencia para el diseño del servicio y su posterior evolución.
  3. Abstracción: este principio pone el enfásis en ocultar los detalles internos del servicio, tanto como sea posible. El servicio debe ser una caja negra, únicamente definido por su contrato, que a su vez es el mínimo acoplamiento posible con el consumidor del mismo
  4. Reusabilidad: como es conocido, la arquitectura SOA no busca la sustitución de las lógicas de negocio actuales sino que proporciona una forma de reaprovechar todos estos activos encapsulandolos en servicios para que a su vez puedan ser reutilizados por otros servicios.
  5. Autonomia: Este principio indica que el servicio tiene un alto grado de control sobre su entorno de ejecución y sobre la lógica que encapsula
  6. Sin estado: el tratamiento de una gran información de estado afectaría gravemente a la escalabilidad del servicio, poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el servicio para trabajar provienen de los parámetros de entrada.
  7. Capacidad de descubrimiento: al servicio se le dota de meta datos, gracias a los cuales puede ser descubierto de manera efectiva. Estos meta datos pueden ser interpretados de manera automática pudiendo ser reutilizados. Para ello es necesario disponer de un mecanismo de descubrimiento (llamado registro de servicios) como por ejemplo el UDDI.
  8. Composición: define la capacidad de un servicio para formar parte de un servicio más complejo. A medida de que la arquitectura SOA se consolide, los nuevos servicios (de más alto nivel) podrán implementarse a partir de los servicios de más bajo nivel ya existentes. La implementación de nuevos servicios se reducirá al mínimo y que los nuevos se crearán a partir de otros ya pre existentes.
  9. Interoperabilidad: este principio no formaba parte de los 8 principios originales ya que en realidad es una propiedad que forma parte de todos ellos.  Cada uno de los anteriores contribuye a la interoperabilidad de alguna manera. En las arquitecturas SOA, el problema de la falta de esta cualidad es uno de los más importantes. Hay que tener en cuenta que muchos de los servicios que intervienen se implementan con una tecnología diferente, incluso con un sistema operativo distinto.
    Por ejemplo, se puede tener un servicio realizado en Java ejecutándose sobre Linux que invoca a otro implementado en .net corriendo en una máquina con Windows. Históricamente las especificaciones que dan forma a los servicios web (como WSDL, SOAP, etc.) eran tan ambiguos que las dos partes estaban prácticamente condenadas a no entenderse. Iniciativas como el Basic Profile 1.0 han contribuido a eliminar estas ambiguedades, simplificando estos estándares, logrando que el consumidor y el proveedor del servicio puedan comunicarse entre sí.

 

 

Referencias

https://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
http://blog.powerdata.es/el-valor-de-la-gestion-de-datos/bid/394446/Los-principios-de-la-arquitectura-orientada-a-servicios
http://es.soapatterns.wikia.com/wiki/Principios_de_Dise%C3%B1o