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.

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.

Para que esto se cumpla, debemos entender que cuando visitamos una página web desde
nuestro navegador, es en realidad un servidor web el que envía los componentes
individuales de dicha página directamente a nuestro ordenador. Esto quiere decir que
para que una página web sea accesible en cualquier momento, el servidor web debe estar
permanentemente online.

Toda página accesible en Internet necesita un servidor especial para sus contenidos web.
A menudo, las grandes empresas y organizaciones cuentan con un servidor web propio
para disponer sus contenidos en Intranet e Internet. Sin embargo, la mayoría de
administradores recurren a los centros de datos de proveedores de alojamiento web para
sus proyectos. Independientemente de si tenemos un servidor web propio o de si
alquilamos uno externo, siempre necesitaremos un software para gestionar los datos de
nuestra página y mantenerla actualizada. En este sentido, tienes la posibilidad de elegir
entre varias soluciones de software para servidores web diseñadas para diferentes
aplicaciones y sistemas operativos.
 MODULO II: SERVICIOS WEB

¿Qué es un Servicio Web?

Un Servicio Web es un componente al que podemos acceder mediante protocolos Web

estándar que actúan como intermediarios entre dos o más maquinas, utilizando XML para
el intercambio de información.

Cuando conectamos a 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.

Para entenderlo mejor, una de las principales funcionalidades que proporcionan los
servicios web, es el intercambio masivo de información. Este servicio proporciona una
puerta de entrada o salida de información a la empresa que los implementa. Nos
podemos encontrar por ejemplo con grandes corporaciones que ya los implementan.
Facebook, Google y Microsoft, entre otras.

Aunque parezca que esto queda muy lejos del usuario de a pie, sin darnos cuenta estamos
utilizando estas herramientas con el simple hecho de realizar el inicio de sesión en una
aplicación a través de nuestra red social favorita, por ejemplo, cuando iniciamos se Inicia
sesión en Facebook.
Características de los Servicios Web

Las características deseables de un Servicio Web son:

 Un servicio debe poder ser accesible a través de la Web. Para ello debe utilizar
protocolos de transporte estándares como HTTP, y codificar los mensajes en un
lenguaje estándar que pueda conocer cualquier cliente que quiera utilizar el
servicio.
 Un servicio debe contener una descripción de sí mismo. De esta forma, una
aplicación podrá saber cuál es la función de un determinado Servicio Web, y cuál
es su interfaz, de manera que pueda ser utilizado de forma automática por
cualquier aplicación, sin la intervención del usuario.
 Debe poder ser localizado. Deberemos tener algún mecanismo que nos permita
encontrar un Servicio Web que realice una determinada función. De esta forma
tendremos la posibilidad de que una aplicación localice el servicio que necesite de
forma automática, sin tener que conocerlo previamente el usuario.

Arquitectura de capas de protocolos

Los protocolos utilizados en los Servicios Web se organizan en una serie de capas:

Capa Descripción

Es la capa que se encarga de transportar los mensajes entre

aplicaciones. Normalmente se utiliza el protocolo HTTP para
Transporte de servicios este transporte, aunque los servicios web pueden viajar
mediante otros protocolos de transferencia de hipertexto
como SMTP, FTP o BEEP.

Es la capa responsable de codificar los mensajes en XML de

Mensajería XML forma que puedan ser entendidos por cualquier aplicación.
Puede implementar los protocolos XML-RPC o SOAP.

Descripción de servicios Se encarga de definir la interfaz pública de un determinado

 servicio. Está definición se realiza mediante WSDL.

Se encarga del registro centralizado de servicios,

Localización de servicios permitiendo que estos sean anunciados y localizados. Para
ello se utiliza el protocolo UDDI.

Ventajas y Desventajas de los servicios web

La ventaja principal de los servicios web es que la comunicación no depende de una

plataforma determinada, por lo que el cliente y el servidor apenas han de presentar
rasgos en común para poder comunicarse. Para ello, la tecnología web service recurre a
formatos estandarizados que interpretan todos los sistemas.

Pero en estos formatos es donde encontramos una de las desventajas. Precisamente, XML
es un formato más bien voluminoso que genera grandes paquetes de datos, lo que puede
crear problemas en las conexiones de red lentas. Otra posibilidad que permite conectar a
dos sistemas a través de Internet es las API web. Aunque, por lo general, son más rápidas,
someten a cliente y servidor a especificaciones más concretas, con lo que la
interoperabilidad se ve limitada.

¿Cómo funciona un servicio web?

Cuando se utiliza un servicio web, un cliente manda una solicitud a un servidor,
desencadenando una acción por parte de este. A continuación, el servidor devuelve una
respuesta al cliente.

Sin embargo, para que esta comunicación sea posible, los servicios web estandarizados
hacen uso de los siguientes componentes:

XML (Extensible Markup Language): La sigla XML podría traducirse como “Lenguaje de
Marcas Extensible”. Se trata de un lenguaje utilizado para estructurar la información en
cualquier documento que contenga texto como por ejemplo los archivos de configuración
de una aplicación específica o una base de datos. Sin embargo, XML no es un lenguaje de
marcado.

La razón de su popularidad, que se ha acrecentado a lo largo de los últimos años, se debe

al hecho de ser un estándar abierto y además libre, creado por W3C, el consorcio World
Wide Web, los mismos creadores de la WWW.
¿Para qué sirve XML?

Básicamente XML es un meta-lenguaje que nos brinda la posibilidad de definir lenguajes

de marcado adecuados a las aplicaciones en la que lo vamos a usar. Este meta-lenguaje
proviene de un estándar llamado SGML (Estándar Generalised Mark-up Language), un
protocolo para definir lenguajes de marcado desarrollado por la prestigiosa IBM a
principios de la década de 1970, con el propósito de cubrir la necesidad de compartir
grandes volúmenes de información con otras plataformas de software y sistemas
operativos de forma sencilla, segura y sobre todo fiable.

Mediante la implementación del estándar XML el usuario puede definir sus propios
marcadores, como por ejemplo, el llamado “CDF” (Channel Definition Format), que fue
integrado a Microsoft Internet Explorer en su versión 4 constituye una aplicación XML.

Sin embargo, la implementación más usual del estándar XML es utilizarlo para definir la
estructura de los documentos. El lenguaje XML no sólo fue diseñado para su aplicación en
servicios web, sino que también es un estándar para el intercambio de información entre
diferentes instancias. Puede ser utilizado para estructurar bases de datos, editores de
texto u hojas de cálculo. XML representa la interfaz ideal entre las páginas web y las bases
de datos.

Si bien la tecnología XML es muy sencilla, lo cierto es que su principal característica es la

poder complementar otras tecnologías y complementarse con otras tecnologías, hechos
que sin dudas la convierten en una herramienta perfecta para crecer de acuerdo a las
necesidades de cada proyecto, una perspectiva de mucho peso en la actualidad.

Es por ello que hoy XML es el complemento necesario para que todo funcione del modo
en que lo conocemos y queremos que funcione.
Características de XML

Como sabemos, el estándar XML básicamente trata de un conjunto de reglas desarrolladas

para permitir trabajar con grandes volúmenes de datos de una forma que sea sencilla para
la computadora y los programas que utilicen estos datos. Es por ello que ha tenido tanto
éxito en su implementación en todo tipo de apps y servicios en donde se trate con mucha
información, como por ejemplo una base de datos.

Sin duda alguna, la mejor característica de XML reside en su diseño, el cual ha sido
enfocado desde un principio para asegurar un excelente desempeño, simplicidad de
implementación y sencillez de uso en servicios de la web, logros que alcanzó con absoluto
éxito, sobre todo en el ámbito de la publicación de medios electrónicos a gran escala.

Para conseguir este objetivo, fue fundamental que el formato elegido fuera el de texto,
hecho que posibilita que el contenido de los documentos XML sea entendible tanto para
las personas como para los dispositivos. Además ofrece soporte para todos los idiomas, lo
que sin dudas permitió que se expandiera tan rápida en que lo hizo.

Sin embargo, XML ofrece otras características, todas tan importantes e interesantes como
las mencionadas,tales como:
 Es una arquitectura más abierta y extensible. No se necesita versiones para que
puedan funcionar en futuros navegadores. Los identificadores pueden crearse de
manera simple y ser adaptados en el acto en internet/intranet por medio de un
validador de documentos (parser.
 Mayor consistencia, homogeneidad y amplitud de los identificadores descriptivos
del documento con XML (los RDF Resource Description FrameWork), en
comparación a los atributos de la etiqueta del HTML.
 Integración de los datos de las fuentes más dispares. Se podrá hacer el intercambio
de documentos entre las aplicaciones tanto en el propio PC como en una red local
o extensa.
 Datos compuestos de múltiples aplicaciones. La extensibilidad y flexibilidad de este
lenguaje nos permitirá agrupar una variedad amplia de aplicaciones, desde páginas
web hasta bases de datos.
 Gestión y manipulación de los datos desde el propio cliente web.
 Los motores de búsqueda devolverán respuestas más adecuadas y precisas, ya que
la codificación del contenido web en XML consigue que la estructura de la
información resulte más accesible.
 Se desarrollarán de manera extensible las búsquedas personalizables y subjetivas
para robots y agentes inteligentes. También conllevará que los clientes web
puedan ser más autónomos para desarrollar tareas que actualmente se ejecutan
en el servidor.
 Se permitirá un comportamiento más estable y actualizable de las aplicaciones
web, incluyendo enlaces bidireccionales y almacenados de forma externa (El
famoso epígrafe "404 file not found" desaparecerá).
 El concepto de "hipertexto" se desarrollará ampliamente (permitirá denominación
independiente de la ubicación, enlaces bidireccionales, enlaces que pueden
especificarse y gestionarse desde fuera del documento, hiperenlaces múltiples,
enlaces agrupados, atributos para los enlaces, etc. Creado a través del Lenguaje de
enlaces extensible (XLL).
  Exportabilidad a otros formatos de publicación (papel, web, cd-rom, etc.). El
documento maestro de la edición electrónica podría ser un documento XML que se
integraría en el formato deseado de manera directa.

Las ventajas de XML

Las ventajas que nos ha ofrecido XML a través de su implementación son muchas y muy
valiosas, tanto para los desarrolladores como para los usuarios, ya que mientras los
primeros pueden sacar una amplia ventaja de su implementación para que las cosas sean
más simples y rápidas, los segundos disfrutan de estas mejores cada día en sus
aplicaciones.

Otra ventaja de XML es que al tratarse de un estándar que posibilita la

internacionalización, permite la utilización de diversos juegos de caracteres, algo
fundamental en la idea de la globalización. También es un estándar abierto, por lo cual no
tiene ningún tipo de restricción de licencias.

Algunos de los motivos que llevaron al desarrollo del estándar XML eran la necesidad de
implementar mejoras en el uso de HTML, sobre todo en los temas relacionados con los
estilos aplicados en los sitios, los problemas y limitaciones que existían cuando se tenía
que compartir datos entre diferentes dispositivos tales como computadoras y
smartphones, y además las dificultades que había para mostrar la información contenida
en la implementación en diferentes tipos de navegadores o aplicaciones que necesitaran
visualizar estos datos, para que en todos ellos se pudieran visualizar del mismo modo.

Ejemplo de XML
Supongamos que tenemos un pequeño negocio de venta de videojuegos nuevos y usados,
y estamos almacenando una lista con detalles de los juegos en nuestro catálogo:

1. <negocio>
2. <videojuego estado="nuevo">
3. <titulo>Dragon Quest IX</titulo>
4. <desarrolladora>Level 5</desarrolladora>
5. </videojuego>
6. </negocio>

En el ejemplo anterior se utilizó jerarquía para almacenar información. La raíz de los datos
es la etiqueta <negocio>; luego tenemos un elemento con un atributo en la etiqueta
<videojuego> y el atributo estado=»nuevo»; finalmente, las etiquetas <titulo> y
<desarrolladora> contienen información en forma de texto.

 WSDL (Web Services Description Language): es una descripción basada en XML de

los requisitos funcionales necesarios para establecer una comunicación con los
servicios web publicados. Una definición WSDL indica a un cliente cómo componer
una solicitud de servicio y describe la interfaz.
El fichero WSDL describirá la interfaz del Servicio Web, con los métodos a los que
podemos invocar, los parámetros que debemos proporcionarles y los tipos de
datos de dichos parámetros.
Si desarrollamos un Servicio Web, y queremos que otras personas sean capaces de
utilizar nuestro servicio para sus aplicaciones, podremos proporcionar un
documento WSDL describiendo nuestro servicio. De esta forma, a partir de este
documento otros usuarios podrán generar aplicaciones clientes en cualquier
plataforma (ya que WSDL se define como un estándar) que se ajusten a nuestro
servicio.
El elemento raíz dentro de este fichero es definitions, donde se especifican los
espacios de nombres que utilizamos en nuestro servicio. Dentro de este elemento
raíz encontramos los siguientes elementos:
  types: Se utiliza para definir los tipos de datos que se intercambiarán en el
mensaje.
 message: Define los distintos mensajes que se intercambiaran durante el proceso
de invocación del servicio. Se deberán definir los mensajes de entrada y salida para
cada operación que ofrezca el servicio. En el caso de mensajes RPC, en el mensaje
de entrada se definirán los tipos de parámetros que se proporcionan, y en el de
salida el tipo del valor devuelto.
 portType: Define las operaciones que ofrece el servicio. De cada operación indica
cuales son los mensajes de entrada y salida, de entre los mensajes definidos en el
apartado anterior.
 binding: Indica el protocolo y el formato de los datos para cada mensaje de los
definidos anteriormente. Este formato puede ser orientado al documento u
orientado a RPC. Si es orientado al documento tanto el mensaje de entrada como
el de salida contendrán un documento XML. Si es orientado a RPC el mensaje de
entrada contendrá el método invocado y sus parámetros, y el de salida el resultado
de invocar dicho método.
 service: Define el servicio como una colección de puertos a los que se puede
acceder. Un puerto es la dirección (URL) donde el servicio actúa. Esta será la
dirección a la que las aplicaciones deberán conectarse para acceder al servicio.
Además contiene la documentación en lenguaje natural del servicio.

Un documento WSDL de ejemplo es el siguiente:

<?xml version="1.0" encoding="utf-8" ?>

<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://rvg.ua.es/wsdl"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://rvg.ua.es/wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="getTempRequest">
<part name="string_1"
xmlns:partns="http://www.w3.org/2001/XMLSchema"
type="partns:string" />
</message>
<message name="getTempResponse">
<part name="double_1"
xmlns:partns="http://www.w3.org/2001/XMLSchema"
type="partns:double" />
</message>
<portType name="TempPortType">
<operation name="getTemp">
<input message="tns:getTempRequest" />
<output message="tns:getTempResponse" />
</operation>
</portType>
<binding name="TempPortSoapBinding" type="tns:TempPortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="getTemp">
<soap:operation soapAction="" style="rpc" />
<input>
<soap:body use="encoded"
namespace="http://rvg.ua.es/wsdl"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/" />
</input>
<output>
<soap:body use="encoded"
namespace="http://rvg.ua.es/wsdl"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/" />
</output>
</operation>
</binding>
<service name="Temp">
<documentation>Documentacion</documentation>
<port name="TempPort" binding="tns:TempPortSoapBinding">
<soap:address
location="http://localhost:7001/sw_temp/Temp" />
</port>
</service>
</definitions>

En el que se define un servicio que proporciona el método getTemp, que toma como
parámetro una cadena con el nombre del área que queremos consultar, y nos devuelve un
valor real.
En los elementos message vemos que tenemos dos mensajes: los mensajes de entrada y
salida de la operación getTemp de nuestro servicio. El mensaje de entrada contiene un
dato de tipo string (el parámetro del método), y el de salida es de tipo double (la
temperatura que devuelve el servicio).

El elemento portType define la operación getTemp a partir de los mensajes de entrada y

salida que la componen, y en binding se establece esta operación como de tipo RPC y se
indica la codificación de estos mensajes.

Por último en el apartado service se especifica el puerto al que podemos conectar para
usar el servicio, dando la URL a la que nuestro cliente deberá acceder.

SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): es una
serie de protocolos estándar sobre los que se establece el intercambio de datos mediante
XML.

Normalmente utilizaremos SOAP para conectarnos a un servicio e invocar métodos

remotos, aunque puede ser utilizado de forma más genérica para enviar cualquier tipo de
contenido. Podemos distinguir dos tipos de mensajes según su contenido:

 Mensajes orientados al documento: Contienen cualquier tipo de contenido que

queramos enviar entre aplicaciones.
 Mensajes orientados a RPC: Este tipo de mensajes servirá para invocar
procedimientos de forma remota (Remote Procedure Calls). Podemos verlo como
un tipo más concreto dentro del tipo anterior, ya que en este caso como contenido
del mensaje especificaremos el método que queremos invocar junto a los
parámetros que le pasamos, y el servidor nos deberá devolver como respuesta un
mensaje SOAP con el resultado de invocar el método.

El protocolo SOAP tiene tres características principales:

  Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).
 Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transporte
como HTTP, SMTP, TCP o JMS).
 Independencia (SOAP permite cualquier modelo de programación).

Cuando hablamos de Servicios Web normalmente nos referimos a RPC, por lo que nos
centraremos en este tipo de mensajes.

Puede ser utilizado sobre varios protocolos de transporte, aunque está especialmente
diseñado para trabajar sobre HTTP.

Dentro del mensaje SOAP podemos distinguir los siguientes elementos:

 Un sobre (Envelope), que describe el mensaje, a quien va dirigido, y cómo debe ser
procesado. El sobre incluye las definiciones de tipos que se usarán en el
documento. Contiene una cabecera de forma opcional, y el cuerpo del mensaje.
 Una cabecera (Header) opcional, donde podemos incluir información sobre el
mensaje. Por ejemplo, podemos especificar si el mensaje es obligatorio (debe ser
entendido de forma obligatoria por el destinatario), e indicar los actores (lugares
por donde ha pasado el mensaje).
 El cuerpo del mensaje (Body), que contiene el mensaje en sí. En el caso de los
mensajes RPC se define una convención sobre cómo debe ser este contenido, en el
 que se especificará el método al que se invoca y los valores que se pasan como
parámetros. Puede contener un error de forma opcional.
 Un error (Fault) en el cuerpo del mensaje de forma opcional. Nos servirá para
indicar en una respuesta SOAP que ha habido un error en el procesamiento del
mensaje de petición que mandamos.

Hemos visto como los mensajes SOAP nos sirven para intercambiar cualquier documento
XML entre aplicaciones. Pero puede ocurrir que necesitemos enviar en el mensaje datos
que no son XML, como puede ser una imagen. En ese caso tendremos que recurrir a la
especificación de mensajes SOAP con anexos.

Los mensajes SOAP con anexos añaden un elemento más al mensaje:

 El anexo (Attachment), puede contener cualquier tipo de contenido (incluido el

XML). De esta forma podremos enviar cualquier tipo de contenido junto a un
mensaje SOAP.

Nuestro mensaje podrá contener tantos anexos como queramos.

Un ejemplo de mensaje SOAP es el siguiente:

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns:getTemperatura xmlns:ns="http://rvg.ua.es/ns">
<area>Alicante</area>
</ns:getTemperatura>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

En él estamos llamando a nuestro método getTemperatura para obtener información

meteorológica, proporcionando como parámetro el área de la que queremos obtener la
temperatura.

Algunas de las Ventajas de SOAP son:

 No está asociado con ningún lenguaje: los desarrolladores involucrados en nuevos

proyectos pueden elegir desarrollar con el último y mejor lenguaje de
programación que exista pero los desarrolladores responsables de mantener
antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el
lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la
implementación de la API se deja al lenguaje de programación, como en Java, y la
plataforma como Microsoft .Net.
 No se encuentra fuertemente asociado a ningún protocolo de transporte: La
especificación de SOAP no describe como se deberían asociar los mensajes de
SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo
que puede transportarse utilizando cualquier protocolo capaz de transmitir texto.
 No está atado a ninguna infraestructura de objeto distribuido La mayoría de los
sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos
para que admitan SOAP.
 Aprovecha los estándares existentes en la industria: Los principales
contribuyentes a la especificación SOAP evitaron, intencionadamente, reinventar
las cosas. Optaron por extender los estándares existentes para que coincidieran
con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los
mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la
especificación esquema de XML. Y como ya se ha mencionado SOAP no define un
medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a los
protocolos de transporte existentes como HTTP y SMTP.
 Permite la interoperabilidad entre múltiples entornos: SOAP se desarrolló sobre
los estándares existentes de la industria, por lo que las aplicaciones que se
ejecuten en plataformas con dicho estándares pueden comunicarse mediante
mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo,
una aplicación de escritorio que se ejecute en una PC puede comunicarse con una
aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir
XML sobre HTTP.

 UDDI (Universal Description, Discovery and Integration): nos permite localizar

Servicios Web. UDDI define la especificación para construir un directorio
distribuido de Servicios Web, donde los datos se almacenan en XML.
Además, UDDI define una API para trabajar con dicho registro, que nos permitirá
buscar datos almacenados en él, y publicar datos nuevos. De esta forma, una
aplicación podrá anunciar sus servicios en un registro UDDI, o bien localizar
servicios que necesitemos mediante este registro.
Esta capacidad de localizar servicios en tiempo de ejecución, y de que una
aplicación pueda saber cómo utilizarlo inmediatamente gracias a la descripción del
servicio, nos permitirá realizar una integración débilmente acoplada de nuestra
aplicación.
 La interfaz de UDDI está basada en SOAP. Para acceder al registro se utilizarán
mensajes SOAP, que son transportados mediante protocolo HTTP.

Lo más importante es que UDDI contiene información sobre las interfaces técnicas
de los servicios de una empresa. A través de un conjunto de llamadas a API XML
basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como
de ejecución para descubrir datos técnicos de los servicios que permitan invocarlos
y utilizarlos. De este modo, UDDI sirve como infraestructura para una colección de
software basado en servicios Web.

 ¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en
cuenta que existe una colección de software de miles (quizás millones) de servicios
Web, se nos plantean varias cuestiones difíciles:
 ¿Cómo se descubren los servicios Web?
 ¿Cómo se categoriza la información de forma coherente?
 ¿Cómo repercute esto en la localización?
 ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la
interoperabilidad del mecanismo de descubrimiento?
 ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de
descubrimiento cuando mi aplicación depende de un servicio Web?

La iniciativa UDDI surgió como respuesta a estas preguntas. Varias empresas,

incluidas Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas
trescientas más (para obtener un listado completo, consulte UDDI: Community [en
inglés]), unieron sus esfuerzos para desarrollar una especificación basada en
estándares abiertos y tecnologías no propietarias que permitiera resolver los retos
anteriores. El resultado, cuya versión beta se lanzó en diciembre de 2000 y estaba
en producción en mayo de 2001, fue un registro empresarial global alojado por
varios nodos de operadores en el que los usuarios podían realizar búsquedas y
publicaciones sin coste alguno.
 A partir de la creación de esta infraestructura para servicios Web, los datos sobre
estos servicios se pueden encontrar de forma sistemática y confiable en una
capacidad universal totalmente independiente de proveedores. Se pueden llevar a
cabo búsquedas categóricas precisas utilizando sistemas de identificación y
taxonómicos extensibles. La integración de UDDI en tiempo de ejecución se puede
incorporar a las aplicaciones. Como resultado, se fomenta el desarrollo de un
entorno de software de servicios Web.

¿Cómo funciona UDDI?

La información de UDDI se aloja en nodos de operador, empresas que se han

comprometido a ejecutar un nodo público conforme a la especificación que rige el
consorcio UDDI.org. En la actualidad existen dos nodos públicos que se ajustan a la
versión 1 de la especificación UDDI: Microsoft aloja uno e IBM el otro. Hewlett
Packard se ha comprometido a alojar un nodo bajo la versión 2 de la
especificación. Los operadores del host deben replicar datos entre ellos a través de
un canal seguro, para conseguir la redundancia de la información en el registro
UDDI. Se pueden publicar los datos en un nodo y descubrirlos en otro tras la
réplica. Actualmente, la réplica se produce cada 24 horas. En el futuro, este
intervalo entre réplicas se reducirá, ya que habrá más aplicaciones que dependan
de los datos de UDDI.

CARACTERISTICAS DE UDDI 

 Soporte para firma digital

 Separación de los datos de una entidad UDDI de los metadatos asociados (Ej.: para
calcular la firma digital).
 Uso de esquemas de XML.
 Soporte de lenguaje.
Existen algunos otros componentes no menos importantes tales como:

 El WS-Security (Web Service Security): protocolo de seguridad aceptado como

estándar por OASIS. El protocolo proporciona especificaciones sobre cómo debe de
garantizarse la seguridad del intercambio de la información en un web service.
 REST (Representational State Transfer): se trata de una arquitectura que haciendo
uso del protocolo HTTP, un conjunto de operaciones bien definidas (GET, POST,
PUT y DELETE) y una sintaxis universal para identificar recursos, es posible realizar
una comunicación entre un servicio web y el cliente.
Consorcio World Wide Web (W3C)

La W3C nace con un objetivo claro, ser un foro de discusión abierto y fomentar la
interoperabilidad en la evolución técnica que se produce en el mundo Web. En un periodo
de tiempo menor a diez años, se han generado más de cincuenta especificaciones técnicas
que están orientadas a la estandarización de la infraestructura WEB. Se definen como
objetivos a largo plazo en W3C:

 Acceso Universal. Permitir que el acceso a la web sea para todos. Realizando un
esfuerzo por las tecnologías que consideran las diferentes lenguas, culturas,
capacidades, educación, recursos disponibles o las disminuciones físicas o
psíquicas de cada uno.
 Web Semántica. Ofrecer y desarrollar avances en el mundo WEB que permitan a
los usuarios disfrutar del mejor uso posible de los recursos disponibles en la web,
adaptándolo a las necesidades de cada usuario.
 Web de Confianza. Crear un desarrollo web, que permita realizar desarrollo
manteniendo unos criterios comerciales y sociales adecuados.

OASIS (Organization for the Advancement of Structured Information Standards)

OASIS, es un organismo global muy centrado en temas de comercio electrónico. Es un

organismo sin ánimo de lucro. Oasis trata de establecer estándares de forma abierta y
mediante procesos ligeros aplicados por sus miembros, tratando temas referentes a la
seguridad, servicios Web, edición digital, tratamiento de XML, etc...

IBM/Microsoft/Verisign/RSA Security

Mediante un proceso de colaboración entre las principales compañías dentro del ámbito
IT, siendo encabezadas por Microsoft e IBM, se han propuesto una serie de
especificaciones acerca de cómo afrontar la seguridad en los servicios Web. Dentro de
este conjunto de especificaciones se encuentra la especificación WS-Security
estandarizada por OASIS.
WS-Security

La especificación WS-Security, describe la forma de asegurar los servicios Web en el nivel

de los mensajes, en lugar de en el nivel del protocolo de transferencia o en el de la
conexión. Para ello, tiene como objetivo principal describir la forma de firmar y de
encriptar mensajes de tipo SOAP. Las soluciones en el nivel de transporte actuales, como
SSL/TLS, proporcionan un sólido cifrado y autenticación de datos punto a punto, aunque
presentan limitaciones cuando un servicio intermedio debe procesar o examinar un
mensaje. Por ejemplo, un gran número de organizaciones implementan un corta fuegos
(firewall) que realiza un filtrado en el nivel de la aplicación para examinar el tráfico antes
de pasarlo a una red interna.

Si un mensaje debe pasar a través de varios puntos para llegar a su destino, cada punto
intermedio debe reenviarlo a través de una nueva conexión SSL. En este modelo, el
mensaje original del cliente no está protegido mediante cifrado puesto que atraviesa
servidores intermedios y para cada nueva conexión SSL que se establece se realizan
operaciones de cifrado adicionales que requieren una gran cantidad de programación

El estándar WS-Security se basa en estándares y certificaciones digitales para dotar a los

mensajes SOAP de los criterios de seguridad necesarios. Se definen cabeceras y usa XML
Signature para el manejo de firmas en el mensaje. La encriptación de la información la
realiza mediante XML Encryption. Hace uso del intercambio de credenciales de los clientes

WS-Addressing, desempeña un papel fundamental en la seguridad en el nivel de los

mensajes puesto que proporciona los mecanismos para enviar los mensajes de un modo
independiente del transporte. Esto permite enviar un mensaje seguro a través de
cualquier transporte y enrutarlo con facilidad. La protección del mensaje en lugar del uso
del protocolo de transporte ofrece varias ventajas:

 En primer lugar, resulta más flexible puesto que se pueden firmar o cifrar partes
del mensaje en lugar del mensaje completo. De este modo, los intermediarios
 pueden ver las partes del mensaje destinadas a ellos. Un ejemplo de esto sería un
servicio Web que enruta mensajes SOAP y puede inspeccionar las partes no
cifradas de los mismos para determinar a dónde enviarlos, mientras que otras
partes permanecen cifradas.
 En segundo lugar, los intermediarios pueden agregar sus propios encabezados al
mensaje y firmarlos para llevar a cabo el registro de auditorías. Por último, esto
implica que el mensaje protegido se puede enviar a través de diferentes
protocolos, como SMTP, FTP y TCP, sin necesidad de basarse en el protocolo para
la seguridad

Como funciona WS-Security

WS-Security define la forma de conseguir integridad, confidencialidad y autenticación en

los mensajes SOAP. Se realiza de la siguiente manera:

 La autenticación se ocupa de identificar al llamador.

 WS-Security utiliza tokens de seguridad para mantener esta información mediante
un encabezado de seguridad del mensaje SOAP.
 La integridad del mensaje se consigue mediante firmas digitales XML, que
permiten garantizar que no se han alterado partes del mensaje desde que lo firmó
el originador.
 La confidencialidad del mensaje se basa en la especificación XML Encryption y
garantiza que sólo el destinatario o los destinatarios a quien va destinado el
mensaje podrán comprender las partes correspondientes.
 Se apoya en WS-Adressing para asegurar el no repudio.

WS-Policy

Es la especificación encargada de delimitar las diferentes políticas aplicables a los servicios

Web. Es de vital importancia a la hora de integrar los servicios Web, ya que si presentan
cierta complejidad, es muy necesario conocer los detalles del XML que lo define, además
de otros requisitos o capacidades adicionales.

Si se produce un intento de integrar un servicio sin conocer los detalles de su

implementación probablemente se esté evocando al fracaso. Por lo tanto es muy
necesario realizar un estándar que defina las diferentes políticas a acordar. Sin él, los
desarrolladores quedarían expuestos a realizar desarrollos sin integración y difícilmente
escalables

Un marco de trabajo de políticas permitiría a los desarrolladores expresar las políticas de

los servicios de una forma procesable por las computadoras. La infraestructura de los
servicios Web puede verse ser mejorada para entender ciertas políticas y forzar su uso en
tiempo de ejecución.

WS-Trust

La especificación WS-Trust permite definir extensiones al estándar WS-Security con el

objetivo claro de dotar a este de nuevos mecanismos de seguridad. En esta especificación
se incluye el proceso de solicitud, emisión y control sobre tokens de seguridad y se
permite la gestión de las relaciones de confianza entre los servicios

WS-Security, realiza una definición amplia de los mecanismos básicos para proporcionar
un entorno de trabajo seguro en el intercambio de mensajes. Esta especificación,
partiendo de los mecanismos básicos, va añadiendo primitivas adicionales junto con
extensiones para estandarizar el intercambio de tokens de seguridad. Con ello se busca
optimizar la emisión y propagación de las credenciales de los servicios dentro de
diferentes dominios de confianza.

Como funciona WS-Trust

Esta especificación da soporte a un modelo de confianza destinado a los servicios Web, se

le denomina Web Services Trust Model. Para ello, define un proceso a través del cual, un
servicio, puede solicitar que cualquier petición que le llegue cumpla con una serie de
reclamaciones. En la situación, que un solicitante no disponga de todos los requerimientos
necesarios, los solicita al Servicio de tokens de seguridad (STS). Existe una relación de
confianza entre el STS y el servicio

La especificación define varios mecanismos para verificar relaciones de confianza entre

dos partes. Sin embargo, no se restringe solo a ellos, pudiendo un servicio verificar la
relación de confianza con la otra parte como considere necesario. Los métodos que
definen son los siguientes:

 Fixed Trust Roots: El más simple. El servicio mantiene un conjunto fijo de

relaciones de confianza
 Trust hierarchies: El servicio confiara en los tokens siempre que vengan de una
jerarquía de confianza que lleve a un trust root.
 Authentication Service: Es un servicio con el cual el servicio mantiene una relación
de confianza. Cuando llega un security token, el servicio lo envía al Authentication
Service el cuál enviará probablemente otro token que aprobará o no la
autenticación

WS-Federation

Con frecuencia se produce la situación de que participantes en el consumo y la prestación

de un servicio pueden utilizar diferentes tecnologías de seguridad, por ejemplo, una de las
partes podrá utilizar Kerberos y otro Certificados X.509, podría necesitarse una traducción
de los datos que afectan a la seguridad entre las partes afectadas.

Una federación es una colección dominios de seguridad que han establecido relaciones en
virtud del cual un proveedor de uno de los dominios puede proporcionar acceso
autorizado a los recursos que gestiona sobre la base de la información de los participantes
(como puede ser su identidad) la cual debe ser afirmada por un proveedor de identidad
(Security Token Service).
WS-Federation es la especificación que describe la forma de llevar a cabo la
intermediación entre los participantes. Esta especificación tiene como objetivo principal
ayudar a la definición de los mecanismos de federación de dominios de seguridad, ya sean
distintos o similares. Para ello, define , categoriza y intermedia con los niveles de
confianza de las identidades, atributos, y autenticación de los servicios Web de todos los
colaboradores.

En la especificación WS-Federation se definen perfiles asociados a las entidades que

servirán para clasificar los solicitantes que pueden adaptarse al modelo. Es por tanto un
objetivo prioritario de esta especificación habilitar la federación de la información de las
identidades, atributos, autenticación y autorización.

WS-Addressing

WS-Addressing ofrece seguridad de extremo a extremo a la mensajería SOAP.

Independientemente de los tipos de intermediarios como puertos, workstations,
cortafuegos, etc. que sean atravesados por un bloque en el camino al receptor, todo aquel
que se encuentre por el camino sabrá:

 De dónde viene
 (Dirección postal) La dirección a donde se supone que va
 (Att) La persona o servicio específico en esa dirección que se supone va a recibirlo
 Dónde debería ir si no puede ser remitido como estaba previsto
 Todo esto lo incluye en la cabecera del mensaje SOAP ()

WS-Addressing convierte a los mensajes en unidades autónomas de comunicación. La

especificación WS-Addressing define dos tipos de elementos que se incorporan en los
mensajes SOAP:

 Endpoint References (EPR), referencias de invocación, que identifican al punto

donde deben ser dirigidas las peticiones.
  Message Information Headers, son cabeceras específicas que contienen
información relacionada con la identificación que caracteriza al mensaje.

Endpoint References (EPR)

Un identificador de punto de acceso al servicio web puede contener las siguientes

propiedades:

 [wsa:Address], una URI que identifica al punto de acceso. Este elemento es

obligatorio
 [wsa:ReferenceProperties], propiedades individuales necesarias para identificar la
entidad o recurso transportado. Las provee el creador del punto de acceso al
servicio web.
 [wsa:ReferenceParameters], parámetros que faciliten interacciones fruto del
camino que recorre el mensaje. Las provee el punto de acceso al servicio web.
 [wsa:PortType]
 [wsa:ServiceName]
 [wsp:Policy], políticas WS-Policy aplicables

Message Information Headers

Provee información que caracteriza al mensaje y que no se puede modificar a lo largo del
transporte del mismo. Puede contener las siguientes propiedades:

 [destination, wsa:To], una URI identificando el destino del mensaje.

 [source endpoint, wsa:From], un EndpointReference del punto de acceso del
emisor del mensaje.
 [reply endpoint, wsa:ReplyTo], un EndpointReference que contenga el punto de
acceso al que dirigir una respuesta. Si se espera respuesta del punto de acceso de
destino del mensaje es obligatoria la presencia de esta propiedad.
  [fault endpoint, wsa:FaultTo], un EndpointReference que contenga el punto de
acceso al que dirigir los fallos provocados por el mensaje.
 [action, wsa:Action], una URI que identifique el mensaje como un mensaje de
entrada, salida o error en la WSDL del servicio web de destino.
 [message id, wsa:MessageID], una URI que identifique unívocamente el mensaje. Si
se espera una respuesta, esta propiedad es obligatoria.
 [relationship, wsa:RelatesTo]

La Seguridad en los Servicios Web

Siguiendo el modelo W3C, vamos a realizar un pequeño estudio sobre los requisitos de
seguridad que se encuentran enumerados dentro de la arquitectura de referencia de los
servicios web y señalando las diferentes tentativas de ataque que también aparecen
dentro de la especificación. Se ofrecerán soluciones para las mismas.

Servicios de seguridad básicos

La seguridad es un concepto considerado clave dentro de los que comprenden el

aseguramiento de calidad dentro del servicio Web. Si se realiza una catalogación básica de
los servicios de seguridad son la confidencialidad, integridad, autenticidad de origen, no
repudio y control de acceso. A continuación se explica brevemente cada uno de ellos:

 Autenticación de los participantes. Los servicios Web por definición tienen mucha
heterogeneidad, lo que provoca que los sistemas de autenticación tengan que ser
flexibles. Si imaginamos un servicio Web que necesita comunicarse con otro
servicio, este podría solicitar al demandante credenciales junto a una
demostración de que es el propietario de las mismas. Resulta necesario conseguir
un estandarizamiento de los protocolos y en los formatos a utilizar. Otro problema
remanente es definir un modelo de autenticación Single Sign-On de forma que un
servicio que necesita comunicarse con otros servicios Web,no tenga la necesidad
 de estar continuamente autenticándose y logre completar el proceso de negocio
en un tiempo de respuesta aceptable.
 Autorización. Con frecuencia, es necesario aplicar unos criterios que permitan
controlar el acceso a los diferentes recursos. Es necesario definir los usuarios que
pueden realizar diversas acciones sobre los diferentes recursos. En combinación
con la autenticación, permite a las identidades conocidas realizar las acciones para
las que tienen permisos. Con frecuencia se definen políticas de acceso en base a
jerarquías.
 Confidencialidad. Es necesario asegurar que el contenido incluido en los mensajes
que se intercambian se mantiene como información confidencial. Es muy habitual
emplear técnicas de cifrado, ya muy extendidas. Obviamente, la confidencialidad
del mensaje va más allá que el canal por el que es transmitido.
 Integridad. Esta propiedad garantiza que la información que se ha recibido, es
exactamente la misma que se envió desde el cliente.
 No repudio. En una comunicación que se realizan transacciones, es necesario
registrar que las mismas se han producido y registrar el autor que lo ejecutó. En el
caso de los servicios Web, trasladamos esta política la uso del servicio. Se
comprueba que cierto cliente hizo uso de un servicio a pesar de que éste lo niegue
(no repudio del solicitante) así como probar la ejecución se llevó a cabo (no
repudio del receptor).
 Disponibilidad. Uno de los ataques más frecuentes a las aplicaciones se basa en la
denegación de servicios. Se lanzan múltiples solicitudes falsas para inundar el
servicio y provocar su caída. Es necesario contemplar la disponibilidad, como
punto muy importante en el diseño de servicio web, ya que permiten cierta
redundancia de los sistemas.
 Audibilidad. El registro de las acciones en los servicios Web permite mantener una
traza de las mismas de manera que se puedan realizar análisis posteriores de los
datos.
  Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario
garantizar la seguridad durante todo el recorrido que efectúan los mensajes. Dado
que normalmente existen routers como intermediarios de la comunicación, esto
provoca un aumento de la política de seguridad que garantice que se realiza el
transporte de forma segura y confirme la seguridad de los intermediarios. Es
importante disponer de un contexto de seguridad único y que incluya el canal de
comunicación. Para conseguirlo, es necesario aplicar diversas operaciones de
carácter criptográfico sobre la información en el origen. De esta manera se evita
una dependencia con la seguridad que se configure por debajo de la capa de
aplicación y se garantiza los servicios de seguridad

Requisitos de Seguridad

Si realizamos una abstracción sobre la problemática, el objetivo principal es conseguir un

entorno para las transacciones y los procesos que sea seguro para todo el canal de
comunicación. Obviamente, es necesario asegurar la seguridad durante el tránsito de la
comunicación, ya sea con intermediarios o sin ellos durante la misma. Por otra parte, se
necesita asegurar la seguridad de la información en los procesos de almacenamiento: A
continuación se ofrece una revisión breve de los principales requisitos para asegurar la
seguridad en la comunicación.

Mecanismos de autenticación

La autenticación es obligatoria para mantener control y verificar la identidad de

solicitantes y proveedores. En algunas ocasiones, resultará necesario realizar una
autenticación tanto del solicitante como del proveedor, ya que puede producirse que los
participantes no estén en conexión directa. Pueden existir intermediarios que
retransmitan la comunicación

En función de la política de seguridad que se adopte, será necesario autenticar tanto al

proveedor como al solicitante o simplemente a alguno de ellos. Se pueden emplear
métodos basados en contraseñas, certificados, etc... Para formalizar la autenticación. Si se
basan en contraseñas, es necesario aplicar una política que aporte robustez a las mismas.

Autorización

La autorización resulta necesaria para efectuar un control sobre el acceso a los recursos.
Una vez se ha realizado la autenticación sobre el participante y se conoce su identidad, se
utilizarán los mecanismos de autorización para realizar las comprobaciones pertinentes y
asegurar el acceso adecuado al recurso por parte del participante.

Se crean políticas que determinan los privilegios de los participantes. Mediante la gestión
de la confianza, se permite la interacción entre un solicitante y un proveedor sin
referencias previas pero que atendiendo a las credenciales que se intercambian
determinen un nivel de confianza asumible por ambos. De esta manera se permite un
proceso de autenticación sin que haya existido la necesidad de desvelar las identidades de
los participantes en el proceso

Integridad y confidencialidad de los datos

El proceso que mantiene la integridad de los datos, garantiza que la información que se ha
enviada no ha sufrido ninguna transformación sin que se haya detectado. La
confidencialidad, asegura los principios de intimidad de la información. Es decir solo se
permite el acceso a la información a aquellos participantes con permisos para hacerlo.
Con frecuencia, se usan técnicas de cifrado para conceptos de confidencialidad y la firma
digital para temas de integridad.

No repudio

El objeto de las técnicas de no repudio ya se han comentado anteriormente, es registrar la

participación y el grado de la misma de los diferentes interlocutores en una transacción
para protegerlo de una posible denegación, posiblemente por parte de algún interlocutor
de la misma, negando de que la transacción ocurrió o de su participación en la misma.
Las técnicas de no repudio permiten proporcionar evidencias sobre lo sucedido en la
transacción, de manera que una tercera parte resuelve el desacuerdo producido.

Rastreabilidad

Es necesario ajustar trazas que aseguren poder conocer información del acceso una vez se
haya producido este, y comprobar el comportamiento que ha tenido el usuario que ha
realizado el acceso. Son de especial importancia para verificar la integridad del sistema.
Normalmente las trazas las generen los determinados "agentes de auditoria" que pueden
realizar monitoreo, observar recursos y el comportamiento de otros agentes, y validar el
cumplimiento de las políticas establecidas. Con frecuencia , no es posible prevenir la
violación de las diferentes obligaciones pero si un agente de auditoria detecta una brecha
podría activar un plan de repulsa o determinar otro tipo de actividades.

Aplicación distribuida de las políticas de seguridad

Si se han definido arquitecturas que están basadas en Servicios Web, están deben permitir
la definición de políticas de seguridad y comprobar su cumplimiento en las diversas
plataformas y con las diversas variaciones de acceso al servicio.

Uso de políticas

Los mensajes que se envían en la comunicación de los servicios Web atraviesan los
cortafuegos y pueden ser modificados a través de los diferentes puertos y protocolos
existentes. Es necesario, para asegurar la calidad de seguridad en los servicios Web, crear
políticas corporativas para integrarse con las diversas políticas de los proveedores y con la
gestión de la confianza planificada.

Políticas distribuidas

Con frecuencia, se asocian las políticas de seguridad a los proveedores o a los clientes o a
un mecanismo de descubrimiento. Se utilizan para controlar y definir la metodología de
acceso de las peticiones y las respuestas a las mismas, dadas por los involucrados en la
comunicación. Estas políticas son validadas en ejecución dentro del contexto de la
comunicación. Cada parte involucrada debe realizar la validación de sus políticas.

Políticas de confianza

Defiendo de manera simple una política de confianza como una política distribuida que
asegura a dos entidades que afrontan una interacción sin conocerse previamente.
Mediante el uso de credenciales, asumen el nivel de seguridad que pueden soportar. En
ocasiones, la definición de estas políticas implica a terceras entidades de forma recursiva ,
que influyen en la decisión. Un ejemplo, "yo confió en esta entidad, si mis dos compañeros
confían en ti y tu confías en mis dos compañeros"

Mecanismo de Descubrimiento Seguro

El mecanismo de descubrimiento seguro controla las publicaciones y apariciones de un

servicio. Cuando aparece un servicio, es necesario realizar una evaluación de las políticas
de publicación del servicio, exceptuando las situaciones que supongan un servicio de
descubrimiento entre nodos. Si el descubrimiento lo realiza un cliente, puede dotar de
identidad o no dársela al servicio. En esta segunda situación hablamos de un
descubrimiento anónimo.

Confianza y Descubrimiento

Si imaginamos una situación donde un cliente descubre que existe un servicio Web muy
necesario para él, y el proveedor del mismo, es una entidad desconocida hay que
preguntarse qué nivel de confianza puede otorgar el solicitante a ese servicio. Esta
situación es especialmente importante en el caso que se esté manejando información muy
sensible, ya que se está corrigiendo un riesgo grave.
Privacidad

La privacidad se expresa mediante las diferentes políticas definidas por los diferentes
propietarios de los datos. Con frecuencia, los propietarios son los usuarios de los servicios
Web. Es necesario asegurar que los privilegios y derechos de los usuarios son respetados

Fiabilidad de los servicios Web

La aparición de errores es inevitable, especialmente si consideramos que el contexto

engloba a multitud de servicios interconectados por una red global que pertenecen a todo
tipo de personas y entidades. La eliminación de errores no puede ser completa, así que el
objetivo principal es reducir la tasa de errores que aparecen al nivel máximo posible.

Si hablamos de fiabilidad dentro de los servicios Web, podemos realizar una clasificación
en función de la predictibilidad y la fiabilidad de:

 Los servicios de la infraestructura, como un mecanismo de transporte de los

mensajes o un servicio de descubrimiento.
 Las interacciones entre los servicios.
 El comportamiento individual del solicitante y del proveedor.

Amenazas de seguridad

Si analizamos el concepto de amenaza de seguridad, tendemos a asumir que existirá un

intento de acceso y mal uso de los servicios. Por lo tanto hay que realizar un esfuerzo para
controlar los accesos no permitidos. Si realizamos una clasificación de las principales
amenazas, tenemos lo siguiente:

 Acceso no permitido llevado a cabo por entidades sin identificar. Es necesario

poder identificar de forma confiable la identidad de proveedores, servicios, etc...
 Alteración de la información en el canal de comunicación. Es necesario garantizar
la integridad de la información que se envía.
  Debe asegurarse el acceso a la información. Solo pueden acceder las partes
deseadas. Debe de mantenerse una certeza del contenido y de que la
comunicación tuvo lugar.
 El acceso inapropiado a los recursos. Debería ser posible garantizar que los
recursos y las acciones no son accesibles por aquellas partes que no están
autorizadas. De nuevo, este hecho se podría extender al mero conocimiento de
que cierto recurso existe, es decir, de alguna forma se debería poder impedir que
personas no autorizadas no puedan conocer la existencia de ciertos recursos o
ciertos servicios.
 Denegación de servicio. No debería ser posible que los clientes de los servicios no
puedan acceder a él.

Tipos de ataques

Los tipos de ataques que se listan a continuación están extraídos de la especificación W3C.

Alteración de los mensajes

Es un tipo de ataque centrado sobre la integridad de los mensajes. Se busca modificar el

contenido del mensaje (ya sea parcialmente o totalmente). En el caso que el atacante
tuviera controlado un canal de comunicaciones entre servicios podría modificar los
mismos, eliminarlos, capturarlos y reenviarlos.

La integridad de los mensajes se proporciona mediante la firma digital del fichero XML
junto con tokens de seguridad para asegurar que el mensaje es transmitido sin
modificaciones. El mecanismo de integridad está diseñado para soportar múltiples firmas
por diferentes actores y se puede extender para soportar nuevos mecanismo de firma.
Integrando XMLSignature, según lo establecido por la especificación WS-Security se
minimiza la repercusión de estos ataques.
Ataques a la confidencialidad

Centrados en la captación de la información contenida dentro de los mensajes. En

ocasiones puede existir información muy sensible (datos médicos, datos económicos,
etc...)

Hombre en el medio o ‘man- in-the-middle.

Es la infiltración por parte de un atacante entre los participantes de una comunicación.

Normalmente, intercepta la comunicación y suplanta a los participantes de manera que
estos creen que se comunican entre si cuando lo hacen con el atacante.

La posibilidad de un ataque de intermediario sigue siendo un problema potencial de

seguridad serio, incluso para muchos sistemas criptográficos basados en clave pública.
Existen varios tipos de defensa contra estos ataques que emplean técnicas de
autenticación basadas en:

 Claves públicas
 Autenticación mutua fuerte
 Claves secretas (secretos con alta entropía)
 Passwords (secretos con baja entropía)
 Otros criterios, como el reconocimiento de voz u otras características biométricas

La integridad de las claves públicas debe asegurarse de alguna manera, pero éstas no
exigen ser secretas, mientras que los passwords y las claves de secreto compartido tienen
el requerimiento adicional de la confidencialidad. Las claves públicas pueden ser
verificadas por una autoridad de certificación (CA), cuya clave pública sea distribuida a
través de un canal seguro (por ejemplo, integrada en el navegador web o en la instalación
del sistema operativo).
Suplantación de identidad (Spoofing)

Es un ataque orientado a los niveles de confianza que se establecen en la comunicación. El

atacante suplanta la identidad de uno de los participantes en una relación de confianza,
usualmente trata de comprometer al destinatario de la comunicación. Es muy útil utilizar
una robusta autenticación para fortalecer el servicio ante estos ataques.

Para evitar ataques de spoofing exitosos contra nuestros sistemas podemos tomar
diferentes medidas preventivas; en primer lugar, parece evidente que una gran ayuda es
reforzar la secuencia de predicción de números de secuencia TCP. Otra medida sencilla es
eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las
máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el
filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas
medidas de seguridad importantes de cara a evitar el spoofing.

Denegación de servicio

El objetivo es mantener un servicio activo para que los usuarios legítimos puedan acceder
a él. Los ataques se centran en destruir la disponibilidad de un servicio. Su objetivo es
interrumpir las operaciones de un servicio dejándolo desconectado.

Es necesario adaptar la configuración del servidor a las necesidades de autenticación,

seguir recomendaciones con respecto al tamaño de mensajes aceptadas, controlar la
distribución de mensajes para minimizar este tipo de ataques.

Ataque de repetición

En este caso un atacante es capaz de interceptar un mensaje válido pudiendo reenviarlo

más tarde todas las veces que quiera al servicio para el que era destinatario. Para poder
solventar este problema se deben utilizar técnicas de autenticación apropiadas
conjuntamente con técnicas de sellado de tiempos y números de secuencia.
Estándares y frameworks actuales que abordan la seguridad en servicios web

El esquema del que parte la estructura de los servicios Web, tiene unas características
propias de acceso a la información, sobre el intercambio de la misma, sobre la autonomía
de la información que difieren de lo establecido en los modelos de seguridad
tradicionales. De hecho, esto provoca la necesidad y el desafío de modificar mecanismos
que afectan a la integridad y confidencialidad de la información que es enviada por el
canal del servicio Web. Si analizamos la estructura de los sistemas de seguridad
perimetrales (cortafuegos, sistemas anti-intrusos) no están preparados para asegurar
arquitecturas SOA. Estas arquitecturas son eminentemente dinámicas y son transmitidas a
través de protocolos no asegurados como HTTP. Si aplicamos criterios que controlan la
comunicación punto a punto (TLS,SSL), no son válidos para porque no aseguran la
aplicación completa.

El procesamiento de SOA se basa en comunicaciones basadas en mensajes SOAP y

documentos XML. Es necesario asegurar transmisiones a través de una infraestructura de
conectividad. Los estándares que se están desarrollando por W3C y otras organismos,
basados en XML, tratan de asegurar la confidencialidad, integridad y disponibilidad de los
Servicios Web. Estas especificaciones dotan de mecanismos para cifrar, firmar
digitalmente, autenticar y certificar documentos XML.

A continuación se ofrece una tabla resumen con los principales elementos de seguridad
dentro de los servicios Web, así como las recomendaciones al respecto.
Tendencias de desarrollo y aspectos futuros de los Servicios Web

Hoy en día, con los acelerados cambios que la tecnología está provocando en todas
nuestras actividades, algunos nos preguntamos: ¿cómo será dentro de 10 o 20 años
Internet? ¿Qué nuevos usos le podremos dar? ¿Qué innovaciones podemos esperar en
materia de aplicaciones y servicios? ¿Cuáles y cómo serán los dispositivos que utilizaremos
para interconectarnos al Internet del futuro?

Para responder a esas preguntas, y buscando que las respuestas sean lo más asertivas
posibles, evitando caer en predicciones que puedan estar lejos de una realidad objetiva,
es muy importante analizar los avances actuales en la materia, así como tomar en cuenta
la opinión de expertos como lo son Vinton G. Cerf y Robert E. Kahn, considerados padres
del Internet y, con esta información, hacernos una idea de cómo y en qué puede
transformarse en algunos años la red de redes.
Para ponernos en contexto, los expertos concuerdan en que hacer predicciones a más de
10 años es muy arriesgado; sin embargo, el avance tecnológico y la tendencia hacia una
sociedad más digitalizada y conectada, están provocando una transformación acelerada
del Internet, lo que a su vez genera que los servicios y aplicaciones soportados en esta red,
progresivamente aceleren su innovación y desarrollo.

Si entendemos entonces el Internet del futuro como un término global aplicado para
agrupar actividades políticas, regulatorias, socioeconómicas y tecnológicas enfocadas a
fortalecer el desarrollo de su entorno, podemos pronosticar que el Internet pasará a ser
un servicio básico como lo es hoy la electricidad, disponible para todos, y tendrá presencia
en todas partes, es decir, una Internet ubicua.

El futuro del Internet estará íntimamente ligado con el futuro de la humanidad, por lo
cual, los avances actuales relacionados con la industria 4.0, el big data, el cómputo en la
nube y el Internet de las Cosas propiciarán un entorno de oportunidades de negocios
donde cualquier nuevo dispositivo o tecnología lanzada al mercado, que cumpla con los
protocolos y estándares establecidos, tendrá las capacidades para conectarse a la red,
integrando servicios de aprendizaje automático que gestionen sistemas inteligentes que
permitan a sus usuarios hacer uso inmediato de toda la información recopilada, utilizando
ambientes de realidad aumentada o mixta, integrando herramientas diseñadas a la
medida de cada usuario para la gestión de su privacidad, con tecnologías de autenticación
y ciberseguridad muy sofisticadas.

El Internet del futuro buscará acabar con las fronteras en todos los aspectos, habilitando
servicios de conexión con diversas tecnologías (fibra óptica, satelital y LiFi, entre otras) a
velocidades muy superiores a las actualmente disponibles, permitiendo a toda persona y
dispositivos enlazarse sin importar en qué lugar de la Tierra se encuentren.

Google ha definido siete puntos a considerar para el desarrollo del Internet del futuro: un
Internet móvil que proporcione conexiones a cada vez más dispositivos; una red
omnipresente donde todos los puntos del planeta tengan acceso; una navegación de alta
velocidad con grandes anchos de banda; cómputo en la nube operando 24x7; iMarketing
personalizado basado en perfiles inteligentes; disponibilidad en tiempo real de todos los
servicios públicos y privados; y una evolución hacia las redes sociales inteligentes.

Los expertos señalan cinco retos principales que el Internet del futuro deberá afrontar:

 Aumentar su capacidad de transporte, conectividad y ancho de banda;

 Realizar acuerdos globales para la definición de políticas, aspectos técnicos y
socioeconómicos que impacten directamente en su desarrollo;
 Desarrollar nuevas arquitecturas de redes y modelos de referencia;
 Implementar metodologías vanguardistas para la gestión de contenidos, sistemas
de sociabilidad e integración de nuevos dispositivos móviles inteligentes y
virtuales;
 Y mejorar los niveles de gobernabilidad y ciberseguridad de la red.

El futuro del Internet no está escrito en piedra, ya que es flexible y dinámico. Todos
participamos de alguna manera en su proceso de construcción, motivo por el cual su
futuro se encuentra en constante evolución, generando nuevas oportunidades de
negocios globales para toda empresa interesada en participar en su desarrollo.
https://www.ionos.es/digitalguide/servidores/know-how/servidor-web-definicion-
historia-y-programas/?

https://tugesto.com/blog/web-service/

http://uddi.xml.org/uddi-org

https://desarrolloweb.com/articulos/1574.php3

https://www.w3c.es/

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

https://www.ibm.com/developerworks/library/specification/ws-secmap/#download