Desarrollo de Web Services con Software Libre

Web Services
Jennifer Pérez Benedí Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia C/Camino de Vera s/n E-46071 Valencia- España jeperez@dsic.upv.es

1. ¿POR QUÉ WEB SERVICES?
Existen diversas razones por las que han surgido los Web Services y están teniendo tanto éxito. Entre ellas está el hecho de que los sistemas de información actuales son cada vez más complejos y está surgiendo una tendencia a la programación orientada a componentes y un abandono de la programación orientada a objetos. La aproximación a la programación orientada a componentes de los Web Services hace que muchas empresas opten por esta tecnología. 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 tecnologías son bastante pesadas y el restablecimiento de la conexión con un objeto remoto resulta muy costoso. Debido a esto, surge la necesidad de crear una nueva tecnología desde cero, los Web Services. A continuación 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 están libres por encima del 1024. Por ese motivo, estos middleware establecen y gestionan sus políticas de seguridad (java.policy en Java RMI) de forma eficaz, haciendo que la comunicación de un cliente con un servidor a través 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 comunicación 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 conexión 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 función del cortafuegos es proteger una Intranet evitando que entren en ella transmisiones de red no deseadas , aplicando la filosofía de lo que no está permitido expresamente es negado.

1

Desarrollo de Web Services con Software Libre

§

§

Hacen muy difícil mantener una infraestructura balanceada en su carga que permita lograr una alta escalabilidad, ya que cuando una conexión entre un cliente y un servidor se rompe no se puede cambiar y enviar la siguiente petición a otro servidor. No gestionan de una forma satisfactoria las interrupciones en la conexión. 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 conexión.

Otro aspecto que ha propiciado esta tendencia hacia los Web Services es que la mayor parte del tráfico de Internet se limita a un conjunto de protocolos (http, ftp y algunos de correo) de los que el más importante volumen de información 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. Además, XML es un lenguaje de marcado que esta siendo utilizado por la mayoría de empresas debido a sus ventajas. Entre todas ellas cabe destacar la compartición de datos interna (entre departamentos) y externa (con otras empresas). Esta situación ha desencadenado un mayor interés por la integración, de datos mediante XML y de aplicaciones usando Web Services. A la hora de adoptar esta nueva tecnología se han de tener en cuenta las necesidades y el área de la empresa. En concreto, la tecnología Web Services está orientada a aplicaciones de e-comerce, haciendo que la mayoría de Web Services sean transacciones business-to-business (B-to-B). Otra consideración a tener en cuenta es que adaptar todo el software desarrollado a esta tecnología resulta caro, a pesar de la reutilización de código y de utilizar Linux y herramientas de sofware libre. Por estos motivos, es necesario tener en cuenta que cuanta mayor inversión se realice en la Web, más 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 tecnologías son para el desarrollo y ejecución 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 través de la Web. Una compañía puede ser tanto proveedora como consumidora de Web Services. Un Web Service es una clase cuya interfaz se puede hacer pública en un servidor Web mediante un lenguaje de descripción de interfaces (WSDL). Dicha interfaz ofrece un conjunto de actividades que un cliente puede invocar. El cliente accede al Web Service usando los estándares de Internet. Para acceder a un Web Service se pueden utilizar varios protocolos Web estándar como HTTP GET o HTTP POST, aunque se ha diseñado un protocolo específicamente diseñado para ello: SOAP (Simple Object Access Protocol). Este protocolo se basa en la utilización de HTTP para el transporte de mensajes y el lenguaje

2

Desarrollo de Web Services con Software Libre

XML para la escritura del cuerpo de estos mensajes. Todo esto permite a cualquier aplicación 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 ubicación (URL) de un Web Service se accede a un directorio centralizado utilizando protocolos como UDDI (Universal Description, Discovery, and Integration) o DISCO. 2.1. CARACTERÍSTICAS Las características de esta nueva tecnología 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 gestión 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 mayoría de lenguajes de programación. - Uso de los estándares de Internet: Los servicios Web utilizan los estándares de Internet y evitan, en la medida de lo posible, reinventar soluciones a problemas que ya están resueltas. - Soporte de cualquier lenguaje: La implementación de un Servicio Web no está ligada a un particular lenguaje de programación. Esta es una gran ventaja frente a otras tecnologías como Java RMI, que está completamente ligada al uso de lenguaje Java, haciendo realmente difícil 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 programación en el que fue implementado. - Soporte para cualquier infraestructura de componentes distribuidas: Los Servicios Web no están ligados a una arquitectura de componentes en particular. Los protocolos facilitan a nivel base la comunicación entre las distintas infraestructuras de objetos distribuidos. Por este motivo, únicamente es necesario preocuparse del desarrollo y utilización de Servicios Web. 2.2. PROTOCOLOS Y LENGUAJES IMPLICADOS EN EL DESARROLLO DE WEB SERVICES Los bloques necesarios para construir una aplicación remota entre dos aplicaciones son los que se muestran en la figura 1. El objetivo de cada uno de estos bloques se detallan a continuación: Discovery: Permite al cliente conocer la ubicación de un Web Service. Description: Proporciona al cliente la información adecuada para que pueda interactuar con un Web Service. La descripción de un Servicio Web abarca desde la estructura de metadatos de su interfaz (WSDL) hasta una documentación detallada sobre su funcionalidad, incluyendo ejemplos de uso.

3

Desarrollo de Web Services con Software Libre

-

-

Message Format: Especifica el formato de codificación de los mensajes para que el cliente y el servidor puedan comunicarse y la interpretación de los datos sea la correcta. Encoding: Permite la codificación de los datos que se transmiten en el cuerpo del mensaje, es decir, la serialización 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 Comunicación mediante Web Services

2.2.1. WSDL: Web Service Description Language WSDL es el lenguaje de descripción 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 parámetros 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"/>

4

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 definición 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 más mensajes. Se especifica una interfaz por cada uno de los métodos 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">

5

Desarrollo de Web Services con Software Libre

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

• Binding : Asocia la definición 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 colección 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">

6

Desarrollo de Web Services con Software Libre

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

Además de estos bloques, el bloque de definiciones establece los espacios de nombres que serán 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 diseñado para acceder remotamente a los Web Services, pero se puede utilizar para realizar invocaciones remotas de diferente tipo. Sus características 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 código, y las actualizaciones de la aplicación. No está restringido a un protocolo de transporte. La especificación 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 estándares ya existentes. De hecho, incluso el sistema de tipos que utiliza es el de XML. Hace posible la comunicación entre entornos muy heterogéneos, ya que cualquier aplicación 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 información complementaria al cuerpo. Por ejemplo, si la información del cuerpo del mensaje estuviera comprimida o cifrada, aquí se indicaría la información a cerca de la compresión 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 continuación aparece el cuerpo del mensaje, que es obligatorio. Aquí puede aparecer cualquier texto, pero en la especificación de SOAP se propone un método de codificación que se describe a continuación:

7

Desarrollo de Web Services con Software Libre

Dentro del bloque body, hay que definir otro con el nombre del método, y dentro de éste, tantos como parámetros necesite la invocación. Los parámetros deberán tener el mismo nombre, y posición que en la definición del método. A continuación 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 estándar para muchos lenguajes de programación (int, boolean, float, string ...). Una instancia de estos tipos es codificada como un elemento XML, por ejemplo: Invocación:
public int Suma(int x, int y) { return x + y; }

Mensaje SOAP equivalente a la invocación:
<?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 invocación:
<?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 Invocación:
Public struct angulo { public int grados; public int minutos; public int segundos; }

8

Desarrollo de Web Services con Software Libre

Mensaje SOAP equivalente a la invocación:
<?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 Definición:
int[] valores = [1, 2, 3]; media(valores);

Mensaje SOAP equivalente a la definición:
<?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 parámetros por referencia también está contemplado. Una invocación a un procedimiento con parámetros por referencia es exactamente igual que si fueran por valor. La diferencia radica en que el mensaje de respuesta nos retornará también los parámetros, con sus nuevos valores. SOAP también proporciona un mecanismo para comunicar que se ha producido un error en el servidor, mientras procesaba la petición. Para ello incorpora el elemento Fault en el boque body. Existen una serie de errores predeterminados, cuyo significado se detalla a continuación:

9

Desarrollo de Web Services con Software Libre

-

-

VersionMismatch: Se ha especificado un namespace erróneo para el elemento envelope. MustUnderstand: Hay problemas con algún 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 algún error, como pueden ser accesos a bases de datos, división por cero, etc.

2.2.3 UDDI: Universal Description, Discovery and Integration

UDDI proporciona un servicio de directorio centralizado para publicar información 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 compañía, 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 automáticamente en el resto. Un cliente accede a un Registry mediante uno de los Registrar del mismo, y los cambios se propagan a los demás.

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 máquina. DISCO ofrece un acceso a los Web Services de una máquina de manera similar a la navegación 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 cómo desarrollarlo. A continuación se detallan las partes implicadas y los pasos necesarios para publicar un Web Service ya desarrollado y cómo 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 acción

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 tecnología. Estas herramientas proporcionan el entorno de desarrollo de Web Services y la gestión 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 programación que se utiliza. El uso de los Web Services a través de la Web hace necesario que se puedan utilizar en diferentes plataformas. Debido a este requisito Java se presenta como uno de los más firmes candidatos para el desarrollo de Servicios Web, ya que asegura que su código sea portable. Además, la elección de Java se hace más firme y adecuada debido a las APIs que incorpora para XML, haciendo el uso de XML embebido en código Java mucho más fácil. Estas APIs se incorporan en un paquete de desarrollo de Java para la programación de Web Services. Existe la posibilidad de utilizarlo directamente programando en Java, o bien, utilizar herramientas que hacen un uso más 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 documentación 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 estándares industriales. Las APIs de Java para XML definen unos requisitos de compatibilidad que aseguran que todas las implementaciones proporcionan la funcionalidad estándar y proporcionan mucha libertad para desarrollar implementaciones que toleren usos específicos. El desarrollo de Web Services mediante WSDP y TomCat proporciona una serie de herramientas que facilitan la implantanción de una aplicación Web: - Ant: Se utiliza para la compilación del ficheros con código Java y la generación de la jerarquía para la implantación de la aplicación Web. Dicha jerarquía tiene un diseño estandar para la estructuración de ficheros y directorios. - DeployTool: Al igual que Ant se utiliza para la implantación de una aplicación Web desarrollada con Web Services. DeployTool crea un Web Application aRchive (WAR) para implantar la aplicación 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 implantanción de una aplicación Web: - DeployTool: Esta herramienta se utiliza para crear una nueva aplicación (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 aplicación 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 asíncronos.

12

Desarrollo de Web Services con Software Libre

Figura 4. Creación de un fichero EAR

Figura 5. Asignación 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 estándares HTTP, SOAP, WDSL y XML. Con AXIS se puede implementar desde un Web Service básico 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 código Java que encapsula toda la intercomunicación entre Web Services. Esta herramienta facilita la labor de obtener la información necesaria para invocar un Web Service (URL, nombre, parámetros, tipo de los parámetros, etc) cuando estamos desarrollando un Web Service cliente, ya que dicha información se detalla en un fichero WSDL. Además, reduce el esfuerzo de realizar llamadas remotas al hacer el proceso interno más transparente al usuario. WSDL2java también facilita la labor de desarrollo de un Web Service servidor, ya que a partir del código java del Web Service es capaz de generar automáticamente el WSDL que lo describe para su posterior publicación. Tcpmon es una herramienta para monitorizar y visualizar el tráfico de entrada y de salida de un Web Service en ejecución. También se utiliza para la compilación del código. AXIS facilita la implantación y gestión de Web Services. La forma más rápida de crear un Web Service con AXIS consiste en dejar un fichero de código 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 métodos individuales de un Web Service. AXIS también incorpora una serie de herramientas para la administración del sistema. La herramienta AdminClient te ayuda al implantación 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 conexión 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 aplicación servidora JBoss que facilita la implementación y publicación de Web Services basados en J2EE y permite que Web Services de otras plataformas puedan ejecutarse dentro del entorno J2EE. Además JBoss permite trabajar no solo con TomCat, también con Jetty como contenedor Web. Existen otras herramientas para el desarrollo de Web Services sobre linux que se están 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 más extendida.

14

Desarrollo de Web Services con Software Libre

3.2. WASP sobre ECLIPSE IBM Eclipse es un entorno de desarrollo Java que no sólo permite desarrollar aplicaciones Java, sino que también permite codificar plugins para la propia herramienta. De forma que es posible añadir funcionalidad y modificarla según 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, depuración y gestión de aplicaciones basadas en Web Services, pero también 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 más ergonómico y ágil. Si bien es cierto, en cuanto a software libre se refiere, Eclipse es mucho más rápido 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 sólo 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 envío de mensajes cliente servidor vía SOAP. Una vez finalizada la aplicación es posible registrar los servicios en el registro UDDI. Algunas de las ventajas que ofrece este pluing es que realiza la generación automática 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 gestión de la implantación de la aplicación sobre el sistema.

15