ANLISIS Y APLICACIN DE SERVICIOS WEB UTILIZANDO EL PROTOCOLO SOAP

Un caso de estudio en el Dominio Judicial.

Trabajo Final para la Asignatura Desarrollo de Aplicaciones Web. UNPA-UACO

Autores: AdeSCossioMaria AdeS Pereyra Gabriel Directores: Dra. Adriana Martin Ing. Natalia Seron.

Contenido
1. INTRODUCCION........................................................................................................................................ 3 2.WEB SERVICES............................................................................................................................................ 4 2.1 Elementos de los WS ....................................................................................................................... 4 2.1.1 Agentes y Servicios................................................................................................................ 5 2.1.2 Cliente y proveedor ............................................................................................................... 5 2.1.3 Descripcin del servicio ......................................................................................................... 5 2.1.4 Semnticas ............................................................................................................................. 5 3. ESTANDARES BASICOS ............................................................................................................................ 5 3.1 Descripcin de SOAP ....................................................................................................................... 6 3.2 Descripcin de WSDL....................................................................................................................... 8 3.3 Descripcin de UDDI........................................................................................................................ 9 4. TECNOLOGIAS PARA WEB SERVICES ...................................................................................................10 4.1 Microsoft .NET ..............................................................................................................................10 4.2 J2EE................................................................................................................................................11 4.3 Axis2 ..............................................................................................................................................12 5 . DESCRPCIN DEL PROBLEMA Y DESARROLLO DE LA SOLUCION ........................................................13 5.1 El Sistema SGAC ...........................................................................................................................13 5.2 Web Service Desarchivo de expedientes .....................................................................................14 5.3 Desarrollo de la solucin ..............................................................................................................15 5.3.1 Desarrollo e implementacin de un WS con Netbeans ...................................................16 5.3.2 Desarrollo e implementacin de un cliente WS, con Netbeans ....................................17 6. RESULTADOS OBTENIDOS ......................................................................................................................19 7. CONCLUSIONES .......................................................................................................................................21 8. REFERENCIAS...........................................................................................................................................22

1. Introduccin

Con el surgimiento de Internet y su masificacin a niveles inesperados, surgi la necesidad de lograr la integracin entre sistemas heterogneos, tanto de software como de hardware. En este contexto nacen los Servicios Web, componentes de software independientes de la plataforma que pueden ser fcilmente publicados, localizados e invocados mediante protocolos web estndar, como XML, SOAP, UDDI o WSDL. El Sistema de Gestin del Archivo Central (SGAC) [1] es una aplicacin de software desarrollada para ser utilizada en la unidad encargada de administrar el Archivo Central del Poder Judicial. El Archivo Central guarda expedientes que envan los juzgados para ser archivados. Los juzgados tambin pueden solicitar el desarchivo de los expedientes. El Archivo Central, adems brinda servicios al pblico en general que necesite consultar algn expediente. El propsito de SGAC es facilitar el funcionamiento diario del Archivo Central, ya sea para el registro informtico de los expedientes recibidos, as como el tratamiento de la informacin registrada para la evacuacin de consultas formuladas por los propios usuarios o por organismos que requieran esta informacin. El presente trabajo est organizado de la siguiente manera: La seccin 2 provee una introduccin a los Servicios Web, su definicin y caractersticas. Luego, en la seccin 3, se presentan los estndares ms importantes que se utilizan en el desarrollo resaltando la funcin que cumple cada uno de ellos para lograr la interoperabilidad de los servicios. En la seccin 4 se describen algunas tecnologas utilizadas en su implementacin. Finalmente, en la seccin 5 damos a conocer de qu manera implementamos un Servicio Web utilizando el sistema SGAC, tecnologas utilizadas y descripcin de los resultados obtenidos en la seccin 6.

2. Web Services

Los Web Services (en adelante WS) responden a una tecnologa reciente muy prometedora, de la cual an se est desarrollando soporte a caractersticas que no posee, pero que seguramente en poco tiempo podrn incluir. Los WS estn comenzando a formar parte esencial de la Web pero su alcance no siempre est bien definido. Para su mejor comprensin se presenta la siguiente definicin de la W3C [2]: Los Web Services son sistemas que soportan interaccin maquina a mquina interoperable sobre una red. Proporcionan una comunicacin universal entre aplicaciones diferentes dentro de empresas o entre diferentes compaas permitiendo un rpido desarrollo de aplicaciones distribuidas en sistemas heterogneos. El funcionamiento bsico de un WS consiste en un proveedor del servicio web y un consumidor del servicio, como muestra la figura 1. El servicio web puede proporcionarse a cualquier cliente web, es decir que la implementacin del servicio es independiente de la plataforma de desarrollo, tanto para el proveedor del servicio como para el cliente. En la implementacin del WS se puede utilizar el lenguaje java para el servicio y el cliente, aunque no es una restriccin que los clientes web implementados en php, asp, o perl puedan utilizar el WS.

Figura 1. Funcionamiento de un Web Services.

2. 1 Elementos de los WS
Como se menciona en el apartado anterior, los WS son independientes de la plataforma, por lo tanto no estn ligados a ninguna tecnologa en especial. Sin embargo, deben respetar una serie de reglas e interfaces para poder ser accedidos por cualquier sistema (siempre que est conectado a la red y tenga el permiso para hacerlo). En [3] se detallan una serie de elementos que se deben considerar en la utilizacin de WS. Se detallan los agentes y servicios, el cliente y el proveedor, la descripcin del servicio y la semntica.

2.1.1 Agentes y Servicios Un Servicio Web es un conjunto abstracto de funcionalidades ofrecidas. El agente es una porcin de software que implementa la funcionalidad. Este agente debe ser capaz de enviar y recibir mensajes, ya que es el encargado de recibir las peticiones y enviar las respuestas. 2.1.2 Cliente y proveedor Un servicio web puede ser ofrecido por una persona o una organizacin, el proveedor del servicio y es quien desarrolla un agente capaz de soportar un determinado servicio. Quien desea hacer uso del servicio, el cliente, puede ser tambin una persona u organizacin que tiene implementado un agente que se comunica con el agente del proveedor. Para que la comunicacin se pueda realizar exitosamente, los participantes deben ponerse de acuerdo en la semntica y en los mecanismos de intercambio de mensajes. 2.1.3 Descripcin del servicio La descripcin de un servicio se documenta mediante el protocolo WSD (Web Service Description) en un lenguaje llamado WSDL (Web Service Description Language). En esta descripcin se incluyen elementos como el formato de los mensajes, los tipos de datos, los protocolos de transporte disponibles y los formatos de serializacin utilizados para la comunicacin entre agentes. 2.1.4 Semnticas La semntica de un WS es el comportamiento esperado del mismo, cmo reacciona cuando recibe una peticin. Tambin puede verse como un contrato entre la entidad que realiza la consulta y la entidad a la que va dirigida la consulta.

3. Estndares bsicos

La iniciativa de los servicios web ha estado guiada por estndares desde su nacimiento*4] Como indicamos en la definicin de Servicios Web, su principal caracterstica es su interoperabilidad independiente de la plataforma. Esto se logra gracias a la utilizacin de estndares y protocolos definidos por la W3C1. Estos estndares tratan de describir y definir las caractersticas propias de los servicios: cmo se describen o se localizan, cmo se representa toda la informacin e inclusive la forma mediante la cual se deben comunicar. A continuacin mencionaremos brevemente los ms importantes y luego se describirn con ms detalle. SOAP: El intercambio de mensajes entre el cliente y el servicio web se realiza utilizando un protocolo denominado SOAP2 (Simple Object Access Protocol) que define la estructura del mensaje

W3C, The World Wide Web Consortium, W3C Services Package PAS Explanatory Report, 2012, link: <http://www.w3.org/2010/08/wspas.html> 2 W3C, The World Wide Web Consortium, SOAP Version 1.2, link: <http://www.w3.org/TR/2007/REC-soap12-part0-20070427/>

utilizando el lenguaje XML. Bsicamente SOAP permite que aplicaciones distintas desarrolladas en diferentes lenguajes y plataformas puedan comunicarse. WSDL: Los WS utilizan otro documento basado en XML denominado WSDL3 (Web Services Description Language) para que los clientes puedan comprender la utilizacin del servicio, es decir, el documento describe la interfaz del servicio. UDDI: Para localizar los servicios, los documentos WSDL son publicados utilizando otro servicio denominado UDDI ( Universal Description, Discovery and Integration) , una iniciativa de OASIS4, en el cual los WS se registran almacenando su nombre y su respectivo documento WSDL. La siguiente figura muestra cmo interaccionan los distintos protocolos para proporcionar un servicio web.

Figura 2. Estndares La transmisin de los mensajes utilizando el protocolo SOAP se realiza utilizando otro estndar de la Web: el protocolo HTTP. Por el cual los WS obtienen ciertas ventajas respecto a otros desarrollos similares, que persiguen la misma filosofa, como por ejemplo CORBA.

3.1 Descripcin de SOAP

SOAP es un protocolo de la W3C para intercambio de datos sobre HTTP que proporciona un mtodo estndar para enviar mensajes XML entre aplicaciones. Los WS utilizan SOAP para enviar mensajes entre el servicio y sus clientes. Debido a que el protocolo HTTP es soportado por todos los navegadores los mensajes SOAP pueden ser enviados entre aplicaciones ms all de su plataforma y lenguaje de programacin. SOAP consta de tres partes: un sobre o envoltura (envelope) que define un marco para describir lo que est en un mensaje y cmo procesarlo, un conjunto de reglas de codificacin para expresar
3

W3C, The World Wide Web Consortium, Web Services Description Language, link: <http://www.w3.org/TR/wsdl>

Organization for the Advancement of Structured Information Standards: es un consorcio internacional sin fines de lucro que orienta el desarrollo, la convergencia y la adopcin de los estndares de comercio electrnico y servicios web

instancias de tipos de datos definidos por la aplicacin y una convencin para representar llamadas a procedimientos remotos y respuestas [5]. El consorcio W3C proporciona un documento conteniendo una serie de recomendaciones que permiten optimizar el intercambio de mensajes a travs del protocolo SOAP. La versin actual de este documento es la versin 1.2 y est disponible en [6]. Mensaje SOAP La especificacin SOAP establece un formato de mensajes estndar que consiste de un documento XML capaz de organizar RPC y datos basados en documentos. El documento o mensaje SOAP se transmite entre aplicaciones y puede atravesar a varios intermediarios cuando viaja del remitente inicial al destinatario definitivo. El documento SOAP est compuesto de tres secciones: Envelope (sobre), Header (encabezado) y Body (cuerpo). Esta estructura se puede observar en la figura siguiente:

Figura 3. Estructura del documento SOAP Envelope SOAP

Es el recipiente para los otros elementos del mensaje, es el elemento raz que representa el documento del mensaje. Un proceso del lado del servidor llamado manejador SOAP puede usar la disponibilidad de Envelope SOAP con la declaracin del espacio de nombres, para determinar si el documento XML entrante es un mensaje SOAP o no. El manejador puede ser parte de la aplicacin del servidor o puede ser un producto externo. Header SOAP

El elemento Header SOAP tiene que ser el primer hijo del elemento Envelope. A su vez, cada elemento Header puede tener elementos hijo. La informacin que se suele incluir en el elemento Header puede ser:

- Implementacin de extensiones SOAP que son aplicaciones predefinidas o especficas. - Identificacin de destinatarios intermediarios de SOAP. - Provisin de informacin de la meta suplementaria sobre el mensaje de SOAP. Mientras un mensaje SOAP progresa a lo largo de una ruta del mensaje, los intermediarios pueden agregar, borrar o procesar informacin en los Header SOAP. Body SOAP

Es la parte obligatoria de un mensaje SOAP. Esta seccin acta como un recipiente de los datos que sern entregados por el mensaje SOAP. Estos datos son conocidos como la carga til o datos de carga. Modelo de procesamiento SOAP SOAP provee un modelo de procesamiento distribuido en el que un mensaje es originado por un emisor inicial SOAP, y enviado a un receptor final SOAP a travs de cero o ms intermediarios SOAP. Este modelo puede soportar muchos Patrones de Intercambio de Mensajes, incluyendo mensajes unidireccionales, interacciones del tipo peticin/respuesta y conversaciones punto a punto. Este modelo especifica cmo un receptor SOAP procesa el mensaje que le ha llegado. En el modelo no est contemplado el mantener ningn estado en la comunicacin, o el llevar u control de la correlacin de los mensajes. Sera responsabilidad de las caractersticas adicionales el definir de alguna forma este tipo de procesamiento.

Figura 4. Procesamiento SOAP

3.2Descripcin de WSDL
WSDL es un formato XML para describir servicios de red como un conjunto de nodos operando sobre los mensajes que contienen informacin orientada a documentos u orientada a procedimientos. Las operaciones y mensajes se describen en forma abstracta y luego se pueden vincular a un protocolo

de red concreto y formato de mensaje para definir un nodo. Los nodos concretos se combinan con nodos abstractos (servicios). WSDL es extensible para permitir la descripcin de los nodos y sus mensajes independientemente de qu formato de mensaje o protocolos de red se usan para la comunicacin. [7]

En un documento WSDL, los servicios se definen usando los siguientes elementos: Types: Proporcionan definiciones de tipos de datos que se usan para describir el intercambio de mensajes. Message: representa una definicin abstracta de los datos que estn siendo transmitidos. El mensaje consiste de partes lgicas, cada una de las cuales se asocia con una definicin dentro de algn tipo de sistema. portType: es un conjunto de operaciones abstractas. Cada operacin refiere a un mensaje de entrada y mensajes de salida. Binding: especifica un protocolo concreto y especificaciones de formatos de datos para las operaciones y mensajes definidos por un portType particular. Port: nodo definido como la combinacin de una vinculacin y una direccin de red. Service: se usa para agregar un conjunto de puertos relacionados.

En resumen, WSDL define un contrato que compromete al proveedor soportar la separacin de la interfaz, no especifica cmo se implementa el Servicio Web. WSDL proporciona el formato comn para codificar y descifrar mensajes a y desde cualquier aplicacin back-end, sin importar qu aplicaciones hay detrs de los servicios web.

3.3Descripcin de UDDI
El protocolo UDDI, Universal Description, Discovery and Integration, es un estndar aprobado por la organizacin OASIS. Define un mtodo estndar para publicacin y descubrimiento de componentes de software basadas en red de una arquitectura orientada a servicios (SOA). [8] Bsicamente UDDI est concebida como: Una especificacin tcnica para construir un directorio distribuido de negocios y servicios Web. Datos que son almacenados dentro de un formato de XML especfico y detalles de APIs para buscar datos existentes y publicacin de nuevos datos. Un registro de negocios que es una implementacin totalmente operacional de la especificacin de UDDI. El registro de UDDI permite ahora a cualquiera buscar los datos de UDDI existentes. Tambin permite a cualquier compaa registrarse y registrar sus servicios.

El directorio UDDI tiene tres partes [9]: Pginas blancas: Informacin bsica, como direccin, contacto y otros identificadores conocidos sobre un proveedor de servicios. Pginas amarillas: categorizacin industrial basada en taxonomas. Pginas verdes: informacin tcnica sobre los servicios que aportan las propias empresas. Generalmente esto incluye un apuntador a la especificacin externa y una direccin en la que invocar el servicio.

El registro UDDI

El propsito funcional de un registro UDDI es la representacin de datos y metadatos de Servicios Web. Un registro, ya sea para uso en una red pblica o dentro de la estructura interna de una organizacin, ofrece un mecanismo basado en estndares para clasificar, catalogar y gestionar servicios web, as pueden ser descubiertos y utilizados por otras aplicaciones. [8].

4. Tecnologas para Web Services

Gracias a la creacin de los estndares descriptos anteriormente los WS pueden ser desarrollados de manera que puedan ser accedidos por clientes de cualquier plataforma, slo se tendrn que respetar las reglas de comunicacin. Para el diseo y creacin de los WS, cada plataforma dispone de uno o varios entornos tecnolgicos que, utilizando sus propios lenguajes y aplicaciones de desarrollo, permiten crear WS de acuerdo a las especificaciones con cierto grado de automatizacin. A continuacin se presentan brevemente algunas tecnologas que permiten el desarrollo de servicios web.

4.1 Microsoft .NET

Microsoft .NET tiene su propio soporte para WS. Si se crea un servicio Web con cdigo administrado basado en ASP.NET y .NET Framework, no es necesario que se escriba cdigo de infraestructura para administrar detalles como los protocolos de comunicaciones o transportes de mensajes. En el modelo de aplicacin ASP.NET, las pginas web usan a extensin .aspx para diferenciar los servicios Web de las pginas ASP.NET habituales, los primeros utilizan la extensin .asmx [10] La comunicacin se realiza comnmente mediante el protocolo HTTP, ya que es el ms utilizado para comunicacin con servidores Web. Los componentes del .NET Framework proveen los ladrillos necesarios para construir aplicaciones Web, WS y cualquier aplicacin dentro de Visual Studio .NET. Cuando se crea una aplicacin Windows en algn lenguaje compatible con la plataforma .NET, puede utilizar cualquiera de los servicios que la biblioteca de clases .NET proporciona, cuando se compila la aplicacin se crea un cdigo intermedio llamado MSIL5, este cdigo es independiente de la plataforma de hardware, una vez compilado el Common Language Runtime administra la ejecucin de la aplicacin. [11]

Microsoft IntermediateLanguage es el lenguaje de programacinlegible por humanos de ms bajo nivel en .NET Framework

4.2 J2EE
J2EE es la plataforma de Sun MicroSystems para Java en la que se integran un conjunto de potentes tecnologas para el desarrollo Web. La plataforma J2EE dispone de un conjunto de APIs importantes para el desarrollo de WS: JAXP JAXB JAX-WS JAXM JAXR

4.2.1 JAXP Esta API se encarga del procesamiento de documentos SOAP mediante SAX y DOM. SAX (Simple API for XML Parsing)

SAX lee el documento de principio a fin, y cuando encuentra una construccin sintctica, lo notifica a la aplicacin que lo ejecuta mediante la interfaz ContentHandler, por lo que se dice que el funcionamiento de esta API est dirigido por eventos. DOM (Document Object Model)

Representa el documento XML mediante una estructura de rbol, y permite su manipulacin con clases y operaciones que manipulan este rbol conceptual.

4.2.2 JAXB (Java Architecture for Java Binding) Permite generar clases Java a partir de esquemas XML. Como parte de este proceso, JAXB proporciona mtodos para transformar (unmarshal) una instancia de un documento XML en un rbol de objetos Java, y viceversa, transformar el rbol de objetos en un instancia de documento XML. JAXB ofrece un mtodo rpido para ligar un esquema XML a una representacin de cdigo Java, facilitando la incorporacin de datos y funciones procedentes de Java a las aplicaciones XML sin necesidad de tener grandes nociones de XML.

4.2.3 JAX-WS JAX-WS [12] simplifica el desarrollo de aplicaciones a travs del apoyo de una norma, la anotacin modelo basado en el desarrollo de aplicaciones de servicios web y clientes. JAX-WS sustituye a la llamada a procedimiento remoto modelo de programacin definida por JAX-RPC. Es una parte necesaria de la plataforma Java, Enterprise Edition. JAX-WS introduce soporte para anotar clases de Java con metadatos para indicar que la clase Java es un servicio web. Por ejemplo, se puede colocar una etiqueta @WebService en el cdigo fuente de Java para exponer el Bean como un servicio Web:

@WebService public class QuoteBean implements StockQuote { public float getQuote(String sym) { ... } }

La notacin @WebService comunica al servidor para que exponga todos los mtodos pblicos de ese Bean como un servicio Web. El uso de anotaciones hace mucho ms fcil exponer objetos de Java como servicios Web. Otras notaciones: @SOAPBinding : Indica que el servicio WEB utiliza el protocolo SOAP @WebMethod Expone el mtodo como parte de un SW @WebParam : Se puede utilizar en conjunto con la anotacin @WebMethod para definir los parmetros de un mensaje generado en el WSDL @WebResult: Opera en conjunto con @WebMethod se utiliza para especificar el nombre del mensaje de retorno en el WSDL @WebServiceRef: Se puede invocar un servicio web desde un bean de sesin.

4.2.4 JAXM (Java API for XML Messaging) Esta API proporciona un mecanismo estndar para mandar documentos XML a travs de Internet. Las caractersticas de JAXM : Mensajes asncronos (en una sola direccin). Enrutamiento de un mensaje a ms de un destinatario. Mensajes fiable, como la garanta de entrega

La clase que encapsula un mensaje de este tipo es la SOAP Message, que tiene siempre una parte SOAP (para cumplir con el estndar) y puede tener adems una o ms partes correspondientes a adjuntos.

4.2.5 JAXR (Java API for XML Registries) JAXR es una API Java que permite acceder a registros de negocios en Internet que, como UDDI, que vienen a ser como pginas amarillas.

4.3 Axis2
El proyecto de Apache Software Foundation Axis2 [12] es una implementacin basada en Java para el lado cliente y servidor de Web Services. Diseado para llevar ventajas de lo aprendido de Apache Axis 1.0, Apache Axis2 proporciona un completo modelo de objetos y arquitectura modular que facilita aadir funcionalidad y soporte para nuevos Web Services en relacin a especificaciones y recomendaciones.

Axis2 permite realizar fcilmente las siguientes tareas:

Enviar mensajes SOAP. Recibir y procesar mensajes SOAP. Crear un Web Service a partir de una simple clase Java. Crear implementaciones de clases tanto para el servidor y el cliente usando WSDL Recuperar fcilmente el WSDL para un servicio. Enviar y recibir mensajes SOAP con adjuntos. Crear o utilizar un Web Service basado en REST. Crear o utilizar servicios que lleven las ventajas de las especificaciones para WS-Security, WSReliableMessaging, WS-Addressing,WS-Coordination, y recomendaciones WS-Atomic Transaction. Usar Axis2 como una estructura modular para facilitar y aadir soporte para nuevas recomendaciones que emerjan.

5. Descripcin del Problema y Desarrollo de la Solucin

5.1 El Sistema SGAC

El Sistema de Gestin del Archivo Central SGAC [1] es una aplicacin de software desarrollada para ser utilizada en la unidad encargada de administrar el Archivo Central del Poder Judicial a los efectos de permitir su funcionamiento diario, ya sea para el registro informtico de los expedientes recibidos, as como el tratamiento de la informacin registrada para la evacuacin de consultas formuladas por los propios usuarios o por organismos que requieran esta informacin.

El sistema posee las siguientes funcionalidades: 1. Registro de ingreso de expedientes al sistema. Permite el ingreso de un expediente en el sistema, verificando las variables que identifican cada uno de ellos 2. Consultas y estadsticas sobre el contenido y actividad del archivo 3. Registro de egresos de expedientes 4. Emisin de etiquetas.

El propsito del presente trabajo es tomar cierta informacin del SGAC y brindarla a otros usuarios como un WS. Una de las operaciones que realiza el SGAC es el desarchivo de un expediente. Los Juzgados envan expedientes para que sean guardados por el Archivo Central pero posteriormente pueden solicitar el desarchivo de los mismos, es decir, la remisin del expediente al juzgado.

Actualmente el desarchivo de expedientes consiste en los siguientes pasos, ilustrado en la figura 5:

1. El juzgado enva a un funcionario a retirar el expediente. 2. El operador del SGAC solicita el formulario de desarchivo y consulta el estado del expediente. 3. Si el expediente esta archivado se realiza el desarchivo. Si no, el funcionario regresa sin xito.

Figura 5. Caso de uso Desarchivo de expedientes

5.2 Web Services Desarchivo de expedientes

La propuesta es ofrecer como servicio Web la porcin del Sistema que brinda informacin sobre estado y movimiento de los expedientes ingresados, como muestra la figura 6. Los clientes del servicio sern los juzgados que enviaron expedientes al Archivo, ya que dicha informacin les ser til en caso de desarchivo del expediente.

Figura 6. Servicio Web para el desarchivo de expedientes.

Para desplegar la actividad de desarchivo de expedientes como un WS se tuvo en cuenta la herramienta de desarrollo que se describe a continuacin.

IDE Netbeans 6.8 /7.0 El entorno de desarrollo integrado NetBeans versin 6.8/7.0[13] proporciona un entorno de programacin amigable, incluye la librera Metro y JAX-WS. La librera Metro implementa tanto el cliente como el servicio web utilizando la API de JAX-WS. Netbeans proporciona una interfaz intuitiva para la creacin de WS.
.

5.3 Desarrollo de la solucin

La solucin propuesta viene de la mano de NetBeans [13], ya que proporciona un medio automatizado frente a otras herramientas como Axis2 que requieren conocimientos previos, los pasos para el desarrollo se resumen en los siguientes:

Creacin del Web Services: 1. Se crea un nuevo proyecto WebApplication, o se sita en el directorio del proyecto principal que ofrecer una parte de su funcionalidad como un WS. 2. Se crea un nuevo archivo denominado Web Services. En la clase creada se implementa el mtodo bajo la etiqueta de @WebMethod con la funcionalidad especificada que ofrecer el WS. 3. Se realiza un test del WS, con el botn derecho del mouse en el archivo determinado como WS.

Creacin del Cliente: Se crea un nuevo proyecto Web Application, o se sita en el directorio del proyecto principal del cliente web que invocara al WS. 2. Se crea un nuevo archivo denominado Web client. Se indica la fuente del archivo WSDL y se invoca al WS de la siguiente manera:
1. PublicWSConsultadService service = new WSConsultadService(); WSConsultadport = service.getWSConsultadPort (); Stringresult=port.consultaexp(exp); // INVOCACION DEL WS

Con las siguientes posibilidades: Desde una nueva clase, desde un Servlet o desde la misma pgina jsp entre los smbolos <% %>. En la siguiente seccin se explican los pasos detallados con grficos.

5.3.1 Desarrollo e implementacin de un WS con Netbeans 1. Desde el proyecto web SGAC creamos el WS como un nuevo archivo Web Service como muestra la figura 7.

Figura 7. Creacin de un Web Service con Netbeans.

2. La herramienta solicita informacin necesaria para el WS, como el nombre, ubicacin y el paquete que contendr el archivo del WS, como muestra la figura 8.

Figura 8. Nuevo Web Service desde Netbeans.

3. Se edita el mtodo especificado con la etiqueta @WebMethod con la funcionalidad de que retorne en una variable de tipo String, si un expediente determinado (que pasamos como

parmetro) est en estado archivado o desarchivado, como se ilustra en la figura 9.

Figura 9. Mtodo principal

4. Se realiza un test para verificar el funcionamiento del WS, en el cual se comprueba la disponibilidad del documento WSDL que describe la interfaz del servicio, como muestra la figura 10.

Figura 10. Test del Servicio Web

5.3.2 Desarrollo e implementacin de un cliente WS, con Netbeans 1- Desde la aplicacin web que ser el cliente para nuestro WS, se crea un nuevo archivo para un cliente de WS, como muestra la figura 11.

Figura 12. Creacin de un cliente WS. 2- Se ingresa la ubicacin del documento WSDL que explica la interfaz del WS perteneciente al sistema SGAC, como ilustra la figura 13.

Figura 13. Creacin de un cliente WS desde Netbeans.

Netbeans crea las clases automticamente por medio de la librera Metro, la cual implementa el cliente utilizando la API Jax-WS. 3- Para invocar el servicio se debe declarar e instanciar las siguientes clases:
PublicWSConsultadService service =new WSConsultadService(); WSConsultadport;

Se invoca el servicio de la siguiente manera:

WSConsultadport = service.getWSConsultadPort(); Stringresult=port.consultaexp(exp); // INVOCACION DEL WS request.setAttribute("result", result);

6. Resultados obtenidos
Para poder realizar la prueba del WS se cre un nuevo proyecto en NetBeans, el cual simula ser una aplicacin web de un juzgado, en este caso fue realizado en lenguaje Java. La interfaz de usuario permite consultar sobre un nmero de expediente en particular, devolviendo como resultado si el expediente est disponible o desarchivado. Fue necesario crear esta aplicacin para poder realizar las pruebas con el WS aunque se podra realizar la aplicacin en otro lenguaje como PHP y comprobar su funcionamiento. La aplicacin devolvi con xito el mensaje, al consultar por un expediente, indicando que el expediente esta Desarchivado, lo que significa que el funcionario debe esperar hasta que el expediente este nuevamente archivado y disponible. Todo el proceso es totalmente transparente al usuario sin embargo, por debajo, existe un intercambio de mensajes en los protocolos Http, XML, SOAP, y los datos del expediente. Al obtener la respuesta, la aplicacin presento un retardo en la respuesta del WS, la cual puede deberse a los tiempos de envo del mensaje ms el tiempo que le toma a la aplicacin SGAC procesar la consulta y enviar la respuesta. La aplicacin cumpli correctamente con los resultados esperados y la respuesta fue correcta. La herramienta NetBeans proporcion una manera fcil e intuitiva de desarrollar la solucin, acortando los tiempos de desarrollo frente a otras similares.

Detalle de la Aplicacin Cliente

1. Se realiza la consulta del estado de un expediente, desde la aplicacin cliente, indicando el nmero de expediente, como muestra la figura 14.

Figura 14. Interfaz cliente para la Consulta al Web Service.

2.

Resultado obtenido como respuesta al consultar sobre un expediente, por medio de la invocacin del WS del sistema SGAC.

Figura 15. Interfaz cliente de la respuesta del Web Service.

7. Conclusiones
Si bien son una tecnologa reciente, los servicios web se han desarrollado en forma exponencial. En la Web se puede encontrar considerable y variada informacin sobre el tema. Un aspecto importante a tener en cuenta en su desarrollo, tiene que ver con la seguridad, debido a que los datos se intercambian en formato de texto sobre el protocolo HTTP, por lo que deben incluir conexiones seguras utilizando tcnicas de encriptacin de datos u otras similares para garantizar la confidencialidad e integridad de los datos. Axis2 presenta una buena opcin no solo en lo que respecta a seguridad, sino tambin a otras especificaciones importantes, presentadas en [3] y [14], como son transacciones atmicas y coordinacin de servicios para integrar varios servicios web en uno. Adems representa una manera intuitiva de desarrollar servicios web ya que utiliza la propia clase java para implementar e invocar el servicio, sin necesidad de tener conocimientos sobre XML, haciendo que todo sea transparente para el desarrollador. Las libreras Metro de Sun MicroSystem[15], tambin incorporan soluciones en cuanto a especificaciones para servicios web al igual que su par de Microsoft como el WCF (Windows Communication Foundation) [16], que por razones de su extenso material no fueron explicados. Respecto a la tecnologa Java para servicios web, resulta ser flexible al momento de trabajar con clases y objetos ya que la API Jaxb permite transformar una clase java a un esquema XML y viceversa lo que facilita el envo de datos complejos sin necesidad de tener amplios conocimientos sobre XML. Esto significa una ventaja importante ya que se puede trabajar utilizando todo el potencial del lenguaje Java para el desarrollo de servicios web. Las principales dificultades respecto al desarrollo del servicio web en SGAC fueron los pocos ejemplos concretos localizados en la web para la interiorizacin y aprendizaje desde la parte prctica. En un principio resulto una ardua labor de investigacin, ya que los conceptos de servicios web incluyen la comprensin de varias tecnologas, como los protocolos bsicos (SOAP, WSDL, UDDI), lenguaje XML, y las diversas herramientas disponibles para su implementacin. Axis2 presentaba una solucin posible, aunque requiere de ciertos conceptos previos a la hora de implementar los servicios web. Por lo cual el Entorno de Desarrollo Integrado NetBeans y sus libreras Metro y JAX-WS, resultaron una mejor opcin, ya que facilitan la implementacin tanto de clientes como de proveedores de servicios web por tener la creacin automatizada de las clases que realizan el intercambio de mensajes SOAP, a travs de XML, una manera sencilla y fcil para el programador que solo tiene que desarrollar adecuadamente el mtodo a invocar como un servicio. De la misma manera la creacin de un cliente a travs de un documento WSDL, es automtica, invocando el servicio desde una clase o un servlet. La creacin del servicio web en SGAC resulto ser sencilla luego de la ardua investigacin. El trabajo realizado que incluye la consulta de un expediente por medio de su nmero es una excelente iniciativa para integrar aplicaciones web, con ms importancia aun en el mbito judicial, ya que se puede extender ms su funcionalidad, permitiendo mantener la informacin actualizada entre juzgados acortando los plazos entre etapas de procesos e instancias judiciales. El trabajo a futuro, incluir ampliar las funcionalidades de SGAC ofrecidas como servicios web y realizar pruebas con otras plataformas como PHP para comprobar su correcta interaccin, de esta manera el SGAC se podr integrar con otras aplicaciones mejorando el funcionamiento de todo el sistema judicial.

Referencias
[1] SGAC, Sistema de Gestin del Archivo Central, Proyecto Final Carrera Analista de Sistemas, Desarrolladores: AdeS. Mara Cossio AdeS. Gabriel Pereyra, 2012, Universidad Nacional de la Patagonia Austral, Unidad Acadmica Caleta Olivia. [2] W3C, The World Wide Web Consortium, W3C Services Package PAS Explanatory Report, 2012, link: <http://www.w3.org/2010/08/ws-pas.html> [3] Servicios Web, Universidad de Castilla - La Mancha, Espaa, Autores: Ignacio Garca, Macario Polo Francisco Ruiz, Mario Piattini, Enero 2005, link: <http://www.infoab.uclm.es/descargas/thecnicalreports/DIAB-05-01-1/Servicios%20Web.pdf> [4] Ingeniera del Sofware Ian Sommerville Sptima edicin PEARSON EDUCACION S.A. Madrid, 2005. [5] W3C, The World Wide Web Consortium, Simple Object Access Protocol (SOAP) 1.1, May 2000, link:<http://www.w3.org/TR/2000/NOTE-SOAP-20000508/> [6]W3C, The World Wide Web Consortium SOAP Version 1.2, W3C Recommendation, 27 April 2001, link: <http://www.w3.org/TR/soap12-part1/> [7]W3C, The World Wide Web Consortium, Web Services Description Language (WSDL) 1.1, March 2001, link: <http://www.w3.org/TR/wsdl> [8] Online community for the Universal Description, Discovery, and Integration OASIS Standard, link:<http://uddi.xml.org/uddi-101> [9] WIKIPEDIA, La <http://es.wikipedia.org/wiki/UDDI> Enciclopedia Libre, UDDI, Octubre 2012 link:

[10] Servicios Web ASP.NET, Introduccin a la programacin de servicios web en cdigo administrado, link<:http://msdn.microsoft.com/es-es/library/yzbxwf53%28v=vs.100%29.aspx> [11] Sitio Web Desarrolloweb.com, Tema: <http://www.desarrolloweb.com/articulos/1705.php> el .NET Framework, link:

[12] The Apache Software Foundation, Axis2, <http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html> [13] NetBeans, Introduction <http://netbeans.org/kb/docs/websvc/intro-ws.html> [14] to Web

JAX-WS

GUIDE,

link:

Services,

link:

Curso Servicios web, Universidad La Salle Universidad Autonoma Metropolitana, Sergio Gonzalez Nava, Lourdes Sanchez Guerrero, Mexico, <http://capacinet.gob.mx/Cursos/Tecnologia%20amiga/desarrolladordesoftware/ServiciosWeb_SE.pdf> [15] Metro User Guide, SunMicroSystem, link <http://metro.java.net/guide/user-guide.pdf>

[16] Microsoft Communication Foundation, Microsoft, link; <http://msdn.microsoft.com/eses/library/ms735119%28VS.90%29.aspx>