Análisis y aplicación de servicios web utilizando el

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

Contenido1. 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 Descripción del servicio........................................................................................................5

2.1.4 Semánticas...........................................................................................................................5

3. ESTANDARES BASICOS..........................................................................................................................5

3.1 Descripción de SOAP......................................................................................................................6

3.2 Descripción de WSDL.....................................................................................................................8

3.3 Descripción de UDDI......................................................................................................................9

4. TECNOLOGIAS PARA WEB SERVICES..................................................................................................10

4.1 Microsoft .NET............................................................................................................................10

4.2 J2EE..............................................................................................................................................11

4.3 Axis2............................................................................................................................................12

5 . DESCRPCIÓN 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 solución............................................................................................................15

5.3.1 Desarrollo e implementación de un WS con Netbeans...................................................16

5.3.2 Desarrollo e implementación de un cliente WS, con Netbeans...................................17

6. RESULTADOS OBTENIDOS.....................................................................................................................19

7. CONCLUSIONES.....................................................................................................................................21

8. REFERENCIAS.........................................................................................................................................22

1. Introducción

Con el surgimiento de Internet y su masificación a niveles inesperados, surgió la necesidad de lograr la integración entre sistemas heterogéneos, tanto de software como de hardware. En este contexto nacen los Servicios Web, componentes de software independientes de la plataforma que pueden ser fácilmente publicados, localizados e invocados mediante protocolos web estándar, como XML, SOAP, UDDI o WSDL.

El Sistema de Gestión del Archivo Central (SGAC) [1] es una aplicación de software desarrollada para ser utilizada en la unidad encargada de administrar el Archivo Central del Poder Judicial. El Archivo Central guarda expedientes que envían los juzgados para ser archivados. Los juzgados también pueden solicitar el desarchivo de los expedientes. El Archivo Central, además brinda servicios al público en general que necesite consultar algún expediente.

El propósito de SGAC es facilitar el funcionamiento diario del Archivo Central, ya sea para el registro informático de los expedientes recibidos, así como el tratamiento de la información registrada para la evacuación de consultas formuladas por los propios usuarios o por organismos que requieran esta información.

El presente trabajo está organizado de la siguiente manera: La sección 2 provee una introducción a los Servicios Web, su definición y características. Luego, en la sección 3, se presentan los estándares más importantes que se utilizan en el desarrollo resaltando la función que cumple cada uno de ellos para lograr la interoperabilidad de los servicios. En la sección 4 se describen algunas tecnologías utilizadas en su implementación. Finalmente, en la sección 5 damos a conocer de qué manera implementamos un Servicio Web utilizando el sistema SGAC, tecnologías utilizadas y descripción de los resultados obtenidos en la sección 6.

2. Web Services

Los Web Services (en adelante WS) responden a una tecnología reciente muy prometedora, de la cual aún se está desarrollando soporte a características que no posee, pero que seguramente en poco tiempo podrán incluir. Los WS están comenzando a formar parte esencial de la Web pero su alcance no siempre está bien definido. Para su mejor comprensión se presenta la siguiente definición de la W3C [2]:

“Los Web Services son sistemas que soportan interacción maquina a máquina interoperable sobre una red. Proporcionan una comunicación universal entre aplicaciones diferentes dentro de empresas o entre diferentes compañías permitiendo un rápido desarrollo de aplicaciones distribuidas en sistemas heterogéneos.”

El funcionamiento básico 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 implementación del servicio es independiente de la plataforma de desarrollo, tanto para el proveedor del servicio como para el cliente. En la implementación del WS se puede utilizar el lenguaje java para el servicio y el cliente, aunque no es una restricción 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 WSComo se menciona en el apartado anterior, los WS son independientes de la plataforma, por lo

tanto no están ligados a ninguna tecnología 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

ProveedorServicio

ProveedorServicio

ConsumidorServicio

ConsumidorServicio

Solicitud de Servicio

Proporciona Servicio

Servicio Web en JavaOtros?

Cliente en PHP

Cliente en ASP

Cliente en Perl

la utilización de WS. Se detallan los agentes y servicios, el cliente y el proveedor, la descripción del servicio y la semántica.

2.1.1 Agentes y ServiciosUn Servicio Web es un conjunto abstracto de funcionalidades ofrecidas. El agente es una porción

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 proveedorUn servicio web puede ser ofrecido por una persona o una organización, 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 también una persona u organización que tiene implementado un agente que se comunica con el agente del proveedor. Para que la comunicación se pueda realizar exitosamente, los participantes deben ponerse de acuerdo en la semántica y en los mecanismos de intercambio de mensajes.

2.1.3 Descripción del servicioLa descripción de un servicio se documenta mediante el protocolo WSD (Web Service Description)

en un lenguaje llamado WSDL (Web Service Description Language). En esta descripción se incluyen elementos como el formato de los mensajes, los tipos de datos, los protocolos de transporte disponibles y los formatos de serialización utilizados para la comunicación entre agentes.

2.1.4 SemánticasLa semántica de un WS es el comportamiento esperado del mismo, cómo reacciona cuando recibe

una petición. También puede verse como un contrato entre la entidad que realiza la consulta y la entidad a la que va dirigida la consulta.

3. Estándares básicos

“La iniciativa de los servicios web ha estado guiada por estándares desde su nacimiento…”[4]

Como indicamos en la definición de Servicios Web, su principal característica es su interoperabilidad independiente de la plataforma. Esto se logra gracias a la utilización de estándares y protocolos definidos por la W3C1.

Estos estándares tratan de describir y definir las características propias de los servicios: cómo se describen o se localizan, cómo se representa toda la información e inclusive la forma mediante la cual se deben comunicar. A continuación mencionaremos brevemente los más importantes y luego se describirán con más detalle.

1W3C, The World Wide Web Consortium, W3C Services Package PAS Explanatory Report, 2012, link: <http://www.w3.org/2010/08/ws-pas.html>

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 utilizando el lenguaje XML. Básicamente 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 utilización 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 OASIS 4, en el cual los WS se registran almacenando su nombre y su respectivo documento WSDL.

La siguiente figura muestra cómo interaccionan los distintos protocolos para proporcionar un servicio web.

Figura 2. Estándares

La transmisión de los mensajes utilizando el protocolo SOAP se realiza utilizando otro estándar de la Web: el protocolo HTTP. Por el cual los WS obtienen ciertas ventajas respecto a otros desarrollos similares, que persiguen la misma filosofía, como por ejemplo CORBA.

2W3C, The World Wide Web Consortium, SOAP Version 1.2, link: <http://www.w3.org/TR/2007/REC-soap12-part0-20070427/>3W3C, The World Wide Web Consortium, Web Services Description Language, link: <http://www.w3.org/TR/wsdl>

4Organization for the Advancement of Structured Information Standards: es un consorcio internacional sin fines de lucro que orienta el desarrollo, la convergencia y la adopción de los estándares de comercio electrónico y servicios web

AplicaciónCliente

AplicaciónCliente

DescubrimientomedianteUDDI

Servicios publicadosServicios publicados

Registro UDDI

Servicio 1Servicio 1Servicio

Servicio Web

Servicio Web

Invocación y acceso mediante SOAPTransporte mediante HTTP / Otros…

MensajeSOAP

MensajeSOAP

PublicaciónmedianteUDDI

Descripción mediante WSDL

XMLSchemaWSDL

XMLSchemaWSDL

3.1 Descripción de SOAPSOAP es un protocolo de la W3C para intercambio de datos sobre HTTP que proporciona un

método estándar 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 más allá de su plataforma y lenguaje de programación.

SOAP consta de tres partes: un sobre o envoltura (envelope) que define un marco para describir lo que está en un mensaje y cómo procesarlo, un conjunto de reglas de codificación para expresar instancias de tipos de datos definidos por la aplicación y una convención 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 través del protocolo SOAP. La versión actual de este documento es la versión 1.2 y está disponible en [6].

Mensaje SOAP

La especificación SOAP establece un formato de mensajes estándar 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 raíz que representa el documento del mensaje.

Un proceso del lado del servidor llamado manejador SOAP puede usar la disponibilidad de Envelope SOAP con la declaración del espacio de nombres, para determinar si el documento XML entrante es un mensaje SOAP o no. El manejador puede ser parte de la aplicación 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 información que se suele incluir en el elemento Header puede ser:

- Implementación de extensiones SOAP que son aplicaciones predefinidas o específicas.- Identificación de destinatarios intermediarios de SOAP.- Provisión de información 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 información en los Header SOAP.

Body SOAP

Es la parte obligatoria de un mensaje SOAP. Esta sección actúa como un recipiente de los datos que serán 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 través de cero o más intermediarios SOAP. Este modelo puede soportar muchos Patrones de Intercambio de Mensajes, incluyendo mensajes unidireccionales, interacciones del tipo petición/respuesta y conversaciones punto a punto.

Este modelo especifica cómo un receptor SOAP procesa el mensaje que le ha llegado. En el modelo no está contemplado el mantener ningún estado en la comunicación, o el llevar u control de la correlación de los mensajes. Sería responsabilidad de las características adicionales el definir de alguna forma este tipo de procesamiento.

Figura 4. Procesamiento SOAP

3.2Descripción de WSDLWSDL es un formato XML para describir servicios de red como un conjunto de nodos operando

sobre los mensajes que contienen información 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 descripción de los nodos y sus mensajes independientemente de qué formato de mensaje o protocolos de red se usan para la comunicación. [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 definición abstracta de los datos que están siendo transmitidos. El mensaje consiste de partes lógicas, cada una de las cuales se asocia con una definición dentro de algún tipo de sistema.

portType: es un conjunto de operaciones abstractas. Cada operación 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 combinación de una vinculación y una dirección de red. Service: se usa para agregar un conjunto de puertos relacionados.

En resumen, WSDL define un contrato que compromete al proveedor soportar la separación de la interfaz, no especifica cómo se implementa el Servicio Web. WSDL proporciona el formato común para

codificar y descifrar mensajes a y desde cualquier aplicación back-end, sin importar qué aplicaciones hay detrás de los servicios web.

3.3Descripción de UDDIEl protocolo UDDI, Universal Description, Discovery and Integration, es un estándar aprobado por

la organización OASIS. Define un método estándar para publicación y descubrimiento de componentes de software basadas en red de una arquitectura orientada a servicios (SOA). [8]

Básicamente UDDI está concebida como:

Una especificación técnica para construir un directorio distribuido de negocios y servicios Web. Datos que son almacenados dentro de un formato de XML específico y detalles de APIs para buscar datos existentes y publicación de nuevos datos.

Un registro de negocios que es una implementación totalmente operacional de la especificación de UDDI. El registro de UDDI permite ahora a cualquiera buscar los datos de UDDI existentes. También permite a cualquier compañía registrarse y registrar sus servicios.

El directorio UDDI tiene tres partes [9]:

Páginas blancas: Información básica, como dirección, contacto y otros identificadores conocidos sobre un proveedor de servicios.

Páginas amarillas: categorización industrial basada en taxonomías. Páginas verdes: información técnica sobre los servicios que aportan las propias empresas.

Generalmente esto incluye un apuntador a la especificación externa y una dirección en la que invocar el servicio.

El registro UDDI

El propósito funcional de un registro UDDI es la representación de datos y metadatos de Servicios Web. Un registro, ya sea para uso en una red pública o dentro de la estructura interna de una organización, ofrece un mecanismo basado en estándares para clasificar, catalogar y gestionar servicios web, así pueden ser descubiertos y utilizados por otras aplicaciones. [8].

4. Tecnologías para Web Services

Gracias a la creación de los estándares descriptos anteriormente los WS pueden ser desarrollados de manera que puedan ser accedidos por clientes de cualquier plataforma, sólo se tendrán que respetar las reglas de comunicación.

Para el diseño y creación de los WS, cada plataforma dispone de uno o varios entornos tecnológicos que, utilizando sus propios lenguajes y aplicaciones de desarrollo, permiten crear WS de acuerdo a las especificaciones con cierto grado de automatización.

A continuación se presentan brevemente algunas tecnologías 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 código administrado basado en ASP.NET y .NET Framework, no es necesario que se escriba código de infraestructura para administrar detalles como los protocolos de comunicaciones o transportes de mensajes. En el modelo de aplicación ASP.NET, las páginas web usan a extensión .aspx para diferenciar los servicios Web de las páginas ASP.NET habituales, los primeros utilizan la extensión .asmx [10]

La comunicación se realiza comúnmente mediante el protocolo HTTP, ya que es el más utilizado para comunicación con servidores Web.

Los componentes del .NET Framework proveen los ladrillos necesarios para construir aplicaciones Web, WS y cualquier aplicación dentro de Visual Studio .NET. Cuando se crea una aplicación Windows en algún lenguaje compatible con la plataforma .NET, puede utilizar cualquiera de los servicios que la biblioteca de clases .NET proporciona, cuando se compila la aplicación se crea un código intermedio llamado MSIL5, este código es independiente de la plataforma de hardware, una vez compilado el Common Language Runtime administra la ejecución de la aplicación. [11]

4.2 J2EE

J2EE es la plataforma de Sun MicroSystems para Java en la que se integran un conjunto de potentes tecnologías 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 JAXPEsta API se encarga del procesamiento de documentos SOAP mediante SAX y DOM.

SAX (Simple API for XML Parsing)

5Microsoft IntermediateLanguage es el lenguaje de programaciónlegible por humanos de más bajo nivel en .NET Framework

SAX lee el documento de principio a fin, y cuando encuentra una construcción sintáctica, lo notifica a la aplicación 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 manipulación 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 métodos 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 método rápido para ligar un esquema XML a una representación de código Java, facilitando la incorporación de datos y funciones procedentes de Java a las aplicaciones XML sin necesidad de tener grandes nociones de XML.

4.2.3 JAX-WSJAX-WS [12] simplifica el desarrollo de aplicaciones a través del apoyo de una norma, la anotación

modelo basado en el desarrollo de aplicaciones de servicios web y clientes. JAX-WS sustituye a la llamada a procedimiento remoto modelo de programación 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 código fuente de Java para exponer el Bean como un servicio Web:

@WebService

public class QuoteBean implements StockQuote {

public float getQuote(String sym) { ... } }

La notación @WebService comunica al servidor para que exponga todos los métodos públicos de ese Bean como un servicio Web. El uso de anotaciones hace mucho más fácil exponer objetos de Java como servicios Web.

Otras notaciones:

@SOAPBinding : Indica que el servicio WEB utiliza el protocolo SOAP @WebMethod Expone el método como parte de un SW @WebParam : Se puede utilizar en conjunto con la anotación @WebMethod para definir los

parámetros 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 sesión.

4.2.4 JAXM (Java API for XML Messaging)Esta API proporciona un mecanismo estándar para mandar documentos XML a través de Internet.

Las características de JAXM :

Mensajes asíncronos (en una sola dirección). Enrutamiento de un mensaje a más de un destinatario. Mensajes fiable, como la garantía 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 estándar) y puede tener además una o más 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 páginas amarillas.

4.3 Axis2

El proyecto de Apache Software Foundation Axis2 [12] es una implementación basada en Java para el lado cliente y servidor de Web Services. Diseñado para llevar ventajas de lo aprendido de Apache Axis 1.0, Apache Axis2 proporciona un completo modelo de objetos y arquitectura modular que facilita añadir funcionalidad y soporte para nuevos Web Services en relación a especificaciones y recomendaciones.

Axis2 permite realizar fácilmente 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 fácilmente 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, WS-ReliableMessaging, WS-Addressing,WS-Coordination, y recomendaciones WS-Atomic Transaction.

Usar Axis2 como una estructura modular para facilitar y añadir soporte para nuevas recomendaciones que emerjan.

5. Descripción del Problema y Desarrollo de la Solución

5.1 El Sistema SGAC

El Sistema de Gestión del Archivo Central SGAC [1] es una aplicación 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 informático de los expedientes recibidos, así como el tratamiento de la información registrada para la evacuación de consultas formuladas por los propios usuarios o por organismos que requieran esta información.

- 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 estadísticas sobre el contenido y actividad del archivo3. Registro de egresos de expedientes4. Emisión de etiquetas.

El propósito del presente trabajo es tomar cierta información 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 envían expedientes para que sean guardados por el Archivo Central pero posteriormente pueden solicitar el desarchivo de los mismos, es decir, la remisión del expediente al juzgado.

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

1. El juzgado envía 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.

SGAC

Funcionario

Figura 5. Caso de uso Desarchivo de expedientes

5.2 Web Services Desarchivo de expedientes

La propuesta es ofrecer como servicio Web la porción del Sistema que brinda información sobre estado y movimiento de los expedientes ingresados, como muestra la figura 6. Los clientes del servicio serán los juzgados que enviaron expedientes al Archivo, ya que dicha información 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 continuación.

IDE Netbeans 6.8 /7.0

El entorno de desarrollo integrado NetBeans versión 6.8/7.0[13] proporciona un entorno de programación amigable, incluye la librería Metro y JAX-WS. La librería Metro implementa tanto el cliente como el servicio web utilizando la API de JAX-WS. Netbeans proporciona una interfaz intuitiva para la creación de WS.

.

5.3 Desarrollo de la solución

Servicio - SOAP -

La solución 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:

Creación del Web Services:

1. Se crea un nuevo proyecto “WebApplication”, o se sitúa 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 método bajo la etiqueta de “@WebMethod” con la funcionalidad especificada que ofrecerá el WS.

3. Se realiza un test del WS, con el botón derecho del mouse en el archivo determinado como WS.

Creación del Cliente:

1. Se crea un nuevo proyecto “Web Application”, o se sitúa 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:

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 página jsp entre los símbolos <% %>.

En la siguiente sección se explican los pasos detallados con gráficos.

5.3.1 Desarrollo e implementación 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. Creación de un Web Service con Netbeans.

2. La herramienta solicita información necesaria para el WS, como el nombre, ubicación 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 método especificado con la etiqueta @WebMethod con la funcionalidad de que retorne en una variable de tipo String, si un expediente determinado (que pasamos como parámetro) está en estado archivado o desarchivado, como se ilustra en la figura 9.

Figura 9. Método 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 implementación de un cliente WS, con Netbeans

1- Desde la aplicación 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. Creación de un cliente WS.

2- Se ingresa la ubicación del documento WSDL que explica la interfaz del WS perteneciente al sistema SGAC, como ilustra la figura 13.

Figura 13. Creación de un cliente WS desde Netbeans.

Netbeans crea las clases automáticamente por medio de la librería 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 WSrequest.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 aplicación web de un juzgado, en este caso fue realizado en lenguaje Java. La interfaz de usuario permite consultar sobre un número de expediente en particular, devolviendo como resultado si el expediente está “disponible” o “desarchivado”. Fue necesario crear esta aplicación para poder realizar las pruebas con el WS aunque se podría realizar la aplicación en otro lenguaje como PHP y comprobar su funcionamiento.

La aplicación 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 aplicación presento un retardo en la respuesta del WS, la cual puede deberse a los tiempos de envío del mensaje más el tiempo que le toma a la aplicación SGAC procesar la consulta y enviar la respuesta. La aplicación cumplió correctamente con los resultados esperados y la respuesta fue correcta. La herramienta NetBeans proporcionó una manera fácil e intuitiva de desarrollar la solución, acortando los tiempos de desarrollo frente a otras similares.

Detalle de la Aplicación Cliente

1. Se realiza la consulta del estado de un expediente, desde la aplicación cliente, indicando el número 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 invocación del WS del sistema SGAC.

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

7. Conclusiones

Si bien son una tecnología reciente, los servicios web se han desarrollado en forma exponencial. En la Web se puede encontrar considerable y variada información 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 técnicas de encriptación de datos u otras similares para garantizar la confidencialidad e integridad de los datos. Axis2 presenta una buena opción no solo en lo que respecta a seguridad, sino también a otras especificaciones importantes, presentadas en [3] y [14], como son transacciones atómicas y coordinación de servicios para integrar varios servicios web en uno. Además 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 librerías Metro de Sun MicroSystem[15], también 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 tecnología 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 envío 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 interiorización y aprendizaje desde la parte práctica. En un principio resulto una ardua labor de investigación, ya que los conceptos de servicios web incluyen la comprensión de varias tecnologías, como los protocolos básicos (SOAP, WSDL, UDDI), lenguaje XML, y las diversas herramientas disponibles para su implementación. Axis2 presentaba una solución 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 librerías Metro y JAX-WS, resultaron una mejor opción, ya que facilitan la implementación tanto de clientes como de proveedores de servicios web por tener la creación automatizada de las clases que realizan el intercambio de mensajes SOAP, a través de XML, una manera sencilla y fácil para el programador que solo tiene que desarrollar adecuadamente el método a invocar como un servicio. De la misma manera la creación de un cliente a través de un documento WSDL, es automática, invocando el servicio desde una clase o un servlet.

La creación del servicio web en SGAC resulto ser sencilla luego de la ardua investigación. El trabajo realizado que incluye la consulta de un expediente por medio de su número es una excelente iniciativa para integrar aplicaciones web, con más importancia aun en el ámbito judicial, ya que se puede extender más su funcionalidad, permitiendo mantener la información 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 interacción, de esta manera el SGAC se podrá integrar con otras aplicaciones mejorando el funcionamiento de todo el sistema judicial.

Referencias[1] SGAC, Sistema de Gestión del Archivo Central, Proyecto Final Carrera Analista de

Sistemas, Desarrolladores: AdeS. María Cossio – AdeS. Gabriel Pereyra, 2012, Universidad Nacional de la Patagonia Austral, Unidad Académica 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, España, Autores: Ignacio García, Macario Polo Francisco Ruiz, Mario Piattini, Enero 2005, link: <http://www.info-ab.uclm.es/descargas/thecnicalreports/DIAB-05-01-1/Servicios%20Web.pdf>

[4] Ingeniería del Sofware Ian Sommerville Séptima edición 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 Enciclopedia Libre, UDDI, Octubre 2012 link: <http://es.wikipedia.org/wiki/UDDI>

[10] Servicios Web ASP.NET, Introducción a la programación de servicios web en código administrado, link<:http://msdn.microsoft.com/es-es/library/yzbxwf53%28v=vs.100%29.aspx>

[11] Sitio Web Desarrolloweb.com, Tema: el .NET Framework, link: <http://www.desarrolloweb.com/articulos/1705.php>

[12] The Apache Software Foundation, Axis2, JAX-WS GUIDE, link: <http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html>

[13] NetBeans, Introduction to Web Services, link: <http://netbeans.org/kb/docs/websvc/intro-ws.html>

[14] 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/es-es/library/ms735119%28VS.90%29.aspx>