Printer Friendly

Desarrollo de un servicio web de verificacion vehicular en centrales de riesgos crediticios.

DEVELOPMENT OF A WEB SERVICE OF VEHICLE INSPECTION IN CENTRAL CREDIT RISK

INTRODUCCION

En la actualidad los servicios web o Web Services proporcionan una importante interoperabilidad e integracion entre sistemas de informacion desarrollados bajo diferentes tecnologias. Por otro lado, las centrales de riesgos crediticios son las encargadas de la recepcion de informacion crediticia de diferentes fuentes externas (AFP, bancos, seguros, municipalidades, etc.), en el Peru estan reguladas por la Superintendencia de Banca, Seguros y AFP (SBS).

Estas centrales de riesgos a su vez proporcionan una serie de servicios en base al procesamiento y modelamiento de la informacion que acumulan. Uno de estos servicios es el de "verificacion vehicular", consulta que se realiza a los sistemas de informacion por parte de usuarios externos (clientes). Estos usuarios externos son principalmente las empresas aseguradoras que venden el Seguro Obligatorio de Accidentes de Transito (SOAT). La informacion brindada por esta consulta se utiliza para validar los datos del vehiculo proporcionados por un comprador del SOAT.

Un inconveniente presentado durante varios anos es el problema de comunicacion e incompatibilidad de tecnologias, debido a que las empresas e instituciones elegian diferentes plataformas para el desarrollo de sus sistemas de informacion y esto dificultaba la interoperabilidad entre tecnologias diferentes de dos empresas. Sin embargo, en junio del ano 2001 el Gartnet Group, un centro de investigacion de tecnologias de informacion y Arma consultora formada por importantes empresas del sector de las Tecnologias de Informacion, documento un cronograma para la adopcion de Web Services desde el 2001 al 2005.

"La Web usa HTTP para correr sobre TCP/IP, que se convirtio en el estandar universal. La invencion de XML fue lo que realmente permitio el camino para los Web Services. Con SOAP y WSDL, las companias pudieron crear y describir sus propios Web Services." [1] [4] (traducido de la referencia). Estos conceptos seran explicados en las secciones siguientes. Asi mismo, para el desarrollo de este Web Service se empleo el Lenguaje Unificado de Modelo UML, el lenguaje de programacion Java en su version J2EE, la plataforma SUN JAX-WS (ver definicion en tabla 1) para le generacion de los artefactos necesarios para la publicacion del Web Service y JMeter como testeador para las pruebas del sistema.

Los principales objetivos de la investigacion son establecer si las tecnologias seleccionadas funcionan correctamente, desarrollar los diagramas UML que permitiran una diagramacion adecuada y ordenada para futuras modificaciones, y por ultimo determinar el valor maximo de usuarios concurrentes para el correcto funcionamiento del Web Service.

DEFINICIONES

Web Service o servicio web permite la comunicacion negocio a negocio B2B (Business to Business, que se denomina comercio en la red), permitiendo a las empresas compartir e integrar datos y servicios heterogeneos en una Arquitectura Orientada a Servicios SOA. "En los ultimos anos, Web Service se ha convertido en una tendencia dominante y se esta haciendo la tecnologia "omnipresente" que prometia ser en sus origenes" [1].

Los Web Services permiten llamadas a procedimientos remotos y la mensajeria asincrona, soliendo implementarse mediante mensajes XML a traves del protocolo de comunicacion HTTP.

Adicionalmente, los "Web Services son definidos por W3C que es el comite responsable de su arquitectura y reglamentacion" [2].

A continuacion la definicion de terminos importantes para la compresion de los Web Services:

* XML: Extensible Markup Language, es el formato estandar para los datos que se intercambian.

* SOAP: Simple Object Access Protocol, protocolo sobre el que se establece el intercambio, principalmente HTTP.

* WSDL: Web Services Description Language, es el lenguaje de la interfaz publica para los servicios web, es una descripcion basada en XML de los requisitos funcionales necesarios para establecer una comunicacion con los servicios web.

* UDDI: Universal Description Discovery and Integration, protocolo para publicar la informacion de los servicios web, permite a las aplicaciones comprobar que servicios web estan disponibles.

* HTTP: Hipertext Transfer Protocol, es el protocolo utilizado en cada transaccion de la World Wide Web.

* W3C: World Wide Web Consortium, consorcio internacional que produce recomendaciones para la World Wide Web.

Para el caso particular de la implementacion del Web Service de "Verificacion Vehicular", se realiza mediante el protocolo HTTP por ser un estandar ampliamente utilizado. Se aprecia en la Figura 1 que los diversos "consumidores" del Web Service seran los puntos de venta de los SOAT, por ejemplo modulos en los supermercados, retails, grifos, universidades, etc. Inclusive BlackBerries u otros dispositivos moviles para vendedores de a pie.

La comunicacion con el Web Service no se realiza a traves de los usuarios humanos, sino los sistemas informaticos de la empresa, porque el consumo del Web Service se realiza mediante la invocacion de otro sistema informatico, por tanto la Figura 1 es un diagrama ilustrativo, siendo los "Puntos de Venta" sistemas de informacion.

[FIGURA 1 OMITIR]

Asi mismo, para el desarrollo del Web Service se seleccionaron las tecnologias que se indican, de forma sustentada en la Tabla 1.

En la Figura 2 se aprecia como se desplegara y almacenara el aplicativo que resolvera el problema de la implementacion y puesta en marcha del Web Service de verificacion vehicular. Esta compuesto por dos partes:

Aplicativo Web (Contenedor Web): donde se almacena en si el WSDL, es decir el Web Service que se publica para su consumo.

Aplicacion Empresarial EJB 3 (Contenedor de Aplicaciones): donde se almacena en si la clase encargada de realizar la logica del negocio. Esta no es visible por los consumidores, sino que es invocada por el "Aplicativo Web".

La aplicacion de este Web Service permitira su consumo por parte de los clientes, en este caso vienen a ser los sistemas de informacion de las empresas que adquieran el servicio. Estos sistemas no necesariamente tienen que estar desarrollados bajo el lenguaje de programacion Java, debido a que se emplea el protocolo de comunicacion HTTP y el estandar XML. Por ello, se pueden utilizar lenguajes de programacion como .NET, Visual Basic, PHP, Ruby, Cobol, etc. para poder consumir el Web Service.

En la Figura 3 se muestra un ejemplo de la interaccion de un "Consumidor" (Client Side) y un "Productor" (Server Side) desarrollados en Java.

Todo ello empieza del lado izquierdo, el "Consumidor" establece los valores de los parametros (param) necesarios para realizar el consumo del Web Service y seguido invoca mediante un mensaje Request: SOAP y el "Productor" recibe la peticion, lee los parametros enviados y procesa. Por ultimo, genera un retorno mediante el mensaje Response: SOAP el cual es enviado de regreso al "Consumidor", Analizando el ciclo.

2. DESARROLLO DEL SISTEMA DE INFORMACION

2.1. Analisis del sistema mediante la notacion UML

Siendo Java el lenguaje de programacion a utilizar y su principal caracteristica es de ser un lenguaje orientado a objetos; el analisis del sistema se basara en la notacion UML, es decir el Lenguaje Unificado de Modelado.

"UML es un lenguaje de modelado visual de proposito general que se utiliza para especificar, utilizar, construir y documentar los artefactos de un sistema software" [7]. Dada esta definicion, se establece que un modelo capta los aspectos importantes de lo que se esta modelando y simplifica u omite el resto.

[FIGURA 2 OMITIR]

[FIGURA 3 OMITIR]

Uno de los artefactos mas importantes de la notacion UML son los casos de uso del sistema, los cuales modelan la funcionalidad del sistema tal como lo perciben los agentes externos que interactuan con este. Su funcionalidad se expresa como una transaccion que se realiza entre un actor y el sistema; en la Figura 4 se aprecia un ejemplo.

Para el Sistema de Verificacion Vehicular se identifica al actor externo como un "Sistema Consumidor Externo" y al proceso de la consulta como el caso de uso "Consultar Vehiculo", tal como se aprecia en la Fig. 5.

"Notese que la caja del actor contiene el simbolo <<actor>>, denominado estereotipo UML, el cual trata de clasificarlo de un solo modo" [3]. Se decide utilizar este estereotipo como buena practica, ya que el actor que interactua con el sistema no es una persona en si, sino un sistema informatico externo. Cabe precisar que este caso de uso se debe de especificar, es decir escribir "literalmente" como actua el actor y el caso de uso en un llamado al Web Service.

Adicionalmente, en la Figura 6 se presenta el diagrama de clase de analisis con las principales entidades a implementar. En este caso "EstructuraVehicularEntrada" representa los parametros de entrada a enviar al Web Service y "EstructuraVehicularSalida" representa a los parametros a devolver producto de la consulta.

[FIGURA 4 OMITIR]

[FIGURA 5 OMITIR]

[FIGURA 6 OMITIR]

2.2. Diseno del sistema

"El diseno orientado a objetos transforma el modelo de analisis creado usando analisis orientado a objetos, en un modelo de diseno que sirve como anteproyecto para la construccion de software" [6].

En el presente diseno, se define en la Figura 7 el diagrama de clases de diseno que sera el soporte de la implementacion y logica del negocio, basados en las estructuras definidas en la Figura 6.

Se aprecia que la clase "VerificacionVehicularWS" es la entrada del Web Service, seguido se invoca a la interfaz "VerificacionCICSLocal" que a su vez esta implementada por el EJB Session "VerificacionCICS"; siendo esta ultima la encargada de realizar la logica del negocio que implica una llamada a la funcion "conectarCICS" de la clase "Conexion-Vehiculo", que obtiene realmente los datos de un servidor del tipo CICS.

Asi mismo, todo el aplicativo estara empaquetado en un archivo del tipo Enterprise Application Archive (EAR) que es un estandar propio de las aplicaciones J2EE y se utiliza para su despliegue en el servidor Jboss. En la figura 8 se observa un EAR y sus principales componentes internos que agrupan dentro de si a las clases de las figuras 6 y 7.

2.3. Implementacion de J2EE

La construccion del Web Service se desarrolla con el lenguaje de programacion Java en su version J2EE. Asi mismo, esta permite el desarrollo de los servicios web mediante el uso de anotaciones, los cuales son los siguientes:

@WebService a especifica que la clase es un Web Service a publicar.

@WebResult a especifica el metodo y el resultado del Web Service a publicar.

@WeParam a especifica el o los parametro(s) que recibe el Web Service.

En la figura 9 se visualiza la clase VerificacionVehicularWS y la utilizacion de las anotaciones para su publicacion como Web Service. Adicionalmente, se aprecia la utilizacion de las clases de diseno previamente realizadas en el punto 2.2 DISENO DEL SISTEMA y Figura 7.

[FIGURA 7 OMITIR]

[FIGURA 8 OMITIR]

Despues de implementar y escribir el codigo fuente se procede a utilizar la herramienta de compilacion JAX-WS en su version 2.2.1, que proporciona los artefactos necesarios para la publicacion y puesta en marcha del Web Service. Estos artefactos son principalmente los siguientes: la clase VerificacionVehicularWS compilada, el archivo de extension .XSD (contiene las estructuras de entrada y salida del Web Service) y el archivo WSLD; siendo este ultimo el principal y el encargado de publicar el Web Service en la Web y proveer la recepcion y emision de los mensajes a traves del SOAP. En la figura 10 se aprecia el contenido del archivo WSDL del tipo XML generado.

En la Figura 11 se visualiza los archivos XML de un consumo del Web Service de Verificacion Vehicular. En la seccion izquierda de la figura se aprecia el archivo de entrada con los campos respectivos a enviar. En la seccion derecha se observa el archivo de respuestas con los campos obtenidos producto de la consulta. Los mencionados archivos viajan por medio de la Web a traves del protocolo HTTP y la definicion del WSDL.
Figura 9. Visualizacion del codigo la clase Verificacion VehicularWS.

Package com.pe.verification.ws;

Import javax.jws.WebParam;[]

@WebService (name="VErificationService")
Public class VerificationVehicularWS (

   private Context ctx;

   public VerificationVehicularWS(){[]

   public @WebResult (name-"Salida") EstructuraVehicularSalida
   VerificarVehiculo
   (@WebParam (name="Entrada") EstructuraVehicularEntrada
   estructuraEntrada)
   {
           EstucturaVehicularSalida estructuraSalida = null;

           VerificacionCICSLocal verificacionCICS;
           Try {

                verificacionCICS = (VerificacionCICSLocal)
                ctx.lookup("java:comp/env/
   VerificacionCICSlocal");

                estructuraSalida = verificacionCICS.verificarVehiculo
                (estructuraEntrada);

           } catch (NamingException e) {
               e.printStackTrace();

           }

           Return estructuraSalida;

FUENTE: Elaboracion propia

Figura 10. Archivo WSDL generado por el JAX-WS

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-Generated by JAX-WS RI at "http://jax-ws.dev.java.net. RI's version
is JAX-WS RI 2.2.1-b01-.-->
<definitions targetNamespace=http://ws.verificacion.pe.com/
name="VerificacionVehicularWSService" xmlns="http://schemas.
xmlsoap.org/wsdl"
xmlns:wsp=http://www.w3org/ns/ws-policy
xmlns:tns=http://ws.verificacion.pe.com/
xmnls:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">
  <types>
    <xsd:schema>
       <xsd:import namespace=http://ws.verificacion.pe.com/
schemalocation="VerificacionVehicularWSService_schema1.xsd"/>
    </xsd:schema>
  </types>
  <message name="verificarVehiculo">
    <part name="parameters" element="tns:verificarVehiculoResponsde"/>
  </mesage>
  <portType name="VerificacionService">
  <operation name="verificarVehiculo">
    <input
wsam:Action=http://ws.verificacion.pe.com/VerificacionService/
verificarVehiculo Request message="tns:verificarVehiculo"/>
    <output
wsam:Action="http://ws.verificacion.pe.com/VerificacionService/
verificarVehiculo Response message="tns:verificarVehiculoResponse"/>
    </operation>
  </portType>
  <binding name="VerificacionServicePortBinding" type="tns:
  VerificacionService">

Fuente: Elaboration propia

Figura 11. Archivos XML de entrada (izquierda) y salida (derecha) de
un consumo del WS.

<?xml version = "1.0" encoding = "UTF - 8">
<soapenv: Envelope
xmlns: soapenv = "http://schemas.xmlsoap.org/soap/envelope/"
xmlns: ws = "http://ws.verification.pe.com/">
   <soapenv: Header/>
   <soapenv: Body>
       <ws: verificarVehiculo>
           <Entrada>
              <argumento> II4939</argumento>
              <cabecera>
                 <canal>IAX123</canal>
                 <clave>MACRI1234</clave>
                 <transaccion>0</transaccion>
              </cabecera>
              <tipoConsulta>1</tipoConsulta>
            </Entrada>
        </ws: verificarVehiculo>
    </soapenv: Body>
</soapenv: Envelope>

<?xml version-"1.0" encoding-"UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body>
    <ns2:verificarVehiculoResponse
          xmlns:ns2="http://ws.verificacion.pe.com/">
      <Salida>
          <anhoVehiculo>2010</anhoVehiculo>
          <cantidadToneladas>2300</cantidadToneladas>
          <capacidadMotor>1600</capacidadMotor>
          <carroceriaChasis>Nueva de fabrica</carroceriaChasis>
          <claseVehiculo>Class EE</claseVehiculo>
          <color>Negro</color>
          <kilometraje>150000</kilometraje>
          <marca>Mercedes Benz</marca>
          <modelo>Coupe</modelo>
          <motor>1800</motor>
          <numAsientos>4</numAsientos>
          <placa>II4939</placa>
          <remolque>No aplica</remolque>
          <tipoCombustible>Premium</tipoCombustible>
          <tipoVehiculo>De lujo</tipoVehiculo>
          <uso>Ejecutivo</uso>
          <valorVehiculo>75000</valorVehiculo>
          <version>C1</version>
          <zonaRegistral>Lina - Lina - San Isidro</zonaRegistral>
      </Salida>
    </ns2:verificarVehiculoResponse>
  </S:Body>
</S:Envelope>


3. PRUEBA DEL SERVICIO WEB

"El objetivo de las pruebas, expresado de forma sencilla, es encontrar el mayor numero de errores con una cantidad razonable de esfuerzo, aplicado sobre un lapso de tiempo realista" [6].

En el parrafo anterior se definio las pruebas para un sistema de informacion tradicional y que refleja el enfoque de las pruebas del tipo funcional. Sin embargo, la prueba mas critica e importante para un Web Service son las denominadas pruebas de estres, las cuales someteran al servicio web a un numero determinado e incremental de invocaciones.

Lo que se busca primordialmente es evaluar la respuesta y desempeno del Web Service ante un mayor numero de consultas concurrentes. Por ello, se utilizo la herramienta de testeo de software JMeter especializada en pruebas para sistemas desarrollados bajo la tecnologia J2EE.

En la Tabla 2 se muestra los datos de la simulacion del sistema, empezando por 10 usuarios hasta llegar a los 10 000 con los incrementos como se aprecia en la tabla. Ademas, JMeter arroja un resultado denominado "Rendimiento" que se establece como el numero de peticiones por minuto, el cual cuantifica precisamente el rendimiento del aplicativo. Como se aprecia en la grafica a mayor numero de usuarios concurrentes el valor de "Rendimiento" va en aumento, es decir el Web Service toma un mayor tiempo para procesar las solicitudes de consulta.

Todos los valores de la Tabla 2 son extraidos de las pruebas y reflejan una unidad de medida de JMeter denominada latencia que se expresa en ms (milisegundos). En la Figura 13 se muestra la grafica de evolucion del rendimiento, lo cual refleja que a mayor numero de usuarios se requerira un numero mayor de tiempo de procesamiento y se vera reflejado en la lentitud del sistema. Cabe mencionar, que un pico de incremento considerable se obtiene al variar de 5 000 a 7 000 usuarios.

[FIGURA 12 OMITIR]

[FIGURA 13 OMITIR]

4. CONCLUSIONES

* El Web Service funciono correctamente y su desarrollo e implementacion con las tecnologias Java J2EE, EJB3, JAX-WS y JBoss fue una eleccion correcta y viable al ser Open Source y no tener la limitacion de una licencia comercial.

* El analisis y diseno mediante la notacion UML permitio un adecuado entendimiento del sistema asi como una clara documentacion para modificaciones o mantenimientos en el futuro.

* Se garantiza la compatibilidad del Web Service con los llamados de otros aplicativos desarrollados en diferentes lenguajes de programacion, debido a que se utilizo el protocolo SOAP y el estandar XML para su implementacion.

5. RECOMENDACIONES

* La aplicacion desarrollada fue puesta en produccion en una importante central de riesgos crediticios del pais, del mismo modo se espera que otras centrales lo implementen ya que implica un negocio importante para ellos por ser el SOAT un seguro obligatorio, debido a que las companias aseguradoras se ven en la obligacion de comprobar la informacion brindada por sus clientes.

* Adicionalmente, las centrales de riegos deben tener en cuenta los resultados de las pruebas realizadas en esta investigacion y a modo de recomendacion se deberia de configurar el servidor de aplicaciones JBoss para recibir un maximo de 5000 usuarios concurrentes, ya que hasta ese valor la aplicacion trabaja con un buen rendimiento.

6. REFERENCIAS BIBLIOGRAFICAS

[1] Clay W. Avondolio D. Schrager S. Mitchell M. Scanlon J. (2007). Profesional Java JDK. 6.a ed. First Edition, Anaya Multimedia--WROX, Spain.

[2] Ferris C, Farrell J.--IBM Research Triangle Park, INC (2003). What are Web Services? As sociation for Computing Machinery--ACM Digital Library. Disponible en: http://portal.acm.org/citation.cfm?id=777335 (Visitado el 03/01/2011).

[3] Larman C. (2008). UML Y PATRONES--Una introduccion al analisis y diseno orientado a objetos y al proceso unificado. 2.a ed. Pearson Prentice Hall, Espana.

[4] Levvit J (2001), From EDI to XML and UDDI: A brief history of Web Services, Information Week. Disponible en: http://www.informationweek.com/news/development/tools/showArticle. jhtml?articleID=6506480 (Visitado el 03/01/2011).

[5] Mark D. Hansen (2007). SOA Using Java Web Services, First Edition, Prentice Hall, U.S.A.

[6] Pressman R (2005). Ingenieria del Software Un enfoque practico. 6.a ed. Mc Graw Hill, Espana.

[7] Rumbaugh J. Jacobson I. Booch G (2007). El lenguaje Unificado de Modelado, UML 2.0--Manual de Referencia. 2.a ed. Pearson, Espana.

[8] The Apache Jakarta Project (2010). Building a Web Service Test Plan, Apache JMeter. Disponible en: http://jakarta.apache.org/jmeter/ usermanual/build-ws-test-plan.html_(Visitado el 03/01/2011).

Recibido: 21/03/11

Aceptado: 05/09/11

(1) Felix Melchor Santos Lopez

(1) Ingeniero Informatico, Pontificia Universidad Catolica del Peru. E-mail: fsantos@pucp.edu.pe
Tabla 1. Cuadro de tecnologias a utilizar y su descripcion

Tipo de Tecnologia                Descripcion y sustento

Lenguaje de            J2EE (Java Second Enterprise Edition),
 Programacion Java.    lenguaje de programacion ampliamente
  Version: JDK 6.      utilizado en las empresas, posee una
                       gran variedad de documentacion, una
                       madurez en el mercado que lo hacen
                       confiable, soporte de la corporacion Oracle
                       y es Open Source.

Enterprise Java        Perteneciente al J2EE, EJB es un API para el
 Bean--EJB.            desarrollo de aplicaciones
 Version: EJB 3.       empresariales que permite almacenar y gestionar
                       las clases encargadas de llevar a cabo la
                       logica de negocio de un sistema de informacion.
                       Se utiliza la version numero 3 que permite la
                       utilizacion de "anotaciones", lo cual
                       disminuye el tiempo de desarrollo debido
                       a que es mas simple.

SUN JAX-WS.            Permite la construccion de Web Services
 Version: 2.2.1.       mediante la utilizacion de "anotaciones"
                       proporcionados por el JDK 6 y genera
                       automaticamente el archivo WSDL, UDDI y las
                       clases necesarias para el despliegue del Web
                       Service.

Servidor de            Servidor de Aplicaciones encargado de almacenar
 Aplicaciones Jboss.   la aplicacion y ponerlo en marcha. Jboss es
 Version: Jboss        compatible para la puesta en produccion de
 5.0.1GA.              aplicaciones J2EE, su version EJB3 y Web
                       Services. Adicionalmente, la version GA de
                       Jboss es Open Source.

JMeter                 JMeter es un software OpenSource desarrollado
 Version: 2.4.         en java como una aplicacion de escritorio que
                       permite realizar pruebas de esfuerzo de
                       aplicaciones y servicios Web.

Fuente: Elaboracion propia

Tabla 2. Cuadro de valores arrojados en las pruebas

Numero de      Rendimiento       Media    Mediana   Desviacion
usuarios    (peticion/minuto)    (ms)      (ms)        (ms)

   10            85.167          3534      2040        2616
   50            25.927          3337      3041        2446
   100           37.490          3542      3077        2373
   500           121.257         3556      3070        2594
  1000           224.309         2937      1681        2423
  2500           457.948         2245      1158        2169
  5000           726.207         2077      1197        1923
  7000          19839.271        2324      1432        1821
  10000         17336.353        2251      1440        1827

Fuente: Elaboracion propia
COPYRIGHT 2011 Universidad Nacional Mayor de San Marcos
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2011 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Sistema e Informatica
Author:Melchor Santos Lopez, Felix
Publication:Industrial data
Article Type:Report
Date:Jul 1, 2011
Words:3664
Previous Article:Tratamiento de efluentes textiles con luz ultravioleta solar.
Next Article:Gestion de base de datos con SCADA para el control automatizado de una valvula de control proporcional.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters