Sistema prototipo de telelaboratorio de equipos de red (TELELAB)

Texto completo

(1)Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Miguel Enrique Díaz Solarte Germán Andrés Collazos Lebaza. Universidad del Cauca Facultad de Ingeniería Electrónica y Telecomunicaciones. Departamento de Telemática Aplicaciones y Servicios sobre Internet – Tele-educación Popayán 2012.

(2) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Miguel Enrique Díaz Solarte Germán Andrés Collazos Lebaza Trabajo de Grado presentado para optar al título de Ingeniero en Electrónica y Telecomunicaciones. Director: Ing. Javier Alexander Hurtado. Universidad del Cauca Facultad de Ingeniería Electrónica y Telecomunicaciones. Departamento de Telemática Aplicaciones y Servicios sobre Internet – Tele-educación Popayán 2012.

(3) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). CONTENIDO CAPÍTULO 1 ...................................................................................................................................... 9 INTRODUCCIÓN .............................................................................................................................. 9 1.1.. DEFINICIÓN DEL PROBLEMA ........................................................................... 9. 1.2.. DEFINICIÓN DEL SERVICIO Y ALCANCE DEL PROYECTO........................... 10. 1.3.. FUNCIONALIDADES DE TELELAB .................................................................. 10. 1.4.. CONSIDERACIONES ACERCA DE TELELAB .................................................. 11. 1.5.. OBJETIVOS ...................................................................................................... 12. 1.5.1.. Objetivo General......................................................................................... 12. 1.5.2.. Objetivos Específicos ................................................................................. 12. CAPÍTULO 2 .................................................................................................................................... 13 ESTADO DEL ARTE ....................................................................................................................... 13 2.1.. TRABAJOS RELACIONADOS........................................................................... 13. 2.1.1. 2.2.. Laboratorios remotos de redes basados en Internet ................................... 14. TECNOLOGÍAS UTILIZADAS PARA EL DESARROLLO DE TELELAB ............ 19. 2.2.1.. Criterios para la selección de tecnologías ................................................... 19. 2.2.2.. Selección de tecnologías ............................................................................ 19. 2.2.3.. Uso de código abierto ................................................................................. 39. CAPÍTULO 3 .................................................................................................................................... 42 DISEÑO DE TELELAB ................................................................................................................... 42 3.1.. DEFINICIONES ................................................................................................. 42. 3.2.. SERVICIOS DE TELELAB................................................................................. 42. 3.3.. MODELO DE CASOS DE USO ......................................................................... 43. 3.3.1.. Modelo de casos de uso del negocio .......................................................... 43. 3.3.2.. Diagrama de casos de uso del sistema ...................................................... 48. 3.4.. MODELO DE SUBSISTEMAS ........................................................................... 49. 3.4.1.. Servidor de gestión remota ......................................................................... 50. 3.4.2.. Mediador .................................................................................................... 50. 3.4.3.. Controlador de dispositivos......................................................................... 50. 3.4.4.. Sistema conmutador ................................................................................... 50. 3.5.. COMPORTAMIENTO DINÁMICO ..................................................................... 50. 3.5.1.. Servicio de gestión de usuarios y cursos .................................................... 50. 3.5.2.. Servicio de gestión de dispositivos ............................................................. 51. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 1.

(4) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 3.5.3.. Servicio de gestión de conexiones .............................................................. 52. 3.5.4.. Servicio de acceso remoto y registro de interacciones ............................... 53. 3.5.5.. Servicio de conexión remota....................................................................... 53. 3.5.6.. Servicio de reservación de prácticas .......................................................... 54. 3.5.7.. Servicio de chat .......................................................................................... 55. 3.6.. MODELO DE IMPLEMENTACIÓN DE REFERENCIA ....................................... 55. 3.6.1.. Componentes del servidor de gestión remota ............................................. 56. 3.6.2.. Componentes del mediador ........................................................................ 56. 3.6.3.. Componentes del servidor de dispositivos .................................................. 56. 3.6.4.. Componentes del Sistema de Conmutación ............................................... 57. CAPÍTULO 4 .................................................................................................................................... 58 IMPLEMENTACIÓN DE TELELAB .............................................................................................. 58 4.1.. CONSIDERACIONES DE DISEÑO E IMPLEMENTACIÓN DE TELELAB ......... 58. 4.2.. MODELO DE DATOS ........................................................................................ 60. 4.2.1.. SERVICIO DE ADMINISTRACIÓN ............................................................. 60. 4.2.2.. SERVICIO DE LABORATORIO REMOTO ................................................. 61. 4.3.. DESCOMPOSICIÓN DE TELELAB ................................................................... 63. 4.3.1.. Aplicación de gestión .................................................................................. 64. 4.3.2.. Mediador de mensajes ............................................................................... 74. 4.3.3.. Servidor de dispositivos .............................................................................. 74. 4.3.4.. Sistema conmutador ................................................................................... 79. CAPÍTULO 5 .................................................................................................................................... 82 PRUEBAS Y RESULTADOS .......................................................................................................... 82 5.1.. METODOLOGÍA DE EVALUACIÓN FUNCIONAL ............................................. 82. 5.2.. PLANEACIÓN DE LA EVALUACIÓN FUNCIONAL ........................................... 82. 5.2.1.. Descripción de la experiencia ..................................................................... 82. 5.2.2.. Características evaluadas........................................................................... 83. 5.2.3.. Componentes hardware involucrados en la experiencia ............................. 84. 5.3.. PROCEDIMIENTO DE EVALUACIÓN FUNCIONAL ......................................... 86. 5.3.1.. Experiencia 1 .............................................................................................. 86. 5.3.2.. Experiencia 2 .............................................................................................. 89. 5.4.. CONCLUSIONES .............................................................................................. 90. CAPÍTULO 6 .................................................................................................................................... 91 2. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(5) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). CONCLUSIONES, APORTES Y TRABAJOS FUTUROS ............................................................ 91 6.1.. CONCLUSIONES .............................................................................................. 91. 6.2.. APORTES ......................................................................................................... 91. 6.3.. TRABAJOS FUTUROS...................................................................................... 92. BIBLIOGRAFÍA............................................................................................................................... 93 ANEXOS........................................................................................................................................... 95. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 3.

(6) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). LISTA DE FIGURAS pág. Figura 1. Diagrama inicial de despliegue. ........................................................................ 11 Figura 2. Opciones iniciales. ............................................................................................ 15 Figura 3. Reserva de práctica predefinida por los cursos de la academia CISCO............ 15 Figura 4. Consola de dispositivo. ..................................................................................... 16 Figura 5. Opciones de cuenta de estudiante. ................................................................... 17 Figura 6. Interfaz de creación de reserva. ........................................................................ 17 Figura 7. Bloques de dispositivos..................................................................................... 18 Figura 8. Interfaz de creación de reserva. ........................................................................ 18 Figura 9. Diagrama de arquitectura de alto nivel para XMPP. .......................................... 22 Figura 10. Esquema de conexión de una red IRC. ........................................................... 23 Figura 11. Patrón MVC en Rails. ..................................................................................... 28 Figura 12. Despliegue de aplicación Rails (componentes más sobresalientes)................ 29 Figura 13. AJAX utilizando el procedimiento de código bajo demanda. ........................... 31 Figura 14. Variables en SASS. ........................................................................................ 35 Figura 15. Ejemplo de anidamiento en SASS. ................................................................. 35 Figura 16. Ejemplo de mixins en SASS............................................................................ 35 Figura 17. Herencia en selectores. .................................................................................. 36 Figura 18. Mapa conceptual del software libre y de código abierto. ................................. 40 Figura 19. Diagrama de casos de uso del negocio. ......................................................... 44 Figura 20. Diagrama de objetos del negocio: administrar cursos y docentes. .................. 45 Figura 21. Diagrama de objetos del negocio: gestionar dispositivos. ............................... 45 Figura 22. Diagrama de objetos del negocio: formular prácticas. ..................................... 45 Figura 23. Diagrama de objetos del negocio: realizar prácticas. ...................................... 46 Figura 24. Diagrama de objetos del negocio: revisar prácticas. ....................................... 46 Figura 25. Diagrama de actividades................................................................................. 47 Figura 26. Diagrama de casos de uso del sistema. .......................................................... 48 Figura 27. Diagrama de subsistemas de Telelab. ............................................................ 49 Figura 28. Diagrama de secuencia para el servicio de gestión de usuarios y cursos. ...... 51 Figura 29. Diagrama de secuencia para el servicio de gestión de dispositivos. ............... 51 Figura 30. Diagramas de secuencia para el servicio de gestión de conexiones. .............. 52 Figura 31. Diagrama de secuencia para los servicios de acceso remoto y registro de interacciones. .................................................................................................................. 53 Figura 32. Diagrama de secuencia para el servicio de conexión remota. ......................... 54 Figura 33. Diagrama de secuencia para el servicio de reservación de prácticas.............. 54 Figura 34. Diagrama de secuencia para el servicio de chat. ............................................ 55 Figura 35. Diagrama de implementación de referencia de Telelab................................... 55 Figura 36. Diagrama de entidad-relación simplificado. ..................................................... 60 Figura 37. Diagrama de despliegue de Telelab en las instalaciones de la Universidad del Cauca. ............................................................................................................................. 63 Figura 38. Componentes de la aplicación de gestión. ...................................................... 64 Figura 39. Asignación de tareas en Telelab para los componentes de la aplicación de gestión. ............................................................................................................................ 65 Figura 40. Proceso de multicast en un entorno de práctica por parte de Faye. ................ 65 Figura 41. Obtención de librería de Faye. ........................................................................ 66 Figura 42. Consumo de servicio de multicast de Faye por los demás servidores. ............ 66 4. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(7) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Figura 43. Máquina de estados para una práctica. .......................................................... 67 Figura 44. Eventos para la transición entre estados una práctica en relación con el tiempo. ........................................................................................................................................ 67 Figura 45. Restablecimiento de dispositivos y conexiones al finalizar una práctica. ......... 68 Figura 46. Componentes software de la aplicación web. ................................................. 69 Figura 47. Componentes de la aplicación web articulados con el patrón MVC................. 69 Figura 48. Módulos adicionales para soportar las comunicaciones con los servidores Faye y Gateway........................................................................................................................ 71 Figura 49. Componentes software de la aplicación de Gateway. ..................................... 72 Figura 50. Módulo IRCGateway. ...................................................................................... 73 Figura 51. Relación uno a uno para canales IRC y Faye, efectuada por el módulo IRCGateway. ................................................................................................................... 74 Figura 52. Red IRC existente en Telelab. ........................................................................ 74 Figura 53. Mapeo uno a uno de canales IRC a puertos COM por parte del servidor de dispositivos. ..................................................................................................................... 74 Figura 54. Diagrama de componentes de un servidor de dispositivos. ............................. 75 Figura 55. Llamada REST al servidor Telelab por parte del módulo configurador en el servidor de dispositivos. ................................................................................................... 76 Figura 56. Transformación de la configuración en formato JSON a objetos JAVA. .......... 77 Figura 57. Ejemplo de la acción del Telebot con dos dispositivos. ................................... 78 Figura 58. Clúster de servidores de dispositivos. ............................................................. 78 Figura 59. Ejemplo de conexión de dispositivos en el laboratorio remoto. ....................... 79 Figura 60. Ejemplo de topología en diagrama simplificado. ............................................. 80 Figura 61. Ejemplo de topología en diagrama simplificado, mostrando los puertos. ........ 81 Figura 62. Conexión física utilizando un mediador (Switch Principal) para la topología de ejemplo. ........................................................................................................................... 81. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 5.

(8) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). LISTA DE TABLAS pág. Tabla 1. Frameworks considerados para desarrollo web en Telelab. ............................... 25 Tabla 2. Principales características del Servidor Telelab. ................................................ 84 Tabla 3. Características de los equipos de red. ............................................................... 85 Tabla 4. Recopilación de resultados de la evaluación funcional para la experiencia 1. .... 87 Tabla 5. Recopilación de resultados de la evaluación funcional para la experiencia 2. .... 89. 6. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(9) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). LISTA DE ANEXOS pág. ANEXO A ......................................................................................................................................... 96 PRUEBA DE EXPLORACIÓN........................................................................................................ 96 ANEXO B ....................................................................................................................................... 107 MANUAL DE USUARIO .............................................................................................................. 107 ANEXO C ....................................................................................................................................... 134 GUÍA PARA EL ESTABLECIMIENTO DEL ENTORNO DE DESARROLLO Y EJECUCIÓN ......................................................................................................................................................... 134 ANEXO D ....................................................................................................................................... 146 ENCUESTA DE EVALUACIÓN FUNCIONAL .......................................................................... 146 ANEXO E ....................................................................................................................................... 150 GUÍA DE LABORATORIO PARA LA EJECUCIÓN DE PRÁCTICA CON DISPOSITIVOS DE RED ................................................................................................................................................. 150 ANEXO F........................................................................................................................................ 154 CASOS DE USO DEL SISTEMA EN FORMATO DE ALTO NIVEL ........................................ 154. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 7.

(10) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). RESUMEN. El presente trabajo enmarca el desarrollo de un prototipo funcional de laboratorio de redes denominado Telelab, el cual permite reservar y ejecutar prácticas de laboratorio con dispositivos de red reales (e.g. routers y switches) de forma remota a través de Internet. Se desarrolla con el propósito de elevar la tasa de realización de prácticas de laboratorio en redes telemáticas al utilizar de mejor manera los recursos disponibles para ejecutarlas. Como caso de estudio, es desplegada la prueba funcional del prototipo en el entorno del Laboratorio de Redes de la Academia Cisco de la FIET situado en las instalaciones de la Universidad del Cauca. Para especificar los procesos de diseño, implementación y prueba de Telelab se ha estructurado este documento en los siguientes capítulos: Capítulo 1: Introduce al lector en el contexto del proyecto, indicando la necesidad y el aporte del desarrollo de recursos de acceso remoto, en particular con la implementación de Telelab. Comprende los conceptos necesarios para entender y delimitar el entorno de Telelab; especificando el propósito, las características y requisitos generales para su construcción y despliegue. Capítulo 2: Comprende el estudio de las herramientas y tecnologías pertinentes para el desarrollo de Telelab, así como trabajos relacionados cuyas funcionalidades son semejantes al trabajo propuesto en este proyecto. Capítulo 3: Presenta el diseño general de Telelab en cuanto a sus subsistemas, así como el comportamiento dinámico de los mismos. Capítulo 4: Particulariza la construcción de Telelab, exponiendo cada uno de sus componentes y examinando sus detalles de implementación específicos. Capítulo 5: Presenta el procedimiento utilizado para la evaluación funcional, así como el informe de resultados derivado de las pruebas. Capítulo 6: Presenta las conclusiones, aportes y trabajos futuros del trabajo de grado. Adicionalmente al documento de trabajo de grado se agregan 6 anexos, los cuales deberán consultarse para complementar en varios de los temas más importantes que se estudiaron y utilizaron para el desarrollo del presente proyecto. Anexo A: Prueba de exploración. Anexo B: Manual de usuario. Anexo C: Guía para el establecimiento del entorno de desarrollo y ejecución. Anexo D: Encuesta de evaluación funcional. Anexo E: Guía de laboratorio para la ejecución de práctica con dispositivos de red. Anexo F: Casos de uso del sistema en formato de alto nivel.. 8. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(11) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). CAPÍTULO 1 INTRODUCCIÓN La búsqueda de estrategias que motiven una mayor participación de los estudiantes de educación superior en su proceso de aprendizaje es un factor que promueve la creación de herramientas didácticas capaces de proporcionar un mayor cubrimiento estudiantil [1], cuyo fin sea el establecimiento de horarios flexibles de estudio que optimicen el uso de recursos humanos y físicos en la realización de prácticas educativas. El uso de las Tecnologías de la Información y las Comunicaciones (TIC) son un gran aporte en la exploración de herramientas que permitan lograr este fin, así como la utilización de Internet para la difusión de servicios dado que soportan un notable avance en el desarrollo de la educación a distancia, dotando al estudiante de un enorme rango de recursos, y en muchos casos, sin limitaciones de tiempo o espacio [2] [3]. Teniendo en cuenta lo anterior, y sumando a ello un amplio rango de tecnologías de código abierto para el desarrollo rápido de aplicaciones basadas en Internet, se dan las condiciones suficientes para emprender el desarrollo de servicios de acceso remoto1 con la capacidad de proporcionar un aprendizaje y que se adapten a las necesidades de docentes y estudiantes. 1.1.. DEFINICIÓN DEL PROBLEMA. En el Laboratorio de Redes de la Academia Cisco de la Facultad de Ingeniería Electrónica y Telecomunicaciones (FIET) en la Universidad del Cauca2, se ha identificado un escenario en el que puede aplicarse el acceso remoto vía Internet a equipos físicos de laboratorio para desarrollar prácticas con los mismos. Actualmente, las prácticas en los cursos de telemática y afines involucran la presencia de los estudiantes en las aulas, limitando la disponibilidad de los equipos con los cuales se desarrollan las prácticas; asimismo, la configuración manual del entorno físico reduce el tiempo de actividad en el laboratorio generando inconformidad y búsqueda de espacios extracurriculares para completar las tareas asignadas. Lo anterior conlleva a las siguientes implicaciones:   . El tiempo neto en el cual se desarrollan las prácticas es muy corto. El número de prácticas con el equipo físico a lo largo del curso es muy bajo siendo en promedio de tres (3) prácticas por curso3. Los estudiantes no pueden realizar muchas de las prácticas del laboratorio de redes en entornos reales, por lo que deben emplear simuladores para realizarlas. Ejemplos de estas herramientas de simulación son: Cisco Packet Tracer4, OPNET5, entre otros.. 1. Acceso remoto: en redes de computadoras, acceder desde una computadora a un recurso ubicado físicamente en otro lugar, a través de una red local o externa (como Internet). 2 En adelante, cada vez que se traiga en contexto al conjunto “laboratorio de redes” o relacionado, se estará haciendo referencia al Laboratorio de Redes de la Academia Cisco de la FIET, presente en las instalaciones de la Universidad del Cauca. 3 Curso de Énfasis 1 de Telemática - II periodo de 2009 - FIET de la Universidad del Cauca a cargo del Ingeniero Iván Hernández, entre otros cursos prácticos.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 9.

(12) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab).  . La revisión de las prácticas sólo puede realizarse en el tiempo restante de clase. No todos los estudiantes pueden interactuar con los recursos del laboratorio.. Las anteriores implicaciones generan los siguientes interrogantes:   . ¿Cómo se pueden incrementar las horas de práctica con equipo real? ¿Cómo pueden los estudiantes realizar las prácticas sin tener que estar físicamente frente a los dispositivos de red? ¿Qué se puede hacer para que el docente pueda supervisar de mejor forma las prácticas?. Como respuesta a las necesidades presentadas se analiza, diseña y desarrolla un sistema prototipo de laboratorio de redes de acceso remoto: Telelab.. 1.2.. DEFINICIÓN DEL SERVICIO Y ALCANCE DEL PROYECTO. Para contextualizar el alcance de Telelab en cuanto a sus funcionalidades, es debido establecer las siguientes definiciones:   . Práctica: Es una actividad que asocia un conjunto de equipos remotos, un usuario o un grupo de usuarios y un intervalo de tiempo para ser realizada. Entorno de práctica: Es el escenario en el que el usuario o grupo de usuarios de una práctica, realiza las acciones relacionadas con los equipos remotos reservados para la misma. Gestión: En el contexto de este documento el término “gestión” se debe entender como la agrupación de las funcionalidades básicas de creación, lectura, modificación y eliminación (CRUD, Create, Read, Update and Delete) que pueden realizarse sobre un recurso.. Telelab es un sistema prototipo que permite realizar prácticas o laboratorios de red de forma remota. Se desarrolla a modo de aplicación web donde usuarios registrados pueden acceder para separar horarios de práctica y disponer de los dispositivos 6 reales existentes de forma remota, siendo así muy diferente de herramientas de simulación. 1.3.. FUNCIONALIDADES DE TELELAB. En esencia, Telelab otorga un conjunto de funcionalidades para el control a distancia de dispositivos de red tales como switches y routers, así como funciones básicas de gestión. Estas funcionalidades son puntualizadas a continuación:    . Soporte básico para la gestión de usuarios. Soporte básico para la gestión de cursos. Reservación de prácticas de laboratorio. Acceso remoto a las consolas de los dispositivos de red (switches y enrutadores).. 4. Herramienta Packet Tracer - http://www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html Herramienta OPNET - http://www.opnet.com/ 6 Dispositivo: se utiliza indistintamente como equivalente al término “dispositivo de red”, “equipo” o “equipo de red” 5. 10. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(13) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab).     . Conexión de los dispositivos remotos en cualquier topología7. Registro de las interacciones de los usuarios con las consolas de los equipos por cada entorno de práctica. Soporte multiusuario en tiempo real en el entorno de práctica. Servicio embebido de mensajería instantánea con soporte de presencia para cada entorno de práctica. Configuración vía web del mapeo físico-lógico de conexiones.. A manera de introducción al sistema se muestra en la Figura 1 el diagrama simplificado de despliegue de la aplicación.. Figura 1. Diagrama inicial de despliegue. Como es mostrado en la Figura 1, esencialmente los usuarios acceden a través de Internet a Telelab y de esta forma establecen una comunicación con los dispositivos remotos para configurarlos utilizando la interfaz de consola.. 1.4.. CONSIDERACIONES ACERCA DE TELELAB. Telelab está pensado como una solución software, no sujeta a requerimientos de hardware especial, por lo cual busca convertirse en una solución alternativa de bajo costo para un uso más eficiente de los recursos hardware involucrados en la realización de prácticas de redes. De igual forma se espera que el desarrollo del presente proyecto sirva de guía en el diseño y construcción de laboratorios de acceso remoto, además de contribuir al soporte de programas virtuales, en búsqueda de una mayor responsabilidad de los estudiantes en relación a la labor académica. Por último, Telelab se considera muy importante para el programa de Ingeniería Electrónica y Telecomunicaciones, en especial para el énfasis en Telemática y asignaturas de Redes en el programa de Ingeniería de Sistemas, dada la posibilidad de ser establecido como un servicio de tiempo completo convirtiéndose en una herramienta adicional a disposición tanto de docentes como estudiantes.. 7. Configuración topológica: hace referencia a topologías compuestas únicamente de conexiones Ethernet, no a aquellas donde estén presentes conexiones serial del tipo DCE/DTE, dado que la conmutación de dichas conexiones requeriría de equipo especializado no disponible para el proyecto.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 11.

(14) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 1.5.. OBJETIVOS. 1.5.1. Objetivo General Diseñar e implementar una solución para el acceso remoto, aplicado al Laboratorio de Redes de la Academia Cisco a cargo del Departamento de Telemática de la Universidad del Cauca, que permita la optimización del uso de equipos de laboratorio. 1.5.2. Objetivos Específicos  Diseñar una solución para el acceso remoto a los dispositivos reales del laboratorio de redes de la Academia Cisco a cargo del Departamento Telemática de la Universidad del Cauca.  Implementar un prototipo de la solución para el acceso remoto a los dispositivos reales del laboratorio de redes de la Academia Cisco a cargo del Departamento Telemática de la Universidad del Cauca.  Probar el funcionamiento del sistema en el entorno real de las instalaciones de la Universidad del Cauca, con un mínimo de 4 dispositivos controlables e interconectables por los usuarios de forma remota.. 12. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(15) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). CAPÍTULO 2 ESTADO DEL ARTE En esta sección son presentadas y analizadas las tecnologías consideradas para la implementación de Telelab, resaltando aquellas seleccionadas para el desarrollo final del prototipo. Como introducción, se presentan inicialmente las generalidades de trabajos comparables a Telelab, siendo éstos laboratorios accedidos remotamente. 2.1.. TRABAJOS RELACIONADOS. El avance en el desarrollo de nuevas tecnologías de la información, ha permitido que los entornos de experimentación sean reemplazados o complementados por laboratorios virtuales y/o remotos. Un laboratorio remoto es un entorno en línea para el desarrollo de las habilidades de práctica de los estudiantes; éstos, no consisten en simulaciones, por el contrario, son experimentos reales sobre equipos situados en un laboratorio real [4]. Entre los proyectos de laboratorios remotos publicados, se destaca: . Open Network Laboratory (ONL): describe un entorno de prueba de enrutamiento remotamente accesible, usando routers de alto rendimiento; de esta forma, el sistema es construido mediante un conjunto de routers de alto nivel los cuales son extensibles y fácilmente configurables a través de un entorno de interfaces gráficas intuitivas denominado RLI (Remote Laboratory Interface) [5].. . Didactical Issues of a Remote Network Laboratory: presenta una plataforma para cursos a distancia en la que varios usuarios asisten a ejercicios en muchos servidores distribuidos localmente. El curso incluye la plataforma de administración automatizada de estudiantes y la programación de los módulos de laboratorio. Igualmente, los estudiantes pueden trabajar con cualquier navegador web estándar y no necesitan instalar software adicional [6].. . Remote Real Laboratory: presenta un proyecto el cual permite el despliegue de cursos que ofrecen ejercicios prácticos en el área de las telecomunicaciones y redes de computadoras a los estudiantes. Los cuales realizan los ejercicios de forma práctica a través de las siguientes capacidades soportadas por el sistema: transferencia de archivos, ejecución remota y generación de terminales virtuales [7].. . Laboratorio remoto para la enseñanza de redes TCP8/IP9: describe un laboratorio remoto para la enseñanza a distancia de algunos conceptos de redes tales como la interconexión de redes mediante IP y los problemas derivados del uso conjunto de IPv4 e IPv6. Los usuarios acceden al laboratorio a través de una interfaz web y pueden realizar y estudiar distintas configuraciones de una red privada [8].. 8 9. Protocolo de Control de Transmisión (TCP, Transmission Control Protocol). Protocolo de Internet (IP, Internet Protocol).. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 13.

(16) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Dentro de este marco se han mencionado plataformas y herramientas que permiten el despliegue y la ejecución de laboratorios remotos en el área de las redes de telecomunicaciones. Sin embargo, no presentan un sistema integrado que soporte en un único entorno de administración las capacidades de: gestión de usuarios basadas en roles de ambientes de aprendizaje, comunicación instantánea entre los participantes de las practicas remotas, reservación de prácticas, configuración del sistema de conmutación de terminales físicos, interfaz gráfica de usuario portable y almacenamiento del avance en las prácticas de los participantes de la misma. 2.1.1. Laboratorios remotos de redes basados en Internet En este apartado se hace referencia a herramientas actuales, que permiten el control de dispositivos de red, estableciendo el servicio como una aplicación web. 2.1.1.1.. NETLAB. Es un laboratorio de redes de licencia comercial desarrollado por Network Development Group, Inc. Para instituciones con cursos orientados a redes telemáticas enfocados en prácticas de laboratorio de la Academia Cisco. Este, permite la interacción directa con equipo de red real, así como con máquinas virtuales por medio de Internet. Utiliza el protocolo de red Telnet para el acceso a las funciones remotas de consola de dispositivos [9]. La interfaz expuesta en la Figura 2 pertenece a una cuenta de tipo estudiante y presenta en la pantalla principal las opciones para:   . Acceso a la creación o verificación de reservas (Scheduler). Acceso el servicio de almacenamiento de archivo de configuración de práctica o dispositivo (File Manager). Acceso a los datos personales (Profile).. La Figura 3 presenta un tipo de práctica de laboratorio en ejecución. La topología de red no es libremente configurada por el usuario y existe de manera predefinida (según los practicas de enrutamiento definidas por la Academia Cisco).. 14. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(17) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Figura 2. Opciones iniciales.. Figura 3. Reserva de práctica predefinida por los cursos de la academia CISCO.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 15.

(18) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). En la Figura 3, se observa que el laboratorio permite conexiones DCE. La Figura 4 presenta la interfaz de usuario para la consola de dispositivo. Se observan en la parte inferior las opciones para desconexión y personalización.. Figura 4. Consola de dispositivo. La Figura 5 muestra los privilegios en la aplicación con una cuenta tipo estudiante. Como se observa las opciones de usuario están dispuestas en las pestañas:     . 16. Topology: Muestra la topología de red según la práctica reservada. Action: Permite cambiar el estado de los dispositivos: Apagado, OK Status: Muestra el estado de los dispositivos. Load: Carga las configuraciones de prácticas o dispositivos guardadas. Save: Guarda las configuraciones de prácticas o dispositivos.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(19) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Figura 5. Opciones de cuenta de estudiante. 2.1.1.2.. PacketLife. Es un sistema que provee acceso libre a miembros registrados para el entrenamiento con equipos de red. El registro es gratuito y la solicitud de equipos se hace por medio de reservaciones de bloques de dispositivos [10]. La Figura 6 presenta el horario de visualización de reservas. PacketLife posee interfaces más limitadas y no permite la conexión entre dispositivos.. Figura 6. Interfaz de creación de reserva.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 17.

(20) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). La interfaz mostrada en la Figura 6 no es seleccionable. Como se observa, las reservaciones se realizan por bloques de dispositivos. La Figura 7 muestra los tipos de bloques existentes.. Figura 7. Bloques de dispositivos. La interfaz de creación de reserva se muestra en la Figura 8.. Figura 8. Interfaz de creación de reserva.. 18. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(21) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 2.2.. TECNOLOGÍAS UTILIZADAS PARA EL DESARROLLO DE TELELAB. En esta sección se presentan y analizan las tecnologías consideradas para la implementación de Telelab, resaltando aquellas seleccionadas para el desarrollo final del prototipo. 2.2.1. Criterios para la selección de tecnologías Habiendo determinado las capacidades soportadas por Telelab (sección 1.3), son especificados los siguientes criterios para la selección de las tecnologías aptas para el desarrollo: . Cumplimiento de los requerimientos técnicos: las tecnologías, herramientas, librerías o componentes a utilizar deben cumplir con todas las funcionalidades técnicas necesarias para llevar a cabo la implementación.. . Experiencia de uso: es ideal para el progreso de la implementación que el grupo de desarrolladores del prototipo, tenga una experiencia previa en el uso de la tecnología, herramienta o componente adoptado.. . Curva de aprendizaje: se desea una fácil asimilación de las tecnologías a ser utilizadas, debido a la necesidad de integrarlas para lograr la construcción de la solución.. . Documentación: aspecto esencial en el complemento de la curva de aprendizaje y solución de problemas implicados en el uso de cualquier tecnología; esta documentación puede estar albergada en la web (e.g. páginas principales, blogs10, comunidades virtuales, wikis11, entre otros), literatura impresa o digital, contenidos multimedia, entre otros.. . Tendencia actual: el comportamiento de grupos de desarrolladores sobre las tecnologías, herramientas o componentes adoptadas debe ser tenido en cuenta para dar soporte y confiabilidad sobre las mismas.. . Licencia: es importante involucrar proyectos de código abierto debido a las características de reusabilidad y bajos costos.. 2.2.2. Selección de tecnologías Teniendo en cuenta lo anterior, se procede a detallar las diferentes áreas técnicas indicando su relevancia en la implementación de Telelab. En esta sección se presentan y analizan las tecnologías consideradas para la implementación de Telelab, resaltando aquellas seleccionadas para el desarrollo final del prototipo.. 10 11. Blogs: es un sitio web periódicamente actualizado que recopila cronológicamente textos o artículos de uno o varios autores. Wikis: sitio web cuyas páginas pueden ser editadas por múltiples voluntarios a través del navegador web.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 19.

(22) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 2.2.2.1.. Control de puerto serial. Para el desarrollo del prototipo, el correcto manejo del puerto serial es indispensable para el control de los equipos de laboratorio; siendo la característica fundamental de Telelab el proveer acceso remoto a la consola serial de los mismos, emulando la interacción que se lleva a cabo entre un programa de consola serial (e.g. Hyperterminal) y el equipo hardware (e.g. un enrutador). De esta manera, se definen las siguientes características para la selección de la tecnología más apropiada para este propósito:   . Soporte para comunicación bidireccional asíncrona con el puerto serial. Soporte para múltiples conexiones de puerto serial de manera concurrente. API12 soportada en un lenguaje de programación de alto nivel para el manejo del puerto serial.. Teniendo en cuenta los criterios base para la selección de tecnologías (sección 2.2.1), especialmente el referente a la experiencia de uso, así como los tres (3) específicamente citados para el manejo del puerto serial, se optó por el uso de APIs basadas en el lenguaje de programación Java, lo cual acota el campo de búsqueda a las presentadas seguidamente: 2.2.2.1.1. Java Communications API Java Communications API (javacomm) es la librería base utilizada para la interacción con el puerto serial en el lenguaje de programación Java. Facilita el desarrollo de aplicaciones independientemente de la plataforma de comunicaciones en sistemas integrados (e.g. faxes, módems, terminales de pantalla, entre otros), proporcionando a éstas acceso y control al hardware RS23213 [11]. No obstante presta un manejo de muy bajo nivel al comunicarse a partir de señales de control muy específicas. 2.2.2.1.2. Giovynet Giovynet cuenta con controladores14 propios (Giovynet Driver15) para soportar la interacción con los puertos serie así como la instanciación directa de los mismos y manejo eficaz de eventos asíncronos a través de métodos como creación de procesos paralelos y listeners. Está basado en javacomm y provee una interfaz de más alto nivel, evitando muchas de las tareas comunes en el establecimiento de una conexión. Conclusión: Habiendo determinado uno de los criterios para la elección de las librerías como el nivel de abstracción proveído por las API, se prefirió el uso de Giovynet por sobre javacomm como librería Java para el manejo del puerto serial en Telelab por su facilidad de uso e integración.. 12. Interfaz de programación de aplicaciones (API, Application Programming Interface), es el conjunto de funciones, procedimientos o métodos que ofrece cierto servicio para ser utilizado por otro software como una capa de abstracción. También denominadas comúnmente "librerías". 13 Estándar que define un método de comunicación serial asíncrona 14 Controlador: también conocido como “driver”, es un módulo software que permite la interacción entre el sistema operativo de una computadora y un periférico o hardware. 15 Giovynet Driver - http://www.giovynet.com/giovynetDriver_en.html. 20. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(23) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 2.2.2.2.. Control de la comunicación con los dispositivos. El requerimiento de la interacción con dispositivos de red para el prototipo Telelab, hace preciso establecer un modo de comunicación de dos vías entre el desarrollo que controle el flujo de mensajes hacia los dispositivos y la implementación que se comunique directamente con ellos. Dicha comunicación debe realizarse en tiempo real y contar con mecanismos para dirigir el tráfico de la información, suponiendo el establecimiento de conexiones simultáneas por cada equipo y que permita la interacción con los mismos de forma asíncrona. Por esto se plantean las siguientes alternativas como solución al requerimiento antes nombrado, haciendo uso de tecnologías para el manejo de eventos y mensajes asíncronos: 2.2.2.2.1. Faye Es un sistema de publicación–suscripción de mensajería basado en el protocolo Bayeux. Ofrece servidores para la difusión de mensajes para Ruby, y clientes para su uso en los navegadores web más importantes [12]. El protocolo Bayeux es un protocolo para el transporte de mensajes asincrónicos principalmente sobre HTTP16, con bajo retardo entre el servidor web y un cliente web [13]. Los mensajes se enrutan a través de canales con nombres y se pueden entregar de:   . Servidor a Cliente Cliente a Servidor Cliente a Cliente (por medio del Servidor). También incluye un conjunto sólido de herramientas para la construcción de servidores y clientes simples basados en WebSockets, compatibles con una amplia gama de versiones del protocolo. WebSocket es una tecnología web17 para proporcionar canales de comunicación bidireccionales a través de un único socket TCP. El API de WebSocket está siendo estandarizado por el W3C18, y el protocolo por la IETF19 en el RFC20 6455 [14]. Está diseñado para ser implementado en los navegadores y los servidores web 21, aunque puede utilizarse en cualquier aplicación cliente o servidor. Adicionalmente, sirve para aplicaciones web que requieran comunicaciones en tiempo real bidireccionales.. 16. Protocolo de Transferencia de HiperTexto (HTTP, HyperText Transfer Protocol) Tecnología web: conjunto de herramientas para facilitar el desarrollo de un sitio o aplicación web. Consorcio internacional que produce recomendaciones para la World Wide Web (WWW). 19 Grupo de Trabajo de Ingeniería de Internet (IETF, Internet Engineering Task Force). 20 Solicitud de Comentarios (RFC, Request for Comments), son una serie de notas sobre Internet, y sobre sistemas que se conectan a Internet 21 Servidor web: servidor para el alojamiento y control de páginas web. 17 18. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 21.

(24) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 2.2.2.2.2. XMPP XMPP22 se implementa como un protocolo abierto de XML23, para mensajería en tiempo real, establecimiento de presencia y servicios de solicitud-respuesta [15]. Aunque XMPP no está sujeto a una arquitectura de red específica (diseño descentralizado), se ha implementado generalmente a través de una arquitectura clienteservidor en el que un cliente que utiliza el acceso a un servidor XMPP mediante una conexión TCP, y los servidores también se comunican entre sí a través de conexiones TCP. La Figura 9 presenta una descripción de alto nivel de esta arquitectura, donde "-" representa las comunicaciones que utilizan XMPP y "=" representa las comunicaciones que utilizan cualquier otro protocolo.. Figura 9. Diagrama de arquitectura de alto nivel para XMPP. . C1, C2, C3: Clientes XMPP.. . S1, S2: Servidores XMPP.. . G1: Pasarela que permite la conexión entre una red de mensajería XMPP y una red foránea (no XMPP) que utiliza otro protocolo.. . FN1: Red de mensajería foránea.. . FC1: Cliente en una red de mensajería foránea.. Algunas de las ventajas de XMPP son [16]:. 22 23. . XMPP es libre y abierto a modificaciones. Además, existen múltiples implementaciones en forma de servidores, clientes, componentes del servidor y librerías.. . Se encuentra estandarizado en las especificaciones publicadas por el IETF, con el RFC 3920 y RFC 3921, como una tecnología de presencia y mensajería instantánea aprobada.. . Posee una arquitectura de red descentralizada, donde no existe restricción para desplegar un servidor XMPP.. Protocolo de Presencia y Mensajes Extensible (XMPP, EXtensible Messaging and Presence Protocol) Lenguaje de Marcado Extensible (XML, EXtensible Markup Language). 22. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(25) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). . Un servidor XMPP puede implementarse aislado de una red pública, a través del uso de SASL24 y TLS25.. 2.2.2.2.3. IRC El protocolo IRC se basa en el modelo cliente-servidor y es adecuado para funcionar sobre varias máquinas de un modo distribuido. Una configuración típica involucra un proceso único (el servidor) que actúa como punto central para los clientes (u otros servidores) que se conectan a él, realizando el multiplexado y envío de mensajes necesarios así como otras funciones [17]. Una red de IRC está definida como un grupo de servidores conectados entre ellos. Un único servidor forma la red IRC más simple posible. La única configuración permitida para los servidores de IRC es la de un árbol donde cada servidor actúa de nodo central para el resto de la red que éste "ve" [18]. El protocolo IRC no proporciona medios para comunicación directa entre clientes. Toda la comunicación entre clientes está basada en el servidor o servidores. Los componentes básicos definidos por el protocolo IRC son descritos a continuación. El Servidor IRC forma la espina dorsal de la red IRC ya que es el único componente capaz de enlazar los demás módulos: proporciona un punto de conexión tanto a los clientes IRC que se vinculan para hablar, como a otros servidores IRC [19]. El servidor también es el responsable de dar los servicios básicos definidos por el protocolo IRC. Se pueden apreciar los servidores en la Figura 10, denotados por las letras A, B, C, D y E.. Figura 10. Esquema de conexión de una red IRC. El Cliente IRC es cualquier proceso que se conecte al servidor, exceptuando otro servidor [20]. Se pueden apreciar los clientes en la Figura 10, denotados por los números 1, 2, 3 y 4. Algunos de los clientes más útiles y descritos en mejor detalle se describen a continuación:. 24 25. Capa de Seguridad y Autenticación Simple (SASL, Simple Authentication and Security Layer). Seguridad en la Capa de Transporte (TLS, Transport Layer Security).. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 23.

(26) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). . PircBot. PircBot es un framework para la rápida construcción de programas automáticos (bot) para IRC en el lenguaje de programación Java. Sus características incluyen una arquitectura orientada al manejo de eventos que permite procesar sucesos comunes en la red IRC, por ejemplo, control de inundación (flood), soporte DCC (Direct Client to Client, que puede ser utilizado para trasferir archivos entre clientes) y soporte de identificación. Los métodos que PircBot implementa permiten enviar mensajes al servidor IRC al cual se esté conectado y soportar la conexión con múltiples servidores IRC. Además, pueden sobrescribirse algunos de los métodos para generar acciones de forma automática una vez se reciban mensajes del servidor IRC. . Cinch. Es un framework para implementar bots para IRC en Ruby con un esfuerzo mínimo. Proporciona una interfaz simple basada en conectores y reglas. Características de Cinch:     . Orientado a objetos. Permite lecturas y escrituras hacia el servidor IRC sin bloqueos. Proporciona un sistema modular basado en conectores. Constantes numéricas para representar los códigos de respuestas de los servidores IRC. Salida de mensajes con texto coloreado para fácil visualización.. Conclusión: La implementación de un servicio de fácil establecimiento para el control centralizado de los mensajes hacia los dispositivos, que permita desplegarse de modo distribuido y cuente con frameworks para la creación de bots en varios entornos de ejecución (Java, Ruby). Hace preciso el uso del protocolo IRC, cuya importancia en la implementación de Telelab se centra en la transmisión y recepción de mensajes, con la posibilidad de generar respuestas automáticas.. 2.2.2.3.. Framework para el desarrollo de aplicaciones web. Debido a que Telelab se despliega a modo de aplicación web, adoptar un framework26 de desarrollo repercute en gran medida en la forma en que son diseñados e implementados sus distintos componentes. Como se muestra en la Tabla 1, los frameworks para desarrollo web que fueron considerados para su utilización en el desarrollo de Telelab poseen las facilidades de código bajo demanda, interacción con bases de datos utilizando ORM27, plantillado 26. Framework: marco conceptual soportado por tecnologías específicas que abordan la construcción de una solución que se adapta a un patrón determinado. 27 ORM: Hace referencia al Mapeo Objeto-Relacional, una forma de representar registros almacenados en una base de datos relacional (i.e. a base de tablas) como instancias de modelos de entidad.. 24. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(27) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). HTML28, interfaz RESTful (tratado en mayor detalle en la sección 2.2.2.4.1.4) y prototipado rápido. Todos los frameworks considerados hacen uso del patrón MVC29 como base para el desarrollo de las aplicaciones web. Tabla 1. Frameworks considerados para desarrollo web en Telelab. Framework Basados en JSF32 CakePHP33 36. Symfony. Ruby on Rails37 Merb38. Lenguaje. AJAX 30 Código bajo demanda. ORM. Java. SI SI. 34. PHP. Plantillas HTML. Interfaz RESTful. Prototipado rápido31. Actualidad. Independiente. SI. SI. SI. 2010-10-22. 35. SI. SI. SI. 2012-01-22. SI. SI. SI. 2012-02-24. Datamapper Propel, Doctrine. PHP. SI. Ruby. SI. Active Record. SI. SI. SI. 2011-10-07. Ruby. SI. Active Record. SI. SI. SI. 2010-06-17. Brevemente se describen las características más relevantes de cada uno de estos frameworks a continuación: 2.2.2.3.1. Frameworks basados en JSF Es un estándar que simplifica la creación de aplicaciones web Java a través de la especificación de un diseño general orientado hacia el modelo MVC, contemplando las características más comunes de una aplicación web. Existen varios frameworks que implementan la especificación JSF (e.g. ICEFaces39, RichFaces40 y PrimeFaces41), pero sus características generales son las siguientes: . Un conjunto de API para representar componentes de una interfaz de usuario y administrar su estado, manejar eventos, validar entradas, definir un esquema de navegación de las páginas y dar soporte para internacionalización y accesibilidad.. . Un conjunto por defecto de componentes para la interfaz de usuario.. 28. Lenguaje de Marcado de Hypertexto (HTML, HyperText Markup Language). Modelo-Vista-Controlador (MVC, Model View Controller), patrón arquitectónico para la separación de responsabilidades en una aplicación que comprende interfaz de usuario, lógica de negocio e interacción con información almacenada en bases de datos. 30 Javascript Asíncrono y XML (AJAX, Asynchronous Javascript and XML): hace referencia a la comunicación asíncrona con un servidor web. 31 Prototipado rápido: es un método de construcción de programas informáticos en el que prevalece la funcionalidad sobre la presentación. 32 Frameworks basados en Java Server Faces (JSF) - http://blue-walrus.com/?p=187 33 CakePHP framework - http://cakephp.org/ 34 Lenguaje de programación PHP - http://www.php.net/ 35 Se encuentra en http://datamapper.org/ 36 Symfony framework - http://symfony.com/ 37 Ruby on Rails framework - http://rubyonrails.org/ 38 Merb framework - http://www.merbivore.com/ 39 ICEFaces framework - http://www.icesoft.org/projects/ICEfaces/overview.jsf 40 RichFaces framework - http://www.jboss.org/richfaces 41 PrimeFaces framework - http://primefaces.org/ 29. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 25.

(28) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). . Bibliotecas de etiquetas personalizables que permiten expresar los componentes de interfaz gráfica dentro de una página JSP42.. . Un modelo de eventos en el lado del servidor.. . Administración de estados de la sesión.. 2.2.2.3.2. CakePHP y Symfony Basados en el framework Ruby on Rails, son frameworks escritos en lenguaje PHP que cuentan con muchas características deseables para la implementación de aplicaciones ligeras. . Prototipado rápido. Posee comandos de generación y plantillas para construir funciones comunes rápidamente.. . Poca configuración. Requiere únicamente de una configuración sencilla para la conexión a la base de datos para facilitar el arranque de una aplicación.. . Licencia amigable. Está licenciado bajo la licencia MIT43 lo cual permite su uso en aplicaciones comerciales.. . Funcionalidades incluidas. El soporte multilenguaje, acceso de bases de datos, almacenamiento en caché, validación, autenticación, entre otras características; vienen incluidas en el esqueleto de la aplicación.. . Adopción de MVC. Presenta una clara separación de los componentes del patrón MVC para su fácil uso.. 2.2.2.3.3. Merb Es un framework que opera de manera muy similar a Symfony y cakePHP. Básicamente la diferencia radica en el uso del lenguaje de programación Ruby, con la diferencia de manejar las librerías utilizando Bundler44, debido a que es un programa. 2.2.2.3.4. Ruby on Rails Escrito en el lenguaje de programación Ruby y abreviado como RoR o simplemente Rails. Es un framework para desarrollo de aplicaciones web diseñado para facilitar este tipo de implementación, al hacer suposiciones acerca de lo que cada desarrollador necesita para empezar la implementación de una nueva aplicación. Con base en estas suposiciones tanto arquitectónicas como de concepto, el desarrollador puede obtener una gran funcionalidad a cambio de pocas líneas de código. Rails es software altamente 42. Java Server Pages (JSP) es un formato de páginas web que permite embeber código Java dentro de HTML. Licencia MIT - http://www.opensource.org/licenses/MIT. 44 Bundler - http://gembundler.com/ 43. 26. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(29) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). dogmático45, significando que asume que existe una única forma óptima para la realización de cualquier proceso. Está diseñado para promover la forma en la que se estructura la solución y desmotivar las alternativas que no se ajusten al patrón de diseño. En el caso de este framework específicamente, el dogma se conoce por el nombre de “The Rails Way” [21]. Conclusión: Teniendo en cuenta los anteriores frameworks y con base en los criterios para la selección de tecnologías definidos inicialmente, se optó por la selección de Ruby on Rails para la implementación del prototipo; este framework fue elegido basándose principalmente en los criterios relativos a la experiencia de uso, curva de aprendizaje y documentación.. 2.2.2.4.. Ruby on Rails como framework para el desarrollo web para Telelab. A continuación se exponen y profundizan las razones por las cuales Ruby on Rails califica como el framework de preferencia para el desarrollo del presente proyecto, haciendo énfasis en las características representativas del framework. 2.2.2.4.1. Características técnicas 2.2.2.4.1.1.. Adopción del patrón MVC y principios de construcción ágiles. Los beneficios en la utilización del patrón MVC para la creación de aplicaciones web (y aplicaciones en general) incluyen:   . Aislamiento de la lógica de negocio de la interfaz de usuario. Facilidad para el re-uso de código. Fácil mantenimiento y localización de código con su respectiva función.. Como se indicó en la Tabla 1, los frameworks considerados se basan en el patrón MVC como generalización del diseño de una aplicación web. Así, en la Figura 11 se muestra en forma más concreta como Rails sigue este patrón.. 45. Dogmático: hace referencia a la preferencia por una solución específica en el contexto del desarrollo de software.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 27.

(30) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). Figura 11. Patrón MVC en Rails46. Modelo Un modelo representa la información (datos) que tiene la aplicación y las reglas para manipular dicha información. En el caso de Rails, los modelos son usados principalmente para manejar la interacción con tablas de una base de datos. En la mayoría de los casos una tabla existente en la base de datos se mapeará de forma directa a un modelo en la aplicación para la manipulación de los registros de esa tabla. El framework como tal se encarga del mapeo de la tabla de forma inteligente y los modelos presentan por defecto funcionalidad agregada como validaciones, formatos para la representación de los datos, entre otras. Vista La vista representa la interfaz de usuario de la aplicación. En el caso de Rails, las vistas son generalmente archivos en HTML con código Ruby embebido, que únicamente manipula la presentación de los datos entregados por el componente controlador. Las vistas se encargan de entregar la información al explorador web o cualquier otro cliente que esté requiriendo la información a través de peticiones HTTP. Controlador Los controladores proveen una capa de intercambio de datos o middleware entre los modelos y las vistas. En el caso de Rails, los controladores son responsables de procesar las peticiones entrantes que provienen desde los clientes web, llamar a los respectivos. 46. Rails MVC - http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/. 28. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(31) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). modelos para que entreguen los datos requeridos y pasando dichos datos las vistas para su presentación. En la Figura 12 se muestra un diagrama que ayuda a la comprensión del ciclo de respuesta y su interacción con los componentes más sobresalientes de una aplicación Rails.. Figura 12. Despliegue de aplicación Rails (componentes más sobresalientes). Además de la utilización del patrón MVC, Rails adopta principios de construcción ágiles lo cual hace que responda de manera eficiente respecto a cambios en la base de código47. Estos principios se exponen a continuación: . No se repita a usted mismo (DRY, Don’t Repeat Yourself). Este principio se basa en la reutilización pura del código y sugiere que escribir el mismo código en múltiples lugares (o código fundamentalmente similar en distintas partes de un programa) debe evitarse para proveer facilidad de reestructuración en el futuro. . Convención sobre configuración (COC, Convention Over Configuration). Este principio está incorporado en el framework al hacer suposiciones respecto al diseño de la aplicación, evitando al desarrollador especificar gran cantidad de parámetros de configuración. Dado que el framework es dogmático, una gran parte de cómo funciona la aplicación se desprende por defecto sin configuración alguna y sólo aquellas porciones que no se enmarquen en las suposiciones hechas por el framework deben ser 47. Principios de Rails - http://guides.rubyonrails.org/getting_started.html. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 29.

(32) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). explícitamente configuradas, por ello se dice que prevalece la “convención sobre la configuración”. . Uso de REST (REpresentational State Transfer). Este principio dictamina la forma en que se lleva cabo la comunicación entre clientes y servidores de las aplicaciones web desarrolladas con Rails. Aprovechando el hecho que las aplicaciones web se basan en peticiones mediante HTTP para llevar a cabo la comunicación tradicional en el mundo de Internet, REST organiza el acceso y de cierta manera estandariza las llamadas a las aplicaciones, facilitando la obtención de recursos y operación sobre los mismos de forma remota. Por su importancia en Rails y amplia teoría, se extiende la presentación respecto a este principio.. 2.2.2.4.1.2.. Prototipado rápido a través de generación de código. Dado que Telelab no basa su implementación en una aplicación web existente, la rápida construcción de los subsistemas implicados es un factor fundamental para el logro del proyecto en el tiempo especificado. Las herramientas para la generación de código integradas con Rails permiten que muchas de las tareas más comunes en cuanto a la construcción de aplicaciones web sean realizadas más eficientemente, concentrando el esfuerzo de implementación en las funciones directamente relacionadas con la prestación del servicio. Rails dispone de cinco (5) estrategias esenciales para la generación de código: . Generación de esqueleto (Skeleton generation): Hace referencia a la generación de la estructura inicial del código fuente del proyecto a desarrollar (i.e. esqueleto), estableciendo el núcleo base de una aplicación Rails.. . Recetas (Recipes): Hace referencia a la utilización de scripts proporcionados por terceras partes, que de manera automática instalan funcionalidades compatibles con Rails.. . Plantillado (Templating): Hace referencia a la utilización de un archivo de plantilla para la generación automatizada de un esqueleto que incluye múltiples recetas.. . Andamiaje (Scaffolding): Hace referencia a la generación de elementos en todas las capas del patrón MVC (Modelo Vista Controlador) dando lugar a una funcionalidad completa referentes a acciones CRUD sobre un modelo de entidad48 en particular.. . Inicio rápido (Bootstrapping): Hace referencia a la utilización de facultades de generación de código proporcionadas por diferentes librerías, extensiones o complementos para Rails.. 48. Modelo de entidad: hace referencia a la representación de una tabla de la base de datos como una clase en el contexto del paradigma orientado a objetos.. 30. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones.

(33) Sistema Prototipo de Telelaboratorio de Equipos de Red (Telelab). 2.2.2.4.1.3.. Soporte para AJAX. Telelab incorpora numerosas funciones habilitadas por AJAX para soportar las características referentes a la interacción multiusuario en tiempo real en los entornos de práctica (nombradas en la sección 1.2.1), lo cual hace imprescindible la presencia de facilidades en el manejo de llamadas HTTP asíncronas, así como renderización apropiada de respuestas en formato JSON49 o XML. En el caso de Rails, el soporte para AJAX no está condicionado a que el cliente deba recibir la información estrictamente en XML o JSON para ser procesada, sino que adicionalmente soporta la renderización de Javascript en el servidor; esta última es la forma predilecta de funcionamiento AJAX en Rails, la cual se denomina “código bajo demanda” y es presentada en la Figura 13.. Figura 13. AJAX utilizando el procedimiento de código bajo demanda. Este modo de operación permite especificar todas las interacciones en el navegador del usuario desde el servidor; así, éste último es encargado de la generación del código Javascript el cual será ejecutado posteriormente en el cliente; evitando la necesidad de codificar manualmente un intérprete XML o JSON para cada petición recibida. 2.2.2.4.1.4.. Interfaz de servicio RESTful. El uso de REST (Representational State Transfer) en la web es cada vez más acogido y Rails se incluye en esta tendencia al exponer todas las interacciones entre clientes y servidores a través de una interfaz RESTful. El funcionamiento interno de Telelab involucra la puesta en marcha de una multitud de servicios los cuales deben efectuar peticiones entre sí de forma coherente, por lo tanto la adopción de REST para definir estas interfaces de comunicación es una opción tanto simple como eficiente para solventar este requerimiento. Aprovechando el hecho que las aplicaciones web se basan en peticiones HTTP para llevar a cabo la comunicación tradicional en el mundo de Internet, REST facilita la obtención de recursos50 y estandariza las peticiones a las aplicaciones para la manipulación remota de éstos. REST define las siguientes seis (6) restricciones, dejando libre el diseño e implementación de los componentes individuales al framework (i.e. Rails): . Arquitectura cliente-servidor: debe existir una clara separación entre clientes y servidores, permitiendo que cualquiera de éstos pueda ser reemplazado y desarrollado independientemente.. . Sin estado (Stateless): toda petición debe proporcionar la totalidad de la información requerida para que el servidor efectúe el manejo de la misma; evitando que éste. 49 50. Notación de Objetos de Javascript (JSON, Javascript Object Notation). Recurso: elementos de información que pueden ser accedidos utilizando un identificador global.. Universidad del Cauca. Facultad de Ingeniería Electrónica y Telecomunicaciones. 31.