Solución al mal concepto entre: servicio, web service, rest y aplicación

Actualmente existe una problemática muy grande relacionada con la conceptualización y terminología enfocada a algunos terminos soa & eai.

Introducción

El presente artículo trata de dar a conocer una realidad que actualmente muchos profesionales de TI, directamente relacionados a los diferentes rubros como Telecomunicaciones, entre otros y así mismo áreas como: Integración, Arquitectura, etc., tienen en sus trabajos del día a día muchos problemas al momento de comunicarse entre ellos y/o sus empresas outsourcing con las cuales tercerizan actividades de proyectos, debido a un incorrecto entendimiento a nivel de conceptos enfocados a SOA / EAI.

Antecedentes

Todo nace muchos años atrás cuando lo que se conoce como ‘Aplicaciones Distribuidas’ se empezaron a poner de moda como, para brindar solución para la comunicación entre aplicaciones Monolíticas que era el estándar de aquellos tiempos. Dichas arquitecturas Monolíticas manejaban un modelo de lógica cliente-servidor, esto quiere decir que las ejecuciones de los mensajes eran lanzadas desde un aplicativo cliente hacia un aplicativo servidor quien los recibía, procesaba y respondía en una misma red.

La problemática que se encontraba era que toda la lógica de negocio era encapsulada de manera completa en una misma aplicación (grandes procesos completos dentro de una misma aplicación), esto quiere decir que el concepto de servicios de Presentación, Negocio, Utilitario simplemente a nivel de arquitectura no existía y generaban bastantes problemas en lo relacionado al procesamiento, memoria, mantenimiento y rendimiento respectivamente.

Posteriormente, con el concepto de distribución más maduro, se desarrollaron soluciones como CORBA (Object Request Broker Architecture), RMI (Remote Method Invocation), entre otras, que en su momento fueron mecanismos con enfoque distribuido para invocar y/o ejecutar procedimientos de manera remota hacia computadoras o servidores. Así mismo, es imposible pensar que para las empresas era lo mejor el tener una sola computadora y/o servidor en el cual se tenga que desplegar todo, debido a ello este enfoque era lo mejor de la época.

Actualidad:

En la actualidad debido a que las empresas tienen la tendencia a la globalización y a tener todas sus aplicaciones integradas, con respuestas rápidas y optimas han nacido nuevas arquitecturas así como metodologías, marcos de trabajo y patrones que alientan y apoyan los conceptos de las aplicaciones distribuidas, es así como nace EAI (Enterprise Application Integration), SOA (Service Oriented Architecture), ESB (Enterprise Service, Bus) y Microservices, las cuales diferentes vendors como: IBM, ORACLE, REDHAT apoyan e implementan diferentes soluciones y suites para facilitar el aplicar más fácilmente dichos conceptos.

Estas arquitecturas actuales, tienen como base lo que se conoce como ‘servicio’ y de este nombre se desencadenan una serie de conceptos que muy usualmente los profesionales de tecnología suelen tener muchos problemas, ya sea en entender dichos conceptos, así mismo en cómo aplicarlos en sus trabajos, conversaciones, etc.

¿Porque se da esto?, muchas veces porque provienen de empresas que desarrollan software en modo factory y no acostumbran mucho al trabajo 100% middleware, o por otro lado, son parte de empresas que han migrado de arquitectura de una versión Monolítica a una versión Distribuida (aplicando alguna de estas arquitecturas), y no les han sabido explicar los conceptos base y/o las diferencias entre dichos conceptos, para manejarlos correctamente (en muchos casos solo lo asumen).

¿Cuáles son las consecuencias de esta problemática?, las consecuencias serían que dichos conceptos erróneos lo tratan de aplicar en el día a día, pensando que es el correcto y si incluso asumen posteriormente algún cargo superior, fuerzan que se maneje dichos conceptos, no porque estén bien, sino porque ellos así los entienden y es no es lo correcto. En mi experiencia de más de 10 años trabajando en el rubro de Telecomunicaciones, por ejemplo se da mucho este problema en lo relacionado a tocar el tema de: Servicio, Web Service, Rest, Aplicación, Soap. Muchos colegas ingenieros ya sean: Consultores, Arquitectos, Funcionales, Jefes de Proyectos, etc, utilizan estas definiciones muy por usar, aparentemente sin conocer la realidad de cada uno y a que están enfocados, y lo que hacen es por ejemplo para hablar de un Servicio, mencionan WebService, o para hacer referencia a un WebService de un tipo específico lo llaman como Aplicación, para hablar de una arquitectura SOA mencionan SOAP y confunden cuando hablar sobre Rest o Restful, etc. y eso está mal.

El objetivo de este artículo es justamente dar a conocer las diferencias entre estas definiciones, para que los que aún tienen problemas con dichos conceptos, sepan aplicarlos correctamente al explicar y/o graficar sus arquitecturas, documentos de diseño o simplemente saber expresarse para hacerse entender correctamente a futuro.

A continuación detallaré con mis propias palabras, el concepto utilizado a nivel de TELCOS y en realidad el estándar que debería ser utilizado en cualquier rubro respectivamente que trabaje con dichos conceptos:

Aplicación:

Una Aplicación hace referencia al software que interactúa con el usuario por medio una interface gráfica (Front-end), esta puede estar construida en cualquier lenguaje de programación como JAVA o .NET (últimamente: Angular JS + Bootstrap). En una Arquitectura SOA las Aplicaciones son las encargadas de interactuar por medio de la ejecución de sus componentes HTML (Links, Botones, etc), con servicios pertenecientes a ‘Inventario de Servicios’ expuestos por detrás.

Servicio:

Un Servicio debe ser considerado como un ‘activo de la empresa’, así mismo como Servicio a nivel de tecnología puede ser considerado por ejemplo: un WebService, un EJB, un MDB, etc. El objetivo es que cumplan la meta para los que fueron construidos y así mismo sigan sobre todo los principios SOA. Finalmente, es importante saber que un Servicio base a su tipo (muy independientemente del lenguaje en que se desarrolle: JAVA, BPEL) pueden ser de tipo:

  • Presentación: Servicios que dan la cara a la aplicación (No tienen lógica de negocio), redireccionan.
  • Negocio: Servicios que orquestan a nivel de sus flujos, la lógica de negocio definida para el proceso.
  • Utilitario: Servicios que su objetivo es la reutilización, para el acceso a BackEnd y/o funcionalidades por ejemplo: BD, Plataformas Legacy, Envío de correos, Generación de logs, etc (No tienen lógica de negocio), aquí entran a tallar como parte de este tipo los conceptos de servicios de: ‘’Conectividad’ y ‘Datos’.

Webservice:

Un Webservice es un tipo de Servicio, basada en una tecnología que utiliza una serie de protocolos para intercambiar mensajes. Estos protocolos son: SOAP & REST. Así mismo, los Webservice no proveen al usuario una interfaz gráfica (GUI), en vez de ello, los Webservice exponen la información requerida por medio de una interfaz a través de la red.

Los Webservice permiten a distintas aplicaciones, de diferentes orígenes, en diferentes ambientes comunicarse entre ellos, así mismo no están ligados a ningún Sistema Operativo o Lenguaje de Programación.

SOAP:

SOAP (Simple Object Access Protocol) es un protocolo para el manejo de Webservice el cual está basado XML y su objetivo es la comunicación entre servicios los cuales tengan expuesto con contratos (WSDL: Web Services Description Language). Actualmente, si hablamos de este protocolo me sabe que pueden exponer dos tipos: SOAP 1.1 o SOAP 1.2, así mismo manejar una comunicación varios tipos que son: Síncrono, Asíncrono y Oneway (XML en realidad).

En la imagen se muestra cómo evolucionó una arquitectura SOA, la cual anteriormente cuando no se conocía el concepto del bus de servicios (ESB), toda la comunicación era en modo: Punto a Punto (no estaba controlada), ya posteriormente con la entrada del ESB, todo cambio y ese era el encargado de la comunicación, seguridad, redireccionamiento, exposición, etc.

REST:

REST (Representational State Transfer) es un protocolo para el manejo de Webservice el cual trabaja sobre HTTP. Así mismo, dicho protocolo puede manejar una comunicación basada en XML & JSON (Formatos distintos), exponer URIs y de manejar si se requiere un contrato similar al del protocolo SOAP (WSDL), que es conocido como WADL (Web Application Description Language), que facilita el Topdown al momento de generar un servicio. Lo único malo es que dicho contrato WADL no es 100% estándar debido a ellos, muchas apis no brindan internamente el soporte respectivo. Dicha arquitectura por ser ligera es muy utilizada en la comunicación de aplicaciones de tipo Mobile.

RESTful:

RESTful consiste en el manejo de webservice pero aplicando en su comunicación el protocolo REST, pero correctamente esto quiere decir que para que se le reconozca que se está aplicando RESTful se daría únicamente si llegara a cumplir en su manejo con las operaciones estándar: GET, POST, PUT, DELETE, etc.

Conclusiones:

Se ha tratado de explicar de la manera más amigable las diferentes definiciones usadas en el trabajo con Aplicaciones Distribuidas basadas en SOA / EAI, que usualmente generan controversia para su entendimiento.

El asumir y manejar un mal entendimiento de algunos conceptos base, puede ser contraproducente y mal visto por las empresas que si conocen el concepto.

El objetivo es que el nivel de entendimiento de las organizaciones y profesionales de TI tengan claro los conceptos, esto para que por ambas partes hablen el mismo idioma y de esta manera puedan realizar mejor sus trabajos y/o proyectos en el día a día.

Referencias

https://laurmolina7821.files.wordpress.com

https://encrypted-tbn0.gstatic.com

http://2.bp.blogspot.com

http://temariotic.wikidot.com

http://lapastillaroja.net

http://4.bp.blogspot.com

Tags

What other's say about : Solución al mal concepto entre: servicio, web service, rest y aplicación


eli

marzo 17, 2018 Responder

REST (Representational State Transfer) es un estilo de arquitectura de software para
sistemas hipermedias distribuidos tales como
la Web. El término fue introducido en la
tesis doctoral de Roy Fielding en 2000, quien es uno de los principales autores de la
especificación de HTTP.
No es como tal un protocolo.

admin

admin

marzo 20, 2018 Responder

Hola Eli,

Es correcto, REST es un tipo de Arquitectura de Software, tecnologías como HTTP y RESTful son construidas utilizando esta arquitectura.

Deja un comentario


*