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

La ventaja de los Web Services es que utilizan toda esta infraestructura ya establecida. ftp y algunos de correo) de los que el más importante volumen de información es http (puerto 80) junto con XML. 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. Además. Una compañía puede ser tanto proveedora como consumidora de Web Services. Por estos motivos.Desarrollo de Web Services con Software Libre § § Hacen muy difícil mantener una infraestructura balanceada en su carga que permita lograr una alta escalabilidad. más conveniente es utilizar Web Services. aunque se ha diseñado un protocolo específicamente diseñado para ello: SOAP (Simple Object Access Protocol). Los Web Services los utilizan normalmente las empresas de negocios con el fin de ofertar sus servicios a través de la Web. Esta situación ha desencadenado un mayor interés por la integración. No gestionan de una forma satisfactoria las interrupciones en la conexión. haciendo que la mayoría de Web Services sean transacciones business-to-business (B-to-B). Entre todas ellas cabe destacar la compartición de datos interna (entre departamentos) y externa (con otras empresas). aunque las principales ventajas que aporta frente a otras tecnologías son para el desarrollo y ejecución de escenarios Web. 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). XML es un lenguaje de marcado que esta siendo utilizado por la mayoría de empresas debido a sus ventajas. a pesar de la reutilización de código y de utilizar Linux y herramientas de sofware libre. Para acceder a un Web Service se pueden utilizar varios protocolos Web estándar como HTTP GET o HTTP POST. Este es un gran inconveniente porque Internet no está bajo el control del administrador de red y por lo tanto. Dicha interfaz ofrece un conjunto de actividades que un cliente puede invocar. WEB SERVICES Un Web Service es un servicio que se ofrece mediante la web. 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 se puede asegurar ni la calidad ni la fiabilidad de la conexión. El cliente accede al Web Service usando los estándares de Internet. es necesario tener en cuenta que cuanta mayor inversión se realice en la Web. Este protocolo se basa en la utilización de HTTP para el transporte de mensajes y el lenguaje 2 . sin la necesidad de inventar otra nueva. la tecnología Web Services está orientada a aplicaciones de e-comerce. 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. Otra consideración a tener en cuenta es que adaptar todo el software desarrollado a esta tecnología resulta caro. de datos mediante XML y de aplicaciones usando Web Services. Esto no significa que no se puedan utilizar Web Services en aplicaciones que no sean orientadas a la Web. 2.

El servicio recibe la solicitud. Los protocolos facilitan a nivel base la comunicación entre las distintas infraestructuras de objetos distribuidos. 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. Por este motivo.1. Para conocer la ubicación (URL) de un Web Service se accede a un directorio centralizado utilizando protocolos como UDDI (Universal Description. .2. CARACTERÍSTICAS Las características de esta nueva tecnología son las que se citan en los siguientes subapartados. únicamente es necesario preocuparse del desarrollo y utilización de Servicios Web.Interoperabilidad: Los Servicios Web se pueden consumir por clientes de otras plataformas. . en la medida de lo posible.Soporte de cualquier lenguaje: La implementación de un Servicio Web no está ligada a un particular lenguaje de programación. haciendo realmente difícil hacer una llamada a un objeto Java desde un objeto Visual Basic o Perl. Description: Proporciona al cliente la información adecuada para que pueda interactuar con un Web Service. 3 . 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. un cliente puede implementar o usar un Servicio Web independientemente del lenguaje de programación en el que fue implementado. .Desarrollo de Web Services con Software Libre XML para la escritura del cuerpo de estos mensajes. la procesa y devuelve una respuesta. . De este modo. reinventar soluciones a problemas que ya están resueltas. . 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. que está completamente ligada al uso de lenguaje Java. . La solicitud de un Servicio Web se realiza a una determinada URL utilizando el protocolo SOAP.Uso de los estándares de Internet: Los servicios Web utilizan los estándares de Internet y evitan. Todo esto permite a cualquier aplicación ser capaz de generar e interpretar mensajes en SOAP independientemente de la plataforma. Discovery. incluyendo ejemplos de uso.Soporte para cualquier infraestructura de componentes distribuidas: Los Servicios Web no están ligados a una arquitectura de componentes en particular.Acceso externo desde Internet: Los Servicios Web realizan una buena gestión para los accesos que provienen de clientes de Internet. 2. 2.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. and Integration) o DISCO. Esta es una gran ventaja frente a otras tecnologías como Java RMI.

las operaciones que el servicio puede soportar y los parámetros de entrada y salida. Discovery UDDI. Encoding: Permite la codificación de los datos que se transmiten en el cuerpo del mensaje. El elemento principal de un documento WSDL es el bloque de definiciones. <?xml version="1.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.1. PortType. Se representan en un esquema utilizando XML Schema. Bloques en la Comunicación mediante Web Services 2.2. WSDL: Web Service Description Language WSDL es el lenguaje de descripción de Web Services basado en XML. DISCO Description WSDL. XML Schema. es decir. etc Figura 1. Message. aunque admite otras extensiones opcionales. SMTP. • Types: Contiene las definiciones de los mensajes que pueden ser enviados o recibidos por un servicio.0" encoding="utf-8"?> <definitions> <types> <element name="Add"> <complexType> <all> <element name="x" type="int"/> <element name="y" type="int"/> 4 . Binding y Service. WSDL permite describir la interfaz ofrecida por un Web Service. Docs Message Format SOAP Encoding XML Transport HTTP. la serialización de los datos. El bloque de definiciones está compuesto a su vez por cinco bloques: Types. Transport: Realiza la transferencia del mensaje entre el cliente y el servidor mediante un protocolo de transporte.

.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> . . HTTPGET o HTTPPOST. En el siguiente ejemplo solamente se muestra para SOAP: <?xml version="1. </types> </definitions> • Message : Proporciona las asociaciones entre los mensajes y su definición en el esquema. </message> <portType name="CalculatorSoapPortType"> <operation name="Add"> <input message="tns:AddSoapIn"> 5 . . . . Cada interfaz es asociada con uno o más mensajes. . </definitions> • PortType : Define el conjunto de interfaces que ofrece el Web Service.0" encoding="utf-8"?> <definitions> <types> . .0" encoding="utf-8"?> <definitions> <types> . . <?xml version="1. </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> . . </types> <message> . Se especifica una interfaz por cada uno de los métodos de acceso que se deseen utilizar SOAP. .

.xmlsoap. . Dichos puertos son cada elemento de Binding con su correspondiente URL. . .org/IniciaSesionComprador" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> . </message> <portType> . .0" encoding="utf-8"?> <definitions> <types> . . . </portType> <binding name="CalculatorSoapBinding" type="tns:CalculatorSoapPortType"> <soap:binding transport="http://schemas. . . . . . </definitions> • Service : Define una colección de puertos ofrecidos por el Web Service. . </binding> <service name=" CalculatorService "> <port name="CalculatorSoapPortType" binding="tns:CalculatorSoapBinding"> 6 . . </types> <message> . . <?xml version="1. </definitions> • Binding : Asocia la definición portType con un protocolo concreto. <?xml version="1. . </portType> . . </message> <portType> . . . . . </types> <message> . </binding> .org/soap/http" style="document" /> <operation name="IniciaSesionComprador"> <soap:operation soapAction="http://tempuri. . </portType> <binding> .0" encoding="utf-8"?> <definitions> <types> .Desarrollo de Web Services con Software Libre <output message="tns:AddSoapOut"> <fault message="tns:CalculateFaultMsg" name="CalculateFault"> </operation> .

. incluso el sistema de tipos que utiliza es el de XML. <?xml version="1. Aquí puede aparecer cualquier texto. </definitions> Además de estos bloques. .org/" xmlns="http://schemas. En primer lugar aparece la cabecera . aquí se indicaría la información a cerca de la compresión o del cifrado. si la información del cuerpo del mensaje estuviera comprimida o cifrada.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri. SOAP (Simple Object Access Protocol) SOAP es el protocolo diseñado para acceder remotamente a los Web Services. Por ejemplo.0" encoding="utf-8"?> <definitions xmlns:http="http://schemas.xmlsoap. Como este campo es opcional. ya que cualquier aplicación capaz de escribir y leer XML sobre HTTP puede utilizar SOAP. para evitar que sea descartada se debe indicar con la etiqueta ‘mustUnderstand=”1”’. y las actualizaciones de la aplicación. Hace posible la comunicación entre entornos muy heterogéneos. Esto facilita la reusabilidad de código.Desarrollo de Web Services con Software Libre <soap:address location="http://localhost/MyCalculator/CalculatorSer vice. De hecho. Sus características son las siguientes: No está restringido a un lenguaje ni a una plataforma. . pero se puede utilizar para realizar invocaciones remotas de diferente tipo.org/wsdl/http/" xmlns:soap=http://schemas.xmlsoap. SOAP no especifica una API. La especificación SOAP describe su transporte en HTTP pero puede ser transmitido en cualquier protocolo de transporte de texto. .xmlsoap.org/wsdl/"> </definitions> 2.org/" . No está restringido a un protocolo de transporte. lo que permite al programador abstraer el lenguaje sobre el que pueda estar implementado el objeto invocado. targetNamespace="http://tempuri. pero en la especificación de SOAP se propone un método de codificación que se describe a continuación: 7 .org/wsdl/soap/" xmlns:s="http://www. el bloque de definiciones establece los espacios de nombres que serán utilizados en el documento WSDL.asmx" /> </port> </service> . Está basado en estándares ya existentes.2.2. A continuación aparece el cuerpo del mensaje. - - Un mensaje SOAP esta estructurado en una cabecera y un cuerpo. es opcional y sirve para poner información complementaria al cuerpo. y muchas aplicaciones lo ignoran. que es obligatorio. No está restringido a un Middleware.

0"?> <soap:Envelope xmlns:soap="http://schemas. hay que definir otro con el nombre del método. Los parámetros deberán tener el mismo nombre.Tipos Estructura dos: Se codifica la estructura como un elemento XML.). Una instancia de estos tipos es codificada como un elemento XML. boolean.Estructuras Invocación: Public struct angulo { public int grados. } Mensaje SOAP equivalente a la invocación: <?xml version="1. float. A continuación se muestra la diferencia entre el uso de tipos simples y tipos estructuradas en un mensaje SOAP. public int minutos. por ejemplo: Invocación: public int Suma(int x. . tantos como parámetros necesite la invocación.xmlsoap.Desarrollo de Web Services con Software Libre Dentro del bloque body.0"?> <soap:Envelope xmlns:soap="http://schemas.Tipos simples: Los tipos simples de XML son un conjunto de tipos estándar para muchos lenguajes de programación (int. public int segundos.xmlsoap. int y) { return x + y.org/soap/envelope/"> <soap:Body> <SumaResult> <Result>3</Result> </SumaResult> </soap:Body> </soap:Envelope> . . y dentro del mismo cada uno de sus campos.. } 8 .. y posición que en la definición del método. y dentro de éste.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. string .

2. mientras procesaba la petición. con sus nuevos valores. Mensaje SOAP equivalente a la definición: <?xml version="1. 3]. media(valores).org/soap/encoding/" xmlns:xsi="http://www. cuyo significado se detalla a continuación: 9 .org/soap/envelope/" xmlns:soap-enc="http://schemas.0"?> <soap:Envelope xmlns:soap="http://schemas.Desarrollo de Web Services con Software Libre Mensaje SOAP equivalente a la invocación: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.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. Existen una serie de errores predeterminados. Para ello incorpora el elemento Fault en el boque body. La diferencia radica en que el mensaje de respuesta nos retornará también los parámetros.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.w3.xmlsoap.xmlsoap. Una invocación a un procedimiento con parámetros por referencia es exactamente igual que si fueran por valor. SOAP también proporciona un mecanismo para comunicar que se ha producido un error en el servidor.xmlsoap.

y los cambios se propagan a los demás. etc. Los cambios hechos en un Registry.Desarrollo de Web Services con Software Libre - - VersionMismatch: Se ha especificado un namespace erróneo para el elemento envelope. Estructura UDDI 2. por ejemplo. mientras que los Registrar proporcionan servicios de registro al cliente. Server El mensaje es en sí correcto. Los Registry tienen una copia del directorio UDDI al completo. 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. Registrar Registrar Registrar Registrar Registrar Registrar Registry Registry Figura 2. Presenta una estructura (ver figura 2) formada por un conjunto de elementos tipo Registry y otro de elementos tipo Registrar. Un cliente accede a un Registry mediante uno de los Registrar del mismo. Client: El cuerpo del mensaje presenta alguna irregularidad.4. presentando una lista de Web Services y referencias a otros ficheros DISCO. nos permita modificar los registros del directorio. 2. 10 .2. pero el procesamiento del mismo ha derivado en algún error. son actualizados automáticamente en el resto. y mediante una interfaz HTML.2. MustUnderstand: Hay problemas con algún elemento que tiene puesto el atributo mustUnderstand a uno. como pueden ser accesos a bases de datos.3 UDDI: Universal Description. DISCO: DISCOvery La alternativa a UDDI se denomina DISCO (de Discovery). como por ejemplo estar incompleto o mal estructurado. Un Registrar puede estar proporcionado por una compañía. que tenga su Registry. división por cero. 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.

UDDI WSDL WSDL Subscribe Invoca Registrado (el que esta subscrito) Publica Programador (el que publica) SOAP sobre HTTP Figura 3.La persona subscrita al directorio invoca el servicio con SOAP 6. utilizar herramientas que hacen un uso más transparente de este paquete. 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). Además.Desarrollo de Web Services con Software Libre 3.La persona subscrita al directorio recibe la respuesta mediante SOAP. Debido a este requisito Java se presenta como uno de los más firmes candidatos para el desarrollo de Servicios Web.El programador describe el Web Service en un fichero WSDL 3. el modo de utilizar un Web Services y cómo desarrollarlo. 1. Estas APIs se incorporan en un paquete de desarrollo de Java para la programación de Web Services.La persona subscrita al directorio busca el Web Service 5. siendo Java el lenguaje de programación que se utiliza..El programador desarrolla el Web Service 2.. 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. la elección de Java se hace más firme y adecuada debido a las APIs que incorpora para XML. ya que asegura que su código sea portable.. 11 . DESARROLLO DE WEB SERVICES CON SOFTWARE LIBRE Existen varias posibilidades de desarrollo de Web Services usando software libre. o bien. ARQUITECTURA WEB SERVICES En una arquitectura de Web Services hay dos partes claramente diferenciables. Estas herramientas proporcionan el entorno de desarrollo de Web Services y la gestión de invocaciones de los servicios Web. Existe la posibilidad de utilizarlo directamente programando en Java.. El uso de los Web Services a través de la Web hace necesario que se puedan utilizar en diferentes plataformas. haciendo el uso de XML embebido en código Java mucho más fácil.El programador publica el Web Service en un directorio como UDDI 4.. 4..

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. El desarrollo de Web Services mediante WSDP y TomCat proporciona una serie de herramientas que facilitan la implantanción de una aplicación Web: . 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. ya que soportan estándares industriales. DeployTool crea un Web Application aRchive (WAR) para implantar la aplicación Web y gestionar aspectos de seguridad.Desarrollo de Web Services con Software Libre 3.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. .DeployTool: Esta herramienta se utiliza para crear una nueva aplicación (fichero EAR) (ver figura 4).1.JAXM Admin Tool: Herramienta (ver figura 6) que configura el JAXM provider. Dicha jerarquía tiene un diseño estandar para la estructuración de ficheros y directorios. . JAXM Provider es un proveedor de mensajes necesario para soportar mensajes asíncronos. . 12 . La ventaja de estas APIs es que todas ellas aseguran interoperabilidad y flexibilidad. DeployTool se comunica con el servidor J2EE para implantar la aplicación Web o eliminar componentes. posteriormente el fichero se asocia al fichero WAR apropiado y se le asigna su contexto Web (ver figura 5).AdminTool: Sirve ara manipular TomCat mientras esta ejecutandose.DeployTool: Al igual que Ant se utiliza para la implantación de una aplicación Web desarrollada con Web Services. Estos ejemplos pueden ser ejecutados tanto en Tomcat como J2EE. El desarrollo de Web Services mediante WSDP y J2EE proporciona una serie de herramientas que facilitan la implantanción de una aplicación Web: .

2. AXIS AXIS es un conjunto de herramientas de Apache para el desarrollo de Web Services. WDSL y XML.Desarrollo de Web Services con Software Libre Figura 4. SOAP. tanto la parte cliente como la servidora. pasando por una applet de Java que interactua con Web Services de otros proveedores. 13 . JAXM Admin Tool 3. Asignación del Contexto Web Figura 6. Con AXIS se puede implementar desde un Web Service básico hasta un gran servicio comercial. Creación de un fichero EAR Figura 5. AXIS está basada en los estándares HTTP.

El acceso a BD con AXIS se hace mediante una conexión JDBC a la BD del SGBD con el que se desee trabajar. También se utiliza para la compilación del código. parámetros. que permiten un mayor control y flexibilidad. como por ejemplo: Case Suite. Sin embargo. AXIS es la herramienta de software libre para el desarrollo de Web Services más extendida. WSDL2java también facilita la labor de desarrollo de un Web Service servidor. Además JBoss permite trabajar no solo con TomCat.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. reduce el esfuerzo de realizar llamadas remotas al hacer el proceso interno más transparente al usuario. etc) cuando estamos desarrollando un Web Service cliente. ya que dicha información se detalla en un fichero WSDL. los ficheros WSDD permiten habilitar o deshabilitar métodos individuales de un Web Service. 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. JBoss. 14 . tipo de los parámetros. Otra manera es haciendo uso de Web Services Deployment Descriptors (WSDD). nombre. Por lo tanto. Además. Web Services basados en J2EE es necesario instalar 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. 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. AXIS también incorpora una serie de herramientas para la administración del sistema. también con Jetty como contenedor Web. Esta herramienta facilita la labor de obtener la información necesaria para invocar un Web Service (URL. AXIS facilita la implantación y gestión de Web Services. Por ejemplo. estas herramientas no son de software libre. Si se desean desarrollar con AXIS. 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.net. Tcpmon es una herramienta para monitorizar y visualizar el tráfico de entrada y de salida de un Web Service en ejecución. 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. Existen otras herramientas para el desarrollo de Web Services sobre linux que se están utilizando tanto como AXIS.

2. depuración y gestión de aplicaciones basadas en Web Services. sino que también permite codificar plugins para la propia herramienta. 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. WASP es un entorno de desarrollo que soporta Eclipse para el desarrollo. Eclipse es mucho más rápido que NetBeans en cuanto al refresco de las pantallas del entorno. ya que te permite elegir entre diferentes entornos de desarrollo. Si bien es cierto. 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. A partir de ese momento. Con WASP. tan sólo se ha de implantar en el servidor embebido. en cuanto a software libre se refiere. Esta es una de las ventajas de WASP. esta flexibilidad es una gran ventaja. dependiendo de tus intereses y del que al usuario resulte más ergonómico y ágil. se pueden desarrollar clientes que hagan llamadas remotas a sus servicios utilizando el envío de mensajes cliente servidor vía SOAP. WASP sobre ECLIPSE IBM Eclipse es un entorno de desarrollo Java que no sólo permite desarrollar aplicaciones Java. De forma que es posible añadir funcionalidad y modificarla según las necesidades de desarrollo del programador. tu puedes desarrollar un Web Service como si implementases una clase java cualquiera. pero también puede utilizarse sobre Sun ONE Studio (y NetBeans que es su software libre equivalente) y Borland JBuilder.Desarrollo de Web Services con Software Libre 3. Una vez finalizada la aplicación es posible registrar los servicios en el registro UDDI. de ahí que este informe se centre en Eclipse. 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. se encuentra WASP. 15 .

Sign up to vote on this title
UsefulNot useful