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 Publica
Invoca
Registrado Programador
(el que esta (el que
subscrito) SOAP sobre HTTP publica)

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