consumo de servicios web por medio de clientes java

1

CONSUMO DE SERVICIOS WEB POR MEDIO DE CLIENTES JAVA AUTOGENERADOS PARA LA EMPRESA ST&T L.T.D.A.

JUAN SEBASTIÁN CRUZ MORA

LILIANA JOHANA LOAIZA PULGARÍN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA

INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C.

2017

2

CONSUMO DE SERVICIOS WEB POR MEDIO DE CLIENTES JAVA AUTOGENERADOS PARA LA EMPRESA ST&T L.T.D.A.

JUAN SEBASTIÁN CRUZ MORA CÓDIGO: 20152678010

[email protected]

LILIANA JOHANA LOAIZA PULGARÍN CÓDIGO: 20152678019 [email protected]

TUTOR ING. MIGUEL ÁNGEL LEGUIZAMÓN PÁEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA

INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C.

2017

3

Nota de Aceptación

Tutor

Jurado

Bogotá D.C. 2017

4

ÍNDICE

RESUMEN ................................................................................................................................ 9

ABSTRACT ............................................................................................................................. 10

INTRODUCCIÓN .................................................................................................................... 11

1. FASE 1: PLANEAR ........................................................................................................... 12

1.1. TÍTULO .................................................................................................................... 12

1.2. TEMA ...................................................................................................................... 12

1.3. PLANTEAMIENTO DEL PROBLEMA ......................................................................... 12

1.3.1. DESCRIPCIÓN .................................................................................................. 12

1.3.2. FORMULACIÓN DEL PROBLEMA ..................................................................... 12

1.4. JUSTIFICACIÓN ....................................................................................................... 13

1.5. OBJETIVOS .............................................................................................................. 13

1.5.1. OBJETIVO GENERAL ........................................................................................ 13

1.5.2. OBJETIVOS ESPECÍFICOS ................................................................................. 13

1.6. ALCANCES............................................................................................................... 14

1.6.1. A NIVEL TÉCNICO ............................................................................................ 14

1.6.2. A NIVEL FUNCIONAL ....................................................................................... 14

1.7. DELIMITACIONES.................................................................................................... 15

1.7.1. TÉCNICA .......................................................................................................... 15

1.7.2. GEOGRÁFICA ................................................................................................... 15

1.7.3. TEMPORAL ...................................................................................................... 16

1.8. MARCO DE REFERENCIA ........................................................................................ 16

1.8.1. MARCO INSTITUCIONAL ................................................................................. 16

1.8.2. MARCO TEÓRICO ............................................................................................ 16

Estado del arte .......................................................................................................... 16

Metodología de Desarrollo ....................................................................................... 19

1.8.3. MARCO METOLÓGICO .................................................................................... 21

Planear (Plan)............................................................................................................ 21

Hacer (Do) ................................................................................................................. 22

Verificar (Check) ....................................................................................................... 22

Actuar (Act) ............................................................................................................... 22

5

1.9. FACTIBILIDAD ......................................................................................................... 22

1.9.1. FACTIBILIDAD TÉCNICA ................................................................................... 23

1.9.2. FACTIBILIDAD OPERATIVA .............................................................................. 23

1.9.3. FACTIBILIDAD ECONÓMICA ............................................................................ 23

1.9.4. FACTIBILIDAD LEGAL ....................................................................................... 24

1.10. CRONOGRAMA DE ACTIVIDADES ....................................................................... 25

2. FASE 2: HACER ............................................................................................................... 26

2.1. COMUNICACIÓN ENTRE SERVIDORES .................................................................... 26

2.1.1. JAVA RMI ........................................................................................................ 26

2.1.2. REST ................................................................................................................ 26

2.1.3. SERVICIOS WEB ............................................................................................... 26

2.2. COMPONENTES DE UN SERVICIO WEB .................................................................. 27

2.2.1. SERVIDORES .................................................................................................... 27

2.2.2. WSDL (Web Service Description Language) ................................................... 28

2.3. TECNOLOGÍAS DE SERVICIOS WEB......................................................................... 30

2.3.1. APACHE AXIS ................................................................................................... 30

2.3.2. JAX-WS ............................................................................................................ 30

2.4. CONSUMO DE SERVICIOS WEB .............................................................................. 31

2.4.1. HTTP CLIENT ................................................................................................... 31

2.4.2. JAX RPC ........................................................................................................... 32

2.4.3. SPRING WS ...................................................................................................... 32

2.5. AMBIENTE DE PRODUCCIÓN ................................................................................. 33

2.5.1. HEROKU (CLOUD) ........................................................................................... 33

2.5.2. ANGULAR JS .................................................................................................... 33

3. FASE 3: VERIFICAR ......................................................................................................... 34

3.1. PRIMER CICLO PHVA .............................................................................................. 34

Generación de cliente WSDL versión Axis - Datos nativos............................................ 34

Generación de cliente WSDL versión Axis - Retorno de “character” ............................ 38

Generación de cliente WSDL versión Axis - Objetos asociados a datos primitivos ...... 40

Generación de cliente WSDL versión Axis - Es Multitag Client ..................................... 42

Generación de cliente WSDL versión JBoss - Datos nativos ......................................... 44

Generación de cliente WSDL versión JBoss - Objetos de datos nativos ....................... 47

Generación de cliente WSDL versión JBoss - Objetos del modelo de negocio ............. 50

6

3.2. SEGUNDO CICLO PHVA .......................................................................................... 53

Combobox almacenando 10 URL o direcciones WSDL ................................................. 53

Opción de recordar formulario ..................................................................................... 56

Edición y eliminación de métodos y parámetros .......................................................... 58

Funcionamiento de botones de flujo ............................................................................ 64

4. FASE 4: ACTUAR............................................................................................................. 71

4.1. Implementación de WSProxyGenerator ................................................................ 71

4.2. Arquitectura de la Solución ................................................................................... 73

5. CONCLUSIONES ............................................................................................................. 74

6. BIBLIOGRAFÍA E INFOGRAFÍA ........................................................................................ 75

7

ÍNDICE DE TABLAS Tabla 1 Escenarios en el alcance a nivel técnico .................................................................. 14

Tabla 2 Descripción del ciclo PHVA ...................................................................................... 21

Tabla 3 Integrantes del proyecto.......................................................................................... 23

Tabla 4 Factibilidad económica – Recursos humanos .......................................................... 24

Tabla 5 Factibilidad económica – Recursos técnicos............................................................ 24

Tabla 6 Factibilidad económica – Costo total ....................................................................... 24

Tabla 7 Prefijos definidos en un WSDL ................................................................................. 29

8

ÍNDICE DE IMÁGENES Ilustración 1 Estado del arte ................................................................................................. 17

Ilustración 2 Ciclo Metodología PHVA .................................................................................. 19

Ilustración 3 Cronograma de actividades ............................................................................. 25

Ilustración 4 Pila de protocolos de los servicios web. .......................................................... 27

Ilustración 5 Comunicación entre un servicio web y un cliente a través de JAX-WS ........... 31

Ilustración 6 Arquitectura de Despliegue ............................................................................. 71

Ilustración 7 Interacción de WSProxyGenerator .................................................................. 72

Ilustración 8 Arquitectura de la Solución ............................................................................. 73

9

RESUMEN

Las empresas dedicadas a la prestación de servicios de tecnología, tales como desarrollo de software, infraestructura, redes informáticas, consultoría, entre otros, enfrentan la necesidad de optimizar todos los recursos posibles en la ejecución de sus procesos internos. De esta manera, se han convertido en pioneros en la actualización de los procedimientos y en un ejemplo para otras empresas que ejercen diferentes actividades. En el caso de la empresa ST&T (Software Telecommunications and Technology), parte del trabajo que debe realizar el personal, se ha concentrado en tareas repetitivas y extensas en la lectura de los documentos de lenguaje de descripción de servicios web (Web Services Description Language, en adelante WSDL) para la comunicación entre servidores, pues se utiliza una gran cantidad de servicios web, lo que implica la lectura de varios archivos. Incluso, algunos de estos WSDL exponen bastantes operaciones, lo que repercute en el tiempo de lectura manual por parte del personal. En vista de los inconvenientes que conllevan la ejecución de este proceso, el margen de error humano, el contenido extenso de los WSDL y el incremento en los tiempos, una herramienta de apoyo como WsProxyGenerator, encargada de la lectura y ejecución automática de componentes basados en la descripción del servicio web, resulta ser un mecanismo de vital importancia para contribuir en estas actividades y facilitar la comunicación entre servidores de aplicaciones, lo que genera un alto impacto en la calidad de código y la eficiencia de este proceso interno.

10

ABSTRACT

Companies engaged in the provision of technology services, such as software development, infrastructure, computer networks, consulting, among others, face the need to optimize all possible resources in the execution of their internal processes. In this way, they have become pioneers in updating the procedures and they are an example for other companies that carry out different activities. In the case of ST&T (Software Telecommunications and Technology), part of the work that must be performed by the staff, has concentrated on repetitive and extensive tasks at reading web services description language documents (hereinafter referred to as "WSDL") for communication between servers, since a large number of web services, which involves reading multiple files. Some of these WSDL even expose quite a few operations, which impacts on manual reading time by staff. In view of the disadvantages involved in the execution of this process, the human margin of error, WSDL extensive content and the increase in the time, a support tool like WsProxyGenerator, responsible for the automatic reading and execution of components based on the description of the web service, proves to be a vital mechanism to contribute to these activities and facilitate communication between application servers, which generates a high impact on the quality of code and the efficiency of this internal process.

11

INTRODUCCIÓN

Software Telecommunications and Technology (ST&T) es una empresa de desarrollo e integración de soluciones innovadoras en software ubicada en Bogotá. Soporta tecnologías como J2EE, Java, Java EE, PHP, Android, iOS, Cobol entre otros. Cuenta con más de 10 años de experiencia en el mercado de soluciones tecnológicas. La empresa en mención realiza desarrollos basados en la tecnología Java EE que generalmente funcionan sobre servidores JBoss, Apache Tomcat, GlassFish y WebSphere. Estas aplicaciones se construyen bajo una arquitectura multinivel, en la cual, la mayoría de aplicaciones utilizan los servidores JBoss, GlassFish y Apache Tomcat como servidores back-end, y los servidores WebSphere y Apache Tomcat como servidores front-end. La comunicación entre servidores se basa en el uso de servicios web que se definen en los servidores back-end y posteriormente son consumidos desde los servidores front-end por medio de los clientes proxy.

12

1. FASE 1: PLANEAR

1.1. TÍTULO

Consumo de servicios web por medio de clientes Java autogenerados para la empresa ST&T L.T.D.A.

1.2. TEMA

Comunicación entre servidores por medio de clientes de servicios web Java autogenerados a partir de una herramienta CASE desarrollada a la medida para la empresa ST&T L.T.D.A.

1.3. PLANTEAMIENTO DEL PROBLEMA

1.3.1. DESCRIPCIÓN

El desarrollo de aplicaciones para servidores bajo la arquitectura multinivel y multicapa es un estándar comúnmente utilizado por empresas de desarrollo de software. En ST&T los desarrolladores de estas aplicaciones se encargan de definir de forma manual los servicios web y los clientes proxy que facilitan la comunicación entre servidores. Sin embargo, el desarrollo de clientes proxy puede convertirse en una tarea complicada debido a la cantidad de métodos y servicios web que se exponen en un servidor. Un ingeniero de desarrollo deberá construir manualmente los clientes que permitirán el consumo de los servicios web, el desarrollo de estos clientes toma bastante tiempo del desarrollo de un proyecto. A pesar de que existen herramientas de autogeneración de código para el desarrollo de clientes de servicios web, el estándar de implementación de las mismas no cumple con la arquitectura solicitada por los clientes de ST&T. Adicionalmente se suma la dificultad de entendimiento del código autogenerado, lo que ocasiona como consecuencia que realizar una modificación sobre el código pueda convertirse en una tarea demasiado compleja.

1.3.2. FORMULACIÓN DEL PROBLEMA

¿De qué manera intercambiar información entre los componentes de aplicaciones web de la empresa ST&T L.T.D.A.?

13

1.4. JUSTIFICACIÓN

El desarrollo de una aplicación con Ingeniería de Software Asistida por Computadora (en adelante, herramienta CASE) capaz de interpretar los WSDL, permitirá a los ingenieros de desarrollo de ST&T la generación de clientes de forma automática que cumplan con los estándares de desarrollo, calidad y documentación de código propuestos por los clientes de la empresa. Si se compara con el procedimiento actual, la generación de estos nuevos clientes cumpliría con las normativas ya expuestas y adicionalmente el tiempo de generación sería mínimo. Esto permite enfocar los equipos de trabajo de la empresa en labores asociadas con la implementación de la lógica de negocio del cliente. La comunicación entre servidores es un requerimiento común de empresas como ST&T, el desarrollo de una herramienta CASE versátil que facilite la interacción entre servidores por medio de los servicios web y el protocolo SOAP (Protocolo Simple de Acceso a Objetos) representa una ventaja de mercado a nivel competitivo, puesto que el desarrollo de proyectos podrá darse con mayor eficacia y la empresa será capaz de desarrollar más trabajos en menos tiempo. La herramienta CASE contará con ventajas como: una mejor implementación de código autogenerado, que sea fácil de entender para un desarrollador común; la configuración de plantillas de salida de código autogenerado que permitirán la adición de código en los clientes proxy autogenerados; la creación automática de clases que representen los objetos expuestos en los servicios web tanto en formato XML (Lenguaje de Marcado Extensible) como en objeto Java; una fácil configuración de los puntos de acceso de un servicio web, como la dirección de los WSDL, el nombre del servicio y el puerto de conexión. Estas son algunas de las funcionalidades a disposición de los usuarios de la aplicación que brindarán una mejor calidad de desarrollo de software.

1.5. OBJETIVOS

1.5.1. OBJETIVO GENERAL

Comunicar los servidores que exponen servicios web por medio de clientes Java autogenerados para la empresa ST&T L.T.D.A.

1.5.2. OBJETIVOS ESPECÍFICOS

Identificar y documentar las características de los servidores que hacen uso de los servicios web para diseñar una herramienta CASE capaz de generar los clientes adecuados que permitan la comunicación entre servidores.

14

Implementar el diseño de la herramienta CASE teniendo en cuenta los estándares manejados por ST&T.

Certificar la comunicación entre servidores por medio de pruebas unitarias.

Identificar, documentar e implementar las mejoras que puede recibir el proyecto tanto en su documentación como en la herramienta CASE.

1.6. ALCANCES

1.6.1. A NIVEL TÉCNICO

La herramienta CASE desarrollada durante la ejecución de este proyecto soportará los siguientes escenarios, de acuerdo con la tecnología de servicios web y tipos de datos:

AXIS: tipos primitivos

JAX-WS: tipos primitivos y complejos

Con relación a los servicios web desarrollados bajo el framework Axis 1, la aplicación desarrollada permite la lectura y generación automática de métodos y propiedades cuyo tipo de dato es primitivo, es decir, aquellos que no son un objeto ni requieren invocación para ser creados (byte, int, bool, etc.) A diferencia de los WSDL basados en AXIS, aquellos desarrollados bajo JAX-WS 2 contienen un esquema que favorece la lectura y generación de clases por el efectivo acoplamiento con la herramienta WSImport 3, lo cual permite la cobertura para tipos primitivos y complejos.

Tabla 1 Escenarios en el alcance a nivel técnico

Tecnología de Servicios Web Tipos de datos soportados Ejemplo

AXIS Tipos primitivos int

JAX-WS Tipos complejos Proxy

Tipos primitivos byte Fuente: elaboración propia

1.6.2. A NIVEL FUNCIONAL

Este proyecto consiste en el desarrollo de una aplicación stand-alone para la lectura y generación de clases cuyos métodos y propiedades correspondan a las implementaciones expuestas en un servicio web, considerando el conjunto de protocolos y estándares utilizados para el intercambio de datos. El formato de dicho WSDL será definido por el usuario.

15

Si bien la complejidad del proyecto se encuentra en el back-end, se ha de presentar una vista que proporcione funcionalidad que le permita al desarrollador la personalización de las clases, métodos y propiedades (parámetros), lo cual podría contribuir con sus estándares de desarrollo y con políticas y directrices de la empresa o expresamente del proyecto base, es decir, aquel que hará uso de las clases generadas. El conjunto de clases generadas se almacenará en un directorio previamente definido por el usuario, lo que representa una reducción considerable en tiempos de desarrollo, convirtiéndose en una herramienta de apoyo para los procesos de desarrollo de software al interior de la compañía.

1.7. DELIMITACIONES

1.7.1. TÉCNICA Para el adecuado funcionamiento del sistema se debe cumplir con los siguientes requisitos:

Sistema Operativo Linux, Windows Vista/7/8/10.

Java Development Kit (JDK) jdk1.8.0_131.

Conexión a internet (opcional: depende de la ubicación del WSDL).

Dadas las características del proyecto, no se requiere de un servidor. Sin embargo, la conexión a internet es necesaria según el WSDL: si este se encuentra configurado en un servidor de aplicaciones alojado en la misma máquina donde se utilizará la aplicación stand-alone, entonces no se requerirá de conexión a internet. En caso contrario, se debe disponer de dicha conexión para obtener el formato sobre el cual se realizará la lectura y posterior generación de clases.

1.7.2. GEOGRÁFICA Este proyecto va dirigido a mejorar los procesos de desarrollo de software para las aplicaciones de la empresa ST&T L.T.D.A., la cual se encuentra ubicada en la ciudad de Bogotá, Colombia., por lo cual esta limitación se encuentra ligada al domicilio contractual en esta ciudad.

16

1.7.3. TEMPORAL Se plantea que el análisis, desarrollo e implementación del sistema propuesto para desarrollar esta herramienta de apoyo en ST&T L.T.D.A., se realice en un tiempo estimado de 6 meses.

1.8. MARCO DE REFERENCIA

1.8.1. MARCO INSTITUCIONAL

Quiénes Somos Somos una empresa de desarrollo e integración de soluciones innovadoras en software y telecomunicaciones, de gran proyección tecnológica, generando grandes beneficios a nuestros clientes. Contamos con una amplia experiencia y conocimiento en el área de datos móviles, dispositivos celulares y wireless modules, para lo cual se han desarrollado diferentes soluciones en áreas comerciales, de logística y transporte, encuestas, automatización y optimización de procesos y telecontrol entre otras.

Nos respaldan diferentes socios estratégicos que apoyan nuestras soluciones. 4

Misión Entregar a las empresas soluciones de Software y Hardware para Comunicaciones Móviles, Redes e Internet, permitiendo el manejo de información en línea y en tiempo real de sus procesos mediante aplicaciones a la medida.

Visión Ser una empresa líder en Soluciones de Software, Telecomunicaciones y Tecnología en Colombia y en el exterior.

1.8.2. MARCO TEÓRICO

Estado del arte El ambiente sobre el cual se basa este proyecto consiste en un servidor y un cliente (aplicación stand alone) que se comunican por medio de servicios web bajo el protocolo SOAP. El protocolo de comunicación que se utiliza es HTTP (protocolo de transferencia de hipertexto) en su método POST (verbo HTTP que envía los datos a

17

procesar a un recurso especificado) y la interpretación del servicio web se da mediante el WSDL.

Ilustración 1 Estado del arte

Fuente: elaboración propia

Existen herramientas que asisten la comunicación entre servidores que exponen servicios web, por medio de la interpretación y generación de un cliente automático a partir de un WSDL. Estas herramientas se basan en 2 componentes esenciales, el primer componente es el interpretador del WSDL y el segundo componente es el generador de código automático. En la Universidad Nacional de Colombia se desarrolló un proyecto titulado: “HERRAMIENTA PARA LA GENERACIÓN DEL CÓDIGO FUENTE PARA APLICACIONES CON ARQUITECTURA MODELO VISTA CONTROLADOR (MVC) BAJO DESARROLLO DIRIGIDO POR MODELOS TEXTUALES (MDD)”5. Este proyecto consiste en el desarrollo de una herramienta CASE que facilite el proceso de desarrollo de software por medio de una aplicación que proporcione el entorno de trabajo y la generación de código fuente de un proyecto bajo la arquitectura MVC basado en un meta modelo. Busca optimizar la productividad del equipo de desarrollo de software asegurando aspectos como la calidad, mantenibilidad y reutilización de componentes. El objetivo general del proyecto se centra en la construcción de una herramienta CASE que permita la generación automática de código fuente para aplicaciones con arquitectura modelo vista controlador teniendo en cuenta el desarrollo dirigido de modelos textuales. Los modelos textuales son lenguajes gramaticales que se configuran en una herramienta como XText dando como resultado final la generación automática de código; el proceso de generación automática de código se da por medio de Línea de Suscripción Digital, en adelante DSL.

18

La solución final del proyecto no cuenta con una limitación en el número de lenguajes de programación en los que se puede generar código automático. La metodología de desarrollo del proyecto se basa en 3 etapas. La primera etapa consiste en la comparación de las metodologías basadas en Desarrollo Dirigidos por Modelo (en adelante MDD), esto permite determinar el enfoque de trabajo investigativo a seguir y determinar las mejores prácticas de ingeniería de software a proyectar en la implementación del proyecto. La segunda etapa consiste en la elaboración de una herramienta lenguaje de dominio específico para la generación de aplicaciones con arquitectura MVC en donde el insumo es un modelo de base de datos relacional. La tercera etapa consiste en la ejecución de pruebas sobre la nueva herramienta en la que se verifica la funcionalidad y aplicabilidad del producto mediante la iteración de todo el proceso. A nivel de conclusiones se resalta el trabajo con MDD y DSL puesto a que puede ser parametrizable para dar soluciones generales. Por otra parte, se destaca el ahorro del esfuerzo humano y costos en la elaboración de un proyecto de software. También menciona la mejora de la curva de aprendizaje a nivel de los distintos lenguajes de programación. El proyecto anterior aporta sobre el presente proyecto el conocimiento de tecnologías que permiten la generación automática de código fuente a partir de meta modelos, cabe mencionar que en el proyecto actual estos meta modelos se encuentran intrínsecamente definidos en un WSDL, y por lo tanto pueden ser comprendidos y por medio de XText se puede generar la primera versión del código autogenerado. La segunda versión del código autogenerado del presente proyecto dependerá de las tecnologías de comunicación que se pretendan utilizar en los clientes autogenerados. En la Universidad Distrital Francisco José de Caldas se desarrolló un proyecto titulado: “SISTEMA TELEMÁTICO PARA CENTRALIZAR EL CONSUMO DE MENSAJERÍA XML SOBRE EL PROTOCOLO HTTP”. El proyecto consiste en el desarrollo de un sistema que facilite la integración de servicios web aplicando a la arquitectura orientada a servicios, que busca resolver el problema de una entidad financiera que tiene una gran cantidad de servicios web indocumentados y sin integrar que trabajan por medio de mensajería XML. El objetivo del proyecto consiste en el desarrollo de un sistema telemático utilizando la arquitectura SOA (Arquitectura Orientada a Servicios) que centralice el consumo de servicios web que exponen mensajería XML sobre el protocolo HTTP. Adicionalmente cuenta con objetivos específicos que hacen referencia al análisis, diseño, implementación y certificación de un sistema de integración orientado a servicios web.

19

El proyecto cuenta con una metodología de desarrollo denominada Top Down, en la que hacen énfasis en cómo esta metodología permite aterrizar los conceptos del desarrollo de un proyecto a nivel de ingeniería, teniendo en cuenta que la metodología no solo aporta conceptos, sino que también hace aportes a nivel de implementación. En las conclusiones del proyecto se enfatiza la integración de servicios como una tarea común en las áreas de desarrollo de una organización, también se hace referencia a diseño de soluciones en ambientes donde la información no está unificada por medio de la arquitectura orientada a servicios, adicionalmente destaca la importancia del manejo de los conceptos de integración que debe tener un ingeniero telemático. Este proyecto recibe un aporte importante del proyecto anterior, básicamente consiste en la adición de un concepto más que se da en la comunicación entre servidores, el concepto es la arquitectura SOA. Teniendo en cuenta lo anterior, en la etapa inicial de este proyecto se hará mención del aporte de la herramienta CASE para los proyectos realizados por la empresa, los cuales hacen uso de la arquitectura SOA.

Metodología de Desarrollo La metodología a utilizar es PHVA (Planificar, Hacer, Verificar, Actuar): Este ciclo (planificar-hacer-verificar-actuar) también conocido como PDCA (plan-do-check-act) es un modelo de cuatro pasos para llevar a cabo el desarrollo de un proyecto. Al igual que los círculos no tiene un final, el ciclo PHVA podría ser repetido nuevamente para una mejora continua. 6

Ilustración 2 Ciclo Metodología PHVA


20

Al ser un ciclo continuo, no se detendrá el trabajo del ciclo PHVA una vez se haya alcanzado la meta. En su lugar, se repite el procedimiento mediante los siguientes pasos:

Planear (Plan) La fase planear es realmente un proceso de dos pasos. El primer paso consiste en la identificación y definición de un problema existente sin un proceso. El segundo paso envuelve el análisis de este problema. Durante estos dos procesos, muchas herramientas y pasos serán necesarios. Entre ellos están:

Determinar la causa principal del problema. Determinar las intervenciones necesarias para corregir el problema. Determinar cuáles son las salidas esperadas. Determinar quiénes serán las partes responsables para la mejora del

problema. Programar los pasos de la corrección. Planificar los recursos. Justificar la necesidad de la mejora. Determinar las métricas para la mejora. Realizar el mapeo de procesos utilizando Flow chart o alguna otra

herramienta. Recolectar cualquier dato relacionado con el problema.

Hacer (Do) Una vez el plan ha sido creado, el documento de alcance de proyecto ha sido firmado, y se ha definido el calendario, es tiempo de ejecutar el plan. Durante esta fase, una solución será:

Implementación en un modo de pruebas. Revisión continua (ver el siguiente paso) por eficiencia. Implementación permanente (si el intento es exitoso). Medida de desempeño. Capacitación de los empleados en mejoramiento de calidad.

Verificar (Check) Una vez la implementación de la solución comience utilizando la metodología de mejoramiento de PHVA, se hará un seguimiento de esta solución con el tiempo y se

21

tomará un tiempo para comparar la calidad del producto o servicio antes y después de la implementación. Para ello se deben responder las siguientes preguntas:

¿La implementación de un cambio alcanzó los resultados esperados? ¿La implementación del cambio trabajó bien? ¿Qué no funcionó? ¿Qué se aprendió de la implementación?

Actuar (Act) Una vez el plan funcione, es momento de estandarizar el proceso de mejora e implementación a través de las prácticas de negocio. Durante esta fase final es necesario:

Identificar cualquier necesidad de formación para la implementación de cualquier mejora.

Adoptar completamente el proceso de solución para el proceso de mejora. Continuar mejorando la solución. Revisar si no se puede mejorar la implementación a través de soluciones

adicionales. Buscar otras oportunidades para la mejora.

Tabla 2 Descripción del ciclo PHVA

Fase Descripción

Planear Se establecen objetivos y se identifican procesos.

Hacer Implementación de los cambios o acciones requeridas.

Verificar Durante un periodo de prueba, se valora la eficiencia de los cambios realizados.

Actuar Si los resultados no son los esperados, se realizan correcciones. Fuente: elaboración propia

1.8.3. MARCO METOLÓGICO

El desarrollo de este proyecto se basará en el ciclo de la metodología PHVA, que brinda las fases necesarias para la culminación de un proyecto de telemática.

Planear (Plan) El problema que se presenta en ST&T consiste en la falta de estándares y tiempo de implementación de un cliente que facilite la comunicación entre servidores. Para empezar

22

a dar solución al problema se iniciará con un estudio documentado acerca de los servicios web y sus características. Adicionalmente se estudiarán los servidores y tecnologías que son capaces de ofrecer servicios web.

Por otra parte, se realizará un análisis técnico de requerimientos que consiste en identificar el estándar de implementación de clientes de la empresa. De acuerdo con lo anterior se podrá comprender la arquitectura manejada por la empresa y así se podrá definir el diseño de una herramienta CASE capaz de satisfacer los requerimientos de la empresa ST&T.

Hacer (Do) Se desarrollará la herramienta CASE teniendo en cuenta la documentación de servicios web y los estándares identificados en ST&T. Se definirán dos fases de desarrollo para elaborar la herramienta CASE, la primera consiste en una aplicación básica en la consola de comandos CMD, que recibirá insumos de entrada tales como el WSDL y la carpeta de salida con los cuales se encargará de generar automáticamente el cliente de servicio web, la segunda fase consistirá en el desarrollo de una interfaz gráfica que capture los valores de entrada y los envíe a la terminal para la generación del cliente.

Verificar (Check) Las pruebas de la herramienta CASE se realizarán en el ambiente laboral de ST&T debido a que allí se encuentran los servicios web indicados para probar el funcionamiento de la herramienta. Se deben verificar aspectos importantes tales como que la herramienta genere un cliente con todos los métodos expuestos del servicio web, adicionalmente se debe validar que los mapeos de cada variable de entrada y salida sean correctos, y por último para las variables de tipo objeto se debe revisar que el mapeo de clases se haya hecho adecuadamente.

Actuar (Act) Se realizará una reunión con el dueño de la empresa para certificar el funcionamiento de la herramienta con el fin de poder identificar posibles mejoras sobre la misma. En tal caso de que exista alguna mejora, se ejecutará nuevamente el ciclo PHVA para llevar a cabo correctamente la implementación de dicha mejora.

1.9. FACTIBILIDAD

El desarrollo del proyecto tiene una factibilidad alta puesto que a nivel técnico se necesita realizar un estudio acerca del funcionamiento de los servicios web, el cual se complemente con el desarrollo de una herramienta CASE que genere el código automático necesario para realizar la comunicación entre servidores; a nivel operativo el desarrollo del proyecto se basa en la identificación de características de un servicio web que se da por medio del estudio a nivel técnico; la factibilidad económica es viable debido a que solo es necesario un computador de gama media con acceso a internet y dos estudiantes de Ingeniería en Telemática; a nivel legal el desarrollo del proyecto no tiene ninguna restricción puesto que se hará uso de herramientas de software libre que permitan alcanzar el objetivo.

23

1.9.1. FACTIBILIDAD TÉCNICA

A nivel técnico el desarrollo del proyecto es viable puesto que es necesario un par de equipos de cómputos (proporcionados por la empresa), dos estudiantes de Ingeniería en Telemática y una oficina con conexión a internet. La empresa apoyará el desarrollo con una definición de tiempo de trabajo, es decir, medio tiempo de trabajo será dedicado al negocio de la empresa y medio tiempo será dedicado al desarrollo del presente proyecto. Es importante mencionar que la información base para el desarrollo del presente proyecto puede ser consultada por internet de forma gratuita.

1.9.2. FACTIBILIDAD OPERATIVA

A nivel operativo el desarrollo del proyecto es viable puesto que la puesta en marcha del mismo resuelve varias necesidades de la empresa como, por ejemplo: un mejor tiempo de desarrollo de proyectos que requieran comunicación entre servidores, una mejor implementación de estándares de calidad de código, una curva de aprendizaje de servicios web más elevada para los desarrolladores nuevos que aprendan a utilizar la herramienta. Adicionalmente quedará un documento detallado que permita la comprensión de los servicios web, y que explique cómo funciona la herramienta.

Tabla 3 Integrantes del proyecto

Nombre Función

Miguel Ángel Leguizamón Páez Tutor del Proyecto

Juan Carlos Lozano Lozano Director Externo

Liliana Johana Loaiza Pulgarín Ejecutor del Proyecto

Juan Sebastián Cruz Mora Ejecutor del Proyecto Fuente: elaboración propia

1.9.3. FACTIBILIDAD ECONÓMICA

A nivel económico el desarrollo del proyecto es viable puesto que su factibilidad económica se basa en el costo laboral de un estudiante de Ingeniería Telemática y un computador de gama con conexión a internet. Estos costos serán asumidos por la empresa y el estudiante. A continuación, se presentan unas tablas que indican un estimado de costos totales del proyecto, entre ellos está el talento humano y equipos de cómputo.

24

Tabla 4 Factibilidad económica – Recursos humanos

Tipo Descripción Valor-Hora

Cantidad Total

Tutor 1 Asesorías para la realización del proyecto, referente a la metodología.

$ 150.000 2 horas semanales

$ 7’200.000

Desarrolladores

Un desarrollador de software que realice la implementación de la solución.

$ 70.000 18 horas semanales

$ 30’240.000

Total Costos Talento Humano $ 37.440.000


Aquí se presentan las asesorías que se tendrán y los gastos del desarrollador. A continuación, en la siguiente tabla se presentarán los gastos de los recursos que se ostentan en el desarrollo del proyecto.

Tabla 5 Factibilidad económica – Recursos técnicos

Recurso Descripción Valor Unitario Cantidad Total

Laptop Equipos de escritorio para el desarrollo y las pruebas del sistema.

$ 2.500.000 1 $ 2’500.000

Internet Fuente de información $ 130.000 / mes 1 $ 780.000

Total Recursos Técnicos $ 3’280.000


Adicionalmente se muestran los gastos adicionales en la Tabla 3 que serán solventados por desarrolladores del proyecto.

Tabla 6 Factibilidad económica – Costo total

Recurso Valor

Total Talento Humano $ 37’440.000

Total Recursos Técnicos $ 3’280.000

Total Otros recursos $ 100.000

Costos imprevistos (5%) $ 2’041.000

TOTAL COSTO $42’861.000 Fuente: elaboración propia

1.9.4. FACTIBILIDAD LEGAL

La documentación del presente proyecto se encontrará debidamente referenciada para indicar el origen de la fuente de información. El desarrollo de la herramienta CASE se hará en el lenguaje de programación Java que es de libre uso y se encuentra bajo la licencia pública general GNU. La empresa cuenta con las licencias de software privativo tales como el paquete de office de Microsoft y el entorno de desarrollo de software como Rational de IBM.

25

1.10. CRONOGRAMA DE ACTIVIDADES

Ilustración 3 Cronograma de actividades


26

2. FASE 2: HACER

2.1. COMUNICACIÓN ENTRE SERVIDORES

Un servidor de aplicaciones es un software que proporciona un ambiente de ejecución para aplicaciones desarrolladas a la medida. Estas aplicaciones se encargan de gestionar las funciones de lógica de negocio y de acceso a los datos de la aplicación. El ambiente de ejecución de las aplicaciones se encuentra basado en el modelo de Sistema Distribuido, el cual se define como un conjunto de servidores que se encuentran conectados entre sí para ofrecer servicios a los usuarios. La comunicación entre estos servidores puede darse de diferentes formas, básicamente por medio de frameworks o tecnologías que obedecen el modelo cliente servidor. 7 Entre los frameworks o tecnologías que facilitan la comunicación entre servidores, se encuentran:

2.1.1. JAVA RMI

(Remote Method Invocation). Es una tecnología propia de Java, que permite a una máquina virtual de Java la ejecución de métodos de un objeto que se encuentra en ejecución en otra máquina virtual. Es utilizada para la comunicación entre máquinas virtuales de java. Las máquinas virtuales de Java pueden encontrarse en algunos de los servidores que componen el Sistema Distribuido. 8

2.1.2. REST

Se define como una tecnología de servicios orientados a la manipulación de recursos de servidor por medio del protocolo HTTP. En un servicio REST típico se tiene que cada recurso expuesto se gestiona de acuerdo con el método utilizado en el protocolo HTTP (GET, POST, PUT, DELETE). 9

2.1.3. SERVICIOS WEB

Se define como una tecnología que utiliza un conjunto de protocolos y estándares para llevar a cabo el intercambio de información entre un cliente y un servidor. El servicio web expone su lógica de negocio por medio de interfaces de acceso.

27

Entre los protocolos en los que se basa el funcionamiento de los servicios web están:

Ilustración 4 Pila de protocolos de los servicios web.

Fuente: http://www.ehu.eus/mrodriguez/archivos/csharppdf/ServiciosWeb/WebServices.pdf

2.2. COMPONENTES DE UN SERVICIO WEB

2.2.1. SERVIDORES

Apache Tomcat El servidor Apache Tomcat es un contenedor de aplicaciones web basado en Java. Es de código abierto creado y fue creado para ejecutar aplicaciones web servlet y JSP (Java Server Pages). Aunque su creación fue bajo el proyecto Apache-Jakarta, su popularidad en la comunidad de Java lo llevó a alojarse en un proyecto aparte. Apache es muy estable y contiene diversas características que proveen funcionalidad adicional, lo cual le convierte en una muy buena opción para una solución completa de desarrollo de software. Su compatibilidad con la máquina virtual de java (JVM) depende de la versión seleccionada. 10

JBoss Muchos de los servidores de aplicaciones comerciales y de código abierto que existen en el mercado, permiten a los desarrolladores ejecutar aplicaciones compatibles con Java EE. En este mercado, JBoss es considerada una solución “líder” de código abierto adoptada por los desarrolladores.

http://www.ehu.eus/mrodriguez/archivos/csharppdf/ServiciosWeb/WebServices.pdf

28

Aunque es difícil brindar una cifra exacta, es probable que sea el servidor de aplicaciones más utilizado en el mercado.

2.2.2. WSDL (Web Service Description Language)

El documento de lenguaje de descripción de servicio web (WSDL) es un documento XML que se publica en la red por medio de un servidor de aplicaciones. En este XML se definen la cantidad de servicios expuestos, los métodos y tipos de datos publicados por el servidor. Cuenta con las secciones “wsdl:service”, “wsdl:binding”, “wsdl:portType”, “wsdl:message” y “wsdl:types”.

En la sección “wsdl:service” se define el nombre de los servicios publicados por el servidor. Cada etiqueta contiene uno o varios puertos de conexión definidos como “wsdl:port”, los cuales contienen una URL que permite el consumo del servicio web, así mismo ésta etiqueta tiene una asociación hacia la etiqueta “wsdl:binding” por medio del atributo “wsdl:port@binding”.

La sección “wsdl:binding” define los detalles del formato y protocolo de los mensajes definidos por un “wsdl:portType” en particular. Por cada uno se realiza una asociación directa hacia un “wsdl:portType” por medio del atributo “type”. En esta sección se definen las operaciones publicadas en el documento, por cada operación se definen una entrada, una salida y una sección de fallas, las cuales se encuentran asociadas a “wsdl:input”, “wsdl:output” y “wsdl:fault” respectivamente. Las tres secciones mencionadas anteriormente definen la codificación que será utilizada en el mensaje. Un WSDL puede contener varios “wsdl:binding”, cada uno con un nombre único por documento.

La sección “wsdl:portType” contiene un conjunto de operaciones abstractas. Estas operaciones hacen referencia a los métodos de un servicio web expuestos. Por cada operación hay cuatro tipos de transmisión:

One-Way: El endpoint recibe un mensaje. Request-response: El endpoint recibe un mensaje y envía un mensaje

correlacionado. Solicit-response: El endpoint envía un mensaje y recibe un mensaje

correlacionado. Notification: El endpoint envía un mensaje.

Así mismo cada operación (“wsdl:operation”) de la sección “wsdl:portType”, contiene una entrada, salida y mensaje de error. Los tags asociados son “wsdl:input”, “wsdl:output” y “wsdl:fault” respectivamente. Las etiquetas mencionadas tienen la misma estructura que las etiquetas de la sección

29

“wsdl:binding”, se diferencian en que por medio del atributo “message” se asocian a la sección “wsdl:message” del documento. La sección “wsdl:message” consiste en una o más partes lógicas. Cada parte está asociada con un tipo de operación (entrada, salida, error). Cada etiqueta define los tipos de datos que interactúan en la comunicación cliente servidor. La sección “wsdl:message” contiene una o varias secciones “wsdl:part” las cuales se encuentran asociadas a la sección “wsdl:type”. La sección “wsdl:type” hace referencia a los tipos de datos publicados en las operaciones expuestas, es decir, los parámetros requeridos para el adecuado funcionamiento de las operaciones definidas en el WSDL. En esta etiqueta se define el tipo de dato del parámetro seguido de su codificación. Junto a “wsdl:type” se encuentra “wsdl:name”, el cual indica el nombre del parámetro. De la manera anteriormente definida, se lleva a cabo la lectura del WSDL para obtener los servicios expuestos, las operaciones, tipos de datos y codificación publicados por el servidor. Notaciones de los Servicios Web

Tabla 7 Prefijos definidos en un WSDL

Prefijo Namespace URI Definición

Wsdl http://schemas.xmlsoap.org/wsdl/ Nombre único del WSDL para el marco de trabajo (framework) del WSDL.

Soap http://schemas.xmlsoap.org/wsdl/soap/ Nombre único del WSDL para el enlace WSDL SOAP.

http http://schemas.xmlsoap.org/wsdl/http/ Nombre único del WSDL para el enlace HTTP GET & POST.

Mime http://schemas.xmlsoap.org/wsdl/mime/ Nombre único del WSDL para el enlace MIME.

soapenc http://schemas.xmlsoap.org/soap/encoding/ Nombre único para la codificación definida por SOAP 1.1.

soapenv http://schemas.xmlsoap.org/soap/envelope/ Nombre único para la codificación definida por SOAP 1.1.

Xsi http://www.w3.org/2000/10/XMLSchema-instance

Nombre único de una instancia definida por un XSD.

Xsd http://www.w3.org/2000/10/XMLSchema Nombre único del esquema definido por el XSD.

tns (various) El prefijo “this namespace” (tns) es utilizado como una

30

convención para referirse al documento actual.

(other) (various) Todos los otros prefijos de nombres únicos son solamente ejemplos. En particular, las URIs que comienzan con “http://example.com” representan alguna dependencia de aplicación o contexto dependiente de URI.

Fuente: Tomado de 11

2.3. TECNOLOGÍAS DE SERVICIOS WEB

2.3.1. APACHE AXIS Este Sistema de interacción extensible de Apache (por sus siglas en inglés “Apache Extensible Interaction System”) es uno de los proyectos de servicios web de Apache, el cual provee un conjunto de librerías para la conversión de interfaces Java y descripciones del WSDL, y viceversa. Proporciona un manejador de invocaciones del lado del cliente y del servidor, y es útil para el monitoreo de peticiones SOAP. 12 Axis es considerado un framework que surge como implementación del protocolo SOAP. Ha demostrado ser una base confiable y estable en la cual se puede implementar servicios web desarrollados en Java, formando una comunidad de usuarios muy activa con muchas empresas que utilizan Axis para el soporte de servicios web en sus productos. Para su utilización, basta con descargar Axis del sitio oficial y copiar los archivos en el directorio de Eclipse y crear un nuevo proyecto Java que incluya las dependencias de Axis, desarrollar el código requerido, compilar y publicar en el directorio de Tomcat.

2.3.2. JAX-WS

Significa “Api de Java para servicios web XML”. Es una tecnología para la construcción de servicios web y clientes que se comunican utilizando XML. Con JAX-WS, una invocación de una operación a un servicio web se representa con un protocolo basado en XML, como por ejemplo SOAP, donde se define la estructura o formato del mensaje, las reglas de codificación y las convenciones para representar invocaciones y respuestas del servicio web. Dichas llamadas y respuestas se transmiten como mensajes SOAP (ficheros XML) mediante el protocolo HTTP.

http://axis.apache.org/axis/

31

Aunque los mensajes SOAP se caracterizan por complejidad, el api JAX-WS se encarga de ocultar dicha complejidad al desarrollador de la aplicación. En lo relacionado al servidor, el desarrollador especifica las operaciones del servicio web cuando codifica los métodos en una interfaz escrita en lenguaje Java. También codifica una o más clases que implementan dichos métodos. Por otra parte, los programas cliente también son fáciles de codificar, pues un cliente crea un “proxy” (objeto local que representa el servicio) y a continuación invoca los métodos sobre el proxy. Con JAX-WS, el desarrollador no necesita generar o "parsear" mensajes SOAP, dado que el runtime de JAX-WS convierte las llamadas y respuestas del API en y desde los mensajes SOAP. La siguiente figura muestra la interacción entre un cliente y un servicio web a través de JAX-WS.

Ilustración 5 Comunicación entre un servicio web y un cliente a través de JAX-WS

Fuente: Servicios Web y SOA, disponible en http://www.jtech.ua.es/j2ee/publico/servc-web-2012-

13/wholesite.pdf

En este apartado aparece un concepto denominado JAXB, parte de la plataforma Java SE que hace referencia a la arquitectura en Java para “XML Binding (JAXB)”. Permite a los desarrolladores Java asignar clases de Java a representaciones XML y proporciona dos características principales: la capacidad de serializar las referencias de objetos Java a XML y la inversa, es decir, deserializar XML en objetos Java. JAXB permite almacenar y recuperar datos en memoria en cualquier formato XML, y no requiere la implementación de un conjunto específico de métodos de carga y guardado de XML para la estructura de clases del programa.

2.4. CONSUMO DE SERVICIOS WEB

2.4.1. HTTP CLIENT HTTP es un protocolo de transferencia de hipertexto utilizado masivamente para los servicios en internet. Dentro de su aplicación, se encuentra la utilidad en los servicios web, proporcionándole un aumento en el papel del protocolo HTTP más allá de los navegadores web orientados al usuario.

http://www.jtech.ua.es/j2ee/publico/servc-web-2012-13/wholesite.pdf

http://www.jtech.ua.es/j2ee/publico/servc-web-2012-13/wholesite.pdf

32

Pese a que java.net proporciona funcionalidad para el acceso a los recursos mediante este protocolo, carece de flexibilidad y cobertura para muchas aplicaciones. En vista de esta condición, aproximadamente en 2001 surge el componente HttpClient como un subproyecto de “Jakarta Commons”, el cual propende por brindar un paquete más actualizado, cumpliendo con los estándares y recomendaciones del protocolo HTTP. Este componente se adapta a diferentes soluciones y puede ser utilizado en diversas aplicaciones, pues se caracteriza por su robustez y eficiencia en clientes compatibles con HTTP. 13

2.4.2. JAX RPC

Es un API de Java para la “Llamada de procedimiento remoto” basada en XML, la cual brinda soporte en la interoperabilidad y accesibilidad de los servicios web. Se utiliza en diversas aplicaciones para el desarrollo y consumo de servicios web, permitiéndole a un cliente JAX-RPC comunicarse con otro servicio web que ha sido desplegado en otro servidor o plataforma, inclusive, en un lenguaje de programación diferente. JAX-RPC también define la correlación entre descripciones de los WSDL e interfaces Java. Su definición y funcionalidad ocultan la complejidad de los protocolos subyacentes y del procesamiento de mensajes para los desarrolladores de aplicaciones que elaboran servicios web basados en Java 2. Al combinar el api con RPC (Remote Procedure Call), se obtiene un mecanismo que facilita a los clientes la ejecución de tareas en ambientes distribuidos o remotos, y que los desarrolladores puedan crear servicios web. Las llamadas de JAX-RPC se representan por un XML y se transfieren mediante la capa de “transporte de red”. Su implementación actual se basa en el protocolo SOAP 1.1 y en el transporte de red HTTP 1.1. 14

2.4.3. SPRING WS “Spring Web Services” es un producto de la comunidad de Spring que se ha enfocado en la creación de servicios web basados en documentos. El objetivo principal de Spring Web Services es facilitar el desarrollo de los servicio SOAP, permitiendo la creación de servicios web flexibles que hacen uso de una de las diversas maneras de manipular cargas XML. El producto se basa en el framework de Spring de Java, ampliamente utilizado en el desarrollo de aplicaciones. Lo anterior significa que se pueden utilizar los conceptos de Spring, tales como la inyección de dependencias como parte integral de su servicio web.

33

Los desarrolladores utilizan Spring-WS por diversas razones, en su mayoría, relacionadas a encontrar pilas SOAP de las que se carece en los intentos de trabajar con las mejores prácticas de servicio web. Spring-WS hace de la mejor práctica una práctica fácil, lo cual incluye prácticas como el perfil básico de WS-I, el desarrollo de implementaciones de contratos, y el tener un acoplamiento bajo entre el contrato y la implementación. 15

2.5. AMBIENTE DE PRODUCCIÓN

2.5.1. HEROKU (CLOUD) Heroku es una plataforma en la nube que le proporciona a sus clientes (empresas) la facilidad de crear, entregar, monitorizar y escalar aplicaciones, evitando una gran variedad de problemas de infraestructura. Su enfoque se encuentra en las aplicaciones y la experiencia del desarrollador en torno a las mismas, factor que contribuye a los procesos de empresas de todos los tamaños sin la necesidad de tratar con asuntos relacionados al hardware (especialmente servidores). Los servicios que provee esta plataforma conllevan a que los procesos de despliegue, configuración, escalado, ajuste y administración de aplicaciones, se conviertan en labores sencillas, de tal manera que los ingenieros de desarrollo se concentren en lo más relevante: la creación de aplicaciones óptimas para la satisfacción de los requerimientos del cliente. 16

2.5.2. ANGULAR JS Angular JS es un framework de Javascript de código abierto desarrollado por la compañía Google. Se basa en el patrón de arquitectura de software MVC (Modelo, Vista, Controlador). Su funcionalidad se aplica directamente sobre el HTML (Lenguaje de Marcado para Hipertextos) nativo el cual recibe una adición de funcionalidades por medio de directivas (conector entre la vista y el controlador). La comunicación entre el modelo y el controlador se lleva a cabo por medio de servicios REST en conjunto con los objetos JSON. 17

34

3. FASE 3: VERIFICAR

El entorno de pruebas consiste en la evaluación de los WSDL:

[http://localhost:8082/InventoryAxisWS/services/InventoryWS_Axis?wsdl]

[http://localhost:8082/InventoryWS/InventoryWS_JBoss?wsdl].

InventoryWS_Axis.w

sdl

InventoryWS_JBoss.

wsdl

3.1. PRIMER CICLO PHVA

Durante este ciclo se ejecutaron casos de prueba sobre el desarrollo inicial de la herramienta CASE.

Generación de cliente WSDL versión Axis - Datos nativos ID Prueba

Módulo Prueba Unitaria

Julio 31, Agosto 4

01 ws-proxy-generator

No se define el atributo char del método datosPrimitivos1 en la clase final.

Ambiente de pruebas para ejecución

Ambiente Aplicado

Desarrollo X

Pruebas

Precondiciones para la ejecución de los escenarios de prueba Servicios web o documentos WSDL con permisos de acceso para la aplicación.

Errores de respuesta

Resultado esperado Tipo

Funcional Estructural

La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa. Se debe evaluar que los métodos del archivo generado cumplan con el nombre y el tipo de dato especificado.

X

Datos de prueba

Entradas Datos

WSDL http://localhost:8082/InventoryAxisWS/services/MusicInventoryService?wsdl

Directorio de Salida D:\pruebas-ws-proxy-generator

Paquete co.com.stt.proxy.inventoryaxis

Is Multitag Client false

Registro de pantallas evidenciando los hallazgos

35

Se configura el método [datosPrimitivos1] del WSDL con los siguientes parámetros:

Se publica el WSDL en:

Se ingresan los datos en la aplicación y se presiona el botón [Cargar WSDL]:

La aplicación muestra el mensaje “Proxy generado en D:\

-ws-proxy-generator”:

36

Se revisa el directorio de salida:

Se revisa el contenido del archivo MusicInventoryServicePort.java y no se evidencia el atributo char1 especificado en el método datosPrimitivos1

38

Generación de cliente WSDL versión Axis - Retorno de “character” ID Prueba


Julio 31, Agosto 4


Ninguna Observación


Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa. El método returnChar debe cargar adecuadamente.

X

Datos de prueba

Entradas Datos






Se configura el método [returnChar] del WSDL con los siguientes parámetros:

Se registran los datos en la aplicación:

39

El método “returnChar” se carga adecuadamente con los valores definidos en el WSDL:

40

Generación de cliente WSDL versión Axis - Objetos asociados a datos primitivos ID Prueba


Julio 31, Agosto 4




Ambiente Aplicado

Desarrollo X

Pruebas

Precondiciones para la ejecución de los escenarios de prueba Servicios web o documentos WSDL con permisos de acceso para la aplicación




La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa El método “variables” debe cargar adecuadamente

X

Datos de prueba

Entradas Datos






Se define el método [variables] bajo la tecnología Apache Axis:

Se registran los datos en la aplicación:

41

El método “variables” se carga adecuadamente con los valores definidos en el WSDL:

42

Generación de cliente WSDL versión Axis - Es Multitag Client ID Prueba


Julio 31, Agosto 4




Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa La sección isMultitagClient debe ser cargada en el archivo final del cliente proxy

X

Datos de prueba

Entradas Datos






Se registran los datos en la aplicación asegurándose que el tag [Is Multitag Client] está seleccionado:

43

La sección [isMultitagClient] se carga adecuadamente con los valores definidos en el WSDL:

La sección se carga adecuadamente en el proxy generado

44

Generación de cliente WSDL versión JBoss - Datos nativos ID Prueba


Julio 31, Agosto 4




Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa Se debe evaluar que los métodos del archivo generado cumplan con el nombre y el tipo de dato especificado.

X

Datos de prueba

Entradas Datos

WSDL http://localhost:8082/InventoryWS/MusicInventoryService?wsdl

Directorio de Salida D:\WSProxyGenerator-Pruebas

Paquete co.com.stt.inventoryws



Se configura el método [datosPrimitivos1] bajo la tecnología JAXWS:

Se valida publicación del servicio utilizando el navegador:

45

Se cargan los datos en la aplicación y se presiona el botón [Cargar WSDL]:

Se revisa el directorio [D:\WSProxyGenerator-Pruebas] de generación de archivo:

46

El método [datosPrimitivos1] se generó correctamente

47

Generación de cliente WSDL versión JBoss - Objetos de datos nativos ID Prueba


Julio 31, Agosto 4




Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa Los valores del método [variables] deben cargarse adecuadamente de acuerdo con su definición original.

X

Datos de prueba

Entradas Datos






Se configura el método [variables] bajo la tecnología JAXWS:


48



49

El método [variables] se generó correctamente.

50

Generación de cliente WSDL versión JBoss - Objetos del modelo de negocio ID Prueba


Julio 31, Agosto 4




Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación genera los respectivos archivos y, los mismos compilan adecuadamente en el ambiente de la empresa Los valores del método [insertGuitar] se deben cargar adecuadamente:

X

Datos de prueba

Entradas Datos






Se configura el método [variables] bajo la tecnología JAXWS:


51



52

El método [insertGuitar] se generó correctamente.

53

3.2. SEGUNDO CICLO PHVA

Para este segundo ciclo se llevaron a cabo algunas mejoras y correcciones sobre lo desarrollado en el primer ciclo, tales como la ventana de visualización de estructura y la de vista previa. Adicionalmente se realizaron ajustes a la principal, reemplazando la caja de texto del WSDL por un combo para desplegar una lista con las últimas 10 entradas (dicho valor puede ser modificado por el usuario mediante archivo de configuración “config.properties”).

Combobox almacenando 10 URL o direcciones WSDL ID Prueba


Septiembre 5, Septiembre 8




Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación alamacena en sus archivos de configuración hasta 10 direcciones de WSDL

X

Datos de prueba

Entradas Datos

WSDL D:\WSProxyGenerator-Pruebas\input\Example _1.wsdl D:\WSProxyGenerator-Pruebas\input\Example.wsdl

D:\WSProxyGenerator-Pruebas\input\InventoryAxisWS.wsdl D:\WSProxyGenerator-Pruebas\input\InventoryAxisWS_1.wsdl

D:\WSProxyGenerator-Pruebas\input\InventoryJaxWS.wsdl D:\WSProxyGenerator-Pruebas\input\InventoryJaxWS_1.wsdl

D:\WSProxyGenerator-Pruebas\input\ServiceTripImpl.wsdl D:\WSProxyGenerator-Pruebas\input\ServiceTripImpl_1.wsdl

D:\WSProxyGenerator-Pruebas\input\UserService.wsdl D:\WSProxyGenerator-Pruebas\input\UserService_1.wsdl

http://localhost:8082/InventoryWS/MusicInventoryService?wsdl http://localhost:8082/InventoryAxisWS/services/MusicInventoryService?wsdl





Se definen 10 WSDL iniciales:

54

Se valida la existencia de los 10 WSDL en la aplicación:

Se cargan el WSDL http://localhost:8082/InventoryWS/MusicInventoryService?wsdl y se presiona el botón [Volver]

http://localhost:8082/InventoryWS/MusicInventoryService?wsdl

55

La dirección WSDL http://localhost:8082/InventoryWS/MusicInventoryService?wsdl se carga en el ComboBox

Se realiza conteo de la cantidad de opciones de la lista y sigue en 10


56

Opción de recordar formulario ID Prueba






Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación debe recordar los valores de la última ejecución exitosa.

X

Datos de prueba

Entradas Datos






Durante la ejecución del flujo completo se valida que el checkbox esté en [Recordar Formulario] esté habilitado

El proxy se genera en la ruta:

57

La información del formulario es la misma de la última ejecución:

58

Edición y eliminación de métodos y parámetros ID Prueba






Ambiente Aplicado

Desarrollo X

Pruebas





La aplicación edita y elimina parámetros, en la vista final se hacen evidentes las modificaciones

X

Datos de prueba

Entradas Datos






Se cargan los valores en la apliación y se presiona el botón [Cargar WSDL]

59

Árbol de valores con los valores originales, se presiona el botón [Vista Previa]:

Se presiona el botón [Volver]:

60

Se procede a eliminar los métodos [returnChar, datosPrimitivos2, variables].

61

Se cambian a español algunos de nombres de parámetros de los métodos y se presiona el botón [Vista Previa]:

62

Se evidencia el cambio de nombres de parámetros en el proxy final:

64

Funcionamiento de botones de flujo ID Prueba






Ambiente Aplicado

Desarrollo X

Pruebas





Los botones que permiten el flujo de la aplicación funcionan en concordancia con su nombre.

X

Datos de prueba

Entradas Datos




Is Multitag Client False


Se cargan los valores en la apliación y se presiona el botón [Cargar WSDL]


65

Árbol de valores con los valores originales, se presiona el botón [Volver]:

Se presiona el botón [Salir]:

66

El botón [Volver, Nuevo Proxy, Salir] funcionan adecuadamente:

68

Se cambian a español algunos de nombres de parámetros de los métodos y se presiona el botón [Vista Previa]:

69

Se evidencia el cambio de nombres de parámetros en el proxy final:

71

4. FASE 4: ACTUAR

4.1. Implementación de WSProxyGenerator

Este proyecto fue realizado para integrarse con las tecnologías de AngularJS que se despliegan en el cloud Heroku para permitir la comunicación entre los servidores de aplicaciones de la empresa y Heroku.

Ilustración 6 Arquitectura de Despliegue


El modelo anterior representa el escenario genérico de despliegue de una aplicación desarrollada por ST&T. Dependiendo los requerimientos de negocio, la base de datos se desarrolla sobre Teradata o DB2 (IBM), así mismo, el código Java que define la lógica de negocio se desarrolla para los servidores JBoss o Apache Tomcat 7, dependiendo del requerimiento del cliente. A nivel visual se utiliza el servidor de aplicaciones Apache Tomcat 8 el cual es instalado sobre el cloud Heroku. A nivel general la arquitectura de componentes de la empresa se basa en un sistema multinivel y multicapa, combinado con los beneficios de un sistema distribuido, esto se debe a que existen varios servidores JBoss y varios Servidores Apache Tomcat7. La capa de presentación se basa bajo la arquitectura MVC, en el cual el modelo se define en Java, la vista se define en HTML extendido con AngularJS, y el controlador se basa en el uso de servicios REST que se comunican con clientes JavaScript por medio de la tecnología de Ajax.

72

Ilustración 7 Interacción de WSProxyGenerator


La herramienta CASE desarrollada fue nombrada “ws-proxy-generator”. Su interacción con el modelo de arquitectura presentado anteriormente se basa en facilitar la comunicación entre los servidores Apache Tomcat 7 y JBoss con el servidor Apache Tomcat 8 por medio de la generación automática de clientes Java que serán instalados en el servidor Apache Tomcat 8. Desde la perspectiva cliente-servidor en este escenario el cliente es el servidor Apache Tomcat 8 y los servidores son Apache Tomcat 7 y JBoss.

73

4.2. Arquitectura de la Solución

La arquitectura de la herramienta CASE WSProxyGenerator se encuentra definida en el siguiente diagrama:

Ilustración 8 Arquitectura de la Solución


A nivel general, el modelo anterior contiene la integración del flujo lógico de la herramienta con el funcionamiento interno. Los componentes cuyo fondo es de color verde representan los Frame finales de usuario (ventanas finales de usuario), los de azul representan los componentes más relevantes de la herramienta. Los círculos de color rojo con la palabra “END” definen el final de la ejecución de la herramienta. El flujo de la aplicación comienza desde el Frame [MainFrame] que contiene los parámetros iniciales para comenzar con la generación del cliente. Entre los parámetros solicitados están el WSDL, directorio de salida y el paquete de salida final. Una vez se captura la información, se inicia la validación de datos, se valida el acceso al WSDL, se verifica la existencia del directorio de salida y la definición correcta de un nombre de paquete. Luego la herramienta CASE procede a interpretar el WSDL para generar el modelo lógico de un cliente proxy. Una vez terminada la interpretación, la herramienta presenta un árbol con el modelo lógico del cliente. Dicho árbol puede recibir ediciones en sus parámetros, nombres de servicio y métodos, de forma adicional se permite la eliminación de métodos. Una vez el usuario final edita el árbol de acuerdo con los requerimientos del negocio, la herramienta presenta una previsualización del cliente final, la cual puede escribirse como archivo en el directorio del sistema especificado anteriormente. Finalmente, la herramienta ofrece iniciar el flujo con un nuevo WSDL dar por terminada la generación.

74

5. CONCLUSIONES

Los procesos internos de la compañía ST&T requieren un personal altamente calificado para cumplir con los requerimientos del cliente. Al hacer uso de los recursos humanos, económicos y tecnológicos brindados por la empresa, se planeó y ejecutó este proyecto, cuyo resultado proporcionó un mecanismo práctico para facilitar la comunicación entre servidores apoyados en la herramienta CASE desarrollada. La implementación de dicha herramienta plantea mejoras en los procesos para los servicios ofrecidos por la compañía, pues apoya la aplicación de estándares de calidad en pro de los principios de eficiencia, eficacia, escalabilidad, mantenibilidad y usabilidad, reduce los tiempos de planeación, desarrollo y evaluación de los proyectos, y mitiga los riesgos ante errores humanos o de definición de reglas de negocio en la creación de los clientes proxy. En un sentido estratégico, la metodología PHVA utilizada durante el desarrollo y puesta en marcha del proyecto sirvió como base en la retroalimentación y mejora continua, para lo cual se aplicaron 2 ciclos. El primer ciclo del proyecto consistió en el desarrollo de la herramienta CASE capaz de generar automáticamente el código para facilitar la comunicación entre servidores. En el segundo ciclo se llevaron a cabo algunas mejoras a la herramienta, tales como las opciones de editar o eliminar elementos de la estructura de un cliente proxy, y la previsualización de la definición de dicha estructura. Finalmente se detectó y evidenció que la interpretación de los WSDL es una tarea compleja que implica una intervención imperativa por parte del personal del área de desarrollo, lo cual representa un inconveniente y aumenta el margen de error humano. A lo anterior, se suma el volumen considerable de operaciones de los servicios web actuales y por implementar, tales como consulta, edición, inserción o eliminación de datos de todos los modelos expuestos en los WSDL, lo cual incrementa los tiempos asignados para los proyectos. Dicho inconveniente es solventado mediante la implementación de la herramienta CASE WSProxyGenerator.

75

6. BIBLIOGRAFÍA E INFOGRAFÍA

1 Web Services – Axis. The Apache Software Foundation [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: http://axis.apache.org/axis/ 2 JavaTM API for XML-Based Web Services (JAX-WS) 2.0. Java Community Process [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: https://jcp.org/en/jsr/detail?id=224 3 WsImport - Java™ API for XML Web Services (JAX-WS) 2.0. Oracle [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: http://docs.oracle.com/javase/7/docs/technotes/tools/share/wsimport.html 4 ST&T. Software, Telecommunications and Technology - Quiénes somos. [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: http://www.stt.com.co/ 5 Martínez Acosta, Deivis de Jesús. Herramienta para la generación del código fuente para aplicaciones con arquitectura Modelo Vista Controlador (MVC) bajo desarrollo dirigido por modelos textuales (MDD). Msc. en Ingeniería de Sistemas y Computación. 1 Volumen, Bogotá D.C.: Universidad Nacional de Colombia, 2014. 6 Learn about Quality: Plan – Do – Check – Act. ASQ [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: http://asq.org/learn-about-quality/project-planning-tools/overview/pdca-cycle.html 7 Candela, Santiago. García, Rubén. Quesada, Alexis. Santana, Francisco. Santos, Miguel. Fundamentos de sistemas operativos. Madrid. Thomson Editores Spain. Pág. 336, 2007. 8 Trail: RMI (Remote Method Invocation). Oracle [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: https://docs.oracle.com/javase/tutorial/rmi/ 9 Brito, Nacho. JavaEE como siempre debió haber sido. Manual de desarrollo web con Grails. Volumen 1,0. Pág. 131 10 Vukotic, Aleksa. Goodwill, James. Apache Tomcat 7. La voz expert en Java. Apress. Friendsof. 11 Web Services Description Languaje. W3C [en línea] [revisado 07 de agosto de 2017] Disponible en Internet: https://www.w3.org/TR/wsdl#_notational 12 Marchioni, Francesco. JBoss as 7 development. Develop, deploy and secure Java applications on the new release of this robust, open source application server. Packt.

http://axis.apache.org/axis/

https://jcp.org/en/jsr/detail?id=224

http://docs.oracle.com/javase/7/docs/technotes/tools/share/wsimport.html

http://www.stt.com.co/

http://asq.org/learn-about-quality/project-planning-tools/overview/pdca-cycle.html

http://asq.org/learn-about-quality/project-planning-tools/overview/pdca-cycle.html

https://docs.oracle.com/javase/tutorial/rmi/

https://www.w3.org/TR/wsdl#_notational

76

13 HTTP Components. The Apache software foundation [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: http://hc.apache.org/httpclient-3.x/ 14 Gupta, Arun. Stearns, Beth. Getting Started with JAX-RPC [en línea], abril 2002 [revisado 4 de agosto de 2017]. Disponible en Internet: http://www.oracle.com/technetwork/articles/javase/getstartjaxrpc-135460.html 15 Spring Web Services. Spring by Pivotal. [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: http://projects.spring.io/spring-ws/ 16 Heroku. What is Heroku? [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: https://www.heroku.com/what 17 AngularJS. Super-powered by Google ©2010-2017 [en línea], [revisado 4 de agosto de 2017]. Disponible en Internet: https://angularjs.org/

http://hc.apache.org/httpclient-3.x/

http://www.oracle.com/technetwork/articles/javase/getstartjaxrpc-135460.html

http://projects.spring.io/spring-ws/

https://www.heroku.com/what

consumo de servicios web por medio de clientes java

Documents