| Artículos | 01 MAR 2002

¿Qué son los servicios Web?

Tags: Histórico
José M. Alarcón.
Desde hace unos meses esta expresión se oye por todas partes en el mundillo de la programación. En este artículo descubrirá qué son, cómo funcionan y qué los hace tan importantes.

La expresión “Servicio Web” se oye con fuerza desde hace unos meses en el ámbito del desarrollo de aplicaciones e incluso en el ambiente gerencial. Lo cierto es que no se trata de un concepto tan novedoso como cabría esperar y las innovaciones que conlleva no son tecnológicas, sino más bien conceptuales.
En este artículo explicaremos para el lector no técnico los conceptos relacionados con los servicios web, cómo funcionan, de dónde vienen y a dónde van, dejando para un segundo artículo las urdimbres tecnológicas de su implementación. Pero antes un poco de historia.

Modelos de desarrollo de aplicaciones
El hecho de poder comunicar componentes de software entre sí tiene una enorme importancia. Hasta no hace muchos años era muy típico hacer aplicaciones de una sola pieza, monolíticas. Estos programas (Figura 1) podían acceder a un sistema gestor de datos a través de la red, pero toda la lógica del flujo de datos, la seguridad y las interacciones con las personas se encontraban en el ordenador del usuario en forma de un gran ejecutable. La situación descrita no era la ideal, ya que implicaba problemas de toda índole a la hora de instalar las aplicaciones y, sobre todo, cuando se modificaban o actualizaban.
Una metodología de desarrollo mucho mejor, aunque más laboriosa a la hora de programar, es el modelo cliente/servidor en tres capas (Figura 2). En este modelo toda la lógica de los datos, su validación, los permisos, etc., residen en un servidor intermedio y son utilizados por todos los clientes a través de una red. En este caso en el ordenador del usuario lo único que hay es una capa de presentación que se ocupa básicamente de recoger y recibir datos, es decir, actúa de intermediario entre el usuario y las reglas de negocio residentes en la capa intermedia. Este modelo es más eficiente y está muy evolucionado respecto al anterior, pero aún se puede ir más allá.
La arquitectura de desarrollo en n-capas (n-tier, que dicen los anglosajones) lleva el concepto cliente/servidor un paso hacia adelante, dividiendo la capa intermedia en muchas otras capas especializadas, cada una de las cuales puede residir en un servidor diferente, tal y como se ilustra en la Figura 3. En este modelo existe una gran variedad de componentes especializados en tareas específicas como la validación de datos, la autenticación y la seguridad o el acceso a datos. Dichos componentes deben trabajar unos con otros como piezas de un mecanismo, gestionando la información que circula entre el usuario y el servidor de datos. La belleza de este modelo se basa en que cada uno de ellos (o cada grupo de ellos) puede residir en un servidor diferente, siendo transparente su ubicación para los clientes que los utilizan y aumentando mucho la escalabilidad de las aplicaciones, pues basta con añadir nuevos servidores e instalar los componentes en ellos para poder atender más peticiones. Por otra parte, y esto es muy interesante también, mientras sus interfaces de programación sean las mismas es posible sustituir cualquier componente por otro actualizado o que actúe de manera distinta para corregir errores o cambiar el modo de trabajo de la aplicación global, y todo ello sin que los clientes sean conscientes de ello. Obviamente esto ofrece más ventajas aún, ya que, por ejemplo, no es necesario reinstalar la aplicación en cada cliente, sino que basta con sustituir un componente en un único lugar y automáticamente todos los usuarios tendrán su aplicación actualizada.

Comunicación entre componentes
Conceptualmente, lo indicado en el párrafo anterior tiene muy buena pinta, pero existen varias dificultades técnicas a la hora de llevarlo a la práctica. Entre ellas están la comunicación entre las distintas capas y componentes que constituyen la aplicación, la gestión de peticiones y el balanceado de carga entre servidores cuando un mismo componente reside en varios de ellos (para aplicaciones muy grandes con muchos clientes), la gestión de transacciones entre componentes y algunas otras cosas más.
Existe la posibilidad de escribir un protocolo de comunicaciones propio que se ocupe de todas estas cuestiones, pero por supuesto se trata de una opción muy poco realista dada la complejidad que conllevaría. Para responder a estas necesidades de los programadores, diversos fabricantes y asociaciones de la industria crearon servicios y protocolos específicos orientados a la interacción distribuida de componentes. Aunque existe una gran variedad, de todos ellos los más importantes sin duda son:
· DCOM (Distributed Common Object Model), la propuesta de Microsoft, ligada a sus sistemas Windows. Se trata de algo más que un protocolo de invocación remota de procedimientos (RPC), ya que su última encarnación, COM+, incluye servicios avanzados para balanceado de carga, gestión de transacciones o llamadas asíncronas. Los parámetros son transmitidos a través de la red mediante un formato binario propio llamado NDR (Network Data Representation).
· RMI (Remote Method Invocation) es la metodología de llamada remota a procedimientos de Java. No se mete demasiado en la definición de interfaces para compatibilidad binaria de componentes, ni en otros conceptos avanzados, y se basa en la existencia de un cliente y un servidor que actúan de intermediarios entre los componentes que se quieren comunicar. Es una tecnología bastante sencilla que es fácil de utilizar.
· CORBA (Common Object Request Broker Architecture). Se trata de una serie de convenciones que describen cómo deben comunicarse los distintos componentes, cómo deben transferir los datos de las llamadas y sus resultados o cómo se describen las interfaces de programación de los componentes para que los demás sepan cómo utilizarlos. Fue desarrollado por el OMG (Object Management Group) en la segunda mitad de la década de 1990 y es el modelo que más éxito ha tenido entre los opositores a Microsoft, mayormente en el mundo UNIX. Su método de empaquetado y transmisión de datos a través de la red se llama CDR (Common Data representation).
Estos modelos son buenos y muy eficientes, pero tienen algunas pegas importantes, siendo dos las principales: es difícil la comunicación entre los distintos modelos y su utilización a través de Internet se complica debido a cuestiones de seguridad de las que enseguida hablaremos.
Existen en el mercado puentes CORBA/DCOM que permiten la comunicación entre componentes COM y componentes CORBA, pero su utilización es difícil y añaden una nueva capa de complejidad a las aplicaciones, además de disminuir su rendimiento.

El jabón lubrica los engranajes
Las expectativas actuales respecto a los componentes han aumentado. Al igual que podemos usar un navegador web para acceder a cualquier página independientemente del sistema operativo del servidor en que resida, ¿por qué no podríamos invocar métodos de componentes a través de la red independientemente de dónde se encuentren, del lenguaje en el que estén escritos y de la plataforma de computación en la que se ejecuten?
Esto es lo que ofrecen los servicios web. Gracias a ellos se derriban la antiguas divisiones resultantes de los modelos de compon

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información