Desarrollo de Web Services con Software Libre

Web Services
Jennifer Prez Bened Departamento de Sistemas Informticos y Computacin Universidad Politcnica de Valencia C/Camino de Vera s/n E-46071 Valencia- Espaa jeperez@dsic.upv.es

1. POR QU WEB SERVICES?

Existen diversas razones por las que han surgido los Web Services y estn teniendo tanto xito. Entre ellas est el hecho de que los sistemas de informacin actuales son cada vez ms complejos y est surgiendo una tendencia a la programacin orientada a componentes y un abandono de la programacin orientada a objetos. La aproximacin a la programacin orientada a componentes de los Web Services hace que muchas empresas opten por esta tecnologa. Otra de las razones por las que han surgido los Web Services ha sido que las aplicaciones y componentes desarrolladas utilizando un middleware, como DCOM, CORBA y Java RMI, tienen varias limitaciones. Se hizo un intento de superarlas mediante un modelo llamado stateless programming, pero no tuvo xito porque estas tecnologas son bastante pesadas y el restablecimiento de la conexin con un objeto remoto resulta muy costoso. Debido a esto, surge la necesidad de crear una nueva tecnologa desde cero, los Web Services. A continuacin se citan algunas de las limitaciones que presentan middleware como DCOM, CORBA y Java RMI: Plantean problemas de seguridad, ya que para poder trabajar necesitan un puerto abierto, no uno de los bien conocidos, sino uno de los que estn libres por encima del 1024. Por ese motivo, estos middleware establecen y gestionan sus polticas de seguridad (java.policy en Java RMI) de forma eficaz, haciendo que la comunicacin de un cliente con un servidor a travs de Internet tenga numerosas barreras que sobrepasar. Para ello, los administradores de red se encargan de implementar routers corporativos y firewalls 1 con el objetivo de garantizar su seguridad y no permitir una comunicacin externa con Internet. Todo esto hace que los protocolos que usan DCOM, CORBA y Java RMI no sean adecuados para los escenarios Web. El hecho de que sus protocolos sean patentados y orientados a la conexin crea varios inconvenientes a la hora de utilizarlos en un escenario Web: Las aplicaciones deben estar gestionadas e instaladas en un centro de datos.

1 Software que funciona en un servidor, generalmente conectado a un router que, a su vez, est conectado a una red externa. La funcin del cortafuegos es proteger una Intranet evitando que entren en ella transmisiones de red no deseadas , aplicando la filosofa de lo que no est permitido expresamente es negado.

Desarrollo de Web Services con Software Libre

Hacen muy difcil mantener una infraestructura balanceada en su carga que permita lograr una alta escalabilidad, ya que cuando una conexin entre un cliente y un servidor se rompe no se puede cambiar y enviar la siguiente peticin a otro servidor. No gestionan de una forma satisfactoria las interrupciones en la conexin. Este es un gran inconveniente porque Internet no est bajo el control del administrador de red y por lo tanto, no se puede asegurar ni la calidad ni la fiabilidad de la conexin.

Otro aspecto que ha propiciado esta tendencia hacia los Web Services es que la mayor parte del trfico de Internet se limita a un conjunto de protocolos (http, ftp y algunos de correo) de los que el ms importante volumen de informacin es http (puerto 80) junto con XML. La ventaja de los Web Services es que utilizan toda esta infraestructura ya establecida, sin la necesidad de inventar otra nueva. Adems, XML es un lenguaje de marcado que esta siendo utilizado por la mayora de empresas debido a sus ventajas. Entre todas ellas cabe destacar la comparticin de datos interna (entre departamentos) y externa (con otras empresas). Esta situacin ha desencadenado un mayor inters por la integracin, de datos mediante XML y de aplicaciones usando Web Services. A la hora de adoptar esta nueva tecnologa se han de tener en cuenta las necesidades y el rea de la empresa. En concreto, la tecnologa Web Services est orientada a aplicaciones de e-comerce, haciendo que la mayora de Web Services sean transacciones business-to-business (B-to-B). Otra consideracin a tener en cuenta es que adaptar todo el software desarrollado a esta tecnologa resulta caro, a pesar de la reutilizacin de cdigo y de utilizar Linux y herramientas de sofware libre. Por estos motivos, es necesario tener en cuenta que cuanta mayor inversin se realice en la Web, ms conveniente es utilizar Web Services. Esto no significa que no se puedan utilizar Web Services en aplicaciones que no sean orientadas a la Web, aunque las principales ventajas que aporta frente a otras tecnologas son para el desarrollo y ejecucin de escenarios Web.

2. WEB SERVICES
Un Web Service es un servicio que se ofrece mediante la web. Los Web Services los utilizan normalmente las empresas de negocios con el fin de ofertar sus servicios a travs de la Web. Una compaa puede ser tanto proveedora como consumidora de Web Services. Un Web Service es una clase cuya interfaz se puede hacer pblica en un servidor Web mediante un lenguaje de descripcin de interfaces (WSDL). Dicha interfaz ofrece un conjunto de actividades que un cliente puede invocar. El cliente accede al Web Service usando los estndares de Internet. Para acceder a un Web Service se pueden utilizar varios protocolos Web estndar como HTTP GET o HTTP POST, aunque se ha diseado un protocolo especficamente diseado para ello: SOAP (Simple Object Access Protocol). Este protocolo se basa en la utilizacin de HTTP para el transporte de mensajes y el lenguaje

Desarrollo de Web Services con Software Libre

XML para la escritura del cuerpo de estos mensajes. Todo esto permite a cualquier aplicacin ser capaz de generar e interpretar mensajes en SOAP independientemente de la plataforma. La solicitud de un Servicio Web se realiza a una determinada URL utilizando el protocolo SOAP. El servicio recibe la solicitud, la procesa y devuelve una respuesta. Para conocer la ubicacin (URL) de un Web Service se accede a un directorio centralizado utilizando protocolos como UDDI (Universal Description, Discovery, and Integration) o DISCO. 2.1. CARACTERSTICAS Las caractersticas de esta nueva tecnologa son las que se citan en los siguientes subapartados. - Interoperabilidad: Los Servicios Web se pueden consumir por clientes de otras plataformas. - Acceso externo desde Internet: Los Servicios Web realizan una buena gestin para los accesos que provienen de clientes de Internet. - Tipos de datos de las Interfaces: Los tipo de datos definidos para los Servicios Web se corresponde con los tipos de datos definidos por la mayora de lenguajes de programacin. - Uso de los estndares de Internet: Los servicios Web utilizan los estndares de Internet y evitan, en la medida de lo posible, reinventar soluciones a problemas que ya estn resueltas. - Soporte de cualquier lenguaje: La implementacin de un Servicio Web no est ligada a un particular lenguaje de programacin. Esta es una gran ventaja frente a otras tecnologas como Java RMI, que est completamente ligada al uso de lenguaje Java, haciendo realmente difcil hacer una llamada a un objeto Java desde un objeto Visual Basic o Perl. De este modo, un cliente puede implementar o usar un Servicio Web independientemente del lenguaje de programacin en el que fue implementado. - Soporte para cualquier infraestructura de componentes distribuidas: Los Servicios Web no estn ligados a una arquitectura de componentes en particular. Los protocolos facilitan a nivel base la comunicacin entre las distintas infraestructuras de objetos distribuidos. Por este motivo, nicamente es necesario preocuparse del desarrollo y utilizacin de Servicios Web. 2.2. PROTOCOLOS Y LENGUAJES IMPLICADOS EN EL DESARROLLO DE WEB SERVICES Los bloques necesarios para construir una aplicacin remota entre dos aplicaciones son los que se muestran en la figura 1. El objetivo de cada uno de estos bloques se detallan a continuacin: Discovery: Permite al cliente conocer la ubicacin de un Web Service. Description: Proporciona al cliente la informacin adecuada para que pueda interactuar con un Web Service. La descripcin de un Servicio Web abarca desde la estructura de metadatos de su interfaz (WSDL) hasta una documentacin detallada sobre su funcionalidad, incluyendo ejemplos de uso.

Desarrollo de Web Services con Software Libre

Message Format: Especifica el formato de codificacin de los mensajes para que el cliente y el servidor puedan comunicarse y la interpretacin de los datos sea la correcta. Encoding: Permite la codificacin de los datos que se transmiten en el cuerpo del mensaje, es decir, la serializacin de los datos. Transport: Realiza la transferencia del mensaje entre el cliente y el servidor mediante un protocolo de transporte.

Discovery UDDI, DISCO Description WSDL, XML Schema, Docs Message Format SOAP Encoding XML Transport HTTP, SMTP, etc

Figura 1. Bloques en la Comunicacin mediante Web Services

2.2.1. WSDL: Web Service Description Language WSDL es el lenguaje de descripcin de Web Services basado en XML. WSDL permite describir la interfaz ofrecida por un Web Service, las operaciones que el servicio puede soportar y los parmetros de entrada y salida. El elemento principal de un documento WSDL es el bloque de definiciones, aunque admite otras extensiones opcionales. El bloque de definiciones est compuesto a su vez por cinco bloques: Types, Message, PortType, Binding y Service. Types: Contiene las definiciones de los mensajes que pueden ser enviados o recibidos por un servicio. Se representan en un esquema utilizando XML Schema.
<?xml version="1.0" encoding="utf-8"?> <definitions> <types> <element name="Add"> <complexType> <all> <element name="x" type="int"/> <element name="y" type="int"/>

Desarrollo de Web Services con Software Libre

</all> </complexType> </element> <element name="SubtractResult"> <complexType> <all> <element name="result" type="int"/> </all> </complexType> </element> <element name="CalculateFault"> <complexType> <all> <element name="x" type="int"/> <element name="y" type="int"/> <element name="Description" type="string"/> </all> </complexType> </element> . . . </types> </definitions>

Message : Proporciona las asociaciones entre los mensajes y su definicin en el esquema.

<?xml version="1.0" encoding="utf-8"?> <definitions> <types> . . . </types> <message name="AddSoapIn"> <part name="parameters" element="s:Add"/> </message> <message name="AddSoapOut"> <part name="parameters" element="SubtractResult"/> </message> <message name="CalculateFaultMsg"> <part name="fault" element="s:CalculateFault"/> </message> . . . </definitions>

PortType : Define el conjunto de interfaces que ofrece el Web Service. Cada interfaz es asociada con uno o ms mensajes. Se especifica una interfaz por cada uno de los mtodos de acceso que se deseen utilizar SOAP, HTTPGET o HTTPPOST. En el siguiente ejemplo solamente se muestra para SOAP:
<?xml version="1.0" encoding="utf-8"?> <definitions> <types> . . . </types> <message> . . . </message>

<portType name="CalculatorSoapPortType"> <operation name="Add"> <input message="tns:AddSoapIn">

Desarrollo de Web Services con Software Libre

<output message="tns:AddSoapOut"> <fault message="tns:CalculateFaultMsg" name="CalculateFault"> </operation> . . . </portType> . . . </definitions>

Binding : Asocia la definicin portType con un protocolo concreto.

<?xml version="1.0" encoding="utf-8"?> <definitions> <types> . . . </types> <message> . . . </message> <portType> . . . </portType> <binding name="CalculatorSoapBinding" type="tns:CalculatorSoapPortType">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="IniciaSesionComprador"> <soap:operation soapAction="http://tempuri.org/IniciaSesionComprador" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation>
. . . </binding> . . . </definitions>

Service : Define una coleccin de puertos ofrecidos por el Web Service. Dichos puertos son cada elemento de Binding con su correspondiente URL.
<?xml version="1.0" encoding="utf-8"?> <definitions> <types> . . . </types> <message> . . . </message> <portType> . . . </portType> <binding> . . . </binding> <service name=" CalculatorService ">

<port name="CalculatorSoapPortType" binding="tns:CalculatorSoapBinding">

Desarrollo de Web Services con Software Libre

<soap:address location="http://localhost/MyCalculator/CalculatorSer vice.asmx" /> </port> </service>

. . . </definitions>

Adems de estos bloques, el bloque de definiciones establece los espacios de nombres que sern utilizados en el documento WSDL.
<?xml version="1.0" encoding="utf-8"?> <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://tempuri.org/" . . . targetNamespace="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/"> </definitions>

2.2.2. SOAP (Simple Object Access Protocol) SOAP es el protocolo diseado para acceder remotamente a los Web Services, pero se puede utilizar para realizar invocaciones remotas de diferente tipo. Sus caractersticas son las siguientes: No est restringido a un lenguaje ni a una plataforma. SOAP no especifica una API, lo que permite al programador abstraer el lenguaje sobre el que pueda estar implementado el objeto invocado. Esto facilita la reusabilidad de cdigo, y las actualizaciones de la aplicacin. No est restringido a un protocolo de transporte. La especificacin SOAP describe su transporte en HTTP pero puede ser transmitido en cualquier protocolo de transporte de texto. No est restringido a un Middleware. Est basado en estndares ya existentes. De hecho, incluso el sistema de tipos que utiliza es el de XML. Hace posible la comunicacin entre entornos muy heterogneos, ya que cualquier aplicacin capaz de escribir y leer XML sobre HTTP puede utilizar SOAP.

Un mensaje SOAP esta estructurado en una cabecera y un cuerpo. En primer lugar aparece la cabecera , es opcional y sirve para poner informacin complementaria al cuerpo. Por ejemplo, si la informacin del cuerpo del mensaje estuviera comprimida o cifrada, aqu se indicara la informacin a cerca de la compresin o del cifrado. Como este campo es opcional, y muchas aplicaciones lo ignoran, para evitar que sea descartada se debe indicar con la etiqueta mustUnderstand=1. A continuacin aparece el cuerpo del mensaje, que es obligatorio. Aqu puede aparecer cualquier texto, pero en la especificacin de SOAP se propone un mtodo de codificacin que se describe a continuacin:

Desarrollo de Web Services con Software Libre

Dentro del bloque body, hay que definir otro con el nombre del mtodo, y dentro de ste, tantos como parmetros necesite la invocacin. Los parmetros debern tener el mismo nombre, y posicin que en la definicin del mtodo. A continuacin se muestra la diferencia entre el uso de tipos simples y tipos estructuradas en un mensaje SOAP. - Tipos simples: Los tipos simples de XML son un conjunto de tipos estndar para muchos lenguajes de programacin (int, boolean, float, string ...). Una instancia de estos tipos es codificada como un elemento XML, por ejemplo: Invocacin:
public int Suma(int x, int y) { return x + y; }

Mensaje SOAP equivalente a la invocacin:

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <Suma> <x>1</x> <y>2</y> </Suma> </soap:Body> </soap:Envelope>

Mensaje SOAP obtenido tras la invocacin:

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <SumaResult> <Result>3</Result> </SumaResult> </soap:Body> </soap:Envelope>

- Tipos Estructura dos: Se codifica la estructura como un elemento XML, y dentro del mismo cada uno de sus campos. - Estructuras Invocacin:
Public struct angulo { public int grados; public int minutos; public int segundos; }

Desarrollo de Web Services con Software Libre

Mensaje SOAP equivalente a la invocacin:

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <girar> <a> <grados>12</grados> <minutos>15</minutos> <segundos>34</segundos> </a> </girar> </soap:Body> </soap:Envelope>

Vectores Definicin:
int[] valores = [1, 2, 3]; media(valores);

Mensaje SOAP equivalente a la definicin:

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <media> <valores soap-enc:arrayType="xsi:int[3]"> <int>1</int> <int>2</int> <int>3</int> </valores> </media> </soap:Body> </soap:Envelope>

El paso de parmetros por referencia tambin est contemplado. Una invocacin a un procedimiento con parmetros por referencia es exactamente igual que si fueran por valor. La diferencia radica en que el mensaje de respuesta nos retornar tambin los parmetros, con sus nuevos valores. SOAP tambin proporciona un mecanismo para comunicar que se ha producido un error en el servidor, mientras procesaba la peticin. Para ello incorpora el elemento Fault en el boque body. Existen una serie de errores predeterminados, cuyo significado se detalla a continuacin:

Desarrollo de Web Services con Software Libre

VersionMismatch: Se ha especificado un namespace errneo para el elemento envelope. MustUnderstand: Hay problemas con algn elemento que tiene puesto el atributo mustUnderstand a uno. Client: El cuerpo del mensaje presenta alguna irregularidad, como por ejemplo estar incompleto o mal estructurado. Server El mensaje es en s correcto, pero el procesamiento del mismo ha derivado en algn error, como pueden ser accesos a bases de datos, divisin por cero, etc.

2.2.3 UDDI: Universal Description, Discovery and Integration

UDDI proporciona un servicio de directorio centralizado para publicar informacin acerca de Web Services. En el directorio UDDI se publican los ficheros WSDL que describen a los Web Services que se ofertan. Presenta una estructura (ver figura 2) formada por un conjunto de elementos tipo Registry y otro de elementos tipo Registrar. Los Registry tienen una copia del directorio UDDI al completo, mientras que los Registrar proporcionan servicios de registro al cliente. Un Registrar puede estar proporcionado por una compaa, que tenga su Registry, y mediante una interfaz HTML, por ejemplo, nos permita modificar los registros del directorio. Los cambios hechos en un Registry, son actualizados automticamente en el resto. Un cliente accede a un Registry mediante uno de los Registrar del mismo, y los cambios se propagan a los dems.

Registrar

Registrar

Registrar

Registrar

Registrar

Registrar

Registry

Registry

Figura 2. Estructura UDDI

2.2.4. DISCO: DISCOvery La alternativa a UDDI se denomina DISCO (de Discovery). La diferencia con UDDI es que con UDDI es complicado averiguar que Web Services ofrece una determinada mquina. DISCO ofrece un acceso a los Web Services de una mquina de manera similar a la navegacin por enlaces de HTML, presentando una lista de Web Services y referencias a otros ficheros DISCO.

10

Desarrollo de Web Services con Software Libre

3. ARQUITECTURA WEB SERVICES

En una arquitectura de Web Services hay dos partes claramente diferenciables, el modo de utilizar un Web Services y cmo desarrollarlo. A continuacin se detallan las partes implicadas y los pasos necesarios para publicar un Web Service ya desarrollado y cmo puede ser utilizado (ver figura 3). 1.- El programador desarrolla el Web Service 2.- El programador describe el Web Service en un fichero WSDL 3.- El programador publica el Web Service en un directorio como UDDI 4.- La persona subscrita al directorio busca el Web Service 5.- La persona subscrita al directorio invoca el servicio con SOAP 6.- La persona subscrita al directorio recibe la respuesta mediante SOAP.

UDDI
WSDL WSDL

Subscribe Invoca Registrado (el que esta subscrito)

Publica Programador (el que publica)

SOAP sobre HTTP

Figura 3. Web Services en accin

La arquitectura necesaria para el desarrollo de Web Services es la de un servidor que contenga las herramientas adecuadas para el soporte al desarrollo de este tipo de tecnologa. Estas herramientas proporcionan el entorno de desarrollo de Web Services y la gestin de invocaciones de los servicios Web.

4. DESARROLLO DE WEB SERVICES CON SOFTWARE LIBRE

Existen varias posibilidades de desarrollo de Web Services usando software libre, siendo Java el lenguaje de programacin que se utiliza. El uso de los Web Services a travs de la Web hace necesario que se puedan utilizar en diferentes plataformas. Debido a este requisito Java se presenta como uno de los ms firmes candidatos para el desarrollo de Servicios Web, ya que asegura que su cdigo sea portable. Adems, la eleccin de Java se hace ms firme y adecuada debido a las APIs que incorpora para XML, haciendo el uso de XML embebido en cdigo Java mucho ms fcil. Estas APIs se incorporan en un paquete de desarrollo de Java para la programacin de Web Services. Existe la posibilidad de utilizarlo directamente programando en Java, o bien, utilizar herramientas que hacen un uso ms transparente de este paquete.

11

Desarrollo de Web Services con Software Libre

3.1. JAVA WEB SERVICES DEVELOPER PACK ( JAVA WSDP) Java WSDP es un paquete que incluye ficheros JAR que implementan las APIs para el desarrollo de Web Services y adjuntan una buena documentacin con ejemplos. Estos ejemplos pueden ser ejecutados tanto en Tomcat como J2EE. La ventaja de estas APIs es que todas ellas aseguran interoperabilidad y flexibilidad, ya que soportan estndares industriales. Las APIs de Java para XML definen unos requisitos de compatibilidad que aseguran que todas las implementaciones proporcionan la funcionalidad estndar y proporcionan mucha libertad para desarrollar implementaciones que toleren usos especficos. El desarrollo de Web Services mediante WSDP y TomCat proporciona una serie de herramientas que facilitan la implantancin de una aplicacin Web: - Ant: Se utiliza para la compilacin del ficheros con cdigo Java y la generacin de la jerarqua para la implantacin de la aplicacin Web. Dicha jerarqua tiene un diseo estandar para la estructuracin de ficheros y directorios. - DeployTool: Al igual que Ant se utiliza para la implantacin de una aplicacin Web desarrollada con Web Services. DeployTool crea un Web Application aRchive (WAR) para implantar la aplicacin Web y gestionar aspectos de seguridad. - AdminTool: Sirve ara manipular TomCat mientras esta ejecutandose.

El desarrollo de Web Services mediante WSDP y J2EE proporciona una serie de herramientas que facilitan la implantancin de una aplicacin Web: - DeployTool: Esta herramienta se utiliza para crear una nueva aplicacin (fichero EAR) (ver figura 4), posteriormente el fichero se asocia al fichero WAR apropiado y se le asigna su contexto Web (ver figura 5). DeployTool se comunica con el servidor J2EE para implantar la aplicacin Web o eliminar componentes. - JAXM Admin Tool: Herramienta (ver figura 6) que configura el JAXM provider. JAXM Provider es un proveedor de mensajes necesario para soportar mensajes asncronos.

12

Desarrollo de Web Services con Software Libre

Figura 4. Creacin de un fichero EAR

Figura 5. Asignacin del Contexto Web

Figura 6. JAXM Admin Tool

3.2. AXIS AXIS es un conjunto de herramientas de Apache para el desarrollo de Web Services, tanto la parte cliente como la servidora. AXIS est basada en los estndares HTTP, SOAP, WDSL y XML. Con AXIS se puede implementar desde un Web Service bsico hasta un gran servicio comercial, pasando por una applet de Java que interactua con Web Services de otros proveedores.

13

Desarrollo de Web Services con Software Libre

WSDL2java es una herramienta de AXIS que interpreta ficheros WSDL y emite cdigo Java que encapsula toda la intercomunicacin entre Web Services. Esta herramienta facilita la labor de obtener la informacin necesaria para invocar un Web Service (URL, nombre, parmetros, tipo de los parmetros, etc) cuando estamos desarrollando un Web Service cliente, ya que dicha informacin se detalla en un fichero WSDL. Adems, reduce el esfuerzo de realizar llamadas remotas al hacer el proceso interno ms transparente al usuario. WSDL2java tambin facilita la labor de desarrollo de un Web Service servidor, ya que a partir del cdigo java del Web Service es capaz de generar automticamente el WSDL que lo describe para su posterior publicacin. Tcpmon es una herramienta para monitorizar y visualizar el trfico de entrada y de salida de un Web Service en ejecucin. Tambin se utiliza para la compilacin del cdigo. AXIS facilita la implantacin y gestin de Web Services. La forma ms rpida de crear un Web Service con AXIS consiste en dejar un fichero de cdigo java dentro del directorio de aplicaciones Web de AXIS. Otra manera es haciendo uso de Web Services Deployment Descriptors (WSDD), que permiten un mayor control y flexibilidad. Por ejemplo, los ficheros WSDD permiten habilitar o deshabilitar mtodos individuales de un Web Service. AXIS tambin incorpora una serie de herramientas para la administracin del sistema. La herramienta AdminClient te ayuda al implantacin de Web Services y a que clientes potenciales puedan utilizar los Web Services desarrollados de forma sencilla. Para el desarrollo de un Web Service utilizando AXIS es necesario instalar la herramienta el un servidor Linux con Tomcat instado como servidor Web y motor para servlets. El acceso a BD con AXIS se hace mediante una conexin JDBC a la BD del SGBD con el que se desee trabajar. Si se desean desarrollar con AXIS, Web Services basados en J2EE es necesario instalar JBoss.net. JBoss.net es un plugin a la aplicacin servidora JBoss que facilita la implementacin y publicacin de Web Services basados en J2EE y permite que Web Services de otras plataformas puedan ejecutarse dentro del entorno J2EE. Adems JBoss permite trabajar no solo con TomCat, tambin con Jetty como contenedor Web. Existen otras herramientas para el desarrollo de Web Services sobre linux que se estn utilizando tanto como AXIS, como por ejemplo: Case Suite. Sin embargo, estas herramientas no son de software libre. Por lo tanto, AXIS es la herramienta de software libre para el desarrollo de Web Services ms extendida.

14

Desarrollo de Web Services con Software Libre

3.2. WASP sobre ECLIPSE IBM Eclipse es un entorno de desarrollo Java que no slo permite desarrollar aplicaciones Java, sino que tambin permite codificar plugins para la propia herramienta. De forma que es posible aadir funcionalidad y modificarla segn las necesidades de desarrollo del programador, esta flexibilidad es una gran ventaja. Este entorno de desarrollo de IBM funciona sobre Windows y sobre Linux. Entre los distintos plugins que hay desarrollados y se pueden incorporar en Eclipse, se encuentra WASP. WASP es un entorno de desarrollo que soporta Eclipse para el desarrollo, depuracin y gestin de aplicaciones basadas en Web Services, pero tambin puede utilizarse sobre Sun ONE Studio (y NetBeans que es su software libre equivalente) y Borland JBuilder. Esta es una de las ventajas de WASP, ya que te permite elegir entre diferentes entornos de desarrollo, dependiendo de tus intereses y del que al usuario resulte ms ergonmico y gil. Si bien es cierto, en cuanto a software libre se refiere, Eclipse es mucho ms rpido que NetBeans en cuanto al refresco de las pantallas del entorno, de ah que este informe se centre en Eclipse. Con WASP, tu puedes desarrollar un Web Service como si implementases una clase java cualquiera, tan slo se ha de implantar en el servidor embebido. A partir de ese momento, se pueden desarrollar clientes que hagan llamadas remotas a sus servicios utilizando el envo de mensajes cliente servidor va SOAP. Una vez finalizada la aplicacin es posible registrar los servicios en el registro UDDI. Algunas de las ventajas que ofrece este pluing es que realiza la generacin automtica del fichero WDSL a partir de las clases java, que SOAPSpy rastrea los mensajes SOAP entre cliente y servidor y el servidor WASP soporta la gestin de la implantacin de la aplicacin sobre el sistema.

15