Web Service

Sistema e Informática
Revista de la Facultad de Ingeniería Industrial
Desarrollo de un servicio web de verificación vehicular en centrales de riesgos crediticios
14(2): 16-25 (2011) UNMSM
ISSN: 1560-9146 (Impreso) / ISSN: 1810-9993 (Electrónico)

Desarrollo de un servicio web de verificación
vehicular en centrales de riesgos crediticios

Recibido: 21/03/11 Aceptado: 05/09/11 (1) Félix Melchor Santos López

INTRODUCCIÓN
RESUMEN
Las centrales de riesgo crediticio en el Perú son em- En la actualidad los servicios web o Web Services proporcionan
presas receptoras de información de fuentes externas
(AFP, bancos, seguros, municipalidades, etc.) que se
una importante interoperabilidad e integración entre sistemas de
encargan de brindar diversos servicios a las empre- información desarrollados bajo diferentes tecnologías. Por otro
sas, entidades y ciudadanos del país, por ende sus lado, las centrales de riesgos crediticios son las encargadas de
sistemas informáticos están constantemente actuali-
zados y a la vanguardia de la tecnología. Debido a
la recepción de información crediticia de diferentes fuentes ex-
esto y la gran cantidad de tecnologías presentes en el ternas (AFP, bancos, seguros, municipalidades, etc.), en el Perú
mercado, recientemente se viene optando por brindar están reguladas por la Superintendencia de Banca, Seguros y
soluciones basados en Servicios Web, ya que permi-
ten una comunicación, interoperabilidad e intercambio
AFP (SBS).
de información independiente del lenguaje de pro-
gramación en que estén desarrollados los sistemas.
Estas centrales de riesgos a su vez proporcionan una serie de
Esto representa una gran ventaja por ejemplo para el servicios en base al procesamiento y modelamiento de la informa-
sistema de “Verificación Vehicular” que brinda infor- ción que acumulan. Uno de estos servicios es el de “verificación
mación de los vehículos registrados en el país. Adi-
cionalmente, la utilización de UML (Unified Modeling
vehicular”, consulta que se realiza a los sistemas de información
Language) como el lenguaje de modelado del sistema por parte de usuarios externos (clientes). Estos usuarios exter-
y el lenguaje de programación Java en su versión nos son principalmente las empresas aseguradoras que venden
J2EE (Java Second Enterprise Edition) permiten un
adecuado desarrollo del software, y JMeter contribuye
el Seguro Obligatorio de Accidentes de Tránsito (SOAT). La in-
a realizar las pruebas del sistema lográndose deducir formación brindada por esta consulta se utiliza para validar los
los parámetros de configuración para su óptimo des- datos del vehículo proporcionados por un comprador del SOAT.
empeño, que para el presente sistema se concluye
que no deberá sobrepasar los 5 000 usuarios concu- Un inconveniente presentado durante varios años es el proble-
rrentes del servicio web.
ma de comunicación e incompatibilidad de tecnologías, debido a
Palabras clave: servicio web, verificación vehicular, que las empresas e instituciones elegían diferentes plataformas
central de riesgo crediticio, J2EE, UML
para el desarrollo de sus sistemas de información y esto difi-
Development of a web service of vehi- cultaba la interoperabilidad entre tecnologías diferentes de dos
cle inspection in central credit risk empresas. Sin embargo, en junio del año 2001 el Gartnet Group,
ABSTRACT un centro de investigación de tecnologías de información y firma
The central credit risk companies in Peru collect much consultora formada por importantes empresas del sector de las
information from different external sources and they Tecnologías de Información, documentó un cronograma para la
offer various services to the others enterprises, enti- adopción de Web Services desde el 2001 al 2005.
ties and citizens. Therefore, their information systems
are updated constantly. In the world there are many “La Web usa HTTP para correr sobre TCP/IP, que se convirtió
different technologies developed in different language
programming, thus it was considered a pain in the en el estándar universal. La invención de XML fue lo que real-
neck for software engineers. Fortunately, nowadays mente permitió el camino para los Web Services. Con SOAP
there is a framework called Web Service that allows y WSDL, las compañías pudieron crear y describir sus propios
communication, interoperability and exchange among
different language programming. The “Vehicle Inspec- Web Services.” [1] [4] (traducido de la referencia). Estos con-
tion” system gives all the information about vehicles ceptos serán explicados en las secciones siguientes. Así mismo,
registered in the country. In addition, this system was para el desarrollo de este Web Service se empleó el Lenguaje
developed in J2EE (Java Second Enterprise Edition)
and UML (Unified Modeling Language) because are Unificado de Modelo UML, el lenguaje de programación Java en
reliable and free technologies; also JMeter is a good su versión J2EE, la plataforma SUN JAX-WS (ver definición en
test tool that helps to establish the accurate measure tabla 1) para le generación de los artefactos necesarios para la
of the parameters for a good system performance. As
a result, 5 000 concurrent users should not exceed the publicación del Web Service y JMeter como testeador para las
capacity of this web service. pruebas del sistema.
Keywords: web service, vehicle inspection, central
credit risk, J2EE, UML 1 Ingeniero Informático, Pontificia Universidad Católica del Perú.
E-mail: fsantos@pucp.edu.pe

16 Ind. data 14(2), 2011


Félix Melchor Santos López

Los principales objetivos de la investigación son es- • WSDL: Web Services Description Language, es
tablecer si las tecnologías seleccionadas funcionan el lenguaje de la interfaz pública para los servi-
correctamente, desarrollar los diagramas UML que cios web, es una descripción basada en XML de
permitirán una diagramación adecuada y ordenada los requisitos funcionales necesarios para esta-
para futuras modificaciones, y por último determinar blecer una comunicación con los servicios web.
el valor máximo de usuarios concurrentes para el
correcto funcionamiento del Web Service. • UDDI: Universal Description Discovery and In-
tegration, protocolo para publicar la información
de los servicios web, permite a las aplicaciones
DEFINICIONES
comprobar qué servicios web están disponibles.
Web Service o servicio web permite la comunica-
ción negocio a negocio B2B (Business to Business, • HTTP: Hipertext Transfer Protocol, es el proto-
que se denomina comercio en la red), permitiendo colo utilizado en cada transacción de la World
a las empresas compartir e integrar datos y servi- Wide Web.
cios heterogéneos en una Arquitectura Orientada a • W3C: World Wide Web Consortium, consorcio
Servicios SOA. “En los últimos años, Web Service internacional que produce recomendaciones
se ha convertido en una tendencia dominante y se para la World Wide Web.
está haciendo la tecnología “omnipresente” que
prometía ser en sus orígenes” [1]. Para el caso particular de la implementación del
Web Service de “Verificación Vehicular”, se realiza
Los Web Services permiten llamadas a procedi-
mediante el protocolo HTTP por ser un estándar
mientos remotos y la mensajería asíncrona, solien-
do implementarse mediante mensajes XML a tra- ampliamente utilizado. Se aprecia en la Figura 1
vés del protocolo de comunicación HTTP. que los diversos “consumidores” del Web Service
serán los puntos de venta de los SOAT, por ejem-
Adicionalmente, los “Web Services son definidos plo módulos en los supermercados, retails, grifos,
por W3C que es el comité responsable de su arqui-
universidades, etc. Inclusive BlackBerries u otros
tectura y reglamentación” [2].
dispositivos móviles para vendedores de a pie.
A continuación la definición de términos importan-
La comunicación con el Web Service no se realiza a
tes para la compresión de los Web Services:
través de los usuarios humanos, sino los sistemas
• XML: Extensible Markup Language, es el forma- informáticos de la empresa, porque el consumo del
to estándar para los datos que se intercambian. Web Service se realiza mediante la invocación de
• SOAP: Simple Object Access Protocol, proto- otro sistema informático, por tanto la Figura 1 es un
colo sobre el que se establece el intercambio, diagrama ilustrativo, siendo los “Puntos de Venta”
principalmente HTTP. sistemas de información.

Figura 1. Comunicación de los consumidores del Web Service y el protocolo HTTP.

Fuente: Elaboración propia

Ind. data 14(2), 2011 17



Tabla 1. Cuadro de tecnologías a utilizar y su descripción

Tipo de Tecnología Descripción y sustento

J2EE (Java Second Enterprise Edition), lenguaje de programación amplia-
Lenguaje de Programación Java. mente utilizado en las empresas, posee una gran variedad de documen-
Versión: JDK 6. tación, una madurez en el mercado que lo hacen confiable, soporte de la
corporación Oracle y es Open Source.

Perteneciente al J2EE, EJB es un API para el desarrollo de aplicaciones
Enterprise Java Bean – EJB.
empresariales que permite almacenar y gestionar las clases encargadas
de llevar a cabo la lógica de negocio de un sistema de información. Se uti-
Versión: EJB 3.
liza la versión número 3 que permite la utilización de “anotaciones”, lo cual
disminuye el tiempo de desarrollo debido a que es más simple.

SUN JAX-WS.
Permite la construcción de Web Services mediante la utilización de “anota-
ciones” proporcionados por el JDK 6 y genera automáticamente el archivo
Versión: 2.2.1.
WSDL, UDDI y las clases necesarias para el despliegue del Web Service.

Servidor de Aplicaciones encargado de almacenar la aplicación y ponerlo
Servidor de Aplicaciones Jboss. en marcha. Jboss es compatible para la puesta en producción de aplica-
Versión: Jboss 5.0.1GA. ciones J2EE, su versión EJB3 y Web Services. Adicionalmente, la versión
GA de Jboss es Open Source.

JMeter
JMeter es un software OpenSource desarrollado en java como una aplica-
ción de escritorio que permite realizar pruebas de esfuerzo de aplicaciones
Versión: 2.4.
y servicios Web.


Así mismo, para el desarrollo del Web Service se En la Figura 3 se muestra un ejemplo de la interac-
seleccionaron las tecnologías que se indican, de ción de un “Consumidor” (Client Side) y un “Produc-
forma sustentada en la Tabla 1. tor” (Server Side) desarrollados en Java.
En la Figura 2 se aprecia cómo se desplegará y Todo ello empieza del lado izquierdo, el “Consumi-
almacenará el aplicativo que resolverá el problema dor” establece los valores de los parámetros (pa-
de la implementación y puesta en marcha del Web ram) necesarios para realizar el consumo del Web
Service de verificación vehicular. Está compuesto Service y seguido invoca mediante un mensaje
por dos partes: Request: SOAP y el “Productor” recibe la petición,
lee los parámetros enviados y procesa. Por último,
Aplicativo Web (Contenedor Web): donde se alma-
genera un retorno mediante el mensaje Response:
cena en sí el WSDL, es decir el Web Service que se
SOAP el cual es enviado de regreso al “Consumi-
publica para su consumo.
dor”, finalizando el ciclo.
Aplicación Empresarial EJB 3 (Contenedor de Apli-
caciones): donde se almacena en sí la clase encar-
2. DESARROLLO DEL SISTEMA DE INFORMACIÓN
gada de realizar la lógica del negocio. Esta no es
visible por los consumidores, sino que es invocada
2.1. Análisis del sistema mediante la notación uml
por el “Aplicativo Web”.
Siendo Java el lenguaje de programación a utilizar
La aplicación de este Web Service permitirá su con-
y su principal característica es de ser un lenguaje
sumo por parte de los clientes, en este caso vienen
orientado a objetos; el análisis del sistema se basa-
a ser los sistemas de información de las empresas
rá en la notación UML, es decir el Lenguaje Unifica-
que adquieran el servicio. Estos sistemas no nece-
do de Modelado.
sariamente tienen que estar desarrollados bajo el
lenguaje de programación Java, debido a que se “UML es un lenguaje de modelado visual de propó-
emplea el protocolo de comunicación HTTP y el es- sito general que se utiliza para especificar, utilizar,
tándar XML. Por ello, se pueden utilizar lenguajes de construir y documentar los artefactos de un sistema
programación como .NET, Visual Basic, PHP, Ruby, software” [7]. Dada esta definición, se establece que
Cobol, etc. para poder consumir el Web Service. un modelo capta los aspectos importantes de lo que

18 Ind. data 14(2), 2011



Figura 2. Gráfico del Servidor Jboss y el aplicativo a desarrollar.


Figura 3. Invocación de un Subsistema (Client Side) a un Subsistema (Server Side) desarrollado en
Java mediante mensajes emitidos por SOAP.

Fuente. Tomado de Mark Hansen [5]

se está modelando y simplifica u omite el resto. “Nótese que la caja del actor contiene el símbolo
<<actor>>, denominado estereotipo UML, el cual tra-
Uno de los artefactos más importantes de la nota-
ta de clasificarlo de un solo modo” [3]. Se decide uti-
ción UML son los casos de uso del sistema, los cua-
lizar este estereotipo como buena práctica, ya que el
les modelan la funcionalidad del sistema tal como lo actor que interactúa con el sistema no es una perso-
perciben los agentes externos que interactúan con na en sí, sino un sistema informático externo. Cabe
este. Su funcionalidad se expresa como una tran- precisar que este caso de uso se debe de especifi-
sacción que se realiza entre un actor y el sistema; car, es decir escribir “literalmente” cómo actúa el ac-
en la Figura 4 se aprecia un ejemplo. tor y el caso de uso en un llamado al Web Service.
Para el Sistema de Verificación Vehicular se identifica Adicionalmente, en la Figura 6 se presenta el dia-
al actor externo como un “Sistema Consumidor Exter- grama de clase de análisis con las principales en-
no” y al proceso de la consulta como el caso de uso tidades a implementar. En este caso “Estructura-
“Consultar Vehículo”, tal como se aprecia en la Fig. 5. VehicularEntrada” representa los parámetros de

Ind. data 14(2), 2011 19



Figura 4. Diagrama de caso de uso Figura 5. Diagrama de caso de uso del sistema

Sistema de Verificación Vehicular

<<actor>>
Consultar
Sistema Consumidor
Caso de uso Vehículo
Externo

Fuente: Elaboración propia Fuente: Elaboración propia

Figura 6. Diagrama de clases del sistema


entrada a enviar al Web Service y “EstructuraVehi- está implementada por el EJB Session “Verifica-
cularSalida” representa a los parámetros a devolver cionCICS”; siendo esta última la encargada de rea-
producto de la consulta. lizar la lógica del negocio que implica una llamada
a la función “conectarCICS” de la clase “Conexion-
2.2. Diseño del sistema Vehiculo”, que obtiene realmente los datos de un
“El diseño orientado a objetos transforma el mode- servidor del tipo CICS.
lo de análisis creado usando análisis orientado a Así mismo, todo el aplicativo estará empaquetado
objetos, en un modelo de diseño que sirve como en un archivo del tipo Enterprise Application Archi-
anteproyecto para la construcción de software” [6]. ve (EAR) que es un estándar propio de las aplica-
En el presente diseño, se define en la Figura 7 el ciones J2EE y se utiliza para su despliegue en el
diagrama de clases de diseño que será el soporte servidor Jboss. En la figura 8 se observa un EAR y
de la implementación y lógica del negocio, basados sus principales componentes internos que agrupan
en las estructuras definidas en la Figura 6. dentro de sí a las clases de las figuras 6 y 7.
Se aprecia que la clase “VerificacionVehicularWS”
2.3. Implementación de j2ee
es la entrada del Web Service, seguido se invoca
a la interfaz “VerificacionCICSLocal” que a su vez La construcción del Web Service se desarrolla con

20 Ind. data 14(2), 2011



el lenguaje de programación Java en su versión Después de implementar y escribir el código fuente
J2EE. Así mismo, esta permite el desarrollo de los se procede a utilizar la herramienta de compilación
servicios web mediante el uso de anotaciones, los JAX-WS en su versión 2.2.1, que proporciona los
cuales son los siguientes: artefactos necesarios para la publicación y puesta
en marcha del Web Service. Estos artefactos son
@WebService à especifica que la clase es un Web principalmente los siguientes: la clase Verificacion-
Service a publicar. VehicularWS compilada, el archivo de extensión
@WebResult à especifica el método y el resultado .XSD (contiene las estructuras de entrada y salida
del Web Service a publicar. del Web Service) y el archivo WSLD; siendo este
último el principal y el encargado de publicar el Web
@WeParam à especifica el o los parámetro(s) que Service en la Web y proveer la recepción y emisión
recibe el Web Service. de los mensajes a través del SOAP. En la figura 10
En la figura 9 se visualiza la clase VerificacionVehi- se aprecia el contenido del archivo WSDL del tipo
cularWS y la utilización de las anotaciones para su XML generado.
publicación como Web Service. Adicionalmente, se En la Figura 11 se visualiza los archivos XML de un
aprecia la utilización de las clases de diseño pre- consumo del Web Service de Verificación Vehicular.
viamente realizadas en el punto 2.2 DISEÑO DEL En la sección izquierda de la figura se aprecia el
SISTEMA y Figura 7. archivo de entrada con los campos respectivos a

Figura 7. Diagrama de Clases de Diseño


Figura 8. Enterprise Application Archive (EAR) del sistema.

<<EAR>>
VerificacionVehicularEAR

<<WAR>> <<JAR>>
VerificacionVehicular VerificacionEJBClient

<<JAR>>
VerificacionEJB


Ind. data 14(2), 2011 21



Figura 9. Visualización del código la clase VerificacionVehicularWS.


Figura 10. Archivo WSDL generado por el JAX-WS


22 Ind. data 14(2), 2011



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


enviar. En la sección derecha se observa el archivo número de peticiones por minuto, el cual cuantifica
de respuestas con los campos obtenidos produc- precisamente el rendimiento del aplicativo. Como se
to de la consulta. Los mencionados archivos viajan aprecia en la gráfica a mayor número de usuarios
por medio de la Web a través del protocolo HTTP y concurrentes el valor de “Rendimiento” va en au-
la definición del WSDL. mento, es decir el Web Service toma un mayor tiem-
po para procesar las solicitudes de consulta.
3. Prueba del servicio web
Todos los valores de la Tabla 2 son extraídos de las
“El objetivo de las pruebas, expresado de forma
pruebas y reflejan una unidad de medida de JMeter
sencilla, es encontrar el mayor número de errores
denominada latencia que se expresa en ms (mili-
con una cantidad razonable de esfuerzo, aplicado
segundos). En la Figura 13 se muestra la gráfica
sobre un lapso de tiempo realista” [6].
de evolución del rendimiento, lo cual refleja que a
En el párrafo anterior se definió las pruebas para un
sistema de información tradicional y que refleja el
enfoque de las pruebas del tipo funcional. Sin em-
Figura 12. Gráfico de las pruebas en la herramienta JMeter.
bargo, la prueba más crítica e importante para un
Web Service son las denominadas pruebas de es-
trés, las cuales someterán al servicio web a un nú-
mero determinado e incremental de invocaciones.
Lo que se busca primordialmente es evaluar la res-
puesta y desempeño del Web Service ante un ma-
yor número de consultas concurrentes. Por ello, se
utilizó la herramienta de testeo de software JMeter
especializada en pruebas para sistemas desarrolla-
dos bajo la tecnología J2EE.
En la Tabla 2 se muestra los datos de la simulación
del sistema, empezando por 10 usuarios hasta llegar
a los 10 000 con los incrementos como se aprecia
en la tabla. Además, JMeter arroja un resultado de-
nominado “Rendimiento” que se establece como el Fuente: The Apache Project [8].

Ind. data 14(2), 2011 23



Tabla 2. Cuadro de valores arrojados en las pruebas

Número de Rendimiento Media Mediana Desviación
usuarios (petición/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


Figura 13. Gráfico de rendimiento del Web Service.


mayor número de usuarios se requerirá un número elección correcta y viable al ser Open Source y
mayor de tiempo de procesamiento y se verá re- no tener la limitación de una licencia comercial.
flejado en la lentitud del sistema. Cabe mencionar, • El análisis y diseño mediante la notación UML
que un pico de incremento considerable se obtiene permitió un adecuado entendimiento del sistema
al variar de 5 000 a 7 000 usuarios. así como una clara documentación para modifi-
caciones o mantenimientos en el futuro.

4. CONCLUSIONES • Se garantiza la compatibilidad del Web Service
con los llamados de otros aplicativos desarro-
• El Web Service funcionó correctamente y su de- llados en diferentes lenguajes de programación,
sarrollo e implementación con las tecnologías debido a que se utilizó el protocolo SOAP y el
Java J2EE, EJB3, JAX – WS y JBoss fue una estándar XML para su implementación.

24 Ind. data 14(2), 2011



5. RECOMENDACIONES sociation for Computing Machinery - ACM Digital
Library. Disponible en: http://portal.acm.org/ci-
• La aplicación desarrollada fue puesta en pro-
tation.cfm?id=777335 (Visitado el 03/01/2011).
ducción en una importante central de riesgos
crediticios del país, del mismo modo se espera [3] Larman C. (2008). UML Y PATRONES – Una
que otras centrales lo implementen ya que im- introducción al análisis y diseño orientado a ob-
plica un negocio importante para ellos por ser jetos y al proceso unificado. 2.a ed. Pearson –
el SOAT un seguro obligatorio, debido a que las Prentice Hall, España.
compañías aseguradoras se ven en la obliga-
[4] Levvit J (2001), From EDI to XML and UDDI:
ción de comprobar la información brindada por
A brief history of Web Services, Information
sus clientes.
Week. Disponible en: http://www.information-
• Adicionalmente, las centrales de riegos deben week.com/news/development/tools/showArticle.
tener en cuenta los resultados de las pruebas jhtml?articleID=6506480 (Visitado el 03/01/2011).
realizadas en esta investigación y a modo de
[5] Mark D. Hansen (2007). SOA Using Java Web
recomendación se debería de configurar el
Services, First Edition, Prentice Hall, U.S.A.
servidor de aplicaciones JBoss para recibir un
máximo de 5000 usuarios concurrentes, ya que [6] Pressman R (2005). Ingeniería del Software –
hasta ese valor la aplicación trabaja con un buen Un enfoque práctico. 6.a ed. Mc Graw Hill, Es-
rendimiento. paña.
[7] Rumbaugh J. Jacobson I. Booch G (2007). El
lenguaje Unificado de Modelado, UML 2.0 – Ma-
6. Referencias bibliográficas
nual de Referencia. 2.a ed. Pearson, España.
[1] Clay W. Avondolio D. Schrager S. Mitchell M.
[8] The Apache Jakarta Project (2010). Building a
Scanlon J. (2007). Profesional Java JDK. 6.a ed.
Web Service Test Plan, Apache JMeter. Dis-
First Edition, Anaya Multimedia - WROX, Spain.
ponible en: http://jakarta.apache.org/jmeter/
[2] Ferris C, Farrell J. – IBM Research Triangle usermanual/build-ws-test-plan.html (Visitado el
Park, INC (2003). What are Web Services? As- 03/01/2011).

Ind. data 14(2), 2011 25

Web Service

Más contenido relacionado

Destacado (6)

Similar a Web Service (20)

Último (20)

Web Service