Curso Java Varios

UNIVERSIDAD FRANCISCO GAVIDIA
Tecnología, Humanismo y Calidad

DIRECCION DE POSTGRADOS Y EDUCACION CONTINUA
Trabajo de graduación:
“Sistema WDS para la Administración remota de

servidores”
TRABAJO DE GRADUACION
PREPARADO PARA LA
UNIDAD DE POSTGRADOS
PARA OPTAR AL TITULO DE:
MAESTRO EN INFORMATICA APLICADA EN REDES
Presentan:
Leyla Dinora Rivera Rivera

Hugo Miguel Colato Rodríguez
Nelson Antonio Tesorero
OCTUBRE – 2007
SAN SALVADOR – EL SALVADOR – CENTROAMERICA

Maestría en Informática Aplicada en Redes
RESUMEN
El siguiente documento presenta la propuesta para la administración remota de los

servicios que presta uno o más servidores, por medio del sistema llamado “Sistema
Redundante para la Administración Remota de equipos Servidores – WDS (Sistema
de Perro Guardián por sus siglas en inglés).
Dicha propuesta surge, en el marco actual en el que la administración de servicios y
la solución de fallas de un equipo servidor generalmente se da “in situ”, es decir que
el administrador debe estar presente en el lugar donde se encuentra ubicado el
equipo servidor, para resolverlas. Esta manera de administrar dependiendo del tipo
de empresa y del tipo de servicios prestados a sus clientes, puede resultar no factible
e ineficiente.
Existen en el mercado algunas soluciones de monitoreo para algunos servicios que
prestan los equipos servidores, sin embargo, por lo general, son muy limitados y muy
poco configurables, en cuanto a ir extendiendo los servicios que pueden monitorear.
La mayor desventaja es que estos sistemas de monitoreo, en general no permiten la
solución al problema detectado.
WDS es un sistema capaz de monitorear y controlar los servicios que presta uno o
mas servidores por medio de mensajes de texto SMS vía teléfono celular, es
altamente configurable e interactivo. Por el tipo de tecnología utilizada es una
solución que ofrece economía, seguridad y movilidad.
Las partes que componen el presente trabajo son las siguientes: Marco teórico el
cual nos proporciona los conocimientos para entender como funciona el proyecto
WDS; un análisis de la situación actual de la administración de servidores; la
propuesta de solución, explica por medio de casos de uso, diagramas de secuencia y
otro tipo de gráficos la forma de resolver el problema y justifica la elección de la
tecnología utilizada; la metodología, va detallando la instalación y configuración de
todos y cada uno de los componentes del proyecto WDS, indicando los pasos a
seguir para su correcto funcionamiento. Finalmente las pruebas realizadas para
demostrar la funcionalidad de este proyecto.
Página 2 de 82
Índice
Introducción .................................................................................................................... 4
Objetivos .......................................................................................................................... 6
I. Marco conceptual ...................................................................................................... 7
1.1 SMS.................................................................................................................... 7
1.2 SMSC ................................................................................................................. 7
1.3 Proyecto Gammu ............................................................................................. 8
1.4 MySql ............................................................................................................... 16
1.5 Java .................................................................................................................. 18
1.6 Eclipse.............................................................................................................. 22
1.7 Lomboz ............................................................................................................ 28
1.8 Hibernate ......................................................................................................... 28
1.9 PERL ................................................................................................................ 30
II. Análisis del problema............................................................................................ 32
2.1 Situación actual .............................................................................................. 32
2.2 Planteamiento del problema......................................................................... 34
III. Propuesta de solución ......................................................................................... 38
3.1 Diagrama de contexto (Nivel 0) ................................................................... 38
3.2 Diagrama de nivel 1 ....................................................................................... 40
3.3 Diagrama de nivel 2 ....................................................................................... 41
3.4 Software a utilizar:.......................................................................................... 43
IV. Metodología ....................................................................................................... 45
4.1 Estructura de Carpetas y archivos del sistema WDS .............................. 45
4.2 Requisitos del sistema WDS ........................................................................ 48
4.3 Instalación y configuración del proyecto WDS y de GAMMU................. 48
4.4 Scripts del sistema WDS............................................................................... 50
4.5 Aplicación Java............................................................................................... 57
V. Prototipo y resultados alcanzados ................................................................... 67
VI. Conclusiones generales ...................................................................................... 71
Bibliografía..................................................................................................................... 72
Anexos ............................................................................................................................ 72
Página 3 de 82
Introducción
Existen en la actualidad una variedad de situaciones que se dan en la administración

de servidores, con el propósito de que estos se mantengan funcionando
adecuadamente. Por lo general, cuando se dan fallas en los servicios estos se
resuelven de manera presencial por el(los) administrador(es).
Los costos para mantener los servidores de una institución trabajando de una forma
adecuada, son elevados, sobre todo cuando se sirven una gran cantidad de
servicios, si son sistemas 7/24 o si se trabaja de forma distribuida.
Por lo anteriormente mencionado se necesita una solución que nos permita
administrar remotamente un servidor (o mas), de tal manera que se pueda tomar
control de el, desde cualquier lugar y a cualquier hora que se necesite monitorear y/o
solucionar fallas.
Existen opciones para tomar control de un servidor de manera remota pero implican
tener a acceso a los servidores vía Internet, lo cual es inseguro, ya que exponemos a
los servidores a que sean accedidos con fines no deseados y para evitar esto, se
tiene que hacer una fuerte inversión en infraestructura DMZ, o bien, acceder a este, a
través de una VPN. Todo esto vuelve muy complicado pensar en la administración de
los servidores de forma remota.
El propósito de este trabajo es mostrar la factibilidad técnica de administrar uno o
más servidores de manera remota haciendo uso de la tecnología inalámbrica por
medio de mensajes de texto SMS.
El proyecto WDS es una solución que se basa en el proyecto de código abierto
Gammu, el cual, es un proyecto que abarca aplicaciones, scripts y drivers para
administrar varias funciones de teléfonos celulares y que también posee un esquema
de base de datos, para el manejo de los mensajes SMS.
WDS posee las siguientes características:
• El administrador puede enviar comandos y recibir el resultado de dicha acción,
es decir, recibir una respuesta desde el servidor sobre el resultado de este
comando.
• El administrador puede ir agregando más servicios a controlar al proyecto
WDS.
Página 4 de 82
• Por el tipo de tecnología utilizada el administrador puede monitorear y

controlar al servidor desde cualquier lugar a cualquier hora.
• En términos de seguridad el proyecto ofrece mecanismos para recibir o no
mensajes de determinados teléfonos, ya que posee dentro de sus parámetros
configurables el listado de teléfonos admitidos, así como aquellos teléfonos
que deseamos deben ser excluidos para recibir mensajes SMS. Además la
estructura que debe poseer el mensaje a ser enviado por el administrador, es
tal que, WDS ejecutara aquellos mensajes que poseen dicha estructura y si
no, los ignora, manejándolo como un ‘error’.
• En términos de costos económicos, es una solución que ofrece grandes
ventajas, ya que no necesita conectividad a Internet, inversión en
infraestructura de comunicaciones y además ahorra los costos en recurso
humano.
WDS es un proyecto que brinda comunicación entre el administrador y el servidor, de

tal manera que este puede perfectamente iniciar, detener o reiniciar cualquier
servicio, independientemente del lugar en que este se encuentre, en cualquier hora y
en cualquier día del año.
La aplicación que se le da a WDS para este caso fue, la administración remota de
servidores, pero puede ser adaptado para el control remoto de otros procesos.
Página 5 de 82
Objetivos
• Desarrollar un sistema capaz de lograr interacción en dos vías entre el

administrador físico y un equipo servidor, por medio de un teléfono celular.
• Aprovechar las ventajas que brindan las comunicaciones inalámbricas
como son la movilidad, para lograr la administración remota de uno o mas
equipos servidores, independiente de que el administrador tenga acceso a
una PC.
• Desarrollar un sistema capaz de monitorear y controlar los servicios que
presta uno o más servidores, a través de mensajes de texto SMS, por
medio de un teléfono celular.
Página 6 de 82
I. Marco conceptual
1.1 SMS
El servicio de mensajes cortos o SMS (Short Message Service) es un servicio
disponible en los teléfonos móviles que permite el envío de mensajes cortos (también
conocidos como mensajes de texto) entre teléfonos móviles, teléfonos fijos y otros
dispositivos de mano. SMS fue diseñado originalmente como parte del estándar de
telefonía móvil digital GSM, pero en la actualidad está disponible en una amplia
variedad de redes, incluyendo las redes 3G.
1.2 SMSC
Corresponde a las siglas en inglés Short Message Service Center (Central de
Servicio de Mensajes Cortos), es un elemento de la red de telefonía móvil, cuya
función es enviar y recibir mensajes de texto.
En el momento que un usuario envía un mensaje de texto (SMS) a otro usuario lo
que sucede es que el teléfono envía el mensaje a la SMSC correspondiente al
operador del usuario remitente. La SMSC guarda el mensaje y lo entrega a su
destinatario cuando este se encuentra en cobertura. Por lo general la SMSC, dentro
de los cientos de parámetros configurables que se puede modificar, dispone de un
tiempo máximo durante el cual el mensaje es guardado, si durante este tiempo el
destinatario no es localizado, el mensaje es descartado. También el usuario
remitente puede especificar este tiempo; pero siempre siendo el configurado en la
SMSC el determinante.
Para la transmisión y recepción de mensajes SMSs, las SMSCs utilizan interfaces de
red convencionales, así como algunos protocolos desarrollados específicamente
para las comunicaciones de red móviles.
Página 7 de 82
1.3 Proyecto Gammu
Gammu es un proyecto que derivo de gnokii (gnokii.org) que en sus inicios solo
daba soporte a celulares Nokia; pero evolucionó a otra variedad de marcas logrando
comunicación por cable, irda (infrarrojo) y Bluetooth.
La herramienta Gammu es un proyecto que abarca aplicaciones, scripts y drivers
para administrar varias funciones de teléfonos celulares y otros dispositivos similares.
Gammu permite al usuario acceder al sistema de archivos del teléfono celular y a las
funcionalidades especiales de control, como radios o cámaras integradas. Esta
herramienta se configura editando el archivo de configuración “gammurc” del
directorio de usuario, o bien, en /etc/gammurc para todos los usuarios.
Gammu también tiene la capacidad de enviar y recibir mensajes SMS (Servicio de
Mensajes cortos) por medio del demonio denominado SMSD. Para ejecutarlo se
tiene que editar primero el archivo de configuración de dicho demonio smsdrc,
configurar ciertas características de este modo de trabajo en tablas para
configuración en la base de datos smsd; finalmente ejecutar el script gammu.sh en
background desde la línea de comandos.
El paquete de instalación de Gammu en su ultima o previas versiones se puede
obtener desde su sitio oficial http://www.gammu.org
Gammu puede ser configurado para trabajar en dos modos:

• Archivos – Los mensajes SMS se leen y almacenan en archivos de disco
• MYSQL – Los mensajes SMS se leen y almacenan en una base de datos
Configuración SMSD:
El archivo de configuración smsdrc puede estar ubicado en cualquier directorio y ser
guardado con cualquier nombre. Por defecto el archivo de configuración smsdrc se
ubica en el directorio docs/examples/config/ que viene en el paquete de instalación
de Gammu.
Su formato es el mismo utilizado en el archivo de configuración principal (gammurc).
Si el archivo smsdrc no es definido en la línea de comando los valores de
configuración son leídos desde gammurc.
Página 8 de 82
[gammu]
port = /dev/ttyS1
model = 6110
connection = dlr3
#synchronizetime = yes
logfile = gammulog
logformat = textall
use_locking = yes
#gammuloc = gammu.us
#startinfo = yes
El símbolo “#” nos indica que esa la línea se tomará como un comentario o parte de
documentación, si fuera necesario fijar algún dato diferente a estos por defecto
definidos se deben especificar en este archivo.
#[include_numbers]
#number1 = 1234
Removiendo los comentarios a la sección anterior es posible definir números de
teléfonos desde los cuales se podrán recibir mensajes tal que mensajes entrantes de
otros números telefónicos no definidos en este apartado serán eliminados, actuando
en alguna manera de forma inteligente.
#[exclude_numbers]
#number1 = 1234
Al quitar el comentario de la sección anterior es posible indicar a gammu de qué
números de teléfonos no se procesaran mensajes entrantes, es decir esta sería
tomada como la definición de la “Lista negra de teléfonos”.
Configuración de Gammu en el modo SMSD

Definiciones de variables de configuración para el contenedor de bases de datos
Mysql, como dirección del servidor de base de datos, nombre de la base de datos,
usuario y clave deben definirse en el archivo de configuración smsdrc.
Ejemplo:
user = root
password = maestriaufg
Página 9 de 82
pc = localhost
database = smsd
Para que la aplicación Gammu pueda tener acceso a los recursos de la base de
datos es necesario definir ciertos privilegios al usuario de conexión.
Para la tabla de recepción de mensajes SMS
• Tabla Inbox - INSERT
Para enviar mensajes SMS:
• Tabla Outbox - SELECT, INSERT, DELETE y UPDATE
• Tabla Outbox_MultiPart - SELECT, INSERT y DELETE
• Tabla SentItems - INSERT y UPDATE
Otros parámetros para la configuración general son:
PIN Numero PIN de la tarjeta SIM del teléfono celular
logfile Nombre del archivo Log para información acerca de las acciones del
modulo smsd.
CommTimeout Define un tiempo en segundos que smsd espera para volver a repetir un
lazo de lectura escritura nuevamente. Por defecto: 1
SendTimeout Muestra cuantos segundos smsd esperará por respuesta de la red

durante el envió del mensaje de texto. Si no ocurre nada en este tiempo,
sms lo reenviará. Por defecto: 10
receivefrequency Frecuencia de recepción. El número de segundos entre pruebas para

recibir mensajes, cuando el teléfono esta ocupado enviando mensajes
SMS. Normalmente esta prueba de recepción de mensajes se hace en el
tiempo estipulado en commtimeout y después de cada mensaje enviado.
Por defecto: 0 (No utilizado)
deliveryreport Reportes de entrega. Si se utilizan reportes de entrega (log).

Opciones: no/log/sms.
log: Una línea de entrada de registro(log),
sms: Almacenado en inbox como un mensaje de texto,
Por defecto: no
phoneid Identificación del teléfono utilizado para enviar y recibir mensajes SMS.
Ejemplo de configuración general:

[smsd]
PIN = 1234
Página 10 de 82
logfile = smsdlog
commtimeout = 1
sendtimeout = 10
#receivefrequency = 0
#resetfrequency = 0
#deliveryreport = no
#phoneid = MyPhone1
El script para la creación de la estructura de la base de datos de Gammu se

encuentra en el paquete de instalación en la siguiente ruta:
docs/examples/config/mysql.sql.
Descripción de la estructura de la base de datos de GAMMU.
Tabla Inbox
Tabla en la que se almacenan los mensajes entrantes (SMS)
Campo Tipo Descripción
UpdatedInDB Timestamp Fecha y hora en que se da una actualización del

usuario, demonio, etc.
ReceivingDateTi Timestamp Hora y fecha en que un mensaje SMS fue
me recibido
Text Text Mensaje de texto codificado en Hexadecimal
SenderNumber Varchar(20) Numero de teléfono (decodificado) que envía el

mensaje.
Coding enum('Default_No_Compres Tipo de codificación del mensaje de texto.
sion',’Unicode_No_Compres
sion','8bit','Default_Compres
sion','Unicode_Compression
')
UDH Texto Cabecera de datos de usuario codificado
SMSCNumber Varchar(20) Numero decodificado de la central de servicio de

mensajes cortos
Página 11 de 82
Class Int(11) Clase SMS or -1
TextDecoded Varchar(160) Mensaje de texto (SMS) decodificado. Por

defecto Alfabeto/Unicote SMS)
ID Integer (11) Identificador del mensaje SMS (Para utilizar con
aplicaciones externas)
RecipientID Texto Identificador del demonio de gammu que lo ha
agregado
Processed enum('false', 'true') Utilizado para marcar si un mensaje SMS fue
procesado o no.
Tabla Outbox
Tabla para un mensaje SMS (o el primer mensaje de una secuencia) esperando para
ser enviado.
UpdatedInDB Timestamp Fecha y hora en que se da una actualización del

usuario, demonio, etc.
InsertIntoDB Timestamp Fecha y hora fijada en el momento de un Insert
SendingDateTime Timestamp Campo en el que se fija algún valor. Cuando

buscamos forzar el envío después de un tiempo
planificado.
Text Texto Mensaje de texto codificado usando valores
Hexadecimales.
DestinationNumb Varchar(20) Número de teléfono (decodificado) del
er destinatario del mensaje
Coding enum('Default_No_Compres Tipo de codificación del mensaje de texto.
sion',
'Unicode_No_Compression',
'8bit',
'Default_Compression',
'Unicode_Compression')
UDH Text Cabecera de datos del usuario codificado usando
valores hexadecimales.
Página 12 de 82
TextDecoded Varchar(160) Mensaje de texto en forma legible para el

humano.
ID Integer (11) No asignada. Identificación de secuencia
SMS/SMS.
MultiPart enum('false','true') Informa, si hay más SMS de esta secuencia en
la tabla Outbox_Multipart.
RelativeValidity Integer (11) Validez relativa del SMS como codificación
utilizando especificaciones GSM.
SenderID Text El valor que contenga este campo será enviado
por SMSD
SendingTimeOut Timestamp Utilizado por SMSD para sus propios objetivos
DeliveryReport enum('default','yes','no') Cuando el valor ‘default’ es utilizado, el Reporte

de entrega es utilizado o no de acuerdo a la
configuración de la instancia SMSD; ‘yes’ fuerza
el Reporte de entrega.
CreatorID Text Puede usarse para agregar información sobre un
proceso, que secuencia SMS/SMS agregar
dentro de la base de datos. Esta es copiada para
Sent_Items "as is"
Tabla Outbox_multipart
Tabla para la segunda y próxima secuencia de SMS esperando para ser enviados.
Text Text Mensaje de texto codificado usando valores

Hexadecimales.
Coding enum('Default_No_Compre Tipo de codificación del mensaje de texto.
ssion','Unicode_No_Compr
ession',
'8bit','Default_Compression'
, 'Unicode_Compression'),
Página 13 de 82
UDH Text Cabecera de datos del usuario codificado usando

valores hexadecimales.
TextDecoded varchar(160) Mensaje de texto en forma legible para el humano.
ID Int(11) unsigned Identico significado para valores en la tabla Outbox
SequencePosition Int(11) Información, ¿Cuál es número SMS en la secuencia

SMS?
Tabla Sent_items
Tabla para SMS enviados.
UpdatedInDB Timestamp Fecha y hora en que se da una actualización
del usuario, demonio, etc.
InsertIntoDB Timestamp Fecha y hora fijada en el momento de un
Insert
SendingDateTime Timestamp Fijarlo a un cierto valor, cuando se desea
forzar a el envío después de un tiempo
previsto.
DeliveryDateTime Timestamp Cuando el reporte de envío fue utilizado por
SMS, esta entrada contiene la hora en que
este reporte fue recibido.
Status enum('SendingOK', Cuando el reporte de envío fue utilizado por
'SendingOKNoReport', SMS, esta entrada contiene código de error
'SendingError', legible por el humano.
'DeliveryOK',
'DeliveryFailed',
'DeliveryPending',
'DeliveryUnknown', 'Error')
StatusError Int(11) Cuando el reporte de envío fue utilizado por
SMS, esta entrada contiene códigos de error
como las especificaciones GSM
Text Text Texto SMS codificado usando valores
hexadecimales.
DestinationNumber Varchar(20) Numero de destino decodificado para SMS
Página 14 de 82

Coding enum('Default_No_Compre Texto codificado SMS.
ssion',
'Unicode_No_Compression'
, '8bit',
'Default_Compression',
'Unicode_Compression')
UDH Texto Cabecera de datos del usuario codificado
con valores hexadecimales.
SMSCNumber Varchar(20) Numero decodificado de la central de
servicio de mensajes cortos
Class Int(11) Clase SMS ó -1
TextDecoded varchar(160) Texto SMS en forma legible al humano.
ID Int(11) No asignado - SMS ID
SenderID Text ¿Qué instancia de SMSD envió esta única

secuencia.
SequencePosition Int(11) Número SMS en secuencia SMS
TPMR Int(11) Mensajes de referencia como

especificaciones GSM
RelativeValidity Int(11) Validación Relativa utilizando
especificaciones GSM
CreatorID Text Copiado de CreatorID desde la tabla Outbox
(y contiene cualquier información put por los
usuarios con acceso a la base de datos)
Modo de Archivos
Configuración
Las siguientes rutas pueden ser utilizadas con el trailing “/” o “\” dependiendo del
sistema operativo.
inboxpath Donde los mensajes SMS recibidos son
almacenados, por defecto el directorio actual.
Página 15 de 82
outboxpath Donde los mensajes SMS a ser enviados

deberían ser ubicados, por defecto el directorio
actual.
sentsmspath Donde los mensajes SMS transmitidos son
ubicados, por defecto outboxpath(= deleted)
errorsmspath Donde los mensajes SMS con error en la

transmisión están ubicados, por defecto
sentsmspath.
inboxformat El formato en que el mensaje SMS será
almacenado: ‘detail’, 'unicode', 'standard'.
El formato 'detail' es el formato utilizado por
backup,'standard' es el juego de caracteres
estándar. Por defecto: unicode.
transmitformat El formato para transmitir el SMS:
'auto','unicode', '7bit'. Por defecto: auto
Ejemplo:
Inboxpath = /var/spool/sms/inbox/
outboxpath = /var/spool/sms/outbox/
sentsmspath = /var/spool/sms/sent/
errorsmspath = /var/spool/sms/error/
inboxformat = unicode
transmitformat = auto
1.4 MySql
MySQL, el sistema de gestión de bases de datos SQL Open Source más popular, lo
desarrolla, distribuye y soporta MySQL AB. MySQL AB es una compañía comercial,
fundada por los desarrolladores de MySQL. Es una compañía Open Source de
segunda generación que une los valores y metodología Open Source con un exitoso
modelo de negocio.
Página 16 de 82
El sitio Web MySQL (http://www.mysql.com/) proporciona la última información sobre

MySQL y MySQL AB.
• MySQL es un sistema de gestión de bases de datos
Una base de datos es una colección estructurada de datos. Puede ser

cualquier cosa, desde una simple lista de compra a una galería de pintura o
las más vastas cantidades de información en una red corporativa. Para añadir,
acceder, y procesar los datos almacenados en una base de datos, necesita un
sistema de gestión de base de datos como MySQL Server. Al ser los
computadores muy buenos en tratar grandes cantidades de datos, los
sistemas de gestión de bases de datos juegan un papel central en
computación, como aplicaciones autónomas o como parte de otras
aplicaciones.
• MySQL es un sistema de gestión de bases de datos relacionales
Una base de datos relacional almacena datos en tablas separadas en lugar de

poner todos los datos en un gran almacén. Esto añade velocidad y flexibilidad.
La parte SQL de "MySQL" se refiere a "Structured Query Language". SQL es
el lenguaje estandarizado más común para acceder a bases de datos y está
definido por el estándar ANSI/ISO SQL. El estándar SQL ha evolucionado
desde 1986 y existen varias versiones.
• MySQL software es Open Source.
Open Source significa que es posible para cualquiera usar y modificar el

software. Cualquiera puede bajar el software MySQL desde Internet y usarlo
sin pagar nada. Si se desea estudiar el código fuente y cambiarlo para
adaptarlo a necesidades particulares. El software MySQL usa la licencia GPL
(GNU General Public License), http://www.fsf.org/licenses/, para definir lo que
se puede y no se puede hacer con el software en diferentes situaciones. Si no
se desea utilizar la licencia GPL o se necesita añadir código MySQL en una
aplicación comercial, se puede comprar la licencia comercial.
Página 17 de 82
• El servidor de base de datos MySQL es muy rápido, fiable y fácil de usar.
El servidor MySQL también tiene una serie de características prácticas

desarrolladas en cooperación con los usuarios. MySQL Server se desarrolló
originalmente para tratar grandes bases de datos mucho más rápido que
soluciones existentes y ha sido usado con éxito en entornos de producción de
alto rendimiento durante varios años. MySQL Server ofrece hoy en día una
gran cantidad de funciones. Su conectividad, velocidad, y seguridad hacen de
MySQL Server altamente apropiado para acceder bases de datos en Internet
• MySQL Server trabaja en entornos cliente/servidor o incrustados
El software de bases de datos MySQL es un sistema cliente/servidor que

consiste en un servidor SQL multi-threaded que trabaja con diferentes back
ends, programas y bibliotecas cliente, herramientas administrativas y un
amplio abanico de interfaces de programación para aplicaciones (APIs).
• Una gran cantidad de software de contribuciones está disponible para MySQL,

es decir muchas aplicaciones soportan el servidor de base de datos de
MySQL.
1.5 Java
Java es un lenguaje de programación orientado a objetos desarrollado por Sun
Microsystems a principios de los años 1990. Las aplicaciones Java están típicamente
compiladas en un bytecode, aunque la compilación en código máquina nativo
también es posible. En el tiempo de ejecución, el bytecode es normalmente
interpretado o compilado a código nativo para la ejecución, aunque la ejecución
directa por hardware del bytecode por un procesador Java también es posible.
El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un

modelo de objetos más simple y elimina herramientas de bajo nivel como punteros.
JavaScript, un lenguaje interpretado, comparte un nombre similar y una sintaxis
similar, pero no está directamente relacionado con Java.
Página 18 de 82
Sun Microsystems proporciona una implementación GNU General Public License de

un compilador Java y una máquina virtual Java, conforme a las especificaciones del
Java Community Process, aunque la biblioteca de clases que se requiere para
ejecutar los programas Java no es software libre.
El lenguaje Java se creó con cinco objetivos principales:
1. Debería usar la metodología de la programación orientada a objetos.
2. Debería permitir la ejecución de un mismo programa en múltiples sistemas

operativos.
3. Debería incluir por defecto soporte para trabajo en red.
4. Debería diseñarse para ejecutar código en sistemas remotos de forma segura.
5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a

objetos, como C++.
Para conseguir la ejecución de código remoto y el soporte de red, los programadores

de Java a veces recurren a extensiones como CORBA (Common Object Request
Broker Architecture), Internet Communications Engine o OSGi respectivamente.
Las características principales de Java son las siguientes:
• Orientado a Objetos
La primera característica, orientado a objetos (“OO”), se refiere a un método

de programación y al diseño del lenguaje. Aunque hay muchas
interpretaciones para OO, una primera idea es diseñar el software de forma
que los distintos tipos de datos que use estén unidos a sus operaciones. Así,
los datos y el código (funciones o métodos) se combinan en entidades
llamadas objetos. Un objeto puede verse como un paquete que contiene el
“comportamiento” (el código) y el “estado” (datos). El principio es separar
aquello que cambia de las cosas que permanecen inalterables.
Frecuentemente, cambiar una estructura de datos implica un cambio en el
Página 19 de 82
código que opera sobre los mismos, o viceversa. Esta separación en objetos
coherentes e independientes ofrece una base más estable para el diseño de
un sistema software. El objetivo es hacer que grandes proyectos sean fáciles
de gestionar y manejar, mejorando como consecuencia su calidad y
reduciendo el número de proyectos fallidos. Otra de las grandes promesas de
la programación orientada a objetos es la creación de entidades más
genéricas (objetos) que permitan la reutilización del software entre proyectos,
una de las premisas fundamentales de la Ingeniería del Software. Un objeto
genérico “cliente”, por ejemplo, debería en teoría tener el mismo conjunto de
comportamiento en diferentes proyectos, sobre todo cuando estos coinciden
en cierta medida, algo que suele suceder en las grandes organizaciones. En
este sentido, los objetos podrían verse como piezas reutilizables que pueden
emplearse en múltiples proyectos distintos, posibilitando así a la industria del
software a construir proyectos de envergadura empleando componentes ya
existentes y de comprobada calidad; conduciendo esto finalmente a una
reducción drástica del tiempo de desarrollo. Podemos usar como ejemplo de
objeto el aluminio. Una vez definidos datos (peso, maleabilidad, etc.), y su
“comportamiento” (soldar dos piezas, etc.), el objeto “aluminio” puede ser
reutilizado en el campo de la construcción, del automóvil, de la aviación, etc.
La reutilización del software ha experimentado resultados dispares,

encontrando dos dificultades principales: el diseño de objetos realmente
genéricos es pobremente comprendido, y falta una metodología para la amplia
comunicación de oportunidades de reutilización. Algunas comunidades de
“código abierto” (open source) quieren ayudar en este problema dando medios
a los desarrolladores para diseminar la información sobre el uso y versatilidad
de objetos reutilizables y librerías de objetos.
• Independencia de la plataforma
La segunda característica, la independencia de la plataforma, significa que

programas escritos en el lenguaje Java pueden ejecutarse igualmente en
cualquier tipo de hardware. Es lo que significa ser capaz de escribir un
Página 20 de 82
programa una vez y que pueda ejecutarse en cualquier dispositivo, tal como
reza el lema de Java, ‘’’write once, run everywhere’’’.
Para ello, se compila el código fuente escrito en lenguaje Java, para generar
un código conocido como “bytecode” (específicamente Java bytecode)
instrucciones de máquina simplificadas específicas de la plataforma Java.
Esta pieza está “a medio camino” entre el código fuente y el código máquina
que entiende el dispositivo destino. El bytecode es ejecutado entonces en la
máquina virtual (VM), un programa escrito en código nativo de la plataforma
destino (que es el que entiende su hardware), que interpreta y ejecuta el
código. Además, se suministran librerías adicionales para acceder a las
características de cada dispositivo (como los gráficos, ejecución mediante
hebras o threads, la interfaz de red) de forma unificada. Se debe tener
presente que, aunque hay una etapa explícita de compilación, el bytecode
generado es interpretado o convertido a instrucciones máquina del código
nativo por el compilador JIT (Just In Time).
Hay implementaciones del compilador de Java que convierten el código fuente

directamente en código objeto nativo, como GCJ. Esto elimina la etapa
intermedia donde se genera el bytecode, pero la salida de este tipo de
compiladores sólo puede ejecutarse en un tipo de arquitectura.
Las primeras implementaciones del lenguaje usaban una máquina virtual

interpretada para conseguir la portabilidad. Sin embargo, el resultado eran
programas que se ejecutaban comparativamente más lentos que aquellos
escritos en C o C++. Esto hizo que Java se ganase una reputación de lento en
rendimiento. Las implementaciones recientes de la JVM dan lugar a
programas que se ejecutan considerablemente más rápido que las versiones
antiguas, empleando diversas técnicas.
La portabilidad es técnicamente difícil de lograr, y el éxito de Java en ese

campo ha sido dispar. Aunque es de hecho posible escribir programas para la
Página 21 de 82
plataforma Java que actúen de forma correcta en múltiples plataformas de

distinta arquitectura.
El concepto de independencia de la plataforma de Java cuenta, sin embargo,

con un gran éxito en las aplicaciones en el entorno del servidor, como los
Servicios Web, los Servlets, los Java Beans y otros.
1.6 Eclipse
Eclipse es una plataforma de software de Código abierto independiente de una

plataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente
Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en
navegadores. Esta plataforma, típicamente ha sido usada para desarrollar
entornos integrados de desarrollo (del Inglés IDE), como el IDE de Java llamado
Java Development Toolkit (JDT) y el compilador (ECJ) que se embarca como
parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse).
Sin embargo, también se puede usar para otros tipos de aplicaciones cliente,
como BitTorrent Azureus.
Eclipse es también una comunidad de usuarios, extendiendo constantemente las

áreas de aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse
Modeling Project, cubriendo casi todas las áreas de Model Driven Engineering.
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de
herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación
Eclipse, una organización independiente sin ánimo de lucro que fomenta una
comunidad de código abierto y un conjunto de productos complementarios,
capacidades y servicios.
• Arquitectura
La base para Eclipse es la Plataforma de cliente enriquecido (del Inglés Rich

Client Platform RCP). Los siguientes componentes constituyen la plataforma
de cliente enriquecido:
Página 22 de 82
• Plataforma principal - inicio de Eclipse, ejecución de plugins
• OSGi - una plataforma para bundling estándar.
• El Standard Widget Toolkit (SWT) - Un widget toolkit portable.
• JFace - manejo de archivos, manejo de texto, editores de texto
• El Workbench de Eclipse - vistas, editores, perspectivas, asistentes
Los widgets de Eclipse están implementados por un herramienta de widget para Java
llamada SWT, a diferencia de la mayoría de las aplicaciones Java, que usan las
opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de
Eclipse también tiene una capa GUI intermedia llamada JFace, la cual simplifica la
construcción de aplicaciones basada en SWT.
El entorno integrado de desarrollo (IDE) de Eclipse emplea módulos (en inglés plug-
in) para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a
diferencia de otros entornos monolíticos donde las funcionalidades están todas
incluidas, las necesite el usuario o no. Este mecanismo de módulos es una
plataforma ligera para componentes de software. Adicionalmente a permitirle a
Eclipse extenderse usando otros lenguajes de programación como son C/C++ y
Phyton, permite a Eclipse trabajar con lenguajes para procesado de texto como
LaTeX, aplicaciones en red como Telnet y Sistema de gestión de base de datos. La
arquitectura plugin permite escribir cualquier extensión deseada en el ambiente,
como seria Gestión de la configuración. Se provee soporte para Java y CVS en el
SDK de Eclipse. Y no tiene porque ser usado únicamente para soportar otros
lenguajes de programación.
La definición que da el proyecto Eclipse acerca de su software es: "una especie de

herramienta universal - un IDE abierto y extensible para todo y nada en particular".
En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks

muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de
modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing
Página 23 de 82
Framework - Framework para la edición gráfica) es un plugin de eclipse para el

desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg
hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc.
Dado que los editores realizados con GEF "viven" dentro de eclipse, además de
poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz gráfica
que puede ser personalizada y profesional.
El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE

con un compilador de Java interno y un modelo completo de los archivos fuente de
Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE
también hace uso de un espacio de trabajo, en este caso un grupo de metadata en
un espacio para archivos plano, permitiendo modificaciones externas a los archivos
en tanto se refresque el espacio de trabajo correspondiente.
Características:
La versión actual de Eclipse dispone de las siguientes características:
• Editor de texto
• Resaltado de sintaxis En cuanto a las aplicaciones clientes, eclipse provee al

programador con frameworks muy ricos para el desarrollo de aplicaciones
gráficas, definición y manipulación de modelos de software, aplicaciones web, etc.
Por ejemplo, GEF (Graphic Editing Framework - Framework para la edición
gráfica) es un plugin de eclipse para el desarrollo de editores visuales que pueden
ir desde procesadores de texto wysiwyg hasta editores de diagramas UML,
interfaces gráficas para el usuario (GUI), etc. Dado que los editores realizados
con GEF "viven" dentro de eclipse, además de poder ser usados conjuntamente
con otros plugins, hacen uso de su interfaz gráfica personalizable y profesional.
• El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un

IDE con un compilador de Java interno y un modelo completo de los archivos
fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de
código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo
Página 24 de 82
de metadata en un espacio para archivos plano, permitiendo modificaciones

externas a los archivos en tanto se refresque el espacio de trabajo
correspondiente.
• Compilación en tiempo real
• Pruebas unitarias con JUnit
• Control de versiones con CVS
• Integración con Ant
• Asistentes (wizards): para creación de proyectos, clases, tests, etc.
• Refactorización
Asimismo, a través de "plugins" libremente disponibles es posible añadir:
• Control de versiones con Subversion, vía Subclipse.
• Integración con Hibernate, vía Hibernate Tools.
Proyectos Eclipse
Eclipse esta compuesto de muchos proyectos diferentes. Algunos proyectos se

mencionan a continuación.
• El proyecto Eclipse per se que incluye la Plataforma Eclipse. Plataforma

Eclipse de Cliente Enriquecido (RCP) y las herramientas de desarrollo de Java
(JDT).
• Plataforma de herramientas para pruebas y desempeño (de sus siglas en

Inglés TPTP) que provee una plataforma que permite a desarrolladores de
software construir herramientas de pruebas y desempeño, como son
Depuradores, profilers y aplicaciones Benchmark.
Página 25 de 82
• Proyecto Plataforma de Herramientas Web (WTP) extiende la plataforma

Eclipse con herramientas para desarrollar aplicaciones Web en Java EE. Esta
compuesta de: Editores de fuentes para HTML, JavaScript, CSS, JSP, SQL,
XML, DTD, XSD y WSDL; Editores gráficos para XSD y WSDL; proyectos de
naturaleza Java EE, constructores y modelos y un navegador de Java EE; un
explorador y asistente para servicios Web y una herramienta de pruebas WS-I;
herramientas para acceso a base de datos, filtrado y modelos; y herramientas
para manejo de servidores de pruebas unitarias.
• Proyecto de herramientas para inteligencia empresarial y generación de

reportes (BIRT), un sistema de reporteo Código abierto basado en Eclipse
para aplicaciones Web, especialmente aquellas basadas en Java EE.
• Proyecto de Edición Visual (VE) una plataforma para crear constructores GUI
para Eclipse
• Plataforma de Modelado Eclipse (EMF) una plataforma de modelado y

generación de código para construir herramientas y otras aplicaciones
basadas en un modelo de datos estructurado, desde una especificación de
modelo descrita en XMI.
• Herramientas de Modelado Generativo (GMT) un grupo de herramientas para

modelado por ejemplo para ejecutar transformaciones de modelo QVT.
• Plataforma de Editor Gráfico (GEF) permite a los desarrolladores tomar el

modelo de una aplicación existente y fácilmente crear un editor de gráficos
ricos.
• UML2 una implementación de UML 2.0 metamodel para la plataforma Eclipse

diseñada para soportar el desarrollo de herramientas de modelado.
• Plataforma de comunicaciones de Eclipse Communication Framework (ECF)

habilita la creación de aplicaciones de comunicaciones en la plataforma de
Eclipse.
Página 26 de 82
• Proyecto Plataforma de herramientas de Datos (DTP)
• Plataforma de Herramientas Paralelas (PTP) entrega una plataforma de

herramientas paralelas portables, escalables, basadas en estándares que
habilita la integración de herramientas específicamente desarrolladas para
computadoras con arquitectura paralela.
• Plataforma de Cliente Rico incluido (eRCP) la intención es extender la

plataforma de Cliente Rico (de las siglas en Inglés RCP) para dispositivos
incluidos. eRCP es en general un grupo de componentes que son subgrupos
de los componentes RCP. Básicamente habilita el mismo modelo de
aplicaciones usado en maquinas de escritorio para ser usados en dispositivos.
• Plataforma de Desarrollo de Software para Dispositivos (DSDP) es un

proyecto de desarrollo de software colaborativo de código abierto dedicado a
proveer una plataforma extendible basada en estándares para cubrir un
amplio rango de necesidades en el área del desarrollo de software para
dispositivos usando la plataforma de Eclipse.
Proyectos IDE en Lenguajes
• AspectJ es una extensión del lenguaje Java orientado a aspectos.
• Proyecto de herramientas de desarrollo en C/C++ (CDT) trabaja para proveer

un Ambiente integrado de desarrollo completamente funcional para C y C++
para la plataforma Eclipse.
• Subproyecto IDE de COBOL para Eclipse (COBOL) construye un Ambiente

Integrado de Desarrollo (IDE) completamente funcional para COBOL en la
plataforma Eclipse.
• Herramientas de Desarrollo de Java (JDT) provee las herramientas que

implementan un IDE de Java, soportando el desarrollo de cualquier aplicación
Java, incluyendo los plug-ins de Eclipse.
Página 27 de 82
• Photran (photran) es un IDE completamente funcional para Fortran con

soporte para Refactorización.
• Proyecto IDE PHP trabaja para proveer un IDE completamente funcional para
PHP para la plataforma Eclipse.
• Wolfram Workbench es un IDE basado en Eclipse (también disponible como

plugin para Eclipse) para el lenguaje Mathematica.
• PyDev un IDE completamente funcional para python con soporte para

Refactorización, y depurador gráfico.
1.7 Lomboz
Lomboz es un plugin gratuito y abierto para el entorno de desarrollo J2EE. Tiene
medios para desarrollar, probar, perfilar y desplegar aplicaciones web, Java, J2EE y
EJB. Lomboz admite la mayoría de los runtimes de servidores de aplicaciones J2EE
estándar, y admite la mayoría de los runtimes populares de código abierto tales como
JOnAS. Al igual que JOnAS, Lomboz está hospedado y desarrollado por el consorcio
ObjectWeb (el grupo de desarrollo se llama a sí mismo "eteration"). Esto está
distribuido bajo LGPL.
Lomboz suministra:
1. Asistentes para crear y ensamblar módulos J2EE.

2. editor JSP y asistente para el código.
3. Compatibilidad con JBoss, WebLogic, Apache Tomcat, JOnAS y JRun.
4. generadores de código EJB basados en XDoclet.
5. Generadores de Servicios Web basados en Apache Axis.
1.8 Hibernate
Hibernate es un servicio de persistencia objeto/relaciones y consultas para Java.
Hibernate facilita a los desarrolladores crear las clases de persistencia utilizando
Página 28 de 82
el lenguaje Java - incluyendo la asociación, herencia, polimorfismo y composición

y el entorno de colecciones Java.
Usar JDBC es complejo y muy dependiente de la estructura de los datos. Sería
más natural y mucho más sencillo trabajar directamente con objetos, pero es
imposible con las BBDD relacionales, y las BBDD orientadas a objeto están
todavía muy poco desarrolladas.
La mejor opción entonces es utilizar un motor de persistencia, que es el
componente software encargado de traducir entre objetos y registros. Un motor
de persistencia de código abierto es Hibernate, que nos permitirá hacer cosas
como poder guardar un objeto en la base de datos simplemente con
session.save(miObjeto) o borrarlo con session.delete(miObjeto).
Usa el mecanismo de reflexión de Java, que permite a un objeto en ejecución

examinarse y manipularse a sí mismo, en contra de, por ejemplo, JDO, que
necesita que modifiquemos los archivos de las clases.
Vamos a tener un archivo properties (hibernate.properties) o un archivo xml
(hibernate.cfg.xml) para la configuración, una serie de JavaBeans que son las
clases a persistir y en las que cada campo se asociará con una columna de la
BBDD, y un archivo xml por cada una de estas clases (NombreClase.hbm.xml)
que indica el mapping entre objetos y relaciones.
Ejemplo de archivo de mapeo:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping
DTD//EN"
"http://hibernate.sourceforge.net/hibernate-mapping.dtd">
<hibernate-mapping>
<class name="dbdemo.User" table="users">
<id name="ID" column="LogonId" type="string">
<generator class="assigned"/>
</id>
<property name="userName" column="Name" type="string"/>
<property name="password" type="string"/>
Página 29 de 82
<property name="emailAddress" type="string"/>

<property name="lastLogon" type="date"/>
</class>
</hibernate-mapping>
La etiqueta class del código anterior indica el nombre de la clase que vamos a
mapear a la tablar de users en la base de datos.
La etiquete Id tiene que ver con el mapeo de la clave primaria de la tabla. La etiqueta
del generador le dice a hibernate como debe producir la clave primaria (Hibernate
genera una, del tipo que se desee; pero se le debe indicar como), en este caso se a
fijado como “asignado”. Si se quiere que hibernate asigne las claves se pueden
utilizar las claves uuid.hex y uuid.string.
Las etiquetas property le indican a hibernate los atributos del objeto (name) y su
campo correspondiente en la tabla dentro de la base de datos. El atributo type es
opcional (Hibernate utilizará reflection para conjeturar el tipo para el caso en que no
se le indique)
1.9 PERL
Practical Extraction and Report Language es un sofisticado lenguaje de
programación diseñado a finales de los años 80 por el lingüista norteamericano Larry
Wall. PERL combina en forma concisa las mejores características de lenguajes como
C, sed, awk y sh. En general, es posible reducir extensos programas escritos en C a
pocas líneas de código de un programa PERL, con la ventaja adicional de que corren
sin cambio sobre casi cualquier plataforma existente, lo que convierte a PERL en el
lenguaje ideal para desarrollo de prototipos y aplicaciones robustas 100% portables.
Durante los últimos años la popularidad del lenguaje alcanzó niveles insospechados
a raíz de su utilización generalizada en soluciones Web. PERL es el estándar "no
oficial" para la construcción de compuertas CGI (Common Gateway Interface) que
generan páginas dinámicas en la Web.
Junto con las facilidades para el desarrollo de aplicaciones Web, PERL es útil en la
resolución de cualquier tarea y posee habilidades para integrarse con sistemas
operativos, bases de datos, redes, protocolos, ambientes gráficos, otros lenguajes de
programación (Java, C, etc. ), etc. Su versatilidad y eficiencia en el manejo de texto
Página 30 de 82
y, específicamente, de "expresiones regulares" no tiene equivalente en ningún otro

lenguaje de programación actual.
Finalmente, es importante mencionar que PERL también es un lenguaje orientado a
objetos aunque el programador no está forzado a programar con este esquema.
Página 31 de 82
II. Análisis del problema
En este apartado del proyecto, se analiza la situación actual, se plantea el problema

usando la técnica de la caja negra. Una vez planteado, se analizan las características
del problema y finalmente se establecen las características de la solución.
2.1 Situación actual
Existe una gama de situaciones delicadas en torno a la administración remota de

servidores, con el propósito de que estos se mantengan operando de forma
constante. Los principales problemas en la actualidad se enuncian a continuación:
• Atención de servidor por fallos en servicios
Generalmente la administración de servidores se lleva a cabo “in situ”, por lo que hay
uno o varios administradores responsables del buen funcionamiento de dichos
servidores, de tal forma que si un servicio tiene algún problema, el responsable
deberá solucionarlo presencialmente.
• Soporte de servidor 7/24
Los costos de operación de los servidores por lo general son altos. Cuando dichos
servicios tienen cobertura 7/24 estos se elevan aun más, en términos económicos
para la empresa. El soporte se vuelve un problema para el especialista responsable
de los servidores, ya que las fallas pueden darse a cualquier hora del día y cualquier
día del año, debiendo optar por contratar personal de administración de servidor para
las 24 horas o hacer que el personal pueda desplazarse al lugar donde se
encuentren dicho servidor para solucionar cualquier fallo.
• Múltiples Administradores de servidores
Página 32 de 82
Se da el caso en el que se tienen servidores distribuidos en más de un lugar, como

cuando se poseen sucursales, teniendo que contratarse un administrador por cada
servidor, y este tipo de contratación no es factible para muchas empresas. Por
ejemplo un administrador para la base de datos, otro para el correo electrónico, uno
más para administrador de dominio, otro para administración de servidores Web y así
conforme los servicios que se brinden.
• Baja rentabilidad por fallas de servidores
Es vital para las empresas que sus operaciones no sean suspendidas por fallas en
los servicios prestados por sus servidores, ya que esto les podría causar retraso,
baja productividad e inclusive problemas con clientes que a la larga, redundan en la
paralización de su actividad empresarial.
• Sistemas de monitoreo sin control remoto
Existen algunas aplicaciones Web desde las cuales se pueden realizar monitoreo de
servicios; pero dichas aplicaciones se quedan simplemente en el diagnostico de la
falla. Por ejemplo si un servidor MySql falla, el administrador podría saber cual es el
problema, pero no podrá levantar remotamente dicho servicio y comprobar
posteriormente su estado. Lo anterior nos lleva a decir que no se logra una
comunicación interactiva con el servidor de manera remota.
• Sistemas de control remoto por acceso desde PC e Internet
Existen formas de tomar control remoto de servidores, con aplicaciones tales como
X. Este recurso permite a empresas que tienen sus servidores con una IP pública,
poder tomar control remoto desde otra computadora distante.
Esta solución requiere tener una inversión fuerte en lo relativo a lo económico y a la
seguridad, lo primero, por tener seguramente contrato de servicios redundantes de
Internet, y lo segundo porque sus servidores de producción estarían expuestos
públicamente al Internet. Regularmente los servidores de producción no se pondrían
Página 33 de 82
bajo este riesgo, generalmente se requiere una mayor inversión en infraestructura de

comunicaciones para la incorporación de los servidores en una DMZ o hacer posible
un acceso configurado a través de VPN. Una gran desventaja de este modelo a parte
de lo económico y la seguridad es que el control debe realizarse desde una PC, lo
cual no es como un teléfono celular el cual anda en su bolsillo.
• Sistemas de control remoto por medio de SMS
No existe al momento una forma de lograr la administración remota de servidores por

medio de mensajes de texto desde un celular y que además sea configurable, es
decir, poder ir extendiendo los servicios a los cuales se les pueda dar soporte.
2.2 Planteamiento del problema
A continuación se presenta el planteamiento del problema, a través del método de la

caja negra.
Servidor sin control Sistema Servidor controlado

remoto WDS remotamente
Los elementos involucrados en la caja negra anterior, se analizan preliminarmente en

el siguiente cuadro:
Página 34 de 82
Entrada Proceso Salida
• Fallos en servicios de • Servicios controlados en

servidores remotos WDS servidores remotos
• Sin Soporte 7/24 • Con Soporte 7/24
• Se cuenta con Múltiples • Se pueden controlar uno o
Adimistradores físicos más Servidores y diversos
servicios
• Soluciones no rentables • Solución de bajo costo
• Control remoto desde PC • Control remoto móvil desde
celular por medio de SMS
2.3 Características del problema: A continuación se listan las principales
características del problema:
2.3.1 Características de fallo en servicios en servidores
- Fallo imprevisto en horas no laborales

- Todo servidor tiene riesgo en fallo en sus servicios
- Si el fallo es detectado, el servicio permanece interrumpido.
- La interrupción del servicio persiste hasta que el administrador está
presencialmente
- El servidor no tiene un sistema de monitoreo
- El servidor está monitoreado pero no tiene forma de comunicarse
con el exterior
- El administrador es advertido del fallo del servicio pero no tiene
acceso a al servidor
- El Administrador no puede tener forma de aplicar comandos al
servidor.
2.3.2 Característica de Soporte 7/24
- No se tiene la factibilidad de contratar un especialista en servidor
para cobertura 7/24
Página 35 de 82
- No se cuenta en la mayoría de empresas

- Muchas compañías con servicios críticos como hospitales, policía,
fábricas operan las 24 horas
- El administrador de turno no se encuentra disponible
- El proceso que se ha detenido, es crítico para el cliente del proceso.
- El proceso detenido en el Server, detiene muchos recursos a su vez
(efecto cascada).
- En muchos casos la ubicación geográfica del servidor se encuentra
en zonas de difícil acceso o de alta peligrosidad.
2.3.3 Características del problema con múltiples administradores
- Se tienen varios servidores
- Se tiene un administrador para cada servidor
- Pueden haber varios administradores para diversos servicios en un
solo servidor.
- Pueden haber diversos administradores.
2.3.4 Características en torno a la rentabilidad
- No es rentable la contratación de un ISP
- No es factible contratar especialistas para estar de turno 7/24
- No se tiene acceso a red de telefonía fija y por lo tanto una red de
microondas u otro medio, no es rentable.
- La interrupción de servicios ocasiona baja productividad, mal
imagen y esto se traduce en menores ingresos.
2.3.5 Control remoto móvil
- El administrador tiene PC sin el programa de acceso
- El administrador está viajando de una ubicación geográfica a otra y
no tiene acceso a PC.
- El administrador tiene celular, pero no puede controlar la PC desde
ese dispositivo
2.3.6 Seguridad
- El Server de producción no se puede exponer al Internet
- Una vez en Internet, el Server deberá ser asegurado, respaldado y
se deberán tomar todas las medidas para mitigar riesgos, lo cual
Página 36 de 82
implica tareas de monitoreo, control y otras que deberán

presupuestarse.
- No hay una forma sencilla y segura para tomarlo desde cualquier
ubicación e interactuar con el.
2.4 Características de la solución. La solución que se busca, deberá ser capaz de
resolver todas las características mencionadas anteriormente
• Deberá ser una solución que permita interactuar con el servidor en ambas
vías, es decir lanzarle comandos y recibir respuestas del servidor.
• Deberá permitir soporte 7/24, es decir debe ser capaz de acceder al servidor
en cualquier día y hora.
• Deberá permitir controlar diversos servicios e inclusive diversas máquinas
(PC o Servidores).
• Deberá ser una solución de bajo presupuesto y de preferencia usando
software libre.
• Deberá vencer el problema de depender de una PC para operar un servidor,
se prefiere que el control se haga desde un dispositivo móvil.
• No deberá hacer depender a una empresa de contratar un ISP de Internet.
• Deberá vencer las barreras de Seguridad, ejecutando remotamente grupos
de comandos o instrucciones individuales de sistema operativo que permitan
realizar funciones de administración de servidor tales como la recuperación
de servicios y la consulta del estado de los mismos.
Página 37 de 82
III. Propuesta de solución
En este capítulo se presenta la solución propuesta, así como también la justificación

del tipo de elección.
La propuesta de solución se aproximará en tres escalones:
• Diagrama de contexto o de nivel 0: Diagrama jerárquico de la solución al más

alto nivel posible.
• Diagrama de nivel 1: Diagrama en el que la propuesta de solución es
aproximada como una solución siempre de alto nivel, pero en la cual se
puedan ver sus componentes internos.
• Diagrama de nivel 2: Diagrama completo con todos los componentes de la
solución propuesta.
3.1 Diagrama de contexto (Nivel 0)
Desde la perspectiva del usuario final (administrador(es) del servidor), el proyecto
consiste en diseñar un sistema de ingeniería para acercar el equipo servidor a sus
administradores en cualquier lugar a cualquier hora del día utilizando mensajes de
textos desde su teléfono móvil para administrar los servicios prestados por equipos
servidores en una ubicación distante.
Ordenes o
comandos
Página 38 de 82
El administrador podrá ejecutar comandos en el Servidor desde su celular y recibir la
salida del comando.
El administrador y el sistema WDS, podrá realizar las siguientes actividades:

• Realizar el monitoreo de algún servicio.
• Enviar comandos al equipo servidor.
El procedimiento es bastante simple y consiste de los siguientes pasos:
• Administrador, envía un mensaje al servidor

• Servidor recibe el mensaje y ejecuta el comando asociado
• Servidor capta la salida del comando en el sistema operativo y se la devuelve al
Administrador, vía mensaje de texto, lo cual simula un control remoto del servidor.
El caso de uso puede verse en la siguiente figura.
WDS
Envia /Recibe SMS

«uses» «uses»
«uses»
Ejecutar comando
Admin Fisico Admin Virtual
A continuación se muestra el correspondiente diagrama de secuencia
Página 39 de 82
Admin Viirtual WDS Sistema Operativo
Administrador Físico
Envía SMS
SMS
Comando
Salida del comando
Envia Resultado
Envía SMS
3.2 Diagrama de nivel 1
El mensaje es recibido en el servidor. Para esto será necesario tener otro celular,
quien reciba el mensaje.
Ordenes o
comandos
El celular que recibe el mensaje, estará conectado al Server, por USB, bluetooth,
puerto infrarrojo u otros medios.
El mensaje será trasladado a una base de mySql, a través de un demonio
denominado smsd. Dicho demonio es parte del proyecto Gammu.
Página 40 de 82
En la base de datos, el mensaje deberá ser transformado a comando. Esto será la

tarea que realizará un demonio del presente proyecto WDS, llamado i2ic, el cual
recibe su nombre precisamente de “Inbox to Inbox Command”
Una vez el comando se ha identificado, un programa en java, que es parte del núcleo
del presente proyecto WDS, hará la ejecución del comando a nivel del sistema
operativo, capturando la salida del mismo y la enviará de regreso al celular que inició
toda esta cadena de pasos.
WDS
Lee mensaje Mensaje

SMSD SMSD I2ic
Entrega de
SMS Daemon Daemon
Envía SMS
Gammu MySQL
JAVA
Admin Fisco
Comando a Ejecutar
Sistema
Operativo
3.3 Diagrama de nivel 2
En este diagrama se visualiza la solución completa, con todos los detalles. En

primera instancia, se presente un esquema completo de la solución y seguidamente
se realiza el diagrama de secuencia, a fin de visualizar la interacción de todos los
componentes.
Página 41 de 82
WDS
Entrega de Lee mensaje

SMS SMS Codificado
SMSD
Daemon
Envía SMS
Gammu
Admin Fisco MYSQL

Inbox
Inbox Command Outbox
Command
Hibernate
i2ic Sistema
JAVA Operativo
Daemon
El proceso empieza enviando el mensaje desde un celular válido. Dicho mensaje es

recibido en el celular que controla al servidor. El Mensaje es tomado por el demonio
smsd el cual lo almacenara dentro de la estructura de base de datos. Luego otro
demonio llamado i2ic revisa que el mensaje sea con el formato :1 y va a la base de
datos a buscar el comando correspondiente. El comando encontrado está compuesto
de dos elementos: archivo y ruta. Archivo es el nombre del archivo que puede
contener uno o más comandos (Script) y ruta es la ubicación del dicho archivo en el
sistema de archivos. El mensaje, debidamente identificado con su script asociado, es
conocido ahora como InboxCommand. Una vez el InboxCommand recibe un
comando, la aplicación Java, toma el objeto InboxCommand, por medio del motor de
Página 42 de 82
persistencia llamado HIBERNATE, ejecuta el comando y finalmente convirtiéndolo en

un objeto de salida (Outbox), el cual va hacia el cliente, en forma de SMS, por medio
del celular conectado al servidor.
La secuencia en la que el diagrama anterior realiza la interacción con todos los

componentes, se puede apreciar a través del diagrama de secuencia de la siguiente
figura
Celular1 Celular2 Smsd Daemon Inbox Table I2ic Daemon Command Table JavaClient Os Outbox Table
Enviar Sms
Leer Sms
Insert Sms
Leer Sms
Marcar Leído
getId
getScriptName
Return Script
Mensaje1
Exe Command
getOutput
Prepare Outbox
Insert Outbox
Leer Sms
Escribir Sms
Send Sms
3.4 Software a utilizar:
3.4.1 Gammu. Este proyecto de código abierto en lenguaje C ANSI, que

permite la recepción y envío de mensajes SMS utilizando una base de datos
mySql. Este es gratuito y es podría decirse que es el punto de partida del
presente proyecto WDS. Originalmente se había seleccionado el proyecto
GNOKI el cual permite el control del envío y recepción de mensajes, sin
embargo la parte de la base de datos no la incluye. El presente proyecto
WDS, tendrá que realizar todos los mecanismos para elevar el mensaje a la
categoría de comando, interpretar el comando, ejecutarlo en el sistema
Página 43 de 82
operativo y finalmente capturar la salida del comando y enviarla de nuevo

como SMS al celular solicitante.
3.4.2 Hibernate. Es un motor de persistencia, es decir un servicio de alto
rendimiento objeto/relacional. Es la más flexible y poderosa solución en el
mercado de motores de persistencia. Hibernate se encarga del mapeo de
clases a sus correspondientes tablas de base de datos. El propósito de usar
Hibernate en este proyecto es reducir el tiempo de desarrollo y evitar el uso
de SQL dentro del código, así como evitar conexiones con JDBC, de manera
de programar ciento por ciento orientado a objetos.
3.4.3 Java. El programa de Java puede ejecutarse en cualquier máquina o
plataforma. El lenguaje fue diseñado con las siguientes características en
mente: Simple, familiar, robusto, seguro, portable, etc.
3.4.4 Perl. Este lenguaje combina en forma concisa las mejores

características de lenguajes como C, sed, awk y sh. En general, es posible
reducir extensos programas escritos en C a pocas líneas de código de un
programa PERL, con la ventaja adicional de que corren sin cambio sobre casi
cualquier plataforma existente, lo que convierte a PERL en el lenguaje ideal
para desarrollo de prototipos y aplicaciones robustas 100% portables.
Página 44 de 82
IV. Metodología
En este capitulo se revisan los procedimientos a seguir para la instalación y

configuración del paquete WDS y GAMMU, así como también el procedimiento para
instalar y configurar el prototipo del sistema WDS trabajando como un administrador
virtual de un equipo servidor, dentro de una red local. Esto se realiza con soporte
para el sistema operativo Linux en sus distribuciones RedHat y SUSE v. 9.2
4.1 Estructura de Carpetas y archivos del sistema WDS
La estructura de carpetas y archivos del proyecto WDS es mostrado en la figura 4.1.

En la carpeta installers, se muestra el instalador de proyecto GAMMU version
1.08.15 sobre el cual se monta el proyecto WDS. Las carpetas del sistema se
encuentran dentro de la carpeta WDS. En la carpeta lib pueden apreciarse las
librerias del motor de persistencia hibernate y las de la base de datos mysql en los
archivos hibernate3.jar y mysql-conector-java-3.1.8-bin.jar, asi mismo pueden verse
las otras librerias, las cuales son requeridas para el correcto funcionamiento de la
librería de hibernate. En la carpeta bin se muestran los archivos ejecutables
clientStart.sh y i2ic.pl, los cuales corresponden a los aplicativos para atender las
solicitudes de comandos entrantes y el aplicativo que trabaja como un daemon, que
es el que traslada los mensajes entrantes a solicitudes de comandos
respectivamente. La carpeta classes contiene los archivos de correspondencia
(InboxCommand.hbm.xml, Outbox.hbm.xml) entre las clases de la capa de dominio y
sus tablas de datos, también se encuentra el archivo hibernate.cfg.xml en el que se
definen los parámetros de conexión y configuración para que hibernate pueda
conectarse a la base de datos; también se encuentran las clases que implementan la
capa de dominio, datos y negocio del sistema WDS. Son las clases:
• sv.edu.ufg.maestria.wds.negocio.Cliente
• sv.edu.ufg.maestria.wds.negocio.Administrador
las encargadas de ejecutar la lógica de un administrador virtual para ejecutar el
comando solicitado y obtener una salida desde esta ejecución, enviando un mensaje
Página 45 de 82
hacia el administrador real en respuesta a la ejecución del comando solicitado. Los

comandos disponibles por defecto en el sistema se encuentran en la carpeta scripts,
estos son scripts auto ejecutables, las tareas que realizan son sencillas y su único
objetivo es el de comprobar el buen funcionamiento del sistema. En la carpeta log se
crean archivos nombrados como log_<commandID>.txt en los cuales se van
almacenando información de salida obtenida desde cada comando de usuario
ejecutado. En la carpeta src se encuentran los archivos fuentes del aplicativo java, si
alguno o varios de estos archivos necesitara modificarse por alguna razón, debe
utilizarse el script compile.sh para compilar nuevamente la aplicación, los archivos
colocados en la carpeta base del proyecto (wds-project-1.0) se describen en la tabla
4.1.
Tabla 4.1, Aplicaciones y archivos de configuración del proyecto WDS y GAMMU

Nombre Descripción
gammu.sh Script para iniciar el aplicativo gammu con funcionalidad smsd
setup.sh Script para instalar el proyecto WDS
i2icd Daemon que convierte mensajes entrantes en comandos
wds_smsd.sql Script para la creación de los objetos del esquema smsd
smsdrc Archivo de configuración de GAMMU y MySQL
Página 46 de 82
Fig. 4.1, Estructura de carpetas y archivos del proyecto WDS
Página 47 de 82
4.2 Requisitos del sistema WDS
Los requisitos para que el sistema WDS pueda ser instalado y configurado
correctamente son mostrados en la tabla 4.2.
Tabla 4.2, Listado de paquetes necesarios previo a la implementación del sistema

WDS
Nombre de paquete Descripción
JRE versión 1.5.0_12 Instalado como parte funcional del sistema

operativo.
MySQL Server Versión 14.7 Instalado y configurado para ser iniciado

cada vez que el equipo es encendido.
Perl 5.8.5 Intérprete de Perl 5.8.5 o mayor, instalado

junto con librerías perl, DBD y MySQL.
4.3 Pasos a seguir para la instalación y configuración del proyecto WDS y de
GAMMU
Extracción del archivo wds-project-1.0.tar.gz

# tar -xvzf wds-project-1.0.tar.gz
Cambiarse a la carpeta wds-project/installers y extraer el archivo gammu-

1.08.15.tar.gz
# tar -xvzf gammu-1.08.15.tar.gz
Cambiarse a la carpeta de instalación de gammu:
# cd gammu-1.08.15
Configurar el constructor de GAMMU para nuestro sistema operativo y
construir los binarios de GAMMU
Página 48 de 82
# . /configure
# make
# make shared
Instalar los binarios en las carpetas del sistema operativo
# make install
Instalar las librerias de GAMMU
# make installshared
Configurar las librerías de GAMMU dentro del sistema operativo
# vi /etc/ld.so.conf
# /sbin/ldconfig
Modificar el archivo wds-project/smsdrc de acuerdo a sus requerimientos
# vi ../../smsdrc
Para este caso en el que se utiliza el móvil Siemmens S55, la modificación del
contenido del archivo smsdrc es la que se muestra líneas abajo, observe que
en este, se encuentran las secciones de configuración de GAMMU con la
funcionalidad smsd activada.
[gammu]
port = /dev/ttyS0
connection = AT
logfile = gammulog
logformat = textall
use_locking = yes
# Los números de teléfonos incluidos en esta sección serán los unicos autorizados
# de interactuar con el sistema WDS en el envió de comandos y recepción de mensajes
[include_numbers]
number1 = 503.....
number2 = 503.....
number3 = 503.....
# Así mismo puede descomentar la siguiente sección y agregar números de teléfonos en

# esta para denegar todos los mensajes recibidos por GAMMU desde teléfonos indeseables.
#[exclude_numbers]
#number1 = 1234
# Sustituya las elipses en esta sección escribiendo su propio usuario y clave de conexión a
# la base de datos MySQL.
[smsd]
PIN = 0000
logfile = smsdlog
commtimeout = 1
sendtimeout = 10
#--------------------------- smsd & MySQL configuration
user = ......
password = .....
pc = localhost
database = smsd
Página 49 de 82
Si el valor de la variable LANG no debería ser es_ES utilice el editor de texto

plano vi, para modificar el script del shell gammu.sh
# vi ./gammu.sh
El contenido de gammu.sh es el siguiente
#!/bin/sh
export LANG=es_ES
/usr/local/bin/gammu --smsd MYSQL /etc/smsdrc
Ejecutar el script del shell setup.sh para continuar con la instalación y

configuración del proyecto WDS
# ./setup.sh
4.4 Scripts del sistema WDS
Una vez realizada la configuración anterior y la ejecución del aplicativo setup.sh el

daemon <install_dir>/WDS/bin/i2icd.pl es iniciado, a la vez que se realizó la
configuración de iniciar este daemon cada vez que se de el proceso de inicio del
sistema operativo en el runtime level 5 (init 5).
El contenido de este daemon i2icd.pl es el siguiente:
use DBI;
use POSIX qw(setsid);
my $install_dir = `cat /etc/wds.dir`.'/WDS';

chop($install_dir);
my $dsn = 'DBI:mysql:smsd:localhost';
my ($db_user_name, $db_password) = split (`gunzip -c $install_dir/WDS/bin/wds`,'\n');
my $sql = '';
my (@inbox_regs) = ();
my (@command_regs) = ();
my (@segments) = ();
my ($i, $j) = (0, 0);
my ($Id, $TextDecoded, $processed, $SenderNumber, $SMSCNumber, $ReceivingDateTime) = (0, '', '', '', '', '');
my ($ScriptName, $ScriptLocation, $MaxSecondsTime) = ('', '', '');
my ($code, $status) = ('', '', '');
chdir $install_dir.'/bin';
umask 0;
defined( my ($pid, $ppid) = fork ) or die "Can't fork: $! ";
ècho $pid >/var/run/i2ic.pid`;
exit if $pid;
setsid or die "Can't start a new session: $!";
while(1) {
sleep(5);
# check for new messages

# getting all register from inbox
$sql = "select ID, TextDecoded, processed, SenderNumber, SMSCNumber, ReceivingDateTime
Página 50 de 82
from inbox where processed = 'false' order by 5 asc";
@inbox_regs = &query($sql);
$i = 0;
while ($i < ($#inbox_regs+1)) {
($Id, $TextDecoded, $processed, $SenderNumber, $SMSCNumber, $ReceivingDateTime) =
@{$inbox_regs[$i]};
# updating to true all unprocessed registers

$sql = "update inbox set processed = 'true' where ID = $Id";
&myDo($sql);
# the command has the following structure

# :code
@segments = split /:/, $TextDecoded;

$code = $segments[$#segments];
$code = $code ? $code : "0"; # code == 0 => meaning that error code was received
$sql = "select ScriptName, ScriptLocation, MaxSecondsTime from command where Code = '$code'";
@command_regs = &query($sql);
$j = 0;
while ($j < ($#command_regs + 1)){
($ScriptName, $ScriptLocation, $MaxSecondsTime) = @{$command_regs[$j]};
$j++;
}
if (!length($ScriptName)) {
$ScriptName = 'Error';
$ScriptLocation = '$install_dir/scripts';
}
$sql = "insert into inboxCommand (ScriptName, ScriptLocation, SenderNumber, MaxSecondsTime,

SMSCNumber, IdInbox) values ('$ScriptName', '$ScriptLocation', '$SenderNumber',
'$MaxSecondsTime','$SMSCNumber', '$Id')";
&myDo($sql);
$i++;
open STDOUT, '>$install_dir/log/salida_'.$Id.'.txt' or die "Can't write to salida_$Id.txt:$!";

open STDERR, '>$install_dir/log/salida_'.$Id.'.txt' or die "Can't write to salida_$Id.txt:$!";
$status = `$install_dir/bin/clientStart.sh $Id >>$install_dir/log/salida_$Id.txt`;
exit(0);
sub query
{
my $dbh = DBI->connect($dsn, $db_user_name, $db_password, { RaiseError => 1, AutoCommit => 0 });
my $sth = '';
my $sql = @_[0];
my (@result) = ();
$sth = $dbh->prepare($sql);
$sth->execute;
while (my @res = $sth->fetchrow_array())

{
push(@result, [@res]);
}
$sth->finish();
$dbh->disconnect;
Página 51 de 82
return @result;
}
sub myDo {
my $sql = @_[0];
my $dbh = DBI->connect($dsn, $db_user_name, $db_password, { RaiseError => 1, AutoCommit => 0 });
$dbh->do($sql);
$dbh->disconnect;
}
El objetivo principal de este daemon es convertir los mensajes recibidos en la tabla

inbox a registros de comandos en la tabla inboxCommand, para realizar esto, este se
mantiene iterando en un lazo infinito y para cada iteracion se queda en estado ocioso
5 segundos para luego conectarse a la base de datos smsd para revisar por nuevos
mensajes (Aquellos mensajes que tienen un valor de 'false' en la columna processed
de la tabla inbox) y para cada mensaje satisfactoriamente procesado inicia el
aplicativo java <install_dir>/WDS/bin/clientStart.sh, pasando a este aplicativo como
argumento el identificador del nuevo comando insertado en la tabla inboxCommand
que es el comando que se deberá procesar.
El código fuente del archivo ejecutable clientStart.sh es mostrado a continuación:
#!/bin/bash
#
# prj es la carpeta actual de instalación del proyecto
#
prj=`cat /etc/wds.dir`.'/WDS'
export prj
# CLASSPATH define las librerias necesarias por el aplicativo WDS

#
CLASSPATH=.:$prj/lib/hibernate3.jar:$prj/lib/mysql-connector-java-3.1.8-bin.jar:$prj/lib/swarmcache-1.0rc2.jar:$prj/lib/antlr-
2.7.6.jar:$prj/lib/asm.jar:$prj/lib/asm-attrs.jar:$prj/lib/c3p0-0.9.0.jar:$prj/lib/cglib-2.1.3.jar:$prj/lib/commons-collections-
2.1.1.jar:$prj/lib/commons-logging-1.0.4.jar:$prj/lib/concurrent-1.3.2.jar:$prj/lib/connector.jar:$prj/lib/dom4j-
1.6.1.jar:$prj/lib/ehcache-1.2.jar:$prj/lib/jaas.jar:$prj/lib/jboss-cache.jar:$prj/lib/jboss-common.jar:$prj/lib/jboss-
jmx.jar:$prj/lib/jboss-system.jar:$prj/lib/jdbc2_0-stdext.jar:$prj/lib/jgroups-2.2.8.jar:$prj/lib/jta.jar:$prj/lib/log4j-
1.2.11.jar:$prj/lib/oscache-2.1.jar:$prj/lib/proxool-0.8.3.jar:$prj/classes
export CLASSPATH
# Se ejecuta el aplicativo que procesara el nuevo mensaje recibido desde un cliente remoto
#
# $1 es el identificador del comando a ser procesado
#
java sv.edu.ufg.maestria.wds.negocio.Cliente $1
En este script se puede observar que se definen variables de entorno y luego la clase
sv.edu.ufg.maestria.wds.negocio.Cliente es ejecutada pasándole como argumento el
identificador del comando a procesar; también se observa que la capa de negocio de
la aplicación java interactúa con el daemon i2ic.pl como su única capa de
Página 52 de 82
presentación el cual estaría solicitando servicios de procesamientos de comandos

cada vez que nuevos mensajes sean recibidos y almacenados como peticiones de
comandos en la tabla inboxCommand.
Los objetos de la base de datos MySQL para el esquema smsd son creados a partir
del siguiente archivo script:
-- MySQL dump 10.9

--
-- Host: localhost Database: smsd
-- ------------------------------------------------------
-- Server version 4.1.12
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;

/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
-- Table structure for table `command`

DROP TABLE IF EXISTS `command`;
CREATE TABLE `command` (
Ìd` int(11) NOT NULL auto_increment,
`ScriptName` text,
`ScriptLocation` text,
`MaxSecondsTime` int(11) default NULL,
`Code` varchar(45) NOT NULL default '',
`Description` text,
PRIMARY KEY (Ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
-- Dumping data for table `command`

/*!40000 ALTER TABLE `command` DISABLE KEYS */;
LOCK TABLES `command` WRITE;
INSERT INTO `command` VALUES
(1,'Error','WDS/scripts',10,'0',NULL),(2,'Saludo','WDS/scripts',10,'1',NULL),(3,'Ping','WDS/scripts',10,'2',NULL);
UNLOCK TABLES;
/*!40000 ALTER TABLE `command` ENABLE KEYS */;
-- Table structure for table `daemons`

DROP TABLE IF EXISTS `daemons`;
CREATE TABLE `daemons` (
`Start` text NOT NULL,
Ìnfo` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
-- Dumping data for table `daemons`

/*!40000 ALTER TABLE `daemons` DISABLE KEYS */;
LOCK TABLES `daemons` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE `daemons` ENABLE KEYS */;
--
-- Table structure for table `gammu`
DROP TABLE IF EXISTS `gammu`;
CREATE TABLE `gammu` (
Página 53 de 82
`Version` tinyint(4) NOT NULL default '0'

--
-- Dumping data for table `gammu`
/*!40000 ALTER TABLE `gammu` DISABLE KEYS */;
LOCK TABLES `gammu` WRITE;
INSERT INTO `gammu` VALUES (7);
UNLOCK TABLES;
/*!40000 ALTER TABLE `gammu` ENABLE KEYS */;
--
-- Table structure for table ìnbox`
DROP TABLE IF EXISTS ìnbox`;
CREATE TABLE ìnbox` (
ÙpdatedInDB` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`ReceivingDateTime` timestamp NOT NULL default '0000-00-00 00:00:00',
`Text` text NOT NULL,
`SenderNumber` varchar(20) NOT NULL default '',
`Coding` enum('Default_No_Compression','Unicode_No_Compression','8bit','Default_Compression','Unicode_Compression')
NOT NULL default '8bit',
ÙDH` text NOT NULL,
`SMSCNumber` varchar(20) NOT NULL default '',
`Class` int(11) NOT NULL default '-1',
`TextDecoded` varchar(160) NOT NULL default '',
ÌD` int(11) unsigned NOT NULL auto_increment,
`RecipientID` text NOT NULL,
`Processed` enum('false','true') NOT NULL default 'false',
UNIQUE KEY ÌD` (ÌD`)
--
-- Dumping data for table ìnbox`
/*!40000 ALTER TABLE ìnbox` DISABLE KEYS */;
LOCK TABLES ìnbox` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE ìnbox` ENABLE KEYS */;
--
-- Table structure for table ìnboxCommand`
DROP TABLE IF EXISTS ìnboxCommand`;
CREATE TABLE ìnboxCommand` (
Ìd` int(11) NOT NULL auto_increment,
`ScriptName` text NOT NULL,
`MaxSecondsTime` int(11) NOT NULL default '3600',
`SenderNumber` varchar(20) default NULL,
`SMSCNumber` varchar(20) default NULL,
`Status` varchar(20) default 'NoLeido',
`ScriptLocation` text,
ÌdInbox` int(11) default NULL,
PRIMARY KEY (Ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
--
-- Dumping data for table ìnboxCommand`
/*!40000 ALTER TABLE ìnboxCommand` DISABLE KEYS */;
LOCK TABLES ìnboxCommand` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE ìnboxCommand` ENABLE KEYS */;
--
-- Table structure for table òutbox`
DROP TABLE IF EXISTS òutbox`;
CREATE TABLE òutbox` (
ÌnsertIntoDB` timestamp NOT NULL default '0000-00-00 00:00:00',
`SendingDateTime` timestamp NOT NULL default '0000-00-00 00:00:00',
`Text` text,
`DestinationNumber` varchar(20) NOT NULL default '',
default '8bit',
ÙDH` text,
Página 54 de 82
`Class` int(11) default '-1',

ÌD` int(11) unsigned NOT NULL auto_increment,
`MultiPart` enum('false','true') default 'false',
`RelativeValidity` int(11) default '-1',
`SenderID` text,
`SendingTimeOut` timestamp NULL default '0000-00-00 00:00:00',
`DeliveryReport` enum('default','yes','no') default 'default',
`CreatorID` text NOT NULL,
ÌNSERTLNDB` datetime default NULL,
--
-- Dumping data for table òutbox`
/*!40000 ALTER TABLE òutbox` DISABLE KEYS */;
LOCK TABLES òutbox` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE òutbox` ENABLE KEYS */;
--
-- Table structure for table òutbox_multipart`
DROP TABLE IF EXISTS òutbox_multipart`;
CREATE TABLE òutbox_multipart` (
`Text` text,
default '8bit',
ÙDH` text,
`Class` int(11) default '-1',
`TextDecoded` varchar(160) default NULL,
ÌD` int(11) unsigned NOT NULL default '0',
`SequencePosition` int(11) NOT NULL default '1'
--
-- Dumping data for table òutbox_multipart`
/*!40000 ALTER TABLE òutbox_multipart` DISABLE KEYS */;
LOCK TABLES òutbox_multipart` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE òutbox_multipart` ENABLE KEYS */;
--
-- Table structure for table `pbk`
DROP TABLE IF EXISTS `pbk`;
CREATE TABLE `pbk` (
`GroupID` int(11) NOT NULL default '-1',
`Name` text NOT NULL,
`Number` text NOT NULL
--
-- Dumping data for table `pbk`
/*!40000 ALTER TABLE `pbk` DISABLE KEYS */;
LOCK TABLES `pbk` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE `pbk` ENABLE KEYS */;
--
-- Table structure for table `pbk_groups`
DROP TABLE IF EXISTS `pbk_groups`;
CREATE TABLE `pbk_groups` (
`Name` text NOT NULL,
ÌD` int(11) NOT NULL auto_increment,
--
-- Dumping data for table `pbk_groups`
/*!40000 ALTER TABLE `pbk_groups` DISABLE KEYS */;
LOCK TABLES `pbk_groups` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE `pbk_groups` ENABLE KEYS */;
Página 55 de 82
--
-- Table structure for table `phones`
DROP TABLE IF EXISTS `phones`;
CREATE TABLE `phones` (
ÌD` text NOT NULL,
`TimeOut` timestamp NOT NULL default '0000-00-00 00:00:00',
`Send` enum('yes','no') NOT NULL default 'no',
`Receive` enum('yes','no') NOT NULL default 'no',
ÌMEI` text NOT NULL,
`Client` text NOT NULL
--
-- Dumping data for table `phones`
/*!40000 ALTER TABLE `phones` DISABLE KEYS */;
LOCK TABLES `phones` WRITE;
INSERT INTO `phones` VALUES ('','2006-11-13 20:42:35','2006-11-13 16:52:13','2006-11-13
20:42:45','yes','yes','351083521503632','Gammu 1.08.15, Linux, kernel 2.6.8-24-default, gcc 3.3');
UNLOCK TABLES;
/*!40000 ALTER TABLE `phones` ENABLE KEYS */;
--
-- Table structure for table `sentitems`
DROP TABLE IF EXISTS `sentitems`;
CREATE TABLE `sentitems` (
`SendingDateTime` timestamp NOT NULL default '0000-00-00 00:00:00',
`DeliveryDateTime` timestamp NOT NULL default '0000-00-00 00:00:00',
`Text` text NOT NULL,
`DestinationNumber` varchar(20) NOT NULL default '',
NOT NULL default '8bit',
ÙDH` text NOT NULL,
`SMSCNumber` varchar(20) NOT NULL default '',
`Class` int(11) NOT NULL default '-1',
ÌD` int(11) unsigned NOT NULL default '0',
`SenderID` text NOT NULL,
`SequencePosition` int(11) NOT NULL default '1',
`Status`
enum('SendingOK','SendingOKNoReport','SendingError','DeliveryOK','DeliveryFailed','DeliveryPending','DeliveryUnknown','Error'
) NOT NULL default 'SendingOK',
`StatusError` int(11) NOT NULL default '-1',
`TPMR` int(11) NOT NULL default '-1',
`RelativeValidity` int(11) NOT NULL default '-1',
`CreatorID` text NOT NULL
--
-- Dumping data for table `sentitems`
/*!40000 ALTER TABLE `sentitems` DISABLE KEYS */;
LOCK TABLES `sentitems` WRITE;
UNLOCK TABLES;
/*!40000 ALTER TABLE `sentitems` ENABLE KEYS */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
Página 56 de 82
El script anterior es ejecutado por el gestor de base de datos a solicitud del instalador
del proyecto WDS (setup.sh).
4.5 Aplicación Java
A continuación se detallan las clases creadas en la plataforma Java y que son
utilizadas para ejecutar los comandos solicitados desde el administrador físico y
enviarle la respuesta.
El procesamiento de los comandos, se realiza por medio de la clase
sv.edu.ufg.maestria.wds.negocio.Cliente; como podrá observarse la estructuración
de esta aplicación se ha desarrollado haciendo uso del modelo de programación en
capas, en la siguiente figura se muestra el diagrama UML de esta aplicación.
En la capa de dominio se han colocado las clases que son persistidas en la base de
datos a través del motor de persistencia hibernate, y que son los objetos que las
clases en los paquetes de datos y negocio mueven a través de la aplicación.
Página 57 de 82
A continuación se muestra el código fuente de la clase

sv.edu.ufg.maestria.wds.dominio.InboxCommand
package sv.edu.ufg.maestria.wds.dominio;
import sv.edu.ufg.maestria.wds.datos.*;
public class InboxCommand {
private int id;

private String scriptName;
private String status;
private int idInbox;
private int maxSecondsTime;
private String senderNumber;
Página 58 de 82
private String sMSCNumber;

private String scriptLocation;
public static InboxCommand obtener(String id){

DAOInboxCommand dic = new DAOInboxCommand();
InboxCommand ic = dic.obtener(id);
if (ic == null)
return null;
else
return ic;
public int getId() {

return id;
}
public void setId(int id) {

this.id = id;
}
public int getIdInbox() {
return idInbox;
}
public void setIdInbox(int idInbox) {

this.idInbox = idInbox;
}
public int getMaxSecondsTime() {
return maxSecondsTime;
}
public void setMaxSecondsTime(int maxSecondsTime) {

this.maxSecondsTime = maxSecondsTime;
}
public String getScriptLocation() {

return scriptLocation;
}
public void setScriptLocation(String scriptLocation) {

this.scriptLocation = scriptLocation;
}
public String getScriptName() {

return scriptName;
}
public void setScriptName(String scriptName) {

this.scriptName = scriptName;
}
public String getSenderNumber() {

return senderNumber;
}
public void setSenderNumber(String senderNumber) {

this.senderNumber = senderNumber;
}
public String getsMSCNumber() {

return sMSCNumber;
}
public void setsMSCNumber(String number) {

sMSCNumber = number;
}
public String getStatus() {

return status;
}
Página 59 de 82
public void setStatus(String status) {

this.status = status;
}
}
El código fuente de la clase sv.edu.ufg.maestria.wds.dominio.Outbox es

mostrado a continuación:
package sv.edu.ufg.maestria.wds.dominio;
import sv.edu.ufg.maestria.wds.datos.*;
import java.sql.Timestamp;
public class Outbox {
private int id;

private Timestamp updatedInDb;
private Timestamp inserlnDB;
private Timestamp sendingDateTime;
private String text;
private String destinationNumber;
private String coding;
private String udh;
private int CLASS;
private String textDecoded;
private boolean multipart;
private int relativeValidity;
private String senderId;
private Timestamp sendingTimeOut;
private String deliveryReport;
private String creatorId;
public String guardarNuevo(Outbox o){

DAOOutbox daoOutbox = new DAOOutbox();
return daoOutbox.guardarNuevo(o);
}
private String convertirCadenaAHexa(String st){

String strHex = new String("");
for(int i = 0; i<st.length(); i++)
strHex += Integer.toHexString( (int)st.charAt( i ) );
return strHex;
}
public void llenarValores(InboxCommand ic, String resultadoDelComando){
java.util.Date date1 = new java.util.Date ( ) ;

long time1 = date1.parse ( date1.toString() ) ;
this.setText(this.convertirCadenaAHexa(resultadoDelComando));
this.setTextDecoded(resultadoDelComando);
this.setDestinationNumber(ic.getSenderNumber());
this.setCoding("8bit");
this.setCreatorId(" ");
this.setRelativeValidity(-1);
this.setCLASS(-1);
this.setMultipart(false);
this.setDeliveryReport("default");
this.setSendingTimeOut(new java.sql.Timestamp(time1));
}
public String getCoding() {

return coding;
}
public void setCoding(String coding) {

this.coding = coding;
}
Página 60 de 82
public String getCreatorId() {

return creatorId;
}
public void setCreatorId(String creatorId) {

this.creatorId = creatorId;
}
public String getDeliveryReport() {

return deliveryReport;
}
public void setDeliveryReport(String deliveryReport) {

this.deliveryReport = deliveryReport;
}
public String getDestinationNumber() {

return destinationNumber;
}
public void setDestinationNumber(String destinationNumber) {

this.destinationNumber = destinationNumber;
}
public int getId() {

return id;
}
public void setId(int id) {

this.id = id;
}
public Timestamp getInserlnDB() {

return inserlnDB;
}
public void setInserlnDB(Timestamp inserlnDB) {

this.inserlnDB = inserlnDB;
}
public boolean isMultipart() {

return multipart;
}
public void setMultipart(boolean multipart) {

this.multipart = multipart;
}
public int getRelativeValidity() {

return relativeValidity;
}
public void setRelativeValidity(int relativeValidity) {

this.relativeValidity = relativeValidity;
}
public String getSenderId() {

return senderId;
}
public void setSenderId(String senderId) {

this.senderId = senderId;
}
public Timestamp getSendingDateTime() {

return sendingDateTime;
}
public void setSendingDateTime(Timestamp sendingDateTime) {

this.sendingDateTime = sendingDateTime;
}
Página 61 de 82
public Timestamp getSendingTimeOut() {

return sendingTimeOut;
}
public void setSendingTimeOut(Timestamp sendingTimeOut) {

this.sendingTimeOut = sendingTimeOut;
}
public String getText() {

return text;
}
public void setText(String text) {

this.text = text;
}
public String getTextDecoded() {

return textDecoded;
}
public void setTextDecoded(String textDecoded) {

this.textDecoded = textDecoded;
}
public String getUdh() {

return udh;
}
public void setUdh(String udh) {

this.udh = udh;
}
public Timestamp getUpdatedInDb() {

return updatedInDb;
}
public void setUpdatedInDb(Timestamp updatedInDb) {

this.updatedInDb = updatedInDb;
}
public int getCLASS() {

return CLASS;
}
public void setCLASS(int class1) {

CLASS = class1;
}
}
En la capa de datos se desarrollan las clases encargadas de persistir en la

base de datos objetos de la capa de dominio a través del motor de
persistencia de hibernate, en esta se implementan funcionalidades como
leer y actualizar objetos.
El código fuente de las clases

sv.edu.ufg.maestria.wds.DAOInboxCommand y DAOOutbox es mostrado a
continuación:
package sv.edu.ufg.maestria.wds.datos;
import sv.edu.ufg.maestria.wds.dominio.*;
Página 62 de 82
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import java.util.List;
public class DAOInboxCommand {

public InboxCommand obtener(String id){
try
{ SessionFactory sessionFactory = new
Configuration().configure().buildSessionFactory();
Session sesion = sessionFactory.openSession();
List inboxCommand = sesion.createQuery("from InboxCommand as inboxCommand
where inboxCommand.status='NoLeido' and inboxCommand.idInbox=" + id).list();
sesion.close();
if (inboxCommand.isEmpty()){
return null;
}else{
InboxCommand ic = (InboxCommand)inboxCommand.get(0);
ic.setStatus("Leido");
this.actualizar(ic);
return ic;
}
}catch (Exception ex)
{
return null;
}
}
public void actualizar(InboxCommand ic){

SessionFactory sessionFactory = new
Configuration().configure().buildSessionFactory();
sesion.update(ic);
sesion.flush();
sesion.close();
}
package sv.edu.ufg.maestria.wds.datos;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
public class DAOOutbox {

public String guardarNuevo(Outbox o){
try{
SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();

sesion.save(o);
sesion.flush();
sesion.close();
}
catch(Exception e){
return e.getCause().getLocalizedMessage() ;
}
}
return null;
}
Página 63 de 82
En la capa de negocio se han colocado las clases encargadas de definir la

lógica de ejecución del aplicativo, esta interactúa con el administrador real
a través del daemon i2ic al momento de ingresar nuevas solicitudes de
comandos, el código fuente de las clases de esta capa se presenta a
continuación:
package sv.edu.ufg.wds.negocio;
import java.io.*;
import sv.edu.ufg.wds.dominio.*;
public class Administrador {
public String ejecutarComando(String comando){
try
{
if(comando == null){
comando = "/scripts/Error";
}
Process p = Runtime.getRuntime().exec (comando);
InputStream is = p.getInputStream();
BufferedReader br = new BufferedReader (new InputStreamReader (is));
return br.readLine();
}
catch (Exception e)
{
return e.getMessage();
}
}
public String enviarResultado(Outbox o){

Outbox outbox = new Outbox();
return outbox.guardarNuevo(o);
}
public InboxCommand leerComando(String id) {

InboxCommand ic = InboxCommand.obtener(id);
return ic;
}
package sv.edu.ufg.maestria.wds.negocio;
public class Cliente {

public static void main(String[] args) {
if ( args[0].length() > 0){

Administrador a = new Administrador();
InboxCommand ic = a.leerComando(args[0]);
Outbox o = new Outbox();
String resultadoDelComando =
a.ejecutarComando(ic.getScriptLocation()+"/"+ic.getScriptName());
o.llenarValores(ic, resultadoDelComando);
System.out.print( a.enviarResultado(o));
}else{
System.out.print("ERR: NO ARGS");
}
}
}
Página 64 de 82
Hibernate necesita un archivo de configuración general llamado

hibernate.cfg.xml y un archivo de correspondencia por cada clase que
deba ser persistida en la base de datos, en este caso los archivos de
correspondencia InboxCommand.hbm y Outbox.hbm.xml corresponden a
las clases InboxCommand y Outbox respectivamente. El contenido de
estos archivos es mostrado a continuación.
Archivo hibernate.cfg.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="hibernate.connection.url">jdbc:mysql://localhost/smsd</property>
<property name="hibernate.connection.username"></property>
<property name="hibernate.connection.password"></property>
<property name="hibernate.connection.pool_size">10</property>
<property name="show_sql">true</property>
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="hibernate.hbm2ddl.auto">update</property>

<mapping resource="Outbox.hbm.xml"/>
<mapping resource="InboxCommand.hbm.xml"/>
</session-factory>
</hibernate-configuration>
Archivo InboxCommand.hbm.xml
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="sv.edu.ufg.maestria.wds.dominio.InboxCommand" table="inboxCommand">
<id name="id" type="integer" column="ID" >
</id>
<property name="scriptName">
<column name="ScriptName" />
</property>
<property name="idInbox">
<column name="IDINBOX" />
</property>
<property name="status">
<column name="STATUS" />
</property>
<property name="maxSecondsTime">
<column name="MaxSecondsTime" />
</property>
<property name="senderNumber">
<column name="SenderNumber" />
Página 65 de 82
</property>
<property name="sMSCNumber">
<column name="SMSCNumber" />
</property>
<property name="scriptLocation">
<column name="ScriptLocation" />
</property>
</class>
Archivo Outbox.hbm.xml
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="sv.edu.ufg.maestria.wds.dominio.Outbox" table="outbox">
<id name="id" type="integer" column="ID" >
</id>
<property name="updatedInDb">
<column name="UPDATEDINDB" />
</property>
<property name="inserlnDB">
<column name="INSERTLNDB"/>
</property>
<property name="sendingDateTime">
<column name="SENDINGDATETIME"/>
</property>
<property name="text">
<column name="TEXT"/>
</property>
<property name="destinationNumber">
<column name="DESTINATIONNUMBER"/>
</property>
<property name="coding">
<column name="CODING"/>
</property>
<property name="udh">
<column name="UDH"/>
</property>
<property name="CLASS">
<column name="CLASS"/>
</property>
<property name="textDecoded">
<column name="TEXTDECODED"/>
</property>
<property name="multipart">
<column name="MULTIPART"/>
</property>
<property name="relativeValidity">
<column name="RELATIVEVALIDITY"/>
</property>
<property name="senderId">
<column name="SENDERID"/>
</property>
<property name="sendingTimeOut">
<column name="SENDINGTIMEOUT"/>
</property>
<property name="deliveryReport">
<column name="DELIVERYREPORT"/>
</property>
<property name="creatorId">
<column name="CREATORID"/>
</property>
</class>
Página 66 de 82
V. Prototipo y resultados alcanzados
En este capítulo se encuentran los pasos necesarios para usar el prototipo funcional
desarrollado en este proyecto, además se presentan los resultados de las pruebas
realizadas.
Componentes requeridos y sus especificaciones (ver capítulo IV para los pormenores

de la instalación y configuración de WDS):
• Sistema operativo: SUSE Linux 9.2

• Teléfono celular: Siemens s55
• Servidor: PC / Workstation / Server. RAM requerida la mínima demandada
por el sistema operativo, en promedio 512MB. Disco duro 200MB o
superior.
• SW del proyecto WDS: CD de instalación*
o Instalador
o Hibernate: 3.0**
o Proyecto Gammu:1.0**
* Incluidos en el CD de este proyecto, en la carpeta \instaladores

** Configurados automáticamente con el instalador de WDS
Tanto el sistema operativo del servidor como el modelo del celular usado para la
presente implementación pueden variar.
A continuación se detallan los pasos a seguir para experimentar con el prototipo:
Experimento 1: Prueba de instalación.
En esta prueba se enviará un mensaje de texto con el contenido siguiente :1 como se

muestra en la imagen.
Página 67 de 82
Esto representa al comando etiquetado con el caracter uno y que

está incluido como parte de los comandos por defecto del proyecto
WDS. El comando :1 tiene la siguiente estructura
: Es la secuencia de escape, es decir una letra reservada, que
indica el inicio del comando
C Representa el o los caracteres que identifican el comando a
ejecutar. No necesariamente numérico.
La estructura anterior, indica que habrá que tomar el carácter 1 y
buscarlo en la tabla de comandos de la base de datos, en el esquema smsd de
mysql. En este caso, el comando 1 está asociado a un archivo Script llamado
saludo.sh, cuyo contenido es el siguiente:
Cuando el mensaje sea recibido por el celular conectado al servidor, el demonio

smsd lo leerá y lo colocará en la tabla Inbox. Un siguiente demonio i2ic, lo colocará
en la tabla InboxCommand, habiendo ya detectado cuál es el comando y además
cuál es el archivo de script correspondiente. I2ic ejecutará el programa administrador
en Java, el cual ejecuta en el sistema operativo el comando correspondiente y
captura la salida del comando, enviándola como mensaje de salida a la tabla Outbox.
El celular que ha enviado el comando :1 deberá estar recibiendo de
inmediato el resultado de la aplicación del script, es decir, en su
pantalla se debe leer SALUDOS DESDE WDS
Con esto se puede concluir que todo el sistema está bien instalado y
configurado apropiadamente.
A partir de este punto, se podrán crear todos los scripts de acuerdo
a la necesidad del administrador.
A manera de ejemplo, se han adicionado los siguientes comandos, que estarán

activos inmediatamente se haga la instalación:
Página 68 de 82
Código Nombre Script Acción

:0 Error.sh Respuesta a un código no registrado
:1 Saludo.sh Envía texto de saludo desde el Server
:2 Ping.sh Ejecuta un ping a localhost
Experimento 2: Detener del servicio http de apache

En esta prueba se enviará un mensaje de texto con el contenido siguiente
:webStop
El resultado esperado es que el servidor detenga el servicio web http.
Dado que este comando no existe, habrá que crearlo. Primero se creará un script en
algún lenguaje de programación, en este caso, bash.
El script podrá llamarse apache_stop el cual se colocará en la carpeta scripts del
proyecto WDS
El contenido del archivo de script apache_stop es el siguiente:
#!/bin/bash
/etc/init.d/apache2 stop | grep done
Para ingresar el comando al sistema WDS se insertará un renglón en la tabla

Command, por medio del sql siguiente
Insert into command values (’apache_stop’, ‘/root/WDS/scripts’, 10, ‘webStop’)
Desde el celular del administrador físico, se enviará un mensaje al celular colocado

en el servidor, con el mensaje :wwwStop
Una vez recibido el mensaje de respuesta desde el servidor, se debe verificar que el
servicio Web está detenido, dándose por finalizada con éxito la presente prueba.
Página 69 de 82
Dadas las anteriores pruebas se establece que:

• Se ha creado un mecanismo fácil, económico y seguro para poder controlar un
servidor desde un teléfono celular por medio de mensajes cortos.
• La exposición del control remoto no se limita a aplicaciones de control de
servidor, sino más bien puede ser un inicio para la explotación comercial de
interacciones desde celular a otra máquina, la cual puede contener contacto
con otros servidores (Web Services) o con otros mecanismos o dispositivos.
Por ejemplo un corredor de bolsa, puede enviar el mensaje :precioAccion
cliente=ufg el cual le retornaría el precio de las acciones en este instante en la
bolsa de valores. Una aerolínea podría poner el servicio de confirmación del
vuelo por medio del mensaje :confirm reserva=12345. Consultar por un trámite
en hacienda :renta nit=0614-130368-004-3, tramite de su crédito en su banco
:credito cliente=12345, encuestas de opinión :voto 2 y así un innumerable sin
fin de aplicaciones comerciales.
• Por las razones anteriores, se establece por medio de este proyecto, que
muchas de las aplicaciones comerciales que eran reservadas para aquellas
compañías que poseían plantas telefónicas, estarán al alcance del resto de
empresas.
Página 70 de 82
VI. Conclusiones generales
A. Los aportes del proyecto a la sociedad: En la actualidad, no hay forma

en la cual una empresa pueda tomar control remoto de un servidor, de
una manera fácil, segura y económica. Adicionalmente, el hecho de
poder hacer que un servidor corporativo obedezca comandos enviados
desde un celular, podrá iniciar una revolución de innovadores servicios
que las empresas podrán brindar por medio de la interacción desde los
celulares de los clientes.
B. Aportes a la comunidad científica: por medio del presente proyecto, se
ha establecido una comunicación en dos vías, entre celular y la PC. De
ahora en adelante, ambos dispositivos se podrán considerar fusionados
por el proyecto WDS, abriendo la brecha para una nueva generación de
avances científicos sobre este hecho.
C. En concreto los resultados de la investigación, se resumen en que ha
sido posible ejecutar desde un celular, uno o más comandos y recibir a
vuelta de mensaje corto, el resultado de la aplicación de dichos
comandos. Lo anterior establece un dialogo o interacción entre dos
entidades que por su naturaleza están supuestas a no interactuar sin
una planta telefónica.
D. Gracias al presente trabajo de investigación, se han conocido
diferentes proyectos de código abierto, tales como el proyecto GNOKI y
GAMMU, orientados al manejo de celulares desde la PC. Principio que
abrió la brecha para hacer lo opuesto: manejar la PC desde el celular.
Página 71 de 82
Bibliografía
• Villalobos S. Jorge A.
Fundamentos de programación aprendizaje activo basado en casos: un
enfoque moderno usando Java, UML, objetos y eclipse. 1ª Edición, México.
Editorial: Pearson Educación, 2006. 359 p. ISBN 970-26-0846-5.
• Wikipedia
Eclipse Software, 2006. Fecha de consulta: 23/11/2006
http://es.wikipedia.org/wiki/Eclipse_(computaci%C3%B3n)
• Wyke, Allen; Thomas, Donald

Fundamentos de programación en Perl. 1ª Edición, Bogota, Co. Mc Graw Hill,
2002. 514 p. ISBN 958-41-0296-6.
• Wikipedia
Lomboz, [En linea] 2006. Fecha de consulta: 25/11/2007
http://es.wikipedia.org/wiki/Lomboz
• Brian Sam-Bodden
Beginning POJOs: From Novice to Professional. X. Editorial: Apress.
2004. 400 p. ISBN 1590595963.
• James Elliott
Hibernate: a developer's notebook. 1ª E dición, California, USA.
Publicado por O’Reilly media, Inc. 2004. 190 p. ISBN 0596006969.
• Tony Butcher
Sams Teach Yourself MySQL in 21 Days,. 1ª Edición. USA, Sams
Publishing, 2003. 640 p. ISBN 0672323923
• Managing your mobile phone with Gammu and Wammu Directory Services.
Linux Magazine [En línea] Citado: Septiembre de 2005. Disponible en Internet:
http://www.linux-magazine.com/issue/58/Gammu_und_Wammu.pdf
Página 72 de 82
Anexos
En este apartado se detallan las siguientes consideraciones.
A. Limitantes técnicas a considerar en la implementación del proyecto

WDS
B. Análisis Costo-Beneficio
C. Contingencia de la solución
D. Teléfonos soportados
E. Conjunto de caracteres
Anexo A .Limitantes técnicas a considerar en la implementación del proyecto WDS
Existen ciertos factores técnicos que deben considerarse previo a la implementación

de un proyecto con esta tecnología de mensajes cortos desde celular. Las
consideraciones más importantes son las siguientes:
• Cobertura de la señal del proveedor. Habrá que realizar pruebas
preliminares a fin de establecer cuál proveedor conviene más en
función de la señal que se reciba en el lugar en donde el teléfono estará
en operación.
• Fin del saldo en la tarjeta. Se recomienda que para este tipo de
proyecto, se adquiera un contrato con una compañía telefónica, a fin de
evitar inconvenientes por falta de saldo en el teléfono celular.
• Desperfectos del equipo celular. Debe verificarse el período de vida útil
del aparato celular, con el propósito de realizar el reemplazo oportuno a
fin de que siempre esté en funcionamiento.
• Retardo en la entrega o envío de mensajes de otro proveedor. Se
recomienda tener comunicación entre celulares de la misma compañía.
Si esto no fuere posible, se recomienda tener redundancia al menos de
dos aparatos telefónicos en el Server, de dos diferentes compañías.
Durante el desarrollo del proyecto, se probó con diversos proveedores
siendo el tiempo máximo de espera de 30 segundos, sin embargo se
recomienda establecer con el proveedor de servicios telefónicos un
Página 73 de 82
contrato en donde se establezca la calidad del servicio brindado en

relación a la mensajería de texto.
• Carga de la batería. Es recomendable que el aparato telefónico se
encuentre conectado a la PC por medio del puerto USB a fin de que la
batería esté permanentemente en carga
Anexo B. Análisis Costo-Beneficio
El esquema de costro beneficio para este Framework desarrollado puede ser

calculado de acuerdo a cada caso, pero en general se pueden tomar los siguientes
costos estimados para una inversión inicial
B.1 Costo de inversión inicial
Inversión para el nuevo sistema Costo

Costo del equipo (PC)
Linux 512M Ram, 40G HD, 1.7 GHz $800.00
Costo de infraestructura
Mobiliario para el servidor $100.00
1 licencia SUSE Linux $0.00
1 teléfono celular para Server $50.00
1 chip $5.00
Total $955.00
B.2 Beneficios
A pesar que los ahorros pueden derivarse de una gran cantidad de aspectos, al
menos uno que aplicará en todos los casos, es el recurso humano de planta, que se
ahorrará, pues este podrá controlar el servidor de manera remota.
Se ha tomando como base un salario de $1500.00 por mes para un administrador de
servidor Web (Web master), el cual podrá variar entre empresas, pero se considera
un promedio.
Ahorros por el nuevo sistema Costo

Costo de Personal
1 administrador Web 7/24 nocturno $1,500.00
Ahorro por Mes $1,500.00
Página 74 de 82
B.3 Costo de operación mensual
En cada uno de los meses habrá que estimar el volumen de mensajes a enviar y
recibir desde el sistema WDS. Una cantidad de 30 mensajes por día resultaría en
210 por semana y esto a su vez significa 840 SMS por mes, a una tasa de $0.06 da
como resultado un costo mensual de $50.40
B.4 Recuperación de la inversión
RECUPERACIÓN ANUAL
Mes costo beneficio neto
Mes 1 $995.00 1500 -$505.00
Mes 2 $50.40 1500 -$1,449.60
Mes 3 $50.40 1500 -$1,449.60
Mes 4 $50.40 1500 -$1,449.60
Mes 5 $50.40 1500 -$1,449.60
Mes 6 $50.40 1500 -$1,449.60
Mes 7 $50.40 1500 -$1,449.60
Mes 8 $50.40 1500 -$1,449.60
Mes 9 $50.40 1500 -$1,449.60
Mes 10 $50.40 1500 -$1,449.60
Mes 11 $50.40 1500 -$1,449.60
Mes 12 $50.40 1500 -$1,449.60
Total -$16,450.60
Se concluye que la operación con el sistema WDS tiene una recuperación de la

inversión inmediata.
Anexo C. Contingencia de la solución
En relación a contingencias, se establecen las siguientes consideraciones:

• Redundancia con celulares: Puede instalarse más de un teléfono
celular, lo cual permitiría superar una eventual falla en el equipo o de la
red telefónica de un proveedor, asumiendo celulares con diferente
proveedor.
Página 75 de 82
• Redundancia de administrador virtual: Puede instalarse más de un

sistema de administración virtual WDS en la red, a fin de tener
redundancia de servicio.
• Reporte de robo de terminal de administrador: En el evento de extravío
o robo del celular del administrador físico, deberá modificar el archivo
wds-project/smsdrc en la sección [exclude_numbers].
Anexo D. Teléfonos soportados

Alcatel One Touch 501 Nokia 6151 Siemens A60
Alcatel One Touch 512 Nokia 6151 Siemens A65
Alcatel One Touch 535 Nokia 6170 Siemens AF51
Alcatel One Touch 701 Nokia 6210 Siemens AX75
Alcatel One Touch 715 Nokia 6210 Siemens C35i
Alcatel One Touch 735 Nokia 6220 Siemens C45
Alcatel One Touch 801E Nokia 6225 Siemens C55
BenQ-Siemens C31 at115200 Nokia 6225 Siemens C60
BenQ-Siemens EF81 at115200 Nokia 6230 Siemens C61
Falcom Twist USB at115200 Nokia 6230 Siemens C62
LG U8210 at115200 Nokia 6230 Siemens C65
LG U8330 at115200 Nokia 6230 Siemens C66
Motorola A835 bluerfat Nokia 6230i Siemens C6V
Motorola A835 at115200 Nokia 6230i Siemens CF62
Motorola C390 at115200 Nokia 6230i Siemens CF75
Motorola C550 at19200 Nokia 6230i Siemens CX65
Motorola C650 at19200 Nokia 6230i Siemens CX75
Motorola E375 at19200 Nokia 6233 Siemens ES75
Motorola E375 at19200 Nokia 6233 Siemens M55
Motorola e815 at115200 Nokia 6234 Siemens M56
Motorola KRZR K1 bluerfat Nokia 6270 Siemens M65
Motorola L2 at19200 Nokia 6280 Siemens MC35i
Motorola L6 at19200 Nokia 6280 Siemens MC60
Motorola mpx220 Nokia 6280 Siemens MC75
Motorola Razor V3r Nokia 6288 Siemens ME75
Motorola RAZRV6 at Nokia 6300 Siemens MT50
Motorola RIZR Z3 Nokia 6300 Siemens S150
Motorola SLVR 7 Nokia 6310 Siemens S35i
Motorola V1075 Nokia 6310i Siemens S45
Motorola v190 Nokia 6310i Siemens S75
Motorola v195 Nokia 6310i Siemens SL45i
Motorola V220 Nokia 6340i Siemens TC35
Motorola V3 Nokia 6600 Sony Ericsson J300i
Página 76 de 82
Motorola V300/V40 Nokia 6600 Sony Ericsson K300i

Motorola V360 Nokia 6610 Sony Ericsson K300i
Motorola V360v Nokia 6610 Sony Ericsson K310i
Motorola V3i Nokia 6610i Sony Ericsson K500i
Motorola V3r Nokia 6610i Sony Ericsson K510i
Motorola v3x Nokia 6630 Sony Ericsson K510i
Motorola V501 Nokia 6680 Sony Ericsson K550im
Motorola v620 Nokia 6681 Sony Ericsson K608i
Nokia 2125i Nokia 6820 Sony Ericsson K618i/V
Nokia 3100 Nokia 6820 Sony Ericsson K700i
Nokia 3120 Nokia 7250i Sony Ericsson K790a
Nokia 3200 Nokia 8910 Sony Ericsson K800i/K
Nokia 3205 Nokia E50 Sony Ericsson P800
Nokia 3210 Nokia E60 Sony Ericsson P800
Nokia 3220 Nokia E61i Sony Ericsson P910a
Nokia 3220 Nokia E62 Sony Ericsson P990i
Nokia 3220 Nokia E70 Sony Ericsson R320s
Nokia 3220 Nokia N30 Sony Ericsson S700i
Nokia 3220 Nokia N70 Sony Ericsson T230
Nokia 3310 Nokia N75 Sony Ericsson T230
Nokia 3510i Nokia N93 Sony Ericsson T39m
Nokia 3586 Sagem My501Ci Sony Ericsson T610
Nokia 3589i Sagem my501X Sony Ericsson T610
Nokia 3650 Sagem myC4-2 Sony Ericsson T630
Nokia 5110 Sagem myC5 GP Sony Ericsson T630
Nokia 5140 Sagem myV-55 Sony Ericsson T637
Nokia 5200 Sagem myX5-2 Sony Ericsson T68i
Nokia 5200 Sagem myX6-2 Sony Ericsson V600i
Nokia 5200 Sagem myZ-5 G Sony Ericsson V600i
Nokia 6015i Samsung e350e Sony Ericsson V800
Nokia 6020 Samsung SGH D500e Sony Ericsson V802SE
Nokia 6020 Samsung SGH X530 Sony Ericsson W200i
Nokia 6021 Samsung SGH-A701 Sony Ericsson W300i
Nokia 6021 Samsung SGH-C230 Sony Ericsson W300i
Nokia 6021 Samsung SGH-D500 Sony Ericsson W550i
Nokia 6021 Samsung SGH-E250 Sony Ericsson W700i
Página 77 de 82

Nokia 6080 Samsung SGH-X660 Sony Ericsson W850i
Nokia 6100 Samsung SGH-X680 Sony Ericsson W880i
Nokia 6100 Samsung SGH-Z107 Sony Ericsson W950i
Nokia 6101 Samsung SGH-Z150 Sony Ericsson Z1010
Nokia 6101 Samsung SGH-Z300 Sony Ericsson Z550i
Nokia 6102 Samsung SGH-Z400 Sony Ericsson Z600
Nokia 6103 Samsung SGH-Z500 Sony Ericsson Z610i
Nokia 6103 Samsung SGH-ZV60 Sony Ericsson Z800
Nokia 6108 Samsung SGN 630 Toshiba TS 608
Nokia 6110 Samsung SHG D900 Nokia 3220
Nokia 6110 Samsung T509 Sony Ericsson W810i
Nokia 6111 Samsung V200 Sony Ericsson T610
Nokia 6131 Samsung X100 Nokia 3200
Nokia 6131 Samsung Z300 Nokia 6680
Nokia 6131 Siemens A56 Nokia 6151
Anexo E. Set de caracteres soportados para mensajes cortos SMS
La codificación de los mensajes de texto cortos enviados y recibidos por los teléfonos
móviles están definidos en la recomendación 03.38 y 03.40 de la ETSI (European
Telecommunications Standards Institute) las cuales especifican que los mensajes de
textos pueden ser:
De 160 caracteres de largo escritos con un conjunto de caracteres de 7-bit el cual

incluye todo el alfabeto ingles, numerales, puntuaciones y algunos símbolos (ver
tabla E.1), observe en esta tabla que varios símbolos son de 14 bits de longitud (Ej.
^{}[]\~) y son formados por dos caracteres cuando son enviados en formato de 7 bits,
De 140 caracteres de largo escritos con un conjunto de caracteres de 8 bits, muchos

teléfonos antiguos no pueden desplegar mensajes codificados en formato de 8 bits,
aun así este tipo de codificación es utilizada para el envío de datos (datos binarios
como ring tones, configuración WAP, mensajes inteligentes, etc.).
De 70 caracteres de largo escritos con un conjunto de caracteres de 16 bits unicode

(UCS2), esta codificación es utilizada para el envió de mensajes cortos en lenguajes
internacionales distintos al ingles, la habilidad para desplegar este tipo de caracteres
Página 78 de 82
depende de la capacidad que el móvil receptor tiene para desplegar los caracteres
unicode UCS2.
Revisando el conjunto de caracteres de la tabla E.1. se observa que prácticamente

se encuentran todos los caracteres necesarios como para escribir correctamente
cualquier comando del sistema operativo Windows y Linux con lo que no seria
necesario que el móvil del operador o el instalado como parte del sistema WDS
tenga características sobre un conjunto de caracteres extendidos y el sistema
soportaría como máximo longitudes de mensajes de hasta 160 caracteres.
Tabla E1.Conjunto de caracteres GSM 7-Bit
Gsm 7-bit decimal Character name Character Iso-8859-1 decimal
0 Commercial at @ 64
1 Pound sign £ 163
2 Dollar sign $ 36
3 Yen sign ¥ 165
4 Latin small letter e with grave È 232
5 Latin small letter e with acute É 233
6 Latin small letter u with grave Ù 249
7 Latin small letter i with grave Ì 236
8 Latin small letter o with grave Ò 242
9 Latin capital letter c with cedilla Ç 199
10 Line feed 10
11 Latin capital letter o with stroke Ø 216
12 Latin small letter o with stroke Ø 248
13 Carriage return 13
14 Latin capital letter a with ring above Å 197
15 Latin small letter a with ring above Å 229
16 Greek capital letter delta Δ 916
17 Low line _ 95
18 Greek capital letter phi Φ 934
19 Greek capital letter gamma Γ 915
20 Greek capital letter lambda Λ 923
21 Greek capital letter omega Ω 937
22 Greek capital letter pi Π 928
23 Greek capital letter psi Ψ 936
24 Greek capital letter sigma Σ 931
Página 79 de 82
25 Greek capital letter theta Θ 920

26 Greek capital letter xi Ξ 926
27 Escape to extension table
27 10 Form feed 12
27 20 Circumflex accent ^ 94
27 40 Left curly bracket { 123
27 41 Right curly bracket } 125
27 47 Reverse solidus (backslash) \ 92
27 60 Left square bracket [ 91
27 61 Tilde ~ 126
27 62 Right square bracket ] 93
27 64 Vertical bar | 124
27 101 Euro sign € 164 (iso-8859-15)
8364 (ansi)
28 Latin capital letter ae Æ 198
29 Latin small letter ae Æ 230
30 Latin small letter sharp s (german) ß 223
31 Latin capital letter e with acute É 201
32 Space 32
33 Exclamation mark ! 33
34 Quotation mark " 34
35 Number sign # 35
36 Currency sign ¤ 164 (iso-8859-1)
37 Percent sign % 37
38 Ampersand & 38
39 Apostrophe ' 39
40 Left parenthesis ( 40
41 Right parenthesis ) 41
42 Asterisk * 42
43 Plus sign + 43
44 Comma , 44
45 Hyphen-minus - 45
46 Full stop . 46
47 Solidus (slash) / 47
48 Digit zero 0 48
49 Digit one 1 49
50 Digit two 2 50
51 Digit three 3 51
Página 80 de 82
52 Digit four 4 52
53 Digit five 5 53
54 Digit six 6 54
55 Digit seven 7 55
56 Digit eight 8 56
57 Digit nine 9 57
58 Colon : 58
59 Semicolon ; 59
60 Less-than sign < 60
61 Equals sign = 61
62 Greater-than sign > 62
63 Question mark ? 63
64 Inverted exclamation mark ¡ 161
65 Latin capital letter a A 65
66 Latin capital letter b B 66
67 Latin capital letter c C 67
68 Latin capital letter d D 68
69 Latin capital letter e E 69
70 Latin capital letter f F 70
71 Latin capital letter g G 71
72 Latin capital letter h H 72
73 Latin capital letter i I 73
74 Latin capital letter j J 74
75 Latin capital letter k K 75
76 Latin capital letter l L 76
77 Latin capital letter m M 77
78 Latin capital letter n N 78
79 Latin capital letter o O 79
80 Latin capital letter p P 80
81 Latin capital letter q Q 81
82 Latin capital letter r R 82
83 Latin capital letter s S 83
84 Latin capital letter t T 84
85 Latin capital letter u U 85
86 Latin capital letter v V 86
87 Latin capital letter w W 87
88 Latin capital letter x X 88
89 Latin capital letter y Y 89
Página 81 de 82
90 Latin capital letter z Z 90

91 Latin capital letter a with diaeresis Ä 196
92 Latin capital letter o with diaeresis Ö 214
93 Latin capital letter n with tilde Ñ 209
94 Latin capital letter u with diaeresis Ü 220
95 Section sign § 167
96 Inverted question mark ¿ 191
97 Latin small letter a A 97
98 Latin small letter b B 98
99 Latin small letter c C 99
100 Latin small letter d D 100
101 Latin small letter e E 101
102 Latin small letter f F 102
103 Latin small letter g G 103
104 Latin small letter h H 104
105 Latin small letter i I 105
106 Latin small letter j J 106
107 Latin small letter k K 107
108 Latin small letter l L 108
109 Latin small letter m M 109
110 Latin small letter n N 110
111 Latin small letter o O 111
112 Latin small letter p P 112
113 Latin small letter q Q 113
114 Latin small letter r R 114
115 Latin small letter s S 115
116 Latin small letter t T 116
117 Latin small letter u U 117
118 Latin small letter v V 118
119 Latin small letter w W 119
120 Latin small letter x X 120
121 Latin small letter y Y 121
122 Latin small letter z Z 122
123 Latin small letter a with diaeresis Ä 228
124 Latin small letter o with diaeresis Ö 246
125 Latin small letter n with tilde Ñ 241
126 Latin small letter u with diaeresis Ü 252
127 Latin small letter a with grave À 224
Página 82 de 82

Curso Java Varios

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curso Java Varios

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD FRANCISCO GAVIDIA

Tecnología, Humanismo y Calidad

“Sistema WDS para la Administración remota de

PARA OPTAR AL TITULO DE:

MAESTRO EN INFORMATICA APLICADA EN REDES

Leyla Dinora Rivera Rivera

SAN SALVADOR – EL SALVADOR – CENTROAMERICA

El siguiente documento presenta la propuesta para la administración remota de los

Existen en la actualidad una variedad de situaciones que se dan en la administración

• Por el tipo de tecnología utilizada el administrador puede monitorear y

WDS es un proyecto que brinda comunicación entre el administrador y el servidor, de

• Desarrollar un sistema capaz de lograr interacción en dos vías entre el

1.3 Proyecto Gammu

Gammu puede ser configurado para trabajar en dos modos:

Configuración de Gammu en el modo SMSD

SendTimeout Muestra cuantos segundos smsd esperará por respuesta de la red

receivefrequency Frecuencia de recepción. El número de segundos entre pruebas para

deliveryreport Reportes de entrega. Si se utilizan reportes de entrega (log).

Ejemplo de configuración general:

El script para la creación de la estructura de la base de datos de Gammu se

Descripción de la estructura de la base de datos de GAMMU.

Tabla en la que se almacenan los mensajes entrantes (SMS)

Campo Tipo Descripción

UpdatedInDB Timestamp Fecha y hora en que se da una actualización del

SenderNumber Varchar(20) Numero de teléfono (decodificado) que envía el

SMSCNumber Varchar(20) Numero decodificado de la central de servicio de

Campo Tipo Descripción

Class Int(11) Clase SMS or -1

TextDecoded Varchar(160) Mensaje de texto (SMS) decodificado. Por

Campo Tipo Descripción

UpdatedInDB Timestamp Fecha y hora en que se da una actualización del

SendingDateTime Timestamp Campo en el que se fija algún valor. Cuando

Campo Tipo Descripción

TextDecoded Varchar(160) Mensaje de texto en forma legible para el

DeliveryReport enum('default','yes','no') Cuando el valor ‘default’ es utilizado, el Reporte

Text Text Mensaje de texto codificado usando valores

Campo Tipo Descripción

UDH Text Cabecera de datos del usuario codificado usando

TextDecoded varchar(160) Mensaje de texto en forma legible para el humano.

ID Int(11) unsigned Identico significado para valores en la tabla Outbox

SequencePosition Int(11) Información, ¿Cuál es número SMS en la secuencia

Campo Tipo Descripción

TextDecoded varchar(160) Texto SMS en forma legible al humano.

ID Int(11) No asignado - SMS ID

SenderID Text ¿Qué instancia de SMSD envió esta única

TPMR Int(11) Mensajes de referencia como

outboxpath Donde los mensajes SMS a ser enviados

errorsmspath Donde los mensajes SMS con error en la

El sitio Web MySQL (http://www.mysql.com/) proporciona la última información sobre

• MySQL es un sistema de gestión de bases de datos

Una base de datos es una colección estructurada de datos. Puede ser

• MySQL es un sistema de gestión de bases de datos relacionales

Una base de datos relacional almacena datos en tablas separadas en lugar de

• MySQL software es Open Source.

Open Source significa que es posible para cualquiera usar y modificar el

• El servidor de base de datos MySQL es muy rápido, fiable y fácil de usar.

El servidor MySQL también tiene una serie de características prácticas

• MySQL Server trabaja en entornos cliente/servidor o incrustados

El software de bases de datos MySQL es un sistema cliente/servidor que

• Una gran cantidad de software de contribuciones está disponible para MySQL,

El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un

Sun Microsystems proporciona una implementación GNU General Public License de

El lenguaje Java se creó con cinco objetivos principales: