Embed Size (px)
Citation preview
SERVICIOS WEB
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.
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
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.
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.
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.
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.
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.
É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.
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>
</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.
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>
</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:
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
“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.
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).
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.
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
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.
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 Samples\Servers\FoxIsapi\FoxWeb, 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 Samples\Servers\FoxIsapi\FoxIs, 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
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.
