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

Página 2 de 82

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 3 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 4 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 5 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 6 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 7 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 8 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.

http://www.gnokii.org/

http://www.gammu.org/


Página 9 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 10 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 11 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

me

Timestamp Hora y fecha en que un mensaje SMS fue

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

sion',’Unicode_No_Compres

sion','8bit','Default_Compres

sion','Unicode_Compression

')

Tipo de codificación del mensaje de texto.

UDH Texto Cabecera de datos de usuario codificado

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

mensajes cortos


Página 12 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

er

Varchar(20) Número de teléfono (decodificado) del

destinatario del mensaje

Coding enum('Default_No_Compres

sion',

'Unicode_No_Compression',

'8bit',

'Default_Compression',

'Unicode_Compression')


UDH Text Cabecera de datos del usuario codificado usando

valores hexadecimales.



Página 13 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. Campo Tipo

Descripción

Text Text Mensaje de texto codificado usando valores

Hexadecimales.

Coding enum('Default_No_Compre

ssion','Unicode_No_Compr

ession',

'8bit','Default_Compression'

, 'Unicode_Compression'),



Página 14 de 82

Campo Tipo

Descripción

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.

Campo Tipo Descripción 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',

'SendingOKNoReport',

'SendingError',

'DeliveryOK',

'DeliveryFailed',

'DeliveryPending',

'DeliveryUnknown', 'Error')

Cuando el reporte de envío fue utilizado por

SMS, esta entrada contiene código de error

legible por el humano.

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 15 de 82

Campo Tipo Descripción Coding enum('Default_No_Compre

ssion',

'Unicode_No_Compression'

, '8bit',

'Default_Compression',

'Unicode_Compression')

Texto codificado SMS.

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 16 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 17 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.

http://www.mysql.com/

http://www.fsf.org/licenses/


Página 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 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 29 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 30 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 31 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 32 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 33 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 34 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.

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

el siguiente cuadro:

Sistema

WDS Servidor sin control remoto

Servidor controlado remotamente


Página 35 de 82

Entrada

Proceso

Salida

• Fallos en servicios de

servidores remotos

• Sin Soporte 7/24

• Se cuenta con Múltiples

Adimistradores físicos

• Soluciones no rentables

• Control remoto desde PC

WDS

• Servicios controlados en

servidores remotos

• Con Soporte 7/24

• Se pueden controlar uno o

más Servidores y diversos

servicios

• Solución de bajo costo

• 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 36 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 37 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 38 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 39 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.

Admin Fisico

WDS

Admin Virtual

Envia /Recibe SMS

Ejecutar comando

«uses»

«uses» «uses»

A continuación se muestra el correspondiente diagrama de secuencia


Página 40 de 82

Admin Viirtual WDS Sistema Operativo

SMS

Comando

Salida del comando

Envia Resultado

Envía SMS

Envía SMS

Administrador Físico

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 41 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.

Admin Fisco

WDS

SMSDDaemon

SMSD I2icDaemon

JAVA

Sistema Operativo

Entrega de SMS

Gammu MySQL

Lee mensaje

Envía SMS

Mensaje

Comando a Ejecutar

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 42 de 82

Admin Fisco

WDS

SMSDDaemon

MYSQL

Hibernate

i2icDaemon JAVA Sistema

Operativo

Entrega de SMS

Gammu

Lee mensaje

Envía SMS

Inbox Inbox Command Outbox

Command

SMS Codificado

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 43 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 I2ic Daemon

Leer Sms

Enviar Sms

Command Table

Insert Sms

Inbox TableSmsd Daemon

Leer Sms

Marcar Leído

getScriptName

Return Script

getId

JavaClient Os

Mensaje1

Exe Command

Outbox Table

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 44 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 45 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 46 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 47 de 82

Fig. 4.1, Estructura de carpetas y archivos del proyecto WDS


Página 48 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 49 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 50 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: $! "; `echo $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 51 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 52 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 53 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 54 de 82

`Version` tinyint(4) NOT NULL default '0' ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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` ( ÙpdatedInDB` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, Ì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 '', `Coding` enum('Default_No_Compression','Unicode_No_Compression','8bit','Default_Compression','Unicode_Compression') default '8bit', ÙDH` text,


Página 55 de 82

`Class` int(11) default '-1', `TextDecoded` varchar(160) NOT NULL default '', Ì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, UNIQUE KEY ÌD` (ÌD`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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, `Coding` enum('Default_No_Compression','Unicode_No_Compression','8bit','Default_Compression','Unicode_Compression') 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' ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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 ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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, UNIQUE KEY ÌD` (ÌD`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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 56 de 82

-- -- Table structure for table `phones` DROP TABLE IF EXISTS `phones`; CREATE TABLE `phones` ( ÌD` text NOT NULL, ÙpdatedInDB` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, ÌnsertIntoDB` timestamp NOT NULL default '0000-00-00 00:00:00', `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 ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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` ( ÙpdatedInDB` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, ÌnsertIntoDB` timestamp NOT NULL default '0000-00-00 00:00:00', `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 '', `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 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 ) ENGINE=MyISAM DEFAULT CHARSET=utf8; -- -- 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 57 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 58 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 59 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 60 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 61 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 62 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 63 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(); Session sesion = sessionFactory.openSession(); sesion.update(ic); sesion.flush(); sesion.close(); package sv.edu.ufg.maestria.wds.datos; import sv.edu.ufg.maestria.wds.dominio.*; 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(); Session sesion = sessionFactory.openSession(); sesion.save(o); sesion.flush(); sesion.close(); catch(Exception e) return e.getCause().getLocalizedMessage() ; return null;


Página 64 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; import sv.edu.ufg.maestria.wds.dominio.*; 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 65 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 <?xml version="1.0"?> <!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" > <generator class="assigned"/> </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 66 de 82

</property> <property name="sMSCNumber"> <column name="SMSCNumber" /> </property> <property name="scriptLocation"> <column name="ScriptLocation" /> </property> </class> </hibernate-mapping>

Archivo Outbox.hbm.xml <?xml version="1.0"?> <!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" > <generator class="assigned"/> </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> </hibernate-mapping>


Página 67 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 68 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 69 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 70 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 71 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 72 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

http://es.wikipedia.org/wiki/Eclipse_Foundation

http://es.wikipedia.org/wiki/Eclipse_(computaci%C3%B3n)

http://es.wikipedia.org/wiki/Lomboz

http://www.linux-magazine.com/issue/58/Gammu_und_Wammu.pdf


Página 73 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 74 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 75 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.00Mes 2 $50.40 1500 -$1,449.60Mes 3 $50.40 1500 -$1,449.60Mes 4 $50.40 1500 -$1,449.60Mes 5 $50.40 1500 -$1,449.60Mes 6 $50.40 1500 -$1,449.60Mes 7 $50.40 1500 -$1,449.60Mes 8 $50.40 1500 -$1,449.60Mes 9 $50.40 1500 -$1,449.60Mes 10 $50.40 1500 -$1,449.60Mes 11 $50.40 1500 -$1,449.60Mes 12 $50.40 1500 -$1,449.60Total -$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 76 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 V150 Nokia 6310i Siemens S55 Motorola V180 Nokia 6310i Siemens S65 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 77 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 V365 Nokia 6610 Sony Ericsson K320i Motorola V3i Nokia 6610i Sony Ericsson K500i Motorola V3r Nokia 6610i Sony Ericsson K510i Motorola v3x Nokia 6630 Sony Ericsson K510i Motorola V500 Nokia 6670 Sony Ericsson K550i Motorola V501 Nokia 6680 Sony Ericsson K550im Motorola V547 Nokia 6680 Sony Ericsson K600i Motorola V551 Nokia 6680 Sony Ericsson K608i Motorola v620 Nokia 6681 Sony Ericsson K608i Motorola V80 Nokia 6810 Sony Ericsson K610i Nokia 2125i Nokia 6820 Sony Ericsson K618i/V Nokia 3100 Nokia 6820 Sony Ericsson K700i Nokia 3100 Nokia 6820 Sony Ericsson K700i Nokia 3100 Nokia 7110 Sony Ericsson K750i Nokia 3105 Nokia 7110 Sony Ericsson K750i Nokia 3110 Nokia 7210 Sony Ericsson K750i Nokia 3120 Nokia 7250i Sony Ericsson K790a Nokia 3120 Nokia 7610 Sony Ericsson K800i Nokia 3200 Nokia 8800 Sony Ericsson K800i 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 Nokia 6030 Samsung SGH-E330 Sony Ericsson W800i


Página 78 de 82

Nokia 6030 Samsung SGH-E370 Sony Ericsson W810i Nokia 6070 Samsung SGH-E900 Sony Ericsson W810i 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 79 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 80 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 81 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 82 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

curso java varios

Documents