Diseño de servicios web para el portal móvil de la Universidad de Los Andes

Texto completo

(1)DISEÑO DE SERVICIOS WEB PARA EL PORTAL MOVIL DE LA UNIVERSIDAD DE LOS ANDES. CATALINA OLIVARES BERMÚDEZ. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C.. 1.

(2) DISEÑO DE SERVICIOS WEB PARA EL PORTAL MOVIL DE LA UNIVERSIDAD DE LOS ANDES. CATALINA OLIVARES BERMÚDEZ. Proyecto de Grado para optar al título de Ingeniero de Sistemas y Computación. ASESOR DR. HAROLD CASTRO PROFESOR FACULTAD DE INGENIERÍA UNIVERSIDAD DE LOS ANDES. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C.. 2.

(3) PAGINA DE ACEPTACIÓN. DR. HAROLD CASTRO. BOGOTA D.C.. 3.

(4) A Dios, mi creador y constante inspiración A mis padres por ser los artífices de este importante logro y su incondicional apoyo Catalina. 4.

(5) AGRADECIMIENTOS. Al profesor Harold Castro, quien con su constante colaboración y ayuda, hizo posible el desarrollo y la finalización de este trabajo. A Dios, mis padres, hermanos, y a Juan Pablo quienes con su apoyo y amor, permitieron que culminara satisfactoriamente esta etapa de mi vida.. 5.

(6) TABLA DE CONTENIDO 1. INTRODUCCIÓN ....................................................................................................................................8. 2. MARCO TEORICO...............................................................................................................................11 2.1 2.2. 3. INTERACCIÓN .....................................................................................................................................17 3.1 3.2 3.3. 4. MANEJO DE USUARIOS ..................................................................................................................20 ADMINISTRACIÓN DE EVENTOS ......................................................................................................20 MÓDULO USUARIO.........................................................................................................................21 INTERFACE DEL SERVICIO ..............................................................................................................21. FUNCIONES DEL SERVICIO WEB ..................................................................................................22 5.1 5.2 5.3. 6. INTERACCIÓN PULL........................................................................................................................17 INTERACCIÓN PUSH .......................................................................................................................18 INTERACCIÓN ENTRE EL PORTAL Y LOS SERVICIOS .....................................................................18. DISEÑO DEL SISTEMA ......................................................................................................................19 4.1 4.2 4.3 4.4. 5. SOLICITUD DE SERVICIOS POR PARTE DE UN ESTUDIANTE ...........................................................15 ENVÍO DE INFORMACIÓN AL ESTUDIANTE ......................................................................................16. CURSO BÁSICO DE EVENTOS PARA SICUA: ACTIVAR USUARIO ...................................................22 CURSO BÁSICO DE EVENTOS PARA CORREO: ACTIVAR USUARIO ...............................................22 CURSO BÁSICO DE EVENTOS PARA SICUA Y CORREO: DESACTIVAR USUARIO ..........................23. IMPLEMENTACIÓN.............................................................................................................................24 6.1 6.2 6.3 6.4. IMPLEMENTACIÓN DEL SERVICIO WEB .........................................................................................24 COMUNICACIÓN PORTAL MÓVIL .....................................................................................................25 COMUNICACIÓN CON SICUA: HTTPCLIENT ...............................................................................25 COMUNICACIÓN CON CORREO: JAVAMAIL / IMAP ......................................................................25. 7. PROBLEMAS ENCONTRADOS DURANTE LA IMPLEMENTACIÓN .......................................26. 8. PROBLEMAS ENCONTRADOS EN EL PORTAL MOVIL............................................................29 8.1. PROPUESTAS DE CAMBIO AL PORTAL MÓVIL .............................................................................31. 9. PROPUESTA DE IMPLEMENTACIÓN FUTURA ...........................................................................32. 10. CONCLUSIONES .................................................................................................................................34. 11. REFERENCIAS.....................................................................................................................................35. 6.

(7) TABLA DE ILUSTRACIONES ILUSTRACIÓN 1 ARQUITECTURA SERVICIOS WEB ...................................................13 ILUSTRACIÓN 2 ARQUITECTURA PORTAL MÓVIL Y SERVICIOS WEB .........................15 ILUSTRACIÓN 3 DISEÑO DEL SERVICIO WEB ..........................................................19. 7.

(8) 1. INTRODUCCIÓN. No es posible iniciar una discusión sobre la investigación y desarrollo planteado en el presente trabajo, sin, en primera instancia, enmarcarlo dentro de un nuevo paradigma de la economía, el cual empezó a desarrollarse desde la década de los 70’s y hoy en día ha cobrado gran fuerza. Se trata de la economía de la información, de la cual se desprende la denominada sociedad de la información, cuyos preceptos se pueden considerar un punto de partida adecuado para el trabajo desarrollado. Por Economía de la Información se entiende el estudio de las relaciones entre los agentes económicos en situaciones en las cuales existe una distribución desigual de la información disponible. El área de la Economía de la Información viene caracterizada por procesos en los cuales hay que tomar decisiones aún cuando la información disponible es incompleta (…). Cuando se habla de la Sociedad de la Información se está pensando en un sistema económico y social donde el conocimiento y la información constituyen fuentes fundamentales de bienestar y progreso. Es así como el concepto de sociedad de la información hace referencia a un paradigma que está produciendo profundos cambios en la sociedad global, impulsados principalmente por los nuevos medios disponibles para crear y divulgar información mediante tecnologías digitales. Se cree posible la construcción de una sociedad de la información que permita el desarrollo económico y social (…) a través de un adecuado uso de las tecnologías de la Información y la Comunicación, principalmente mediante la expansión de la red (internet) como sistema de intercambio de información y de comunicación (CORTEZ, Mónica y OTTER Thomas. Economía de la Información, Sociedad de la Información, Información Periodística: Elementos compartidos hacia una información pluralista y equitativa. Pag. 4 y 10). Dentro del contexto de la economía y la sociedad de la información, surge una relación entre estos términos y la educación actual y del futuro. De la misma manera, la educación en la sociedad de la información enmarca términos como conocimiento y aprendizaje, los cuales ahora se ven canalizados a través de los denominados TIC’s (Tecnologías de la Información y la Comunicación), específicamente a los computadores y la Internet. Esta nueva tendencia se ha ido masificando durante los últimos años y, dadas sus ventajas, vendrá el momento en el cual la educación se encaminará totalmente mediante los mencionados TIC’s.. 8.

(9) Actualmente, es palpable ver cómo las instituciones educativas se han ido adaptando gradualmente a este nuevo movimiento; al hablar del caso colombiano específico, la Universidad de los Andes, al ser una de los establecimientos educativos más influyentes en todas las esferas del ámbito académico, busca dedicar parte de su gestión en el desarrollo de estas nuevas tecnologías para el beneficio de la comunidad Uniandina en general. Cabe anotar cómo en los últimos tiempos, en los que la economía del mundo se ha ido convirtiendo en una economía de servicios, los costos de transacción han adquirido una importancia vital. Resulta curioso cómo en un mundo con cada vez mayores niveles de información existan problemas de gestión y de acceso a la misma. Por tal razón, hoy lo importante es saber gestionar los medios por donde se transmitirán los datos, de tal manera que sólo se reciban los detalles más relevantes de una forma más sencilla, aprovechando el carácter de economía de alcance que hoy posee la información1. Esto es uno de los objetivos que persigue la Universidad de los Andes al querer incorporar nuevas tecnologías con un acceso a la información uniforme, claro y completo por parte de toda su comunidad. Para lograr dicho fin, una de las alternativas que ha tomado gran fuerza últimamente es la tecnología de sistemas móviles, la cual representa una plataforma que constituye múltiples aplicaciones en un sólo front-end, y que puede ser accedida desde cualquier lugar. La presente investigación busca explotar de manera práctica la alternativa mencionada, sin embargo pretende ofrecer un portal de servicios para sistemas móviles sensible al contexto para la gestión de la transmisión de la información, logrando que el sistema sea cada vez más autónomo y así pueda identificar las necesidades y gustos de los usuarios. Al darle continuidad a la problemática expuesta en la tesis de maestría del estudiante Richard Douglas García2 y a los retos que la misma dejó plasmados para futuras investigaciones, el paso a seguir consiste en encontrar el servicio que le sea más útil a los usuarios de dicho portal, ya que el mismo ofrece una amplia gama de prestaciones; la idea es minimizar los costos de transacción ya expuestos y permitir que cualquier persona acceda a la información que necesita de una manera rápida, eficiente y oportuna.. 1. ROCASOLANO, Pablo Miró. La economía de la información en un contexto neoinstitucional. En: Contribuciones a la Economía [en línea]. Disponible en: <http://www.eumed.net/ce/2004/pmrinf.htm> 2 “DISEÑO DE UNA ARQUITECTURA PARA UN SISTEMA DE COMUNICACIÓN INTERMÓDULOS PARA UN PORTAL DE SERVICIOS PARA SISTEMAS MÓVILES SENSIBLE AL CONTEXTO”. 9.

(10) El presente trabajo ofrece la creación de un sistema que brinde ciertos servicios en el portal de móvil de la tesis de maestría, para un nicho de beneficiarios específicos y bien diferenciados. Dado que es necesario establecer un alcance amplio para el presente proyecto, se considera que un “mercado” interesante que podría sacar un alto provecho de los servicios del portal móvil ya implementado es el conformado por los estudiantes universitarios, los cuales demandan día a día grandes cantidades de información. Por lo tanto, el desarrollo de esta investigación permite que los estudiantes de la Universidad de los Andes lleguen a estar al tanto de sus notas, tareas, trabajos, correos y notas de cualquier materia, ya que el servicio prestado los buscará de manera proactiva para informarle sobre cualquiera de estas actividades.. 10.

(11) 2. MARCO TEORICO. Dada la relevancia y crecimiento que han venido teniendo las comunicaciones móviles durante los últimos años, en la Universidad de los Andes se dio inicio a una investigación y posterior desarrollo de un portal móvil basado en el tratamiento de los sistemas sensibles al contexto, los cuales son sistemas que poseen información y habilitan su comportamiento y servicios de acuerdo al entorno que rodea al usuario. Los servicios ofrecidos por los sistemas señalados, proveen funciones relacionadas con el contexto del usuario dado que el servicio se encuentra inmerso en el entorno del mismo. El desarrollo de estos sistemas sensibles al contexto se dio a partir de tecnologías que ofrecieran interoperabilidad y bajo acoplamiento, logrando estandarizar funciones de tal manera que los servicios puedan ser compartidos por varias aplicaciones. Por lo expuesto previamente “El Portal de Servicios para sistemas móviles sensitivo al contexto se basa en la posibilidad de la interacción de un usuario, estático o en movimiento, con espacios físicos”3. A partir de la necesidad de contar con una arquitectura en el portal de servicios móviles basada en la flexibilidad y en una abstracción del mundo real, se propuso que el sistema contara con 4 unidades lógicas aislando la forma de comunicación y lo comunicado. En primera instancia se encuentra la Unidad Lógica Usuario que contiene los dispositivos móviles que interactuaran con el sistema. La siguiente unidad es la Unidad Lógica Representante conformada por el Agente Usuario (AU), el cual se encarga de interactuar con el Espacio Activo gestionando los requerimientos del usuario, y la Fuente de Información Posicional (FIP), la cual posee todos los datos de la posición geográfica donde se encuentra el usuario. La Unidad Lógica Portal contiene toda la lógica del negocio, puesto que es la que logra toda la comunicación entre las Unidades de Espacio Activo y los Agentes de Usuario. Esta unidad tiene en principio, el Espacio Activo (EA), el cual atiende y gestiona las solicitudes del usuario y determina cual es la Unidad de 3. PORTAL DE SERVICIOS PARA SISTEMAS MÓVILES SENSIBLE AL CONTEXTO. GARCIA, Richard. 11.

(12) espacio Activa adecuada para resolver el requerimiento proveniente del usuario; cuenta también con un Gestor de Usuarios (GU), el cual contiene todos los datos relacionados con el usuario; así mismo tiene un modulo que se encarga de manejar la información del contexto temporal que afectan el comportamiento de las personas llamado Gestor de Contexto Temporal (GCT); y por último, de manera opcional cuenta con un modulo de Fuente de Información Posicional (FIPEA) del Espacio Activo que permite conocer la ubicación de los usuarios que se encuentran dentro del espacio físico para ofrecerles servicios. Finalmente se encuentra la Unidad Lógica de Sistemas de Información que se encarga de dar respuesta a los requerimientos de los usuarios; donde su modulo principal es la Unidad de espacio Activa (UEA), que presta uno o más servicios, atiende las solicitudes de los usuarios que han sido comunicadas a través del Espacio Activo y propone de manera autónoma información al usuario que ha sido construida con base en los datos de los usuarios que se encuentran autenticados. Dado que el propósito de la presente investigación es ofrecer ciertos servicios a los estudiantes de la Universidad de los Andes, se pensó en la realización de servicios Web los cuales pudieran ser accedidos por medio de la arquitectura móvil ya existente. La razón principal por la cual se decidió usar servicios Web para crear toda la funcionalidad necesaria que supliera las necesidades de información básica de los estudiantes de los Andes es que los servicios sugeridos pueden ser desarrollados y diseñados en distintos lenguajes de programación a los de las aplicaciones software que acceden a él; de igual forma, cada uno de los servicios Web puede ejecutarse en plataformas diferentes, independizando y flexibilizando la aplicación y el servicio Web, posibilitando así que los cambios a futuro en uno no afecten al otro. La independencia que exista entre el portal móvil y los servicios Web permitirá que los servicios que se ofrezcan sean mucho más mantenibles y que el desarrollo de la arquitectura del servidor Web no sea necesariamente realizado en el lenguaje actual en el cual se encuentra el diseño del portal móvil. Los Servicios Web son componentes de software que representan una o más funciones de negocio y pueden ser accedidos por otra aplicación (un cliente, un servidor u otro Servicio Web) sobre redes públicas utilizando protocolos y transportes generalmente disponibles y ubicuos4. De esta manera, los servicios que son ofrecidos se publican de manera abierta en la Web para que las otras aplicaciones lo encuentren y puedan hacer uso de esta funcionalidad por medio de una URL usando el protocolo SOAP sobre HTTP. 4. Gartner Group. 12.

(13) De la misma manera, para un grupo de personas tan grande como la Universidad de los Andes, la necesidad de que la información sea accesible es un tema tan relevante como que esta información sea integra y valida. La propuesta de utilización de Servicios Web que mantienen centralizada la información pretende que no se encuentre información contradictoria, pero brindando una mayor flexibilidad al acceder a los datos. Por medio de un conjunto de estándares que cumplen cada uno una tarea particular, las aplicaciones pueden comunicarse entre si al enviarse una serie de datos en formato XML: Cada uno de los estándares maneja un formato que ajusta los datos que se intercambian entre las aplicaciones, permitiendo así definir la gramática de los lenguajes específicos, este formato es XML De la misma manera, se maneja un protocolo llamado SOAP, sobre el cual se establece el intercambio o la invocación de los servicios, definiendo como dos objetos se pueden comunicar por medio de datos XML. Por otro lado, para representar el lenguaje de la interfaz pública de los servicios Web se utiliza el estándar WSDL, en el cual se describe la funcionalidad necesaria para realizar la comunicación con los Servicios Web. Es un formato XML que describe los servicios Web El protocolo usado para publicar la información pertinente de un Servicio Web para que esta pueda ser accedida por las distintas aplicaciones es UDDI. Los Servicios Web registran su información más relevante, como el WSDL, en business registries. A continuación se presenta una ilustración que describe el procedimiento para publicar y utilizar un servicio Web, teniendo en cuenta los protocolos y estándares previamente mencionados.. Ilustración 1 Arquitectura Servicios Web. 13.

(14) Partiendo de la identificación del mecanismo que se usará para la comunicación del Portal Móvil y los servicios, se dio inicio a plantear una serie de necesidades que permitieran un acceso de los estudiantes a la información de forma rápida y que sea vista en cualquier lugar. Para lograr los planteamientos expuestos, se buscó la posibilidad de agregarle la funcionalidad necesaria al portal móvil trabajado y desarrollar la arquitectura ya existente. De toda la información que puede llegar a ser accedida por los estudiantes en la Universidad de los Andes, se encontró que los servicios de correo y Sicua tienen una gran importancia dado que son frecuentemente utilizados, creando la necesidad de acceder fácil y rápidamente a esta información. Por tal motivo se decidió hacer los servicios que ofrecerá el portal móvil de acuerdo a estas dos páginas Web. Para la elaboración del presente sistema se construirán dos Servicios Web que permitirán que a través de portal móvil el estudiante se active y desactive en la opción de recibir mensajes en caso de que: • • • •. Reciba un correo de un destinatario determinado Le asignen una nueva tarea Le sea enviado un correo de Sicua Se le asigne una nueva nota a una materia. En la implementación del presente proyecto solo es necesario involucrarse con los componentes asociados a la Unidad de Espacio Activo puesto que es éste el modulo que se encarga de ofrecer los servicios a través del Espacio Activo y soluciona los requerimientos provenientes del usuario. A través de las Unidades de Espacio Activo del portal móvil se logra la comunicación necesaria con el Servicio Web para enviar y recibir información pertinente al estudiante, gracias a que estas son las que representan las unidades de negocio y ofrecen de manera general servicios para ser ofrecidos a los alumnos. En la gráfica que se muestra a continuación se representa el modelo de la arquitectura del portal móvil existente, describiendo la interacción que tendrá con los sistemas de información a los cuales se hará la conexión para crear los servicios Web.. 14.

(15) Ilustración 2 Arquitectura Portal Móvil y Servicios Web Los dos servicios Web propuestos se encargarán de ofrecer toda la funcionalidad necesaria para responder a las solicitudes de los usuarios. Por tal razón uno de los servicios Web se encargará de toda las tareas relacionadas con el correo, verificando de esta manera si los estudiantes que se encuentran activos y que solicitaron el servicio tienen nuevos correos del remitente seleccionado previamente durante la activación. El otro servicio Web responderá a todos los requerimientos que estén relacionados con Sicua, el cual deberá identificar nuevas tareas, nuevas notas o nuevos correos de Sicua para las estudiantes activos en el servicio de Sicua. No obstante, cabe anotar que solo existe una única Unidad de Espacio Activo que se encarga de realizar la comunicación con los servicios Web, tanto de correo como de Sicua. Esta Unidad de Espacio Activo recogerá los servicios que le ofrecen los servicios Web y se los comunicará al Espacio Activo al cual la unidad pertenece; de esta manera se logra una integración entre el portal móvil y el servicio Web. Dentro de la Unidad de Espacio Activo se puede encontrar un componente de comunicación con el cual el Espacio Activo se comunica con dicha unidad y viceversa; a través del modulo comunicación ofrecido, se realizó el desarrollo de la interacción del servicio Web con la Unidad. 2.1. Solicitud de servicios por parte de un estudiante. Cuando un Agente de Usuario recibe la solicitud de un estudiante de activarse o desactivarse en cualquiera de los servicios ofrecidos, el componente de Agente de usuario se encarga de comunicarse con el Espacio Activo.. 15.

(16) El espacio Activo construirá un mensaje con la información de la Unidad de Espacio Activo que gestionará la solicitud, en el mensaje irá también el requerimiento. Cuando la Unidad de Espacio Activo recibe la solicitud, verifica cual servicio Web es el más adecuado para solucionar la petición realizada por el usuario, e inmediatamente se comunica con el servicio Web para que solucione el requerimiento. En el caso en el cual la solicitud de servicio por parte del estudiante sea la activación o la desactivación de su perfil en cualquiera de los servicios ofrecidos, el servicio Web se encargará de enviarle al instante una confirmación al usuario en el cual se le indica si la tarea se realizó con éxito o si ocurrió alguna eventualidad. 2.2. Envío de información al estudiante. Puesto que cada uno de los servicios Web se encuentra continuamente verificando si los estudiantes que están activos tienen algún evento ya sea de Sicua o de Correo, en el momento en que cualquiera de los servicios Web identifique que un estudiante tiene un nuevo evento, el servicio Web notificará al modulo de comunicación ofrecido por la Unidad de Espacio Activo. El componente de comunicación de la Unidad de Espacio Activo recibirá un mensaje donde se le indica el suceso. La Unidad de Espacio Activo se encargará de construir el mensaje con el formato establecido XML, y se lo enviará al Espacio Activo para que sea él el que lo envíe al Agente de Usuario correspondiente y el estudiante sea informado.. 16.

(17) 3. INTERACCIÓN. Con base en la interacción propuesta en el portal móvil, el modelo de comunicación planteado para lograr la interacción entre los servicios y el portal, será diseñado cumpliendo los objetivos de flexibilidad, escalabilidad y mantenibilidad. En principio, la arquitectura del portal propone ciertos elementos que hacen parte del modelo y que son considerados importantes en el proceso de comunicación: -. -. Usuario: Interactúa con el sistema, solicitando o recibiendo información Espacio Activo: Lugar geográfico donde se encuentra el usuario. Puede proponer información al estudiante de acuerdo al contexto del usuario. El estudiante puede solicitar información al espacio. Unidad de Espacio Activo: Ofrece los servicios y resuelve los cuestionamientos del usuario. Acciones: Actúan sobre los objetos de acuerdo a un evento iniciado por un usuario. Objetos: Es el servicio ofrecido por la Unidad de Espacio Activo y que los usuarios pueden solicitar a través de una acción.. Dados los elementos que hacen parte de la comunicación entre los módulos, es necesario entrar a analizar los tipos de interacciones que pueden existir cuando una acción se ejecuta; es decir que a partir de una propuesta o una solicitud de información se pueden generar dos formas existentes de interacción. 3.1. Interacción Pull. Se refiere a las acciones iniciadas por el usuario. Actualmente se encuentran clasificadas en: -. Preguntas (Query) es la petición de información a cualquiera de los elementos del modelo de comunicación. Requerimientos de acción (Request) es la ejecución de acciones que modifican el estado de los objetos.. Para cada uno de los tipos de interacción pull existe un archivo XML que posee la estructura de la sintaxis de las preguntas, solicitudes y ejecución de acciones en el portal, de acuerdo a la arquitectura y al modelo de comunicación planteado.. 17.

(18) 3.2. Interacción Push. Son las acciones emprendidas por el sistema para la realización de propuestas de información al usuario. Las propuestas pueden ser dadas por aquellos módulos que conocen el contexto del usuario y el Gestor de Usuarios se encargará de evaluar si esta información resulta pertinente y adecuada, a partir de los filtros de gustos del usuario que el componente posee. Al igual que el tipo de interacción pull, éste también cuenta con una estructura XML de su sintaxis. 3.3. Interacción entre el Portal y los Servicios. Dentro del presente trabajo se pueden encontrar los dos tipos de interacciones. En principio, cuando el usuario solicita ser activado o desactivado en cualquiera de los servicios, está creando una nueva pregunta a través del portal móvil, el cual le solicita esta función al servicio Web. Por su parte el servicio Web se encarga de responder la pregunta y emitir una respuesta o confirmación al usuario en el momento en el que da por terminado la solución de la solicitud. No obstante, para poder indicar cualquier tipo de evento en Sicua o correo, el sistema tendrá que comunicarse con el portal móvil, el cual a su vez se comunicará con el usuario indicándole el nuevo suceso; para comunicarse utiliza el tipo push, el cual representa en el portal móvil una solicitud de servicio diferido o push diferido. Sin embargo, según lo planteado la implementación difiere de la arquitectura existente, dado que para recibir mensajes diferidos o mensajes generados autónomamente por el sistema, es necesaria la creación de una solicitud que queda a la espera de la respuesta; en el caso mencionado no se crea una solicitud, sino que la Unidad de Espacio Activo crea un mensaje dirigido a un usuario en particular sin tener un requerimiento previamente creado.. 18.

(19) 4. DISEÑO DEL SISTEMA. Durante el actual capitulo se describirán los componentes más relevantes que conforman cada uno de los servicios Web.. Ilustración 3 Diseño del Servicio Web En la anterior figura se puede observar el modelo del Servicio Web. Este diseño aplica tanto para Sicua como para correo, representando el esquema general de los servicios Web y como es el comportamiento de cada uno de los componentes y su interrelación.. 19.

(20) 4.1. Manejo de usuarios. Existe un componente particular que maneja todo lo referente a los usuarios. Es el modulo que se encarga de activar y desactivar los usuarios dentro del sistema. Sus tareas principales son:. 4.2. •. Verificar si el usuario que se va activar no existe en el sistema. •. Revisar si el usuario a adicionar es correcto, es decir que el usuario tiene una cuenta de correo en la Universidad y su clave es la indicada.. •. Al momento de desactivar un usuario, comprueba si el estudiante existe en el sistema.. •. Adiciona o elimina el usuario según se establezca. Administración de eventos. Para la realización de cada uno de los Servicios Web, fue necesaria la creación de un subproceso que se encargue de determinar y verificar si existe algún nuevo evento para cada uno de los usuarios activos en el sistema. Se considera que un estudiante tiene un nuevo evento cuando a través de sicua recibe una nueva nota, un nuevo correo de sicua o nueva tarea, o recibe un mensaje de un destinatario determinado al servicio de correo. Para desarrollar la funcionalidad que se requería, se encontró conveniente el uso de un Thread que cumpliera con las siguientes actividades: Cuando la clase principal activa la búsqueda, el Thread inicia su proceso de revisión de cada uno de los usuarios. A partir de la revisión particular de cada uno de los usuarios, comprueba si cada uno de los estudiantes activos en el sistema tiene un nuevo evento ya sea de correo o de Sicua. Cuando finaliza la comprobación si el usuario posee o no nuevos eventos, en el caso en el cual el estudiante tenga una nueva eventualidad, el servicio web enviará un mensaje por medio del portal móvil hacia el usuario, indicando cual evento se produjo y que información se tomó del suceso. En el momento de enviar el mensaje continúa la revisión para cada uno de los estudiantes existentes en el sistema.. 20.

(21) 4.3. Módulo Usuario. Componente que permite construir bajo un mismo objeto, todas las características pertinentes de un estudiante. Dentro de los atributos que contiene el objeto, se encuentran aquellos que ayudan al servicio Web a relacionar los nuevos eventos con el estudiante, logrando de esta manera que un usuario no sea avisado más de una vez de un mismo evento. El módulo de usuario es quien lleva un historial de los previos eventos del usuario. 4.4. Interface del servicio. El último componente que se encuentra es la interface del servicio Web. Es el componente encargado de publicar los servicios Web en un servidor de aplicaciones determinado, de tal manera que la Unidad de Espacio Activo que ofrece los servicios de Sicua y Correo pueda comunicarse con los servicios Web y les delegue las tareas de activación y desactivación de los estudiantes.. 21.

(22) 5. FUNCIONES DEL SERVICIO WEB. El objetivo general de los servicios Web ofrecidos, es brindarles a los estudiantes de la Universidad de los Andes la oportunidad de conocer en determinado momento si ocurrió algún evento de Sicua o de Correo. Cuando se refiere a evento de Sicua, se tienen en cuenta 3 variables importantes tales como nuevas notas, nuevos correos de Sicua y nuevas tareas. Para el caso del correo se cuenta con un simple evento, el cual solo ocurre cuando al estudiante le llega un correo de un filtro (emisor) elegido previamente. 5.1. Curso básico de eventos para Sicua: Activar usuario 1. El usuario se registra en el sistema, donde envía usuario, clave del sistema, e identificadores correspondientes del portal móvil. 2. El sistema verifica si el usuario ya existe o si el usuario ingresado es incorrecto. En caso de que se presente alguno de los errores citados, se le informará al estudiante a través del portal móvil 3. El sistema adiciona el nuevo usuario. 4. Cuando el thread identifica que un estudiante tiene algún nuevo evento de Sicua, el suproceso enviará toda la información pertinente del suceso, a través del portal móvil utilizando la funcionalidad de mensaje diferido. Dicho thread se encuentra activo desde el primer llamado del portal móvil al servicio Web. 5. El thread continúa trabajando e identificando nuevas eventualidades.. 5.2. Curso básico de eventos para Correo: Activar usuario 1. El estudiante se registra en el sistema, enviando usuario, clave, identificadores correspondientes al portal móvil y filtro emisor. 2. El sistema comprueba si el estudiante ya existe o si los datos ingresados son incorrectos. En caso de error le informa al usuario por medio del portal móvil. 3. El sistema adiciona el nuevo usuario.. 22.

(23) 4. Cuando el thread identifica que el estudiante ha recibido un nuevo correo del emisor elegido, se comunica de manera similar que el servicio Web de Sicua con el estudiante, enviándole el contenido del correo recibido. 5. El thread continúa identificando nuevas eventualidades. 5.3. Curso básico de eventos para Sicua y Correo: Desactivar usuario 1. El estudiante indica que desea desactivarse del servicio ofrecido. 2. El sistema recibe la información del estudiante a desactivarse e identifica si el estudiante si existe en el sistema. En caso de que no exista, el usuario será informado a través del portal. 3. El sistema elimina el estudiante del sistema. 4. El thread continúa revisando y comprobando nuevos eventos de aquellos estudiantes que continúan activos en el sistema.. 23.

(24) 6. IMPLEMENTACIÓN. El desarrollo del presente trabajo plantea una arquitectura flexible, ofreciendo un funcionamiento elemental que permite un fácil entendimiento, una comunicación manejable con el portal móvil y una posibilidad de futuros mantenimientos o nuevos desarrollos, gracias a que no crea grandes componentes y su estructura es muy básica. 6.1. Implementación del Servicio Web. Para la implementación de los Servicios Web inicialmente se pensó en J2EE, no obstante JBoss y Java ofrecen día a día nuevas herramientas y maneras de desarrollo que posibilitan que la creación de un proyecto sea menos complejo, dado que no requieren de una gran serie de descriptores e interfaces como lo demanda o reclama la especificación previamente mencionada. Al descartar J2EE como estándar para el desarrollo del servicio Web, se analizó la posibilidad de la creación del proyecto a través de Axis y el servidor Jakarta Tomcat de Apache, sin embargo se encontró que la Universidad no cuenta con una buena instalación de estas herramientas y en muchos de los casos es necesario instalarlo cada vez que se crea una nueva sesión en cualquiera de los computadores disponibles para la Facultad de Sistemas. Por las razones mencionadas preliminarmente se investigó la viabilidad de crear los servicios Web contando con las herramientas existentes. A partir de la necesidad planteada, se encontró que las nuevas versiones del servidor JBoss cuentan con una herramienta llamada wstools5 que permite que el desarrollador no se tenga que preocupar por la interface, el archivo de mapping y el descriptor de servicios WSDL. La utilización de wstools concede la posibilidad que el desarrollo del servicio Web sea mucho más sencillo, ya que sólo es necesario un archivo de configuración para crear todos los archivos correspondientes al servicio Web. Igualmente se hizo uso de Ant para correr las tareas más importantes que permiten montar adecuadamente el servicio Web en la versión de JBoss que se desee6. No obstante es necesario contar con una versión igual o mayor a la 4.04 GA para generar los archivos correspondientes al servicio Web, dado que la herramienta sólo se encuentra disponible para estas versiones.. 5 6. Wstools genera la interface service endpoint y el archivo de mapeo En los anexos se encuentra los pasos necesarios para la correcta ejecución del proyecto. 24.

(25) 6.2. Comunicación portal móvil. Puesto que el portal móvil cuenta con una serie de componentes en el módulo de la Unidad de Espacio Activo que le permiten enviar y recibir información del Espacio Activo, tiene para tal fin un servicio Web que le permite la interacción con los otros módulos. A partir del servicio Web mencionado, se creó un nuevo servicio que ofrece el componente de comunicación de la Unidad de Espacio Activo, cumpliendo con unos de los objetivos principales de la presente investigación: la comunicación desde el servicio Web hasta el portal móvil enviando mensajes asíncronos al usuario. El nuevo servicio recibe la información y la envía a través del portal móvil al usuario correspondiente. Para lograr la comunicación desde el portal móvil hasta los Servicios Web se crearon una serie de funciones en la Unidad de Espacio Activo que se encargan de realizar la conexión con los servicios. Es importante aclarar que estas funciones nos son servicios para el servicio Web de la Unidad de Espacio Activo, sino métodos de salida de información desde la Unidad hacía entes externos, más específicamente hacía los servicios Web; en otras palabras, el servicio Web de la Unidad de Espacio Activo permite que módulos distintos a él le envíen información, pero no permite enviar información. 6.3. Comunicación con Sicua: HTTPCLIENT. Para lograr la conexión con Sicua se utilizó un API7 de Apache, cuya implementación ofrece los mecanismos básicos para interactuar con páginas HTTP. Este API provee gran funcionalidad y flexibilidad que muchas aplicaciones necesitan, ofreciendo un paquete eficiente, actualizado y con un gran número de características implementando el lado del cliente con las más recientes recomendaciones y estándares HTTP 6.4. Comunicación con correo: JavaMail / IMAP. La conexión con el correo se logró a través de un API al igual que Sicua; sin embargo, a diferencia de HTTPCLIENT, este API es un paquete opcional de Java. Gracias al paquete ofrecido, es posible crear aplicaciones de usuario de correo, puesto que maneja distintos protocolos que hacen posible el envío y la lectura de los mensajes sin tener que ser el mismo API el encargado del transporte de los mismos. Es un API sencillo y que facilita la tarea del programador.. 7. HTTP://jakarta.apache.org/commons/httpclient/. 25.

(26) 7. PROBLEMAS ENCONTRADOS DURANTE LA IMPLEMENTACIÓN. Durante el desarrollo de los servicios Web no se encontraron mayores contratiempos, no obstante lograr un conexión con Sicua fue un trabajo arduo y de muchas pruebas, contrario a lo que sucedió con la conexión con el Correo. Era claro que lograr la conexión con Sicua iba a generar mucha más complejidad durante la implementación, puesto que era necesario investigar más a fondo las conexiones a páginas seguras con un certificado digital. Para iniciar la interacción con todo tipo de páginas HTTP, fue necesario documentarse y conocer todas las características y funcionamiento del protocolo por medio de la RFC 26168. A partir del documento descrito, se emprendió la tarea de identificar los mensajes, la definición de los métodos y la declaración de los códigos de estado necesarios para lograr una correcta comunicación con el Servicio de Sicua. No obstante, con esta referencia no se dio un total alcance sobre la información necesaria para conectarse a páginas Web seguras, por lo que fue necesario recurrir a una segunda RFC9 en la cual se describiera cómo es la intercambio de mensajes entre un cliente y una página HTTP sobre un túnel seguro. Dentro de la RFC 2818, se encontró como usar TLS10 para conexiones HTTP seguras sobre la Internet; gracias al documento mencionado, se obtuvo la información básica para dar inicio a la implementación de la conexión a Sicua, dado que se describen claramente los requisitos necesarios para lograr la comunicación y conocer el comportamiento del cliente y el servidor. Inicialmente se pensó en la posibilidad de desarrollarlo por medio de sockets seguros, los cuales permiten conectarse con páginas que tienen certificados de seguridad. Los sockets son componentes de comunicación entre procesos basados en la filosofía de cliente-servidor por un canal encriptado, autenticando sí un host remoto es de confianza. Para que un host establezca su confiabilidad, deberá adquirir un certificado de una entidad emisora de certificados, por lo tanto las aplicaciones están encargadas de validar el certificado y permitir si una conexión se establece o no.. 8. Disponible en la Web: http://www.ietf.org/rfc/rfc2616.txt Disponible en la Web: http://www.ietf.org/rfc/rfc2818.txt 10 TLS (Transport Layer Security) Es el protocolo SSL estandarizado por el Internet Engineering Task Force que abarca toda la capa de transporte de la pila OSI. 9. 26.

(27) Sin embargo, al realizar la implementación de la conexión a Sicua por medio de estos sockets se presentó un error que representó un porcentaje de tiempo mayor en la implementación del proyecto. Fue difícil identificar el error específico que se presentaba, pero las excepciones que se mostraban facilitaron la tipificación del mismo. Al depurar y hacerle seguimiento al error, se pudo encontrar que el error estaba asociado al momento de hacer la conexión, es decir que no se podía abstraer nada del servicio de Sicua porque no se podía establecer una comunicación. La razones principal por la cual el sistema no podía entablar una conexión era que en el momento de realizar el “saludo” o “handshake” se identificaba que la validación del certificado era incorrecta, es decir que no cumplía con los exigencias más importantes a la hora de validarlo, tales como que el certificado sea actual y que haya correspondencia entre la identidad que está contenida en el certificado con respecto a la de la entidad con la cual se conecta. Es importante anotar que al utilizar el mecanismo de comunicación con otras páginas seguras la respuesta era diferente, mostrando que para estas era totalmente viable, contrario a lo que mostró Sicua. A partir de las razones expuestas se eligió otra manera de realizar esta conexión; fue así que se probó con HTTPCLIENT, el cual sirve como cliente HTTP. Por medio del API fue posible realizar la comunicación entre las partes, logrando construir los mensajes y métodos necesarios para abstraer la información necesaria que ayudara a obtener los eventos descritos. Pese a que ésta fue la manera más fácil y rápida de lograr una comunicación, se encontró que solo se obtiene la conexión en máquinas con ciertas características, lo cual llevo a preguntarse si lo mismo sucedía con los sockets seguros puesto que en ciertas máquinas el API arrojaba el mismo error. Fue de esta manera como se dedujo que era necesario contar con máquinas que tuvieran cierto software instalado para poder ver en ejecución el proyecto. El error descrito, se evidenció a partir de realizar pruebas en diferentes salas de computo de la Universidad con software distinto. Sólo en aquellas donde el software - tal como el JDK11, jboss y la máquina virtual de Java - se encuentra debidamente instalado y actualizado, el programa corre adecuadamente. Cabe anotar que las máquinas en las cuales funcionó la conexión contaban con una versión J2SE12 mayor o igual a 5. El funcionamiento del proyecto se debe a 11. Paquete que contiene el entorno de desarrollo y ejecución de Java Representa el reemplazo del JDK para destacar la plataforma J2EE. Incluye clases que soportan el desarrollo de servicios Web. 12. 27.

(28) que estas nuevas versiones integran la seguridad y las extensiones criptográficas como JSEE. Lo anterior muestra que la conexión a Sicua es posible realizarla ya sea a través de sockets, donde la construcción de los métodos y mensajes se hace manualmente, o simplemente se usa el API de Apache que crea automáticamente la comunicación a partir de unos parámetros básicos de conexión; para lograr cualquier tipo de conexión, sólo es necesario contar con la máquina adecuada la cual permite obtener el certificado de seguridad indispensable, adquiriendo así un canal de comunicación con el servicio de Sicua.. 28.

(29) 8. PROBLEMAS ENCONTRADOS EN EL PORTAL MOVIL. El portal móvil implementado propone un sistema de comunicación flexible entre los módulos con un funcionamiento básico, el cual posibilita la entrada y salida de los espacios activos y la obtención de servicios de la Unidad de Espacio Activo. La característica principal del portal es permitir el desarrollo de futuras funcionalidades y la agregación de nuevos componentes que lo vuelven más robusto. A pesar de sus ventajas el portal móvil desarrollado presenta algunas falencias, las cuales se tornan relevantes al momento en el cual se piensa en implementaciones futuras, así como en el crecimiento del portal en cuanto a sus servicios. En primera instancia se encontró un error de implementación que cierra toda posibilidad de incluir en el proyecto más de una Unidad de Espacio Activo. Al encontrar esta falla surgen muchas dudas, dado que desde un principio se creía que el portal podría mantener activas más de una Unidad de Espacio Activo. Por tal razón fue necesario estudiar más a fondo cuales son las características de estos módulos que hacen que en el mismo servidor de aplicaciones (JBoss) no sea posible desplegar varias Unidades. Al examinar la Unidad de Espacio Activo, se apreció que estas están compuestas por una serie de componentes que conforman un gran módulo. Para comenzar se cuenta con un componente controlador que dirige todos los procesos internos, un componente de comunicaciones que, como su nombre lo indica, se encarga de las comunicaciones con los otros módulos; así mismo, cuenta con un componente gestionador de solicitudes, un componente que se encarga de publicar los servicios, un componente que propone información al usuario y un componente de interfaz grafica. Cuando se encuentran tantos componentes que crean un solo modulo, surge una pregunta: ¿Es necesario que cada uno de ellos exista para crear el módulo? A partir del cuestionamiento dado, se logró identificar que estos componentes quedaron sujetos a la implementación de una sola Unidad de Espacio Activo, es decir que cuando se quiere crear otra Unidad de Espacio Activo es necesario cambiar toda la implementación y creación de los componentes; puesto cada parte que compone el modulo tiene una descripción única que al momento de desplegarlos en el servidor de aplicaciones, no permite que dos componentes con las mismas características se ejecuten al mismo tiempo, haciendo que sólo una Unidad de Espacio Activo se asocie al portal.. 29.

(30) Lo anterior contradice un poco el planteamiento inicial del proyecto, dado que la arquitectura del portal móvil ofrecía flexibilidad y mantenibilidad en los módulos y componentes existentes. El simple hecho que sea necesario modificar una arquitectura ya planteada, un diseño y una implementación, hacen que se sesgue toda posibilidad de agregar nuevos componentes y de implementaciones futuras. Por otro lado se evidenció una falla durante el proceso de integración del portal móvil con los servicios Web. Es claro que los servicios Web exigen a la implementación del portal la posibilidad de enviar mensajes diferidos a usuarios específicos en un momento determinado, sin embargo al integrar las dos aplicaciones se observó que no existe manera alguna de determinar qué usuario debe recibir la información solicitada con anterioridad; por lo tanto, en el momento en que alguno de los servicios Web identifique un evento y se comunique con el portal para que informe al usuario, el mensaje no solo lo recibirá el estudiante que obtuvo el nuevo evento, sino que lo recibirán todos los usuarios que se encuentren activos en el portal móvil (más específicamente en el Espacio Activo) en ese momento. Para solucionar inconveniente indicado y que no afectará el desarrollo del sistema de servicios Web, fue necesario que los servicios Web administren la información correspondiente a los identificadores del Espacio Activo en el cual el usuario se encuentra, el identificador del Agente Usuario que representa al cliente o estudiante en el portal y el identificador del usuario en el portal. La solución que se propuso temporalmente no resulta ser la más ortodoxa, ya que genera dependencia entre la implementación del portal y la de los servicios Web, dado que la información que maneja internamente el portal no debe interferir ni atañer de ninguna manera la implementación previamente creada de los servicios Web; sin embargo, en el momento en que se dio inicio a la implementación de la comunicación entre las dos aplicaciones, fue ineludible cambiar el desarrollo y la visión de los servicios Web. Es importante anotar que habría sido igualmente posible administrar esta información directamente desde el portal, no obstante se requería de una serie de cambios importantes en la arquitectura y diseño del mismo para lograr que los servicios Web no conocieran esta información. Por último, vale la pena mencionar una falencia encontrada en el código fuente del portal, no tan relevante como las mencionadas anteriormente pero si necesaria de analizar. Dicha falencia hace referencia a que se puede entrever la dependencia existente entre la localización del portal móvil, sus archivos de configuración, y la ejecución correcta del mismo; en otras palabras, en cualquier circunstancia en la cual sea necesario mover el aplicativo a un servidor o máquina distinta será inevitable modificar el código fuente para redireccionar ciertos archivos de. 30.

(31) configuración, compilarlo nuevamente y crear los componentes para desplegarlos en el servidor, imposibilitando su portabilidad e integrabilidad. 8.1. Propuestas De Cambio Al Portal Móvil. Habiendo presentado las falencias más relevantes en la implementación del portal, basta con proponer medidas que aseguren la verdadera flexibilidad del mismo. En principio se propone analizar y discutir si es necesario mantener los componentes planteados del modulo de la Unidad de Espacio Activo, ya que es claro que el módulo de Unidad de Espacio Activo requiere de un gran cambio a nivel de arquitectura y que muchos de los componentes existentes deberán ser cambiados. No obstante, sería conveniente profundizar si cada uno de los componentes ofrece un valor agregado particular para el correcto y adecuado funcionamiento de la unidad. Cabe mencionar que algunos de los componentes existen sólo por el diseño general de cada uno de los módulos del portal y no porque en verdad la unidad lo requiera. En segunda instancia, para solucionar el inconveniente referente al manejo de los usuarios en el portal, se debe realizar un desarrollo adicional en el cual en alguno de los módulos existentes se mantenga la solicitud de activación realizada por los clientes en Sicua o Correo, de tal forma que cuando llegue una respuesta asíncrona de un servicio Web, el portal tenga la capacidad de identificar a que usuario especifico deberá enviar el mensaje con base en la solicitud previamente realizada. De esta manera se implementa de forma concreta lo expuesto en el documento del portal móvil, donde se plantea la posibilidad de ofrecer la solicitud de servicios diferidos en los cuales las peticiones y respuestas no son sincrónicas, es decir no se retorna un resultado cuando se realiza un llamado a un servicio Web13 En cuanto a la falla existente en la implementación por la dependencia del código y la localización de los archivos de configuración de los componentes, conviene sugerir que se cree un solo archivo de propiedades el cual contenga todas las referencias mencionadas a la localización del portal, de tal manera que cuando el proyecto sea trasladado a otra máquina no sea necesario modificar el código fuente, ni tampoco se tenga que recompilar, ni crear los componentes nuevamente.. 13. GARCÍA RONDON, Richard. Diseño De Servicios Web Para Una Arquitectura De Un Sistema De Comunicación Intermodulos Para Sistemas Sensibles Al Contexto. Bogotá: Universidad de los Andes, 2006. 56 p. 31.

(32) 9. PROPUESTA DE IMPLEMENTACIÓN FUTURA. Al haber abordado ya el desarrollo del proyecto en sí, es importante hablar sobre posibles implementaciones futuras basándose en la conexión lograda a Sicua y correo. A continuación se nombran las más relevantes: 1. La propuesta más interesante a realizar es la administración adecuada de los usuarios en los servicios Web a través de un mecanismo de seguridad, de tal manera que cada uno de los servicios no tenga en memoria todo el tiempo el usuario y la clave de acceso. a. Es posible que, por medio del componente de gestor de usuarios (no implementado aún), no sea el servicio Web el que maneje la información del usuario, sino que sea el portal móvil el que envíe los datos de login y clave. Así mismo, se debe implementar un modo de encripción de los datos de acceso del usuario para una seguridad aún mayor. 2. Actualmente la implementación se realizó para que el sistema indique la materia en la cual se recibió una nueva nota, sin embargo no es posible ver la nota como tal; el presente trabajo establece las bases adecuadas para que, en un futuro, se pueda ver una nota especifica a través de “Sicua”. 3. También será posible trabajar en la visualización de nuevos comentarios en los foros de “Sicua”, permitiendo así que el estudiante se encuentre actualizado con la información más pertinente y en el momento adecuado. 4. El desarrollo de la conexión en el proyecto actual, permite contemplar la opción de ver las características básicas de una tarea asignada en “Sicua”, de tal manera que el estudiante sepa los requisitos que debe tener para hacer la tarea sin necesidad de ir a consultar Sicua directamente. 5. Por otro lado, se puede ofrecer la opción de visualización del texto del correo recibido; así mismo, ofrecer en el servicio de correo mas opciones de filtrado como los son el emisor, el asunto, y la fecha, entre otros. 6. Es importante la creación de un cliente móvil de tal forma que se pueda probar la real movilidad del aplicativo 7. Valdría la pena agregar una opción en la interfaz grafica donde, en el momento en el cual se le informa al estudiante que ha recibido un nuevo mensaje, el usuario pueda hacerle clic al mismo para consultar su contenido.. 32.

(33) 8. Finalmente, se puede evaluar la posibilidad de implementar un módulo que pueda leer y abstraer información de cualquier pagina HTTP, de tal manera que la obtención de datos sea generalizada, y no dependa de las paginas y de sus próximos cambios. Es decir que no sea una conexión como la que tiene el servicio Web de Sicua actualmente, sino que independientemente de la página, se puedan tomar los datos más importantes.. 33.

(34) 10. CONCLUSIONES. Los resultados de la presente investigación arrojan conclusiones positivas frente al objetivo final propuesto inicialmente, el cual busca un flujo constante, rápido y eficiente de la información útil a los estudiantes de la Universidad de los Andes. En primera instancia, la conexión lograda con Sicua y el correo a través del portal móvil representa un avance significativo en cuanto a la disponibilidad y obtención de información por parte de los alumnos de la Universidad. Al iniciar el desarrollo acá propuesto era claro que la interacción que se pensaba realizar con el portal móvil representaba ciertos desafíos, dado que era necesario el cambio de plataforma del mismo; no obstante, no se esperaba encontrar errores lógicos y de diseño, hecho que representó el cambio del desarrollo ya implantado en los servicios Web, además de un nuevo planteamiento en el diseño del portal móvil para lograr la interconexión entre los dos aplicativos. El nuevo planteamiento de la arquitectura del portal móvil, logró la interconexión buscada, sin embargo el diseño del mismo continúa mostrando un error importante a nivel de diseño, y el reto más importante para darle continuidad a las investigaciones hechas en torno a este tema es el rediseño de la arquitectura de dicho portal, a nivel de las unidades de espacio activo, así como en el manejo de los usuarios que se encuentran activos en el mismo. Es necesario analizar en detalle los problemas identificados y expuestos en el presente trabajo, para de esta forma, sea posible crear nuevos desarrollos que tornen la arquitectura del portal móvil más robusta como un todo, incluyendo sus servicios Web. Valdría la pena tener en cuenta las propuestas de implantación futuras expuestas en el punto 11.. 34.

(35) 11. REFERENCIAS. •. GARCÍA RONDON, Richard. Diseño De Servicios Web Para Una Arquitectura De Un Sistema De Comunicación Intermodulos Para Sistemas Sensibles Al Contexto: Portal de Servicios Móviles. Bogotá: Universidad de los Andes, 2006. 122 p.. •. JAVATM SECURE SOCKET EXTENSION (JSSE): for the JavaTM 2 SDK, Standard Edition, v 1.4. En: Reference Guide [en línea]. Disponible en <http://vip.cs.utsa.edu/java/jdk1.4.0/docs/guide/security/jsse/JSSERefGuide. html>. •. APACHE. Jakarta Commons HTTPClient: User Guide. En: The HttpClient user guide [en línea]. Disponible en <http://jakarta.apache.org/commons/httpclient/userguide.html>. •. SUN MICROSYSTEMS, INC. JavaMail API Documentation. En: The JavaMailTM API [en línea. Disponible en <http://java.sun.com/products/javamail/javadocs/index.html>. •. RED HAT, INC. JBoss Web Services User Guide. En: JBoss Portal [en línea]. Disponible en <http://labs.jboss.com/portal/jbossws/userguide/en/html/introduction.html>. •. CHAPPELL David y JEWELL Tyler. Java Web Services. O’Reilly. 2002. 249 p.. •. SUN MICROSYSTEMS, INC. Web Services Made Easier: The Java APIs and Architectures for XML. A Technical White Paper. 2 ed. San Antonio, 2001. 31 p.. •. TANENBAUM Andrew S. Computer Networks. 4 ed. New Jersey: Prentice, 2003. 674 p.. •. GRAHAM Steve., et al. Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI. 2 ed. Indianapolis: Sams Publishing, 2005. 817 p.. 35.

(36) ANEXO A ESPECIFICACIÓN HERRAMIENTAS Y EJECUCIÓN DEL PROYECTO. 36.

(37) Herramientas Utilizadas Base de datos: MySql Server 5.0 Servidor de aplicaciones:- JBoss 4.0.2 para la ejecución del servidor Web y del portal móvil - JBoss 4.0.4 GA para crear los descriptores de los servicios Web por medio de la herramienta wstools Edición estándar de la plataforma Java (JDK): Java 1.5 SDK Herramienta Java de desarrollo: JDSE Development Kit 5.0 Update 9 Editor XML: Altova XMLSpy 2007 Herramienta de Diseño UML: Altova UModel Estructura de carpetas Raíz: Se encuentran los archivos .class Src: Fuentes de los servicios Web - Model: Modelo del negocio - Correo o Sicua: Service Endpoint Lib: Librerias pertinentes para la correcta compilación y ejecución del proyecto META-INF: Archivos de configuración y de mapeo del servidor Web Wsdl: Contiene el archivo descriptor de los servicios Web War: Cada uno de los servidores Web tiene un archivo .war que agrupa las clases y documentos necesarios para crear una aplicación Web en java Ejecución del proyecto Servicios Web Para cada uno de los servicios Web es necesario crear los archivos de configuración y los descriptores para la correcta ejecución del servicio. 1. En los servicios Web se debe configurar el archivo build.properties, donde se indique la correcta ruta del JBoss 4.0.4 GA o superior y la ruta en el classpath en donde se encuentra el proyecto montado. 2. A continuación se debe ejecutar en Ant la tarea “generate-ws-sources”, que compilará los archivos fuente y creará los descriptores correspondientes al servicio Web.. 37.

(38) 3. Por último se debe dar inicio a la tarea de Ant, “Deploy” la cual creará el archivo .war y desplegará el servicio Web en el servidor de aplicaciones. Nota: En caso de que se desee montar el servicio Web en el mismo servidor de aplicaciones en el cual se ejecuta el portal móvil, primero es necesario crear los descriptores con un JBoss 4.0.4 GA o superior y a continuación desplegar el .war en el JBoss deseado. Unidad de Espacio Activo Para ejecutar la Unidad de Espacio Activo que contiene los servicios Web ofrecidos, basta con cambiar la configuración de unos archivos. 1. En primera instancia se debe cambiar el puerto en el cual corre JBoss en el archivo descriptor de los servicios de la Unidad, UAndes.xml. 2. Es necesario configurar igualmente el archivo build.properties, indicando la ruta del JBoss y la ruta en la cual se encuentra montada la Unidad de Espacio Activo 3. A continuación se ejecuta la tarea de Ant, “deploy”, la cual compila, crea el ear14 y lo despliega en el servidor de aplicaciones.. 14. Agrupa los archivos war y jar. Contiene las clases Java y los documentos necesarios para crear una aplicación Web. 38.

(39) ANEXO B DIAGRAMAS DE SECUENCIA DE LOS SERVICIOS OFRECIDOS. 39.

(40) Activación de usuario en el servicio Web. 40.

(41) Desactivación del usuario en el servicio Web. 41.

(42) Envío de información por parte del servicio Web hacia el portal. 42.

(43)