1. INTRODUCCIN A LOS SERVICIOS WEB 1.1. Introduccin 1.2. Objetivos 1.3. Breve historia de la programacin distribuida 1.4.

Qu son los Servicios Web? 1.5. Principales Frameworks de Desarrollo de Servicios Web 1.6. Cuestionario de autoevaluacin 1.7. Conclusiones

1.1. Introduccin
A lo largo del presente captulo se introducirn los conceptos principales relacionados con los Servicios Web, principales exponentes de un nuevo paradigma para la creacin de aplicaciones distribuidas. Los Servicios Web son aplicaciones modulares autodescriptivas, las cuales pueden ser publicadas, localizadas, e invocadas desde cualquier parte de Internet. El elemento clave que se puede encontrar detrs de los Servicios Web es el XML (Extensible Markup Language), utilizado como ncleo de la mayora de las tecnologas existentes para los Servicios Web. Es por ello que normalmente se conoce a los Servicios Web como Servicios Web XML.

1.2. Objetivos
Conocer brevemente la historia de la programacin distribuida. Conocer la arquitectura de los Servicios Web XML. Conocer algunos de los principales frameworks de desarrollo de Servicios Web.

1.3. Breve historia de la programacin distribuida

Los comienzos
No ha pasado demasiado tiempo desde que aquellas aplicaciones serias que se utilizaban en el da a da de las empresas corran bajo un ordenador enorme llamado mainframe. Poco tiempo despus, los empleados empezaron a conectarse con dicha mquina desde su sitio de trabajo y enviar todo tipo de comandos de texto plano a la misma por medio de los novedosos terminales. Sin embargo, lo que supuso una verdadera revolucin en la forma de trabajar en las empresas fue la aparicin de los ordenadores personales o PCs, ya que supuso que la gente estuviese encantada con la idea de tener su propio ordenador y la capacidad de correr sus propias aplicaciones en l. En estas fechas (los aos 80), los desarrolladores no se dedicaban demasiado a los protocolos de comunicaciones. Conseguir que dos aplicaciones se hablasen entre s dentro de la misma mquina ya era un logro. Fue a principios de los 90 cuando aparecieron los dos primeros frameworks relacionados con la programacin distribuida. Fueron COM (Component Object Model) de Microsoft y CORBA (Common Object Request Broker Architecture) del OMG (Object Management Group). Estos frameworks permitan al programador escribir y encapsular cdigo

binario, conocido como componentes, los cuales podan ser llamados libremente desde aplicaciones que soportasen el mismo framework. Sin embargo, estos frameworks no eran interoperables entre s. Debe tenerse en cuenta que en los comienzos resaltados en el prrafo anterior, lo normal era tener comunicaciones aplicacin-aplicacin, creadas sobre el propio sistema operativo del ordenador, y que no fue hasta principios de los 90, cuando aparecieron las redes de rea local, las cuales supusieron el impulso definitivo a las comunicaciones de bajo nivel mquina-mquina. Una vez se extendieron las redes de rea local entre ordenadores personales, COM y CORBA fueron extendidos para soportar la comunicacin a travs de la red. Es por ello que el OMG cre IIOP (Internet Inter-ORB Protocol) como el protocolo bsico de CORBA, mientras que Microsoft apareci con DCOM (Distributed COM) como su protocolo para atravesar los lmites de la mquina. Tambin apareci tras IIOP y DCOM un nuevo competidor utilizado por toda la comunidad Java: el protocolo RMI (Remote Method Invocation). Gracias a la utilizacin de cualquiera de estos tres protocolos, una mquina que los soporte puede hacer llamadas a travs de la red a otros componentes que residan en otros ordenadores. Esto se llevaba a cabo por medio de llamadas a procedimientos remotos o RPCs. De esta forma, un procedimiento alojado en una mquina remota era llamado desde una aplicacin alojada en otra mquina. El procedimiento procesaba la llamada y devolva un resultado a la aplicacin llamante. Se recuerda que la interoperabilidad entre estos frameworks era ms bien imposible, ya que si que se quera conseguir supona pagar un alto precio y esfuerzo. No es tarea de este curso explicar cmo eran CORBA, DCOM y RMI, pero si el lector est interesado en ellos, puede visitar los siguientes enlaces:

CORBA/IIOP: http://www.omg.org y http://www.corba.org DCOM: http://www.microsoft.com/com y http://www.microsoft.com/com/tech/dcom.asp RMI: http://java.sun.com/products/jdk/rmi/index.html

Sin embargo, s que es importante mencionar que tanto DCOM como RMI son protocolos que siguen el patrn peticin/respuesta, o lo que es lo mismo, estn hechos para trabajar de forma sncrona y por tanto no tienen soporte para el intercambio de mensajes de forma unidireccional. Es aqu donde merece la pena comentar ciertas tecnologas que dan solucin a lo anterior: Java Message Service (JMS) y Microsoft Message Queuing (MSMQ). Estas tecnologas asncronas dan soporte, entre otros, al encolado de mensajes y al patrn publicar-suscribir.

Internet y la Web
La forma de conectar aplicaciones entre s utilizando cualquiera de los protocolos anteriores funcionaba de forma correcta siempre que los ordenadores implicados estuviesen dentro de la misma red de rea local. Sin embargo, con la aparicin de Internet y de la Web, las redes crecieron desmesuradamente, convirtindose en redes muy distribuidas y extremadamente descentralizadas. Ahora nadie puede

decidir qu sistema operativo o lenguajes de programacin se van a utilizar en los ordenadores conectados a Internet. Es por ello que las reglas que antes funcionaban tan bien en redes de rea local no lo hacen igual en Internet. A continuacin se muestran algunos de los retos a los que deban enfrentarse los protocolos existentes.

Retos de los protocolos existentes.

A la hora de conseguir comunicacin aplicacin-aplicacin fuera de los lmites de una mquina, cualquiera de los protocolos vistos hasta ahora (CORBA, DCOM y RMI, o incluso JMS y MSMQ) servira para hacerlo. Sin embargo, todos estos protocolos tienden a ser bastante complejos, y por tanto su configuracin e instalacin suele ir acompaada de errores. Si adems hay que aadir seguridad y gestin de las transacciones, la instalacin y la configuracin se tornan ms complicadas si cabe. Otro nuevo obstculo ahora es la comunicacin a travs de Internet. Las tecnologas anteriores tienen como requisito la simetra, o lo que es decir, que ambos extremos de la comunicacin tengan instalado el mismo tipo de modelo de objeto distribuido. Asegurar el cumplimiento de este requisito a travs de Internet es simplemente imposible. Otro problema es que los protocolos anteriores han sido hechos pensando en un tipo concreto de mquina sobre la que correr as como en un tipo de lenguaje de programacin concreto, para as sacar el mximo partido al protocolo. Por ejemplo, CORBA/IIOP utiliza Java como lenguaje primario de programacin, mientras que DCOM ha sido diseado para mquinas con el sistema operativo Windows. Los intentos de migracin de estos protocolos a otros entornos o lenguajes no han logrado ser muy satisfactorios. Otra limitacin es la dificultad que tienen estos protocolos para poder trabajar a travs de firewalls o servidores de proxy. No suelen llevarse bien con los firewalls debido a que sus arquitecturas normalmente les obligan a utilizar nmero de puerto no habituales, los cuales suelen ser cortados por los administradores de red. Es por ello que las comunicaciones a travs de Internet no suelen llegar al destino. Por ltimo, a pesar que todos estos protocolos son conocidos y respetados, la industria no se ha decantado abiertamente por ninguno de ellos. Es por ello que la falta de aceptacin ha marcado tambin la decadencia de estos protocolos. La solucin para obtener comunicacin aplicacin-aplicacin desde una mquina a otra, independientemente del sistema operativo, del lenguaje de programacin, o del modelo de objeto distribuido utilizados, pasa por utilizar los estndares existentes de Internet. Sin embargo, esto no quiere decir que estos protocolos dejen de ser utilizados dentro de las empresas, ya que su correcto funcionamiento ha sido ampliamente probado y reconocido. Este es el momento en el que entran en escena los Servicios Web. Con la aparicin de Internet y de la Web, las aplicaciones Web vieron la luz. Poco a poco estas fueron evolucionando, pasando de ser meras islas de informacin a integrar informacin proveniente de distintas fuentes (otras aplicaciones Web). Los Servicios Web han sido los encargados de resolver la necesidad de

interoperabilidad entre estas aplicaciones Web utilizando para ello XML. Ahora se deben ver las aplicaciones Web como funciones (o en otras palabras, Servicios Web) de modo que una aplicacin Web llama a otra, como lo hara una aplicacin tradicional, invocando una funcin y obteniendo una respuesta. O en el caso de comunicaciones asncronas, una aplicacin Web mandara un mensaje a otra, sin la necesidad de obtener una respuesta inmediata. Por tanto, en el apartado siguiente se comienza con el estudio de los Servicios Web.

1.4. Qu son los Servicios Web?

El W3C (World Wide Web Consortium) define los Servicios Web como Sistemas software diseados para soportar la interaccin/interoperabilidad mquina-mquina sobre una red. Estos sistemas tienen su interfaz descrita en un formato procesable por un ordenador, conocido como WSDL (Web Service Description Language). De esta forma, otros sistemas sern capaces de interactuar con los Servicios Web de una manera preestablecida por su descripcin a travs de mensajes SOAP (Simple Object Access Protocol), tpicamente enviados usando HTTP con una serializacin XML en relacin con otros estndares relacionados con la Web. Se pueden definir de manera ms sencilla como aplicaciones modulares autodescriptivas, que pueden ser publicadas, localizadas, e invocadas desde cualquier parte de la Web o desde dentro de cualquier red de rea local basada en los estndares abiertos de Internet. Combinan lo mejor de la programacin basada en componentes y la programacin Web, y vienen en la forma de mdulos que pueden ser reutilizados sin tener que preocuparse por la forma en que han sido implementados, en qu lenguaje, o en qu sistema operativo.

The Organization for the Advancement of Structured Information Standards y el World Wide Web Consortium son los responsables de la estandarizacin y arquitectura de los servicios Web. La industria, en su inters por el desarrollo de los servicios Web, ha creado la WS-I (Web Services Interoperability Organization) cuya intencin es la integracin de los estndares que garanticen y mejoren la interoperabilidad de los Servicios Web. El conjunto de servicios y protocolos para los Servicios Web se conoce comnmente como la Pila de Protocolos de Servicios Web y son bsicamente utilizados para definir, localizar, implementar y conseguir que un servicio Web interacte con otro. Este conjunto est conformado esencialmente de cuatro subelementos:

Transporte. Mensajera XML. Descripcin del servicio Web. Descubrimiento de Servicios Web.

A continuacin de describen brevemente cada uno de estos elementos.

1.4.1 Transporte
Este servicio es el encargado del transporte de los mensajes entre aplicaciones sobre la red. Incluye varios protocolos del nivel de aplicacin, comentndose a continuacin los ms utilizados, si bien el ms importante es el primero de ellos, HTTP. HTTP (HyperText Transfer Protocol). Es el protocolo del nivel de aplicacin ms utilizado en Internet y el protocolo referencia en los Servicios Web. Este protocolo es el encargado de definir la sintaxis y la semntica utilizada en la Arquitectura de la Web. En el contexto de los Servicios Web, este protocolo se utiliza para la transferencia de los mensajes XML a travs de la red, siguiendo los mismos principios del HTML. FTP (File Transfer Protocol). Es el protocolo encargado de los servicios de transmisin de archivos a travs de redes soportadas sobre TCP. En los Servicios Web, FTP permite realizar modificaciones en equipos remotos evitando el uso de permisos sobre los archivos en la mquina cliente en sistemas operativos diferentes a Windows. SMTP (Simple Mail Transfer Protocol). Es el protocolo utilizado para el envo de mensajes de correo electrnico a travs de Internet. Es un estndar de Facto basado en texto. BEEP (Block Extensible Exchange Protocol). Protocolo diseado para la interaccin asncrona punto a punto sobre una red TCP/IP. Estandarizado por el IETF, provee un marco para administrar las conexiones punto a punto, autenticacin, transporte de mensajes y manejo de errores.

JMS (Java Message Service). Como ya se vio anteriormente, JMS da soporte para el envo de mensajes entre dos o ms clientes, soportando el modelo punto a punto y el modelo de publicacin-suscripcin.

1.4.2 Mensajera XML

Este nivel de la pila es el encargado de la codificacin de los mensajes que sern enviados por el nivel de transporte en un formato XML estndar, de modo que puedan ser interpretados por cualquier nodo de la red. Los componentes ms importantes en este nivel son los siguientes:

XML (eXtended Markup Language).

XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que juega un papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje muy similar a HTML pero su funcin principal es describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de datos a travs de diferentes aplicaciones. Un ejemplo de XML es el siguiente: <?xml version="1.0" encoding="utf-8"?> <libreria> <libro> <nombre> Sinuh el Egipcio </nombre> <autor> Mika Waltari </autor> <editorial> Plaza & Jans </editorial> </libro> </libreria> Los 10 puntos clave para entender XML, expuestos por el W3C en su propia pgina Web (http://www.w3.org/XML/1999/XML-in-10-points.es.html) son los siguientes:

1. XML es para estructurar datos. Los datos estructurados incluyen

cosas como planillas de clculo, libretas de direcciones, parmetros de configuracin, transacciones financieras y dibujos tcnicos. XML es un conjunto de reglas (tambin se las podra pensar como lneas de gua o convenciones) para disear formatos de texto que permitan estructurar los datos. XML no es un lenguaje de programacin, y no hace falta ser un programador para usarlo o aprenderlo. XML facilita a la computadora la tarea de generar datos, leerlos, y asegurar que su estructura no es ambigua. XML evita las fallas comunes en diseo de lenguajes: es extensible, independiente de la plataforma, y soporta internacionalizacin y localizacin. XML cumple totalmente con el estndar Unicode.

2. XML se parece un poco al HTML. Al igual que HTML, XML usa

etiquetas (palabras encerradas por < y >) y atributos (de la forma nombre="valor"). Mientras HTML especifica lo que cada etiqueta y atributo significan, y a menudo cmo aparecer en un navegador el texto que hay entre ellas, XML usa las etiquetas slo para delimitar las piezas de datos, y deja la interpretacin de los datos completamente a la aplicacin que los lee. En otras palabras, si usted ve "<p>" en un archivo XML, no asuma que es un pargrafo. Dependiendo del contexto, podra ser un precio, un parmetro, una persona, una p... (y quin dice que debera ser una palabra que empiece con "p"?).

3. XML es texto, pero no est pensado para ser ledo. Los programas
que producen planillas de clculo, libretas de direcciones y otros datos estructurados, a menudo guardan esos datos en disco, usando un formato binario o de texto. Una ventaja del formato de texto es que permite que las personas, si es necesario, miren los datos sin el programa que los produjo; en un aprieto, uno puede leer un formato de texto con su editor de texto favorito. Los formatos de texto tambin permiten a los desarrolladores corregir ms fcilmente sus aplicaciones. Igual que los de HTML, los archivos de XML son archivos de texto que la gente no necesita, pero puede leer, si surge la necesidad. Las reglas de XML son estrictas, y en esto se parece menos al HTML. Una etiqueta olvidada o un atributo sin comillas inutilizan un archivo XML, mientras que en HTML es tolerada y a menudo explcitamente permitida. La especificacin oficial de XML prohbe a las aplicaciones que traten de adivinar las intenciones del creador de un archivo XML daado; si el archivo est daado, la aplicacin debe detenerse all mismo y reportar un error.

4. XML es verboso por diseo. Como XML es un formato de texto y usa

etiquetas para delimitar los datos, los archivos XML son casi siempre ms grandes que los formatos binarios comparables. Eso fue una decisin consciente de los diseadores de XML. Las ventajas de un formato de texto son evidentes (ver el punto 3), y las desventajas pueden usualmente ser compensadas en un nivel diferente. El espacio de disco es menos caro de lo que sola ser, y los programas de compresin como gzip pueden comprimir los archivos muy bien y muy rpido. Adems, los protocolos de comunicacin como los de mdem y HTTP/1.1, el protocolo central de la Web, pueden comprimir datos al vuelo, ahorrando ancho de banda tan efectivamente como un formato binario.

5. XML es una familia de tecnologas. XML 1.0 es la especificacin que

define lo que son las "etiquetas" y los "atributos". Ms all de XML 1.0, "la familia XML" es un conjunto creciente de mdulos que ofrecen servicios tiles para realizar tareas importantes frecuentemente demandadas. Xlink describe un modo estndar de agregar hipervnculos a un archivo XML. XPointer y XFragments son sintaxis en

desarrollo para apuntar a partes de un documento XML. Un XPointer se parece un poco a un URL, pero en lugar de apuntar a documentos en la Web, apunta a piezas de datos dentro de un archivo XML. CSS, el lenguaje de hojas de estilo, es aplicable a XML tanto como a HTML. XSL es el lenguaje avanzado para expresar las hojas de estilo. Se basa en XSLT, un lenguaje de transformacin usado para reacomodar, agregar y eliminar etiquetas y atributos. El DOM es un conjunto estndar de llamadas a funciones para manipular archivos XML (y HTML) desde un lenguaje de programacin. XML Schemas 1 y 2 ayudan a los desarrolladores a definir con precisin las estructuras de sus propios formatos basados en XML. Hay varios mdulos y herramientas disponibles o en desarrollo. No pierda de vista la pgina de reportes tcnicos de la W3C.

6.

XML es nuevo, pero no tanto. El desarrollo de XML comenz 1996 y ha sido una recomendacin de la W3C desde febrero de 1998, lo cual le podra hacer sospechar que sta es una tecnologa bastante inmadura. De hecho, la tecnologa no es muy nueva. Antes de XML estuvo SGML, desarrollado a principios de los 80, estndar ISO desde 1986, y ampliamente usado para grandes proyectos de documentacin. El desarrollo de HTML empez en 1990. Los diseadores de XML simplemente tomaron las mejores partes de SGML, guiados por la experiencia con HTML, y produjeron algo que es no menos poderoso que SGML, y altamente ms regular y simple de usar. Algunas evoluciones, sin embargo, son difciles de distinguir de revoluciones... y hay que decir que mientras SGML es mayormente usado para documentacin tcnica y mucho menos para otras clases de datos, con XML pasa exactamente lo opuesto.

7. XML lleva HTML a XHTML. Hay una importante aplicacin de XML que
es un formato de documento: XHTML de la W3C, el sucesor de HTML. XHTML tiene muchos de los mismos elementos de HTML. La sintaxis ha sido ligeramente cambiada para conformarse a las reglas de XML. Un documento "basado en XML" hereda la sintaxis de XML y la restringe de ciertas maneras (p.e, XHTML permite "<p>", pero no "<r>"); tambin suma significado a esa sintaxis (XHTML dice que "<p>" significa "pargrafo", y no "precio", "persona", o cualquier otra cosa).

8. XML es

modular. XML le permite definir un formato de documento combinando y reutilizando otros formatos. Puesto que dos formatos desarrollados independientemente podran tener elementos o atributos con el mismo nombre, se debe tener cuidado al combinarlos ("<p>" significa "pargrafo" de este formato o "persona" de aqul otro?). Para eliminar la confusin de nombres al combinar formatos, XML provee un mecanismo de espacio de nombre. XSL y RDF son buenos ejemplos de formatos basados en XML que usan espacios de nombres. XML Schema est diseado para reflejar este soporte de la modularidad al nivel de definir la estructura de documentos XML, por

medio de la facilidad para combinar dos esquemas para producir un tercero que cubre una estructura de documento combinada.

9. XML es la base de RDF y de la Web Semntica. El Resource

Description Framework (RDF) de la W3C es un formato de texto XML que soporta aplicaciones de descripcin de recursos y metadatos, tales como listas de temas musicales, colecciones de fotos, y bibliografas. Por ejemplo, RDF podra permitirle identificar las personas en un lbum de fotos Web usando informacin de una lista de contactos personales; entonces, su cliente de correo podra enviar automticamente a esas personas un mensaje diciendo que sus fotos estn en la Web. Lo mismo que HTML integr los documentos, los sistemas de men y las aplicaciones de formularios para lanzar la Web original, RDF integra las aplicaciones y los agentes en una Web Semntica. Del mismo modo que las personas necesitan estar de acuerdo en los significados de las palabras que emplean en su comunicacin, las computadoras necesitan mecanismos para acordar los significados de los trminos para comunicarse efectivamente. Las descripciones formales de los trminos en una cierta rea (compras o manufactura, por ejemplo) se llaman ontologas, y son una parte necesaria de la Web Semntica. RDF, las ontologas, y la representacin del significado de modo que las computadoras puedan ayudar a las personas a hacer el trabajo, son tpicos de la Actividad de la Web Semntica.

10. XML es gratuito, independiente de la plataforma y bien soportado. Al

elegir XML como la base de un proyecto, usted gana acceso a una comunidad grande y creciente de herramientas (una de las cuales podra ya hacer lo que usted necesita!) e ingenieros experimentados en la tecnologa. Optar por XML es un poco como elegir SQL para bases de datos: usted todava tiene que construir su base de datos y sus propios programas y procedimientos que la manipulen, y hay muchas herramientas disponibles y mucha gente que puede ayudarlo. Y como XML es gratuito, usted puede construir su propio software alrededor de l sin pagar nada a nadie. El soporte grande y creciente significa que usted tampoco est atado a un vendedor nico. XML no es siempre la mejor solucin, pero siempre vale la pena considerarlo.

XML-RPC
Fue creado por Dave Winer de la empresa UserLand Software en asociacin con Microsoft en el ao 1998. Al considerar Microsoft que era muy simple decidi aadirle funcionalidades, las cuales, despus de varias etapas de desarrollo, provocaron que el estndar dejase de ser sencillo y se convirti en lo que actualmente se conoce como SOAP. Una diferencia fundamental es que en los procedimientos en SOAP, los parmetros tienen nombre y no interesa su orden, no siendo as en XML-RPC.

XML-RPC es una implementacin del protocolo de procedimientos remotos (RPC, Remote procedure call) usando XML y HTTP como agente de transporte. Las peticiones y las respuestas estn definidas en XML. El protocolo permite la comunicacin sobre diferentes sistemas operativos y diferentes lenguajes. Es un protocolo de llamada a procedimiento remoto que funciona mediante intercambio de mensajes entre cliente y servidor, utilizando el protocolo HTTP para el transporte de los mensajes. Utiliza peticiones POST de HTTP para enviar un mensaje, en formato XML, sealando:

El procedimiento que se va a ejecutar en el servidor. Los parmetros.

El servidor devuelve el resultado en formato XML, siendo la respuesta XML RPC una respuesta HTTP con cdigo de estatus 200 (OK), siempre y cuando no haya un error de bajo nivel. Los errores de XMLRPC se retornarn como mensajes de HTTP correctos, notificndose ste error en el contenido del mensaje. Es un protocolo muy simple ya que slo define unos cuantos tipos de datos y comandos tiles, adems de una descripcin completa de corta extensin. La simplicidad del XML-RPC est en contraste con la mayora de protocolos RPC que tienen una documentacin extensa y requieren considerable soporte de software para su uso.

SOAP (Simple Object Access Protocol)

SOAP es un protocolo estndar que deriva de XML-RPC y est actualmente bajo el auspicio del W3C. SOAP define cmo dos objetos, en diferentes procesos, pueden comunicarse por medio de intercambio de datos XML. En el ncleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que proporciona un mecanismo estndar de empaquetar mensajes. SOAP ha recibido gran atencin debido a que facilita una comunicacin del estilo RPC entre un cliente y un servidor remoto. Pero existen multitud de protocolos creados para facilitar la comunicacin entre aplicaciones, incluyendo RPC de Sun, DCE de Microsoft, RMI de Java y ORPC de CORBA. La razn fundamental por la que SOAP ha tenido ms repercusin que los dems es, entre otras, que ha contado en todo momento con un increble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prcticamente por todas las grandes compaas de software del mundo. Compaas que en raras ocasiones cooperan entre s, estn ofreciendo su apoyo a este protocolo. Algunas de las mayores Compaas que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba. Algunas de las ventajas de SOAP son:
No

esta asociado con ningn lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el ltimo y mejor lenguaje de programacin que exista, pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podran no

poder hacer esta eleccin sobre el lenguaje de programacin que utilizan. SOAP no especifica una API, por lo que la implementacin de la API se deja al lenguaje de programacin, como en Java, y a la plataforma como Microsoft .Net.
No se encuentra fuertemente asociado a ningn protocolo de

transporte: La especificacin de SOAP no describe como se deberan asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es ms 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

mayora de los sistemas de objetos distribuidos se pueden extender, y ya lo estn algunos de ellos para que admitan SOAP.
Aprovecha los estndares existentes en la industria: Los principales

contribuyentes a la especificacin SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estndares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificacin de los mensajes, en lugar de utilizar su propio sistema de tipos que ya estn definidos en la especificacin 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 mltiples entornos: SOAP se

desarroll sobre los estndares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estndares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicacin de escritorio que se ejecute en una PC puede comunicarse con una aplicacin del back-end ejecutndose en un mainframe capaz de enviar y recibir XML sobre HTTP. En el tema siguiente se estudiar SOAP en profundidad.

REST
En este apartado se pretende ofrecer un resumen de las caractersticas de REST (REpresentational State Transfer), un estilo arquitectnico utilizado como modelo para disear sistemas en entornos distribuidos, y utilizado normalmente para definir una interfaz de transmisin sobre HTTP de manera anloga a como lo hace SOAP. Es por esto ltimo por lo que se estudia REST en este apartado, puesto que REST en s sirve para establecer las bases necesarias para crear lo que se conoce como Servicios Web Ligeros, fuera del alcance de este curso, y motivo suficiente para ser un curso entero. REST surge como un apartado dentro de la tesis de uno de los creadores de la Arquitectura de la Web, Roy Thomas Fielding, all por el ao 2000. Est muy de moda actualmente gracias a la explosin de la llamada Web 2.0, ya que este estilo arquitectnico est incluido dentro del marco de la Web 2.0 por ser la base que facilita el cumplimiento de la filosofa seguida por esta corriente. Como

primer acercamiento a REST, quiz lo mejor sea empezar por conocer el significado sus siglas: REpresentational: Significa que el servidor devuelve una representacin del recurso cuando el cliente accede a una determinada URI. State: La representacin devuelta por el servidor sita al cliente en un estado concreto. Transfer: El cliente puede ir cambiando de estado accediendo a las URIs disponibles en forma de enlace dentro de cada representacin de un recurso.

Es decir, REST se basa en acceder a recursos disponibles en la Web por medio de su identificador (URI), obteniendo como resultado una representacin del mismo. Esta representacin plasma el estado del recurso al que representa en un momento concreto del tiempo. Adems, la representacin puede contener enlaces a otros recursos de modo que el cliente puede navegar a travs de ellos, y consecuentemente, cambiando de estado. La motivacin de desarrollar REST era la de crear un modelo de arquitectura que describiese como debera funcionar la Web, as como que pudiese servir como marco de trabajo para los estndares de protocolos Web. REST ha sido aplicado para describir la arquitectura Web deseada, ayudar a identificar problemas existentes, comparar soluciones alternativas, y asegurar que el protocolo no viole las restricciones que hacen que la Web funcione correctamente. Este trabajo fue realizado por el Internet Engineering Taskforce (IETF) y el World Wide Web Consortium (W3C), gracias a sus esfuerzos por definir un estndar de arquitectura para la Web: HTTP, URI y HTML. El trmino REST ha ido evolucionando a lo largo del tiempo. Fielding lo concibi de una manera abstracta, se refera originalmente a un conjunto de principios de arquitectura (descritos ms adelante), en la actualidad se usa en el sentido ms amplio para describir cualquier interfaz Web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo SOAP introducido anteriormente. Es posible disear sistemas de servicios Web de acuerdo con el estilo arquitectural REST de Fielding, y tambin es posible disear interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del trmino REST causan cierta confusin en las discusiones tcnicas, aunque RPC no es un ejemplo de REST. En cualquier caso, al centrarse slo en estas tecnologas, se puede perder en parte la esencia propuesta por Fielding. En cualquier caso, los sistemas que siguen los principios REST se llaman con frecuencia RESTful.

La Web ha disfrutado de escalabilidad como resultado de una serie de diseos fundamentales clave:
Un protocolo cliente/servidor sin estado: cada mensaje HTTP

contiene toda la informacin necesaria para comprender la peticin. Como resultado, ni el cliente ni el servidor necesitan recordar ningn estado de las comunicaciones entre mensajes. Sin embargo, en la prctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros

mecanismos para mantener el estado de la sesin (algunas de estas prcticas, como la reescritura de URLs, no son permitidas por REST).
Un conjunto de operaciones bien definidas que se aplican a todos

los recursos de informacin: HTTP en s define un conjunto pequeo de operaciones, las ms importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a las operaciones CRUD (Create, Retrieve, Update y Delete) que se requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos. En un sistema

REST, cada recurso es direccionable nicamente a travs de su URI.

El uso de hipermedios, tanto para la informacin de la aplicacin como

para las transiciones de estado de la aplicacin: la representacin de este estado en un sistema REST son tpicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional. A partir de los principios bsicos anteriores, se definen una serie de restricciones que ha de cumplir una aplicacin para poder considerarse REST, y que por tanto se pueden considerar como las caractersticas principales de REST. Esto deriva en que REST no es una tecnologa en s misma, sino una arquitectura que puede implementarse de muy diversas maneras, y que simplemente ha de cumplir una serie de restricciones:

Cliente-Servidor. Sin estado. Cache. Interfaz uniforme. Sistema de capas. Cdigo bajo demanda.

A continuacin se explican brevemente cada una de ellas.

Cliente-Servidor
La primera restriccin que se aade a este estilo de diseo es la de imponer una arquitectura cliente-servidor. La separacin de roles en las entidades cliente y servidora es la base para desarrollar este tipo de arquitecturas. De esta forma, es posible desarrollar estos componentes de forma paralela e independiente. Separando el interfaz de usuario de las caractersticas de almacenamiento y tratamiento de los datos se garantiza la portabilidad de esta funcionalidad de usuario entre diferentes plataformas y mejora la escalabilidad ya que simplifica los componentes del servidor.

Sin estado (Stateless)

Toda informacin que viaja en un elemento de comunicacin atmico entre cliente-servidor (peticin de servicio) es auto contenida, y no se almacena ningn tipo de estado del cliente por parte del servidor. Esta restriccin delega

toda la responsabilidad de mantenimiento de un posible estado de la comunicacin al cliente. Lo anterior se traduce en la independencia del servidor a la hora de procesar una peticin en particular, aadiendo al modelo mejoras en relacin a:
Transparencia. Todas las peticiones en la comunicacin son por as

decirlo iguales.

Fiabilidad. Ante una prdida de servicio por parte del servidor y el

posterior restablecimiento del mismo no hay ninguna prdida de informacin, y la comunicacin puede volver a ser establecida sin problemas por las entidades.
Escalabilidad. El servidor, debido a que procesa las peticiones de

forma individual y por tanto no tiene la necesidad de tener en cuenta la relacin con peticiones anteriores, no reserva recursos. Esto hace que el servidor no tenga que realizar una gestin de recursos adicional al procesado de la peticin que le ofrece al cliente, y estos recursos son liberados ms fcilmente. La desventaja de esta restriccin es que puede empeorar el funcionamiento de la red porque incrementa el trfico de datos repetidos al enviar una serie de peticiones. Esto ocurre porque los datos no pueden quedarse almacenados en el servidor identificando un contexto determinado de comunicacin. Adems poniendo el estado de la aplicacin en el lado del cliente, se reduce el control para obtener un comportamiento consistente en la aplicacin. La aplicacin se hace muy dependiente de una correcta implementacin de la semntica en las distintas versiones del cliente.

Cach
Con objeto de mejorar la eficiencia de la red, las respuestas a una peticin deben poder ser etiquetadas como cacheable o nocacheable. Si una respuesta es cacheable, entonces al cliente cache se le da permiso para reutilizar la respuesta ms tarde si se hace una peticin equivalente. La consecuencia directa de esta restriccin ya se ha comentado anteriormente: se mejora la eficiencia de la red al reducir el trfico que viaja por ella al disponerse de cach. De igual manera, el tiempo de respuesta se ver tambin reducido. Esta restriccin aade, sin embargo, una complejidad al modelo que con otro tipo de arquitecturas no existe: hay que implementar un mdulo/componente en el servidor que discrimine qu tipo de respuesta es (si cacheable o no). Si el servidor no realiza bien esta tarea el funcionamiento de la aplicacin no ser consistente. Hay que tener esto en cuenta como potencial fuente de errores. Las restricciones que se describen a continuacin son realmente las novedades que pretende aportar REST a las nuevas arquitecturas Web. La principal caracterstica que distingue a REST del resto de estilos de arquitecturas de red es el nfasis de usar una interfaz uniforme entre los componentes. Aplicando los principios de generalidad de la ingeniera del

software a los componentes de la interfaz, se simplifica la arquitectura del sistema global y la visibilidad de interacciones se mejora. Las implementaciones se separan de los servicios que proporcionan, lo que anima al desarrollo independiente. La desventaja de usar una interfaz uniforme es que degrada la eficiencia porque la informacin transferida est en una forma estandarizada y no segn las necesidades que tenga la aplicacin. El interfaz de REST est diseado para ser eficiente con transferencias de datos de hipermedios (audio, video y texto, con el que pueden interactuar los usuarios), que suelen ser datos voluminosos. Con esta decisin, est optimizado para la mayor parte de la Web pero no siendo as para otras formas de arquitectura de interaccin. Para obtener una interfaz uniforme, REST define cuatro restricciones de interfaz:

Identificacin de recursos. Manipulacin de recursos a travs de sus representaciones. Mensajes auto-descriptivos. Hipermedios como el motor del estado de la aplicacin.

Sistema de Capas
Para poder mejorar el comportamiento de la escalabilidad en Internet, se aade la restriccin del sistema de capas. Este sistema permite tener una arquitectura compuesta por capas jerrquicas, limitando el comportamiento de los componentes porque no pueden acceder ms all de la capa con la que estn interactuando. Restringiendo la visibilidad del sistema a una sola capa se limita la complejidad total de la misma y se promueve el desarrollo de las capas inferiores, siendo dicho desarrollo independiente. Las caractersticas anteriores se manifiestan en:
Abstraccin de servicios. Delegacin de servicios en capas inferiores. Proteccin de los nuevos servicios. Simplificando los componentes al

mover la funcionalidad atpica de un usuario a una capa intermedia. Estas capas intermedias pueden usarse para mejorar la escalabilidad del sistema permitiendo el balanceo de servicios. Esta restriccin posee tambin inconvenientes, la principal desventaja es que se introduce un tiempo extra de procesamiento de datos entre capas, lo que podra ocasionar una degradacin en la interactividad que percibe el cliente. Para el caso de un sistema basado en cach que utilice capas intermedias, este efecto indeseado de degradacin de servicio se puede reducir incorporando el sistema de cach explicado anteriormente en las capas intermedias. Las capas situadas en los lmites de la organizacin deben implementar polticas de seguridad para garantizar el correcto intercambio de datos con entidades externas al dominio de dicha organizacin. Esto puede ser requerido para implementar el correcto funcionamiento de firewalls, haciendo coincidir las

polticas de restriccin del cortafuegos con las polticas de seguridad implementadas en las capas situadas en los lmites de la organizacin.

Cdigo bajo demanda

Esta ltima restriccin es opcional, y consiste en permitir a los clientes tener la funcionalidad de descargar y ejecutar cdigo en forma de applets y scripts. Esto simplifica el lado del cliente porque reduce el nmero de funcionalidades que tiene que tener implementadas al crearse. Las funcionalidades se pueden descargar posteriormente aumentando as la extensibilidad del sistema. La principal desventaja de esta restriccin es que reduce la visibilidad y puede influir en la seguridad del sistema. Sin embargo, tiene un propsito en el diseo arquitectnico de un sistema que abarque lmites de organizacin mltiples. Con esta restriccin, la arquitectura gana solamente una ventaja y sufre el resto de desventajas, por ello al ser una restriccin opcional, en los contextos en los que el cdigo bajo demanda no sea til ni necesario, lo mejor ser no incluirlo porque puede acarrear ms problemas que beneficios.

1.4.3 Descripcin del Servicio

Los servicios Web deben contar con una interfaz pblica en la que se describa el servicio en s, incluyendo las operaciones soportadas por el mismo. Es por ello por lo que surge WSDL, el lenguaje de descripcin de Servicios Web.

WSDL
WSDL (Web Services Description Language) es un tipo de documento XML que describe lo que hace un servicio Web, dnde se encuentra y la forma de ser invocado. Este lenguaje provee informacin imprescindible para los desarrolladores, ya que entre otras cosas describe el formato de los mensajes que utiliza y a cuales puede responder. Un documento WSDL presenta siempre los siguientes elementos:

Tipos: Tipos de datos usados por los mensajes. Mensaje: Qu datos son enviados desde un nodo a otro. Tipo de puerto: Define las operaciones que pueden ser invocadas. Operacin: Define la configuracin de mensajes de entrada, salida y error. Entrada: Mensaje que es enviado hacia el servidor. Salida: Mensaje enviado hacia el cliente. Falta: Error en el envo de un mensaje. Lmite: Es la descripcin del protocolo que se est utilizando para transportar el mensaje que puede ser HTTP POST, HTTP GET, SOAP y MIME. Servicio: Define una coleccin de puertos (nodos); el puerto especifica una direccin para el lmite definiendo as la comunicacin para un nodo especfico.

Se estudiar en mayor profundidad WSDL en captulos siguientes.

1.4.4 Descubrimiento de Servicios

Uno de los aspectos ms importantes de los Servicios Web es que para poder crear procesos de negocio y poder formar composiciones de servicios con el fin de dar un servicio de valor aadido, es necesario saber cmo encontrarlos. UDDI va a ser el encargado de permitir a los Servicios Web conocer con quien se van a comunicar y dnde podrn encontrar esos otros objetos de negocio (otros servicios Web).

UDDI
UDDI (Universal Description, Discovery and Integration) es un marco independiente de la plataforma para describir servicios, negocios e integrar servicios de negocios. UDDI es un esfuerzo de la industria iniciada en Septiembre de 2000 por Ariba, IBM, Microsoft y otras 33 compaas, siendo actualmente un estndar desarrollado dentro de OASIS. Su estructura est basada sobre los servicios estndares de la Web, lo que quiere decir que UDDI es accesible como otros servicios Web. Los propietarios de los Servicios Web los publican en el registro UDDI. Una vez publicados se mantienen all punteros a la descripcin del Servicio Web y al servicio. UDDI permite a los clientes buscar tal registro, encontrar el servicio deseado y extraer sus detalles. Estos detalles incluyen el punto de invocacin as como otras caractersticas del servicio y su funcionalidad. La figura siguiente muestra las fases en el uso de UDDI.

La estructura de datos de UDDI est compuesta por cuatro entidades:

businessEntity. Describe al proveedor del servicio Web. Tiene datos

como nombre de compaa, detalle de contacto y otra informacin del negocio.

businessService. Describe un conjunto lgico de uno o muchos

servicios Web.

bindingTemplate. Describe un nico Servicio Web, describe toda la

informacin tcnica para que el cliente pueda interactuar con l.

Technical Model - tModel. Representa las especificaciones tcnicas del

servicio, as como metadatos sobre las especificaciones del documento, el nombre puntero URL, y es presentado en forma de un documento WSDL.

La figura siguiente representa las relaciones entre las distintas entidades UDDI.

Como se vio anteriormente, los registros UDDI no almacenan los Servicios en s, lo que almacenan es metainformacin de los mismos, as como la informacin necesaria para realizar el acceso a estos servicios. Estos registros pueden ser de tres tipos:
Pginas amarillas. Contienen la informacin bsica de un proveedor de

servicios, sirven para realizar bsquedas por empresa.

Pginas verdes. Bsqueda por cdigo dado por el gobierno de los

EEUU, por cdigo de United Nations/SPSC o por localizacin geogrfica. informacin relativa a las especificaciones tcnicas de los servicios.

Pginas blancas. Contienen asociaciones entre empresas as como

1.4.5 La realidad de la Pila de Protocolos de Servicios Web

Se han visto hasta ahora los 4 elementos principales de la pila de protocolos de los servicios Web, los cuales conforman el escenario bsico de la arquitectura de los Servicios Web. Sin embargo, no existe una definicin exacta de la pila de

protocolos por parte del W3C, y existen gran cantidad de protocolos, algunos propietarios, otros no, para los distintos niveles de la pila. La figura siguiente muestra gran parte de ellos.

Para obtener mayor informacin de estos protocolos, se recomienda visitar las pginas Web del W3C y de OASIS, las cuales albergan la mayora de los mismos.

1.5. Principales Frameworks de Desarrollo de Servicios Web

A la hora de trabajar con Servicios Web, y como casi siempre en el mundo de la programacin, se puede desarrollar escribiendo todo el cdigo desde cero, o bien

programar ayudndose de alguna herramienta o framework de desarrollo para servicios Web. El amplio abanico de opciones a la hora de elegir un framework para la elaboracin de servicios Web y sus clientes es un sntoma irreprochable de su gran difusin. El hecho de que muchos desarrolladores opten por utilizar este tipo de herramientas es muy significativo, ya que revela que no es muy conveniente decantarse por implementar y utilizar estos servicios sin el empleo de estos frameworks. La utilizacin de estas herramientas no solo evita la aparicin de posibles errores, sino que hace liviana y rpida la tarea de implementacin y manejo de los servicios Web. Mediante este tipo de software, el desarrollador consigue abstraerse casi completamente de las libreras que se utilizan y del funcionamiento de los servicios. De esta forma el desarrollador nicamente tiene que centrarse en la lgica que quiere ofrecer y no en como debe implementar las peculiaridades de los servicios Web. Es por ello que en este curso utilizaremos alguno de los frameworks ms tpicos para desarrollar servicios Web en Java. En los apartados que se muestran a continuacin se hace una breve descripcin de estas herramientas y de sus principales caractersticas, haciendo distincin entre las herramientas de mbito privado y las de cdigo abierto.

Software propietario en Servicios Web

Actualmente existe una amplia gama de productos propietarios relacionados con los Servicios Web, por lo que no es fcil llevar a cabo una seleccin de herramientas de entre las mltiples opciones disponibles en el mercado. Las siguientes herramientas pertenecen a las principales compaas desarrolladoras de software. En concreto, pertenecen a Microsoft, Sun Microsystems, Oracle e IBM, las cuales han desarrollado grandes frameworks de desarrollo de Servicios Web intentando dejar claro que son los grandes actores en el mercado de los Servicios Web. A continuacin se exponen las principales caractersticas de las herramientas de software propietario.

Microsoft Windows Communication Foundation

Windows Communication Foundation (WCF) es la plataforma de Microsoft para el desarrollo y ejecucin de Servicios Web. WCF integra un conjunto de tecnologas proporcionadas por el .NET Framework, tales como ASMX (denominada tambin ASP.NET Web Services), .NET Remoting, Enterprise Services y Web Services Enhancements, que implementan una serie de especificaciones WS-* y Microsoft Message Queuing. WCF incluye un nmero significativo de tecnologas relacionadas con los Servicios Web, entre las que destacan SOAP, WSDL, WS-Addressing, WS-

AtomicTransaction, WS-Coordination, WS-Policy, WS ReliableMessaging, WSSecureConversation, WS-Security, WS-SecurityPolicy y WS-Trust.

Sun Microsystems Java 2 Enterprise Edition

La plataforma Java 2 Enterprise Edition 5 (J2EE 5) de Sun Microsystems proporciona las herramientas necesarias para disear, desarrollar, probar y desplegar SW de forma rpida. En relacin a los Servicios Web, esta plataforma soporta SOAP 1.1/2.0, WSDL 1.1, UDDI 1.0, WS-Addressing y WS-Security.

Oracle JDeveloper
Oracle JDeveloper es un entorno de desarrollo integrado que permite la construccin de aplicaciones orientadas a servicios. Esta herramienta permite desarrollar el ciclo de vida completo de este tipo de aplicaciones: modelado, codificacin, depuracin, prueba, perfilado, ajuste y despliegue. Oracle JDeveloper permite desarrollar WS con SOAP, WSDL y UDDI. El soporte para UDDI incluye el despliegue de WS en repositorios, un navegador UDDI y la posibilidad de generar esqueletos de cdigo para la activacin de Servicios Web. Este producto tambin integra otras tecnologas WS, como WS-Reliability y WSSecurity. Por ltimo, proporciona un entorno grfico que permite disear procesos BPEL.

IBM Websphere Application Server

La compaa IBM dispone de un conjunto muy amplio de productos que constituyen la plataforma Websphere. Entre todos estos destaca IBM Websphere Application Server por ser la base de la plataforma Websphere. IBM Websphere Application Server 6.1 est disponible en mltiples configuraciones: Websphere Application Server Community Edition, Websphere Application Server Express, Websphere Application Server y Websphere Application Server Network Deployment. De todas ellas, se destaca Websphere Application Server Network Deployment, que es la ms completa y a la que se va a referir a continuacin, y Websphere Application Server Community Edition, que se discute en el siguiente apartado, por tratarse de software libre. La plataforma proporciona un entorno integrado de desarrollo y despliegue de WS. Soporta J2EE 5, as como las siguientes tecnologas relacionadas con los WS: SOAP, WSDL, UDDI 3.0, WS-Addressing, WS-BusinessActivity, WSNotification y WS-Security.

Software libre en los Servicios Web

Al igual que con las herramientas de software propietario, son muchas las herramientas de software libre existentes para el desarrollo de Servicios Web. Las herramientas mostradas a continuacin destacan por su madurez y por su representatividad dentro del mundo de los Servicios Web. Las licencias bajo las que se distribuyen estas herramientas son muy variadas e incluso hay casos en los que coexisten licencias libres con otras propietarias.

gSOAP Web Services Toolkit

El conjunto de herramientas gSOAP Web Services permite desarrollar Servicios Web con C y C++. Se utiliza principalmente para desarrollar Servicios Web a partir de su descripcin en WSDL. Entre las herramientas disponibles se incluye un generador de cdigo fuente que realiza parte del trabajo de codificacin e incorpora un analizador de WSDL y de esquemas XML capaz de asociar automticamente los tipos que aparecen en los esquemas con tipos de datos de C y C++. En la actualidad permite trabajar con SOAP 1.1/1.2, WSDL 1.1 y UDDI 2.0, as como con otras tecnologas como WS-Addressing y WS-Security. Entre los planes de desarrollo futuro est el incorporar nuevas especificaciones. Las herramientas gSOAP se distribuyen con tres tipos de licencia: GNU GPL, cdigo abierto pblico gSOAP y comercial. Algunas partes no son libres, como el cdigo fuente del analizador, que slo se distribuye bajo la licencia comercial.

JbossWS
JBoss Application Server es una plataforma J2EE certificada que permite desarrollar y desplegar aplicaciones Java empresariales, adems de aplicaciones y portales Web. A partir de su versin 4.0.4 incorpora el submdulo JbossWS, que es el encargado de proporcionar el soporte para los WS. JBossWS es capaz de trabajar con las siguientes tecnologas: SOAP 1.1/1.2, WSDL 1.1, UDDI, WS-Addressing, WS-BPEL, WS-Coordination, WS-Policy y WS-Security. JBoss Application Server y JBossWS se distribuyen con licencia GNU LGPL.

GlassFish
Este proyecto representa una alternativa libre al entorno J2EE, descrito en el apartado anterior. Su desarrollo se debe a la liberacin por parte de Sun Microsystems de Java System Application Server 9.0 PE. Esto permite a Sun desarrollar y distribuir sus tecnologas WS, mientras se garantiza a los

desarrolladores del proyecto el acceso a las ltimas versiones de las tecnologas XML y WS. En este sentido, GlassFish, a partir de la liberacin de la versin 2.0 del Java Web Services (Java WS) Developer Pack, soporta SOAP 1.1/2.0, WSDL 1.1, UDDI 1.0, WS-Addressing y WS-Security. En cuanto a las licencias, la mayor parte del cdigo del proyecto GlassFish est disponible bajo licencia CDDL. Sin embargo, ciertos componentes slo estn liberados en forma binaria bajo una licencia especfica de Sun.

NetBeans IDE
NetBeans IDE es un entorno de desarrollo integrado (IDE) de cdigo abierto. Proporciona a los desarrolladores mltiples herramientas que permiten crear aplicaciones empresariales, tanto para la Web como para dispositivos porttiles. NetBeans IDE 5.0 ofrece soporte completo para J2EE 5. Esta herramienta nos permite trabajar con SOAP 1.1/1.2 y WSDL 1.1/2.0. En su contra, podemos indicar que no se ha considerado UDDI entre los objetivos de desarrollo, aunque es posible su integracin como elemento independiente. El IDE se puede complementar con varios paquetes que le proporcionan funciones adicionales. Uno de estos paquetes es Enterprise Pack que aade a NetBeans las herramientas necesarias para escribir, depurar y probar aplicaciones SOA utilizando XML, BPEL y Java WS. Este paquete instala herramientas grficas para la creacin de esquemas XML y el diseo de orquestaciones de WS con BPEL. NetBeans Enterprise Pack 5.5 es la ltima versin disponible hasta la fecha y permite trabajar con WS-BPEL 2.0, aunque no de forma completa. Tanto NetBeans IDE como NetBeans Enterprise Pack se desarrollan y distribuyen bajo licencia CDDL.

Apache Axis2
Apache Axis2 es una evolucin de su predecesor, Apache Axis. Su diseo presenta una arquitectura modular que facilita la introduccin de funciones adicionales y la integracin de nuevas tecnologas de la pila WS. Esta plataforma integra SOAP 1.1/1.2, WSDL 1.1/2.0, WS-Addressing, WSReliableMessaging, WS-Security y WS-SecureConversation. Adems, como parte del proyecto, se han desarrollado varios mdulos que permiten integrar otras tecnologas. Los principales son: Kandula, que proporciona WS-AtomicTransaction, WS-BusinessActivity y WS-Coordination, Sandesha, que implementa WS-ReliableMessaging, y Rampart, que incorpora WS-SecurityPolicy. Actualmente, se est desarrollando un nuevo mdulo para soportar WS-Policy. Aunque la plataforma no permite trabajar directamente con UDDI, es posible integrar jUDDI con Axis2.

En cuanto a la licencia, tanto Axis2 como los mdulos descritos Kandula, Sandesha y Rampart se distribuyen bajo licencia Apache 2.0. Esta plataforma ser una de las que se utilizarn en captulos siguientes para el desarrollo de ejercicios.

IBM Websphere Application Server Community Edition

IBM Websphere Application Server Community Edition es un servidor de aplicaciones J2EE con tecnologa Apache Geronimo que incorpora las ltimas innovaciones en software libre para proporcionar una plataforma integrada y flexible con la que desarrollar y desplegar aplicaciones Java. En relacin a los WS, soporta las tecnologas SOAP, WSDL, UDDI, WSBusinessActivity, WS-Notification y WS-Security. En comparacin con otros productos de la familia no permite trabajar con UDDI 3.0. Est construido sobre Apache Tomcat y otras aplicaciones de cdigo abierto lderes como OpenEJB, Apache Axis e IBM Cloudscape, a su vez basada en Apache Cloudscape. Se distribuye bajo licencia Apache 2.0.

1.6. Cuestionario de autoevaluacin 1.7. Conclusiones

En este primer captulo se ha introducido al alumno en el mundo de los Servicios Web. Para ello, se ha estudiado la historia de las aplicaciones distribuidas y su evolucin hasta llegar a la necesidad de los Servicios Web. Una vez introducidos, se ha presentado la pila de protocolos de los Servicios Web, en la cual se encuentran las principales tecnologas utilizadas. De ella se han destacado cuatro niveles: Transporte, Mensajera XML, Descripcin del servicio Web, y Descubrimiento de Servicios Web.

Para finalizar, se han presentado una serie de entornos de desarrollo destinados a la creacin tanto de los Servicios Web en s como a los clientes de los mismos.