1.

INTRODUCCIÓN
El diseño del software tiende a ser cada vez más modular. Las aplicaciones se componen de una
serie de componentes (servicios) reutilizables, que pueden encontrarse distribuidos a lo largo de
una serie de máquinas conectadas en red. Los Servicios Web nos permitirán distribuir nuestra
aplicación a través de Internet, pudiendo una aplicación utilizar los servicios ofrecidos por cualquier
servidor conectado a Internet. La cuestión clave cuando hablamos de servicios Web es la
interoperabilidad entre las aplicaciones.

Un Servicio Web es un componente al que podemos acceder mediante protocolos Web estándar,
utilizando XML para el intercambio de información. Normalmente nos referimos con Servicio Web
a una colección de procedimientos (métodos) a los que podemos llamar desde cualquier lugar de
Internet o de nuestra intranet, siendo este mecanismo de invocación totalmente independiente de
la plataforma que utilicemos y del lenguaje de programación en el que se haya implementado
internamente el servicio. Cuando conectamos con un servidor web desde nuestro navegador, el
servidor nos devuelve la página web solicitada, que es un documento que se mostrará en el
navegador para que lo visualice el usuario, pero es difícilmente entendible por una máquina.
Podemos ver esto como web para humanos. En contraposición, los Servicios Web ofrecen
información con un formato estándar que puede ser entendido fácilmente por una aplicación. En
este caso estaríamos ante una web para máquinas
 2. CLASIFICACION DE LOS SERVICIOS WEB
Un servicio web expone un conjunto de servicios para ser consumidos a través de la red. En
otras palabras, un servicio web específica un conjunto de operación (funciones que
retornan determinado valor, reciben un conjunto finito de parámetros, y retorna un
resultado), a través de una url, donde una aplicación Cliente remota los puede consumir
(podría haber cuestiones de seguridad en el medio). Cuando se expone un servicio web, se
publica un archivo wsdl en el servidor web, donde se muestran esas operaciones,
parámetros, tipos de retorno, dirección para invocar el servicio, etc.
Existe otro enfoque para el diseño de web service, denominado Restful, donde,
resumidamente, en vez de publicar operaciones, se publican identificadores de recursos,
para poder accederlos de forma remota. Un servicio web es una colección de protocolos
abiertos y estándares usados para el intercambio de datos entre aplicaciones o sistemas.
Software ejecutándose en distintas plataformas, y escritos en distintos lenguajes de
programación a través del uso de estos protocolos estándares se comunican entre sí. La
plataforma básica de los servidores es XML + HTTP.
2.1 XML-RPC
Protocolo simple basado en xml para el intercambio de información entre sistemas.
Los Requests son codificados en xml y enviados vía HTTP POST. Las respuestas son
embebidas en el cuerpo de la respuesta HTTP.
Propiedades de XML-RPC
• Diseñado para ser lo más simple posible, resolviendo solo una parte del problema,
pero resolviendo la parte más importante. Los no programadores pueden escribir
llamadas XML-RPC.
• Codifica mensajes para métodos de llamada y descripción, el resultado de las
llamadas a métodos con un vocabulario estándar utiliza XML.
• Tiene un vocabulario limitado de etiquetas XML para describir los tipos de
parámetros y el tipo de un valor de retorno de Una función.
• Utiliza HTTP como el transporte a través de internet.
• HTTP se usa normalmente para la comunicación de persona a persona entre un
navegador y un servidor usando HTML.
• XML-RPC usa HTTP para computadora a computadora o sea Comunicación sin
navegador involucrado.

Limitaciones de XML-RPC
• Elección limitada de los tipos de datos.
• No hay provisión para pasar objetos.
• Poca o ninguna seguridad, ya que los firewalls están anulados.
• No verifica que una estructura no tenga nombres duplicados.
• Las cuerdas solo permiten ASCII.

2.2 SOAP
Protocolo de comunicación basado en xml para intercambio de mensajes entre
sistemas. Especifica un formato para el intercambio de mensajes que es
independiente del lenguaje y de la plataforma. Es extensible, es desarrollado por la
W3C.
Actualmente un sin fin de empresas se han inclinado por el desarrollo de
aplicaciones que puedan trabajar sobre Internet porque permite la distribución
global de la información. Las tecnologías más usadas para el desarrollo de estas
aplicaciones, han sido hasta hace poco CORBA, COM y EJB. Cada una proporciona
un marco de trabajo basado en la activación de objetos remotos mediante la
solicitud de ejecución de servicios de aplicación a un servidor de aplicaciones.

Estas tecnologías han demostrado ser muy efectivas para el establecimiento de

sitios Web, sin embargo, presentan una serie de desventajas, como son total
incompatibilidad e interoperabilidad entre ellas, total dependencia de la máquina
servidora sobre la que corren, así como el lenguaje de programación. Esto ha llevado
a la necesidad de considerar un nuevo modelo de computación distribuida de
objetos que no sea dependiente de plataformas, modelos de desarrollo ni lenguajes
de programación. Por todos estos motivos surge el concepto de SOAP (Simple Object
Access Protocol).

La funcionalidad que aporta SOAP es la de proporcionar un mecanismo simple y

ligero de intercambio de información entre dos puntos usando el lenguaje XML.
SOAP no es más que un mecanismo sencillo de expresar la información mediante un
modelo de empaquetado de datos modular y una serie de mecanismos de
codificación de datos. Esto permite que SOAP sea utilizado en un amplio rango de
servidores de aplicaciones que trabajen mediante el modelo de comunicación RPC
(Remote Procedure Call). SOAP consta de tres partes:

• El SOAP envelope que define el marco de trabajo que determina qué se

puede introducir en un mensaje, quién debería hacerlo y si esa operación es
opcional u obligatoria.
• Las reglas de codificación SOAP que definen el mecanismo de serialización
que será usado para encapsular en los mensajes los distintos tipos de datos.
 • La representación SOAP RPC que define un modo de funcionamiento a la
hora de realizar llamadas a procedimientos remotos y la obtención de sus
resultados.
Objetivos de SOAP
A la hora de realizar el diseño de SOAP se han tenido en cuenta una serie de consideraciones
con el fin de cumplir una serie de objetivos claros, objetivos que le darán el potencial que
reside en SOAP y que le harán tan atractivo. Estos objetivos son:
• Establecer un protocolo estándar de invocación a servicios remotos que esté
basado en protocolos estándares de uso frecuente en Internet, como son
HTTP (Hiper Text Transport Protocol) para la transmisión y XML (eXtensible
Markup Language) para la codificación de los datos.
• Independencia de plataforma hardware, lenguaje de programación e
implementación del servicio Web.
El logro de estos objetivos ha hecho de SOAP un protocolo extremadamente útil, ya que el
protocolo de comunicación HTTP es el empleado para la conexión sobre Internet, por lo que
se garantiza que cualquier cliente con un navegador estándar pueda conectarse con un
servidor remoto. Además, los datos en la transmisión se empaquetan o serializan con el
lenguaje XML, que se ha convertido en algo imprescindible en el intercambio de datos ya
que es capaz de salvar las incompatibilidades que existían en el resto de protocolos de
representación de datos de la red.
Por otra parte, los servidores Web pueden procesar las peticiones de usuario empleando
tecnologías tales como Servlets, páginas ASP (Active Server Pages), páginas JSP (Java Server
Pages) o sencillamente un servidor de aplicaciones con invocación de objetos mediante
CORBA, COM o EJB.

2.3 WSDL
Es un formato estándar basado en xml para describir servicios web y mostrar cómo
acceder a ellos.

El lenguaje de descripción de servicios Web (WSDL, Web Service Description

Language) es un dialecto basado en XML sobre el esquema que describe un servicio
Web. Un documento WSDL proporciona la información necesaria al cliente para
interaccionar con el servicio Web. WSDL es extensible y se pude utilizar para
describir, prácticamente, cualquier servicio de red, incluyendo SOAP sobre HTTP e
incluso protocolos que no se basan en XML.
Dado que los protocolos de comunicaciones y los formatos de mensajes están
estandarizados en la comunidad Web, cada día aumenta la posibilidad e importancia
 de describir las comunicaciones de forma estructurada. WSDL afronta esta
necesidad definiendo una gramática XML que describe los servicios de red como
colecciones de puntos finales de comunicación capaces de intercambiar mensajes.
Las definiciones de servicio de WSDL proporcionan documentación para sistemas
distribuidos y sirven como fórmula para automatizar los detalles que toman parte
en la comunicación entre aplicaciones.

Los documentos WSDL definen los servicios como colecciones de puntos finales de
red o puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se
separa de la instalación concreta de red o de los enlaces del formato de datos. Esto
permite la reutilización de definiciones abstractas: mensajes, que son descripciones
abstractas de los datos que se están intercambiando y tipos de puertos, que son
colecciones abstractas de operaciones. Las especificaciones concretas del protocolo
y del formato de datos para un tipo de puerto determinado constituyen un enlace
reutilizable. Un puerto se define por la asociación de una dirección de red y un
enlace reutilizable; una colección de puertos define un servicio. Por esta razón, un
documento WSDL utiliza los siguientes elementos en la definición de servicios de
red:
• Types: contenedor de definiciones del tipo de datos que utiliza algún sistema
de tipos (por ejemplo, XSD).
• Message: definición abstracta y escrita de los datos que se están
comunicando.
• Operation: descripción abstracta de una acción admitida por el servicio.
• Port Type: conjunto abstracto de operaciones admitidas por uno o más
puntos finales.
• Binding: especificación del protocolo y del formato de datos para un tipo de
puerto determinado.
• Port: punto final único que se define como la combinación de un enlace y
una dirección de red.
• Service: colección de puntos finales relacionados.

2.4 UDDI
Descripción e integración del descubrimiento universal. Es un lenguaje estándar
basado en xml para describir, publicar y encontrar servicio web. Es independiente
de plataforma y puede comunicarse mediante SOAP, CORBA y JAVA.

La especificación UDDI simplifica esa tarea, permitiendo a una organización publicar

información sobre los servicios que ofrece y localizar información sobre servicios web que
necesita utilizar. Describe el interfaz externo de un Servicio Web y cómo utilizarlo. Se puede
definir un archivo WSDL como un documento XML que describe un conjunto de mensajes
 SOAP y la forma en que éstos se intercambian. Puesto que la notación que utiliza WSDL es
XML significa que es un idioma de programación neutral, basado en estándares (W3C) y que
puede utilizarse desde una gran variedad de plataformas y lenguajes.

Además de describir el contenido WSDL define todos los elementos necesarios para utilizar
el servicio (interfaz, lugar en el que está disponible, protocolo de comunicaciones, etc.).
UDDI es simplemente un repositorio de documentos XML (y un esquema) que define un
mensaje SOAP para el registro y petición de información. Un fichero de registro es un
documento XML-UDDI con tres partes principales:

• “páginas blancas”: especifican la dirección, contactos, e identificadores de empresa

• “páginas amarillas”: dan la categoría industrial basada en la taxonomía propuesta por
UDDI
• “páginas verdes”: contienen la información técnica que describe los servicios web.

Características de UDDI:

• UDDI es un sistema ideado para describir servicios (junto con WSDL) y localizar empresas
que ofrezcan estos servicios.
• UDDI significa “Descripción, Localización e Integración Universales”
• Es un directorio para almacenar información sobre servicios web; entre otra, guarda las
interfaces de esos servicios descritas en WSDL.
• UDDI utiliza SOAP para llevar a cabo las comunicaciones.
• Está desarrollado e integrado en la plataforma .NET de Microsoft.

3. REST (Representational state transfer)

REST deriva de "REpresentational State Transfer", que traducido vendría a ser

“transferencia de representación de estado”, lo que tampoco aclara mucho, pero contiene
la clave de lo que significa. Porque la clave de REST es que un servicio REST no tiene estado
(es stateless), lo que quiere decir que, entre dos llamadas cualesquiera, el servicio pierde
todos sus datos. Esto es, que no se puede llamar a un servicio REST y pasarle unos datos (p.
ej. un usuario y una contraseña) y esperar que “nos recuerde” en la siguiente petición. De
ahí el nombre: el estado lo mantiene el cliente y por lo tanto es el cliente quien debe pasar
el estado en cada llamada. Si quiero que un servicio REST me recuerde, debo pasarle quien
soy en cada llamada. Eso puede ser un usuario y una contraseña, un token o cualquier otro
tipo de credenciales, pero debo pasarlas en cada llamada. Y lo mismo aplica para el resto de
información. a. Principios de REST i. utiliza los métodos HTTP de manera explícita ii. no
mantiene estado iii. expone URIs con forma de directorios iv. transfiere XML, JavaScript
Object Notation (JSON), o ambos b. ¿Qué hace que un web service sea REST? i. Esta
asociados a información ii. Permiten listar, crear, leer, actualizar y borrar información iii.
Para las operaciones anteriores necesitan una URL y un método HTTP para accederlas iv.
Usualmente regresan la información en formato JSON. v. Retornan códigos de respuesta
HTML, por ejemplo 200, 201, 404, etc
 La especificación UDDI simplifica esa tarea, permitiendo a una organización publicar
información sobre los servicios que ofrece y localizar información sobre servicios
web que necesita utilizar. Describe el interfaz externo de un Servicio Web y cómo
utilizarlo. Se puede definir un archivo WSDL como un documento XML que describe
un conjunto de mensajes SOAP y la forma en que éstos se intercambian. Puesto que
la notación que utiliza WSDL es XML significa que es un idioma de programación
neutral, basado en estándares (W3C) y que puede utilizarse desde una gran variedad
de plataformas y lenguajes.

Además de describir el contenido WSDL define todos los elementos necesarios para
utilizar el servicio (interfaz, lugar en el que está disponible, protocolo de
comunicaciones, etc.). UDDI es simplemente un repositorio de documentos XML (y
un esquema) que define un mensaje SOAP para el registro y petición de información.
Un fichero de registro es un documento XML-UDDI con tres partes principales:

• “páginas blancas”: especifican la dirección, contactos, e identificadores de

empresa
• “páginas amarillas”: dan la categoría industrial basada en la taxonomía
propuesta por UDDI
• “páginas verdes”: contienen la información técnica que describe los servicios
web.
Características de UDDI
• UDDI es un sistema ideado para describir servicios (junto con WSDL) y
localizar empresas que ofrezcan estos servicios.
• UDDI significa “Descripción, Localización e Integración Universales”
• Es un directorio para almacenar información sobre servicios web; entre otra,
guarda las interfaces de esos servicios descritas en WSDL.
• UDDI utiliza SOAP para llevar a cabo las comunicaciones.
• Está desarrollado e integrado en la plataforma .NET de Microsoft.

2.5 REST (Representational state transfer)

REST deriva de "REpresentational State Transfer", que traducido vendría a ser “transferencia de
representación de estado”, lo que tampoco aclara mucho, pero contiene la clave de lo que
significa. Porque la clave de REST es que un servicio REST no tiene estado (es stateless), lo que
quiere decir que, entre dos llamadas cualesquiera, el servicio pierde todos sus datos. Esto es,
que no se puede llamar a un servicio REST y pasarle unos datos (p. ej. un usuario y una
contraseña) y esperar que “nos recuerde” en la siguiente petición. De ahí el nombre: el estado
lo mantiene el cliente y por lo tanto es el cliente quien debe pasar el estado en cada llamada. Si
quiero que un servicio REST me recuerde, debo pasarle quien soy en cada llamada. Eso puede
 ser un usuario y una contraseña, un token o cualquier otro tipo de credenciales, pero debo
pasarlas en cada llamada. Y lo mismo aplica para el resto de información.

a. Principios de REST

i. utiliza los métodos HTTP de manera explícita

ii. no mantiene estado
iii. expone URIs con forma de directorios
iv. transfiere XML, JavaScript Object Notation (JSON), o ambos

b. ¿Qué hace que un web service sea REST?

i. Esta asociados a información

ii. Permiten listar, crear, leer, actualizar y borrar información
iii. Para las operaciones anteriores necesitan una URL y un método HTTP para
accederlas.
iv. Usualmente regresan la información en formato JSON.
v. Retornan códigos de respuesta HTML, por ejemplo 200, 201, 404, etc.

3. conclusiones

 Hay alternativas para las tecnologías propietarias mayores que dominan el mercado. Por
ejemplo: una combinación de XWT con PHP por medio de XML-RPC, podría reemplazar
una aplicación de Visual Studio .NET, aligerando el costo de las licencias.
 En el momento que decidimos desarrollar nuestros servicios web, tenemos que tomar la
decisión de que arquitectura será la más apropiada para nuestro sistema y el uso que
vayamos a darle.

4. Referencias bibliográficas.

 http://andyramosb.blogspot.com/2012/12/web-services-rest-vs-soap.html
 http://www.esi.uclm.es/www/mpolo/serviciosWeb.pdf
 http://www.unilibre.edu.co/revistaavances/avances_10/r10_art7.pdf
 https://desarrolloweb.com/articulos/que-es-rest-caracteristicas-sistemas.html
 https://www.google.com/amp/s/eamodeorubio.wordpress.com/2010/07/26/servicios-
web-2-¿que-es-rest/amp/