INTRODUCCION A LOS SERVICIOS WEB

1. SERVICIOS WEB

2. INTRODUCCION:
Los servicios web son componentes software con estas características distintivas
para el programador:
• Son accesibles medinte el protocolo SOAP ("Simple Object Access
Protocol").
• Su interfaz se describe mediante un documento WSDL ("Web Services
Description Language" o "Lenguaje de Descripción de Servicios Web").
SOAP es un protocolo de comunicaciones para paso de mensajes XML,
fundamento sobre el cual se sustentan los servicios web. SOAP permite el envío
de mensajes XML entre aplicaciones. Estos mensajes son unidireccionales, pero
todas las aplicaciones pueden ser a la vez emisoras o receptoras.
Los mensajes SOAP sirven para muchos propósitos, como, entre otros,
esquemas de petición y respuesta, notificaciones o mensajería asíncrona.
SOAP es un protocolo de alto nivel, que define la estructura del mensaje y ciertas
reglas básicas para su procesamiento, y es totalmente independiente del protocolo
de transporte.
Esto permite que los mensajes SOAP sean intercambiados mediante HTTP,
SMTP, etc. En estos momentos, HTTP es el más utilizado.

3. WSDL es un estándar que describe servicios web mediante un documento XML. ç
Este documento proporciona a las aplicaciones la información requerida para
acceder a un servicio web.
El documento ofrece una descripción el objetivo del servicio web, sus mecanismos
de comunicación, ubicación, etc.
UDDI ("Universal, Description, Discovery and Integration") es un servicio de
registro de servicios web mediante su nombre, la URL de su WSDL, una
descripción del servicio, etc. Las aplicaciones que lo requieran pueden consultar,
mediante SOAP, los servicios registrados en UDDI.
CONCEPTO DE SERVICIO WEB:
Un servicio web (en inglés, Web service) es una pieza de software que utiliza un
conjunto de protocolos y estándares que sirven para intercambiar datos entre
aplicaciones.
Distintas aplicaciones de software desarrolladas en lenguajes de programación
diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios
web para intercambiar datos en redes de ordenadores como Internet.
La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las
organizaciones OASIS y W3C son los comités responsables de la arquitectura y
reglamentación de los servicios Web. Para mejorar la interoperabilidad entre
distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva
estos estándares.
Las aplicaciones distribuidas y el Web:
• El World Wide Web: El Web:
La aplicación distribuida mayor conocida es el World Wide Web (WWW), en corto
denominado el Web. Técnicamente, el Web es un sistema distribuido de servidores y

4. clientes HTTP (protocolo de transferencia de hipertexto), normalmente conocidos
como los servidores Web y exploradores Web.
La figura 2 muestra un esquema general de la arquitectura Web, en la que sus
elementos se describen adelante.
Antes del suceso
del Web, la
comunidad de usuarios de Internet comprendida grandemente de investigadores y
académicos usaron los servicios de red como correo electrónico y transferencia de
archivo para intercambiar información.
El World Wide Web creado en 1990 en Ginebra Suiza, en el Laboratorio de
Partículas Físicas Europeo. Una propuesta sometida por Tim Berners-Lee y
Robert Cailliau para un "sistema de hipertexto universal."
Desde la propuesta original, el crecimiento del Web mundial ha sido extraordinario
y se ha extendido más allá de la investigación y la comunidad académica en todos
los sectores del mundo, incluso el comercio y casas privadas. El continuo
desarrollo de la tecnología Web es actualmente coordinado por el World Wide
Web Consortium, W3C.
La noción del Web mundial es que combina tres importantes y bien establecidas
tecnologías de la computación:
 Documentos hipertexto: documentos en que palabras o frase elegidas,
típicamente resaltadas, pueden marcarse como enlaces a otros
documentos, para que un usuario pueda tener acceso a los documentos
vinculados haciendo clic con un ratón en el texto resaltado.

5.  Recuperación de información apoyada en la red: Mediante el protocolo de
transferencia de archivos (FTP), que fue ampliamente usado.
 El lenguaje de marcado generalizado estándar (SGML), un estándar de ISO
que permite el marcado de los documentos para que puedan desplegarse
en un formato uniforme en cualquier plataforma, independiente de los
mecanismos de la presentación.
• El típico Web es la aplicación cliente -servidor, basada en HTTP:
 Un servidor Web es un servidor orientado a conexión que
implementa el HTTP. Por omisión, un servidor HTTP se ejecuta en el muy
conocido puerto 80.
 Un usuario ejecuta un cliente del Web (a veces llamado explorador)
en una computadora local. El cliente interactúa con un servidor Web según
el HTTP, especificando un documento para ser obtenido. Si el documento
es localizado por el servidor en su directorio, los contenidos del documento
se devuelven al cliente, el cual los presenta al usuario.
Tecnologías base de servicios Web
• Introducción a las tecnologías básicas:
Un servicio Web es una colección de funciones que son empaquetadas como una
sola entidad y publicadas a la red para el uso a través de otros programas.
Los servicios Web son bloques componentes para crear sistemas distribuidos
abiertos y permiten a las compañías e individuos acceder rápidamente a los
recursos digitales disponibles mundialmente.

6. La base de Servicios Web es la mensajería de XML sobre los protocolos del Web
estándar como HTTP.
Éste es un mecanismo de comunicación muy ligero en el que cualquier lenguaje
de programación, middleware o plataforma pueden participar, suavizando la
interoperabilidad grandemente.
Las tecnologías más populares que han ganado mayor aceptación de la industria y
que son un camino posible de realizar los servicios Web son las siguientes:
• Un proveedor crea, ensambla y despliega un servicio del Web mediante un
lenguaje de programación, middleware y plataforma de la propia opción del
proveedor.
• El proveedor registra el servicio en registros de UDDI (Universal
Description, Discovery and Integration). UDDI permite a los desarrolladores
publicar los Servicios Web y eso permite a su software buscar los servicios
ofrecidos por otros.
• La aplicación del usuario liga al Servicio Web e invoca las operaciones del
servicio mediante SOAP (Simple Object Access Protocol). SOAP ofrece un
formato de XML para representar parámetros y valores devueltos sobre
HTTP.
• Descripción de las tecnologías básicas
XML:
En el contexto de servicios Web, XML se usa no sólo como el formato de mensaje
sino también como la manera en la que los servicios están definidos. Por
consiguiente, es importante saber un poco sobre XML, sobre todo dentro del
contexto de cómo se usa para definir e implementar los servicios Web.

7. Propósitos de XML:
XML fue desarrollado para superar limitaciones de HTML, especialmente para
soportar mejor la creación y manejo del contenido dinámico. HTML está bien para
definir y mantener el contenido estático, pero cuando el Web evoluciona hacia una
plataforma de software activado, en la que los datos tienen significado asociado, el
contenido necesita ser generado y dirigido dinámicamente. Usando XML, pueden
definir cualquier número de elementos para el significado asociado con datos; es
decir, describe los datos y qué realiza con ellos usando uno o más elementos
creados para ese propósito.
Tecnologías de XML
XML es una familia de tecnologías: un lenguaje de marcado de datos, varios
modelos de contenido, un modelo de vinculación, un modelo de espacio de
nombres y varios mecanismos de transformación.
SOAP
La especificación de SOAP define una estructura de la mensajería para
intercambiar los datos de XML formateados en Internet. La estructura de la
mensajería es simple, fácil de desarrollar y completamente neutral con respecto al
sistema operativo, lenguaje de programación o la plataforma de computación
distribuida.
SOAP es fundamentalmente un modelo de comunicación unidireccional que
asegura que un mensaje coherente sea transferido desde un remitente a un
destinatario, inclusive potencialmente intermediarios que pueden procesar parte
de o agregar a la unidad del mensaje. La especificación de SOAP contiene las
convenciones de adaptar la mensajería unidireccional para el paradigma típico de
petición/respuesta en comunicación estilo RPC y además define cómo transmitir
los documentos XML completos.
SOAP esta diseñado para proporcionar un protocolo de comunicaciones
independiente, abstracto capaz de pontear o conectando, dos o más negocios o
dos o más sitios comerciales remotos. Los sistemas conectados pueden ser
construidos usando cualquier combinación de hardware y software que soporten el
acceso a Internet para los sistemas existentes, como .NET y J2EE.

8. WSDL:
El Lenguaje de descripción de servicios Web (WSDL) es un formato de esquema
XML que define una estructura extensible por describir las interfaces de los
servicios Web. WSDL fue desarrollado principalmente por Microsoft e IBM y fue
sometido por compañías al W3C. WSDL tiene el núcleo de la estructura de los
servicios Web, proporcionando un modo común para representar los tipos de
datos proporcionados en los mensajes, las operaciones a ser realizadas en los
mensajes y el mapeo de los mensajes sobre el transporte de la red.
WSDL es dividido en tres elementos mayores:
1. Definiciones de tipo de datos.
2. Definiciones abstractas.
3. Servicio de ligaciones.
Cada elemento mayor puede especificarse en un fragmento de documento XML
separado y puede importarse en varias combinaciones para crear una descripción
final de los servicios Web o ellos pueden todos ser definidos juntos en un solo
documento.
Las definiciones del tipo de datos determinan la estructura y el contenido de los
mensajes.
Las definiciones abstractas determinan las operaciones realizadas en el contenido
del mensaje y el servicio de ligaciones determina el transporte de la red que
llevará el mensaje a su destino.
UDDI:
Después de que han definido los datos en los mensajes (XML), han descrito los
servicios que recibirán y procesarán el mensaje (WSDL) y han identificado los
medios de enviar y recibir los mensajes (SOAP), necesitan una manera para
publicar el servicio que ofrecen y encontrar los servicios que otros ofrecen y que
desean usar.

9. Ésta es la función que proporciona UDDI (distribución universal, descubrimiento e
integración).
La estructura de UDDI define un modelo de datos en XML e interfaces de
programación de aplicaciones de SOAP (APIs) para registrar y descubrir la
información comercial, inclusive los servicios Web en publicación de negocios.
UDDI es producido por un consorcio independiente de vendedores, fundado por
Microsoft, IBM y Ariba, para el desarrollo de un estándar de Internet en el registro
de descripción y descubrimiento de servicios Web.
UDDI es similar en concepto a un directorio de las páginas amarillas.
Los negocios registran su contacto de información, incluyendo cosas en detalle
como números de teléfono y fax, código postal y sitio Web.
El registro incluye la información de la categoría por buscar, como ubicación
geográfica, razón social de la industria, tipo de negocio mercantil, y así
sucesivamente.
Otros negocios pueden buscar la información registrada en UDDI para encontrar
suministro de partes, servicios de comida, compraventas o actividades
comerciales.

10. Un negocio también puede descubrir la información sobre el servicio Web
específico en el registro, encontrando típicamente una URL para un archivo de
WSDL que señala el servicio Web de un distribuidor.
EJEMPLOS DE SEGURIDAD:
• EJEMPLO1:
El siguiente ejemplo muestra una firma digital XML ‘detached’ o desligada:
<Signature Id="MiPrimeraFirma"
xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/RECxml-
c14n-20010315" />
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-
20000126/">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xmlc14n-
20010315" />
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>

11. </SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>...</P>
<Q>...</Q>
<G>...</G>
<Y>...</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
EL elemento requerido SignedInfo representa la información que se está firmando
realmente. De hecho, el elemento que es normalizado, según el algoritmo definido
en el elemento CanonicalizationMethod y que es firmado es el elemento
SignedInfo. La validación fundamental de la firma consiste en dos pasos
obligatorios :
• Validación de la firma: realizada sobre el resultado de firmar el elemento
SignedInfo y que es transportado como valor textual del elemento
SignatureValue.
• Validación de la referencia: validación de cada elemento ‘digest’ incluido
en cada elemento Reference, incluido a su vez dentro del elemento
SignedInfo. Esta validación comprueba la integridad de los objetos de datos
que han sido firmados. El elemento CanonicalizationMethod refleja el
algoritmo utilizado para normalizar o normalizar el elemento SignedInfo
antes de calcular su valor de digestión como parte de la operación de
cálculo de la firma.

12. Ejemplo 2 : Ejemplo extendido (I)
Consideremos el ejemplo anterior con una referencia adicional a un elemento
object local que incluye un elemento SignatureProperty. De esta forma la firma
sería no sólo de tipo desligada sino también envolvente (ya que el elemento
Signature envuelve datos firmados).
<Signature Id="MiSegundaFirma" ...>
<SignedInfo>
...
<Reference URI="http://www.w3.org/TR/xmlstylesheet/"
/>
…
<Reference URI="#propiedadesFirma"
Type="http://www.w3.org/2000/09/xmldsig#Signatur
eProperties">
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig
#sha1" />
<DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</
DigestValue>
</Reference>

13. </SignedInfo>
…<
Object>
<SignatureProperties>
<SignatureProperty Id="propiedadesFirma"
Target="#MiSegundaFirma">
<timestamp
xmlns="http://www.ietf.org/rfcXXXX.txt">
<date>19990908</date>
<time>14:34:34:34</time>
</timestamp>
</SignatureProperty>
</SignatureProperties>
</Object>
</Signature>
La estructura simplificada del documento anterior podría ser vista de la
siguiente manera:

14. Ejemplo 3:
Ejemplo extendido (II)
El elemento Manifest se proporciona para cubrir requisitos adicionales que no
están resueltos directamente por las partes obligatorias de la especificación. A
continuación se presentan dos requisitos y la manera en la que el elemento
Manifest las resuelve.
En primer lugar, las aplicaciones frecuentemente necesitan firmar eficientemente
múltiples objetos de datos incluso cuando la propia operación de firmado es “cara”
como por ejemplo la firma basada en la clave pública.
Este requisito puede ser resuelto incluyendo múltiples elementos Reference dentro
del elemento SignedInfo ya que la inclusión de cada ‘digest’ asegura la integridad
y autenticidad de los datos digeridos.
Sin embargo, algunas aplicaciones podrían no querer adoptar el comportamiento
definido por la validación fundamental asociada con esta aproximación porque
requiere que cada elemento Reference incluido dentro del elemento SignedInfo se

15. “someta” a la validación de la referencia (donde los valores de los elementos
DigestValue son verificados).
El ejemplo que se muestra a continuación incluye un elemento Reference que firma un
elemento Manifest ubicado dentro de un elemento Object.
<Reference
URI="#MiPrimerManifiesto"
Type="http://www.w3.org/2000/09/xmldsig#Manifest">
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
...
<Object>
<Manifest Id="MiPrimerManifiesto">
<Reference>...</Reference>
<Reference>...</Reference>
</Manifest>
</Object>
EJEMPLOS------ GOOGLE:
EJEMPLO 1 :
Operación doGetCachedPage
Su interfaz también es muy sencilla. Requiere dos entradas (key y url) y devuelve
como salida la caché almacenada para la URL indicada. Entradas:
o key. Es el número de licencia proporcionado al usuario de la API.

16. o url. URL de la página o documento.
Su salida es:
o return. Contenido de la caché para la URL solicitada.
EJEMPLO 2:
Operación doGoogleSearch
Esta operación es la que admite un mayor número de opciones de configuración.
Entre las entradas, las más importantes son la clave y la consulta solicitada, pero
también hay otras que debemos conocer. Se explican brevemente todas a
continuación.
o key. Es el número de licencia proporcionado al usuario de la API.
o q. Consulta formada por uno o varios términos de búsqueda.
o start. Posición (índice) del primer elemento a partir del cual solicitamos la
búsqueda.
o maxResults. Número máximo de elementos que solicitamos a partir del
indicado en la entrada anterior. El número devuelto podrá ser menor si no
hay suficientes resultados encontrados.
o filter. Tipo lógico que indica si realizamos la búsqueda filtrando los
elementos similares a otros mostrados o no.
o
restrict. Permite restringir la búsqueda a un almacén de búsqueda
determinado como, por ejemplo, “linux”.
o safeSearch. Permite filtrar contenidos no aptos para menores.
o lr. Restringe a un idioma determinado.
o ie. Codificación de entrada (obsoleto).
o oe. Codificación de salida (obsoleto).

17. La salida se devuelve mediante el elemento return del tipo complejo
GoogleSearchResult. Este tipo está formado por los siguientes elementos:
o documentFiltering. Indica si la búsqueda se realizó con el filtro activo o no.
o searchComments. Comentarios de la búsqueda como, por ejemplo, cuando
se indica que ciertas palabras no se incluyeron en la búsqueda por ser poco
relevantes.
o estimatedTotalResultsCount. Número de resultados totales.
o estimateIsExact. Indica si la cantidad devuelta en el elemento anterior es un
número exacto o aproximado.
o resultElements. Array construido con el tipo complejo ResultElement. Este
array contiene un elemento por cada resultado encontrado según las
opciones de búsqueda.
o searchQuery. Consulta que se ha buscado.
o startIndex. Índice del primer resultado devuelto.
o endIndex. Índice del último resultado devuelto. Obsérvese que los
resultados comprendidos entre startIndex y endIndex serán un subconjunto
del total de resultados, estimatedTotalResultsCount, sin exceder el número
máximo de resultados que se solicitó, maxResults.
o searchTips. Consejos de búsqueda como, por ejemplo, “elimine las comillas
de la búsqueda para obtener más resultados”.
o directoryCategories. Array construido con el tipo complejo
DirectoryCategory. Se incluyen las distintas categorías del directorio ODP
(Open Directory Project) que tienen relación con la consulta de búsqueda.
o searchTime. Tiempo que se ha tardado en ejecutar la búsqueda.
Los elementos anteriores proporcionan información general de toda la búsqueda.
Pasamos ahora a describir los elementos del tipo complejo ResultElement, con
información relativa a un resultado concreto.
o summary. Resumen escrito por un editor del directorio, en caso de que
el sitio esté incluido en el directorio.
o URL. Identificador del documento.

18. o snippet. Fragmento de texto del documento donde normalmente
aparecerán los términos buscados.
o title. Título del documento.
o cachedSize. Tamaño de la página almacenada en caché. Si no está
almacenada, no devuelve nada.
o relatedInformationPresent. Indica si está soportada la búsqueda de
documentos similares para la URL de este resultado.
o hostName. Indica el nombre del host en caso de que se haya mostrado
ya al menos 1 resultado de ese mismo host.
o directoryCategory. Tipo complejo que indica la categoría del directorio
donde está incluido el sitio.
o directoryTitle. Título de la categoría del directorio.
EJEMPLO 3:
Aplicación simple
En este apartado describimos las cuestiones de diseño de la aplicación
desarrollada en Cocoon.
Una vez que conocemos la descripción WSDL de las operaciones de Google,
podemos generar peticiones SOAP y procesar los mensajes de respuesta
recibidos.
El protocolo SOAP (Simple Object Access Protocol, protocolo simple de acceso a
objetos) [7] permite la comunicación entre servidores. SOAP especifica el formato
de los mensajes para que una máquina solicite un servicio a otra máquina y reciba
una respuesta. En nuestro caso, configuraremos un servidor web para que realice
peticiones vía SOAP al servidor de Google y procese los mensajes de respuesta.
Para generar los mensajes SOAP desde Cocoon hemos encontrado 2 alternativas.
La primera es utilizar las clases Java suministradas en la API de Google. La

19. segunda es generar los mensajes SOAP desde Cocoon ajustándonos a la
descripción WSDL proporcionada.
El API de Google resulta muy interesante para comenzar a experimentar con web
services. Incluye una buena documentación para ponerlo en marcha. Se podrían
realizar incluso consultas a Google sin ni siquiera tener conocimientos de WSDL y
SOAP. Sin embargo, en este trabajo hemos querido ir más allá y analizar todas las
posibilidades que se ofrecen.
Como plataforma de desarrollo, se ha optado por Cocoon por ofrecer una muy
buena integración con XML y SOAP. Una vez se dominan las bases de su
funcionamiento, resulta sencillo realizar una petición vía SOAP y devolver sus
resultados en una página HTML.
EJEMPLOS DE MICROSOFT:
EJEMPLO 1:
Ejemplos de servidor de Automatización FoxISAPI.
Visual FoxPro incluye una extensión de ISAPI llamada Foxisapi.dll que permite el acceso
a servidores de Automatización personalizados de Visual FoxPro desde cualquier servidor
de Web que admita ISAPI, como Microsoft Internet Information Server o Microsoft
Personal Web Server. La extensión FoxISAPI funciona al crear una instancia de un
servidor de Automatización de Visual FoxPro y al llamar, a continuación, a un método de
ese servidor que devuelve código HTML. El código HTML se traslada del servidor a un
explorador de Web, como Microsoft Internet Explorer.

20. Visual FoxPro incluye dos ejemplos de servidor de Automatización FoxISAPI que ilustran
el modo de aprovechar las posibilidades de Visual FoxPro para mantener dinámicamente
un sitio Web.
El primer ejemplo, FoxWeb, que se encuentra en la carpeta
SamplesServersFoxIsapiFoxWeb, es una muestra sencilla diseñada para exponer los
conceptos básicos de FoxISAPI. Con él puede recorrer los pasos del proceso de
configuración y construcción de los servidores FoxISAPI, tanto de forma local como
remota. Además, este ejemplo recorre las etapas necesarias para implementar conjuntos
de servidores para una mejor escalabilidad.
El segundo ejemplo, FoxIs, que se encuentra en la carpeta
SamplesServersFoxIsapiFoxIs, es una muestra más compleja que contiene rutinas para
asignar contenido visual y funcional de un formulario de Visual FoxPro a código HTML.
Los conceptos son los mismos que en FoxWeb: FoxISAPI crea una instancia de un
servidor e invoca un método para obtener código HTML. Al utilizar el ejemplo FoxIs un
formulario visual, ofrece más versatilidad, pues le permite ejecutarlo como un programa
independiente, desde clientes OLE y desde un explorador de Web.
Si no está familiarizado con la creación de servidores de Automatización de Visual
FoxPro, vea Crear servidores de Automatización.
EJEMPLO 2:
Ejemplo de servidor de Automatización de Gopher
En este ejemplo se simula un objeto comercial de búsqueda inteligente que
localiza a un cliente que puede encontrarse en una o varias bases de datos
distintas. Esto permite utilizar Visual FoxPro en un modelo de tres capas en el que
los servicios de usuario no sean estrechamente dependientes de los servicios de
datos, como ocurre en muchos de los entornos cliente-servidor actuales.
EJEMPLO 3:
Administrador de grupo: ejemplo de servidor de Automatización

21. En este ejemplo, el procesamiento del trabajo puede controlarse mediante un
equipo remoto. Esto le permite continuar trabajando porque los otros recursos
controlan todo el trabajo.