Web Services

5/11/2018 Web Services - slidepdf.com

http://slidepdf.com/reader/full/web-services-55a2336f6b6bc 1/15

Desarrollo de Web Services con Software Libre

1

Web Services

Jennifer Pérez Benedí Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de ValenciaC/Camino de Vera s/n

E-46071 Valencia- España [email protected]

1. ¿POR QUÉ WEB SERVICES?

Existen diversas razones por las que han surgido los Web Services y estánteniendo 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ónorientada 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 quemuchas empresas opten por esta tecnología.

Otra de las razones por las que han surgido los Web Services ha sido que lasaplicaciones y componentes desarrolladas utilizando un middleware, como DCOM,

CORBA y Java RMI, tienen varias limitaciones. Se hizo un intento de superarlasmediante un modelo llamado stateless programming, pero no tuvo éxito porque estastecnologí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 nuevatecnologí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 librespor encima del 1024. Por ese motivo, estos middleware establecen y gestionan

sus políticas de seguridad (java.policy en Java RMI) de forma eficaz, haciendoque la comunicación de un cliente con un servidor a través de Internet tenganumerosas barreras que sobrepasar. Para ello, los administradores de red se

encargan de implementar routers corporativos y firewalls1 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 nosean adecuados para los escenarios Web.

- El hecho de que sus protocolos sean patentados y orientados a la conexión creavarios inconvenientes a la hora de utilizarlos en un escenario Web:

§ Las aplicaciones deben estar gestionadas e instaladas en un centro dedatos.

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 nodeseadas , aplicando la filosofía de lo que no está permitido expresamente es negado.




2

§ Hacen muy difícil mantener una infraestructura balanceada en sucarga que permita lograr una alta escalabilidad, ya que cuando una

conexión entre un cliente y un servidor se rompe no se puedecambiar 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á bajoel 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 yalgunos 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 estainfraestructura 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 lacompartició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 medianteXML 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 seantransacciones 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 lareutilizació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 utilizarWeb 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 deescenarios 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 através de la Web. Una compañía puede ser tanto proveedora como consumidora de WebServices.

Un Web Service es una clase cuya interfaz se puede hacer pública en un servidorWeb 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 WebService usando los estándares de Internet.

Para acceder a un Web Service se pueden utilizar varios protocolos Webestá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). Esteprotocolo se basa en la utilización de HTTP para el transporte de mensajes y el lenguaje




3

XML para la escritura del cuerpo de estos mensajes. Todo esto permite a cualquieraplicació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, andIntegration) 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 Webse 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 yaestá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 otrastecnologí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 VisualBasic o Perl. De este modo, un cliente puede implementar o usar un Servicio Webindependientemente del lenguaje de programación en el que fue implementado.

- Soporte para cualquier infraestructura de componentes distribuidas: LosServicios 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 deobjetos distribuidos. Por este motivo, únicamente es necesario preocuparse deldesarrollo y utilización de Servicios Web.

2.2. PROTOCOLOS Y LENGUAJES IMPLICADOS EN EL DESARROLLO DEWEB SERVICES

Los bloques necesarios para construir una aplicación remota entre dos aplicacionesson 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.




4

- Message Format: Especifica el formato de codificación de los mensajes paraque 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 servidormediante un protocolo de transporte.

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 elservicio 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 XMLSchema.

<?xml version="1.0" encoding="utf-8"?>

<definitions>

<types><element name="Add">

<complexType>

<all><element name="x" type="int"/>

<element name="y" type="int"/>

DiscoveryUDDI, DISCO

DescriptionWSDL, XML Schema, Docs

Message FormatSOAP

EncodingXML

TransportHTTP, SMTP, etc




5

</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.


<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 oHTTPPOST. En el siguiente ejemplo solamente se muestra para SOAP:


<definitions>

<types>

. . .

</types>

<message>

. . .

</message>

<portType name="CalculatorSoapPortType">

<operation name="Add">

<input message="tns:AddSoapIn">




6

<output message="tns:AddSoapOut">

<fault message="tns:CalculateFaultMsg"

name="CalculateFault">

</operation>. . .

</portType>

. . .

</definitions>

• Binding : Asocia la definición portType con un protocolo concreto.


<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.


<definitions><types>

. . .

</types>

<message>

. . .

</message>

<portType>. . .

</portType>

<binding>

. . .

</binding>

<service name=" CalculatorService "><port name="CalculatorSoapPortType"

binding="tns:CalculatorSoapBinding">




7

<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 nombresque serán utilizados en el documento WSDL.


<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. Suscaracterísticas son las siguientes:

- No está restringido a un lenguaje ni a una plataforma. SOAP no especifica unaAPI, 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 lasactualizaciones de la aplicación.

- No está restringido a un protocolo de transporte. La especificación SOAPdescribe su transporte en HTTP pero puede ser transmitido en cualquierprotocolo 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 lugaraparece la cabecera , es opcional y sirve para poner información complementaria alcuerpo. 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. Comoeste campo es opcional, y muchas aplicaciones lo ignoran, para evitar que sea

descartada se debe indicar con la etiqueta ‘mustUnderstand=”1”’. A continuaciónaparece 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:




8

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 muestrala 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 paramuchos 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 Estructurados: 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;

}




9

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:


<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óna un procedimiento con parámetros por referencia es exactamente igual que si fueranpor 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 producidoun error en el servidor, mientras procesaba la petición. Para ello incorpora el elementoFault en el boque body. Existen una serie de errores predeterminados, cuyo significado

se detalla a continuación:




10

- 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 estarincompleto o mal estructurado.

- Server El mensaje es en sí correcto, pero el procesamiento del mismo ha derivado enalgú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 ficherosWSDL 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 directorioUDDI al completo, mientras que los Registrar proporcionan servicios de registro alcliente. Un Registrar puede estar proporcionado por una compañía, que tenga su

Registry, y mediante una interfaz HTML, por ejemplo, nos permita modificar losregistros del directorio. Los cambios hechos en un Registry, son actualizadosautomá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.

Figura 2. Estructura UDDI2.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 unadeterminada 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.

Registrar Registrar Registrar Registrar Registrar Registrar

Registry Registry




11

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 Service2.- El programador describe el Web Service en un fichero WSDL

3.- El programador publica el Web Service en un directorio como UDDI4.- La persona subscrita al directorio busca el Web Service5.- La persona subscrita al directorio invoca el servicio con SOAP

6.- La persona subscrita al directorio recibe la respuesta mediante SOAP.

Figura 3. Web Services en acción

La arquitectura necesaria para el desarrollo de Web Services es la de un servidorque contenga las herramientas adecuadas para el soporte al desarrollo de este tipo detecnologí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 delos más firmes candidatos para el desarrollo de Servicios Web, ya que asegura que sucó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 Javamucho 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 directamenteprogramando en Java, o bien, utilizar herramientas que hacen un uso más transparente

de este paquete.

UDDI

Registrado(el que estasubscrito)

Programador(el que

publica)

WSDLWSDL

PublicaSubscribe

Invoca

SOAP sobre HTTP




12

3.1. JAVA WEB SERVICES DEVELOPER PACK ( JAVA WSDP)

Java WSDP es un paquete que incluye ficheros JAR que implementan las APIspara 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 soportanestándares industriales.

Las APIs de Java para XML definen unos requisitos de compatibilidad queaseguran que todas las implementaciones proporcionan la funcionalidad estándar y

proporcionan mucha libertad para desarrollar implementaciones que toleren usosespecíficos.

El desarrollo de Web Services mediante WSDP y TomCat proporciona una seriede 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 ydirectorios.

- DeployTool: Al igual que Ant se utiliza para la implantación de una aplicación

Web desarrollada con Web Services. DeployTool crea un Web ApplicationaRchive (WAR) para implantar la aplicación Web y gestionar aspectos deseguridad.

- AdminTool: Sirve ara manipular TomCat mientras esta ejecutandose.

El desarrollo de Web Services mediante WSDP y J2EE proporciona una serie deherramientas 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 secomunica con el servidor J2EE para implantar la aplicación Web o eliminar

componentes.

- JAXM Admin Tool: Herramienta (ver figura 6) que configura el JAXMprovider. JAXM Provider es un proveedor de mensajes necesario para soportarmensajes asíncronos.




13

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ándaresHTTP, 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 interactuacon Web Services de otros proveedores.




14

WSDL2java es una herramienta de AXIS que interpreta ficheros WSDL y emitecó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 WebService (URL, nombre, parámetros, tipo de los parámetros, etc) cuando estamosdesarrollando 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 procesointerno 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 degenerar 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 yde 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 WebServices Deployment Descriptors (WSDD), que permiten un mayor control yflexibilidad. Por ejemplo, los ficheros WSDD permiten habilitar o deshabilitar métodosindividuales 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 aque clientes potenciales puedan utilizar los Web Services desarrollados de formasencilla.

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 paraservlets. El acceso a BD con AXIS se hace mediante una conexión JDBC a la BD delSGBD 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 laimplementación y publicación de Web Services basados en J2EE y permite que WebServices 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 seestán utilizando tanto como AXIS, como por ejemplo: Case Suite. Sin embargo, estasherramientas no son de software libre. Por lo tanto, AXIS es la herramienta de software

libre para el desarrollo de Web Services más extendida.




15

3.2. WASP sobre ECLIPSE

IBM Eclipse es un entorno de desarrollo Java que no sólo permite desarrollaraplicaciones Java, sino que también permite codificar plugins para la propia

herramienta. De forma que es posible añadir funcionalidad y modificarla según lasnecesidades de desarrollo del programador, esta flexibilidad es una gran ventaja. Esteentorno de desarrollo de IBM funciona sobre Windows y sobre Linux.

Entre los distintos plugins que hay desarrollados y se pueden incorporar enEclipse, 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, perotambié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 tepermite elegir entre diferentes entornos de desarrollo, dependiendo de tus intereses y delque 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 laspantallas del entorno, de ahí que este informe se centre en Eclipse.

Con WASP, tu puedes desarrollar un Web Service como si implementases unaclase 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 serviciosutilizando 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 ventajasque ofrece este pluing es que realiza la generación automática del fichero WDSL apartir 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ónsobre el sistema.

Web Services

Documents

Transcript of Web Services