Servicios Web

Vadim Paz Madrid Gorelov1, Juan Francisco De Paz Santana1

1

Universidad de Salamanca, Doctorado Informtica y Automtica Plaza de la Merced s/n 37008, Salamanca, Spain {vpazmadrid, fcofds}@gmail.com

Abstract. En este artculo se trata de proporcionar una visin general de la situacin actual de los servicios Web en diversos aspectos como arquitectura, seguridad, calidad, estndares, problemas de implementacin etc. Tambin se muestran algunas lneas de investigacin que se estn llevando a cabo en el mbito docente y empresarial.

Introduccin

Con la aparicin de Internet y su posterior masificacin a niveles jams pensados, ha existido siempre la necesidad e inquietud por parte de las empresas desarrolladoras de software de buscar o contar con la manera de lograr la integracin entre sistemas heterogneos, siendo sistemas heterogneos los relacionados en software y hardware. Para tal efecto muchas compaas fueron creando de forma individual la mejor manera de lograr esta integracin. Se comenz una bsqueda por generar la mejor tecnologa integradora de sistemas, pero a medida que la competencia se hacia cada vez ms fuerte, la integracin se hacia cada vez ms difcil. Las empresas se percataron que era imposible crear una plataforma integrada de forma individual, as que decidieron atacar el problema de raz. En vez de crear la mejor plataforma integradora, era mejor buscar un leguaje comn de intercambio de informacin aprovechando los estndares existentes. Bajo todo este contexto nacieron los servicios Web (Web Services) que aun estn en desarrollo y este artculo pretender mostrar lo que ellos significan, avances en este campo, limitaciones, una visin futurista en esta rama y algunos ejemplos de lneas de investigacin encontradas en este momento. Una de las caractersticas que diferencia los servicios Web y WWW es el ambiente de funcionamiento. HTTP (Hypertext Transfer Protocol) y HTML se desarrollaron principalmente para lectura por parte de los navegadores y su contenido es frecuentemente esttico, mientras que los servicios Web, para programas que interaccionan de forma dinmica.

Servicios Web

Los servicios Web [3] [Cabrera et al., 2004] tienen gran importancia en la tendencia de la computacin distribuida en Internet. Los estndares abiertos y el enfoque en la comunicacin y la colaboracin entre personas y aplicaciones han creado un entorno donde los servicios Web XML (eXtensible Markup Language) estn favoreciendo una plataforma para la integracin de aplicaciones. Hay tantas definiciones de servicios Web como compaas que los construyen, Una posible sera hablar de ellos como un conjunto de aplicaciones o de tecnologas con capacidad para interoperar en la Web. Estas aplicaciones o tecnologas intercambian datos entre s con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a travs de la Web. Para ampliar un poco mejor el concepto de servicios Web citaremos una exposicin del Doctor Marcos Escobar: "Un Web Service es un componente de software que se comunica con otras aplicaciones codificando los mensaje en XML y enviando estos mensaje a travs de protocolos estndares de Internet tales como el HTTP. Intuitivamente un Web Service es similar a un sitio Web que no cuenta con un interfaz de usuario y que da servicio a las aplicaciones en vez de a las personas. Un Web Service, en vez de obtener solicitudes desde el navegador y retornar pginas Web como respuesta, lo que hace es recibir solicitudes a travs de un mensaje formateado en XML desde una aplicacin, realiza una tarea y devuelve un mensaje de respuesta tambin formateado en XML. Se esta promocionando SOAP (Simple Object Access Protocol) como estndar de los mensajes para los Web Services. Un mensaje SOAP es similar a una carta: es un sobre que contiene una cabecera con la direccin del receptor del mensaje, un conjunto de opciones de entrega (la informacin de encriptacin), y un cuerpo o body con la informacin o data del mensaje. Proveedores lderes promocionan los Web Services como un modelo de programacin para la comunicacin entre aplicaciones. Estas compaas piensan que la conexin de aplicaciones a travs de Internet mejorar la capacidad de las empresas para trabajar conjuntamente con sus socios de negocio, proveedores y clientes. Creando una capa de Web Services sobre una aplicacin corporativa existente, las organizaciones podrn permitir que sistemas externos puedan invocar las funciones de la aplicacin a travs de Internet (o una intranet corporativa) sin tener que modificar la aplicacin misma. Por ejemplo, varias compaas estn hoy en da creando Web Services que actan como front end para aplicaciones de entrada de rdenes que estn

residentes internamente en un mainframe. Estas compaas permiten a los sistemas de compras de sus clientes enviar rdenes de compra a travs de Internet. Poner una capa de Web Services sobre las aplicaciones existentes es una solucin muy interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y as reducir los costos de integracin." Dentro de la gran variedad de definiciones de servicios Web, estas suelen tener en comn lo siguiente: Los servicios Web XML ponen al servicio del usuario Web toda su funcionalidad a travs de un protocolo estndar en la Web. En muchos casos, el protocolo usado es SOAP. Los servicios Web XML proporcionan una forma de describir las interfaces con el suficiente detalle para permitir a los usuarios construir una aplicacin que se comunique con ellos. Esta descripcin se proporciona normalmente en un documento XML llamado WSDL (Web Services Description Language). Los servicios Web XML se encuentran registrados por lo que un usuario los puede localizar fcilmente. Esto se hace con UDDI (Universal Discovery Description and Integration). Se puede definir un servicio Web XML como un servicio software disponible en la red a travs de SOAP o XML-RPC (Remote Procedure Calling), descrito con un fichero WSDL y registrado con UDDI [9]. Estos servicios proporcionan mecanismos de comunicacin estndares entre diferentes aplicaciones, que interactan entre s para presentar informacin dinmica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinacin para realizar operaciones complejas, es necesaria una arquitectura de referencia estndar.

2.1

SOAP

SOAP es uno de los protocolos de comunicacin para los servicios Web XML, es una especificacin que define el formato de un mensaje XML. Hay una parte de la especificacin de SOAP que describe como representar los datos de un programa como XML y como usar SOAP para realizar llamadas a procedimientos remotos pasando los argumentos necesarios para invocarlos. Los datos pueden ser transmitidos a travs de HTTP, SMTP (Simple Mail Transfer Protocol), etc. SOAP especifica el formato de los mensajes. El mensaje SOAP est compuesto por un sobre (Envelope), cuya estructura est formada por los siguientes elementos: cabecera (Header) y cuerpo

(Body). En la siguiente figura (Fig 1), se tiene una representacin de la composicin de un mensaje SOAP.

Fig 1.

Mensaje SOAP

Las limitaciones de SOAP provienen de la diferencia entre su especificacin y las muchas implementaciones que existen. La mayor parte de los desarrolladores que usan SOAP no escribe directamente los mensajes y usa una herramienta de desarrollo para crearlos, estos no suelen ser compatibles con los creados por otras herramientas de desarrollo, esta limitacin no provienen de SOAP sino de la herramienta en particular.

2.2

WSDL

Un archivo WSDL es un documento XML que describe un conjunto de mensajes SOAP y su modo de intercambio. La notacin que se usa en el documento para describir el formato se basa en el XML Schema lo que permite la que los servicios Web XML sean accesibles por una gran variedad de plataformas y lenguajes de programacin.

2.3

UDDI

Se puede definir como las pginas amarillas de los servicios Web. Se puede buscar por compaas los servicios que necesitas y contactar con ellas para la adquisicin del servicio. Como es natural, se puede ofrecer un servicio Web sin registrar lo en UDDI, pero ser ms complicado la localizacin por parte de los usuarios. El directorio UDDI es un fichero XML que describe los negocios y los servicios que ofrecen. Cada entrada se divide en tres partes, las pginas

blancas describen la compaa que ofrece el servicio, las paginas amarillas agrupa las industrias por categoras y las pginas verdes describen la interfaz del servicio con el suficiente detalle para poder utilizarlo. El documento que define un servicio recibe el nombre de Modelo de tipos o tModel. En muchos casos tModel contiene un archivo WSDL que describe un interfaz SOAP para un servicio XML, pero normalmente, el tModel es suficiente para describir un servicio.

2.4

Infraestructura de los servicios Web XML

Como se dijo anteriormente, los servicios Web deben de ser capaces proporcionar un servicio a las diferentes aplicaciones con independencia de la plataforma y del lenguaje de programacin con el objetivo de funcionar en la heterogeneidad de la red. Las principales caractersticas que deben poseer son: Correspondencia imprecisa: El cliente y proveedor del servicio slo deben conocer uno del otro el formato de los mensajes con el cual se comunican. Comunicacin ubicua: Que sea accesible desde cualquier lugar a travs de la red. Formato de datos universal: mediante el uso de estndares abiertos en mtodos de comunicaciones de patentados de bucle cerrado de forma que cualquier sistema que adopte estos estndares abiertos pueda comprender los servicios Web XML. Los servicios Web XML emplean una infraestructura que proporciona lo siguiente: un mecanismo de descubrimiento para localizar servicios Web XML, una descripcin de servicio para definir cmo se deben utilizar esos servicios y formatos de conexin estndar para la comunicacin. En la figura (Fig 2), se muestra un ejemplo de esta infraestructura.

Fig 2.

Infraestructura de los Servicios Web

 Directorio: Proporciona una forma de localizar de forma centralizada los diferentes servicios Web que estn disponibles. Descubrimiento de servicios Web XML: Consiste en localizar los documentos que describen mediante WDSL un determinado servicio. Descripcin de servicios Web XML: La descripcin del servicio se proporciona mediante le fichero WDSL. Formato de conexin de servicios Web XML: El formato de comunicacin entre los servicios Web es abierto. El protocolo de comunicacin ms extendido es SOAP aunque existen otros como XML-RPC

Posibles riesgos

Son muchas las expectaciones alrededor de Servicios Web, porque el mercado de aplicacin es muy amplio. Pero tambin tiene sus puntos oscuros: Los Servicios Web hacen uso de las mismas tecnologas que han sido atacadas en tantas ocasiones. Usando Servicios Web, la seguridad de una empresa puede verse comprometida. La ausencia de tcnicas de seguridad estndar es un obstculo para la adopcin de la tecnologa. La calidad de un Servicio Web es un parmetro que no queda demasiado claro, pero cuya medida es fundamental a la hora de desarrollar un servicio maduro.

Problemas de Interconexin

La mayor parte de los problemas de interoperabilidad [2] encontrados en SOAP provienen del protocolo de transporte o bien de los motores de XML. As se pueden agrupar en las siguientes categoras. Problemas de transporte HTTP Problemas de XML Discontinuidad de SOAP

4.1.1

Problemas de transporte HTTP

HTTP es el protocolo ms utilizado para las llamadas a procedimientos remotos y debe existir una interoperabilidad con SOAP para el funcionamiento correcto. Un ejemplo de este problema se da en el encabezado de HTTP al usar SOAPAction. Se le pueden asignar varios diferentes valores tales como SOAPAction=http://tempuri.org/ El valor de SOAPAction debe aparecer entre comillas pero su valor tambin puede ser nulo sin necesidad de que aparezca nada despus del igual. En ocasiones el servidor puede precisar la presencia de un valor nulo en esta cabecera, pero no todas las API de HTTP lo permiten y por tanto sera necesario repararlo o que el servidor no precisase de tal valor. 4.1.2 Problemas de XML

Otro tipo de problema puede derivar del anlisis del fichero XML y el control de los esquemas XSD (XML Schema Definition). SOAP utiliza XML y esquemas XML en el ncleo, de modo que el control de la interoperabilidad de ambos es necesario para la interoperabilidad de SOAP. Tambin se han detectado un problema de interoperatividad entre el anlisis de cdigo XML y el transporte HTTP en la marca de orden de byte BOM (Byte Order Mark). Cuando se envan datos a travs de HTTP se puede especificar la codificacin en el encabezado Content-Type: text/xml; charset=utf-8 y tambin en el cdigo correspondiente al XML. En el caso de estar usando la codificacin UTF-8, no es necesario especificar la marca BOM si ya se hizo en la cabecera pero si en le caso de utilizar la codificacin UTF-16. POST http://www.whitemesa.net/soap12/add-test-rpc HTTP/1.1 Content-Type: application/soap+xml; charset=utf16; action="" ... OxFF0xFE<?xml version="1.0" encoding="utf-16"?> Los bytes que aparecen justo antes del comienzo del fichero XML indican la codificacin, en este caso 0xFF0xFE representa la codificacin UTF-16, little-endian.

4.1.3

Problemas de SOAP

Un problema que se puede encontrar en la especificacin de SOAP se puede encontrar al especificar en el encabezado el atributo mustUnderstand con valor 1, en este caso, si no se entiende el encabezado de SOAP, se debera de generar un error. Inicialmente no todas las implementaciones lo hicieron.

Seguridad

El hecho de publicar una serie de servicios Web accesibles a todo el mundo puede suponer una ventaja comercial, pero en ocasiones, la seguridad en determinados servicios puede ser de vital importancia y es necesario evitar acceso de terceros a la informacin que viaja en los mensajes SOAP o la alteracin de los mismos y evitar ataques de negacin de servicio [1]. Por lo que ser necesario tener en cuenta los siguientes factores para asegurar la seguridad del servicio [8]: Confidencialidad: los mensajes no puedan ser ledos por terceros Integridad: para asegurar a los receptores que el mensaje no ha sido modificado Autenticacin: asegurar la procedencia del mensaje, realmente es quin dice ser Autorizacin: para determinar si se tienen privilegios para realizar una determinada accin No repudio: para poder demostrar que un determinado cliente realiz una determinada accin Actualmente, los Servicios Web estn siendo ampliamente aceptados por las empresas para el desarrollo de software de uso interno. De este modo, los servicios pueden implementar toda su funcionalidad y permanecer seguros tras el Cortafuegos de la compaa. Los desarrollos actuales no ayudan a la cooperacin entre las empresas ya que no hay ningn estndar establecido sobre las tcnicas de seguridad. Debido a la tecnologa que es usada por los Servicios Web, y en concreto al uso de SOAP, las tcnicas de seguridad convencionales que se han venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se intercambia realiza mltiples saltos y es enrutado a travs de numerosos puntos antes de que alcance su destino final. Es por ello, que los Servicios Web necesitan tecnologas que protejan los mensajes desde el principio hasta el final. Existen un conjunto de tcnicas que se pueden usar para garantizar la seguridad a nivel de mensaje. Estas son:

Encriptacin XML: Evita que los datos se vean expuestos a lo largo de su recorrido. Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de modo que este usuario es el nico que puede modificar dichos datos. XKMS (XML Key Management Specification) y los Certificados: XKMS define Servicios Web que se pueden usar para chequear la confianza de un certificado de usuario. SAML (Security Assertion Mark-up Language) y Autorizacin: SAML hace posible que los Servicios Web intercambien informacin de autentificacin y autorizacin entre ellos, de modo que un servicio Web confe en un usuario autentificado por otro Servicio Web. Validacin de datos: Permite que los Servicios Web reciban datos dentro de los rangos esperados. Adems, tambin hay tcnicas que permiten mantener la seguridad a otros niveles. La seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicacin de un Servicio Web: proveedor, agente y consumidor del servicio. De este modo, nadie podr registrar servicios en el papel de un proveedor o hacer uso de ellos sin contar con los permisos adecuados. En ocasiones, la seguridad se ha conseguido mediante el uso de mtodos externos a los servicios Web, mediante el uso de SSL (Security Socket Layers) o HTTPS (Hypertext Transfer Protocol Security), esta solucin no es aceptable aunque segura debido a que los servicios Web no se limitan nicamente al protocolo HTTP, y deben poseer un sistema pensado especficamente para su mecnica y procedimientos. Para solucionar este problema, se crea la especificacin WS-Security que define una serie de extensiones para el protocolo SOAP, que permite el intercambio entre el cliente y el servidor de tokens de seguridad. El intercambio de tokens junto con mecanismos de encriptacin y firmado, permiten conseguir los factores anteriormente nombrados. Al igual que lo que ocurra con bastantes problemas de interoperatividad, segn Stamos, la mayor parte de los problemas de seguridad con los que nos encontramos hoy en da son consecuencia del uso de herramientas que facilitan la creacin de servicios ocultando la complejidad. Esto tiene como consecuencia que los desarrolladores ignoren las implicaciones de seguridad que el software realiza y con ello se evita que el desarrollador se pueda anticipar a las situaciones de riesgo.

5.1.1

Proteccin de los mensajes

El objetivo es la proteccin del contenido del mensaje de ser interceptado (confidencialidad) y de modificaciones ilegales (integridad). Esto se puede conseguir mediante una firma digital en el cuerpo, en la cabecera o en el adjunto o una combinacin de ellos. El modelo de seguridad de los mensajes se expresa en trminos de una serie de tokens de seguridad combinado con la firma digital. Los tokens de seguridad firmados proporcionan un mecanismo para verificar al emisor del mensaje, de forma que el cliente pueda autentificar la procedencia de los mismos. El receptor de un mensaje rechazara aquellos mensajes con una firma no vlida o bien cuando no traiga emisor o no est autorizado. 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 diseado para soportar mltiples firmas por diferentes actores y se puede extender para soportar nuevos mecanismo de firma. La confidencialidad se consigue mediante la encriptacin del fichero XML en conjuncin con tokens de seguridad en porciones del mensaje SOAP para que sea confidencial. Al igual que en el caso anterior, est preparado para soportar procesos adicionales de encriptacin y operaciones por mltiples actores. 5.1.2 Elementos de seguridad

El bloque de la cabecera se puede adjuntar informacin sobre el receptor o intermediarios de un mensaje. Este bloque puede ser modificado por lo intermediarios aadiendo nuevos elementos de seguridad a los existentes, con lo que un mensaje puede tener varios bloques de seguridad dirigidos para receptores diferentes o incluso uno dirigido a todos ellos. Para ello, hay que extender el protocolo SOAP para aceptar un nuevo espacio de nombres y un nuevo token de seguridad. Adicionalmente existen una serie de tokens [5] para aadir informacin para la identificacin de los usuarios como es el caso de UsernameToken, en el que se pueden incluir el identificador y la contrasea. Otra posibilidad es usar el elemento BinarySecurityToken para especificar que un token est codificado en binario, esto nos permite el uso de certificados, adems se proporciona informacin adicional del tipo de codificacin y los tipos de valores que puede tomar. El cliente y el servidor se tienen que poner de acuerdo en el tipo de codificacin (Base64) e

11

implementar las bibliotecas necesarias para poder codificar y decodificar los tokens de seguridad intercambiados. Otro mtodo de seguridad, sera proporcionar una referencia una URL en la que la aplicacin pudiera solicitar los tokens de seguridad. Adems de los tokens ya nombrados, existen otra serie de tokens destinados a satisfacer los factores anteriormente nombrados. Entre ellos los ms importantes son: Integrity. Para satisfacer el factor de integridad Confidentiality. Para satisfacer el factor de confidencialidad Visibility. Para permitir que partes del mensaje vayan sin encriptacin

Calidad

Ya existen algunas herramientas especficamente diseadas para medir la calidad de los Servicios Web, pero sigue siendo necesaria una estandarizacin sobre este tema. Los resultados sobre la calidad de diferentes Servicios Web, servirn como parmetro de comparacin y ayudarn al consumidor a decantarse por un servicio u otro. Para que un Servicio Web se ejecute con correccin y satisfaga las expectativas creadas, a parte del precio, habr que tener en cuenta una serie de parmetros como por ejemplo, que los resultados obtenidos del mismo sean los esperados o que el entorno de uso sea amigable. Otro elemento importante es la integracin. Aunque tericamente los Servicios Web proporcionan conectividad con cualquier software de un modo transparente, cada proveedor de servicios puede adoptar soluciones diferentes que resultan ms o menos adecuadas para el consumidor. Analizando la escalabilidad se comprobar el grado de modularidad y flexibilidad del servicio. Por ltimo, tambin sera interesante analizar las caractersticas que ofrece el proveedor de Servicios Web. Actualmente no hay definidos estndares sobre este tema, pero la mayora de las empresas ya est demandando algn tipo de acuerdo o contrato con los proveedores, de modo que se pueda garantizar la calidad y la fiabilidad de los servicios por los que se paga.

Estandarizacin

Los Servicios Web se basan XML, estndar que ha sido universalmente aceptado. Pero la situacin para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran todava en desarrollo y pueden ser objeto de cambios. Por esta razn la mayora de las empresas esperan a que estos protocolos sean ms universales antes de profundizar en esta tecnologa. Actualmente, ni WSDL, ni UDDI han sido oficialmente reconocidos por ningn organismo de estandarizacin. SOAP es el nico que en este momento lo est recomendado por parte de World Wide Web Consortium a partir de junio del 2003. SOAP y WSDL estn siendo ampliamente usados, pero de momento UDDI no ha tenido el mismo xito. El principal motivo es que las tcnicas de seguridad son todava muy inmaduras y las compaas prefieren hacer uso de registros privados para dar soporte a intercambios privados de Servicios Web. Algunas de las empresas ms importantes en el desarrollo de Negocio Electrnico han creado el WS-I: organizacin para la Interoperabilidad de los Servicios Web. El objetivo de dicha organizacin es la promocin de la estandarizacin de los Servicios Web de modo que se fomente la cooperacin e interoperabilidad entre las compaas y mercados

Lneas de trabajo futuras

El trabajo sobre la plataforma de servicios Web continuar en el futuro, y aparecern mejoras en tres reas fundamentales. En primer lugar, se aadirn servicios de ms alto nivel. Todo el mundo est de acuerdo en que debe existir un modo estndar de seguridad de servicios Web, enrutar mensajes, garantizar una entrega fiable de mensajes, definir semntica transaccional, etc. Estas caractersticas de propsito general se expanden ms all de los dominios del problema y no hay ninguna razn por la que cada desarrollador de servicios Web deba implementarlas individualmente. En segundo lugar, seguirn estandarizndose especificaciones. El ciclo de vida de las especificaciones de servicios Web tpicamente progresa desde una propuesta hasta un estndar de facto y desde ste hasta un estndar real. Las empresas siguen proponiendo nuevas especificaciones como aadidos a la plataforma de servicios Web y la industria en su conjunto necesitar acordar cules adoptar. Esas especificaciones necesitarn a continuacin ser estandarizadas. Hemos consultado algunos doctores de diferentes Universidades que sabemos estn realizando proyectos de investigacin en esta rama y por ejemplo del Doctor Jaime Navn de la Universidad de Chile

13

[7] nos menciono va e-mail que aun existe gran confusin en cuanto a los estndares. Los nicos que estn un poco mas firme establecidos son los bsicos: SOAP, UDDI y WSDL pero existe una serie de estndares de mas alto nivel que permitiran realmente implementar las arquitecturas orientadas a servicios de la que tanto se ha hablado (seguridad, transacciones, etc.) Otra cosa muy interesante es el surgimiento de servicios Web implementados de un modo completamente distinto (mucho ms simple) conocidos como REST (Representational State Transfer). El entusiasmo por REST se basa en la simplicidad de la solucin y es un poco una reaccin a toda la complejidad de estndares que actualmente se tiene. En tercer lugar, los kits de herramientas y marcos de trabajo seguirn mejorando. Adems de servicios de ms alto nivel como la seguridad y los objetos adjuntos, se aadir soporte para protocolos de transporte alternativos como SMTP o TCP. De modo ms importante, los modelos de programacin migrarn desde los servicios de tipo RPC hacia servicios centrados en documentos, para promover un acoplamiento dbil. Todos estos cambios ocurrirn en paralelo, mientras los desarrolladores continan desarrollando e implantando sistemas basados servicios Web. Estaremos preguntndonos cmo podemos utilizar los servicios Web cuando la plataforma todava est evolucionando. Las herramientas y marcos de trabajo de los servicios Web actuales proporcionan suficiente funcionalidad bsica para desarrollar interesantes aplicaciones distribuidas que envan mensajes SOAP sobre HTTP. Algunos servicios de mayor nivel como WS-Security estn empezando a cuajar con el soporte de diversas herramientas nuevas como el kit Web Services Enhancements. Pero otros servicios estn todava en fase de desarrollo preliminar a medida que las especificaciones se van revisando y las primeras implementaciones exponen reas en las que las especificaciones necesitan solidificarse. Mientras tanto, podemos apoyarnos en mecanismos HTTP tradicionales para implementar seguridad y dems caractersticas. El entendimiento colectivo de SOAP Y WSDL se mejor sustancialmente gracias al intento de implementacin de sistemas basados en ambos estndares por parte de mltiples usuarios. Cuanto ms estrechamente trabajen los usuarios con las nuevas especificaciones, mejor resultar la plataforma de servicios Web global.

8.1

Lneas de Investigacin

Estas son algunas de las reas identificadas por el Doctores de diferentes Universidades entre ellos: Jaime Navn C. de la Universidad de Chile [8],

Juan Manuel Cueva Lovelle de la Universidad de Oviedo Espaa [4], Michael Gould de la Universidad Jaume Castelln Espaa [6]; son: Arquitecturas e Ingeniera Web Un rea que tiene gran auge son los Geographical Information Systems Sistemas de Informacin Geogrfica y algunos ejemplos en esta rea estn: Proyecto europeo (IST) ACE-GIS "Adaptable and composable ecommerce and geographic services" (2002-2004) Proyecto GMES "AWARE" (servicios Web para recursos hdricos) iniciado el 1 de Julio de 2005. AWARE es un proyecto de investigacin que proveer herramientas innovadoras de monitoreo y prediccin de la disponibilidad del agua en la nieve del mundo. Mediante servicios Web geogrficos integrados a la observacin satelital de datos. Comparacin de plataformas de Servicios Web Nuevas aplicaciones de los servicios Web Otro factor importante en la investigacin es el poder contar con recursos financieros, y en esta rea los servicios Web hemos encontrado que existen proyectos remunerados econmicamente para incentivar a investigadores a incursionar en esta rea, como por ejemplo: Instituto de Investigacin en Ingeniera de Aragn ofrece trabajo en proyectos de I+D para empresas y administraciones. Temticas relacionadas con Web semntica, servicios Web, geoprocesamiento interoperable y sistemas de informacin geoespacial. Con una remuneracin base de 1200 euros mensuales.

Conclusiones

El xito de los Servicios Web reside en que se basa en estndares conocidos en los que ya se tiene confianza, como el XML. Adems, el uso de los Servicios Web aporta ventajas significativas a las empresas. El principal objetivo que se logra, es la interoperabilidad y la integracin. Mediante los Servicios Web, las empresas pueden compartir servicios software con sus clientes y sus socios de negocio. Esto ayudar a las compaas a escalar sus negocios, reduciendo el coste en desarrollo y mantenimiento de software, y sacando los productos al mercado con mayor rapidez. La integracin de aplicaciones har posible obtener la informacin demandada en tiempo real, acelerando el proceso de toma de decisiones. La evolucin de Internet hacia

15

los Servicios Web, mejorar los resultados globales de las empresas, reduciendo sus gastos y guindolas hacia una mejora progresiva de la calidad. Proveedores lderes promocionan los Web Services como un modelo de programacin para la comunicacin entre aplicaciones. Estas compaas piensan que la conexin de aplicaciones a travs de Internet mejorar la capacidad de las empresas para trabajar conjuntamente con sus socios de negocio, proveedores y clientes. Como hemos visto los servicios Web son una alternativa para integrar soluciones y aplicaciones actuales entre empresas. Esta integracin es necesaria para brindar mejores soluciones a clientes y tener una ventaja altamente competitiva en el mercado. Ya se ha incursionado en este mbito de desarrollo de servicios Web con buenos resultados en muchos casos, sin embargo aun quedan pendiente el establecimiento de estndares para hacer este proceso de integracin mas fluido, sencillo y seguro, ya que las empresas estn apostando a mover sus aplicaciones a aplicaciones bajo tecnologa Web. Es recomendable que las polticas de seguridad se firmen para evitar alteraciones en ellas. En caso de no estar firmadas o no se pueda confirmar el emisor, es mejor no aceptarlas. Como se dijo anteriormente, hay que ser precavido en el uso de herramientas que facilitan la creacin de servicios Web, puesto que su uso implica que el desarrollador no tenga conocimientos sobre los mecanismos de seguridad que no proporciona.

10 Referencias
[1]Atkinson, B., Della-Libera, G., Hada, S., Hondo M., Hallam-Baker, P., Klein, J., LaMacchia, B., Leach, P., Manferdelli, J., Maruyama, H., Nadalin, A., Nagaratnam, N., Prafullchandra, H., Shewchuk, J., Simon, D., Kaler, C. Web Services Security (WSSecurity). (2002) IBM. http://www-128.ibm.com/developerworks/library/wssecure/#majorhead3 [2]Ballinger, K. Interoperabilidad de los servicios Web y SOAPs. Microsoft Corporation. (2003)http://www.microsoft.com/spanish/msdn/articulos/archivo/280901/voices/soapinterop bkgnd.asp [3]Cabrera, L., Kart, C., Box, D.. An Introduction to the Web Services Architecture and Its Specifications. Microsoft Corporation. (2004) http://msdn.microsoft.com/webservices/webservices/understanding/advancedwebservices/de fault.aspx?pull=/library/en-us/dnwebsrv/html/introwsa.asp#introwsa-upd_topic6a [4]Cueva Lovelle, Juan Manuel. Web Engineering and Web Services Ingeniera Web y Servicios Web (2004) http://www.di.uniovi.es/~cueva/asignaturas/doctorado/2004/IngWebPonti.html [5]Gonzlez, O. Seguridad en Servicios http://www.samelan.com/oscargonzalez Web (I). Dr. Dobbs. (2003)

[6]Gould Michael: Investigacin http://www.terra.es/personal/mgould/ImasD.html [7]Navn, Jaime. reas de Investigacin. http://www2.ing.puc.cl/~jnavon/magister.html

Desarrollo. de Tesis.

(2006). (2006)

Ofrecimiento

[8]Seely, S. Seguridad HTTP y servicios Web de ASP.NET. Microsoft Corporation. (2002) http://www.microsoft.com/spanish/msdn/articulos/archivo/111002/voices/httpsecurity.asp [9]Wolter, R. XML Web Services Basics. Microsoft Corporation. (2001) http://msdn.microsoft.com/webservices/webservices/understanding/webservicebasics/default .aspx?pull=/library/en-us/dnwebsrv/html/webservbasics.asp

11 Bibliografa
Gua del desarrollador de .NET Framework. Infraestructura de servicios Web XML. Microsoft Corporation. http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/cpguide/html/cpconweb servicesinfrastructure.asp WebShere Aplication Server Express. Web Services-Interoperability Basic Profile. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.webspher e.express.doc/info/exp/ae/cwbs_wsiprofile.html Seguridad en Servicios http://www.iec.csic.es/criptonomicon/susurros/susurros37.html Seguridad en Cmputo. Seguridad en http://www.seguridad.unam.mx/noticias/?noti=1904 Web Services Security Policy Language http://schemas.xmlsoap.org/ws/2002/12/secext/ los Web Servicios XML Web. Policy)

(WS-Security

W3C World Wide Web Consortium. SOAP Version 1,2 Part 0 http://www.w3.org/TR/soap12part0/ Servicios Web en plataforma .NET http://www.desarrolloweb.com/manuales/54 W3C World Wide Web Consortium. Gua Breve http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb de Servicios Web.

Web Services and Other Distributed Technologies Developer Center: Web Services Enhancements (WSE) http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx Futuro de los Servicios Web XML. Microsoft Corporation. http://www.microsoft.com/spanish/msdn/articulos/archivo/151102/voices/elfuturo.asp Charles Piller, 2006 Gates says services are the future for computers and Microsoft http://www.detnews.com/apps/pbcs.dll/article?AID=/20060314/BIZ04/603140305/1013 AWARE A tool for monitoring and http://www.aware-eu.info/eng/home.htm forecasting Available WAter Resource

Instituto de investigacin en ingeniera de Aragn http://i3a.unizar.es/ficha_beca.php?ver=42