Documento Tesis Adredimo - Javeriana · 2008-08-06 · herramientas de administración para...
122
INTRODUCCIÓN En un mundo tan dinámico como el actual, en el que las cosas cambian muy rápidamente, las empresas han tenido que evolucionar en su manera de pensar; y se han ido concientizando de la importancia de migrar, de sus antiguos métodos de administración y manejo empresarial, basados en el manejo de papelería, y con un consumo de tiempo considerable, hacia sistemas de información computacionales, basados en redes de comunicaciones, incluso inalámbricos, que les ofrecen mejores tiempos de acceso a la información, y de igual manera, una forma más efectiva y confiable de compartir datos en tiempo real. Para lograr este objetivo, la ingeniería de sistemas ha creado soluciones de manejo de información en red, mediante las cuales la empresa puede mantener una interacción entre sus miembros, y contar con datos veraces, lo cual se refleja en un mejor servicio hacia el cliente. Pero no es nuevo para nadie el hecho de la susceptibilidad a fallos ocasionales de los servicios que prestan las redes empresariales, que pueden tener una gran variedad de causas u orígenes, y ponen en problemas el cumplimiento de los objetivos y las actividades diarias de la empresa. Para tratar de evitar que en el momento en que ocurran fallos en la red, no se puedan solucionar en el mismo instante, o que estos fallos se prolonguen por un tiempo indefinido, y la empresa tenga que asumir costos adicionales, generalmente se encarga a una persona con conocimientos claves para administrar la red, a la cual se le da el nombre de “Administrador de la Red”. Este es el encargado de solucionar los problemas que se presenten, en el menor tiempo posible, y para ello, seria ideal facilitarle una
Transcript of Documento Tesis Adredimo - Javeriana · 2008-08-06 · herramientas de administración para...
INTRODUCCIÓN
En un mundo tan dinámico como el actual, en el que las cosas cambian muy
rápidamente, las empresas han tenido que evolucionar en su manera de pensar; y
se han ido concientizando de la importancia de migrar, de sus antiguos métodos
de administración y manejo empresarial, basados en el manejo de papelería, y con
un consumo de tiempo considerable, hacia sistemas de información
computacionales, basados en redes de comunicaciones, incluso inalámbricos, que
les ofrecen mejores tiempos de acceso a la información, y de igual manera, una
forma más efectiva y confiable de compartir datos en tiempo real.
Para lograr este objetivo, la ingeniería de sistemas ha creado soluciones de
manejo de información en red, mediante las cuales la empresa puede mantener
una interacción entre sus miembros, y contar con datos veraces, lo cual se refleja
en un mejor servicio hacia el cliente.
Pero no es nuevo para nadie el hecho de la susceptibilidad a fallos ocasionales de
los servicios que prestan las redes empresariales, que pueden tener una gran
variedad de causas u orígenes, y ponen en problemas el cumplimiento de los
objetivos y las actividades diarias de la empresa. Para tratar de evitar que en el
momento en que ocurran fallos en la red, no se puedan solucionar en el mismo
instante, o que estos fallos se prolonguen por un tiempo indefinido, y la empresa
tenga que asumir costos adicionales, generalmente se encarga a una persona con
conocimientos claves para administrar la red, a la cual se le da el nombre de
“Administrador de la Red”. Este es el encargado de solucionar los problemas que
se presenten, en el menor tiempo posible, y para ello, seria ideal facilitarle una
herramienta única, que reside en su equipo de trabajo, y la cual le ayuda a
detectar las fallas, y a solucionar inconvenientes en el mismo momento en que
estos ocurren.
El administrador de red es una persona que mantiene una disponibilidad de tiempo
muy escasa, y una carga de estrés demasiado alta, ya que en él recae una gran
responsabilidad, y en la mayoría del tiempo no se le encuentra en su puesto de
trabajo. Por estas razones, es importante considerar todas las actividades que
esta persona debe realizar, y en especial tener en cuenta esos momentos en los
que no tiene acceso a un PC, ya que se podrían presentar complicaciones en el
momento en el que la red presente alguna falla y no haya quien utilice las
herramientas de administración para solucionarlos. Esto crea la necesidad de
buscar una forma de diagnosticar y solucionar los problemas de la red, en
cualquier lugar de la empresa.
La administración de la red es una tarea vital para cualquier organización, y es un
campo en el que una herramienta de software puede ser muy útil, ya que ese
tiempo adicional en la solución de problemas se ve reflejado en costos, en
inconsistencias de información, en disgustos de usuarios, y en algunos casos, se
pueden generar conflictos internos por el hecho de no proveer acceso a los
servicios que brinda la red. Por ejemplo, en el caso de un sistema de reserva de
tiquetes aéreos en línea, si el sistema se cae por un periodo prolongado de
tiempo, muchas reservas no podrán ser registradas, y es posible que haya
problemas en el chequeo de los pasajeros en el aeropuerto, lo que genera
perdidas millonarias para la compañía, además de demandas por parte de los
clientes que no pueden abordar el avión que necesitan. Otro claro ejemplo es la
Banca “Online”, en la que una caída del sistema significa inconsistencia en
transacciones, además de perdidas en costos de oportunidad enormes.
2
Por estas razones, este proyecto pretende mostrar un nuevo concepto de
aplicación para la administración de redes, en el cual no solamente la empresa se
va a ver más beneficiada, sino que las tareas de configuración de red, de un
administrador de red, se van a ver simplificadas y mucho más colaborativas con
sus demás labores dentro de la empresa.
En este documento, se describen los temas principales, para poder construir y el
proyecto que aquí se describe. En los primeros capítulos, usted podrá encontrar
un amplio marco teórico que explica los principales temas que se ven involucrados
y fueron tomados en cuenta en el desarrollo de la aplicación, posteriormente, se
puede leer todo acerca del proyecto en si, desde donde nació la idea, hasta los
futuros proyectos que se podrían vincular a este trabajo, pasando por todas las
especificaciones técnicas del mismo. Finalmente usted podrá encontrar las
conclusiones obtenidas a lo largo de este proyecto.
3
JUSTIFICACIÓN
Como podemos observar, las aplicaciones de administración de red que
existen hoy en día no colaboran mucho con las tareas que un administrador de
red tiene por defecto en si. Por esta razón y luego de analizar y determinar las
necesidades que tiene en la actualidad un Administrador de Red en su trabajo,
se identificó que se requiere un mayor apoyo de una aplicación remota para
que el administrador pueda realizar las actividades de su trabajo de una
manera más cómoda y eficiente. Por esta razón, la construcción de una
aplicación orientada a permitir el acceso desde cualquier punto de una
organización, y que permita incrementar la disponibilidad para el diagnóstico y
solución de los fallos en la red, en el menor tiempo posible, sería algo ideal.
Se propone la implementación de un sistema de administración de redes con
acceso constante, independiente de la ubicación del administrador de red en la
empresa. Dicho acceso se basa en el uso de dispositivos móviles (Ej. PDA,
Pocket PC), con acceso inalámbrico a la red de la empresa, que se conecten al
sistema de administración de red. Esto eliminaría la necesidad del
administrador de dirigirse a su puesto de trabajo (PC), permitiéndole su libre
traslado físico dentro de las instalaciones de la organización, para realizar
diversas tareas de administración adicionales a las proporcionadas por el
sistema, y dar soporte en otros procesos relacionados con la gestión de redes.
Este nuevo modelo de la aplicación que proponemos, le va a permitir al
administrador de red una mayor movilidad dentro de las instalaciones de la
empresa (incluso hasta donde el radio de alcance de la red inalámbrica de la
empresa llegue), y de esta forma siempre podrá tener acceso a la aplicación de
4
administración de red, permitiéndole que desde cualquier punto donde se
encuentre, él pueda tomar acciones correctivas, o modificar configuraciones de
los dispositivos de red que lo requieran, para así poder modificar el
comportamiento de la red.
Esta movilidad con que el nuevo administrador de red contaría, le va a permitir
ser mucho más eficiente con su trabajo, ya que el tiempo y costo de resolución
de problemas en la red sería mucho menor, debido a que el tiempo de traslado
del administrador entre centros de cómputo buscando los dispositivos se va a
eliminar, y el podrá modificar desde un centro de cómputo “A”, la configuración
de un dispositivo de red que se encuentre en un centro de cómputo “B”.
Incluso si se considera una tecnología inalámbrica como GPRS, que es un
servicio ofrecido por todos los operadores actuales de telefonía celular en el
país, se crea la posibilidad de que un Administrador pueda acceder al sistema
desde cualquier ubicación geográfica que tenga cubrimiento de telefonía
celular, y pueda en todo momento conocer el estado de los dispositivos y
arreglar fallos en la red. Esto es algo que realmente reduce los costos, ya que
se elimina el tiempo de traslado del administrador a su oficina, y el costo de
este traslado en el caso que se encuentre en otra ciudad, y además elimina
ese tiempo de traslado, lo cual reduce el tiempo de detección y resolución de
un problema en la red, lo cual a su vez genera enormes beneficios para
cualquier empresa.
Pero este nuevo modelo propuesto no solo pretende ofrecer un acceso a un
sistema de administración de red desde el dispositivo móvil, sino que apunta a
aumentar la disponibilidad, usando una arquitectura distribuida (multicapas),
haciendo que los procesos críticos de la aplicación no residan en una sola
máquina, sino que estén replicados en varias, funcionando como un solo
sistema, de manera transparente para el usuario. Esto incrementa además la
tolerancia a fallas en las máquinas que contienen la aplicación de
5
administración. Al manejarse una arquitectura multicapas se permite la
distribución de componentes en capas dedicadas a diferentes tareas, lo que se
conoce como especialización funcional, permitiendo separar responsabilidades
como la presentación, la lógica del negocio y el manejo de persistencia.
Para poder lograr los objetivos propuestos es necesario tener en cuenta dos
aspectos importantes: El primero es la naturaleza distribuida del administrador,
que inherentemente lo hace más disponible, más confiable y mas escalable (se
pueden agregar nuevos nodos fácilmente). El segundo es la movilidad que el
sistema le ofrece al administrador debido al acceso inalámbrico.
Es de vital importancia dejar en claro que el énfasis de esta investigación no
esta en la implementación de un administrador de red con funcionalidad
completa, dado que ya existen bastantes en el mercado, y son herramientas de
alta complejidad, que en la actualidad ofrecen desde simples monitoreos de
tráfico y paquetes, hasta la modificación de configuración en equipos
conectados a la red, sistemas avanzados de alertas, y acciones automáticas
iniciadas por eventos programados. Por esto el énfasis esta en desarrollar un
sistema que permita una administración básica de la red, mediante una
arquitectura distribuida, que ofrezca acceso a dispositivos móviles o
computadores de escritorio convencionales.
6
METODOLOGIA
Debido a la naturaleza investigativa de este proyecto, basado en tecnologías
en evolución, como lo son las redes inalámbricas y los dispositivos móviles, se
debe tener un enfoque inicial orientado a la investigación y recopilación de la
mayor cantidad de información disponibles sobre las mismas, con el fin de
conocer el entorno de trabajo, y las capacidades de estas tecnologías. Se
considera esta la etapa inicial de la investigación, que ha sido desarrollada en
Proyecto de investigación I.
El segundo paso consiste en estudiar los equipos que se tienen disponibles,
para poder determinar si sus características, colaboran con el proyecto, o no
son compatibles con el y si se deben buscar por fuera otros que permitan
implementar el proyecto, y realizar correctamente las pruebas. Esta etapa se
espera desarrollar entre Proyecto de Investigación I y II.
La siguiente fase del proyecto fue evaluar los administradores de red que se
pudieron conseguir, de arquitectura cerrada o de código libre, para evaluar sus
características, la funcionalidad que ofrecen, y la forma en que funcionan a
nivel de código. Luego vino el desarrollo de un prototipo de administrador, con
funcionalidad básica, pero que permitió evaluar y vislumbrar las ventajas de la
utilización de dicho administrador dentro de una arquitectura distribuida, y con
la capacidad de conectividad móvil. Se hizo la completa documentación de
este proceso: levantamiento de requerimientos, documentos de diseño, y
documentos adicionales si son requeridos.
7
Luego de implementar el prototipo, se definieron los requerimientos de lo que
se iba a construir como sistema solución. Esto incluyó los requerimientos para
distribuir la aplicación de administración, los clientes que se iban a conectar
(móviles, emulados, o estáticos), requerimientos de conectividad
(infraestructura de red, protocolo, etc.), y finalmente requerimientos de interfaz
a usuarios. Para cada uno de estos componentes se hizo un documento de
requerimientos, en los que se recogieron los requerimientos descubiertos,
funcionales y no funcionales, con una bitácora de cambios y modificaciones
para el futuro. Se realizaron pruebas sobre la funcionalidad básica del
prototipo, para asegurar que funcionara correctamente. Dichas pruebas se
documentaron para referencia en las pruebas completas del sistema final.
Para todo el proceso de levantamiento de requerimientos, fase de diseño,
implementación, integración, y pruebas, se aplicó una metodología de
desarrollo de software de espiral. Esta ha sido escogida debido a su
flexibilidad para poder cambiar los requerimientos en todo el desarrollo del
proyecto, si es detectado que es necesario hacerlo. Se evaluo el impacto de
dichos cambios, y su factibilidad para ser implementados. Además esta es la
metodología mas recomendada en proyectos basados en investigaciones en
temas nuevos e innovadores, donde las condiciones varían con mucha
frecuencia.
Después del levantamiento de requerimientos, vino la fase de diseño. Se
elaboró un diseño detallado de los componentes principales del proyecto:
servidores con la aplicación de administración distribuida, Interfaces a clientes,
y Clientes móviles. Para elaborar estos diseños se uso la metodología espiral.
8
La fase siguiente al diseño fue la implementación de los componentes
principales, siguiendo los documentos de diseño elaborados. Después de
dicha implementación se inició una etapa de pruebas, que se orientaron
primero a los componentes individuales, y luego al sistema completo, para
poder evaluar la disponibilidad, y la transparencia de acceso al mismo. Se
establecieron criterios de aceptación para este producto por parte de los
desarrolladores y el director de tesis.
9
OBJETIVOS
OBJETIVO GENERAL
Desarrollar una aplicación de Administración de Red Distribuida, utilizando
arquitectura multicapas, y orientada a la conectividad con dispositivos
móviles, a través de redes inalámbricas.
OBJETIVOS ESPECÍFICOS
• Implementar interfaces que permitan que los clientes accedan de forma
transparente a la aplicación de administración de la red, haciendo énfasis
en el caso especial de un dispositivo móvil como cliente.
• La aplicación de administración de red debe tener un diseño distribuido,
para garantizar la tolerancia a fallas, la transparencia en el acceso (desde
cualquier lugar de la red), y la movilidad de los clientes (dispositivos
móviles).
• La aplicación de administración de red deberá permitir monitorear el estado
de los componentes, manejar las alertas que se generen por eventos en
estos, y permitir algunas acciones por parte del administrador de la red
desde su interfaz de cliente (configuración de componentes).
10
1. REDES Y ADMINISTRADORES DE RED
Las redes son el punto central de este proyecto. Es el propósito de administrarlas
correctamente el que motiva su desarrollo. Por ello es importante hablar de las
tecnologías involucradas, así como las aplicaciones que han buscado cumplir
estos objetivos. En la parte 1.1 se desarrolla el tema de las redes inalámbricas,
que son una tecnología con bastante futuro hoy en día, y que permitirán ofrecer la
característica móvil a toda la aplicación. En la parte 1.2 se desarrolla el tema de
los dispositivos móviles, una tecnología relativamente nueva, que ha cambiado el
paradigma completo de la oficina móvil y el entretenimiento portátil. Sin estos
seria imposible pensar en aplicaciones móviles. En la parte 1.3 se dará un vistazo
a algunas aplicaciones que han sido desarrolladas con el objetivo de administrar
redes. Finalmente en la parte 1.4 se mencionaran algunos aspectos
característicos de los sistemas distribuidos.
1.1 REDES INALÁMBRICAS Una de las tecnologías que últimamente va tomando un mayor auge y acogida en
los mercados empresariales, es la de comunicaciones inalámbricas, ya sea por
medio de expansión de ondas, o por comunicación infrarroja. Una de las mayores
impulsoras de esta tecnología es la IEEE, con su grupo de estándares 802.11X.
Las soluciones de comunicaciones inalámbricas no comenzaron como un intento
de reemplazar las comunicaciones cableadas, ya que en sus inicios era
insospechado que la capacidad de estas pudiera llegar a rivalizar con las redes
fast ethernet que predominan actualmente, las cuales tienen capacidades de hasta
11
100 Mbps, en comparación con los pobres 2 Mbps que inicialmente alcanzaban
las redes inalámbricas. Pero en los últimos años, esta tecnología ha tenido un
crecimiento bastante rápido, y se ha llegado ya a rendimientos de cerca de los 54
Mbps (comercialmente), que aunque siguen presentando desventajas frente a las
redes cableadas tradicionales, ya puede pensarse en un futuro cercano la
posibilidad de que brinden una solución tan efectiva y segura como lo son las
redes ethernet actuales (100 Mbps), ya que aún no pueden equipararse con el
rendimiento de tecnologías avanzadas como la fibra óptica o Gygabit Ethernet.
Si las clasificamos por su alcance geográfico, podemos decir que hoy en día
existen tres tipos de redes inalámbricas: WAN (Wide Area Network), LAN (Local
Area Network); y PAN (Personal Area Network). Las redes WAN inalámbricas son
usadas para interconectar ciudades o organizaciones a largas distancias, utilizan
principalmente satélites, microondas y ondas de radio. Las redes LAN
inalámbricas son usadas principalmente en ambientes corporativos, y permiten
compartir recursos de forma sencilla, además que atraviesan muros y obstáculos
diversos, usando principalmente ondas de radio. Sus puntos fuertes son
movilidad, flexibilidad, escalabilidad, y bajos costos de instalación; mientras que
sus puntos débiles son baja seguridad, debido a que la información viaja por el
aire que es un medio de libre acceso, una velocidad baja comparada con el
cableado tradicional y su limitado alcance. Las redes PAN inalámbricas son
aquellas que permiten interconectar dispositivos electrónicos en un rango de
pocos metros. La tecnología líder en la actualidad en este campo es Bluetooth.
[PK2002]
1.1.1 Características Las redes inalámbricas presentan varias características, que marcan una
diferenciación básica con respecto a las redes cableadas. La mayor diferencia que
existe en cuanto a las redes cableadas, esta en la forma de utilización de algunas
12
de sus capas (Modelo OSI), como lo son la capa física, la cual debe indicar la
manera de realizar el envío de bits de una estación a otra, y la capa de enlace de
datos, la cual se encarga de describir como se empacan y verifican los bits de
modo que no tengan errores. Estas dos capas son diferentes en estas tecnologías,
porque no se trata de buscar conexiones a través de cables, sino validar
conexiones a través del aire, con múltiples equipos escuchando y transmitiendo en
este medio.
Finalmente existen tres características, que son importantes de mencionar: la
primera de ellas hace referencia a la seguridad de la red, ya que en una red
inalámbrica es fácil lograr escuchar transmisiones de datos de un punto de la
comunicación al otro, puesto que se utiliza el aire como medio de transmisión, y
todo aquel que se encuentre dentro del rango de alcance de la comunicación,
podrá tener acceso a los datos transmitidos, si estos no son protegidos. La
segunda característica hace referencia al consumo de energía, ya que se debe
tener en cuenta que la mayoría de equipos que están utilizando esta tecnología
son equipos móviles, los cuales tienen cargas de batería limitadas, al contrario de
lo que ocurre con los computadores de escritorio que tienen energía ilimitada todo
el tiempo. La tercera característica tiene que ver con las velocidades de
transmisión de datos, ya que dependen de la tecnología utilizada, y de los equipos
utilizados en la red. [PK2002]
1.1.2 Tecnologías de Acceso Inalámbrico En el mercado actual existen diferentes tecnologías de acceso inalámbrico, que
utilizan diversos protocolos, pero se destacan dos (2) por su alto uso comercial y
su enfoque hacia futuro; el primero de ellos es Bluetooth (PAN) y el segundo es
IEEE 802.11X (LAN).
13
Bluetooth es una tecnología que permite transmisión de datos entre dispositivos,
con un alcance muy limitado, por lo que se considera una tecnología PAN
(Personal Area Network). La gran mayoría de dispositivos móviles actuales tiene
incorporada esta tecnología como estándar, gracias a su buena velocidad de
transmisión de datos, oer sus mayores problemas son su limitado alcance, y un
esquema de seguridad no muy fuerte.
IEEE 802.11X es un grupo de estándares bajo el concepto LAN (Local Area
Network). Dentro del mismo encontramos al estándar IEEE 802.11b, que
comenzó su desarrollo basándose en el rendimiento, y dejando la seguridad como
un valor agregado, no como una prioridad. Luego se realizó el lanzamiento del
estándar IEEE 802.11g destinado a permitir mayores velocidades que el 802.11b
(aunque mantiene compatibilidad con equipos 802.11b), llegando hasta los 54
mbps (802.11b solo alcanza como máximo 11 mbps), pero sin mejoras en cuanto
a seguridad en ningún aspecto (802.11g usa WEP también para la encripción).
[AC2000]
GPRS (General Packet Radio Service), es una estandar de comunicación para
teléfonos móviles considerado como la generación 2.5, entre la segunda y la
tercera de las redes inalámbricas. GPRS proporciona altas velocidades de
transferencia de datos (especialmente útil para conectar a Internet) y se utiliza en
las redes GSM (Group Special Mobile) o UMTS (Universal Mobile
Telecommunications System)
GPRS es básicamente una comunicación basada en paquetes de datos. Los
timeslots (intervalos de tiempo) se asignan en GSM generalmente mediante una
conexión conmutada, pero en GPRS los intervalos de tiempo se asignan a la
conexión de paquetes, mediante un sistema basado en la necesidad. Esto
significa que si no se envía ningún dato por el usuario, las frecuencias quedan
libres para ser utilizadas por otros usuarios.
14
GPRS ha dado también cabida al lanzamiento de la tecnología EDGE (Enhanced
Data Rates for Global Evolution), la cual es considerada la tecnología de telefonía
digita móvil 2.75, ya que puede alcanzar velocidades de hasta 384 Kbps. Mientras
que GPRS puede transmitir a una velocidad de hasta 11Kbps
En resumen, las redes inalámbricas permiten a un cliente desplazarse libremente
dentro de un área geográfica definida, sin necesidad de estar conectado a través
de cables a un equipo de red. Esta característica brinda movilidad al
administrador de red (usuario final del proyecto), al permitirle moverse dentro del
rango de la red inalámbrica, sin perder el acceso a la aplicación de administración
de red. Esto permite que su trabajo sea más eficiente, y pueda estar alerta de
posibles fallas o problemas en la red, sin depender de un PC de escritorio, lo que
además reduce los tiempos de reacción y corrección de dichos problemas.
Como se pudo observar, existen diversas tecnologías de comunicación
inalámbrica, y cada cual tiene sus ventajas y desventajas, que al escogerse una
en particular, deben tenerse muy en cuenta. Afortunadamente debido a los
estándares de protocolos, es sencillo pensar en utilizar varias, dependiendo de la
situación en particular del administrador, por ejemplo: bluetooth puede ser una
buena solución a muy corto alcance, 802.11x en un rango mas amplio dentro de
las instalaciones físicas de una empresa, y GPRS una buena solución a nivel ya
de largo alcance, dado el gran cubrimiento nacional de las redes celulares. Otras
tecnologías como WiMax no fueron evaluadas en profundidad, mas que todo
debido a que son muy recientes, y aun no se cuenta con los equipos para
probarlas, pero podrían brindar grandes ventajas a un sistema como el planteado,
sobrepasando lo que ofrecen las otras tecnologías.
15
1.2 DISPOSITIVOS MOVILES En los últimos años el mercado de la electrónica digital tiene una fuerte orientación
a los dispositivos móviles, que permitan a sus usuarios llevar consigo a todas
partes, información y capacidad de procesamiento, que en cualquier momento
pueda servir de manera significativa en sus negocios o vida personal.
1.2.1 Características Los dispositivos móviles son aparatos pequeños con algunas capacidades de
procesamiento, con conexión permanente o intermitente a una red, con memoria
limitada, diseñados específicamente para una función, pero lo que no implica que
no puedan desarrollar algunas otras más, generalmente son del uso de una sola
persona; la mayoría de ellos pueden ser transportados en los bolsillos, otros se
integran con otros para aumentar su funcionalidad, y normalmente se sincronizan
con un sistema de escritorio para actualizar aplicaciones y datos.
Otras de las características que son inherentes a los dispositivos móviles y que los
diferencian de los computadores de escritorio son: Funcionalidad limitada; no
necesariamente extensibles ni actualizables; de un ciclo de vida más corto; menos
complicados de manejar; no requieren de un usuario experto; y es fácil aprender
su forma de operación.
Igualmente los dispositivos móviles se pueden catalogar dentro de las siguientes
categorías: Paginadores, comunicadores de bolsillo, sistemas de navegación de
automóviles, sistemas de entrenamiento, sistemas de televisión e Internet,
teléfonos móviles, organizadores, y asistentes personales digitales. [PK2002]
Finalmente los dispositivos móviles se diferencian bastante entre si, y existen
también diferencias en las características de algunos dispositivos dependiendo de
16
la casa matriz, de los costos y de la distribución geográfica donde se encuentre el
cliente del dispositivo.
1.2.2 Dispositivos y Características Individuales • PDA: (Personal Digital Assistant)
Son asistentes digitales personales, que involucran algunas características
como acceso a Internet, email, procesadores de texto sencillos, agenda,
calendario, y muchas otras aplicaciones orientadas a negocios o
esparcimiento.
• Smart Phones: (Teléfonos inteligentes) Se les conoce también como dispositivos de convergencia, dado que unen el
mundo de la telefonía celular convencional, y el mundo de las computadoras
de mano. Son teléfonos celulares, que además de permitir recibir y realizar
llamadas, y guardar números y compromisos, tienen tecnología integrada para
comportarse incluso como PDA’s, con algunas limitaciones de memoria y
pantalla, dado su reducido tamaño, pero con funciones integradas importantes,
como soporte de aplicaciones Java, cámara digital, sincronización con
computadoras de escritorio (Outlook), reproducción de archivos Mp3,
reproducción de video, conectividad bluetooth, etc. Incluso los modelos mas
completos tienen navegadores HTML que permiten visualizar paginas
normales de Internet. Hoy en día la mayoría de fabricantes de electrónica se
han concentrado en convertir estos dispositivos en algo esencial para cada
persona, agregándoles cada vez mas capacidades, un diseño mas practico y
portátil, convirtiéndolos en una plataforma con un gran futuro para desarrollo de
software y aplicaciones comerciales.
17
• Pocket PC: (Computador Personal de Bolsillo)
Son computadoras pequeñas de bolsillo, que ya tienen sistemas operativos
complejos, como el Microsoft Windows CE. Estas tienen un poder de computo
mayor a las PDA, tienen mayor capacidad de memoria, y ofrecen
características mas avanzadas. Hay gran variedad de aplicaciones disponibles
para estos equipos, desde juegos hasta aplicaciones comerciales de negocios.
Ejemplos de Dispositivos móviles:
Compaq iPaQ Pocket PC
Procesador StrongARM SA-1110, memoria SDRAM de 64 MB, Tarjeta de
Memoria SD (opcional), Ranura de Expansión memoria digital confiable,
pantalla de transistor de película delgada de reflejos de 64.000 colores,
grabador de voz, parlante incorporado y conector de paquete de expansión
(batería de polímero de ion de litio)
Dell Axim X5
Procesador Intel XScale 400Mhz, pantalla a color de 3.5”QVGA TFT, 2
ranuras CompactFlash TipoII y secure Digital/MMC, 64MB SDRAM y 48 MB
Intel StrataFlash ROM, Microsoft Pocket PC 2003 Premium y un año de
garantía limitada. (196 gr, 128 mm x 81.5 mm x 18 mm – Largo, ancho, alto)
Dell Axim X3i
Procesador Intel XScale 400Mhz, pantalla a color de 3.5”QVGA TFT, 1 ranura
secure digital/SDIO, 64MB SDRAM y 48 MB Intel StrataFlash ROM, Microsoft
Pocket PC 2003 Premium y un año de garantía limitada. (136 gr, 117 mm x
77.2 mm x 14.9 mm – Largo, ancho, alto)
Palm Zire
Palm ZIRE. 144Mhz, 16 Mb en memoria
18
En el mercado actual se pueden encontrar dispositivos móviles con browser
integrados que soportan HTTP, como pasa en la mayoría de los casos con los
PDA y los PocketPC; aunque de igual manera, se pueden encontrar dispositivos
que no tengan soporte de este protocolo, sino de otro mucho más liviano como lo
es WAP. Por esta razón este proyecto adopta una presentación múltiple para
poder atender las peticiones de los clientes móviles, independiente si el acceso es
por medio de protocolo WAP o HTTP.
1.3 ADMINISTRADOR DE RED Un administrador de red es una aplicación que permite monitorear, analizar,
configurar y alertar, sobre eventos y dispositivos presentes en la red administrada.
Estas aplicaciones se ven más que todo en entornos empresariales, sobre todo en
empresas con redes muy grandes, que sin herramientas como estas, serian
imposibles de administrar. Es un mercado aun no explotado del todo, a pesar que
existen diversas soluciones comerciales, desarrolladas por empresas tan
importantes en el mercado como McAfee (que ofrece administradores para todo
tipo de redes: cableadas, inalámbricas, celulares, etc.), Hewlett Packard (que
ofrece soluciones integrales para administración de redes), y Network Associates
(que ofrece administradores para redes de diversas naturalezas y tamaños), entre
otras.
1.3.1 Características La mayoría de estas soluciones para administración de redes tienen algunas
características similares, como son: [MN1996] Funcionan como agentes, que están dentro del dispositivo administrado, o
agentes delegados fuera del mismo.
Permiten monitorear el estado de diversos dispositivos, y algunas variables de
su funcionamiento.
19
Permiten que los agentes alerten cuando ocurra una falla o un evento
predeterminado.
Algunas permiten que se tomen acciones sobre dispositivos remotos,
configuración, encendido, etc.
1.3.2 Plataformas La mayoría de herramientas de administración de redes tiene una orientación
fuerte a plataformas Windows, las mas comunes en los entornos empresariales
actuales. Pero también hay gran cantidad de administradores de red para Unix
(Linux en el caso más actual). Algunos de estos son incluso herramientas
basadas en código libre, como el caso de RMON.
Nota: Si desea conocer más acerca de administradores de red, vea el capítulo 2
de este documento “Administradores de Red y Características”
1.4 SISTEMAS DISTRIBUIDOS A mediados de la década de los 70, los desarrolladores de sistemas comenzaron
a visualizar el futuro, en el que no estarían grandes mainframes con capacidades
de cómputo enorme, y con terminales sin capacidad de procesamiento solo para
ser interfaces de entrada y salida. Hace unos años, con los avances en los
computadores personales, la posibilidad de aprovechar la capacidad de cómputo
de múltiples computadoras trabajando en una misma tarea se hizo posible. Aquí
es donde se comienza a hablar de Sistemas Distribuidos. Estos fueron
desarrollados con el fin de repartir la carga de tareas complejas en muchas
máquinas distintas, repartidas geográficamente en una LAN, o incluso en una
WAN. El desarrollo de las redes impulsó aun mas los avances en sistemas
distribuidos, brindando mejores conexiones para la interacción de máquinas de
20
forma remota. Los sistemas distribuidos están presentes en muchas áreas
actualmente, en casi toda empresa de tamaño considerable, e incluso en las redes
públicas, como el caso de Internet.
1.4.1 Características [GC2001] Distribución de Carga:
Al tener más de una máquina disponible, podemos repartir la carga de una
tarea compleja, en varias más sencillas, distribuyendo su procesamiento en
distintas máquinas, que luego retornan los resultados parciales, que son
unificados para producir el resultado final total. Al unir el poder de cómputo
de varias máquinas, se sobrepasa el rendimiento de un sistema monolítico,
basado en una sola máquina poderosa. Además es posible que las
solicitudes no lleguen siempre a la misma maquina, permitiendo un manejo
mas eficiente del servicio.
Tolerancia a fallas:
Al disponerse de varias máquinas autónomas interconectadas, si una de
estas falla, otra debe estar en capacidad de realizar las tareas asignadas a
la máquina afectada. Esta técnica se conoce como replicación. Esto
permite que la ejecución de una tarea no se paralice por la pérdida de una
de las máquinas que participaban de ella. Además, al distribuirse la
información, si una máquina falla, se puede recuperar la información desde
las otras.
Transparencia:
Es importante en un sistema distribuido que el usuario final no deba
conocer la estructura interna del mismo para usarlo; para el usuario el
sistema debe funcionar de forma transparente, como si se tratara de una
21
única máquina, de forma que en caso de fallas, por ejemplo, el usuario no
perciba el error, sino que el sistema lo maneje internamente y no exija una
acción extra por parte de los usuarios. El sistema debe percibirse hacia
afuera de igual forma, ya sea que este conformado por una sola máquina, o
toda una red distribuida en un área grande. También existe la
transparencia de acceso, que permite que un sistema sea accesado desde
diferentes medios, pero sin restringir su funcionalidad principal, y sin
requerir acciones externas de los usuarios.
A lo largo de este capitulo se han expuesto diferentes tecnologías, que se integran
o que pueden ser integradas a Adredimo. Cada una de estas, constituye un
elemento vital en el proyecto, y han sido consideradas para el desarrollo del
mismo: en primer lugar las redes son el punto de entrada y el medio de
comunicación con el sistema de administración de red. En segundo lugar, los
sistemas distribuidos, permiten la plantación y diseño de una arquitectura mucho
más confiable, tolerante a fallos y transparente al cliente. Los Dispositivos móviles,
son los equipos que se van a comunicar por medio de redes inalámbricas con el
sistema, brindando al usuario final una característica tan importante como lo es la
movilidad. Así mismo, se consideraron las tecnologías y características más
importantes de algunos de los administradores de red disponibles en el mercado, y
fueron tomadas como base para definir los requerimientos de Adredimo.
Vale la pena mencionar que inicialmente se pensó en un sistema móvil de
administración de redes basado en una aplicación embedida en los mismos
dispositivos. Toda la inteligencia de presentación, lógica de negocio, y acceso a
datos estaría ubicada dentro de los mismos dispositivos. Este enfoque no permitía
brindar todas las ventajas de un sistema distribuido, como lo son la disponibilidad,
transparencia de acceso, tolerancia a fallas, además implicaba limitar el acceso a
solo algunos dispositivos específicos, dejando por fuera el acceso desde un
22
computador de escritorio, o desde algunos dispositivos mas limitados en
capacidades para albergar una aplicación embedida. Por todo esto se decidió
diseñar un sistema distribuido, dejando el peso completo de la aplicación en
servidores de la misma, y usando los dispositivos móviles solo como un caso
particular de cliente, con sus ventajas inherentes de movilidad y disponibilidad
fuera de la empresa.
23
2. ADMINISTRADORES DE RED Y CARACTERÍSTICAS
En el mercado actual podemos encontrar varias opciones en cuanto a software
para administración de redes, y entre ellos podemos encontrar múltiples
características diferentes, que los hacen más o menos atractivos para los posibles
clientes, dependiendo de las funcionalidades que estos últimos busquen para las
redes de sus empresas.
A continuación se listan algunas soluciones de administración de redes que
existen en el mercado, junto con sus características más significativas. Los
administradores de red aquí seleccionados, fueron elegidos bajo criterios de
fidelidad y atracción por la marca por parte de empresas, gracias a un estudio
publicado en un artículo de la revista cambio. El objetivo de la descripción de estos
administradores de red, es poder observar con que cuentan los administradores
de red más comerciales actualmente, para tomarlo como guía en que les falta a
esas aplicaciones, que ideas se pueden tomar de dichos administradores y buscar
un lineamiento en la construcción del proyecto.
2.1 Administradores de Red
2.1.1 LINK ANALYST: [AA2004]
Este es un software ofrecido por “Aguilar & Asociados”, que permite
encontrar las fallas en la red LAN o WAN, antes que los usuarios sean
afectados por la caída del servicio. Adicionalmente realiza un inventario de
24
equipos de red, y los servicios que tienen instalados; así como la detección
de virus y troyanos instalados como servicios en los computadores
Los servicios que esta opción de monitoreo de red ofrece son los
siguientes: Monitoreo Pro-activo de la red, Seguridad, inventario de
dispositivos, inventario de servicios activos, anticipo de problemas de
performance y análisis de rutas.
El mayor gancho comercial y de operatividad que ofrece este producto, es
que se trata de un software que permite el monitoreo pro-activo de la red
con muy bajo costo de mantenimiento y capacitación, utilizando muy bajos
recursos. El cliente puede construir un mapa de la red LAN o WAN y
conocer de inmediato cuando se cayó un router, o un servidor está
sobrecargado de actividad. El mapa se vería como la figura a continuación
lo muestra
Figura 1. Mapa de Red ofrecido por Link Analyst
25
En cuanto a sus puntos débiles, se encuentran algunos aspectos como la
adquisición del producto (US$750 + IVA) y licencias periódicas del mismo;
la no posibilidad de realizar conexiones TelNet o Web al dispositivo para su
configuración al detalle.
2.1.2 RENTAPC VERSIÓN 5: [SS2003]
RentaPC Versión 5 es un software administrador de red dedicado a cafés
Internet, creado por “SPROCOM Software”, y del que actualmente existe
una versión beta 6.0. Este administrador esta basado en la arquitectura
Cliente-Servidor, y utiliza como protocolo estándar TCP/IP.
Es un software que monitorea los computadores en tiempo real, capaz de
trabajar en ambientes Windows 9x, ME, NT, 2000 y XP.
Los costos de este producto dependen de la cantidad de estaciones que se
deseen tener en el café, y se encuentran actualmente entre los US $54.74
para 5 estaciones de trabajo, pasando por los US $214.75 para 20
estaciones hasta los US $531.66 para 50 estaciones de trabajo.
Entre algunas otras características de este producto tenemos:
• Ocupa poco espacio en el disco duro.
• Funciona con DHCP (IP dinámica) o con dirección IP asignada.
• Compuesto por Clientes - Servidor.
• Los clientes pueden operar en forma independiente del servidor.
• Usa el protocolo estándar, TCP/IP.
• No consume recursos de su red.
• Permite definir claves para todo el personal de su empresa.
• Permite definir diferentes tarifas para cobrar.
• Envía mensajes dentro de Intranet, en forma global o personal.
26
• Bloqueo de programas según su tarifa.
• Sincronización automática de reloj de toda la Red.
• Corte de caja de rentas y nota de ventas.
• Contiene un sencillo punto de venta.
• Genera un reporte de archivos impresos.
• Envía corte de caja vía e-mail.
Como ganchos promociónales el producto utiliza: Control exacto del tiempo
usado en los computadores, evitando el uso de hojas de cálculo ya que el
sistema calcula y efectúa todos los controles de alquiler automáticamente;
manejo de tarifas y promociones por horarios o ubicación; permite definir
claves por empleado; permite habilitar y deshabilitar ciertas funciones y
registros de Windows; permite visualizar el funcionamiento de cada
computador, permitiendo ver que programas se están utilizando y el estado
actual de la máquina; y finalmente provee una pequeña base de datos para
el punto de venta, y así poder llevar registros de las ventas que se han
realizado.
2.1.3 PC DUO LANUTIL32: [DA2004]
PC Duo es una mejor alternativa para los departamentos de mantenimiento
y servicio técnico, ya que se diseño para este propósito. El inventario es
cortesía de LANutil32 y hay módulos opcionales para la distribución de
software y el control de licencias. Este utiliza clientes cargados de forma
local para examinar cada estación de trabajo, a la vez que almacena esta
información en un archivo local cifrado. El host LANutil32 accede a estos
archivos a intervalos programados o bajo demanda y descarga la
información en una base de datos central. LANutil32 es muy detallado, pero
la generación de informes es limitada. La interfaz agrupa a las estaciones
27
de trabajo para facilitar el acceso y se puede rellenar de manera automática
la base de datos con los nombres de los ordenadores cliente. PC Duo
necesita tener un host cargado en el PC de Control y utilidad cliente en los
sistemas invitados que se van a controlar. Existe una gran variedad de
opciones para determinar el nivel de acceso que tiene un cliente durante
una sesión de control remoto. Junto con el control remoto también se
obtienen herramientas para la transferencia de archivos Chat basado en
texto y envíos de mensajes. Los clientes pueden ser reiniciados desde el
PC de control. Como gran desventaja muestra que la instalación del cliente
es bastante tediosa.
2.1.4 Snow Suite3.1: [DA2004]
Snow Suite ofrece una característica exclusiva para administrar los
controles de las impresoras en red. Al mantener los controles en un
administrador central, Snow permite que los administradores los
personalicen de forma que todos los clientes utilicen los mismos valores.
Cada usuario tiene un nuevo icono en el menú inicio de manera que pueda
cargar con facilidad la utilidad de print manager y ver todos los
controladores disponibles. La utilidad también presenta una lista con los
puertos disponibles en el sistema local y los usuarios pueden seleccionar la
impresora necesaria simplemente arrastrando el icono del controlador a uno
de los puertos.
Adicionalmente a la característica de administración de impresoras, centra
su atención en la distribución de Software, tarea en la cual también ayudan
los asistentes; que toman una instantánea del computador base en línea y
crean un paquete comparándolo con una segunda instantánea. También se
obtiene Snow Secure, que proporciona un protector de pantalla protegido
mediante contraseña que es compatible con la distribución del mensaje y
permite que se creen contraseñas de administrador cifradas separadas
28
para desbloquear los PC clientes. Las sofisticadas herramientas de control
remoto se ofrecen como opción a través de NetOp de DanWare.
Lamentablemente, Snow empieza a perder fuelle cuando le llaga el turno a
la instalación de clientes, ya que la documentación carece completamente
de instrucciones.
2.1.5 Veritas Desktop Management Suite 3.5: [DA2004]
Esta herramienta se centra en el inventario del Hardware y Software, el
recuento de licencias y la distribución de Software; por lo tanto no ofrece
ningún tipo de monitorización de la red. Se puede acceder a cada utilidad
desde una única interfaz de administración cargada en un sistema Windows
9x o NT. Durante la instalación se copia un grupo de agentes en un
directorio compartido y se ejecuta desde un Script de inicio de sesión. No
es necesario que los agentes residan de forma local en cada una de las
estaciones de trabajo y la instalación de los clientes requiere muy poco
trabajo. Cada estación únicamente se identifica por un pequeño archivo de
texto oculto que crea la primera ejecución del inventario y se almacena de
forma local en el directorio raíz de la estación de trabajo. Se crean archivos
de transacciones para cada cliente y los datos del inventario se pasan a un
sitio de recopilación que se mantiene también en un directorio compartido
en el servidor. Desde aquí se descarga y se mezcla en una base de datos
que mantiene el sistema y que ejecuta la consola DMS.
Veritas proporciona una copia SQL para almacenar los datos del inventario
y un cliente OBDC, que utiliza un agente de fusión para actualizar la base
de datos. Las fusiones pueden ejecutarse por demanda o programarse.
DMS cuenta con una prestación de copia de seguridad de manera que la
base de datos pueda copiarse a otra ubicación. El nivel de información que
ofrece DMS es detallado y preciso. Todos los sistemas operativos y las
versiones de los clientes de las pruebas fueron identificados, al igual que
29
los procesadores y otro Hardware. La información se organiza en carpetas
jerarquizadas y etiquetadas. Los servidores Netware pueden incluirse en el
proceso cargando un pequeño grupo de NLM, permitiendo así que se
pueda acceder a ellos desde la consola DMS. El inventario del Software es
impresionante, veritas utiliza listas master que contienen 11,000
aplicaciones y 1,400 distribuidores. Wininstall usa el método estándar de
instantáneas con el fin de crear paquetes para la distribución del Software.
Sin embargo este es uno de los productos más complejos debido a la gran
cantidad de características que utiliza. Una utilidad Discover se ejecuta en
una maquina nueva y seguidamente, la aplicación elegida se instala sobre
ella. Luego Discover identifica todos los cambios que han ocurrido y crea un
paquete de distribución a partir de ellos. Se puede controlar lo que se deja
coger por Discover ya que se puede modificar para que ignore cambios en
los archivos, en el registro o en los iconos si se desea. El paquete puede
distribuirse utilizando un gran abanico de medios. Se puede forzar una
distribución insertando el paquete en los clientes para que se instale sin
ningún tipo de intervención de los usuarios o utilizar un paquete de una
lista.
2.1.6 Intel LANDesk Management Suite 6.3: [DA2004]
Intel cuenta con dos versiones de LANDesk. La versión 2.53 esta diseñada
para ejecutarse en servidores NetWare, mientras que la 6.3 que es la que
se analiza, debe tener un host un sistema de servidor de Windows NT.
LANDesk utiliza dominios para agrupar los dispositivos de la red y cada
dominio necesita un servidor principal con una buena especificación de
Hardware. Necesita al menos 1GB de espacio de disco duro, 128Mb de
memoria y debería estar dedicado a la tarea. Al servidor principal se accede
a través de consolas y cada dominio admite 30. Los datos del inventario
incluyen copia de Microsoft Access, aunque para redes de más de 200
30
nodos Intel recomienda usar SQL Server. Para distribuir la carga de trabajo,
se pueden implementar centros de servicios que alberguen otras utilidades
de administración. La administración de clientes requiere que se cargue
localmente un grupo de agentes en cada una de las estaciones de trabajo.
Esta es una tarea sencilla se puede decidir primero que servicios se desean
instalar y dejar que LANDesk cree un Script de inicio de sesión para
automatizar la instalación. Desde la interfaz de Desktop Manager se puede
explorar la red, seleccionar un cliente, iniciar sesiones de control remoto,
conversar con los usuarios o transferir archivos. Es posible reiniciar los
sistemas a distancia. LANDesk es uno de los pocos productos de
administración que admite WOL (Wake On Line), así los computadores con
tarjeta de red homologada pueden apagarse y encenderse desde la consola
de Desktop Manager. Es posible hacer un seguimiento de los cambios en el
inventario, seleccionar un componente y elegir el valor que se desea
controlar. Existe una enorme oferta, así que por ejemplo se podría estar
alerta a los cambios en la memoria instalada o incluso en los números de
serie de los discos duros.
El Server Manager atiende tanto a servidores Windows NT como NetWare y
para el último se carga como un grupo de NLM. Es una consola aparte del
Desktop Manager y le permite controlar campos fundamentales, como el
espacio del disco, la actividad del procesador o la utilización de la memoria.
AMS2 vuelve a entrar en juego, ya que muchos eventos pueden tener
umbrales aplicados y habrá avisos si se sobrepasan. Algunos eventos,
como la utilización de la memoria pueden visualizarse en formato gráfico.
LANDesk guarda un registro del historial, de manera que se puede hacer un
seguimiento de los eventos durante periodos prologados. Los gráficos se
pueden imprimir y los datos exportar en formato CSV para su utilización en
hojas de calculo. Los componentes wed de Intel permiten que se acceda a
algunas funciones de LANDesk como el control remoto, el WOL, y el
31
inventario por medio de un explorador wed. El problema principal es que
para instalarse, la consola wed necesita la herramienta LANDesk Datamart.
Esta es una utilidad diseñada para mejorar los tiempos de búsqueda de la
base de datos, pero solamente se recomienda para sitios con más de 2,500
nodos. La consola puede ejecutarse en PC con Windows NT o 9x, pero
también se necesita tener instalado IIS o Personal Web Server, así como
descargado y aplicado el ultimo MDAC. La distribución de Software
comienza en un computador de referencia limpio con Package Builder de
Intel instalado. Esta utilidad controla el sistema antes y después de
instalada una aplicación y crea un paquete con las diferencias; este
paquete se encima a un centro de servicios de distribución donde puede
programarse para ser ejecutado en los computadores de los usuarios. Es
posible añadir aplicaciones con facilidad, ya que existen buenos niveles de
control. LANDesk es un producto muy sofisticado ideal para administrar
redes de gran tamaño.
2.1.7 Novell ManageWise 2.6: [DA2004]
ManageWise es una buena fusión del propio NMS de Novell con un pedazo
de LANDesk de Intel, siendo este último el que proporciona herramientas
de administración del escritorio como por ejemplo, control remoto
transferencias de archivos y funciones de conversión. También se consigue
inventario de Hardware y Software, pero no cuenta con distribución del
Software ni recuento de licencias. La comprobación de virus es la más
sofisticada de estos productos analizados. InocuLAN de Computer
Associates ofrece completas prestaciones de rastreo y obliga a los usuarios
a tener cargada una copia local del antivirus si quieren acceder a la red. En
el esquema de administración es posible incluir los sistemas Windows NT,
ya que Novell proporciona agentes que se cargan como un servicio, estos
devuelven a la consola de ManageWise la información relativa a las
estadísticas y al rendimiento del servidor por medio de SNMP (Véase
32
capítulo de SNMP). El servicio de agentes puede también transmitir a la
consola de ManageWise eventos del registro del sistema NT para los que
utilice a la hora de emitir alertas. Sin embargo las opciones de alerta son
bastante mediocres, ya que los avisos se limitan a guardar el mensaje en la
base de datos, mostrar un mensaje, ejecutar el programa o hacer que
suene una alarma en la consola de ManageWise.
La instalación se lleva acabo desde una estación de trabajo conectada y es
gratamente sencilla. Solamente se necesita un servidor NetWare para
ejecutar los componentes de ManageWise y es posible instalar la consola
de administración al mismo tiempo. Es necesario realizar algunos trabajos
posteriores a la instalación, pero dichas tareas están claramente explicadas
en la documentación en línea. Se precisan utilidades locales para el
inventario y el rastreo de virus; y estas se instalan fácilmente con un Script
de inicio de sesión que se crea durante la instalación. Todo lo que hay que
hacer es añadir usuarios al nuevo grupo NDS de ManageWise y el Software
se instala en cuanto se conectan.
ManageWise es el único producto de estos que ejecuta un proceso de auto
descubrimiento para crear un mapa de la red. Utiliza un grupo de NLM,
conocido como Net Explorer, para rastrear la red a intervalos programados
y añadir al mapa nuevos dispositivos a medida que se van encontrando. La
consola utiliza Net Explorer Manager para recuperar esta información y
mezclarla con la base de datos de ManageWise. Acceder a los diferentes
dispositivos es sencillo, ya que se seleccionan directamente desde el mapa
de principal de la red. Si se hace click en una estación de trabajo se carga
de manera automática el Desktop Manager, que permite que se inicien
sesiones por control remoto y de transferencia de archivos o que se vea la
base de datos del inventario. Las estaciones de trabajo pueden reiniciarse
de forma remota, pero ManageWise no admite Wake-on LAN. La
identificación del Software es mala, puesto que muchos productos no se
33
detectan. Sin embargo es posible hacer un seguimiento de los cambios en
el inventario, aunque cualquier modificación que se encuentre simplemente
se sitúa en un archivo de registro y no puede vincularse al sistema de
alerta. Desde la consola también se puede acceder a cualquier servidor con
el agente de administración apropiado. Un analizador de LAN, NLM controla
la monitorización del tráfico de la red y ofrece estadísticas.
2.2 APORTES Y CONCLUSIONES
Luego de analizar cada uno de los administradores de red investigados, se
encontraron las siguientes características o funcionalidades principales:
Monitoreo de estado de dispositivos en tiempo real: se puede conocer el
estado actual de cualquier dispositivo conectado a la red.
Aviso y Manejo de alertas: se avisa de las alertas al administrador a través de
algún medio disponible, para que pueda reaccionar y solucionar problemas en
la red.
Inventario de Hardware y Software: permite administrar licencias y versiones
de software (distribución de software), a través de los equipos de la red.
Además controlan el inventario de dispositivos de hardware conectados a la
red, con sus características propias.
Distribución de carga de trabajo: permite distribuir carga en los diferentes
componentes de la red, previniendo que se generen cuellos de botella cuando
muchas solicitudes quieran acceder al mismo equipo. En algunos casos se
distribuye también la carga a nivel de enlaces entre dispositivos o equipos.
Administración de acceso a Internet e impresoras: permite configurar y
administrar el acceso de varias maquinas a Internet a través de alguna que
34
sirva como puerta de enlace, o de un enrutador que cumpla esta función.
Además facilitan las labores de compartir impresoras en redes grandes,
permitiendo el acceso de varios equipos a una o varias impresoras.
De todas estas cinco características se decidió que las más importantes son las
dos primeras, debido al impacto que tienen en el funcionamiento de la red. Por
ello se tendrán en cuenta las funcionalidades de Monitorear dispositivos en tiempo
real, y aviso de alertas (Traps). Las otras tres características no son menos
importantes, pero debido a las restricciones propias de este proyecto seria
imposible abarcarlas a todas.
35
3. SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL)
Para poder que un administrador de red mantenga comunicación con los
dispositivos de la red, es necesario que estos hablen un mismo lenguaje para que
se entiendan. Por eso en necesaria la escogencia de un protocolo de
comunicación entre la aplicación y los dispositivos. La razón de la escogencia de
SNMP como protocolo de administración de red, radica en la ventaja que este
brinda en no estar ligado a ninguna casa fabricante de dispositivos de red, así la
cobertura de administración de red de este proyecto, se verá amplificada y tendrá
un limitante menos a la hora de ser instalado en una red empresarial. De igual
forma SNMP es un protocolo, que a lo largo de los últimos años, todos los
fabricantes de dispositivos de red están incorporando en sus productos.
A lo largo de la evolución de las redes (empresariales o públicas) y los dispositivos
de red (routers, switches, etc.), se ha visto una marcada tendencia a un
crecimiento sin control de versiones y creadores de aplicaciones vinculadas a la
misma red, lo que lleva a agregar estas, prácticamente sin control alguno y
llevando a cada vez más usuarios hacer uso de la misma; por lo tanto los sistemas
de administración de redes, deben ser lo suficientemente flexibles para poder
soportar los nuevos dispositivos y aplicaciones que se van añadiendo, sin
necesidad de realizar cambios drásticos en el sistema administrador.
En la gestión o administración de redes, no existe una solución única, aceptada
por todos los fabricantes y que sea fácilmente adaptable a las redes
empresariales. Las soluciones existentes suelen ser propias de marcas
reconocidas como Netview de IBM o OpenView de HP, entre otras; lo que hace
que en una red compleja, formada por equipos o dispositivos de diferentes casas
matrices (Cisco, HP, IBM, etc.) no exista un único sistema capaz de realizar la
36
gestión de administración completa de la red, necesitándose varias plataformas de
administración de red, para poder llevar a cabo esta labor. En este entorno nació
SNMP.
3.1 Introducción
SNMP, es la salida y solución propuesta para poder unificar el proceso de
administración de redes privadas (Intranet), sin tener en cuenta la casa matriz
de donde provienen los dispositivos que componen la red. Es decir, que SNMP
permite la administración total de redes que se compongan de dispositivos de
diferentes marcas. [FI2004]
SNMP, en sus distintas versiones, es un conjunto de aplicaciones de gestión de
red que emplea los servicios ofrecidos por TCP/IP y que ha llegado a
convertirse en un estándar. Surge a raíz del interés mostrado por la IAB
(Internet Activities Board) en encontrar un protocolo de gestión que fuese válido
para Internet, por la necesidad que su mismo crecimiento estaba forjando.
Inicialmente se formaron tres grupos de trabajo, los cuales arrojaron
conclusiones distintas en sus investigaciones, siendo finalmente la de SNMP la
adoptada, incluyendo algunos de los aspectos más relevantes presentados por
los otros dos: HEMS (High-Level Management System) y SGMP (Simple
Gateway Monitoring Protocol). [JH2004]
37
Figura 2. Modelo de comunicación de SNMP [JH2004]
Como se observa en la figura 1, SNMP funciona a nivel de la capa de
aplicación, usando los servicios de TCP/IP. Los mensajes SNMP se
intercambian entre un Agente SNMP, que administra un dispositivo de red
especifico (puede estar este agente embedido dentro del dispositivo, o ser
externo a él), y un administrador de red conectado a este agente.
Para SNMP la red constituye un conjunto de elementos básicos; los
administradores que se encuentran en los equipos de la red, y los gestores o
dispositivos administrados, no son más que elementos pasivos dentro de la red
(Routers, Switches, Hubs, etc.). Dentro de SNMP, los dispositivos
administrados envían información a los administradores, por iniciativa propia en
caso de ocurrir eventos extraordinarios, o al ser interrogados por parte de los
administradores, apoyándose en los parámetros contenidos en sus MIB
(Management Information Base). Su principal inconveniente es el exceso de
tráfico que se genera, lo que lo puede hacer incompatible para entornos
amplios de red. En este punto es donde el uso de un sistema distribuido puede
38
permitir administrar de forma mas eficiente el trafico entre los dispositivos
administrados (agentes SNMP) y la aplicación de administración de red,
reduciendo las cargas, y aumentando la confiabilidad.
3.2 Historia
El protocolo SNMP fue diseñado a principios de los 90 por Case, McCloghrie,
Rose y Waldbusser, como una solución a los problemas de comunicación entre
diferentes tipos de redes.
En un principio, su principal meta era el lograr una solución temporal hasta la
llegada de protocolos de gestión de red con mejores diseños y mas completos.
Pero esos protocolos de red no llegaron y SNMPv1 se convirtió en la única
opción para la gestión redes.
El manejo de este protocolo era simple, se basaba en el intercambio de
información de red a través de mensajes (PDU). Además de ser un protocolo
fácilmente extensible a toda la red, que debido a su uso estandarizo entre
usuarios y empresas que no querían demasiadas complicaciones en la gestión
de sus sistemas informáticos dentro de una red.
No obstante este protocolo no era perfecto, además no estaba pensado para
poder gestionar la inmensa cantidad de redes que cada día iban apareciendo.
Para subsanar sus carencias surgió la versión 2 (SNMPv2), en donde las
mayores innovaciones respecto a la primera versión son: [JR2004]
Introducción de mecanismos de seguridad, totalmente ausentes en la
versión 1. Estos mecanismos protegen la privacidad de los datos, confieren
autentificación a los usuarios y controlan el acceso.
Mayor detalle en la definición de las variables.
39
Se añaden estructuras de la tabla de datos para facilitar el manejo de los
datos. El hecho de poder usar tablas hace aumentar el número de objetos
capaces de gestionar, con lo que el aumento de redes dejo de ser un
problema.
Realmente esta versión 2 no supuso más que un parche; es más hubo
innovaciones como los mecanismos de seguridad que se quedaron en pura
teoría y no se llegaron a implementar. Por estas razones, se ha producido la
estandarización de la versión 3. Con dos ventajas principales sobre sus
predecesores: [JR2004]
Añade algunas características de seguridad como privacidad,
autentificación y autorización a la versión 2 del protocolo.
Uso de Lenguajes Orientados a Objetos (Java o C++) para la construcción
de los elementos propios del protocolo (objetos). Estas técnicas confieren
consistencia y llevan implícita la seguridad, por lo que ayudan a los
mecanismos de seguridad.
3.3 MIB (Management Information Base)
A través del MIB se tiene acceso a la información para la gestión, contenida en
la memoria interna del dispositivo de red. La MIB es una base de datos
completa y bien definida, con una estructura en árbol adecuada para manejar
diversos grupos de objetos (información sobre variables/valores que se pueden
adoptar), con identificadores exclusivos para cada objeto.
La arquitectura SNMP opera con un reducido grupo de objetos que se
encuentran definido con detalle en la RFC 1066 "Base de información de
gestión para la gestión de redes sobre TCP/IP". Generalmente se manejan 8
grupos de objetos por la MIB (MIB-I), que definen un total de 114 objetos
(recientemente, con la introducción de MIB-II se definen hasta un total de 185
objetos). Estos 8 grupos son: [JR2004]
40
Sistema: Incluye la identidad del vendedor y el tiempo desde la última vez
que se reinició el sistema.
Interfaces: Interfaces únicas, múltiples, locales o remotas.
ATT (Address Translation Table): Contiene la dirección de la red y las
equivalencias con las direcciones físicas.
IP (Internet Protocol): Proporciona las tablas de rutas, y mantiene
estadísticas sobre los datagramas IP recibidos.
ICMP (Internet Communication Management Protocol): Cuenta el número
de mensajes ICMP recibidos y los errores.
TCP (Transmission Control Protocol): Facilita información acerca de las
conexiones TCP, retransmisiones, etc.
UDP (User Datagram Protocol): Cuenta el número de datagramas UDP,
enviados, recibidos y entregados.
EGP (Exterior Gateway Protocol): Recoge información sobre el número de
mensajes EGP recibidos, generados, etc.
De igual manera es necesario aclarar la existencia de tres diferentes tipos de
módulos MIB; entre los cuales encontramos: [JR2004]
Estándar:
Diseñados por un grupo de trabajo del IETF (Internet Engineering task
force) y estandarizado por el IESG (Internet Engineering Steering Group).
Los prefijos de los identificadores de objetos se encuentran bajo el subárbol
mgmt.
Experimental:
Mientras un grupo de trabajo desarrolla un MIB, los identificadores de
objetos temporales se colocan bajo el subárbol experimental. Si el MIB
41
adquiere la condición de estándar, se colocan los identificadores bajo el
subárbol mgmt.
Específico:
La mayor parte de las empresas desarrollan módulos MIB propios que
soporten ciertas características particulares, las cuales no son
generalmente contempladas en los módulos MIB estándar.
Mensajes: Para SNMP, poder proveer información proveniente de los dispositivos
administrados hacia los administradores y viceversa, creo 5 tipos de mensajes
distintos, para poder reportar entre ellos los eventos extraordinarios que se
generan dentro de la red. Estos 5 tipos de mensajes son: [JH2004]
Get Request:
Una petición del Administrador al Agente para que envíe los valores
contenidos en el MIB (base de datos).
Get Next Request:
Una petición del Administrador al Agente para que envíe los valores
contenidos en el MIB referente al objeto siguiente al especificado
anteriormente.
Get Response:
La respuesta del Agente a la petición de información lanzada por el
Administrador.
Set Request:
42
Una petición del Administrador al Agente para que cambie el valor
contenido en el MIB referente a un determinado objeto.
Trap:
Un mensaje espontáneo enviado por el Agente al Administrador, al
detectar una condición predeterminada, como es la conexión /
desconexión de una estación o una alarma.
De esta manera, SNMP provee de manera simple y flexible el intercambio de
información en forma estructurada y efectiva, proporcionando significantes
beneficios para la gestión de redes con dispositivos de diferentes marcas,
aunque es necesario aclarar, que para que estas comunicaciones se puedan
efectuar de la forma correcta, los dispositivos de red, deben encontrarse
funcionando en todo momento y que dentro de ellos este instalado y
funcionando el software de soporte al protocolo en mención. Software que
gracias al crecimiento y acogida del protocolo para la administración de redes,
se ha venido incorporando en los dispositivos de todas las marcas desde
mediados de los 90.
3.4 Ventajas de SNMP:
La ventaja fundamental de usar SNMP es que su diseño es simple por lo que
su implementación es sencilla en grandes redes y la información de gestión
que se necesita intercambiar ocupa pocos recursos de la red. Además, permite
al usuario elegir las variables que desea monitorizar sin más que definir:
[FL2003]
• El título de la variable.
43
• El tipo de datos de la variable.
• Si la variable es de solo lectura o también de escritura.
• El valor de la variable.
Otra ventaja de SNMP es que en la actualidad es el sistema más extendido. La
popularidad la ha conseguido al ser el único protocolo que existió en un
principio y por ello casi todos los fabricantes de dispositivos como Switches y
Routers diseñan sus productos para soportar SNMP.
La posibilidad de expansión es otra ventaja del protocolo SNMP: debido a su
sencillez es fácil de actualizar.
3.5 Desventajas de SNMP:
El protocolo SNMP no es perfecto, ya que posee algunos fallos que se han ido
corrigiendo a lo largo de las nuevas versiones. La primera deficiencia de SNMP
es en el campo de la seguridad; ya que se puede permitir a intrusos acceder a
la información que lleva la red; y estos por medio de ese acceso ilegal, pueden
llegar a bloquear o deshabilitar terminales importantes. Como se dijo
anteriormente, estos problemas se han venido solucionando a lo largo del
lanzamiento de sus nuevas versiones, y este problema se soluciona en su
versión SNMPv2, la cual básicamente ha añadido mecanismos para resolver:
[FL2003]
• Privacidad de los datos (los intrusos no puedan tomar información que
va por la red).
• Autentificación (para prevenir que los intrusos manden información falsa
por la red).
• Control de acceso (que restringe el acceso a ciertas variables a
determinados usuarios que puedan hacer caer la red).
44
Otro inconveniente de SNMP es que se considera tan simple que la
información está poco organizada, lo que no lo hace acertado para administrar
las grandes redes de la actualidad. Esto se debe en gran parte a que SNMP se
creó como un protocolo provisional pero que se ha quedado sin ser sustituido
por otro de entidad. Este problema se solucionó con otra versión, SNMPv2,
que permite una separación de variables con más detalle, incluyendo
estructuras de datos para hacer más fácil su manejo. Además SNMPv2 incluye
2 nuevas PDUs orientadas a la manipulación de objetos en tablas.
Posteriormente se lanzo una versión 3, SNMPv3, que mejora frente a SNMPv2
en aspectos como el tamaño de mensaje, seguridad, y manejo de datos. La
gran mayoría de dispositivos actuales tienen soporte para SNMPv1, algunos
para SNMPv2, y solo algunos muy nuevos, para SNMPv3. Por esto para
lograr una compatibilidad alta con los dispositivos administrados, para el caso
de Adredimo, se decide adoptar SNMPv1, soportado por todos los dispositivos
que soportan SNMP.
45
4. ARQUITECTURA DE SOFTWARE
4.1 Arquitectura MultiNivel
Por medio de esta arquitectura, se pueden generar divisiones dentro de la
aplicación, que faciliten y optimicen el sistema; permitiendo varias acciones
como la modificación de cada una de esas divisiones sin que ninguna otra se
de cuenta, una mayor escalabilidad, persistencia del sistema y transparencia
de acceso a la aplicación brindada por la capa de presentación, entre otras
La arquitectura multinivel permite una división funcional de la aplicación,
mediante módulos llamados capas, en donde cada una de ellas es la
encargada de resolver una parte fundamental de las transacciones solicitadas
por los clientes. Adicionalmente, las arquitecturas multinivel, favorecen los
sistemas distribuidos, gracias a su ya mencionada división funcional, porque
cada una de estas divisiones se puede distribuir dentro de una red de manera
que la colaboración entre estas lleve a feliz término las transacciones ofrecidas
por el sistema, con una alta confiabilidad y disponibilidad del mismo. [GC2001]
Una de las característica y ventaja que presenta esta arquitectura, es la
subdivisión funcional de un sistema en subsistemas que colaboran entre si para
poder llevar a cabo una transacción o petición proveniente desde un cliente.
Por esta razón, se pueden añadir más niveles y funcionalidades a la aplicación,
de manera que esta adición, no genere un impacto considerable en el resto del
sistema, ya que solo se tocarían aquellos niveles con los que el nuevo nivel
tenga que interactuar; porque cada nivel únicamente se comunica con los
niveles contiguos a través de interfaces claramente definidas, haciendo que los
cambios de una capa no interfieran en el funcionamiento de las otras.
46
4.2 Arquitectura de Aplicaciones Embebidas en Dispositivos Móviles
4.3 Plataformas para el desarrollo multicapas
En el desarrollo de aplicaciones empresariales, la colaboración entre
departamentos, y el desarrollo de aplicaciones han sufrido un auge muy
importante durante los últimos años. Frente a esta nueva demanda surgen dos
plataformas distintas para el desarrollo de este tipo de aplicaciones: J2EE de
Sun y .NET de Microsoft.
Para que una arquitectura de componentes pueda operar es necesario
disponer de un entorno normalizado que proporcione soporte a los
mecanismos con que se comunican las interfaces. Existen varios entornos de
soporte de componentes creados para uso interno de las empresas, pero los
más conocidos (actualmente comercializados) son: J2EE y .NET
4.3.1 Tecnología J2EE
J2EE define un estándar para el desarrollo de aplicaciones empresariales
multinivel; esto simplifica las aplicaciones empresariales basándolas en
componentes modulares y estandarizados, proveyendo un completo conjunto
de servicios a estos componentes, y manejando muchas de las funciones de la
aplicación de forma automática, sin necesidad de una programación compleja.
J2EE, maneja una arquitectura dividida en cinco (5) partes: El lenguaje de
programación Java, El modelo de programación del cliente, la infraestructura
de la capa de middleware, los API de negocios para los programadores y los
API no visibles para los programadores [SM2005]
47
A diferencia de Microsoft .NET que es un producto, J2EE es un estándar; por
lo tanto, no es posible descargarlo o adquirirlo, sino que es necesario adquirir
alguna de las versiones de plataformas de desarrollo basadas en J2EE que
existen en el mercado como Jboss, IBM WebSphere, BEA Weblogic,
Oracle9iAS o Sun ONE. Cada una estas versiones proporcionan servicios
añadidos a los propuestos en el estándar.
Dentro de la tecnología J2EE, existe una solución a desarrollos Web, que es
bastante utilizada, llamada EJB (Enterprise Java Bean). Los EJB, son una
tecnología desarrollada por Sun Microsystems, para entornos Java que
pueden ser utilizados por múltiples aplicaciones Un EJB también agrupa
servicios funcionales utilizables por aplicaciones, sin embargo, implica la
existencia de un entorno de ejecución conocido como “EJB Container”. Así,
mientras que un “Java Bean” requiere ser integrado con otros componentes
para que sea funcional, un EJB puede ser activado y usado con solo ser
incluido en un “EJB Container”. [SM2005]
Las principales características y ventajas ofrecidas por los Java Beans son:
1. División de Trabajo:
El “EJB Container” es el encargado de ofrecer los servicios y de manejar por
debajo toda la lógica de los componentes creados por el desarrollador, de
modo que el diseñador del componente se centra exclusivamente en el
desarrollo de la funcionalidad principal.
2. Procedimientos Remotos:
El diseño de los EJB gira alrededor de la tecnología RMI, lo que permite la
operación en Sistemas Distribuidos, y fáciles llamados sobre los Java Beans
(sean Session Beans o Entities Beans), mediante llamados de Lookup.
48
3. Diversos Clientes:
Un EJB puede interactuar con una gran gama de clientes: Servlets, bases de
datos, applets, sistemas ERP3, lo que le da una gran heterogeneidad e
independencia de plataforma.
De la misma forma los Java Beans también cuentan con debilidades como:
1. Tiempo de Desarrollo Elevado:
Desarrollar un sistema con Java Beans es sumamente complejo, siempre y
cuando no se cuente con herramientas de desarrollo, que faciliten a los
programadores el ahorro de creación de líneas de código, como en la
actualidad lo hace JBuilder, Eclipse, BEA Workshop, entre otros. Por esta
razón el tiempo de desarrollo es relativo a las herramientas que se tengan por
parte de los programadores, haciendo que esta debilidad desaparezca si se
cuenta con alguno de los recursos nombrados anteriormente.
2. Conocimiento Exhaustivo de Java:
Esta tecnología, integra bastantes conocimientos de otros componentes de
J2EE como RMI, JNDI, JDBC, entre otras, lo que supone que depende
fuertemente del conocimiento en estas otras tecnologías también.
4.3.2 Tecnología .NET
.NET es una plataforma llena de servicios para construir aplicaciones basadas
en Web y desarrollar experiencias interactivas para los usuarios y sus
sistemas. La arquitectura de la plataforma .NET se puede dividir
49
principalmente en: .NET framework, es la parte más importante de la
plataforma .NET. Incluye COM+, un entorno de ejecución común, un
compilador JIT, y un conjunto de librerías de sistema que dan acceso a un
amplio conjunto de servicios y servidores .NET, que son un conjunto de
aplicaciones que pueden usarse en conjunción con el .NET framework para
facilitar el desarrollo de aplicaciones empresariales. Como por ejemplo SQL
Server 2000, Exchange 200 Server o BizTalk Server 2000.
Como se puede ver dentro de la arquitectura de .NET, especialmente en su
framework, existen soluciones para aplicaciones como lo es COM+, que es
una tecnología desarrollada por Microsoft por medio de “Microsoft Component
Object Model”. Esta tecnología aborda la solución basándose en que es más
práctico restringirse a un único lenguaje, proporcionando un sencillo, pero a la
vez potente modelo para construir sistemas software a partir de la interacción
de objetos (componentes). [MI2005]
COM+ define un estándar binario (esto implica que es independiente del
lenguaje de programación) para objetos y la intercomunicación entre ellos.
Toda comunicación se realiza a través de operaciones que son
proporcionadas dentro de interfaces. El diseñador invoca las operaciones que
necesite directamente, incluso si el objeto destinatario está localizado en otro
proceso o en otra máquina. De este modo, la combinación de la tecnología
COM junto con las técnicas de programación orientada a objeto, nos ofrece
una importante simplificación en el proceso de desarrollo de aplicaciones
informáticas. [MI2005-1]
Como mejora a la tecnología COM, en 1998 se introdujo en el mercado la
tecnología COM+, que presenta varias mejoras a la anterior tecnología, como
lo son:
50
1. Simplifica el desarrollo de los componentes porque genera de manera
automática las diversas interfaces necesarias en COM.
2. Las interfaces se define por medio de lenguajes estándar
3. Proporciona un modelo más simple y robusto para registrar e instalar
componentes, permitiendo reescribir la versión de una clase asociada a un
paquete.
4. Liberación de memoria, accesos seguros y sistemas distribuidos
5. Compatible con COM
Otros de los componentes, que se han unido a la tecnología .NET, es CORBA
(Common Object Request Broker Architecture), que se vincula al igual que
COM+, dentro del framework principal de esta tecnología. CORBA es una
tecnología desarrollada por OMG y ahora vinculada a .NET; esta solución
permite cubrir las necesidades de interoperabilidad entre los diversos
productos hardware y software que nos ofrece el mercado hoy en día. Creando
una arquitectura CORBA-ORB, que se compone de los siguientes elementos:
[MI2005-1]
1. Object:
Entidad de programación de CORBA compuesta de una identidad, una
interface y una implementación.
2. Servant:
Implementación de un Object donde se definen las operaciones ofrecidas por
una interfaz CORBA - IDL.
3. Client:
51
Entidad de programación que invoca una operación sobre un Object. El acceso
a los servicios del Object remoto es transparente para el usuario Client.
4. ORB (Object Request Broker):
Mecanismo que proporciona una comunicación transparente entre el Client y el
Object. Esto hace que las solicitudes de Client sean aparentemente simples
procedimientos locales desde su punto de vista.
5. IDL (Stubs / Skeletons):
Son el punto de conexión entre el Client / Object (respectivamente) y el ORB.
La transformación entre la definición del CORBA IDL y el lenguaje de
programación utilizado es automática a través del compilador IDL.
6. DII (Dynamic Invocation Interface):
Interface que permite al cliente acceder directamente a los mecanismos
subyacentes de peticiones que ofrece un ORB. Las aplicaciones utilizan el DII
para realizar peticiones dinámicamente sin necesidad de utilizar interfaces IDL
(Stubs).
7. DSI (Dynamic Skeleton Interface):
Es el análogo al DII. El DSI permite a un ORB trasladar peticiones a un Object
que no tiene conocimiento en tiempo de compilación del tipo de Object que va
a implementar.
8. Object Adapter:
Es el encargado de asociar los distintos Servants con el ORB. Pueden ser
especializados para ciertos estilos de Servants, como por ejemplo OODB3
Object Adapters para objetos persistentes o Library Object Adapters para
objetos locales.
Ya que se ha hecho una descripción de los diferentes tipos de entornos y de
mecanismos de comunicación de niveles, se ha decidido trabajar bajo la política
52
de los Java Beans, por ser una tecnología con una arquitectura subdividida, y que
provee bastantes herramientas para el desarrollo. Adicionalmente, los únicos
costos que se vinculan al proyecto, hacen relación a soportes y herramientas de
desarrollo, entre otras; ya que el resto depende directamente del JSDK que se
encuentre disponible en el mercado.
Pero para poder obtener un correcto funcionamiento de Java Beans es necesario
evaluar los diferentes tipos de Contenedores disponibles para esta tecnología de
igual forma.
4.4 Contenedores de Java Beans:
Para soluciones de J2EE con Enterprise Java Beans, existen múltiples
contenedores disponibles en el mercado; por lo que se mencionarán los más
reconocidos y comunes en el mercado, desde el punto de vista del número en
desarrollos, funcionalidades, y resultados exitosos en proyectos anteriores y sobre
todo por ser referencias principales dentro de Sun Microsystems (referencia
principal de tecnologías Java).
4.4.1 Sun One Application Server Standard Edition [SM2005-1]
Sun ONE Application Server Standard Edition proporciona una plataforma
J2EE de alto rendimiento para facilitar servicios de aplicaciones de nivel
empresarial y servicios Web. La versión Standard Edition, añade funciones de
administración de operaciones a Sun ONE Application Server Platform Edition,
proporcionando una plataforma J2EE de bajo costo ideal para
implementaciones de nivel empresarial. Asimismo, ofrece una fácil
administración de distintas instancias de servidor de aplicaciones a través de
un único servidor de administración, lo que reduce los costes de
administración. Estas funciones de administración permiten la administración
remota y una infraestructura de control basada en SNMP.
53
Sus principales características son:
1. Administración de operaciones para control remoto de varias instancias a
través de un único servidor de administración.
2. Compatible con J2EE 1.3, admite JSP, Servlets, y aplicaciones basadas en
EJB.
3. Incluye servidor HTTP con un software de colas de alto rendimiento.
4. Proporciona una estructura de servicios Web muy grande.
5. Integrado con Sun One Studio 4 y Sun One Application Framework.
Sus principales ventajas son:
1. Reducción de costos de administración
2. Reduce el riesgo de atarse a un solo proveedor
3. Plataforma HTTP escalable para servicios Web y aplicaciones
empresariales.
4. Aumenta productividad del desarrollador.
Las características de funcionamiento son:
1. 500 MB de espacio en disco
2. 256 como mínimo de RAM, aunque puede aumentar según la
configuración.
3. Compatible con Windows 2000 y XP, Red Hat Linux 7.2, HP-UX 11i, IBM
AIX4.3.3 y entornos Solarios 8 o 9
4.4.2 JBoss
JBoss es una implementación Open-Source de un "EJB Container"; mediante
el cual es posible llevar acabo un desarrollo con Java Beans. Este tipo de
54
producto ("EJB Container") generalmente no es distribuido como producto
individual y por esta razón se le puede considerar como un producto diferente.
Jboss es únicamente un contenedor para Java Beans, y es por esto que
generalmente se utiliza en conjunción con un "Web-Container", el "Web-
Container" puede ser cualquiera disponible en el mercado, sin embargo,
cuando se trabaja con Jboss existe la posibilidad de incluir Tomcat o Jetty
(Web container que viene con JBoss); lo anterior no lo restringe para operar
con otro "Web Container" como ServletExec. Lo que le da la ventaja de tiempo
de ejecución, coordinación y configuración entre JBoss y los Web Containers
utilizados (Servlet Engines).
Las características de funcionamiento son:
1. Mínimo procesador de 350 MHz o más
2. Mínimo 400 Mb libre en el disco
3. Mínimo 128 Mb en memoria RAM, recomendado 256
4.4.3 Oracle 9i Application Server
Oracle 9i Application Server es uno de los servidores de aplicaciones J2EE
más rápidos, completos e integrados. Oracle 9i AS ofrece software de portal,
servicios inalámbricos y de voz, caché de páginas Web, business intelligence e
integración completa.
Las características de funcionamiento son:
1. Mínimo procesador de 450 MHz o más
2. Mínimo 560 Mb libre en el disco para J2EE y la Cache Web, 1.1 Gb para
Wireless, 1.51 para Business Intelligence y 2.6 Gb para la infraestructura del
Oracle Application Server 10g. (cada componente puede o no instalarse a
excepción de J2EE)
3. Mínimo 128 Mb en memoria RAM, recomendado 256
55
4. Monitor de 256 Colores
4.4.4 WebSphere
Es una plataforma de software que centra su rendimiento en 4 pilares:
integración, escalabilidad, flexibilidad y compatibilidad; y que permite
construcción de aplicaciones de acuerdo a las necesidades, objetivos y
estrategias sin temer por la incompatibilidad e integración de diversas
tecnologías.
WebSphere es software de infraestructura que permite a las compañías
desarrollar e integrar aplicaciones de la nueva generación e-business, como
aplicaciones para business to business (B2B) que van más allá de simplemente
publicar información en la Web a transacciones empresariales. Pero este
contenedor esta más enfocado a aplicaciones e-business.
Las características de funcionamiento sobre plataformas Windows 2000 – 2003
son:
1. Mínimo procesador Intel Pentium (o equivalente) de 500MHz o más, Intel
EM64T o AMD Optaron de 64 bit (solo com 32 bit de sistema de soporte
operativo)
2. Mínimo 990 Mb libre en el disco
3. Mínimo 512 Mb en memoria RAM, recomendado 1Gb
4. Unidad de CD-ROM
Las características de funcionamiento sobre plataformas Linux son:
1. Mínimo procesador Intel X86 de 500MHz o más, Intel EM64T o AMD
Optaron de 64 bit (solo com 32 bit de sistema de soporte operativo)
2. Mínimo 995 Mb libre en el disco
56
3. Mínimo 512 Mb en memoria RAM, recomendado 1Gb
4. Unidad de CD-ROM
Luego de haber descrito y analizado cada uno de los contenedores disponibles en
el mercado actual para los EJB, se decidió trabajar con Jboss, ya que permite el
manejo necesario para este proyecto al igual que los demás; pero a diferencia del
resto, permite que ADREDIMO pueda funcionar sobre máquinas de menor
capacidad que es lo que se necesitaría con los demás contenedores, permitiendo
que el sistema de administración pueda ser adoptado también por pequeñas
empresas que no cuentan con grandes recursos.
57
5. ADREDIMO A lo largo del ciclo de vida del proyecto, aparecieron diferentes etapas desde la
concepción inicial de la idea, hasta el producto final de la investigación. En este
capitulo se muestran todos los procesos a los que el proyecto fue sometido, y los
cuales debió superar para poder presentar esta nueva propuesta en
administración de redes empresariales multifabricantes.
De igual forma y como se ha podido observar a lo largo de los capítulos anteriores,
que expresan el marco teórico de este proyecto, existen muchas y variadas
alternativas de desarrollo para un administrador de red. Así como también existen
varias opciones que se le pueden embeber a este. Por eso en este capítulo podrá
encontrar las especificaciones adoptadas para el proyecto, y como es que este
nuevo sistema de administración de red se encuentra concebido.
5.1 ANÁLISIS DE LA SOLUCIÓN
La solución radica en la construcción de una aplicación de administración de red,
que permita el acceso de un dispositivo móvil a sus funciones, para que pueda
solucionar inconvenientes que se presenten en la red de una empresa. Este
dispositivo, deberá poseer una conexión inalámbrica con los servidores en donde
se encuentra el sistema distribuido. El servidor que reciba la conexión deberá
proveer los servicios necesarios al dispositivo, para poder desde este solucionar
los inconvenientes que se presenten en la red; siendo un sistema transparente y
con una alta disponibilidad.
58
Para lograr el correcto funcionamiento de esta propuesta, se deben analizar
algunos de los posibles escenarios con los que el administrador se pueda
encontrar, y en los que se requiera de las funcionalidades especificas que esta
propuesta proporciona, para lograr mejores soluciones.
5.2 CARACTERÍSTICAS PRINCIPALES DE LA PROPUESTA
Primero se tiene una arquitectura multicapas. Esta estructura permitirá que se
manejen por separado los datos persistentes (capa de datos), de las funciones de
administración de red (capa de aplicación), y las funciones de presentación a los
clientes móviles o fijos (capa de presentación). Esto nos dará facilidades para
implementar un acceso transparente a los diferentes clientes, sean móviles o
estacionarios.
La segunda característica es el enfoque que se debe tener en la arquitectura
distribuida, por lo que la herramienta de administración de la red debe residir en
varios servidores que se encuentren distribuidos a lo largo de las instalaciones
físicas de la empresa, haciendo que se vea de manera transparente para el
usuario como un solo sistema, sin que esto cause conflictos de ninguna especie
en la utilización de la misma, con el fin de incrementar la disponibilidad y
oportunidades de acceso a la administración de la red desde el dispositivo móvil,
solo con que este tenga acceso a la red. Además la arquitectura distribuida
permite una mayor tolerancia a fallas, y una mayor disponibilidad al existir
maquinas de “backup”, con replicas de los procesos críticos, para poder brindar
sus servicios al administrador con la mayor disponibilidad posible.
59
5.3 BENEFICIOS DE ADREDIMO
• Disponibilidad:
Al estar construida de forma distribuida, la aplicación de red es tolerante a
fallas, lo que hace que pueda ofrecer sus servicios de manera casi constante,
solo interrumpidos por fallas mayores en la red.
• Tiempo de resolución de problemas:
Permite disminuir el tiempo que actualmente se emplea por parte del
administrador de red para solucionar los inconvenientes que impidan el
correcto funcionamiento de la red, o que afecten el desempeño de la misma.
• Disminución de costos:
Al disminuir los tiempos de resolución de problemas, las empresas podrán
disminuir los costos de oportunidad que se generan mientras la red esta
desconectada.
• Facilidad de uso:
Será mucho más cómodo para el administrador de la red el hecho de poder
solucionar los inconvenientes de la red desde el lugar en el que se encuentre
en la empresa, pudiendo usar un dispositivo móvil, como un PDA.
5.4 REQUERIMIENTOS Como en cualquier proceso de desarrollo de software, es necesario definir y
aclarar las especificaciones y requerimientos con que el sistema debe contar para
poder evaluar posteriormente cuando ya se tenga el producto final, el grado de
éxito alcanzado por el sistema implementado, ya que basándose en los
requerimientos se puede definir si el sistema final cumple con las condiciones que
inicialmente fueron dadas al proyecto.
60
A continuación podemos encontrar esas condiciones iniciales que se adoptan
como compromisos de cumplimiento para ADREDIMO; y por medio de las cuales
se rige el proceso de diseño e implementación de este administrador de red.
5.4.1 Requerimientos de administrador de red:
• El administrador de red permitirá monitorear el estado de los componentes
de red (con soporte SNMP), dado que este protocolo permite a los
dispositivos almacenar variables con su estado (MIB - Base de datos de
variables), y que un agente administrador de red puede acceder a estas
variables; permitiéndole monitorearlas con regularidad y saber su estado en
un momento específico. Las variables que se van a monitorear en un
principio son las que hacen parte de la MIB básica de los dispositivos
SNMP, entre las cuales se tienen (Para ver la información detallada de
cada uno ver Anexo A):
MIB BASICA
SysDescr:
Descripción textual que incluye todos los datos completos del
dispositivo; solo contiene Caracteres ASCII
SysObjectID:
Provee una descripción de que en tipo de red esta el dispositivo,
dentro de la red administrada (en que subred se encuentra).
61
SysUpTime:
Tiempo que el dispositivo lleva activo en la red luego de su
último inicio.
SysContact:
Identificación y descripción de la persona encargada del
dispositivo, junto con la información de como contactarlo.
SysName:
Nombre que se le da al dispositivo en el entorno administrativo.
SysLocation:
Ubicación física del dispositivo.
IfNumber:
Número de interfaces de red presentes en el dispositivo.
IfSpeed:
Estimativo del ancho de banda por interfaces de red en bits
por segundo.
IfPhysAddress:
Dirección de interfaces en la capa de protocolo junto al
protocolo de la capa de red.
IfAdminStatus:
Petición de estado de interfaces. Los estados de prueba
muestran que paquetes no operacionales no pueden pasar.
62
IfOpenStatus:
Muestra el estado de la operación en curso de la interfaz del
dispositivo
AtNetAddress:
Dirección de red correspondiente al dispositivo (Dirección IP).
• El administrador de red permitirá capturar y manejar los mensajes (Traps)
provenientes de los dispositivos de red (Switches, Routers, PC, etc.) que
actúan como agentes debido al soporte SNMP que estos poseen y les
permite enviar mensajes por la red hacia el administrador. Los Traps que
se van a manejar son:
ColdStart: Mensaje que comunica la necesidad de reiniciar el
dispositivo debido a algún cambio en la configuración de
la red.
LinkDown: Mensaje que comunica una falla en uno de los enlaces
de comunicación de uno de los dispositivos (agentes) de
la red.
LinkUp: Mensaje que indica la reconexión de uno de los enlaces
de comunicación de algún dispositivo (agente).
• El administrador de red permitirá modificar los valores de las variables con
opción de escritura de la MIB de cada uno de los dispositivos que se estén
administrando. No todos los valores monitoreados pueden ser cambiados,
debido a su restricción de acceso, ya que unos tiene acceso de solamente
de lectura y otros de lectura / escritura. Los valores monitoreados al ser
modificados (aquellos que lo permitan), cambiarán el funcionamiento y
disposición de los dispositivos dentro de la red; dependiendo de la variable
modificada el dispositivo cambiará su funcionamiento.
63
• El administrador de red debe ser distribuido de forma que si se cae uno de
los componentes, existan otros disponibles para atender las peticiones de
los clientes. Cada componente debe mantener un funcionamiento
independiente y mientras exista al menos uno en funcionamiento, deberá
cumplir con las funciones solicitadas por el cliente. En el caso de las tareas
críticas, el administrador de red permitirá la puesta en funcionamiento de un
sistema de backup (en caso de que un punto de entrada de haya caído); el
cual permitirá realizar la atención a las solicitudes realizadas por los clientes
de igual forma que se hacía con el sistema principal.
• El administrador de red permitirá implementar un método de seguridad y
autenticación de usuarios. El énfasis del sistema de administración de red,
no esta en la seguridad, pero esta debe manejarse para la interactividad
con los usuarios autorizados, independientemente de la plataforma que
estén manejando. El sistema de autenticación se basara en contraseñas
de usuario como proceso de autenticación.
• El administrador debe guardar registro de todos los Traps que se generen
desde cualquier dispositivo dentro de la red, para poder ser consultados
posteriormente por los clientes.
• El administrador debe almacenar en una Base de Datos la información
pertinente a los dispositivos que conformen la red, especificando un nombre
dado por el cliente, la dirección IP con que el dispositivo fue configurado
dentro de la red y el Community String de acceso a la MIB de los
dispositivos de red.
64
5.4.2 Requerimientos de Cliente:
• El cliente permitirá un acceso por medio de un Browser a la aplicación de
administración de red, la cual debe ser liviana para poder ser procesada en
dispositivos móviles.
• El cliente debe poseer un Browser que soporte HTML o WML en el caso de
los dispositivos móviles.
• El cliente que desee tener habilitada la opción de recepción en tiempo real
de Traps de alerta, debe tener soporte Java en la máquina desde donde se
acceda al sistema de administración de red.
• El cliente no móvil, podrá conectarse a al interfaz Web desde cualquier
maquina de la red, que tenga habilitado un navegador y el protocolo TCP-
IP.
5.5 ARQUITECTURA DE SOFTWARE
ADREDIMO es un administrador de red distribuido, con arquitectura multinivel, que
ofrece una orientación especial a su uso mediante dispositivos móviles. La
escogencia de la arquitectura multinivel para este proyecto radica en sus grandes
ventajas y características de división de funcionalidades que a continuación se
especifican. Adicionalmente se dan pautas para la selección del Contenedor que
se va a manejar en el lanzamiento de los servidores de aplicación, los cuales
proveen técnicas que derivan en la disponibilidad y confiabilidad del sistema.
Adredimo adoptará una arquitectura de cuatro (4) niveles, distribuidos de la
siguiente manera: El sistema de administración de red se dividirá en 3 funciones o
niveles principales, la capa de presentación (con la que interactúa el cliente) la
capa lógica (la encargada de la lógica del negocio) y la capa de persistencia
65
(bases de datos). De igual forma la capa de lógica del negocio, se dividirá en dos
pequeñas partes: la primera es la presentación, a realizar mediante servicios
WEB, y la segunda es la de lógica de aplicación, con componentes distribuidos.
Para poder llevar a cabo esta implementación también es necesario tener especial
cuidado en no saturar el sistema de niveles, ya que si aumenta más de lo
necesario el número de niveles, aumentará el número de comunicaciones, el
tiempo de repuesta y si existen niveles que residan en máquinas diferentes,
aumentaría la carga de red.
Igualmente para el nivel de la capa lógica, es necesario definir como va a ser el
manejo de la información y las transacciones; y por medio de que contenedor se
van a manejar los requerimientos no funcionales; para que los requerimientos
funcionales sean el centro de atención a la hora de programar. En el caso de este
proyecto, como se ha descrito en los capítulos anteriores, se va a utilizar Jboss,
como servidor de aplicaciones.
Debido a la escogencia de Enterprise Java Beans (EJB) como solución al sistema
de administración de red, el diagrama de la arquitectura multinivel queda
constituido de la siguiente forma:
66
Figura 3. Arquitectura de ADREDIMO
En la parte izquierda se observa la capa de presentación, que como su nombre
indica, se encarga de presentar la información del sistema a los clientes, y sirve
como interfaz para las solicitudes de estos. En la parte central se encuentra la
capa de lógica, donde se encuentran los EJBs, componentes encargados de las
funciones principales del sistema, que contienen la lógica del negocio. Finalmente
en la parte derecha esta la capa de datos, encargada de la persistencia de la
información de Adredimo a una base de datos (MySql).
De igual forma la comunicación entre niveles se da de la siguiente forma:
67
Figura 4. Diagrama de comunicación de capas de ADREDIMO
Como se observa en la figura 4, los clientes se comunican con los Servlets, ya sea
usando HTTP, o WAP. Los Servlets usan RMI-IIOP para comunicarse con los
EJBs, e invocar sus métodos. En el caso de Adredimo se usa un componente que
funciona como delegado para la comunicación entre los Servlets y los EJBs, y
ofrece una interfaz completa para los clientes externos, hacia el sistema en si. Por
el otro lado, los Entity Beans utilizan JDBC para acceder a la base de datos MySql
y utilizar su información.
68
5.6 DISEÑO DISTRIBUIDO DE ADMINISTRACION DE RED
Figura 5. Diseño de sistema Adredimo.
69
Como se puede observar en la figura 5, el diseño de Adredimo, se centra sobre
una arquitectura netamente Multicapas, y de una naturaleza distribuida, ya que
permite realizar una división funcional de la aplicación. Esta división funcional,
permite que el sistema mantenga una transparencia hacia el cliente, sea tolerante
a fallos, mantenga una alta disponibilidad gracias a los múltiples servidores de
aplicación.
En un principio, como lo muestra el diseño, el cliente debe tener acceso a la red a
administrar, ya sea por medio de un PC o un dispositivo móvil con acceso
inalámbrico. Cuando los clientes ingresan a la aplicación se dirigen directamente
al Servidor Web, que es el encargado de realizar la distribución de Carga, sobre
los servidores de aplicación.
El servidor de interfaz a cliente, es el encargado de mantener los Servlets, y la
capa de presentación (paginas html y jsp), y es el acceso a la presentación de la
información por parte del administrador, y el punto de entrada a los datos que
deben ser ingresados por parte del usuario final.
Los servidores de aplicación son lo encargados de mantener el módulo de los EJBs, y manejar los intercambios de información y actualización de la misma sobre la base de datos de componentes.
5.7 PROCESOS CRITICOS DE ADREDIMO
Luego de la definición de los requerimientos del sistema, se analizo una de las
características principales que debe tener el proyecto, la cual es la disponibilidad.
Para garantizar dicha característica, se deben definir los procesos críticos que
deben estar siempre “disponibles”, para el correcto funcionamiento de la aplicación
de administración de red. Estos procesos deben ser replicados, para que en el
caso que una maquina falle, siempre se pueda invocar en otra maquina. Para el
caso de Adredimo, se concluyo que los procesos críticos son los siguientes:
70
Almacenamiento de alertas (Traps) en la base de datos. Este proceso es
critico porque es el que permitirá al administrador consultar los traps que se
han generado, en el caso de que quiera conocer el historial de eventos, o
que no disponga del aviso en tiempo real de alertas. Esto permite analizar
el comportamiento de la red, y en algunos casos predecir fallas a futuro.}
Acceso a la base de datos de dispositivos de red. Es vital este proceso
porque permite al administrador conocer los dispositivos que tiene
conectados a la red, y decidir cual desea monitorear o ajustar. En el caso
de agregarse nueva información esta debe ser replicada en las bases de
datos que sea pertinente.
5.8 IMPLEMENTACION
En esta sección de este capítulo se describe la implementación final del sistema
Adredimo. Se explica en detalle los componentes que forman el sistema, y su
función dentro del mismo. Además se aclara la forma en que estos trabajan en
conjunto para realizar sus funciones.
5.8.1 Módulos de la Arquitectura de Software Distribución Cargas Adredimo
Este Modulo Web es el encargado de recibir todas las solicitudes iniciales de los
clientes de Adredimo, para ingresar al sistema, convirtiéndose en la puerta de
entrada al administrador de red, y realizando la distribución de cargas entre los
servidores de aplicación que se encuentren disponibles en el momento,
71
manteniendo un listado de los servidores que pueden atender a los clientes, los
cuales conforman un grupo específico en la red.
Por otro lado este módulo Web solamente se debe encontrar habilitado en el
servidor de entrada al sistema, y en uno o varios servidores que harán las veces
de Back Up, para cuando el servidor principal no se encuentre disponible.
Este módulo, solo contiene un único Servlet, que se encarga de manejar la lógica
de la Distribución de Carga, entre los servidores de aplicación.
Adredimo Web Module
Este módulo Web se debe encontrar en todos los servidores de aplicación, de la
misma forma como deben encontrarse referenciados en el módulo Web
Distribución de Cargas, que se encuentra en el servidor de entrada al sistema.
Este módulo Web es el encargado de comunicar la presentación con la lógica de
negocio, usando Servlets, y la comunicación que estos mantienen con los
Enterprise Java Beans (EJB). Dentro de este módulo, se encuentra la
presentación de la capa lógica, tanto de los clientes WEB, como Móviles.
Enterprise Java Beans Module
Este modulo contiene los componentes EJB distribuidos que son el núcleo de
todas las funciones de Adredimo. En ellos esta implementada la lógica del
negocio, y las funciones que controlan los Entity Beans, encargados de la
persistencia de la información. En Adredimo se compone de 3 Session Beans, y 3
Entity Beans BMP.
72
5.8.2 Páginas HTML y JSP Adredimo se compone de pocas páginas HTML y WML, ya que sus Servlets son
los encargados de generar las páginas de navegación. El caso de HTML, se
maneja para acceso de clientes con browser que soporte HTTP, mientras que
WML, se maneja para clientes de dispositivos móviles con soporte WAP, y sin
soporte HTTP.
Las dos (2) principales páginas de presentación que encontramos en Adredimo
son las páginas de inicio o “Index”, las cuales poseen sus tres versiones,
“index.html”, “indexMovil.html” e “index.wml”.
“Index.html”, es una página compuesta por tres (3) frames principales, y es usada
para el uso de clientes de computadores de estaciones de trabajo, ya que ofrece
una interfaz con una distribución para monitores de más de 14 pulgadas. Para los
dispositivos móviles que tienen soporte HTTP se creo una pagina html llamada
“indexMovil.html”, que junta todas las características de “index.html”, pero
diseñado para pantallas de Pocket PC.
“Index.wml”, es una página WML, la cual tiene como objetivo final, únicamente el
ingreso de los datos de inicio del sistema, ya que estos son enviados luego al
servlet correspondiente dentro del Módulo Web “Adredimo Web Module”
5.8.3 Servlets
Servlet de Distribución de Cargas
La distribución de cargas es efectuada únicamente por un servlet llamado
“adredimo”, el cual mantiene una referencia a cada uno de los servidores
dispuestos como servidores de aplicación, mediante una cola de servidores, y a
73
medida que es llamado desde una estación cliente, se encarga de ir asignando
clientes a cada servidor de aplicación, desde el primero hasta el último y cuando
llega a este retorna a asignar el siguiente cliente al primer servidor de aplicación
en la cola.
Servlets WEB
Junto con los Servlets WAP, con los cuales se encuentran en el mismo módulo
Web (Adredimo Web Module), los Servlets WEB, manejan la lógica del negocio
para aquellos clientes que ingresan y mantiene comunicación con el sistema
utilizando el protocolo HTTP.
Para poder realizar una eficiente labor al cliente final, y que este obtenga los
resultados esperados, se dividieron tareas en Servlets distintos, y se les permitió
a estos manejar la presentación al cliente final, mediante la autogeneración de
páginas HTML.
Los Servlets que podemos encontrar como Servlets WEB y sus tareas respectivas,
son los siguientes:
Ingreso:
Este Servlet, es el encargado de recibir la información de ingreso del
usuario, por medio de una verificación de datos, la cual la hace contra la
Base de Datos. Si la base de Datos no esta activa, tiene la opción de
permitir el ingreso de un usuario genérico con una clave genérica, para
acceder a todas las funcionalidades del sistema.
AdicionDispositivos:
Este Servlet, es el encargado de capturar los datos de entrada para nuevos
dispositivos que se vayan a adicionar a la base de datos; para adicionarlos
a la Base de Datos. Luego el Servlet se encargará de decirle al usuario si la
adición fue realizada con éxito o no.
74
Monitoreo:
Este Servlet, es el encargado de solicitar los datos de ingreso del
dispositivo sobre el que se va a realizar el monitoreo de la MIB, para saber
su estado actual. Para esto, trae de la Base de Datos, el listado de
dispositivos de la red, cuando el usuario selecciona el dispositivo que
desea, se encarga de traer de la Base de Datos la dirección IP del mismo
dispositivo, y envía la solicitud al Servlet “ResultadosMonitoreo”, para que
este continúe el proceso.
ResultadosMonitoreo:
Este Servlet es invocado necesariamente por el Servlet “Monitoreo”, y se
encarga de recibir los datos “nombre de dispositivo” e “dirección IP del
dispositivo”; así mismo debe solicitarle al usuario el ingreso del
“community”, para poder realizar el monitoreo de la MIB. Cuando estos
datos son ingresados, por medio de los Session Bean, se encarga de traer
los datos actuales del dispositivo seleccionado, y los muestra al usuario.
TrapsAdredimo:
Este Servlet, es el encargado de mostrar los Traps que han sido capturados
por el sistema y almacenados en la Base De Datos, para que el
administrador de red pueda hacer un seguimiento de los eventos más
frecuentes, y pueda tomar acciones correctivas sobre los mismos.
SetValorMIB:
Este Servlet se encarga de recibir las peticiones para cambiar los valores
de la MIB básica de los dispositivos de red, capturando los datos de
entrada, permitiendo modificarlos y realizando la escritura en el dispositivo.
75
SalidaAdredimo:
Este Servlet se encarga de cerrar la sesión del usuario, impidiéndole
acceder a alguno de los servicios del administrador de red.
Servlets WAP
Como fue mencionado señalado en la sección 7.3.2 Servlets WEB, los Servlets
WAP, hacen las tareas paralelas que realizan los Servlets WEB, para aquellos
clientes que no poseen soporte de protocolo HTTP, y usan una conexión WAP.
Aunque las tareas que realicen los Servlets WAP y WEB, sean paralelas y
similares, la codificación de las mismas, no es igual, ya que en estos Servlets no
podemos manejar sesiones de usuarios, y WML tiene una presentación mediante
“tags” especiales llamados “card”, que permite que se realice la presentación final
al cliente. Y la captura de datos.
Los Servlets que podemos encontrar como Servlets WAP son los siguientes:
MenuWap:
Este Servlet se encarga de recibir los datos de ingreso del usuario, y
verificarlos. Si el acceso es permitido, le muestra al usuario el menú que
tiene disponible; y para los casos de Adición de Dispositivos, y Monitoreo,
se encarga de recibir los datos de entrada, mediante nuevas “card” que
crea en presentación. Luego redirecciona la solicitud a los Servlet
correspondientes.
76
MonitoreoWap:
Este Servlet recibe los datos de entrada, y realiza la consulta de los valores
básicos de la MIB, mediante los Session Bean, y se encarga de mostrar los
resultados correspondientes al dispositivo.
ConsultaTrapsWap:
AL igual que su semejante en Servlet WEB, este Servlet, se encarga de
listar los Traps capturados por el sistema de administración de red, y
presentarlos al usuario final.
SetValorMIBWap:
Este Servlet se encarga de recibir las peticiones de clientes móviles, para
cambiar los valores de la MIB básica de los dispositivos de red. Al igual que
su semejante en la parte WEB, este Servlet, también realiza la escritura de
los nuevos valores en los dispositivos de red.
AdicionDispositivosWap:
Este Servlet se encarga de recibir los datos de ingreso de Dispositivos a la
Base de Datos del sistema, y transmitir esta solicitud a los Session Bean
correspondientes, para que efectúen la operación, informando al final el
éxito o fracaso de la operación realizada.
5.8.4 Enterprise Java Beans La arquitectura del sistema Adredimo esta basada en J2EE, especialmente en la
tecnología de Enterprise Java Beans. Esto permite que sea clara la distribución
de responsabilidades y cargas en el sistema, lo que además le proporciona todas
las ventajas del diseño orientado a objetos.
77
Session Beans
En Adredimo encontramos 3 Session Beans, encargados cada uno de una parte
importante del sistema. Estos implementan la mayoría del código orientado al
negocio, es decir, a la administración de redes, y adicionalmente las funciones
propias de un sistema distribuido, como manejo de usuarios, equipos, etc.
MonitorSession
Este Session Bean se encarga del monitoreo de dispositivos SNMP. Aparte de
esto maneja las funciones que permiten cambiar valores en la MIB de los
dispositivos. Se trata de un Statefull Session Bean, lo que indica que guarda el
estado de operación mientras un usuario lo este usando.
CapturasSession
Este Session Bean se encarga de recibir los traps enviados por los dispositivos, y
enviarlos a la base de datos para que sean posteriormente consultados por el
administrador. Implementa una interfaz SNMP que esta escuchando
permanentemente por el puerto de captura de traps, y genera una notificación
cuando recibe un trap. Es un staless Session Bean, dado que no necesita guardar
un estado conversacional con los clientes. Tiene además la función de permitir
consultar los traps a los Servlets que los muestran a los clientes.
78
PrincipalSession
Este Session Bean se encarga de proveer los métodos básicos para el
funcionamiento del sistema: validación de usuarios, conexiones, consulta de
equipos, etc. Es un staless Session Bean que no mantiene conversación con los
clientes.
Entity Beans
En el sistema Adredimo se usan 3 Entity Beans para acceder a la base de datos
MySql. Se trata de BMP Entity Beans, donde BMP significa que la persistencia es
controlada por el mismo Bean, no por el contenedor.
InventarioEntity
Este Entity Bean se encarga de administrar la tabla de dispositivos de Adredimo.
Provee además métodos para consultar la lista de equipos para facilitar la
búsqueda de los mismos por los clientes.
CapturasEntity
Este Entity Bean administra la tabla de Capturas, donde se almacenan los traps.
Permite a los clientes consultar la información de las capturas de todos los
dispositivos administrados.
79
UsuarioEntity
Este Entity Bean se encarga de administrar los usuarios, para validar el ingreso al
sistema.
Figura 6. Esquema de EJBs de Adredimo.
5.8.5 Base de Datos El sistema Adredimo usa un motor de base de datos MySql, para almacenar
información como los usuarios, traps, y dispositivos conectados al sistema. Este
no es vital para el funcionamiento de Adredimo, dado que la orientación del
80
sistema es que no dependa de muchas cosas para funcionar, y disminuya la carga
de administración en lugar de aumentarla. La base de datos esta almacenada en
un equipo que actúa como servidor de base de datos, y puede ser también a la
vez servidor de aplicaciones, ejecutando JBoss. En caso de que la base de datos
no este disponible, el usuario ingresa con un usuario especial habilitado para este
fin, para que pueda monitorear el estado del sistema aun en esta eventualidad. El
único servicio importante que pierde al no tener conexión a la base de datos es la
consulta de traps. La base de datos esta conformada por las siguientes tablas:
Inventario: Almacena la información de los dispositivos, con los campos: id
(interno), nombre, dirección (IP), y comunidad (palabra clave de acceso de
SNMP). Esta se usa para permitir al cliente monitorear un dispositivo
indicando su nombre asignado, en lugar de tener que memorizar
direcciones IP.
Captura: Esta tabla almacena la información de los traps generados por los
dispositivos conectados al sistema. Se guardan los campos: id (interno),
origen (dirección IP del dispositivo generador del trap), tipo (código SNMP
del tipo de trap), descripción (información adicional enviada en el trap),
fecha, y hora (de cuando se recibió el trap).
Usuario: Almacena la información de los usuarios del sistema. Se manejan
los campos: usuario (nombre de usuario o login), y clave (cadena
alfanumerica secreta de cada usuario).
5.9 PRUEBAS
En esta parte del capitulo, se mencionan las pruebas que se realizaron al sistema,
y se explica cual es el objetivo de cada una de ellas, y en que consistieron, así
mismo como los resultados obtenidos. Para evaluar la implementación realizada,
81
se realizaron 4 pruebas distintas con las que se evaluaron diferentes aspectos
fundamentales: Transparencia, Disponibilidad, Confiabilidad y pruebas de SNMP.
Para estas pruebas se construyo el siguiente escenario: se creo una red WAN, en
el laboratorio de redes, con dos Routers (Cisco 2500 y Cisco 3600), y dos redes
LAN al lado de cada Router. En cada LAN se ubicaron 2 equipos como servidores
de aplicación Adredimo. Un equipo actuaba como servidor de base de datos,
ubicado en una de las LAN. Los 4 servidores funcionaron además como servidor
Web. El mismo equipo que actuó como servidor de base de datos funciono como
Distribuidor de Cargas. A continuación se encuentra el diagrama de red.
Figura 7. Diagrama de Red de Ambiente de Pruebas
Dentro de esta red WAN, creada en el laboratorio de redes de la Pontificia
Universidad Javeriana se utilizaron tres servidores de aplicación, uno de los cuales
cumplía con las condiciones mínimas exigidas por Jboss (servidor de aplicaciones
82
elegido), de 128 en memoria RAM, el equipo que cumplía con estas condiciones
fue el 40.0.0.2, los otros dos servidores de aplicación, fueron montados sobre
computadores con mejores condiciones para poder correr en ellos varias
funciones al tiempo (servidor de aplicaciones y servidor de base de datos, servidor
de aplicaciones y servidor de distribución de cargas). Para toda la red se utilizó la
máscara de red 255.0.0.0
5.9.1 Pruebas de Transparencia de Acceso
Con estas pruebas, se pretendió evaluar, la transparencia de acceso a la
aplicación, mediante cada una de sus opciones de entrada. Para ello se utilizaron
diferentes medios como: Pocket PC, Emuladores de dispositivos móviles y
estaciones de trabajo fijas (PC).
Para las pruebas con estaciones de trabajo estáticas (Cliente Web), se accedió al
servidor de distribución de cargas desde el cliente Web que muestra el diagrama
de red; el cual atendió una serie de peticiones que se realizaron, para que este
distribuyera las cargas dentro de la red de servidores de aplicación.
Para las pruebas con Emuladores de Dispositivos Móviles (CCWap), se realizó la
misma prueba que con las estaciones de trabajo, pero se accedió utilizando el
emulador de dispositivos móviles CCWAP, el cual tiene la facultad de poder
emular teléfonos, PDA, y NoteBooks. Este emulador utiliza a su vez un protocolo
WAP.
Finalmente se realizó una tercera prueba de acceso con un Pocket Pc y una
conexión bluetooth, adicionándole a dos de los servidores de aplicación las llaves
de conexión bluetooth, mediante sus puertos USB. De igual forma, se accedió al
servidor de distribución de cargas mediante acceso inalámbrico desde el Pocket
PC,
83
Como resultados de estas pruebas, en los dos primeros casos nunca se presentó
ningún inconveniente, y el acceso fue normal y como se esperaba. Pero para el
tercer caso, al principio se presentó un inconveniente luego del acceso a la
aplicación, ya que el servidor de distribución de cargas, funcionaba correctamente,
pero cuando se ingresaba a la aplicación, el servidor que atendía la petición se
caía. Este inconveniente pudo ser resuelto y el acceso desde dispositivos móviles
luego de otras pruebas funcionó correctamente.
5.9.2 Pruebas de Disponibilidad Para esta prueba, se utilizaron los cuatro equipos conectados a la red, incluso los
servidores de aplicación como clientes, ya que se necesitaban conectar varios
clientes concurrentes al servidor Distribuidor de Cargas, el cual fue
redireccionando las peticiones de forma secuencial a cada uno de los servidores
habilitados en el sistema. De forma que de 4 clientes, cada uno quedo conectado
a un servidor diferente. Luego se bajo uno de los servidores, y se pudo comprobar
que el Distribuidor de Cargas direcciona a este, pero si no se puede conectar, y se
actualiza la pagina, direcciona al siguiente disponible.
5.9.3 Pruebas de Confiabilidad La prueba consistió en bajar cualquiera de los 3 servidores normales y ver si aun
se podía monitorear el resto de equipos de la red, lo cual sucedió sin problemas.
Para ubicarnos dentro de la red, de los tres servidores de aplicación que se
encontraban disponibles en la red, se bajó el correspondiente a la IP 50.0.0.4 y se
verificó que tan correcta era la información que presentaban los otros servidores,
los cuales pasaron sin ningún inconveniente la prueba, ya que la información
presentada fue coherente con lo que se tenía incluso antes de bajar el servidor en
mención. Luego se procedió a bajar el servidor de Distribución de Cargas, para ver
si aun se podía acceder directamente a los otros servidores. No hubo
inconvenientes. Luego se bajo el servidor de base de datos, y se probo que el
84
sistema puede funcionar sin base de datos, validando un usuario administrador
único, de forma que la perdida de la base de datos solo afecta la posibilidad de
consultar los Traps generados desde que se cae la base de datos. Una vez sube
de nuevo la base de datos, el sistema reenvía los traps que quedaron
almacenados en cola en memoria, para que la información quede completamente
actualizada. Aun con la base de datos caída, se pudo monitorear los Router
indicando a mano sus direcciones IP, sin problemas.
En esta prueba si hubo un inconveniente, cuando se trato de bajar un servidor en
medio de una sesión de atención a un cliente. Si el servidor se bajaba cuando se
tenia un Session Bean ya corriendo, y luego se trataba de que otro servidor lo
siguiera atendiendo, no se podía sincronizar correctamente dicha sesión. Esto es
un problema inherente a el manejo de Session Bean de JBoss. Para sincronizar
dicha sesión se requeriría de bastante código y tiempo, y es un tema que escapa
al alcance de nuestro proyecto. Este problema solo se presenta cuando se cae un
servidor, en medio del momento de atención a un cliente, cosa que es poco
probable en el funcionamiento de Adredimo, dado que se basa mas que todo en
consultas de corta duración de aspectos puntuales. Por ejemplo, si el servidor se
cae en medio del monitoreo de un dispositivo, la única consecuencia de la falta de
sincronización es que el cliente debería volver a indicar el dispositivo a modificar y
la comunidad, que son dos datos fáciles de recordar e introducir de nuevo.
5.9.4 Pruebas de SNMP Para esta prueba se monitoreo desde distintos servidores a los dos routers
presentes en el sistema, sin problemas. Además se monitoreo a uno de los
servidores Windows 2000 de la aplicación (IP 50.0.0.5). Se probó además la
recepción de traps, accediendo a la consola de los router, y bajando y subiendo
interfaces de los mismos (Cisco 3600 y Cisco 2500), los cuales generaron traps
que fueron capturados por el sistema, enviados a la base de datos, y consultados
85
desde un equipo PC cliente, a través del browser. Además se modificaron valores
numéricos, y de texto de la MIB, para probar la posibilidad de realizar cambios en
la misma. Los cambios se reflejaron en las consultas posteriores. Todo esto
transcurrió sin inconvenientes.
5.10 TRABAJOS FUTUROS
Como hemos podido observar, este es un proyecto, hizo referencia a una gran
cantidad de temas que han venido tomando mucha fuerza en los últimos años, en
la rama de los desarrollos de software, entre ellos tenemos la vinculación de
dispositivos móviles, la utilización de ambientes distribuidos, la división funcional
de un sistema mediante diferentes arquitecturas de software, en este caso una
arquitectura multinivel, entre otros. Pero aún así, este proyecto puede tomar
mucha más fuerza comercial si a medida que se van mejorando aspectos de
máquina, y van saliendo máquinas más poderosas al mercado a menor costo, se
podría pensar en la adopción de otras ideas para vincular a este proyecto como lo
son:
• Migración de SNMPv1 a SNMPv2 o SNMPv3
Este trabajo o actualización no debería llevar mucho tiempo, ya que la base del
protocolo SNMP no difiere de sus versiones, sino que cada una de ellas le
adicionan nievas características y mejoras al protocolo. Pero para realizar esta
actualización, sería conveniente el evaluar que tan apropiado es el momento
de hacerla, y si en ese momento los dispositivos de red tienen soporte de la
versión de SNMP a la que se vaya a actualizar. Por lo que se considera que
este trabajo depende de la velocidad con que las empresas adquieran nuevos
dispositivos de red que tengan un soporte de SNMP más reciente que el
SNMPv1.
• Utilización de otro Servidor de Aplicaciones
86
Al igual que la mejora descrita en el punto anterior, esta mejora queda abierta a
la posibilidad de una empresa de adquirir equipos de una mayor capacidad de
procesamiento, ya que Adredimo se puede beneficiar de ciertas características
de configuración inherentes a algunos contenedores como el de WebLogic, en
el cual se trae un amplio soporte de SNMP, pero necesita unos requerimientos
de máquina muy altos como lo es un procesador de no menos de 1.8 MHz y
memoria RAM de no menos de 1Gb.
• Utilización de una sola puerta de entrada al Sistema
En la actualidad Adredimo cuenta con 2 puertas de entrada, dependiendo del
tipo de cliente que se encuentre atendiendo. Es decir, si el cliente es un cliente
con un browser que soporta HTTP, entra al sistema apuntando a un servidor
de distribución de cargas distinto, al servidor de distribución de cargas que
apunta un cliente móvil con un browser que soporta WAP. La razón de esto, es
que para las pruebas diseñadas al sistema, no se contó con un dispositivo
físico que solo tuviera soporte WAP, ya que los dispositivos móviles utilizados
en las pruebas siempre tuvieron soporte HTTP, por eso para las pruebas
realizadas al respecto se utilizaron emuladores instalados en PC de escritorio,
lo cual no permitía identificar de manera confiable si era un cliente que tuviera
soporte HTTP o WAP.
• Utilización de un portal externo para ingresar a la aplicación
Otro posible trabajo futuro para Adredimo, es la creación de un portal Web, el
cual pueda ser accedido por medio de Internet, para así poder ampliar la
cobertura del sistema, y que incluso el administrador de red pueda tomar
decisiones sobre la red de la empresa desde su casa. Esta mejora haría
mucho más comercial el producto, pero se debe tener en cuenta que
mecanismos de seguridad debería adicionarse, para que la red de la empresa
no quede invulnerable ante ataques externos provenientes de Internet.
87
6. CONCLUSIONES Y RECOMENDACIONES
En el transcurso del proyecto se encontraron varios aspectos importantes a
mencionar, y que resultan de la experiencia del equipo de desarrollo en su trabajo.
Un sistema administrador de redes debe estar orientado a permitir un
mayor control del cliente sobre su red, proporcionándole herramientas que
faciliten las labores diarias del administrador, sin crearle cargas más
grandes de las que se pretende liberar.
El sistema debe ser robusto y distribuido, pero a la vez depender de la
menor cantidad de sistemas externos que sea posible. Dado que es un
sistema critico para la operación de cualquier empresa, debe estar siempre
disponible y no caerse por efecto de problemas en los sistemas adicionales.
Como vimos en las pruebas, el diseño de Adredimo garantiza bastante
disponibilidad, y una alta confiabilidad, con algunos puntos débiles que
podrían mejorarse para incrementar dichas características, como es el caso
del problema de sincronización de los Session Beans Statefull.
SNMP es una tecnología con bastantes años en el mercado, tiene un mas
amplio soporte en el ramo de administración de dispositivos, y fue
estructurado para ser sencillo, ordenado, y eficiente. Sus falencias de
seguridad pueden ser muy peligrosas si cae en manos de un administrador
inexperto, que no configure las cosas adecuadamente.
Las posibilidades nuevas que surgieron con el desarrollo de los dispositivos
móviles no han sido plenamente exploradas e implementadas, lo que ofrece
un gran mercado para las nuevas soluciones basadas en las ventajas
88
inherentes de estas tecnologías, la movilidad, disponibilidad y portabilidad.
En el caso de la administración de redes, es muy poco lo que se tiene en el
mercado local, y es aun más poco lo que ofrece nuevas tecnologías como
parte de su implementación. Si pensamos en una aplicación de
administración de redes que se puede usar desde un Smart Phone,
hablamos de brindar la posibilidad a un administrador de detectar y arreglar
problemas desde cualquier lugar cubierto por una red de transmisión de
datos celular, usando GPRS, lo cual le da una movilidad enorme. Este es
el caso de Adredimo, y es una de sus características más fuertes e
innovadoras. En las pruebas se utilizo Bluetooth, que es de un alcance
mas limitado, pero permite vislumbrar la capacidad inalámbrica de la
aplicación.
El WML, junto con WAP, ofrecen una herramienta versátil para el acceso a
la información desde cualquier dispositivo compatible, sin importar su
naturaleza. Representa para el mundo móvil lo que representa HTML para
los PC, la posibilidad de crear programas y aplicaciones muy livianas, que
pueden ser accedidas desde distintas maquinas, sin importar sistema
operativo, marca, hardware, etc. Cuando se usan en conjunto permiten
ofrecer una solución como Adredimo, que puede ser usado desde múltiples
plataformas computacionales, tradicionales equipos de escritorio, o
teléfonos celulares convencionales.
J2EE nos brinda una plataforma bastante robusta para desarrollar
aplicaciones distribuidas. Los Java Beans encapsulan gran parte de las
complicaciones de controlar las comunicaciones e interfaces entre objetos
en una aplicación grande. Permiten un diseño mas ordenado, y más
expandible, dado que si se requiere funcionalidad adicional simplemente se
agregan Java Beans que provean esos servicios. Por ejemplo los Entity
Beans facilitan enormemente el trabajo de acceder a una base de datos,
89
ocultando los detalles de bajo nivel de la conexión, lo que permite que se
pueda migrar de base de datos sin tantos traumatismos.
90
BIBLIOGRAFÍA
[SM2000] Subramanian Mani. “Network management: principles and practice”.
Addison - Wesley. Massachusetts. 2000
[GC2001] George Colouris. Sistemas Distribuidos, Conceptos y
Diseño”.Addison Wesley. Madrid, España. 2001
[MN1996] Muller Nathan J. Network planning, procurement, and
management”.McGraw – Hill. New York. 1996.
[PK2002] Pahlavan Kaveh, Krishnamurthy Prashant. “Principles of wireless
networks: a unified approach”. Prentince Hall. New Yersey. 2002
[AC2000] Arehart Charles. “Professional WAP”. Birminghan. Chicago, Illionois.
2000
[HG2001] Held Gilbert. “Data over wireless networks: Bluetooth TM WAP, and
Wireless LANS”. Mc Graw-Hill. New York, San Francisco. 2001
[NB2001] Nikita Borisov, Ian Goldberg, and David Wagner. “Security of the
WEP algorithm“. 2001. http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
[WI2004] Wi-Fi Organization. “Wi-Fi Alliance. Wi-Fi Security at work on the
road”. 2004. www.Wi-Fi.org
[RU2002] Rice University. “Using the Fluhrer, Martin and Shamir attack to
break WEP”. 2002. www.cs.rice.edu
[MV2001] Mauricio Vargas. “Tendencias Empresariales”. Revista Cambio.
Bogotá Colombia. 2001.
91
[AA2004] Aguilar & Asociados. “Monitoreo de Redes WAN – Link Analyst”.
www.aguilaryasociados.com
[WI2004-1] Wi-Fi organization. “Software Servidor Hot Spot”. www.wi-fi.com
[SS2003] Sprocom Software. “RentaPC Ver5”. www.spocrom.com
[FL2003] Fernando Lacuza, Eduardo Magaña y Alfonso Matrínez. “SNMP”.
www.arrakis.es
[JH2004] Juan Manuel Huidobro. “SNMP. Un Protocolo Simple de Gestión”.
www.coit.es
[FI2004] Facultad Ingeniería, Universidad de la República de Uruguay. “SNMP
Simple Network Management Protocol. Gestión de Redes”. www.fing.edu.uy
[JR2004] José Carrasco, Juan Espino y Carlos Ruiz “Gestión de Red:
Protocolo SNMP”. http://ceres.ugr.es
[SM2005] Sun Microsystems. “Rutas de Aprendizaje J2EE”. www.sun.com
[MI2005] Microsoft. “Introducción a la tecnología .NET”. www.micrsoft.com
[MI2005-1] Microsoft. “Componentes Servidos en .NET”. www.microsoft.com
[SM2005-1] Sun Microsystem. “Sun Java System Application Server”.
www.sun.com
92
ANEXOS
6.1 ANEXO A: Descripción detallada de las variables básicas de la MIB SNMPv1
SysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0...255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity. This value should include
the full name and version identification of the system's
hardware type, software operating-system, and networking
software. It is mandatory that this only contain printable ASCII
characters."
::= {system 1}
SysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the network
management subsystem contained in the entity. This value is
allocated within the SMI enterprises subtree (1.3.6.1.4.1) and
provides an easy and unambiguous means for determining
93
`what kind of box' is being managed. For example, if vendor
`Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it
could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
Router'."
::= {system 2}
SysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time (in hundredths of a second) since the network
management portion of the system was last re-initialized."
::= {system 3}
SysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0...255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person for this
managed node, together with information on how to contact
this person."
::= {system 4}
SysName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0...255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
94
"An administratively-assigned name for this managed node.
By convention, this is the node's fully-qualified domain name."
::= {system 5}
SysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0...255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The physical location of this node (e.g., telephone closet, 3rd
floor')."
::= { system 6 }
IfNumber OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of network interfaces (regardless of their current
state) present on this system."
::= {interfaces 1}
IfSpeed OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An estimate of the interface's current bandwidth in bits per
second. For interfaces which do not vary in bandwidth or for
95
those where no accurate estimation can be made, this object
should contain the nominal bandwidth."
::= {ifEntry 5}
IfPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The interface's address at the protocol layer immediately
`below' the network layer in the protocol stack. For interfaces
which do not have such an address (e.g., a serial line), this
object should contain an octet string of zero length."
::= {ifEntry 6}
IfAdminStatus OBJECT-TYPE
SYNTAX INTEGER
{
Up (1), -- ready to pass packets
Down (2),
Testing (3) -- in some test mode
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The desired state of the interface. The testing (3) state
indicates that no operational packets can be passed."
::= {ifEntry 7}
96
IfOperStatus OBJECT-TYPE
SYNTAX INTEGER
{
Up (1), -- ready to pass packets
Down (2),
Testing (3), -- in some test mode
Unknown (4),
Dormant (5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The current operational state of the interface. The testing (3)
state indicates that no operational packets can be passed."
::= {ifEntry 8}
AtNetAddress OBJECT-TYPE
SYNTAX NetworkAddress
ACCESS read-write
STATUS deprecated
DESCRIPTION
"The NetworkAddress (e.g., the IP address) corresponding to
the media-dependent `physical' address."
::= {atEntry 3}
97
6.2 Manuales
6.2.1 Story Board Introducción
El equipo que conforma la investigación de Adredimo, presenta en este manual, la
secuencia que Adredimo adopta para poder ofrecer sus servicios al usuario final.
El objetivo final de este manual, es que al finalizar la lectura y puesta en práctica
del mismo, el usuario del sistema Adredimo, tenga un total conocimiento de las
opciones que se le pueden presentar en un momento dado dependiendo del punto
en el que se encuentre dentro del sistema, o los pasos que debe seguir para poder
dirigirse a otro módulo funcional del sistema de administración de red.
Alcance
En este manual debe quedar explicado de manera clara y concisa, los pasos o el
camino necesarios a seguir por un usuario para poder dirigirse de un módulo
funcional a otro dentro del Adredimo.
Descripción
Adredimo cuenta con una sencilla estructura de navegabilidad, basada en dos
tipos de acceso (Web y Wap), y en cada uno de estos, podemos encontrar una
sencilla y siempre dispuesta posibilidad de acceder de un módulo funcional distinto
al que nos encontremos.
98
A continuación encontraremos los dos tipos de Story Board Desarrollados para
cada tipo de Acceso, ya que deben ser diferentes el Web del Wap, por la
diferencia en la capacidad de procesamiento de los dispositivos móviles sin
soporte HTTP, para los cuales, se habilitó WML.
Como se especifica en el “Manual de Usuario”, Adredimo tiene una subdivisión en
módulos funcionales; por lo que se debe especificar claramente el Story Board por
cada uno de ellos.
Story Board Web
Ingreso
El ingreso a Adredimo, es la operación que nos lleva a poder acceder a los
demás módulos funcionales del administrador de red, por medio de una
solicitud de identificación de usuario, en la página principal de Adredimo.
Cuando se accede al sistema, se encuentra una página, en la cual se
deben disponer componentes que permitan el ingreso de dos valores
únicamente conocidos por los usuarios permitidos en el sistema; el
“usuario” y la “clave”.
99
Si se selecciona la opción de “Borrar”, se deben limpiar los datos que se
hayan ingresado en los campos de texto, pero si por el contrario se
selecciona la opción de “Ingresar”, y el ingreso es fallido, se debe mostrar la
información correspondiente, y solicitar al usuario el intento de ingresar de
nuevo. Pero si el ingreso es exitoso, se debe mostrar una página que tenga
el menú principal de opciones de Adredimo, junto a un mensaje de
bienvenida.
Monitoreo
En el monitoreo, se deben tener varias consideraciones con el usuario del
sistema, como la dificultad de recordar todas las direcciones IP de los
dispositivos de red instalados, o los nombres que a estos se le han
asignado, para que el usuario final digite estos dos datos junto con el
community de seguridad y poder comenzar a realizar el monitoreo. Por esta
razón, se debe realizar la selección del dispositivo a monitorear y el
monitoreo de la siguiente forma:
Se elige de una lista desplegable, el dispositivo que el usuario desea.
100
Si se elige la opción de “Cancelar”, el sistema deberá retornar al usuario a
la página de bienvenida. Pero si se elige la opción de “Aceptar”, el sistema
deberá retornar, otra página donde presente al usuario información como el
nombre del dispositivo, y la IP correspondiente al mismo; solicitándole
además que el ingrese el community de seguridad para poder monitorear el
dispositivo.
Si se elige la opción de “Cancelar”, el sistema deberá retornar al usuario a
la página de bienvenida. Pero si selecciona la opción de “Aceptar”, se
desplegará una tercera y última página, en la cual se muestra la información
del dispositivo seleccionado, y los valores de la MIB Básica en el instante
del monitoreo.
101
Si se elige la opción de “Continuar”, el sistema deberá retornar al usuario a
la página de bienvenida. Pero si selecciona la opción de “Actualizar”, el
sistema deberá actualizar los valores de la MIB Básica presentados en esta
pantalla.
Traps
En la opción de Traps, debemos considerar que se realiza una búsqueda de
los últimos Traps capturados por el sistema, y se presenta al usuario de
manera descendiente (el más reciente primero), y que adicionalmente se
debe presentar la opción de descarga de la aplicación local.
102
Si el usuario selecciona la opción de “Descargar aplicación Local”, se debe
iniciar una descarga de la carpeta que contenga los archivos necesarios
para poder realizar la captura de Traps en tiempo real. Pero si selecciona la
opción de “Continuar”, el sistema deberá retornar al usuario a la página de
bienvenida.
Dispositivos
Para la opción de dispositivos, se deben ingresar los datos del dispositivo
adicionado a la red, para lo cual si es necesario que se ingresen los 3 datos
básicos para poder mantener un control sobre el nuevo dispositivo. Por eso
se debe presentar una pantalla que permita la captura de estos datos.
103
Si el usuario selecciona la opción de “ingresar”, el sistema verifica que el
dispositivo no se haya ingresado antes, o la IP este ya asignada, y si el
ingreso es exitoso, debe mostrar una pantalla con la información de
ingreso, o por el contrario con la información de rechazo. Pero si el usuario
selecciona la opción de “Cancelar”, el sistema deberá retornar al usuario a
la página de bienvenida.
Salida:
Esta opción simplemente debe llevar al usuario a la primera página, donde
se solicitan los datos de ingreso del usuario.
Anexos
No existe ningún anexo disponible. Definiciones, Acrónimos y Abreviaciones
Módulo Funcional
Un módulo funcional hace referencia a las opciones que el sistema de
administración de red le ofrece al usuario final, y por cada una de esas
opciones se define un módulo individual y que tiene como objetivo el
cumplir una tarea específica.
Navegación / Navegabilidad
Es el proceso compuesto por una o varias pantallas diferentes, presentadas
al usuario final, que llevan a una finalidad específica dentro del sistema de
administración de red.
104
6.2.2 Manual de Usuario Introducción
El equipo que conforma la investigación de Adredimo, presenta en este manual,
los estándares adoptados durante el desarrollo del proyecto, en cuanto a su
presentación final al usuario. De igual manera, usted podrá encontrar dentro de
este manual el reflejo de la transparencia en interactividad entre el usuario y el
sistema, independiente de la plataforma o el browser que los usuarios utilicen.
El objetivo final de este manual, es que al finalizar la lectura y puesta en práctica
del mismo, el usuario del sistema Adredimo, este en la capacidad y tenga el
completo conocimiento de cómo funciona y como debe manejar Adredimo para
poder obtener de él, el mayor provecho posible.
Alcance
En este manual debe quedar explicado de manera clara y concisa, como el
usuario debe interactuar con el sistema Adredimo, para poder acceder a cada una
de sus opciones y funcionalidades. Al mismo tiempo que debe proveer todas las
ayudas visuales necesarias para el entendimiento de los conceptos explicados en
este documento.
Descripción
En este documento usted podrá encontrar diferentes y diversos temas
relacionados con Adredimo; pero para su mayor comodidad, en esta sección se
describe cada uno de esos temas de manera breve, ofreciéndole una mayor
facilidad para poder dirigirse al tema de su elección. Sin embargo es
105
recomendable que el manual sea leído en su totalidad y en el orden que aquí
sugerimos.
Los conceptos que se explican en este documento son los siguientes:
Módulos Funcionales
Los módulos funcionales hacen referencia a las alternativas de consulta que
tiene el usuario final en un momento dado, dependiendo de en que sitio de
la navegación se encuentre. En los módulos funcionales, usted podrá
encontrar todas las opciones que Adredimo le ofrece.
Anexos
En esta sección usted podrá encontrar las explicaciones adicionales que
requiera, y a las cuales se haga referencia dentro del manual.
Definiciones, acrónimos y Abreviaciones
En esta sección usted podrá encontrar la definición de algunas palabras
técnicas, acrónimos y abreviaciones que son utilizadas dentro de este
manual. Esta sección le ayudará a comprender de una mejor manera el
manual.
Módulos Funcionales
Las opciones presentadas por Adredimo son varias, y en algunos casos
diferentes, todo depende del tipo de acceso que se tenga al sistema; ya sea Web
o Wap. Por esta razón deben ser explicados de manera separada.
106
Por otra parte, el acceso Web permite una estructura diferente de presentación; ya
que la capacidad de procesamiento de los equipos que accedan al sistema es
mayor a la de los dispositivos móviles que no poseen browser alguno.
Ingreso
El primer módulo que el usuario de Adredimo debe conocer es el de
“Ingreso”; ya que es obligatorio para cualquier tipo de usuario acceder al
sistema.
Este es el primer nivel de seguridad de Adredimo, ya que aquí, se debe
digitar un nombre de usuario y una clave que corresponda al usuario
ingresado. Estos datos son verificados por el sistema en la base de datos
de usuarios permitidos, y retorna un mensaje de éxito o una solicitud de
nuevo ingreso de datos si los datos ingresados no son los correctos,
impidiéndole a personas no autorizadas utilizar el sistema.
1. Se ingresa al sitio Web de Adredimo
107
2. Se ingresan los Datos de ingreso en los campos correspondientes
3. El usuario debe esperar la respuesta que el sistema le de, y
dependiendo de esta podrá o no seguir adelante. (En este punto
108
mostraremos las dos pantallas que retorna el sistema, pero para los
pasos siguientes se asumirá que el ingreso fue exitoso)
En caso que el ingreso sea exitoso:
4. El usuario debe seleccionar la opción de “Desplegar menú de
opciones”, y la siguiente será la pantalla que verá.
109
5. El usuario ha ingresado satisfactoriamente, y puede empezar a
utilizar los otros módulos funcionales.
Monitoreo
El segundo módulo que el usuario de Adredimo debe conocer es el de
“Monitoreo”; y por medio de este módulo podrá conocer el estado de un
dispositivo móvil en especial en un momento dado.
Aquí se implementa otro nivel de seguridad, ya que luego de realizarse la
escogencia del dispositivo, se debe digitar la clave del community asignado
al dispositivo que del que se quiere conocer el estado actual. El sistema
verifica que esta clave corresponda con la que le ha sido asignada al
dispositivo a la hora de instalarlo en la red, y retorna los valores de la MIB
básica, o retorna una página de error en caso de que el community
ingresado no sea el correcto.
110
Traps
El tercer módulo que el usuario de Adredimo debe conocer es el de “Traps”;
y por medio de este módulo podrá conocer los últimos mensajes
emergentes, provenientes de los dispositivos de red, que han sido
capturados últimamente.
Dispositivos
El cuarto módulo que el usuario de Adredimo debe conocer es el de
“Dispositivos”; el cual se encuentra enfocado especialmente al ingreso a la
base de datos de Adredimo de nuevos dispositivos instalados en la red,
para poder mantener el control también sobre estos.
Aplicación de Escucha de Traps para acceso Web
El quinto y último módulo que el usuario de Adredimo debe conocer es el
que hace referencia a la aplicación que se puede descargar en clientes que
accedan al sistema de manera Web; por lo que este módulo es el único que
no se encuentra disponible para el acceso Wap, marcando la más grande
diferencia entre los dos tipos de acceso a Adredimo.
Anexos
No existe ningún anexo disponible.
111
Definiciones, Acrónimos y Abreviaciones
Adredimo:
Administrador de Red Distribuido Orientado a Dispositivos Móviles (nombre
del proyecto).
Aplicación
Sistema independiente que tiene como objetivo realizar tareas específicas
para la colaboración con el cumplimiento de un objetivo común. Las
aplicaciones son locales cuando estas se encuentran ejecutándose en el
computador que las accede, o remotas en caso contrario.
Community:
Clave asignada a los dispositivos al momento de ser instalados en la red,
para por medio de ella poder verificar si las solicitudes de información a los
dispositivos provienen de una persona autorizada o no.
Dispositivos
Son el hardware que compone la red, y que permite que esta preste el
servicio indicado a los usuarios finales. Cuando se utiliza este término en
este documento se hace referencia a todo el hardware inteligente y con
soporte SNMP que hace parte de la red administrada.
Navegación / Navegabilidad
Es el proceso compuesto por una o varias pantallas diferentes, presentadas
al usuario final, que llevan a una finalidad específica dentro del sistema de
administración de red.
112
Transparencia:
Este término es utilizado dentro de este manual cuando se hace referencia
al no conocimiento del usuario final, de cómo el sistema se encuentra
trabajando en los servidores que lo componen, ya que cuando este accede
desde un equipo con conexión a la red, siempre lo observará y utilizará de
la misma forma como lo ha hecho anteriormente.
Traps:
Mensajes provenientes de los dispositivos de la red que se están
administrando. Estos son enviados por los dispositivos en el momento que
algún hecho extraordinario ocurra con ellos.
Wap
Cuando se hace referencia a este término, se busca enfatizar en una de las
opciones de acceso remoto que tiene el sistema Adredimo, que en este
caso especial es el acceso desde un dispositivo móvil sin soporte de
browser. Lo que lo limitará a mantener una navegabilidad plana
Web
Cuando se hace referencia a este término, se busca enfatizar en una de las
opciones de acceso remoto que tiene el sistema Adredimo, que en este
caso especial es el acceso desde una máquina con soporte de browser.
113
ADREDIMO “ADMINISTRADOR DISTRIBUIDO DE REDES ORIENTADO
A DISPOSITIVOS MÓVILES”
JOHN JAIRO MENDIVELSO SANCHEZ IVAN GERARDO NEVA VARGAS
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS BOGOTA D.C.
2005
114
ADREDIMO “ADMINISTRADOR DISTRIBUIDO DE REDES ORIENTADO
A DISPOSITIVOS MÓVILES”
JOHN JAIRO MENDIVELSO SANCHEZ IVAN GERARDO NEVA VARGAS
Trabajo de Grado Para Optar al Título de Ingeniero de Sistemas
Director Ing. Juan Pablo Garzón Ruiz
Ingeniero de Sistemas
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA DE SISTEMAS BOGOTA D.C.
2005
115
INTRODUCCIÓN................................................................................................................................. 1
JUSTIFICACIÓN................................................................................................................................. 4
METODOLOGIA ................................................................................................................................. 7
OBJETIVOS...................................................................................................................................... 10
1. REDES Y ADMINISTRADORES DE RED............................................................................... 11
1.1 REDES INALÁMBRICAS........................................................................................................... 11 1.1.1 Características ......................................................................................................................... 12 1.1.2 Tecnologías de Acceso Inalámbrico ......................................................................................... 13
1.2 DISPOSITIVOS MOVILES ......................................................................................................... 16 1.2.1 Características ......................................................................................................................... 16 1.2.2 Dispositivos y Características Individuales.............................................................................. 17
1.3 ADMINISTRADOR DE RED ...................................................................................................... 19 1.3.1 Características ......................................................................................................................... 19 1.3.2 Plataformas .............................................................................................................................. 20
1.4 SISTEMAS DISTRIBUIDOS....................................................................................................... 20 1.4.1 Características [GC2001] ........................................................................................................ 21
2. ADMINISTRADORES DE RED Y CARACTERÍSTICAS......................................................... 24
2.1 ADMINISTRADORES DE RED ........................................................................................................... 24 2.1.1 LINK ANALYST: [AA2004] ...................................................................................................... 24 2.1.2 RENTAPC VERSIÓN 5: [SS2003] ........................................................................................... 26 2.1.3 PC DUO LANUTIL32: [DA2004] ............................................................................................ 27 2.1.4 Snow Suite3.1: [DA2004] ......................................................................................................... 28 2.1.5 Veritas Desktop Management Suite 3.5: [DA2004] ................................................................. 29 2.1.6 Intel LANDesk Management Suite 6.3: [DA2004] ................................................................... 30 2.1.7 Novell ManageWise 2.6: [DA2004].......................................................................................... 32
2.2 APORTES Y CONCLUSIONES.................................................................................................. 34 3. SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL) .................................................. 36
3.1 INTRODUCCIÓN .............................................................................................................................. 37 3.2 HISTORIA ....................................................................................................................................... 39 3.3 MIB (MANAGEMENT INFORMATION BASE) ................................................................................... 40 3.4 VENTAJAS DE SNMP: .................................................................................................................... 43 3.5 DESVENTAJAS DE SNMP: .............................................................................................................. 44
4. ARQUITECTURA DE SOFTWARE ......................................................................................... 46
4.1 ARQUITECTURA MULTINIVEL........................................................................................................ 46 4.2 ARQUITECTURA DE APLICACIONES EMBEBIDAS EN DISPOSITIVOS MÓVILES ................................. 47 4.3 PLATAFORMAS PARA EL DESARROLLO MULTICAPAS ...................................................................... 47
4.3.1 Tecnología J2EE ...................................................................................................................... 47 4.3.2 Tecnología .NET....................................................................................................................... 49
4.4 CONTENEDORES DE JAVA BEANS: .................................................................................................. 53 4.4.1 Sun One Application Server Standard Edition [SM2005-1]..................................................... 53 4.4.2 JBoss......................................................................................................................................... 54 4.4.3 Oracle 9i Application Server .................................................................................................... 55 4.4.4 WebSphere................................................................................................................................ 56
116
5. ADREDIMO .............................................................................................................................. 58
5.1 ANÁLISIS DE LA SOLUCIÓN................................................................................................... 58 5.2 CARACTERÍSTICAS PRINCIPALES DE LA PROPUESTA .................................................... 59 5.3 BENEFICIOS DE ADREDIMO ................................................................................................... 60 5.4 REQUERIMIENTOS.................................................................................................................... 60
5.4.1 Requerimientos de administrador de red: ................................................................................ 61 5.4.2 Requerimientos de Cliente:....................................................................................................... 65
5.5 ARQUITECTURA DE SOFTWARE ........................................................................................... 65 5.6 DISEÑO DISTRIBUIDO DE ADMINISTRACION DE RED..................................................... 69 5.7 PROCESOS CRITICOS DE ADREDIMO................................................................................... 70 5.8 IMPLEMENTACION................................................................................................................... 71
5.8.1 Módulos de la Arquitectura de Software .................................................................................. 71 5.8.2 Páginas HTML y JSP ............................................................................................................... 73 5.8.3 Servlets ..................................................................................................................................... 73 5.8.4 Enterprise Java Beans .............................................................................................................. 77 5.8.5 Base de Datos ........................................................................................................................... 80
5.9 PRUEBAS..................................................................................................................................... 81 5.9.1 Pruebas de Transparencia de Acceso....................................................................................... 83 5.9.2 Pruebas de Disponibilidad ....................................................................................................... 84 5.9.3 Pruebas de Confiabilidad......................................................................................................... 84 5.9.4 Pruebas de SNMP..................................................................................................................... 85
5.10 TRABAJOS FUTUROS................................................................................................................ 86 6. CONCLUSIONES Y RECOMENDACIONES........................................................................... 88
BIBLIOGRAFÍA................................................................................................................................. 91
ANEXOS ........................................................................................................................................... 93
6.1 ANEXO A: DESCRIPCIÓN DETALLADA DE LAS VARIABLES BÁSICAS DE LA MIB SNMPV1 ......... 93 6.2 MANUALES .................................................................................................................................... 98
6.2.1 Story Board............................................................................................................................... 98 6.2.2 Manual de Usuario................................................................................................................. 105
117
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
Rector Magnífico
Padre Gerardo Remolina Vargas S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería
Padre Antonio José Sarmiento Nova S.J.
Director Carrera de Ingeniería de Sistemas
Ingeniera Hilda Cristina Chaparro López
Director Departamento de Ingeniería de Sistemas
Ingeniero Germán Alberto Chavarro Flórez
118
Nota de Aceptación:
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
Director del proyecto
________________________________________
JUAN PABLO GARZON
Jurado
________________________________________
MARIA ISABEL SERRANO
Jurado
________________________________________
RIGOBERTO BEJARANO
119
Bogotá D.C., Julio 11 de 2005
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado.
Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”
120
AGRADECIMIENTOS
“A nuestras familias, por el apoyo en tantos años de estudio; a nuestros amigos y
compañeros, por su ayuda y colaboración en todo momento; y a los profesores de
la carrera, por darnos los conocimientos necesarios para desarrollar un proyecto
de esta magnitud. Nuestros triunfos son reflejo de sus virtudes.”
Los autores
121
“Lo poco que he aprendido carece de valor, comparado con lo que ignoro y no
desespero en aprender”
René Descartes
122
