Tesis de Trafico

Maestra en Informtica y
Computacin
Universidad Nacional de Misiones
TESIS DE MAESTRA
SISTEMA INTELIGENTE PARA SOLUCIONAR

PROBLEMAS DE TRFICO EN REDES A
NIVEL DE LA CAPA DE APLICACIN
Presentada por:
Estigarribia Oscar Alberto

para la obtencin del ttulo de
Magister en Informtica y Computacin

Dirigida por el
Mgter. David Luis la Red Martnez
Tema de Estudio y Director de tesis aprobados por el Consejo Acadmico
de la Maestra en Informtica y Computacin de la Facultad de Ciencias
Econmicas de la Universidad Nacional de Misiones.
ii
Prefacio
El presente trabajo de Tesis de Maestra se ha realizado con el propsito
de integrar diversos conocimientos adquiridos en el desarrollo de la Maestra
para resolver de manera novedosa y a bajo costo, el problema de la integracin de aplicaciones de legado (legacy) desarrolladas en los aos 70s,
que requieren intercambiar informacin entre diferentes equipos conectados mediante Internet, utilizando un gestor de trco de requerimientos
y respuestas a nivel de capa de aplicacin.
El mencionado gestor de trco, llamado protocolo YOSUKO, fue
desarrollado utilizando el lenguaje multiplataforma Java y gran parte de
sus posibilidades de gestin de trco y de seguridad.
Contenido
Esta Tesis est dividida en tres partes claramente denidas:
Parte I: Marco Conceptual y Herramientas Utilizadas

Esta parte est integrada por los primeros cinco captulos.
Se comienza con un captulo dedicado a los objetivos del trabajo, las
hiptesis de partida, la justicacin del proyecto planteado y algunos
aspectos del marco conceptual empleado.
Se contina luego con un captulo dedicado a los protocolos de comunicaciones de datos, en especial el TCP/IP.
El tercer captulo trata de los sistemas distribuidos, revisndose rpidamente aspectos relacionados con sockets, RPC, CORBA, RMI, etc.
En el siguiente captulo se presenta una resea acerca de los principales aspectos referidos a los sistemas expertos, empleados en el desarrollo
de la tesis.
iii
Se contina con una revisin de los aspectos ms sobresalientes de la

programacin orientada a objetos y del lenguaje Java, especialmente los
aspectos utilizados en el desarrollo de la tesis, tales como los relativos a
los sockets.
Parte II: Desarrollos Efectuados y Conclusiones

Se inicia esta parte con un captulo dedicado a los principales aspectos
del desarrollo del producto de software.
Se prosigue con un captulo dedicado a diferentes aspectos de seguridad considerados en el producto desarrollado.
Seguidamente se describe la interaccin del software desarrollado con
otras aplicaciones preexistentes para lograr procesamiento destribuido,
con gestin de trco inteligente desde la aplicacin desarrollada, todo
ello a travs de Internet.
Finalmente se presentan las conclusiones y posibles trabajos futuros.
Parte III: Anexo

En esta parte se describen los objetos ms importantes del producto
desarrollado, como as tambin el Manual del Usuario de dicho producto.
iv
Agradecimientos
Haber llegado a las instancias de presentar esta Tesis de Maestra es

el mrito de muchas personas que han sido los mentores, impulsores y
mi apoyo para seguir adelante hasta esta meta, a quienes les debo mi
agradecimiento.
Ante todo quiero expresar la ms profunda gratitud a mi familia por
el apoyo, la paciencia, la comprensin y tolerancia durante el tiempo
de desarrollo de la Maestra, y muy especialmente a mi madre, quien
frecuentemente me deca hijo, te pueden sacar todas tur pertenencias,
pero nunca lo que est en tu mente..
En particular, a dos de mis profesores y guas. En primer lugar,
al Prof. Mgr. David la Red Martnez, quien fuera mi docente cuando
cursaba mis estudios universitarios, y posteriormente en este postgrado,
donde adems ha sido un director de tesis ejemplar. En segundo lugar,
mi agradecimiento es para el Prof. Dr. Enrique Castillo Ron, quien
en una demostracin de altrusmo y condiciones acadmicas y humanas
superiores, nos ha permitido lograr este crecimiento.
A las autoridades de la Universidad Nacional de Misiones, y de la
Facultad de Ciencias Econmicas. En particular al Decano Mgr. Aldo
Montini, por su permanente apoyo a la Maestra en Informtica y Computacin en la Facultad de Ciencias Econmicas de la UNaM.
A todos los docentes de la Maestra, tanto argentinos como espaoles,
por su esfuerzo y dedicacin.
A mis colegas y compaeros de facultad y de maestra, con quienes he
compartido esta importante experiencia, en especial a Carlos Brys, Myriam Kurtz y Marcelo Marinelli, por el permanente aliento para concluir
la tarea emprendida.
Oscar Alberto Estigarribia
Maestra en Informtica y Computacin

Facultad de Ciencias Econmicas
Universidad Nacional de Misiones
Posadas-Misiones, Argentina, Febrero de 2006.
Tabla de Contenidos
Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contenido . . . . . . . . . . . . . . . . . . . . . . . . . .
Agradecimientos . . . . . . . . . . . . . . . . . . . . . . .
ii
ii
iv
I Marco Conceptual y Herramientas Utilizadas 1

1 Aspectos Conceptuales
Introduccin . . . . . . . . . . . . . . . . . . . . . . .
Objetivo General . . . . . . . . . . . . . . . . . . . .
Objetivos Especcos . . . . . . . . . . . . . . . . . .
Hiptesis . . . . . . . . . . . . . . . . . . . . . . . . .
Justicacin del Estudio . . . . . . . . . . . . . . . .
Denicin del Impacto de la Investigacin . . . . . .
Marco Conceptual . . . . . . . . . . . . . . . . . . .
Resea Sobre Modelos de Diseos de Programas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduccin . . . . . . . . . . . . . . . . . . . . . . . .
Niveles o Capas del Modelo OSI . . . . . . . . . . . . .
Protocolo TCP/IP . . . . . . . . . . . . . . . . . . . .
Introduccin . . . . . . . . . . . . . . . . . . . . .
Funciones TCP/IP . . . . . . . . . . . . . . . . .
Denicin del Nivel IP . . . . . . . . . . . . . . .
Estructura del Datagrama . . . . . . . . . . . . .
Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . .
Detalles de Direccionamiento: Subredes y Broadcasting
Fragmentacin y Reensamblado del Datagrama . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Protocolos de Comunicacin de Datos
2
2
3
4
4
5
5
6
6
8
10
14
14
16
17
18
19
21
23
v
TABLA DE CONTENIDOS
vi
ARP: Address Resolution Protocol . . . . . . . . . . . .

Sistema de Dominios . . . . . . . . . . . . . . . . . . . .
Protocolos que Trabajan Junto con TCP/lP . . . . . . .
Protocolos Usados en el Nivel OSI de Aplicacin,
sentacin y Sesin . . . . . . . . . . . . . . .
Mtodos de Comunicacin . . . . . . . . . . . . . . . . .
...
...
...
Pre...
...
3 Sistema Distribuidos
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enfoques al Diseo de Aplicaciones Distribuidas . . . . . . . .
Aplicaciones Distribuidas en Internet . . . . . . . . . . . . . .
Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RPC - Llamadas a Procedimientos Remotos . . . . . . . . . .
Diferentes Enfoques Para la Contruccin de Aplicaciones Distribuida . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entorno de Computacin Distribuida . . . . . . . . . . .
El Modelo de Objeto Componente Distribuido . . . . . .
Arquitectura de Intermediacin de Solicitud de Objetos Comunes (CORBA) . . . . . . . . . . . . . . . . . . . . . .
Invocacin Remota de Mtodos de Java . . . . . . . . . . . . .
El Modelo de Objeto Distribuido de Java . . . . . . . . . . . .
Las Tres Capas de la RMI de Java . . . . . . . . . . . . . . .
Pasar Argumentos y Valores de Retorno . . . . . . . . . . . .
Los Objetos y la Invocacin Remota de Mtodos . . . . . . . .
Seguridad de la Aplicacin Distribuida . . . . . . . . . . . . .
Seguridad en el Transporte . . . . . . . . . . . . . . . . . . . .
Autenticacin y Control de Acceso . . . . . . . . . . . . . . .
4 Sistemas Expertos
Denicin de Sistema Experto . . . . . . . . . . . .

Aspectos Fundamentales de los Sistemas Expertos .
Componentes de un Sistema Experto . . . . .
Tipos de Conocimiento . . . . . . . . . . . . .
Fuentes de Conocimiento . . . . . . . . . . . .
Denicin del Conocimiento . . . . . . . . . .
Clasicacin de los Sistemas Expertos . . . . .
Sistemas Expertos Basados en Reglas . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
26
26
27
29
29
30
31
32
35
37
37
38
42
44
45
46
49
50
51
52
52
57
57
58
58
59
60
60
61
62
TABLA DE CONTENIDOS
vii
El Motor de Inferencia . . . . . . . . . . . . . . . . .
Modus Ponens y Modus Tollens . . . . . . . . . . . .
Resolucin . . . . . . . . . . . . . . . . . . . . . . . .
Encadenamiento de Reglas . . . . . . . . . . . . . . .
Encadenamiento de Reglas Orientada a un Objetivo .
Compilacin de Reglas . . . . . . . . . . . . . . . . .
Control de la Coherencia . . . . . . . . . . . . . . . .
Metodologa de Weiss y Kulikowski . . . . . . . . . .
Base de Conocimiento . . . . . . . . . . . . . . . . .
Modelado de la Base de Conocimiento . . . . . . . .
Deniciones y Conceptos Sobre Grafos . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
5 Programacin Orientada a Objetos
.
.
.
.
.
.
.
.
.
.
.
62
64
65
66
67
67
67
68
69
69
73
77
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Clases y Objetos . . . . . . . . . . . . . . . . . . . . . . 79
Propiedades de un Lenguaje Orientado a Objetos . . . . . . . 80
Encapsulamiento . . . . . . . . . . . . . . . . . . . . . . 81
Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Polimorsmo . . . . . . . . . . . . . . . . . . . . . . . . 85
Lenguaje Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Caractersticas Destacables del Lenguaje Java . . . . . . 86
Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Pasos Para Crear un Servidor . . . . . . . . . . . . . . . 96
Crear el Socket Servidor . . . . . . . . . . . . . . . . . . 97
Aceptar un Cliente . . . . . . . . . . . . . . . . . . . . . 97
Obtener el InputStream y / o OutputStream . . . . . . . 98
Crear unos InputStream y / o OutputStream Ms Adecuados a las Necesidades . . . . . . . . . . . . . . 98
Leer y Escribir Datos Del y Al Cliente . . . . . . . . . . 99
Cerrar el Socket . . . . . . . . . . . . . . . . . . . . . . . 102
Pasos Para Crear un Cliente . . . . . . . . . . . . . . . . 102
II Desarrollos Efectuados y Conclusiones
104
6 Desarrollo del Producto
105
TABLA DE CONTENIDOS
viii
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objetivos del Prototipo . . . . . . . . . . . . . . . . . . . . .
Estudio Comparativo de Ambas Versiones del Prototipo . . .
Protocolo YOSUKO V. 2.0. . . . . . . . . . . . . . . . . . . .
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . .
Planteo del Problema . . . . . . . . . . . . . . . . . . . .
Estudio de Factibilidad para Brindar una Solucin al Problema . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusin del Estudio de Factibilidad . . . . . . . . . .
Desarrollo de la Experiencia . . . . . . . . . . . . . . . .
Arquitectura Utilizada para Desarrollar el Protocolo . . .
Base de Conocimiento Yosuko V 1.0. . . . . . . . . . . .
Almacenamiento de las Reglas . . . . . . . . . . . . . . .
Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Seguridad a Nivel de Informacin
Introduccin . . . . . . . . . . . . . . . . . . . . . . .
Seguridad Nivel de Aplicacin . . . . . . . . . .
Seguridad Cuando se Transmite la Informacin
Seguridad Nivel Usuarios . . . . . . . . . . . . .
Diagrama en Bloque del Sistema . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
105
106
106
107
107
108
108
109
110
115
115
117
131
132
132
133
135
137
138
8 Metodologa de Integracin de YOSUKO V.2.0 y Aplicaciones Informticas

140
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . .
El Protocolo YOSUKO V. 2.0 y las Aplicaciones Externas
Descripcin Operativa del Sistema de Integracin . . . . .
Algoritmo del Sistema Integracin . . . . . . . . . . . . . .
Prueba de la Implementacin Efectuada . . . . . . . . . .
Prueba de Transmisin de Paquetes . . . . . . . . . . . . .
Prueba con Aplicacin Externa de Ventas de Boletos . . .
9 Conclusiones y Futuros Trabajos
.
.
.
.
.
.
.
.
.
.
.
.
.
.
140
141
146
152
157
160
162
168
TABLA DE CONTENIDOS
III Anexo
10 Anexo
Detalles de los Objetos Ms Importantes del Protocolo YOSUKO

V. 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manual del Usuario de YOSUKO V. 2.0 . . . . . . . . . . . .
Pasos Para la Instalacin Modo Servidor . . . . . . . . .
Pasos Para la Instalacin Modo Cliente . . . . . . . . . .
Panel de Control . . . . . . . . . . . . . . . . . . . . . .
Conguracin . . . . . . . . . . . . . . . . . . . . . . . .
ABM de Actividades . . . . . . . . . . . . . . . . . . . .
ABM de Terminales (Modo Servidor) . . . . . . . . . . .
ABM de Procesos . . . . . . . . . . . . . . . . . . . . . .
ix
171
172
172
176
176
177
178
178
179
179
180
Bibliografa
183
ndice Alfabtico
186
Lista de Figuras
2-1
2-2
2-3
3-1
3-2
3-3
3-4
3-5
3-6
3-7
3-8
3-9
4-1
4-2
4-3
4-4
4-5
4-6
4-7
4-8
4-9
4-10
5-1
5-2
5-3
Modelo OSI - Estructura. . . . . . . . . . . . . . . . . .

Diferencia entre Modelo OSI y TCP/IP. . . . . . . . . .
Estructura del Datagrama. . . . . . . . . . . . . . . . . .
La organizacin de sistema distribuido. . . . . . . . . . .
Estructura del servidor. . . . . . . . . . . . . . . . . . . .
Ejemplo de aplicacin distribuida. . . . . . . . . . . . . .
Utilizacin de sockets. . . . . . . . . . . . . . . . . . . .
Filosofa del RPC. . . . . . . . . . . . . . . . . . . . . .
COM y DCOM. . . . . . . . . . . . . . . . . . . . . . . .
Cmo funciona CORBA. . . . . . . . . . . . . . . . . . .
RMI de Java. . . . . . . . . . . . . . . . . . . . . . . . .
Las tres capas de RMI. . . . . . . . . . . . . . . . . . . .
Esquema resumido del funcionamiento de un sistema experto. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La cadena del conocimiento. . . . . . . . . . . . . . . . .
Regla modus ponens. . . . . . . . . . . . . . . . . . . . .
Regla modus tollens. . . . . . . . . . . . . . . . . . . . .
Proceso de bsqueda en la base de conocimiento. . . . .
Diceo de la regla mediante UML. . . . . . . . . . . . . .
Etapas en el desarrollo de un SE. . . . . . . . . . . . . .
Tipos de grafos. . . . . . . . . . . . . . . . . . . . . . . .
Notacin de grafos. . . . . . . . . . . . . . . . . . . . . .
Grafo completo. . . . . . . . . . . . . . . . . . . . . . . .
Terminologa de objetos. . . . . . . . . . . . . . . . . . .
Reutilizacin de objeto. . . . . . . . . . . . . . . . . . . .
Interface para RMI. . . . . . . . . . . . . . . . . . . . . .
11
15
18
30
32
33
34
36
54
55
55
56
58
61
65
66
70
70
72
74
74
75
79
84
91
x
LISTA DE FIGURAS
5-4
5-5
5-6
5-7
5-8
5-9
5-10
5-11
5-12
5-13
5-14
5-15
5-16
5-17
5-18
5-19
5-20
5-21
5-22
5-23
5-24
6-1
6-2
6-3
6-4
6-5
6-6
6-7
6-8
6-9
6-10
6-11
6-12
6-13
6-14
6-15
Objeto remoto. . . . . . . . . . . . . . . . . . . . . . .
Permiso de seguridad. . . . . . . . . . . . . . . . . . .
Archivo de poltica de seguridad. . . . . . . . . . . . .
Lanzamiento de rmiregristry. . . . . . . . . . . . . . . .
Indicacin de la ubicacin del cdigo base. . . . . . . .
Gestor de seguridad. . . . . . . . . . . . . . . . . . . .
Instancia y registra un objeto en el servidor rmi. . . . .
Solicitud de objeto remoto. . . . . . . . . . . . . . . . .
Llamado a un mtodo. . . . . . . . . . . . . . . . . . .
Creacin del socket servidor. . . . . . . . . . . . . . . .
El servidor activa la atencin a un cliente. . . . . . . .
Lectura y envo de datos. . . . . . . . . . . . . . . . .
Objetos para recibir datos (enteros, otantes, strings).
Objetos para recibir o enviar clases. . . . . . . . . . . .
Implementa interface Serializable. . . . . . . . . . . . .
Implementa interface Serializable. . . . . . . . . . . . .
Dene mtodos privados. . . . . . . . . . . . . . . . . .
Mtodo WriteObjet. . . . . . . . . . . . . . . . . . . .
Lectura de objetos por socket. . . . . . . . . . . . . . .
Cierre de una conexin cliente y servidor. . . . . . . . .
Creacin de una conexin cliente. . . . . . . . . . . . .
Presupuesto de servidor. . . . . . . . . . . . . . . . . .
Costo de la comunicacin. . . . . . . . . . . . . . . . .
Arquitectura utilizada para el sistema experto. . . . . .
Estructura del almacenamiento de las reglas. . . . . . .
Archivo de reglas. . . . . . . . . . . . . . . . . . . . . .
Algoritmo del motor de inferencia de YOSUKO V.1.0. .
Archivo de nodos. . . . . . . . . . . . . . . . . . . . . .
Archivo contenedor de reglas. . . . . . . . . . . . . . .
Regla 1 del ejemplo. . . . . . . . . . . . . . . . . . . .
Clculo de ping modelo 1. . . . . . . . . . . . . . . . .
Clculo TPR segundo mtodo. . . . . . . . . . . . . . .
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
92
93
93
94
94
95
95
96
96
97
98
98
99
99
100
101
101
102
102
102
103
111
114
115
117
118
119
120
122
122
123
123
123
124
126
129
LISTA DE FIGURAS
6-16
7-1
7-2
8-1
8-2
8-3
8-4
8-5
8-6
8-7
8-8
8-9
8-10
8-11
8-12
8-13
8-14
8-15
8-16
8-17
8-18
8-19
8-20
8-21
8-22
8-23
10-1
10-2
10-3
10-4
10-5
10-6
Grafo completo no dirigido. . . . . . . . . . . . . . . . .

Pantalla donde se registra el producto. . . . . . . . . . .
Esquema funcional de nodos. . . . . . . . . . . . . . . . .
Diagrama de interaccin de YOSUKO con las aplicaciones
externas. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Estructura del archivo Read.dat. . . . . . . . . . . . . .
Archivo binario Activ.dat. . . . . . . . . . . . . . . . . .
Archivo binario Control.dat. . . . . . . . . . . . . . . . .
Archivo binario Nodos.dat. . . . . . . . . . . . . . . . . .
Archivo binario Proc.dat. . . . . . . . . . . . . . . . . . .
Ingreso al Servidor MySQL. . . . . . . . . . . . . . . . .
Pantalla de registracin del producto. . . . . . . . . . . .
Pantalla de conrmacin. . . . . . . . . . . . . . . . . . .
Tabla Usuario de la base de datos YOSUKO. . . . . . . .
ABM de servidores y terminales. . . . . . . . . . . . . . .
Error en el segundo nivel de seguridad. . . . . . . . . . .
Registro del cliente en la aplicacin. . . . . . . . . . . . .
Registro de la actividad. . . . . . . . . . . . . . . . . . .
Registro de procesos. . . . . . . . . . . . . . . . . . . . .
Vericacin del nivel de seguridad a nivel usuario. . . . .
Panel sin nodos. . . . . . . . . . . . . . . . . . . . . . . .
Terminal de control con nodos activos. . . . . . . . . . .
Pantalla de aplicacin de antigua generacin (lenguaje Clipper 5.2). . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transferencia entre dos nodos. . . . . . . . . . . . . . . .
Archivo encriptado. . . . . . . . . . . . . . . . . . . . . .
Aplicacin de ventas de boletos. . . . . . . . . . . . . . .
Deteccin del mejor camino por parte de YOSUKO para
atender una aplicacin externa. . . . . . . . . . . . . . .
Contenido del CD de la tesis. . . . . . . . . . . . . . . .
Pantalla panel de control. . . . . . . . . . . . . . . . . .
Pantalla de conguracin del terminal. . . . . . . . . . .
Pantalla ABM de actividades. . . . . . . . . . . . . . . .
Pantalla de ABM de terminales. . . . . . . . . . . . . . .
Pantalla para ABM de procesos. . . . . . . . . . . . . . .
xii
130
134
139
142
143
144
145
146
147
157
158
158
159
159
160
161
162
163
163
164
165
165
166
166
167
167
176
179
180
181
181
182
Parte I
Marco Conceptual y
Herramientas Utilizadas
Captulo 1
Aspectos Conceptuales
Introduccin
La masicacin de las redes computacionales, y el exponencial crecimiento de Internet, han cambiado la forma en que los usuarios comparten, distribuyen y analizan la informacin.
Adems las nuevas tecnologas en comunicacin, han logrado centralizar o distribuir la informacin en tiempo real, brindando grandes
benecios a las empresas o al ser humano que utiliza estas herramientas
para la toma de decisiones.
Muchos sistemas actualmente poseen la Tecnologa Cliente / Servidor con Motores de Bases de Datos, utilizando una conectividad ODBC ,
JDBC , en una gran diversidad de redes locales o de rea amplia, interactuando con diversos dispositivos inteligentes. Esto signica un gran
benecio para algunas empresas (que aprovechan todas las bondades),
y un inconveniente para otras, que solo los aprovechan parcialmente, lo
2
que no justica la inversin de implementar dichas tecnologas.

Las mayoras de las empresas de nuestro medio, se encuentran sistematizadas con lenguaje de programacin que no tienen la capacidad
de utilizar las tecnologas actuales, trayendo consecuencias drsticas a
nivel costo y organizacin, debido a que tienen que volver a programar
los sistemas existentes, comprar nuevos equipamientos (servidor, router,
rack, etc.), licencias de software, capacitacin al personal, etc.
Adems hay empresas que debido a su actividad, necesitan tener la
informacin en tiempo real. Ej.: empresas de transporte de pasajeros que
se informatizan, utilizando las tcnicas Cliente / Servidor, centralizando
la informacin en un solo servidor, pero existe el inconveniente con los
puntos de ventas remotos, donde no se puede utilizar comunicacin de
bajo costo (ADSL). Debido a que un corte de comunicacin representa
gran perdida de dinero, se ven obligado a contratar proveedores, que
garanticen la comunicacin punto a punto, ej.: Telecom, Telefnica.
Objetivo General
Teniendo en cuenta los inconveniente antes mencionados, se propuso desarrollar un Sistema Experto Multiplataforma en lenguaje Java, empleando comunicacin de bajo costo, permitiendo gestionar trco entre
servidores remotos, teniendo en cuenta como mtrica la del camino ms
rpido, detectado mediante sondeo en tiempo real, e integrando software
desarrollado en la dcada de los 70s, con tecnologa Clientes Servidor,
Motor de Bases de Datos, e interconexin a Internet, y brindando seguridad a la informacin transmitida.
Para evaluar el sistema se realizaran pruebas con la interfaz, y las
nuevas tecnologas, demostrando la efectividad en costo y velocidad.
Objetivos Especficos
Disear y desarrollar un Sistema Experto basado en reglas (en lenguaje
Java ), con el n de lograr los siguientes objetivos:
1. Gestionar el trco entre servidores remotos, utilizando comunicacin de bajo costo, detectando el mejor camino segn el criterio
ya mencionado.
2. Interactuar con los diferentes Motores de Bases de datos o sistemas
de archivos de los distintos servidores mediante comandos de SQL.
3. Integrar aplicaciones, desarrollada en la dcada de los 70s, a travs
de un contenedor de pedidos; estas aplicaciones se podrn ejecutar
en forma local o remota.
4. Utilizar algoritmos de seguridad para dar proteccin a los datos
recibidos o enviados por el contenedor de pedidos.
5. Disear pruebas que permitan evaluar la efectividad del software.
Hiptesis
Es posible desarrollar un Sistema Experto para gestin de trco, a nivel,
de capa de aplicacin, capaz de integrar software confeccionado en la
dcada de los 70s, con tecnologa Cliente / Servidor, Motor de Bases de
Datos, interconectado con varios servidores, proveyendo seguridad a la
informacin transmitida.
Justificacin del Estudio

Ante el avance de las exigencias de los negocios, es una necesidad para
muchas empresas PYMES (que carecen de la posibilidad de utilizar las
nuevas soluciones integrales por su elevado costo), el desarrollo de una
interfaz con un Sistema Experto para gestin del trco entre servidores
en los que opera el software aplicativo de legado (heredado).
Definicin del Impacto de la Investigacin

Con esta interfaz de software las empresas obtendrn los siguientes benecios:
1.
2.
3.
4.
5.
6.
7.
Ahorro en la reprogramacin del software.

Ahorro en servidores costosos.
Ahorro en motores de bases de datos.
Ahorro en costo de comunicacin.
Ahorro en licencias de software.
Ahorro en capacitacin del personal.
Seguridad de datos en el momento de transmitir la informacin.
Marco Conceptual
Resea Sobre Modelos de Diseos de Programas

Actualmente existen varios modelos de diseo de programas, los que se
detallan seguidamente:
Modelo 1:
Programas de red local. Suelen ser programas de bajo costo con

un tratamiento de cheros y bloqueos dentro de una red local. Poseen
sistemas ms o menos avanzados de generacin de informes.
Modelo 2:
Son programas de modelo 1, muy planicados, para realizar ejecucin remota. Utilizan lenguaje SQL con tecnologa ODBC o JDBC, y
stos se enlazan con bases de datos relacionales, implicando generalmente
servidores costosos y comunicacin de alto costo para lograr rendimiento.
Adems se debe contar con una buena poltica de seguridad con respecto
a la proteccin de los servidores.
Modelo 3:
Aplicaciones distribuidas, cuyos procedimientos se distribuye por mltiples computadoras de una red, y que son capaces de servir a usuarios
mltiples. Se implementan como sistemas cliente / servidor, organizados
de conformidad con la interfaz de usuario [14, Jaworski-99]. Tambin se
denominan aplicaciones RMI (Invocacin Remota de Mtodos).
[32, Tanenbaum-97-01] Expresa que Un sistema distribuido es aqul
al que sus usuarios ven como un ordinario sistema operativo centralizado;
sin embargo, se ejecuta en diferentes e independientes CPUs. El concepto clave aqu es la transparencia ; en otras palabras, el uso de diversos
procesadores deber ser invisible (transparente) al usuario. Otra forma
de expresar esta misma idea es diciendo que el usuario ver al sistema
como un uniprocesador virtual y no como una coleccin de mquinas
diferentes.
Asimismo, [11, Coulouris Dollimire Kindberg -01] indican respecto

de un sistema distribuido que es un Sistema en el cual componentes de
hardware y software, localizados en computadores diferentes y en red, se
comunican y coordinan sus acciones slo por paso de mensajes.
Por qu utilizar aplicaciones distribuida?. Existen esencialmente tres
lneas de justicacin:
1. Compartir recursos de una manera ms natural, estos pueden ser
de variados tipos: capacidad de procesamiento, perifricos, informacin, accesibilidad, etc.
2. Distribuir la carga, los procesos pueden ser delegados segn criterios
(posicin geogrca, capacidad de procesamiento, seguridad, etc.).
3. Optimizar su ejecucin y distribucin de resultados, es decir, lograr
la ejecucin de aplicaciones en ambientes ms adecuados.
Se ha propuesto el desarrollo de un Sistema Experto con la

arquitectura del modelo 3.
Antes de tomar la decisin se han evaluado en forma sinttica los benecios que se tienen al utilizar diversas tecnologas, tales como las relacionadas con los Niveles OSI, Protocolo TCP/IP, Sistema Distribuido,
Sistema Experto Basado en Reglas, Lenguaje Java, Programacin Orientada a Objetos y Programacin RMI.
Captulo 2
Protocolos de Comunicacin
de Datos
Introduccin
Desde tiempos muy remotos los seres humanos han desarrollado y asimilado un lenguaje de comunicacin, que les ha permitido entenderse, relacionarse, compartir conocimientos, y progresar. Del mismo modo, en una
red, para establecer la comunicacin entre las computadoras, se requiere
un lenguaje comn, el protocolo es dicho lenguaje.
Los protocolos son estndares software que se instalan en las computadoras de una red para denir el lenguaje, las reglas, los procedimientos,
y las metodologa utilizadas, para que las mquinas de la red, puedan
entenderse entre ellas. El uso de protocolos, permite a las computadoras comunicarse, intercambiar informacin, atender errores que puedan
producirse durante el intercambio, etc.
8
Protocolos de Comunicacin de Datos
En resumen, se podra decir que los protocolos son el lenguaje comn

que utilizan las computadoras para poder comunicarse dentro de una red
LAN (red de rea local) o WAN (red de rea extensa).
Todo protocolo deber tener muy bien estudiado tres aspectos :
La sincronizacin temporal.
La sincronizacin en el orden de los campos de un paquete.
La sincronizacin en el signicado que se d a los mensajes de los
campos de un paquete.
Estos tres requisitos deben ser cumplidos a la perfeccin por los protocolos para un correcto funcionamiento de la red.
A continuacin se describe cada uno de ellos:
Sincronizacin temporal : Hace referencia a las reglas que debe tener

denidas el protocolo, para que los paquetes enviados y recibidos a
travs de la red sean cronometrados y sincronizados en el tiempo.
Por ejemplo, cada paquete enviado tiene un tiempo de vida til,
y despus de que dicho tiempo expira, el paquete no es tenido en
cuenta y carece de validez. Esa marca de tiempo que tienen los
paquetes es til cuando una computadora destino recibe, de otra,
varias versiones de un mismo paquete.
Sincronizacin en el orden de los campos de un paquete : Todo
paquete de datos que viaja a travs de la red est subdividido en
diferentes campos. Una analoga similar a ello seran los campos
que tiene el registro de un archivo de datos. Cada campo cumple
una funcin especca dentro del paquete de datos; por ejemplo,
hay campos para indicar la direccin de destino del paquete, la
direccin de origen del paquete (remitente), la seccin de datos o
informacin, la longitud del paquete, el cdigo de vericacin de
error o paridad, el tiempo de vida del paquete, la identicacin del
paquete, el tipo de servicio para el que ser usado el paquete, la
versin del protocolo.
10
Sincronizacin en el signicado de los mensajes : No slo basta que

los campos de un paquete estn en el lugar apropiado y tengan una
longitud ja para lograr que un paquete sea correctamente interpretado. Adems, los protocolos deben tener reglas que denan
la sintaxis o el lenguaje apropiados en cada uno de los mensajes
inmersos en los campos del paquete, durante la transmisin o recepcin de los mensajes a travs de la red, para as lograr una
correcta interpretacin y evitar el uso de idiomas diferentes.
Niveles o Capas del Modelo OSI

La comunicacin entre las computadoras de una red requiere procedimientos muy complejos, en los que intervienen el hardware, el software
y los lenguajes de comunicacin (tambin denominados protocolos ).
Varias arquitecturas basadas en capas partieron del modelo OSI y a
partir de ste se generaron muchas otras como TCP/IP y B-ISDN .
El modelo de referencia OSI (Open Systems Interconnection, Interconexin de Sistemas Abiertos ) es un modelo de siete capas desarrollado
por la Organizacin Internacional de Normas (ISO ). En la gura 2-1 de
la pg. 11 se describe el modelo de capas de OSI.
Los niveles OSI se caracterizan por ser :
Lgicos : Independientes de lo fsico; independientes de las agrupaciones de software y hardware que existen actualmente.
Funcionales : Cada nivel cumple una tarea especca.
Jerrquicos : Cada nivel tiene autoridad sobre su inmediato inferior
y desarrolla tareas ms generales o menos especializadas que su
nivel inferior.
Ideales : Actualmente su implementacin es ms un modelo, un
marco de referencia, una norma, un deseo o una utopa que una re-
Figura 2-1
11
Modelo OSI - Estructura.
alidad totalmente llevada a la prctica por los fabricantes de hardware, software y protocolos de red.
El modelo de referencia OSI tiene como funcin :
Facilitar el estudio de los elementos que componen las redes y los

procesos que permiten la comunicacin entre ellas.
Mejorar la compatibilidad, estandarizacin y reglamentacin entre
los diferente fabricantes de software y hardware de red.
Minimizar las actualizaciones provocadas por los avances y cambios
en la tecnologa de software y hardware.
Funciones de cada uno de los niveles OSI:

Cada uno de los niveles OSI posee una funcin particular, las que se
detallan brevemente a continuacin:
Nivel l (fsico): En este nivel se denen las normas y especicaciones tcnicas del hardware de red (tarjetas de red, Hub, cableado,
conectores, topologas, arquitectura, etc.) y la forma de transmisin de las seales elctricas u pticas (bits) de un ordenador a
otro a travs del cableado.
Nivel 2 (enlace de datos): En este nivel se denen las normas y
especicaciones tcnicas de los controladores (drivers) de la arquitectura de red usada (Ethernet, ARCnet, Token Ring, ATM, etc.)
y de las especicaciones (ODI, NDIS, etc.) que permiten:
12
Establecer una sesin de enlace de datos con igual nivel de

otra computadora de la red.
La conversin de los datagramas recibidos desde el nivel de
red (nivel 3) en tramas; la trama es la estructura de datos
usada en este nivel a travs de la cual viaja la informacin.
La deteccin y correccin de errores que se puedan presentar.
El reenvo de tramas que no llegaron a destino.
Nivel 3 (red): En este nivel se denen las normas y especicaciones

tcnicas de los protocolos de red instalados en las computadoras
(por ejemplo, IPX de SPX/PX, o IP del TCP/IP), que permiten
fragmentar los paquetes del nivel de transporte en data gramas
y encaminarlos de una computadora a otra mediante ruteadores,
hasta llegar a la computadora destino; cada ruteador (servidor que
se encuentra en el medio, es decir, entre la computadora que enva
el mensaje y la que lo recibe) debe elegir el camino correcto de los
paquetes que arriban a l, para que stos se encaminen a travs de
los ruteadores que hay en las distintas sub redes y puedan llegar a la
computadora destino, para ello, esos ruteadores deben actuar como
un agente de trnsito, dando prioridad a determinados paquetes y
evitando las redes muy congestionadas (donde la prdida de tiempo
es muy grande) o los caminos poco seguros (donde el nmero le
prdidas de paquetes es muy alto).
Nivel 4 (transporte): En este nivel se denen las normas y especicaciones tcnicas de los protocolos de transporte instalados en las
computadoras (por ejemplo, SPX de SPX/IPX o TCP de TCP/IP),
que permiten hacer agrupaciones de datos, llamadas paquetes.
13
La ventaja de usar paquetes, en vez de, por ejemplo, enviar un

archivo completo, es que si ste llega defectuoso, habra que mandarlo todo nuevamente en vez de enviar un solo paquete, con la
consecuente prdida de tiempo y aumento del congestionamiento
de trco. Adems, si se enviara el archivo entero, los datos ocuparan la red por un cierto tiempo, impidiendo que otras computadoras puedan tambin enviar sus archivos. Como consecuencia, la
red se volvera muy impredecible respecto del tiempo de transferencia. Adems, se debe controlar el orden en que se envan o reciben
los paquetes y si los paquetes enviados llegan; de lo contrario, volver
a trasmitirlos; si los paquetes enviados no llegan porque en ese momento la red est muy congestionada, este nivel deber reducir el
nmero de paquetes trasmitidos, para evitar reenvos de paquetes
que congestionan an ms la red.
Nivel 5 (sesin): En este nivel se denen las normas y especicaciones tcnicas que permiten a dos computadoras abrir, establecer y cerrar una sesin (dilogo, transmisin) entre ellas. Al abrir
una sesin, ambas mquinas efectan un reconocimiento mutuo y
acuerdan detalles como la seguridad, el tamao de los paquetes o la
velocidad de transmisin. Un vez abierta la sesin, este nivel dene
cul de las dos computadoras transmite y durante cunto tiempo.
Nivel 6 (presentacin): Aqu se denen las normas y especicaciones tcnicas que permiten traducir, encriptar y comprimir los
datos recibidos (caracteres o grcos) del nivel de aplicacin, para
entregarlos en un lenguaje comprensible al nivel de sesin, y a la
inversa. Es decir, este nivel permite procesar los datos recibidos
del nivel de sesin que vienen de otra computadora y entregarlos al
nivel de aplicacin en un lenguaje comprensible.
Nivel 7 (aplicacin): Su funcin es proporcionar servicios a los
programas de aplicacin de red (correo electrnico, transferencia
de archivos, acceso a bases de datos o servicios de directorio), por
ejemplo, visualizar en pantalla, transferir archivos o imprimir hacia
otras computadoras que se encuentren en la misma red.
14
Protocolo TCP/IP
Introduccin
Sobre la base del modelo de referencia OSI se desarrollaron otros modelos

de red y arquitecturas completas para las redes de comunicacin. Este
modelo se desarroll a partir de un proyecto de investigacin patrocinado por el Departamento de Defensa de los Estados Unidos denominado
ARPANET .
Esta red debera permanecer funcionando en caso de que algunos de
los nodos de la red o incluso sus conexiones fueran daados por algn
motivo. La red ARPANET empez conectando centros de investigacin
del gobierno y luego universidades hasta convertirse en la red ms popular
de uso pblico hasta el momento: Internet .
Las computadoras de Arpanet tenan la capacidad de fragmentar un
gran archivos de informacin en pequeos paquetes de datos, para luego
enviarlos por la red. Este envo fragmentado de informacin imposibilitaba que cualquier PC se adueara de la red durante mucho tiempo.
Cada paquete de datos lanzado a la red tena una direccin de origen (de
la computadora que lo enviaba) y otra de destino (de la computadora
que lo reciba).
Los paquetes enviados por una PC a la red Arpanet podan ser encaminados por la mejor ruta alternativa, lo que haca que muchas veces
llegaran a su destino nal desordenados y por diferentes caminos. Gracias a que los paquetes enviados por la red eran numerados, la mquina
que se hallaba en la direccin de destino, al recibir dichos paquetes, los
poda ordenar, agrupar y reconstruir para crear el archivo original.
Si algn paquete se extraviaba, la computadora destino peda que se le
reenviara el paquete faltante. A esa habilidad conseguida en ARPANET
(poder encaminar los paquetes de datos) se la conoce como conmutacin
de paquetes. Esto cumpla los objetivos buscados por el Departamento
de Defensa de los Estados Unidos dado que, si durante la guerra quedaba
destruido algn enlace (bra ptica, microonda o satlite), los paquetes
15
de datos se encaminaban por otra ruta disponible de la red ARPANET.

Como fruto de las investigaciones de esa red, en 1974 naci el protocolo de comunicaciones TCP/IP (Transfer Control Protocolo / lnternet
Protocol, lo que en espaol signica Protocolo de Control de Transmisin
/ Protocolo Internet ).
TCP/IP diere del modelo de referencia OSI en que no maneja siete
capas sino cinco (en el modelo de TCP/IP no hay capas para sesin y
presentacin), segn muestra la siguiente gura 2-2 de la pg. 15.
Figura 2-2
Diferencia entre Modelo OSI y TCP/IP.
Este lenguaje comn que se instala en las computadoras de la red permite llevar a cabo la comunicacin entre diferentes plataformas, sistemas
operativos, topologas y arquitecturas por el mejor camino disponible.
Eso signica que, en las redes interconectadas, si existe algn camino deteriorado o congestionado con excesivo trco de informacin, los ruteadores
TCP/IP buscan el mejor camino alternativo.
Luego del xito y difusin que tuvo el protocolo TCP/IP, la Agencia
de Investigaciones Avanzadas de Proyectos de Defensa de Estados Unidos
16
(DARPA) lo puso a disposicin del mundo entero en forma gratuita y sin

ningn tipo de restricciones, y as, lleg a ser el protocolo de comunicacin
que usan hoy las computadoras en Internet.
Funciones TCP/IP
En realidad, el protocolo TCP /IP no es un solo protocolo, sino dos:
TCP pertenece al nivel OSI de transporte; IP, al nivel de red.
Funciones de TCP
Las funciones son las siguientes:
Controlar y asegurar el orden en que se envan y reciben los paquetes de datos durante una transmisin a travs de la red, entre dos
mquinas remotas.
Asegurar que los paquetes enviados y recibidos lleguen a destino;
en caso contrario, arbitrar los medios para que sean reenviados.
Asegurar que los paquetes enviados y recibidos lleguen en buen
estado; en caso contrario, arbitrar los medios para que sean reenviados.
Funciones de IP
Las funciones son las siguientes:
Elegir el camino correcto (rutear) de los paquetes de datos que viajan mediante la red pasando a travs de los diferentes ruteadores
para llegar a la computadora destino. Los ruteadores son dispositivos o computadoras que vinculan las redes entre s. Su funcin
es encaminar los paquetes de datos recibidos para que continen el
trayecto hacia su destino nal. Tanto las PCs que envan o reciben
datos a travs de la red como los ruteadores que encaminan dichos
paquetes, hacen uso del protocolo IP para lograr una comunicacin
estandarizada, y as, entenderse y cumplir sus objetivos.
17
Denicin del Nivel IP

El protocolo IP surgi para interconectar redes. El principal trabajo de
IP es buscar una ruta para que los datos lleguen al destino. Con respecto
al modelo OSI (7 capas) podemos ubicar a este protocolo en el tercer nivel
(Capa de Red).
Una de las principales caractersticas de IP es que no esta orientado
a conexin, esto quiere decir que
para la transmisin de datos entre dos host no se construye ningn
vnculo que los conecte antes del envo de los mismos.
IP utiliza como unidad de transmisin el datagrama .
Cada host se individualiza mediante una direccin de 32 bits, dividida en 4 octetos. En ella se especica un identicador de red y un
identicador de host.
Para administrar estas direcciones se denieron diferentes clases:
Clase A: 8 bits para red, 24 bits para hosts.

Clase B: 16 bits para red, 16 bits para hosts.
Clase C: 24 bits para red, 8 bits para hosts.
Clase D y E: reservadas (D para multicasting).
Las direcciones origen y destino a nivel IP nunca cambian en la
vida de una trama.
Para permitir a los dispositivos intermedios transmitir datagramas,

ste cuenta con un encabezado en el que se especican todos los parmetros de control necesarios para que el datagrama llegue a destino (direccin
origen, direccin destino, tipo de protocolo, etc.).
Adems del encabezado, el datagrama contiene la porcin de datos
que se est queriendo transmitir.
El encabezado tiene una parte ja de 20 octetos y una parte opcional
de longitud variable.
18
Estructura del Datagrama

La estructura se muestra en la gura 2-3 de la pg. 18.
Figura 2-3 Estructura del Datagrama.
Versin : Indica a qu versin del protocolo pertenece cada uno de los

datagramas. Mediante la inclusin de la versin en cada datagrama, no
se excluye la posibilidad de modicar los protocolos mientras la red se
encuentra en operacin.
H Len : Especica la longitud que tiene el encabezado en palabras de
32 bits, es necesario puesto que la longitud del encabezado es variable.
Tipo Servicio: Indica el tipo de servicio, es posible tener varias combinaciones con respecto a la seguridad y a la velocidad.
Longitud Total del Datagrama : Incluye todo el datagrama, tanto el
encabezado como los datos, est expresado en bytes.
Identicador del Datagrama : Se necesita para permitir al destino
determinar a qu datagrama pertenece el fragmento recin llegado. Todos los fragmentos de un datagrama contienen el mismo identicador (el
identicador se asigna aleatoriamente).
19
Bit D : Si este campo est seteado con 1 indica que el datagrama no

se puede fragmentar.
Bit M : Si este bit se encuentra en 1 signica que existen ms fragmentos, todos los fragmentos excepto el ltimo debern tener este bit
seteado en 1.
Oset : Es el desplazamiento del fragmento dentro del datagrama
original. Se utiliza para regenerar el datagrama original.
TTL (Time To Live): Es un contador que se utiliza para limitar el
tiempo de vida de los paquetes. Cada vez que el datagrama pasa por
un router el campo TTL se decrementa en 1, cuando llega a cero el
datagrama se descarta.
Protocolo: Indica el protocolo de nivel superior que el datagrama est
transportando.
Checksum : Es el campo que se utiliza para el reconocimiento de errores en IP, el alcance es sobre el encabezado. Divide al encabezado
en palabras de 16 bits, las suma en complemento a 1 y al resultado los
complementa a 1.
Direcciones Origen y Destino: Especican las direcciones IP del host
origen y del host destino respectivamente.
Opciones : Este campo se utiliza con nes de seguridad, informe de
errores, depuracin, as como para otro tipo de informacin. Permite
tambin incluir a versiones de protocolos subsiguientes informacin que
no est presente en el diseo original.
Ruteo
Como se mencion anteriormente, IP es responsable de llevar un datagrama al destino indicado en el encabezado, pero poco se dijo de cmo
se hace. La tarea de encontrar cmo llevar un datagrama al destino es
20
conocida como routing .

Es necesario conocer el modelo en que IP est basado. IP asume que
cada host esta conectado a una red local, tambin se asume que el host
puede enviar el datagrama dentro de la misma red. Pero el problema
surge cuando se quiere enviar un datagrama a un host que se encuentra
en una red diferente.
Este problema es manejado por los gateways (dispositivos intermedios). Un gateway es un sistema que conecta a una red con una o ms
redes, generalmente son computadoras normales con ms de una interface de red. En muchos casos, gateways de propsitos especiales proveen
mejor performance y conabilidad que los gateways de propsitos generales.
El ruteo en IP se basa en el nmero de red de la direccin destino.
Cada computadora tiene una tabla de nmeros de red. Para cada nmero
de red se tiene un gateway que es el que se intentar alcanzar si se desea
enviar un datagrama a la red asociada.
Hay que notar que el gateway no tiene que estar conectado directamente a la red, pero ste debe ser tericamente el mejor ubicado para
acceder a la red.
Cuando una computadora desea enviar un datagrama, primero chequea
si la direccin destino est en su red local, si esto ocurre el datagrama
puede enviarse directamente, de otra manera el sistema espera encontrar
una entrada en la tabla para la direccin destino y utiliza ese gateway
para enviar el datagrama.
Las tablas pueden volverse muy grandes por lo cual existen tcnicas
para reducir el tamao de las mismas. Una de estas tcnicas consiste en
denir un default gateway que es la nica salida hacia fuera de la red.
Este gateway debe conectar a la red local con las dems redes. En este
caso no necesitaremos tener una entrada por cada red en el mundo, sino
que simplemente tenemos un gateway como default, y si no encontramos
una ruta especca para un datagrama, ste es enviado al gateway default.
Un gateway por default se puede denir aunque existan varios gateways en la red.
21
Existe la posibilidad de que un gateway mande un mensaje especicando que l no es la mejor opcin e informando cual s lo es.
La mayor parte de las interfaces de red son diseadas para usar este
tipo mensajes para agregar o modicar entradas en la tabla.
Se recomienda que los host en forma individual no traten de buscar el
camino hacia el destino nal por ellos mismos, sino que dejen esta tarea
a los gateways.
Para que los gateways puedan armar sus tablas de ruteo se necesitan
protocolos de ruteo.
Detalles de Direccionamiento: Subredes y Broadcasting

Algunas organizaciones creen conveniente dividir su nmero de red en
subredes, esto se realiza utilizando algunos de los bits de la direccin IP
reservados para host. Para determinar a que subred pertenece una direccin se utiliza una mscara (se efecta un AND lgico entre la direccin
y la mscara).
Supongamos que se cuenta con una red R1 a la que le fue asignada
una direccin de Clase B 128.6; y se desea usar el tercer octeto de la
direccin IP para indicar cules host son Ethernet dentro de la red.
Esta divisin no tiene sentido fuera de R1, una computadora de otra
red enviar los datagramas direccionados a 128.6 de la misma manera.
De esta manera las computadoras fuera de R1 no tendrn diferentes rutas
para 128.6.4 o 128.6.5. Pero dentro de la red R1, a las direcciones 128.6.4
y 128.6.5 se las ve como redes separadas. En efecto los gateways dentro
de la Red R1 tienen entradas separadas para cada subred, mientras que
los gateways que se encuentran afuera de R1 cuentan con una entrada
para 128.6.
22
Dentro de las direcciones IP los nmeros 0 y 255 tienen un signicado

especial, o son reservado para mquinas que no conocen su direccin . En
ciertas circunstancias es usado por mquinas que no conocen el nmero
de red en la que se encuentra, an conociendo su propio nmero de host,
por ejemplo 0.0.0.23 es un mquina que conoce su nmero de host pero
desconoce el nmero de red a la cual pertenece.
El nmero 255 es usado para broadcast. Un mensaje de broadcast
es aquel que todos los host pueden leer. Este es usado en algunas situaciones donde se desconoce la direccin del host con el que se desea una
comunicacin. Algunas veces no se conoce la direccin del name server
ms cercano, en este caso se debe enviar un Request como broadcast.
Existen casos en donde un host est interesado en enviar la misma
informacin a varios host. Es ms simple entonces, enviar un simple
broadcast a las mquinas en cuestin que enviar un datagrama individualmente a cada host. Para enviar este tipo de broadcast se debe usar una
direccin que est construida usando el nmero de red seguido de unos en
la parte de la direccin que corresponda al nmero de host (por ejemplo
si la mquina se encuentra sobre la red 128.6.4 deber usar 128.6.5.255
como broadcast).
La implementacin de broadcast depende del medio fsico, en muchos
casos no es posible usarlo, sin embargo s es posible sobre Ethernet.
Debido a que 0 y 255 son usados para direcciones desconocidas y
de broadcast respectivamente, un host nunca debe tener asignado como
direccin ni la 0 y ni la 255.
Las direcciones nunca deben comenzar con 0 o 127.
23
Fragmentacin y Reensamblado del

Datagrama
TCP/IP est diseado para usarse para diferentes clases de redes. Desafortunadamente los diseadores de redes no se ponen de acuerdo acerca
del tamao optimo del paquete a ser enviado. Ethernet puede usar paquetes de 1500 octetos de longitud, mientras que los paquetes de Arpanet
tienen un mximo de alrededor de 1000 octetos. Hay redes de gran velocidad que pueden usar paquetes de mayor longitud. En principio se
puede pensar que IP utiliza el paquete ms pequeo, pero esto causa
serios problemas de performance; cuando se transere archivos grandes,
los grandes paquetes son ms ecientes que los chicos. Por lo tanto lo
que es deseable es usar el tamao ms largo posible.
Se supone que se cuenta con dos host en diferentes redes Ethernet
(capaces de transmitir paquetes de 1500 octetos) conectadas a travs de
una red que las vincula pero que transmite paquetes de 200 octetos. La
mquina origen transmite un datagrama de 1500 octetos. Cuando ste
paquete llega al link de 200 octetos debe ser fragmentado a este nmero
para poder llegar a la red destino y ser reensamblado en el host destino.
A este proceso se lo llama fragmentacin y reensamblado.
ARP: Address Resolution Protocol

El ARP es un protocolo para resolver el mapeo de direcciones IP a direcciones de nivel 2. Trabaja en forma paralela a IP. Se describir el
funcionamiento de este protocolo mediante un ejemplo:
Se supone que se tiene un Host 128.6.4.194 (A) que se quiere conectar
con el Host 128.6.4.7 (B). Vericamos primero que B se encuentre sobre
la misma red, entonces se examina la tabla de ARP local para vericar
que existe la direccin Ethernet asociada a la direccin IP en cuestin,
si es as se enva el datagrama.
24
Ahora se supone que el host no encuentra la direccin Ethernet asociada en la tabla de ARP local, entonces se utiliza el protocolo ARP para
enviar un Request. Todos los Host escuchan el ARP Request. Cuando
un host interpreta que el ARP Request es para l, responde. Esta respuesta se hace mediante un ARP Reply informando al que origin el
request la direccin Ethernet del que responde. El host origen salvar
la informacin en la tabla de ARP local para enviar futuros paquetes
directamente.
La mayora de los host tratan a las tablas de ARP como una cach y
limpian peridicamente las entradas que no son usadas.
Se debe notar que la forma de enviar en ARP Request es por medio
de un paquete de broadcast. Los ARP request no se pueden enviar
directamente a un Host determinado. Muchos host utilizan los ARP
Request que le arriban para actualizar su propia tabla ARP.
Sistema de Dominios
Generalmente, el software de red utiliza direcciones IP de 32 bits para
enviar datagramas, sin embargo los usuarios preeren utilizar nombres
en lugar de nmeros. De esta manera se podra contar con una base
de datos que permita asociar nombres a direcciones IP, esto implicara
tener una tabla con las direcciones-nombres del resto de los Host. Esta
solucin es simple si contamos con una red pequea, pero se vuelve poco
prctica para redes de gran tamao.
En el caso de redes grandes en lugar de tablas se tiene un conjunto
de servidores de nombres interconectados.
Los servidores de nombres forman un rbol que se corresponde con
una estructura institucional. Estas instituciones conforman el sistema
de dominios y delegan la autoridad sobre los nombres a instituciones
jerrquicamente inferiores en el rbol del sistema de dominios.
Un ejemplo de un nombre es AYELEN.INFO.UNLP.EDU. Este nom-
25
bre representa a una computadora del Departamento de Informtica.

Para saber dnde se encuentra EDU, se debe consultar a un servidor
raz. EDU mantiene a las instituciones educacionales. El servidor raz
cuenta con varios servidores para EDU, por lo tanto se debe consultar a
EDU acerca del servidor para UNLP y as sucesivamente hasta completar
la direccin. Cada uno de estos niveles es conocido como dominio.
Afortunadamente, generalmente no es necesario realizar este procedimiento. Se debe notar que el servidor de nombres raz es el servidor
de nombres del nivel ms alto de los dominios tal como EDU. De esta
manera un simple query sobre el server raz llevar a UNLP.
Adems el software recuerda las consultas anteriores, esto permite
recordar dnde buscar los servidores para un nombre dado. Cada una de
stas piezas de informacin tiene un tiempo de vida asociado (del orden
de das), luego de este tiempo la informacin expira y debe ser obtenida
nuevamente.
Cada nombre de dominio es un nodo en una base de datos. El nodo
puede tener registros que especican un nmero de propiedades diferentes
(por ejemplo: direcciones IP, tipo de computadora y una lista de servicios
provistos para una computadora). Un programa puede preguntar por una
pieza especca de informacin, o por toda la informacin acerca de un
nodo dado. Tambin es posible denir un alias para un nodo de la base
de datos.
El sistema de dominios tambin puede usarse para almacenar informacin acerca de los usuarios, listas de mail y otros objetos.
Existe un standard que dene la operacin sobre las base de datos,
tales como protocolos usados para realizar consultas sobre ellas. Cada
red debe ser capaz de realizar tales consultas.
26
Protocolos que Trabajan Junto con

TCP/lP
El protocolo TCP/IP trabaja en el nivel OSI de transporte y red. Pero en
los niveles de aplicacin, presentacin y sesin, trabajan otros protocolos
que colaboran para desempear determinadas funciones.
Protocolos Usados en el Nivel OSI de Aplicacin,

Presentacin y Sesin
HTTP (protocolo de transferencia de hipertexto): Desde una aplicacin

llamada navegador, permite a una computadora cliente leer y ejecutar pginas web (archivos HTML) de un servidor web que se encuentra
dentro de la Intranet o en Internet. Estas pginas pueden incluir texto,
imgenes, sonido, video y vnculos a otros archivos HTML, a los que se
puede acceder con un simple clic del mouse.
Windows permite instalar un servidor web, mediante Internet Information Server (es un servidor web y FTP). Puede ser instalado en el
sistema operativo Windows NT 4.0, Windows 2000 o Windows XP (Profesional).
FTP (protocolo de transferencia de archivos): Permite a una computadora cliente transferir archivos (subir o bajar) desde un servidor
FTP situado dentro de la Intranet o en Internet. En Windows NT 4.0,
2000 Y XP (Profesional), se puede crear un servidor FTP mediante la
aplicacin Internet Informacin Server (IIS ).
TELNET : Permite que una computadora tenga acceso remoto sobre
otra, e incluso, que ejecute sus programas a distancia a travs de Internet.
SMTP (Protocolo Simple de Transferencia de Correo): Permite que
una computadora con TCP/IP pueda enviar a travs de Internet correo
electrnico (e-mail) a un servidor SMTP, proporcionado generalmente
por el proveedor de Internet, que ser el encargado de reenviar los men-
27
sajes recibidos para que lleguen a destino.

POP3 (Protocolo de Ocina de Correo versin 3): Permite que una
computadora con TCP/IP pueda recibir correo electrnico desde un servidor POP3, proporcionado por el de Internet. En Internet encontraremos
muchos servicios que nos ofrecen la posibilidad de tener una cuenta de
correo de tipo POP3. Esto signica, justamente, la posibilidad de administrar una aplicacin denominada cliente de correo electrnico, como
puede ser Outlook Express, Eudora entre otros programas.
Mtodos de Comunicacin
Los protocolos de transporte se utilizan para enviar informacin de un
puerto a otro consiguiendo as que haya comunicacin entre los programas
de aplicacin. Utilizan un mtodo de comunicacin orientada a conexin
o bien un mtodo sin conexin.
TCP es un protocolo orientado a conexin y UDP es un protocolo
de transporte sin conexin.
El protocolo TCP orientado a conexin establece un vnculo de comunicacin entre una direccin del puerto fuente y una direccin del puerto
destino. Los puertos se conectan entre s a travs de este vnculo hasta
que la conexin naliza y el vnculo se rompe. Un ejemplo de protocolo
orientado a conexin es una conversacin telefnica. Esta se establece,
la comunicacin tiene lugar y la conexin naliza.
La abilidad de la comunicacin que se establece entre los programas fuente y destino se asegura a travs de mecanismos de deteccin y
correccin de errores que se implementan en el TCP.
TCP implementa la conexin como un ujo de bytes desde la fuente
hasta el destino. Esta caracterstica permite el uso de clases de E/S de
ujo que ofrece Java.io.
El protocolo sin conexin UDP diere del protocolo orientado a conex-
28
in en que no establece un vnculo mientras dura la conexin. Un ejemplo

de protocolo sin conexin es el correo postal. Para enviar algo por correo,
simplemente se escribe la direccin de destino (y opcionalmente un remitente) en el sobre y se echa al buzn.
Cuando se usa UDP, un programa de aplicacin escribe el puerto
de destino y la direccin IP en un datagrama y enva este ltimo a su
destino. UDP es menos de ar que TCP debido a que en el protocolo
no hay seguridad de entrega o mecanismos de deteccin y correccin de
errores.
Los protocolos de aplicacin como son FTP, SMTP y HTTP utilizan
TCP para ofrecer una comunicacin able y basada en un ujo entre los
programas clientes y servidor. Otros protocolos utilizan UDP, cuando la
velocidad de entrega es ms importante que la abilidad.
Captulo 3
Sistema Distribuidos
Introduccin
La forma ms elemental de interpretar un sistema distribuido es la de
un sistema computacional compuesto por diferentes procesadores interconectados. Normalmente, esta interconexin estar soportada por una
red abierta, basada en un conjunto de protocolos estndar que permita
la colaboracin entre aplicaciones, escalabilidad y portabilidad.
Esta interpretacin no es, sin embargo, completa; los componentes
de una aplicacin distribuida pueden residir en la misma mquina o en
distintos nodos de la red y, por lo tanto, al hablar de las interconexiones
no se trata tanto de que se produzcan a travs de enlaces hardware, sino
de comunicaciones entre procesos.
Las siguientes secciones muestran los principales conceptos: enfoques
al diseo de aplicaciones distribuidas, aplicacin distribuida en Internet,
sockets, RPC - llamadas a procedimientos remotos, diferentes enfoques
29
30
para la construccin de una aplicacin distribuida, el modelo de objeto

distribuido de Java y seguridad en una aplicacin distribuida.
Enfoques al Diseo de Aplicaciones

Distribuidas
Una aplicacin distribuida es una aplicacin cuyo procesamiento se distribuye por mltiples computadoras de una red.
Las aplicaciones distribuidas son capaces de servir a la vez a usuarios
mltiples y, dependiendo de su diseo, hacer uso ms adecuado de los
recursos de procesamiento.
Las aplicaciones distribuidas se implementan tpicamente como sistemas cliente / servidor , organizados de conformidad con la interfaz de
usuario, el procesamiento de la informacin y las capas de procesamiento
de la informacin como se ilustra en la gura 3-1 de la pg. 30.
Figura 3-1 La organizacin de sistema distribuido.
La capa de interfaz de usuario viene implementada por una aplicacin

cliente. Los programas de correo electrnico y navegadores web constituyen ejemplos del componente de interfaz de usuario de las aplicaciones
distribuidas.
La capa de procesamiento de la informacin la implementa la aplicacin cliente, una aplicacin servidor o una aplicacin con soporte de
servidor. Por ejemplo, una aplicacin puede utilizar un cliente de bases
31
de datos para convertir las selecciones del usuario en instrucciones SQL;

un servidor con acceso, a base de datos, puede ser utilizado para admitir
la comunicacin entre el cliente y un servidor de base de datos, y el servidor de base de datos puede usar software de informacin para procesar
la informacin solicitada por un cliente.
La capa de almacenamiento de la informacin la implementan servidores de bases de datos, servidores Web, servidores FTP, servidores de
archivo y cualquier otro servidor cuya nalidad sea la de almacenar y
recuperar informacin.
Aplicaciones Distribuidas en Internet

La popularidad de la Internet y de la Web ha supuesto la congestin de
la red. Las computadoras son accesibles directamente entre s a travs
del protocolo TCP/IP.
Esta conectividad mundial ha hecho crecer las aplicaciones distribuidas
que se ejecutan en la estructura cliente / servidor de Internet. Estas aplicaciones de primera generacin admiten la comunicacin cliente / servidor en base a protocolos especcos de la capa de aplicacin como son
HTTP, FTP Y SQL*NET (ver gura 3-2 de la pg. 32).
Normalmente un programa cliente se ejecuta en mltiples computadoras Host. El cliente utiliza TCP para conectarse con un servidor que
escucha en un puerto conocido. El cliente realiza una o ms solicitudes al
servidor. Este servidor procesa las solicitudes del cliente, posiblemente
utilizando programas de pasarela o servidores de fondo y reenva la respuesta al cliente.
Por ejemplo, una aplicacin nanciera que se est ejecutando en la
PC puede invocar mtodos de objetos que se estn ejecutando en otra
PC que pertenezca a la Intranet de la empresa. Puede ser que estos
32
Servidor
Black-end
Servidor
Black-end
Servidor
De aplicacin
cliente
cliente
cliente
Figura 3-2 Estructura del servidor.
objetos busquen en las bases de datos de empresas la informacin que

la aplicacin nanciera est utilizando, que procesen esta informacin de
acuerdo con las reglas comerciales de la empresa y que la faciliten a su
aplicacin nanciera.
Los resultados que haya calculado la aplicacin nanciera pueden ser
automticamente reenviados a un objeto de distribucin de informacin,
el cual pondr los resultados a disposicin de otros empleados de la empresa, adems de a los agentes y clientes seleccionados. La gura 3-3 de
la pg. 33 ilustra este ejemplo de aplicacin distribuida.
Sockets
La comunicacin entre cliente / servidor se realiza a bajo nivel sobre un
determinado protocolo de red, siendo TCP/IP el ms empleado. Cada
dispositivo en red recibe una direccin IP nica (al menos en el mbito
33
Objetos de
Normas
Comerciales
Aplicacin
Financiera
Objeto
de
Bsqueda
Objeto de
Distribucin de
Informacin
Figura 3-3 Ejemplo de aplicacin distribuida.
de esa red) que la identica para sus comunicaciones. Un punto nal

de comunicaciones queda denido por la direccin IP y un nmero de
puerto, es decir, un mismo dispositivo puede tener mltiples lneas de
comunicacin abiertas, al menos una por cada puerto empleado.
La popularidad actual de TCP/IP se debe a Internet, que lo emplea
como protocolo de red, y ha sido el protocolo empleado en mquinas
Unix desde su inicio.
A principios de los 80 la distribucin UNIX de Berkeley introdujo el
modelo de sockets como un mecanismo de comunicacin entre procesos
[16, Leer McKusick Karels-89], que se ha convertido en el estndar
de facto para programacin en red sobre TCP/IP. Sin embargo, su API
(interfaz de programacin de aplicaciones) puede en principio usarse con
34
otros protocolos de red.

Un socket [24, Stevens-90] es un punto nal de comunicacin, identicado en TCP/IP mediante la direccin IP y un puerto. Existen dos
tipos de sockets: orientados a conexin (TCP) y sin conexin, tambin
llamados datagramas (UDP).
TCP crea un circuito virtual entre los procesos que comunica, por lo
que los sockets sobre TCP se consideran ables. Los datagramas no son
ables ni se asegura el orden o no duplicacin de los datos enviados, pero
permiten el envo de mensajes broadcast, a ms de un destino nal.
Un servidor que emplea sockets debe asociarse a una determinada
direccin, donde espera continuamente la llegada de datos.
Un cliente debe conocer cul es esa direccin especca para enviarle
datos.
La informacin que se transmite no tiene ningn signicado para los
sockets, que actan nicamente como puntos de entrada y salida para
las comunicaciones. Es la aplicacin la que debe interpretar esos datos y
producir, posiblemente, una respuesta (ver gura 3-4 de la pg. 34).
Figura 3-4 Utilizacin de sockets.
35
RPC - Llamadas a Procedimientos

Remotos
Se ha mencionado que las aplicaciones distribuidas se implementan tpicamente como sistemas cliente / servidor; seguidamente se ver un ejemplo
sencillo de autenticacin .
Un cliente suministra un nombre (login ) y una clave (password ), y
el servicio comprueba su validez. Empleando sockets, el cliente debe
conectarse al servidor y enviar en una cadena de bytes la informacin
necesaria, el nombre y la clave, que se supone son cadenas de caracteres.
No existe ningn requisito, sobre cmo enviar esa informacin, y el
servidor debe especicar qu formato espera. Por ejemplo, un primer
byte que indique la longitud del nombre, seguido por tantos bytes como
caracteres tengan el nombre, y luego otro byte que indique la longitud
de la clave y tantos bytes como caracteres tenga esa clave.
Es responsabilidad del cliente, aplicar correctamente el formato esperado. Y este formato debe especicarse con mayor detalle: qu orden
de bytes se espera, qu codicacin de caracteres, ASCII o EBCDIC, etc.
Adems, la aplicacin debe gestionar los errores de comunicaciones.
Desde el punto de vista del servidor [22, Smith Ungar-95], si precisa
soportar varios clientes simultneamente, es tambin la aplicacin la que
debe incluir toda la lgica de concurrencia y de gestin de mltiples
clientes.
Una librera puede soportar el formateo/deformateo de determinados
tipos de datos, deniendo cmo transferir cadenas de caracteres, tipos enteros, etc. Si tanto el servidor como el cliente emplean la misma librera,
parte de los anteriores problemas se solucionan. suministra este soporte
de librera, a la vez que realiza una abstraccin de llamadas a procedimientos. Siguiendo el ejemplo anterior, el servidor puede especicarse
como una funcin denida de la siguiente manera:
int validate (in char* login, in char *password).
36
Al emplear un compilador RPC sobre esta denicin, se generan dos

porciones de cdigo. Una se llama stub del cliente, y lo que hace es
proporcionar un procedimiento con la misma denicin dada.
El cliente invoca este procedimiento (ver la gura 3-5 de la pg. 36),
y ste automticamente prepara la cadena de bytes a enviar al servidor,
formateando los datos y envindolos a travs del socket.
La segunda porcin de cdigo se denomina stub del servidor, verica
continuamente el socket donde recibe la informacin, que deformatea y
enva al servidor. Cuando se elabora la respuesta, sta se enva por el
camino inverso.
De esta forma, se accede al servidor como si fuera local, al que se invoca mediante procedimientos, tal como si fuera una librera del sistema.
Figura 3-5 Filosofa del RPC.
37
Diferentes Enfoques Para la Contruccin de Aplicaciones Distribuida
Entorno de Computacin Distribuida
El Entorno de Computacin Distribuida (DCE ) constituye otro enfoque

para la construccin de aplicaciones distribuidas.
El DCE fue desarrollado por la Open Software Foundation, a la que
se llama ahora Open Group. DCE integra una serie de servicios y tecnologas fundamentales para construir aplicaciones distribuidas.
Los sistemas distribuidos estn organizados en celdas, que son grupos
de recursos, servicios y usuarios de procesamiento que admiten funciones
comunes y que comparten un conjunto comn de servicios del DCE. Por
ejemplo, se pueden organizar las celdas de acuerdo con las funciones
de la empresa. En este caso, se puede tener celdas separadas para los
departamentos nanciero, de produccin y de marketing.
Los servicios y tecnologas que se usan, en una celda del DCE constan
de:
Servicios de Directorio: Almacenan los nombres de los recursos

que estn disponibles dentro del entorno distribuido. El Servicio
de Directorio de Celda (CDS ) admite los nombres en una celda,
mientras que el Servicio de Directorio Global (GDS ) admite los
nombres en todas las celdas de una empresa. GDS implementa el
servicio de directorio X.500.
Servicio de Archivos Distribuidos (DFS): Un servicio opcional del
OCE que proporciona un sistema de archivos perfecto que opera
en todas las computadoras que hay en una celda.
Servicio de Horas Distribuidas (DTS): Se usa para sincronizar la
hora en todas las computadoras que hay en una celda.
Servicio de Seguridad : Se utiliza para autenticar los usuarios de
38
celda y controlar el acceso a los recursos que estn disponibles dentro de la misma.
Llamadas de Procedimientos Remotos (RPC): Reemplazan a los

sockets TCP como mecanismo bsico para la comunicacin cliente
/ servidor. Las RPC se implementan como capa que se construye
por encima de la capa de transporte TCP/IP y gestiona de forma
transparente las cuestiones relativas al manejo de la conexin y de
los protocolos.
Hilos del OCE : Parecidos a los hilos de Java. Se trata de procesos
ligeros que simplican el diseo de aplicaciones cliente / servidor.
El DCE se dice que es de soporte intermedio, ya que no se trata
de un producto autnomo, sino de un paquete de servicios que se
integra en un sistema operativo o entorno operativo. Estos servicios se usan como alternativa a la construccin de las aplicaciones
distribuidas.
El Modelo de Objeto Componente Distribuido

El Modelo de Objeto Componente Distribuido, o DCOM, es el planteamiento
de Microsoft al desarrollo de sistemas distribuidos.
El DCOM se basa en el COM, que constituye el ncleo de la estrategia de desarrollo orientado a objetos de Microsoft. Dado que el DCOM
es esencialmente una extensin del sistema distribuido del COM, la comprensin de este ltimo es fundamental para entender el primero.
Comprensin del COM

COM es el fruto de la tecnologa Incrustacin y Vinculacin de Objetos,
de Microsoft.
El COM era una solucin a los problemas antiguos de OLE (se utilizaba en versiones antiguas de Windows para admitir documentos compuestos, o documentos que son el producto de aplicaciones mltiples.)
39
Los objetos COM constituyen instancias de las clases y se organizan

en interfaces. Las interfaces son simples colecciones de mtodos.
A los objetos COM slo se puede acceder a travs de sus mtodos,
y cada objeto COM se implementa dentro de un servidor. Un servidor
se puede implementar como biblioteca de vnculos dinmicos, proceso
independiente o servicio operativo.
El COM evita los detalles de la implementacin y presenta una interfaz nica y uniforme para todos los objetos, independientemente de
cmo est implementado cada objeto.
La biblioteca del COM es clave para implementar esta interfaz comn
entre los objetos.
Est presente en todo sistema que admita el COM y proporciona
un directorio de todas las clases que estn disponibles en ese sistema.
La biblioteca del COM mantiene informacin sobre las clases que estn
disponibles en el registro del sistema.
Cuando un objeto COM accede a otro, en primer lugar invoca a las
funciones de la biblioteca del COM. Estas funciones se pueden utilizar
para crear un objeto COM a partir de su clase u obtener un indicador a
sus interfaces.
El tiempo de ejecucin del COM es un proceso que da soporte a
la biblioteca del COM para implementar sus funciones. Lo admite el
Administrador de Control de Servicios.
El objeto invocante utiliza sealizadores de interfaz para invocar los
mtodos del objeto al que accede a travs de la biblioteca del COM.
Los sealizadores que usan los objetos COM pueden ser empleados por
objetos que estn escritos en cualquier lenguaje de programacin.
El lenguaje de denicin de interfaz que se usa para denir las interfaces y mtodos del COM procede del DCE. El COM dene tambin
un estndar de interfaz binaria. Este estndar ayuda a promocionar la
independencia del lenguaje.
Nota: El COM diere de otros sistemas orientados a Objetos en su
soporte a la herencia. Las clases del COM no heredan la implementacin
40
de mtodos a partir de sus superclases. Solo heredan la denici6n de esas

interfaces. Esto implica que todos los mtodos deben ser implementados
de nuevo cada vez que se declare una subclase.
El COM ofrece una solucin a este problema, llamada agregacin.
Utilizando la agregacin, una clase puede heredar una interfaz completa
copiando la interfaz de su superclase. No obstante,1a clase no puede
omitir los mtodos individuales de la interfaz de herencia.
Del COM al DCOM

El DCOM es esencialmente el COM distribuido sobre computadoras mltiples. El DCOM permite a los objetos COM que se ejecutan en una
computadora crear objetos COM en otras computadoras y acceder a sus
mtodos. La ubicacin del objeto remoto es transparente.
Utilizando el DCOM se accede a los objetos remotos de una manera
exactamente igual que a los objetos locales.
Con el n de que un objeto que est en un sistema local acceda a los
mtodos de un objeto que est en un sistema remoto, el sistema local
debe registrar la clase del objeto remoto en su registro local.
El objeto local inconsciente de la ubicacin del objeto al que est
accediendo, crea el objeto remoto y/u obtiene un indicador a sus mtodos
mediante la invocacin de las funciones de su biblioteca del COM local.
La biblioteca del COM procesa las llamadas de funcin por medio de su
tiempo de ejecucin del COM local.
El tiempo de ejecucin del COM comprueba la clase del objeto al que
se est accediendo en el registro del sistema.
Si el registro indica que la clase se dene en el registro de una mquina
remota, el tiempo de ejecucin del COM local contactar con el tiempo
de ejecucin del COM de la mquina remota y le pedir que cree el objeto
remoto o que se invoquen sus mtodos.
El tiempo de ejecucin del COM remoto llevar a cabo la peticin si
sta la aceptan las normas de seguridad del sistema.
41
Los procesos del tiempo de ejecucin del COM de mquinas separadas

se comunican entre s por medio de un mecanismo de la RPC que se
denomina RPC de objetos, u ORPC.
La ORPC se basa en la RPC de Microsoft, que es, en esencia, la RPC
del DCE.
La ORPC puede ser congurada para utilizar una serie de protocolos
de transporte, pero funciona mejor con el UDP. Dado que la mayora de
los corta fuegos bloquean al UDP, es necesario utilizar el TCP junto a la
ORPC para construir aplicaciones distribuidas que funcionen en Internet.
Estas normas, por lo general, son las predeterminadas de las normas de seguridad de Windows NT, pero pueden adaptarse o restringirse
en una aplicacin determinada. La gura 3-6 de la pg. 54 resume el
funcionamiento del DCOM.
Modo de Funcionamiento del DCOM

Si bien el DCOM es un producto de Microsoft, constituye un estndar
abierto que se ha transportado a otras plataformas, como UNIX.
Microsoft trata de que el DCOM sea una solucin de plataforma
cruzada para el desarrollo de aplicaciones distribuidas. As, los usuarios
de Windows la han recibido muy bien, pero el xito en las aplicaciones
de plataformas cruzadas ha sido ms bien mediocre.
Una de las caractersticas a destacar del DCOM es el soporte que da
a las aplicaciones.
La seguridad del DCOM integra y ampla el modelo de seguridad de
Windows NT. Permite que se tomen decisiones de control de acceso con
un alto nivel de granularidad. Por ejemplo, resulta posible especicar si
a un objeto se le permite crear o invocar a los mtodos de otro.
El DCOM tambin ofrece una seguridad en la comunicacin exible y fuerte. Se pueden usar una serie de mecanismos de encriptacin
para proteger la informacin en la forma en que sta se transmite de un
objeto COM a otro. Windows NT 5.0 ampla estas posibilidades de en-
42
criptacin a la autenticacin basada en Kerberos, a la encriptacin y al

control de acceso (Kerberos es un potente mecanismo de proteccin que
fue desarrollado por el Instituto de Tecnologa de Massachusetts).
Arquitectura de Intermediacin de Solicitud de Objetos Comunes (CORBA)

La Arquitectura de Intermediacin de Solicitud de Objetos Comunes o
CORBA ofrece otra aproximacin, a la construccin de sistemas distribuidos. CORBA, al igual que el DCOM pero al contrario que el DCE,
est orientada a objetos.
Permite que los objetos de una computadora invoquen los mtodos
de objetos de otras computadoras. CORBA, al contrario que el DCOM,
es una solucin abierta y no est vinculada a ningn sistema operativo
determinado.
Debido a esto, CORBA constituye una buena opcin a la construccin
de aplicaciones orientadas a objetos distribuidos.
CORBA utiliza los objetos que estn accesibles a travs de los Intermediarios de Solicitud de Objetos (ORB ). Estos ORB se emplean para
conectar objetos entre s por una red. Un objeto de una computadora
(objeto cliente ) invoca a los mtodos de otro objeto de otra computadora
(objeto servidor ) a travs de un ORB.
La interfaz del cliente al ORB es un fragmento adaptador que est
escrito en Lenguaje de Denicin de Interfaz (IDL). El fragmento adaptador es un proxy local de un objeto remoto. El IDL proporciona un
mecanismo de programacin independiente del lenguaje para describir
los mtodos de un objeto.
La interfaz del ORB con el servidor se hace a travs de un esqueleto
del IDL. Este esqueleto dota al ORB de un mecanismo independiente del
lenguaje que sirve para acceder al objeto remoto.
43
La invocacin remota de mtodos de CORBA tiene lugar como sigue:
El objeto cliente invoca los mtodos del fragmento adaptador del

IDL que se corresponde con un objeto remoto.
Este fragmento adaptador comunica las invocaciones de mtodos
al ORB.
El ORB invoca los mtodos correspondientes del esqueleto del IDL.
Este esqueleto invoca los mtodos de la implementacin remota de
objetos servidor.
El objeto servidor devuelve el resultado de la invocacin de mtodos
a travs del esqueleto del IDL, que devuelve el resultado al ORB.
El ORB a su vez devuelve el resultado al fragmento adaptador del
IDL, mientras que este fragmento adaptador devuelve el resultado
al objeto diente.
La gura 3-7 de la pg. 55 muestra el ORB como una sola capa de

los hosts de cliente y servidor. Esta es la forma normal en que se ve el
ORB.
Caben una serie de implementaciones del ORB. Por ejemplo, los ORB
hermanos pueden ser implementados en los hosts de cliente y servidor, o
un ORB de sistema central puede ser implementado en un servidor local.
Tambin son posibles otras implementaciones ORB.
Ahora que ya se sabe cmo funciona CORBA, podra preguntarse
cmo se usa para desarrollar aplicaciones distribuidas. La respuesta es
que CORBA proporciona un enfoque exible al desarrollo de aplicaciones
distribuidas.
Ofrece un nivel muy bueno de granularidad en la implementacin de
sistemas cliente / servidor. En lugar de depender de clientes y servidores
monolticos (como es el caso de los navegadores y servidores Web), tanto
los clientes como los servidores se pueden distribuir sobre varios hosts.
Las ventajas que tiene CORBA sobre otros enfoques de integracin
de aplicaciones distribuidas son signicativos:
44
Proporciona un verdadero enfoque orientado a objetos para el desarrollo de aplicaciones distribuidas.

Es independiente del lenguaje. Se puede utilizar para conectar
objetos que se desarrollen en cualquier lenguaje de programacin,
siempre y cuando se pueda suministrar a los objetos un fragmento
adaptador del IDL.
Se reconoce como un estndar internacional y lo admiten casi todas
las principales marcas.
Invocacin Remota de Mtodos de

Java
Habida cuenta de los diferentes enfoques relacionados con el desarrollo
de las aplicaciones distribuidas de las secciones anteriores, cabra preguntarse por qu Java no toma el mejor enfoque en lugar de usar la RMI.
Existen varias razones para explicar esto:
Sockets TCP : Java los admite. Puede construir aplicaciones tradicionales cliente / servidor en base a sockets usando Java en una
intranet o en Internet. Los applets y servlets de Java se pueden
usar para distribuir la capa de procesamiento de informacin de la
aplicacin entre el cliente y el servidor. Aunque Java admita sockets TCP, JavaSoft decidi que se necesitaba un enfoque ms denso
para el desarrollo de las aplicaciones distribuidas, como el que proporciona CORBA, con el n de desarrollar aplicaciones distribuidas
avanzadas por medio de Java.
DCE : Se basa en la RPC, que constituye un enfoque orientado a
procedimientos para el desarrollo de aplicaciones distribuidas. La
RPC no se acopla bien con las aplicaciones distribuidas orientadas
a objetos. El enfoque que la invocacin remota de mtodos que
45
admite CORBA se adapta mucho mejor al modelo de objetos de

Java.
DCOM : Se basa en la RPC del DCE, pero ofrece posibilidades de
programacin orientadas a objetos a travs de objetos, interfaces
y mtodos del COM. Adems, el DCOM proporciona servicios de
seguridad amplios. El entorno de desarrollo Java de Microsoft,
Visual J++, ofrece la posibilidad de acceder a objetos COM y
DCOM desde Java. No obstante, esta posibilidad constituye ms
bien un puente a las tecnologas de herencia que una extensin
distribuida del modelo de objetos Java.
CORBA: Proporciona un enfoque excelente a la construccin de
aplicaciones distribuidas orientadas a objetos. Y Java s que admite CORBA. Sin embargo, CORBA est diseada para admitir
un modelo de objetos independiente del lenguaje. La RMI de Java
posee todas las ventajas de CORBA, pero est especialmente adaptada al modelo de objetos Java. Esto hace que la RMI de Java sea
mucho ms ecaz y fcil de usar que CORBA en lo que respecta a
aplicaciones de Java puro.
El Modelo de Objeto Distribuido de

Java
El Modelo de Objeto Distribuido que usa Java permite que los objetos
que se ejecutan en una JVM invoquen a los mtodos de objetos que se
ejecutan en otras JVM. Estas otras JVM pueden ejecutarse como proceso
separado en la misma computadora o en otras computadoras remotas.
El objeto que hace la invocacin del mtodo se denomina objeto
cliente (Hijo).
El objeto cuyos mtodos se estn invocando se denomina objeto servidor (Padre).
46
El objeto cliente tambin recibe el nombre de objeto local y se dice

que se ejecuta de forma local.
El objeto servidor tambin se denomina objeto remoto y se dice que
se ejecuta de forma remota.
En el Modelo de Objeto Distribuido de Java, un objeto cliente nunca
hace referencia directa a un objeto remoto. En lugar de ello, hace referencia a una interfaz remota que implementa el objeto remoto.
El uso de interfaces remotas permite que los objetos servidor se diferencien entre sus interfaces locales y remotas. Por ejemplo, un objeto
podra proporcionar mtodos a los objetos que se ejecutaran dentro de la
misma JVM que se sumaran a los que proporciona a travs de su interfaz
remota.
El uso de interfaces remotas tambin permite que los objetos servidor
presenten modos diferentes de acceso remoto.
Por ejemplo, un objeto servidor puede proporcionar al mismo tiempo
una interfaz de administracin remota y una interfaz de usuario remota.
Por ltimo, el uso de interfaces remotas permite que la posicin del
objeto servidor dentro de su clase jerrquica se abstraiga de la manera
en que ste se utiliza. Esto permite compilar los objetos cliente por
medio de la interfaz remota, eliminando la necesidad de que los archivos
de clases del servidor estn presentes localmente durante el proceso de
compilacin.
Las Tres Capas de la RMI de Java

Aparte de las interfaces remotas, el modelo utiliza clases pertenecientes
al fragmento adaptador y al esqueleto de forma muy parecida a como lo
hace CORBA:
47
Las clases de fragmento adaptador actan como proxies locales de

los objetos remotos.
Las clases de esqueleto actan como proxies remotos.
Ambas clases implementan la interfaz remota del objeto servidor.
La interfaz cliente invoca a los mtodos del objeto fragmento adaptador local.
El fragmento adaptador local comunica estas invocaciones de mtodos al esqueleto remoto, mientras que este ltimo invoca a los mtodos del objeto servidor.
El objeto servidor devuelve un valor al objeto esqueleto.
El objeto esqueleto devuelve el valor al objeto fragmento adaptador,
mientras que este ltimo devuelve el valor al cliente.
La gura 3-8 de la pg. 55 resume el uso de los fragmentos adaptadores y esqueletos.

Si se es un programador de CORBA, se notar la ausencia de los IDL
y ORB en la gura 3-8 de la pg. 55 (IDL Y ORB se requieren por parte
de CORBA, ya que es neutral al lenguaje).
Las clases de fragmento adaptador y esqueleto las genera automticamente el compilador RMIC a partir del objeto servidor (el compilador
RMIC es una herramienta estndar del JDK ). Estas clases son clases
verdaderas de Java y no dependen de un IDL externo.
No se necesita un ORB, ya que la RMI de Java es una solucin de
Java puro. El objeto cliente y el fragmento adaptador se comunican por
medio de las invocaciones normales de mtodos de Java, al igual que
lo hacen el esqueleto y el objeto servidor. El fragmento adaptador y el
esqueleto se comunican a travs de una capa de referencia remota.
Esta capa de referencia remota admite la comunicacin entre el fragmento adaptador y el esqueleto. Si el fragmento adaptador se comunica
48
con ms de una instancia de esqueleto (no admitida activamente), el objeto fragmento adaptador se comunicar con esqueletos mltiples de un
modo multidifusin.
Hoy por hoy, la API RMI slo dene las clases que admiten una comunicacin unidifusin entre un fragmento adaptador y un solo esqueleto.
La capa de referencia remota tambin puede ser utilizada para activar
los objetos servidor cuando se invoquen remotamente.
La capa de refencia remota del host local se comunica con la capa de
referencia remota del host remoto a travs de la capa de transporte de la
RMI.
La capa de transporte congura y administra las conexiones que se dan
entre objetos a los que se puede acceder normalmente y determina cundo
las conexiones estn en comps de espera y se vuelven inoperativas. La
capa de transporte utiliza por defecto sockets TCP para comunicarse
entre los hosts local y remoto, no obstante, se puede usar tambin otros
protocolos de capa de transporte, como SSL y UDP .
La gura 3-9 de la pg. 56 ilustra las tres capas que se usan para
implementar la RMI de Java.
En esta vista ampliada del modelo:
El objeto cliente invoca a los mtodos del fragmento adaptador

local del objeto servidor.
El fragmento adaptador local utiliza la capa de referencia remota
para comunicarse con el esqueleto del servidor.
La capa de referencia remota utiliza la capa de transporte para
establecer una conexin entre los espacios de direciones locales y
remotas y para obtener una referencia del objeto esqueleto.
Con el n de que se pueda acceder remotamente a un objeto servidor,

ste se debe registrar a s mismo con el registro remoto. Esto lo hace
asociando su instancia de objeto a un nombre.
49
El registro remoto es un proceso que se ejecuta en el host del servidor

y se crea ejecutando el programa rmiregistry, otra herramienta del JDK.
El registro remoto mantiene una base de datos de objetos servidor
y los nombres en virtud de los cuales se puede hacer referencia a esos
objetos.
Cuando un cliente crea una instancia de la interfaz de un objeto servidor (es decir, su fragmento adaptador local):
La capa de transporte del host local se comunica con la capa de

transporte del host remoto para determinar si el objeto al que se ha
hecho referencia existe y para ver el tipo de interfaz que implementa
el objeto al que se ha hecho referencia.
La capa de transporte del lado del servidor utiliza el registro remoto
para acceder a esta informacin.
Un proceso separado, al que se llama Demonio de Sistema de Activacin de la RMI de Java, da soporte a la activacin de objetos
remotos. Este proceso se ejecuta por medio del programa rmid del
JDK en el sistema remoto.
Pasar Argumentos y Valores de Retorno

Para que un objeto cliente pase un argumento como parte de la invocacin
remota de mtodos, el tipo de argumento deber ser serializable.
Un tipo serializable es un tipo primitivo, o de referencia, susceptible
de ser escrito o ledo en un ujo. En la prctica, todos los tipos primitivos
de Java son serializables, y tambin lo son todas las clases e interfaces que
implementan o amplan la interfaz Serializable. Esta interfaz se dene
en el paquete java.io.
50
Las referencias a objetos se usan dentro de la JVM que contiene el

objeto.
Cuando un objeto local se pasa como argumento a una invocacin
remota de mtodos, el objeto local se copiar de la JVM local a la JVM
remota. Slo se copian las variables de campo no estticas y no transitorias.
Cuando se pasa un objeto remoto a travs de una invocacin remota
de mtodos dentro de la misma JVM, se pasar la referencia al objeto
remoto. Esto se debe a que la JVM remota contiene el objeto al que se
est haciendo referencia.
Cuando un objeto servidor est devolviendo un objeto como consecuencia de la invocacin remota de mtodos, el objeto se copiar de la
JVM remota a la JVM local.
Los Objetos y la Invocacin Remota

de Mtodos
El Modelo de Objeto Distribuido de Java constituye una extensin natural
del Modelo de Objetos de Java que hay en una sola JVM. Este modelo
implementa la RMI de un modo fcil de usar y establece unos requisitos
mnimos para que se pueda acceder a los objetos remotamente. Estos
requisitos son:
La clase del objeto debe implementar una interfaz que ample la interfaz Remote. Esta interfaz debe denir los mtodos que el objeto
va a permitir que se invoquen remotamente. Estos mtodos deben
arrojar la excepcin RemoteException.
La clase del objeto debe ampliar la clase RemoteServer. Esto se
hace normalmente ampliando la subclase UnicastRemoteObject de
RemoteServer.
51
Las clases de fragmento adaptador y el esqueleto de la clase de objeto deben ser creados por medio del compilador rmic. El fragmento
adaptador debe ser distribuido al host del cliente.
La clase, interfaz y clase del esqueleto del objeto remoto deben
estar en la CLASSPATH del host remoto. El demonio de activacin
remota y el registro remoto deben estar activados.
.Se debe crear una instancia de objetos remotos, y se debe registrar
en el registro remoto. Los mtodos bind ( ) y rebind ( ) de la clase
Naming se ulizan para registrar un objeto con su nombre asociado.
El objeto remoto debe instalar un administrador de seguridad para
permitir la carga de las clases de la RMI.
Seguridad de la Aplicacin Distribuida

El modelo de objetos distribuidos de Java implementa la seguridad a
travs del uso de cargadores de clase y administradores de seguridad de
la misma forma que lo hace para applets y aplicaciones.
El cargador de clases confa en las clases que se cargan desde el host
local. No se permite cargar las clases desde una red, a menos que un
administrador de seguridad est presente y permita la carga de clases de
forma remota.
Se coloca automticamente un administrador de seguridad para que
los applets se vayan cargando.
El administrador de seguridad que se usa en las aplicaciones distribuidas de Java es la clase RMISecurityManager.
Se debe establecer una instancia de esta clase a travs del mtodo
setSecurityManager () de la clase System al principio de la ejecucin de
un objeto cliente o servidor.
Se pueden desarrollar administradores de seguridad menos restrictivos
52
subclasicando RMISecurityManager y omitiendo sus mtodos.
Seguridad en el Transporte
Dado que la RMI utiliza TCP/IP para la comunicacin en redes, est
sujeto a las debilidades del paquete de protocolos TCP /IP.
Las mejoras del JDK 1.2 a la RMI ofrecen la posibilidad de crear
sockets personalizados sobre una base objeto a objeto.
Los sockets personalizados pueden hacer que la RMI utilice el protocolo SSL de Netscape para proteger la informacin a medida que se
comunica entre los objetos locales y remotos. Esto se hace creando una
RMI- SocketFactory personalizada.
Autenticacin y Control de Acceso

La autenticacin es el proceso de vericacin de la identidad de una
persona u objeto que acta en nombre propio.
El control de acceso es el proceso de restringir el acceso a los recursos
o servicios que estn basados en la identidad de un objeto o de una
persona.
La autenticacin y el control de acceso trabajan mano a mano. Sin
una autenticacin consistente, las personas sin escrpulos podran hacerse pasar por personas de toda conanza. Sin control de acceso, la
autenticacin no tiene dientes.
La autorizacin y el control de acceso son importantes en las aplicaciones distribuidas. Por ejemplo, puede ser que se desee limitar los objetos capaces de invocar remotamente a los mtodos de un objeto servidor
53
determinado a aquellos objetos que se ejecutan en un host especco o

en un conjunto de hosts, o que actan en nombre de una persona determinada.
La API RMI no proporciona las clases e interfaces que admiten directamente la autenticacin y el control de acceso.
No obstante, se pueden construir estas posibilidades por encima de
las clases que ofrece la API RMI. Por ejemplo, el mtodo getClientHost
() de la clase RemoteServer puede utilizarlo un objeto servidor para
determinar el nombre del host desde el que se inicia la invocacin remota
de mtodos. Esto se puede usar para limitar el acceso de la RMI a una
lista especicada de hosts, pero este enfoque no es infalible.
Existen formas de que hosts maliciosos se hagan pasar por hosts de
conanza. No obstante, puede ser usado para proporcionar un nivel
limitado de proteccin.
Se pueden implementar una autenticacin y un control de acceso ms
avanzados a travs del uso de certicados digitales en la aplicacin distribuida general que admita la RMI.
Los corta fuegos pueden ser utilizados para proteger las aplicaciones
distribuidas que se ejecutan en una intranet. Se utilizan normalmente
para restringir el acceso a la aplicacin distribuida a aquellos hosts que
estn en una intranet corporativa o en un segmento seleccionado de una
intranet.
Sin embargo, los corta fuegos crean problemas propios. Si hay un
corta fuego en la ruta de comunicacin entre objetos cliente y servidor,
este corta fuego puede evitar que se produzcan invocaciones remotas de
mtodos.
Afortunadamente, JavaSoft ha reconocido el problema, y la clase
RMISocketFactory ofrece la posibilidad de usar una RMI con un corta
fuego. Esta clase utiliza enfoques alternativos a la comunicacin cliente
/ servidor susceptibles de emplearse para burlar las restricciones de seguridad que imponen muchos corta fuegos.
Servidor de objetos
Objeto local
COM
Servidor de objetos
Objeto remoto
COM
Biblioteca
COM
registro
Tiempo de
Ejecucin
COM(SCM)
Tiempo de
Ejecucin
COM(SCM)
nivel de
transporte
nivel de
transporte
Figura 3-6 COM y DCOM.
registro
55
Host del cliente
Host del cliente
Objetivo cliente
Objetivo cliente
FRAGMENTO
IDL
ESQUELETO
DE IDL
ORB
Figura 3-7 Cmo funciona CORBA.
OBJETO
CLIENTE
OBJETO
SERVIDOR
FRAGMENTO
ESQUELETO
Figura 3-8 RMI de Java.
56
Objeto
Cliente
Objeto
Servidor
Fragmento
Esqueleto
Nivel de
Nivel de
Referencia
Remota
Referencia
Remota
Nivel de
Transporte
Nivel de
Transporte
Figura 3-9 Las tres capas de RMI.
Captulo 4
Sistemas Expertos
Definicin de Sistema Experto
Un sistema experto (SE) puede denirse como un sistema informtico
(hardware y software) que simula a los expertos humanos en un rea de
especializacin dada [5, Castillo Gutierrez Haidi-96].
La ms poderosa contribucin de los sistemas expertos es poner al
servicio de los analistas noveles la experiencia adquirida por aquellas
personas consideradas verdaderos especialistas en el rea.
Un SE es un software que imita el comportamiento de un experto
humano en la solucin de un problema. Pueden almacenar conocimientos de expertos para un campo determinado y solucionar un problema
mediante deduccin lgica de conclusiones.
Son programas que contienen tanto conocimiento declarativo (hechos
a cerca de objetos, eventos y/o situaciones) como conocimiento de control
57
Sistemas Expertos
58
(informacin acerca de los cursos de una accin), para emular el proceso

de razonamiento de los expertos humanos en un dominio en particular
y/o rea de experiencia [5, Castillo Gutierrez Haidi-96].
Los sistemas expertos son programas que reproducen el proceso intelectual de un experto humano en un campo particular, pudiendo mejorar su productividad, ahorrar tiempo y dinero, conservar sus valiosos
conocimientos y difundirlos ms fcilmente.
El esquema resumido de funcionamiento de un SE se muestra en la
gura 4-1 de la pg. 58.
Figura 4-1 Esquema resumido del funcionamiento de un sistema experto.
Aspectos Fundamentales de los Sistemas Expertos
Componentes de un Sistema Experto

Una caracterstica decisiva de los SE es la separacin entre conocimiento
(reglas, hechos) por un lado y su procesamiento por el otro. A ello se
aade una interfaz de usuario y un componente explicativo.
Sistemas Expertos
59
A continuacin se muestra una breve descripcin de cada uno de los

componentes :
1. La Base de Conocimientos de un SE contiene el conocimiento de
los hechos y de las experiencias de los expertos en un dominio determinado.
2. El Mecanismo de Inferencia de un SE puede simular la estrategia
de solucin de un experto.
3. El Componente Explicativo explica al usuario la estrategia de solucin encontrada y el porqu de las decisiones tomadas.
4. La Interfaz de Usuario sirve para que ste pueda realizar una consulta en un lenguaje lo ms natural posible.
5. El Componente de Adquisicin ofrece ayuda a la estructuracin e
implementacin del conocimiento en la base de conocimientos.
Tipos de Conocimiento
Existen dos tipos de conocimiento:
Conocimiento abstracto: Es de validez general y se almacena permanentemente.

Conocimiento concreto: Es de validez particular y se almacena
temporalmente. Son los datos o hechos de un problema especco
que es resuelto por el SE.
Para el presente trabajo se usarn los dos tipos de conocimiento.
El primero, como se usarn marcos de problema elementales, sern
de validez general y se almacenarn permanentemente y el tipo de
conocimiento concreto ser empleado cuando se resuelva un problema especco partiendo de lo general a lo particular.
Sistemas Expertos
60
Fuentes de Conocimiento
Existen dos tipos de fuentes de conocimiento:
Fuentes Primarias : acceso directo al conocimiento (experto humano, libros, textos, Internet, etc.).
Fuentes Secundarias : acceso indirecto a la informacin (referencias,
publicaciones, etc.).
Denicin del Conocimiento

El conocimiento es materia de estudio de distintas disciplinas, tales como
la losofa, la gestin empresarial y, ms recientemente la informtica;
existe varias denicin, segn el punto de vista e inters de quienes se
pronuncien.
Para la denicin de conocimiento varios autores interesados en la
informtica, se apoyan en la denicin, de dato e informacin .
Segn la Real Academia Espaola dice:
Dato: Antecedente necesario para llegar al conocimiento exacto, de

una cosa o para deducir las consecuencias legtimas de un hecho.
Informacin : Accin y efecto de informar o informarse.
Conocimiento : Accin y efecto de conocer. Nocin, ciencia, sabidura.
Cada una de las facultades sensoriales del hombre en la medida en
que estn activas.
Sabidura :Conocimiento reutilizado y proceso de retroalimentacin
de los conocimientos (el aprendizaje como cuna del conocimiento).
En la gura 4-2 de la pg. 61 se seala la llamada cadena del conocimiento.
Sistemas Expertos
61
Figura 4-2 La cadena del conocimiento.
Clasicacin de los Sistemas Expertos
Los sistemas expertos se clasican de acuerdo al tipo de conocimiento

que se utiliza:
SE basado en reglas : La construccin de la base de conocimiento es

en base a reglas, lo cual, en algunos casos se elabora sencillamente;
la explicacin de las conclusiones es simple. El motor de inferencia
se realiza con algoritmos complejos, lo cual es relativamente lento,
adems de que el aprendizaje estructural es complejo.
SE basado en probabilidades : La construccin de la base de conocimiento
es en base a frecuencias lo cual requiere de mucha informacin,
la explicacin de las conclusiones resulta ms compleja. El motor de inferencia se realiza con algoritmos simples, el aprendizaje
paramtrico es sencillo.
Se emplear el conocimiento basado en reglas porque la informacin
con que se cuenta es de tipo determinstico.
Sistemas Expertos
62
Sistemas Expertos Basados en Reglas
Los sistemas basados en reglas son los ms comnmente utilizados. Su

simplicidad y similitud con el razonamiento humano han contribuido para
su popularidad en diferentes dominios. Las reglas son un importante paradigma de representacin del conocimiento [5, Castillo Gutierrez Haidi96].
Una regla es una armacin lgica que relaciona dos o ms objetos e
incluye dos partes, la premisa y la conclusin. Cada una de estas partes
consiste en una expresin lgica con una armacin objeto - valor conectadas mediante los operadores lgicos y, o, o no [5, Castillo Gutierrez
Haidi-96].
Las reglas representan el conocimiento utilizando un formato SI ENTONCES (IF - THEN), es decir tienen 2 partes:
La parte SI (IF): Es el antecedente, premisa, condicin o situacin.
La parte ENTONCES (THEN): Es el consecuente, conclusin, accin o respuesta.
Las reglas pueden ser utilizadas para expresar un amplio rango de

asociaciones.
Una declaracin de que algo es verdadero o es un hecho conocido, es
una armacin.
El conjunto de armaciones se conoce frecuentemente con el nombre
de base de armaciones. De igual forma, al conjunto de reglas se lo
denomina base de reglas.
El Motor de Inferencia
Se ha mencionado que hay dos tipos de elementos : los datos (hechos o
evidencia) y el conocimiento (el conjunto de reglas almacenado en la base
de conocimiento).
Sistemas Expertos
63
El motor de inferencia usa ambos para obtener nuevas conclusiones

o hechos. Por ejemplo, si la premisa de una regla es cierta, entonces la
conclusin de la regla debe ser tambin cierta.
Los datos iniciales se incrementan incorporando las nuevas conclusiones. Por ello, tanto los hechos iniciales o datos de partida como las
conclusiones derivadas de ellos forman parte de los hechos o datos de que
se dispone en un instante dado.
Las conclusiones pueden clasicarse en dos tipos: simples y compuestas.
Las conclusiones simples son las que resultan de una regla simple.
Las conclusiones compuestas son las que resultan de ms de una regla.
Para obtener conclusiones, los expertos utilizan diferentes tipos de
regla y estrategias de inferencias y control.
Las reglas son las siguientes:
Modus Ponens.
Modus Tollens.
Resolucin.
Las estrategias de inferencias son las siguientes:
Encadenamiento de reglas.
Encadenamiento de reglas orientado a un objeto.
Compilacin de reglas, que son utilizadas por el motor de inferencia
para obtener conclusiones simples y compuestas.
Las dos primeras reglas de inferencia se usan para obtener conclusiones simples y el resto de reglas y estrategias para obtener conclusiones
compuestas.
Ntese, sin embargo, que ninguna de las estrategias anteriores, si se
implementan solas, conduce a todas las conclusiones posibles. Por ello
Sistemas Expertos
64
deben implementarse varias reglas y estrategias en el sistema experto

para que el motor de inferencia sea capaz de obtener tantas conclusiones
como sea posible.
Modus Ponens y Modus Tollens
El Modus Ponens es quizs la regla de inferencia ms comnmente utilizada.

Se usa para obtener conclusiones simples. En ella se examina la
premisa de la regla y, si es cierta, la conclusin pasa a formar parte
del conocimiento.
Como ilustracin, supngase que se tiene la regla, Si A es cierto,
entonces B es cierto y que se sabe adems que A es cierto. Entonces,
tal como muestra la gura 4-3 de la pg. 65, la regla Modus Ponens
concluye que B es cierto.
Esta regla de inferencia, que parece trivial, debido a su familiaridad,
es la base de un gran nmero de SE.
La regla de inferencia Modus Tollens se utiliza tambin para obtener
conclusiones simples.
En este caso se examina la conclusin y si es falsa, se concluye que la
premisa tambin es falsa. Por ejemplo, supngase de nuevo que se tiene
la regla, Si A es cierto, entonces B es cierto, pero se sabe que B es
falso.
Entonces, utilizando la regla Modus Ponens no se puede obtener
ninguna conclusin, pero, tal como se muestra en la gura 4-4 de la
pg. 66, la regla Modus Tollens concluye que A es falso.
Aunque muy simple y con muchas aplicaciones tiles, la regla Modus
Tollens es menos utilizada que la Modus Ponens.
La regla Modus Ponens se mueve hacia delante, es decir, de la premisa
a la conclusin de una regla, mientras que la regla Modus Tollens se
mueve hacia atrs, es decir, de la conclusin a la premisa.
Sistemas Expertos
65
Figura 4-3 Regla modus ponens.
Las dos reglas de inferencia no deben ser vistas como alternativas sino
como complementarias.
La regla Modus Ponens necesita informacin de los objetos de la
premisa para concluir, mientras que la regla Modus Tollens necesita informacin sobre los objetos de la conclusin.
De hecho, para un motor de inferencia que solamente utiliza Modus
Ponens, la incorporacin de la regla de inferencia Modus Tollens puede
ser considerada como una expansin de la base de conocimiento mediante
la adicin de reglas.
Resolucin
Las reglas de inferencias Modus Ponens y Modus Tollens puede ser utilizada para obtener conclusiones simples. Por otra parte, las conclusiones
compuestas, que se basan en dos o ms reglas, se obtienen usando el llamado mecanismo de resolucin .
Sistemas Expertos
66
Figura 4-4 Regla modus tollens.
Encadenamiento de Reglas
Una de las estrategias de inferencia ms utilizada para obtener conclusiones compuestas es el llamado encadenamiento de reglas.
Esta estrategia puede utilizarse cuando las premisas de ciertas clases
coinciden con conclusiones de otras.
Cuando se encadenan las reglas, los hechos pueden dar lugar a nuevos
hechos. Esto se repite sucesivamente hasta que no pueda obtenerse ms
conclusiones.
El tiempo que consume este proceso hasta su terminacin depende,
por una parte, de los hechos conocidos, y por otra, de las reglas que se
activan.
Sistemas Expertos
67
Encadenamiento de Reglas Orientada a un Objetivo
El algoritmo de encadenamiento de reglas orientado a un objetivo requiere del usuario seleccionar, en primer lugar, una variable o nodo objetivo; entonces el algoritmo navega a travs de reglas en bsqueda de una
conclusin para el nodo objetivo.
Si no se obtiene ninguna conclusin con la informacin existente, entonces el algoritmo fuerza a preguntar al usuario en busca de nueva informacin sobre los elementos que son relevantes para obtener informacin
sobre el objetivo.
Compilacin de Reglas
Otra forma de tratar con reglas encadenadas consiste en comenzar con un
conjunto de datos (informacin) y tratar de alcanzar algunos objetivos.
Esto se conoce con el nombre de compilacin de reglas.
Cuando ambos, datos y objetivos, se han determinado previamente,
las reglas pueden ser compiladas, es decir, pueden escribirse los objetivos
en funcin de los datos para obtener las llamadas ecuaciones objetivo.
En el presente trabajo se ha utilizado Modus Ponens y encadenamiento
de reglas.
Control de la Coherencia
En situaciones complejas, incluso verdaderos expertos pueden dar informacin inconsistente (por ejemplo, reglas inconsistentes y/o combinaciones de hechos no factibles). Por ello es muy importante controlar
la coherencia del conocimiento tanto durante la construccin de la base
de conocimiento como durante los procesos de adquisicin de datos y
razonamiento.
Si la base de conocimiento contiene informacin inconsistente (por
ejemplo, reglas y/o hechos), es muy probable que el SE se comporte de
forma poco satisfactoria y obtenga conclusiones absurdas.
Sistemas Expertos
68
El objetivo del control de la coherencia consiste en:
Ayudar al usuario a no dar hechos inconsistentes, por ejemplo, dndole al usuario las restricciones que debe satisfacer la informacin
demandada.
Evitar que entre en la base de conocimiento cualquier tipo de
conocimiento inconsistente o contradictorio.
El control de la coherencia debe hacerse controlando la coherencia de

las reglas y la de los hechos.
Un conjunto de reglas se denomina coherente si existe, al menos, un
conjunto de valores de todos los objetos que producen conclusiones no
contradictorias.
En consecuencia, un conjunto coherente de reglas no tiene por qu
producir conclusiones no contradictorias para todos los posibles conjuntos
de valores de los objetos. Es decir, es suciente que exista un conjunto
de valores que conduzcan a conclusiones no contradictorias.
Metodologa de Weiss y Kulikowski

Para el desarrollo de un sistema experto Weiss y Kulikowski sugieren las
siguientes etapas para el diseo e implementacin de un SE :
Planteamiento del problema : La primera etapa en cualquier proyecto

es normalmente la denicin del problema a resolver. Puesto que
el objetivo principal de un SE es responder a preguntas y resolver
problemas, esta etapa es quizs la ms importante en el desarrollo
del mismo. Si el sistema est mal denido, se espera que el sistema
suministre respuestas errneas.
Encontrar expertos humanos que puedan resolver el problema : En
algunos casos, sin embargo, las bases de datos pueden jugar el papel
del experto humano.
Sistemas Expertos
69
Diseo de un SE : Esta etapa incluye el diseo de estructuras para

almacenar el conocimiento, el motor de inferencia, el subsistema de
explicacin, la interfaz de usuario, etc.
Base de Conocimiento
No es el nico componente de un SE. Si lo fuera un SE podra ser tan
solo una lista de reglas condicionales if - then.
Lo que se necesita es un mecanismo para operar a lo largo de la base
de conocimiento para resolver un problema. A tal mecanismo se le conoce
como motor de inferencia.
Otra pieza necesaria es el rea de trabajo que contenga las condiciones del problema; esta captura puede realizarse mediante una lista
de vericacin, preguntas y respuestas de opcin mltiple o un sistema
extremadamente sosticado sentado en el idioma natural.
Para interactuar con el sistema experto el usuario captura las condiciones de un problema en la interfaz del usuario, y las almacena en el
rea de trabajo.
El motor de inferencia se vale de tales condiciones para buscar una
solucin en la base de conocimiento. La gura 4-5 de la pg. 70 muestra
un diagrama de secuencias de este proceso1 .
Modelado de la Base de Conocimiento

La representacin de UML para las reglas es similar a la de objetos.
Se debe contar con uno de los atributos para que sea la parte if, otra
la parte then, y agregar otros atributos conforme sea necesario.
El diseo de una regla mediante UML se esquematiza en la gura 4-6
de la pg. 702 .
1
2
Joseph Schmuller-2000.
Joseph Schrnuller-2000.
Sistemas Expertos
70
Figura 4-5 Proceso de bsqueda en la base de conocimiento.
Figura 4-6 Diceo de la regla mediante UML.
Para balancear la proliferacin respecto a la necesidad de la simplicidad, primero se crea un sencillo icono que representa a la regla, se llena
la parte de if y la parte de then, seguidamente se debe de incorporar
cierta informacin de identicacin para cada regla, se agrega su nombre
en la parte superior; con esto se logra:
1. Convertir a cada regla en nica.
2. Mostrar adnde ir en el catlogo de reglas para obtener una descripcin y explicacin completa de la regla.
Sistemas Expertos
71
Si una regla es parte de un subgrupo de reglas, se puede tratar

al subconjunto como un paquete. Luego agregar el paquete de
informacin al identicador de la forma usual propia del UML,
hacer que el nombre del paquete anteceda a un par de dos puntos
(::), que antecedan al identicador.
Concluido el paso de anlisis de requisitos, se pasa al siguiente paso,
el diseo del SE :
Eleccin de la herramienta de desarrollo: Debe decidirse si realizar

un SE a medida utilizando lenguaje de programacin.
Desarrollo y prueba de un prototipo: Si el prototipo no pasa las
pruebas requeridas, las etapas anteriores (con las modicaciones
apropiadas) deban ser repetidas hasta que se obtenga un prototipo
satisfactorio.
Renamiento y generalizacin : En esta etapa se corrigen los fallos
y se incluyen nuevas posibilidades no incorporadas en el diseo
inicial.
Mantenimiento y puesta al da : En esta etapa el usuario plantea
problemas o defectos del prototipo, corrige errores, actualiza el producto con nuevos avances, etc.
Todas estas etapas inuyen en la calidad del SE resultante, que siempre debe ser evaluado en funcin de las aportaciones de los usuarios.
Las etapas en el desarrollo de un SE se indican en la gura 4-7 de la
pg. 723 .
La diferencia fundamental entre un programa tradicional y un SE
puede resumirse como sigue:
Un programa tradicional puede esquematizarse de la siguiente manera:
3
Enrique Castillo, Jos Manuel Gutirrez, y Ah S. Hadi. [CAT, 1999].
Sistemas Expertos
Figura 4-7 Etapas en el desarrollo de un SE.
72
Sistemas Expertos
73
Un SE estara denido de la siguiente forma:
Las ventajas que se obtiene al utilizar un SE son las siguientes:
Mayor acceso al conocimiento experto.

Rpida obtencin de conclusiones y soluciones.
Resultados objetivos.
Conclusiones realistas en situaciones crticas.
Definiciones y Conceptos Sobre Grafos

Un grafo es un conjunto de vrtices V (o nodos) y un conjunto de arcos
E que se conectan entre s.
El concepto de grafos puede denirse de forma ms general, por ejemplo, puede permitirse que dos nodos estn conectados por ms de una
arista, o incluso que un nodo est conectado consigo mismo.
Sin embargo, en el campo de los SE, los grafos se utilizan para representar un conjuntos de variables proposicionales (nodos) y una relacin
de dependencia entre ellas (aristas).
Sistemas Expertos
74
Las aristas de un grco pueden ser dirigidas o no dirigidas, dependiendo de si se considera o no, el orden de los nodos.
En la prctica esta distincin depender de la importancia del orden
en que se relacionan los objetos.
En la gura 4-8 de la pg. 74 de muestran ejemplos de grafos y en la
gura 4-9 de la pg. 74 notaciones de los mismos.
Figura 4-8 Tipos de grafos.
Figura 4-9 Notacin de grafos.
Los grafos pueden ser extendidos mediante la adicin de rtulos (labels) a los arcos. Estos rtulos pueden representar costos, longitudes,
distancias, pesos, etc.
Un grafo no dirigido se denomina completo si contiene una arista
entre cada par de nodos (ver gura 4-10 de la pg. 75).
Un grafo puede ser representado en memoria numricamente, utilizando determinado tipos de matrices, como la matriz de adyacencia.
Sistemas Expertos
75
Figura 4-10 Grafo completo.
Un grafo se puede representar mediante una matriz A tal que A[i,j] =

1 si hay un arco que conecta v con v , y 0 si no. La matriz de adyacencia
de un grafo no dirigido, es simtrica.
Una matriz de adyacencia permite determinar si dos vrtices estn
conectados o no en tiempo constante, pero requieren O(n2 ) bits de memoria. Esto puede ser demasiado para muchos grafos que aparecen en aplicaciones reales, en donde |E|<<n2.
Otro problema es que se requiere tiempo O(n) para encontrar la lista
de vecinos de un vrtice dado.
La matriz de adyacencia permite comprobar si existe algn camino
entre cada par de nodos, tambin puede calcularse la longitud de todos
los caminos que unan cada par de nodos
i
La representacin mediante listas de adyacencia consiste en almacenar, para cada nodo, la lista de los nodos adyacentes a l.
Ejemplo:
v1 : v2
v2 : v2 , v3
Sistemas Expertos
76
v3 : v1 , v4
v4 : v3
Esto utiliza espacio O(|E|) y permite acceso eciente a los vecinos,
pero no hay acceso al azar a los arcos.
En el presente trabajo se utiliza modus ponens, encadenamiento de reglas en la versin Yosuko 1.0, y en la versin Yosuko
2.0 se utiliza la tcnica de grafos completos, con matriz de adyacencia,
destacndose los benecios e inconveniente encontrados en cada caso.
Nota :
Captulo 5
Programacin Orientada a Objetos

Introduccin
La programacin orientada a objetos (POO ) es una tcnica de programacin que trata de mejorar las antiguas tcnicas de programacin lineal
y programacin estructurada.
Con los lenguajes estructurados fue posible escribir programas moderadamente complejos de una forma bastante sencilla; sin embargo, usando incluso la programacin estructurada, cuando los proyectos alcanzan cierto tamao, su complejidad se vuelve demasiado difcil para ser
controlada por un programador.
La POO toma las mejores ideas de la programacin estructurada y
las combina con nuevos y poderosos conceptos que animan o alientan una
nueva visin de la tarea de la programacin.
77
78
La POO permite descomponer fcilmente un problema en subgrupos

de partes relacionadas. Entonces, se puede traducir estos subgrupos en
unidades autocontenidas llamadas objetos.
Las principales ventajas de utilizar la tcnica de programacin orientada a objeto son las siguientes:
Los programas son ms fciles de modicar.

Los programas son fciles de mantener.
El cdigo desarrollado es mucho ms portable y reutilizable que
con otros paradigmas.
Objeto
Un objeto es un conjunto constituido por una o varias variables y, opcionalmente por mtodos.
Un objeto es cualquier entidad lgica del mundo real que se pueda
imaginar.
Objetos sicos : Automviles, aviones, animales mamferos etc.
Tambin se puede decir que tienen determiandas caracterstica, y
comportamiento, ej. una casa.
Caractersticas : Nmero de pisos, altura total en metros, color de la
fachada, nmero de ventanas, nmero de puertas, ciudad, calle y nmero
donde est ubicada, etc.
Operaciones : Construir, destruir, pintar fachada, modicar alguna
de las caractersticas, como por ejemplo, abrir una nueva ventana, etc.
Evidentemente, cada objeto puede denirse en funcin de multitud
de caractersticas y se pueden realizar innumerables operaciones sobre l.
79
Ya en trminos de programacin, ser misin del programador determinar qu caractersticas y que operaciones interesa mantener sobre un
objeto. Por ejemplo, sobre el objeto casa puede no ser necesario conocer
su ubicacin y por lo tanto, dichas caractersticas no formarn parte del
objeto denido por el programador. Lo mismo podra decirse sobre las
operaciones.
En terminologa de programacin orientada a objetos, a las caractersticas del objeto se les denomina atributos y a las operaciones mtodos (ver
gura 5-1 de la pg. 79).
Cada uno de estos mtodos es un procedimiento o una funcin perteneciente
a un objeto.
Figura 5-1 Terminologa de objetos.
Un objeto est formado por una serie de caractersticas o datos (atributos) y una serie de operaciones (mtodos). No puede concebirse nicamente en funcin de los datos o de las operaciones sino en su conjunto.
Clases y Objetos
En la POO hay que distinguir entre dos conceptos ntimamente ligados,
la clase y el objeto.
De forma anloga a cmo se denen las variables en un lenguaje de
programacin, cuando se declara un objeto hay que denir el tipo de
objeto al que pertenece. Este tipo es la clase.
En C, se denen dos variables X e Y de tipo entero de la forma
siguiente: int X,Y;.
80
En este caso, X e Y son variables, y el tipo de dichas variables es

entero.
La forma de declarar objetos en Java es la misma:
Ccasa casa1, casa2
En este caso, casa1 y casa2 son efectivamente variables, pero un
tanto especiales, son objetos .
Adems, el tipo de objetos es Ccasa. Este tipo es la clase del objetos.
Analoga
VARIABLE = OBJETO
TIPO = CLASE
Al declarar casa1 y casa2 como objetos pertenecientes a la clase
Ccasa, se est indicando que casa1 y casa2 tendrn una serie de atributos (datos) como son nPuertas, nVentanas y color ; y, adems, una serie
de mtodos (operaciones que se pueden realizar sobre ellos) como son:
abrirVentanas (), cerrarVentanas (), etc.
Propiedades de un Lenguaje Orientado a Objetos

Las propiedades que debe cumplir un lenguaje para ser considerado OO
(orientado a objetos) son las siguientes:
Encapsulamiento.
Herencia.
Polimorsmo.
Encapsulamiento
81
El encapsulamiento consiste en la propiedad que tienen los objetos de

ocultar sus atributos, e incluso los mtodos, a otras partes del programa
u otros objetos.
La forma natural de construir una clase es la de denir una serie
de atributos que, en general, no son accesibles fuera del mismo objeto,
sino que nicamente pueden modicarse a travs de los mtodos que son
denidos como accesibles desde el exterior de esa clase.
class Ccasa {
int nPuertas, nVentanas;
String color;
public Ccasa(int np, int nv, String co) {
nPuertas=np;
nVentanas=nv;
color=co;
}
public void pintar(String co) {
color=co;
}
public void abrirVentanas(int n) {
nVentanas=nVentanas+n;
}
public void cerrarVentanas(int n) {
nVentanas=nVentanas-n;
if (nVentanas
<0)
82
nVentanas=0;
}
public void abrirPuertas(int n) {
nPuertas=nPuertas+n;
}
public void cerrarPuertas(int n) {
nPuertas=nPuertas-n;
<
if (nPuertas 0)
nPuertas=0;
}
}
Ccasa casa1,casa2;
La forma normal de declarar la clase Ccasa consiste en denir una

serie de atributos no accesibles desde cualquier parte del programa, sino
nicamente a travs de determinados mtodos. As, si se quiere abrir una
nueva ventana en la casa casa1, la losofa tradicional de un programador
consistira en realizar lo siguiente:
casa1.N_VENTANAS := casa1.N_VENTANAS + 1;
Sin embargo, la forma natural de hacerlo en POO es llamando al
mtodo casa1.abrirVentanas(1). Ese mtodo (procedimiento) se encargar de incrementar en 1 el atributo nVentanas. Esto no quiere decir que
el atributo nVentanas no pueda ser accedido de la forma tradicional (si
se hubiera denido como public) pero, para que el lenguaje pueda ser
considerado como OO, debe permitir la posibilidad de prohibir el acceso
a los atributos directamente.
Herencia
83
Es una de las principales ventajas de la POO.

Esta propiedad permite denir clases descendientes de otras, de forma
que la nueva clase (la clase descendiente) hereda de la clase antecesora
todos sus atributos y mtodos.
La nueva clase puede denir nuevos atributos y mtodos o incluso
puede redenir atributos y mtodos ya existentes (por ejemplo: cambiar el tipo de un atributo o las operaciones que realiza un determinado
mtodo).
Es la forma natural de denir objetos en la vida real. La mayora de la
gente dira, por ejemplo, que un chalet es una casa con jardn. Tiene las
mismas caractersticas y propiedades u operaciones que pueden realizarse
sobre una casa y, adems, incorpora una nueva caracterstica, el jardn.
En otras ocasiones, se aadir funcionalidad (mtodos) y no atributos. Por ejemplo: un pato es un ave que nada. Mantiene las mismas
caractersticas que las aves y nicamente habra que declarar un mtodo
sobre la nueva clase (el mtodo nadar).
Esta propiedad permite la reutilizacin del cdigo, siendo muy fcil
aprovechar el cdigo de clases ya existentes, modicndolas mnimamente
para adaptarlas a las nuevas especicaciones.
Ejemplo: Se supone que tenemos construida la clase Ccasa y queremos denir una nueva clase que represente a los chalets. En este caso
puede ser conveniente denir un nuevo atributo que represente los metros cuadrados de jardn. En lugar de volver a denir una nueva clase
desde cero, puede aprovecharse el cdigo escrito para la clase Ccasa de
la siguiente forma (ver adems la gura 5-2 de la pg. 84):
class Cchalet extends Ccasa {
int mJardin;
public Cchalet(int np, int nv, String co, int nj) {
super(np,nv,co);
84
mJardin=nj;
}
}
Cchalet chalet1,chalet2;
Figura 5-2
Reutilizacin de objeto.
Como puede verse, nicamente hay que declarar que la nueva clase
Cchalet es descendiente de Ccasa (extends Ccasa) y declarar el nuevo
atributo.
Evidentemente, el mtodo constructor hay que redenirlo para poder
inicializar el nuevo atributo mJardin . Pero los mtodo para Abrir/Cerrar
puertas ventanas no es necesario denirlos, son heredados de la clase
Ccasa y pueden utilizarse, por ejemplo de la siguiente forma:
chalet1.pintar(Blanco);
85
Polimorsmo
El polimorsmo permite que un mismo mensaje enviado a objetos de

clases distintas haga que estos se comporten tambin de forma distinta
(objetos distintos pueden tener mtodos con el mismo nombre o incluso
un mismo objeto puede tener nombres de mtodos idnticos pero con
distintos parmetros ). Por ej.:
class Ccasa {
public Ccasa(int np, int nv, String co) {
nPuertas=np;
nVentanas=nv;
color=co;
}
public Ccasa() {
nPuertas=0;
nVentanas=0;
color=;
}
Tiene dos mtodos con el mismo nombre pero parmetros distintos.

En el primer caso se inicializarn los atributos del objeto con los parmetros del mtodo y en el segundo caso se inicializarn a cero, por ejemplo.
Adems, si tenemos dos objetos casa1 y chalet1 y se llama al mtodo
chalet1.abrirVentanas(2) se ejecutar el cdigo del procedimiento abrirVentanas de la clase Cchalet y no de la clase Ccasa .
Lenguaje Java
86
Caractersticas Destacables del Lenguaje Java

Independencia en la Plataforma
Una de las razones ms importante para utilizar Java, es la independencia de la plataforma.
Java se ejecuta en la mayor parte de plataformas de hardware y software, entre las que se incluyen Windows 95, 98, NT, 2000, XP, Macintosh,
y varias gamas de UNIX.
Los navegadores Web compatibles con Java, como Netscape Navigator
e Internet Explorer, admiten los applets de Java.
Cambiando el software existente a Java, se podr hacer inmediatamente compatibles estas plataformas de software. Sus programas sern
ms porttiles y se eliminar toda dependencia con el sistema operativo.
Si bien C y C++ son compatibles en todas las plataformas compatibles con Java, estos lenguajes no son compatibles al margen de la
plataforma. Las aplicaciones en C y C++ que se implementan en una
plataforma de sistema operativo, por regla general se entrelazan demasiado con el sistema nativo de ventanas y con las posibilidades de red
especcas del sistema operativo. El cambio de plataforma de sistema
operativo requiere como mnimo una recompilacin, as como un rediseo importante en la mayora de casos.
Orientacin a Objetos
Java es un lenguaje verdaderamente orientado a objetos. No slo

ofrece la posibilidad de implementar principios orientados a objetos, sino
que tambin pone en prctica tales principios.
Se pueden desarrollar programas orientados a objetos en C++, pero
no es necesario hacerlo; tambin se puede usar C++ para escribir programas en C.
Java no permite salirse de la estructura orientada a objetos. O se
suscribe totalmente al enfoque del desarrollo orientado a objetos o no se
podr programar en Java
87
Seguridad
Java es uno de los primeros lenguajes de programacin que tiene en
cuenta la seguridad como parte de su diseo.
El lenguaje, el compilador, el intrprete y el entorno de tiempo de
ejecucin de Java fueron desarrollados pensando en la seguridad.
El compilador, el intrprete, la API y los navegadores compatibles
con Java contienen todos ellos varios niveles de medidas de seguridad,
diseados para reducir el riesgo del compromiso de seguridad, prdida de
datos, integridad del programa y daos a los usuarios del sistema.
Caractersticas Varias
El lenguaje Java ofrece muchas caractersticas que lo hacen ms atractivo que C o C++ para el desarrollo de software moderno.
Al principio de la lista nos encontramos con el soporte intrnseco de
Java al multihilo, lo cual falta tanto en C como enC++.
Otras caractersticas son sus posibilidades de manipulacin de excepciones, que fueron recientemente introducidas en C++, su adherencia
estricta al desarrollo de software orientado a clases y objetos, y su soporte
de recoleccin automtica de basura.
Aparte de estas caractersticas, Java implementa un estilo de programacin comn que elimina la posibilidad de salirse del paradigma de
programacin orientado a clases y a objetos para desarrollar programas
orientados a funciones del tipo C.
La API Java
Las clases predenidas de la API Java ofrecen una base conjunta e independiente de la plataforma que se usa para el desarrollo de programas.
Estas clases ofrecen la posibilidad de desarrollar programas de ventana
y de red que se ejecutan en una amplia gama de hosts.
El soporte para la API Java, con la invocacin remota de mtodos,
conectividad de bases de datos y seguridad, no lo supera la API de ningn
otro lenguaje. Adems, ningn otro lenguaje ofrece una potencia inde-
88
pendiente de la plataforma que se utilice como la API Java.

Su distribucin ha recorrido un largo camino para dar soporte a
la computacin totalmente distribuida con su soporte RML CORBA y
JDBC.
Estas API ofrecen la posibilidad de desarrollar e integrar objetos remotos en programas autnomos y aplicaciones Web basadas en applets.
Generacin Rpida de Cdigo
Dado que Java es un lenguaje de interpretacin, se puede utilizar para

hacer rpidamente prototipos de aplicaciones que requeriran bastante
ms soporte en lenguajes como C o C++.
La API Java tambin contribuye a la posibilidad de admitir la generacin rpida de cdigo. Las clases de la API Java ofrecen un receptculo
integrado y fcil de utilizar para el desarrollo de software especco de la
aplicacin.
Dado que la API Java ofrece soporte para ventanas de alto nivel, redes
y bases de datos, se pueden construir ms rpidamente los prototipos
personalizados de aplicacin teniendo estas clases como fundamento.
Facilidad de Documentacin y Mantenimiento
En esencia, el software de Java se documenta automticamente cuando

se utilizan los comentarios doc y la herramienta javadoc para generar
documentacin para el software.
La excelente documentacin de la API Java constituye un ejemplo de
las posibilidades superiores de documentacin que ofrece Java.
Dado que el software de Java est inherentemente mejor estructurado
y documentado que el de C o C++, por lo general es ms fcil de
mantener. Aparte de esto, la orientacin de paquete del software de
Java ofrece una modularidad considerable en el diseo, desarrollo, documentacin y mantenimiento del software.
RMI (Remote Method Invocation o Invocacin de Mtodos

Remotos)
89
Introduccin
Al igual que con los RPC (Remote Procedure Call o Llamada a Procedimientos Remotos) de C en Linux, es posible hacer que un programa
en Java llame a mtodos de objetos que estn instanciados en otro programa distinto, incluso que estn corriendo en otra mquina conectada
en red.
Estos mtodos, aunque los llamemos desde este ordenador, se ejecutan
en el otro.
Este mtodo tiene la ventaja de que si, por ejemplo, tenemos un ordenador capaz de realizar cuentas muy rpidamente y otro capaz de dibujar
grcos maravillosos y adems necesitamos hacer un programa con varias
cuentas y varios grcos, podemos implementar en el ordenador de las
cuentas aquellas clases que calculan cuentas, en el ordenador de grcos
aquellas clases de pintado y hacer que cada ordenador haga lo que mejor
puede hacer.
Cuando al hacer un grco necesitemos calcular cuentas, llamaremos
a la clase remota que hace las cuentas, y stas se harn en el ordenador
de las cuentas, devolviendo el resultado al de los grcos.
Las clases que se necesitan para congurar un RMI son las siguientes:
InterfaceRemota : Es una interfaz Java con todos los mtodos que

se quiera poder invocar de forma remota, es decir, los mtodos se
llaman desde el cliente, pero se ejecutarn en el servidor.
ObjetoRemoto: Es una clase con la implementacin de los mtodos
de InterfaceRemota. A esta clase slo la ve el servidor de rmi.
ObjetoRemoto_Stubs : Es una clase que implementa InterfaceRemota, cada mtodo se encarga de hacer una llamada a travs de la
red al ObjetoRemoto del servidor, espera el resultado y lo retorna.
Esta clase es la que ve el cliente y no necesita codicarla, Java lo
hace automticamente a partir de ObjetoRemoto.
Poltica de Seguridad
90
Se precias tambin un archivo de poltica de seguridad. En este

archivo se indica al servidor de rmi y al cliente de rmi, qu conexiones
pueden o no establecerse. Debe haber un chero de poltica de seguridad
en el servidor de rmi y otro en el cliente.
En la pc/mquina servidor de rmi se debe correr dos programas:
rmiregistry : Este es un programa que proporciona Java. Una vez

arrancado, admite que se registren en l objetos para que puedan
ser invocados remotamente y admite peticiones de clientes para
ejecutar mtodos de estos objetos.
Servidor : Este es un programa que se debe confeccionar. Se debe
instanciar el ObjetoRemoto y registrar en el rmiregistry. Una vez
registrado el ObjetoRemoto, el servidor no muere, sino que queda
vivo. Cuando un cliente llame a un mtodo de ObjetoRemoto, el
cdigo de ese mtodo se ejecutar en este proceso.
En la pc/mquina del cliente se debe correr el programa:
Cliente : Este programa debe pedir al rmiregistry de la pc/mquina
servidor una referencia remota al ObjetoRemoto. Una vez que la
consigue (obtiene un ObjetoRemoto_Stbus ), se pueden hacer las
llamadas a sus mtodos. Los mtodos se ejecutarn en el Servidor,
pero el Cliente quedar bloqueado hasta que el Servidor termine
de ejecutar el mtodo.
Ejemplo: cmo realizar una operacin suma en un objeto remoto.

La interface de la clase remota Hacer es una interfaz, con los mtodos
que se quiera, llamar remotamente. Esta interface sera como la se indica
en la gura 5-3 de la pg. 91.
Se tiene que heredar de la interface Remote de Java, si no el objeto
no ser remoto. Se aade adems los mtodos que se quiera, pero todos
deben lanzar la excepcin java.rmi.RemoteException, que se producir
si hay algn problema con la comunicacin entre los dos ordenadores o
cualquier otro problema interno de rmi.
91
Figura 5-3 Interface para RMI.
Todos los parmetros y valores devueltos de estos mtodos deben ser

tipos primitivos de Java o bien clases que implementen la interfaz Serializable de Java. De esta forma, tanto los parmetros como el resultado
podrn viajar por red del cliente al servidor y al revs.
El Objeto Remoto
Se debe hacer una clase que implemente esa InterfaceRemota, es decir,

que tenga los mtodos que se quiere llamar desde un cliente rmi.
El servidor de rmi se encargar de instanciar esta clase y de ponerla
a disposicin de los clientes. Esa clase es la que se llama objeto remoto.
Esta clase remota debe implementar la interfaz remota que se ha
denido (y por tanto implementar tambin la interfaz Remote de Java),
denir mtodos como hashCode (), toString (), equals (), etc., de forma
adecuada a un objeto remoto. Tambin debe tener mtodos que permita
obtener referencias remotas, etc.
La forma sencilla de hacer esto es hacer que la clase herede de UnicastRemoteObject.
El cdigo sera similar al mostrado en la gura 5-4 de la pg. 92.
Otra opcin es no hacerlo heredar de UnicastRemoteObject.
Una vez compilado se obtiene el chero ObjetoRemoto.class, se necesita crear la clase de stubs.
Para que desde un programa en un ordenador se pueda llamar a un
mtodo de una clase que est en otro ordenador, est claro que de alguna
92
Figura 5-4 Objeto remoto.
manera se debe enviar un mensaje por la red de un ordenador a otro,

indicando que se quiere llamar a determinado mtodo de determinada
clase y adems pasar los parmetros de dicha llamada.
Una vez ejecutado el mtodo, el ordenador que lo ha ejecutado debe
enviar un mensaje con el resultado.
La clase de stubs es una clase con los mismos mtodos que ObjetoRemoto, pero en cada uno de esos mtodos est codicado todo el tema del
envo del mensaje por la red y la recepcin de la respuesta.
Afortunadamente para el programador, no se tiene que codicar todo
este problema de mensajes de ida y vuelta. Java proporciona una herramienta llamada rmic a la que se le pasa la clase ObjetoRemoto y devuelve la clase de stubs ObjetoRemoto_stubs.
Slo se tiene que poner en la variable de entorno CLASSPATH el
directorio en el que est la clase ObjetoRemoto y ejecutar rmic.
Adems se tiene el archivo de poltica de seguridad, que se muestra
Con este contenido, se dan todos los permisos a todo el mundo. No
es la opcin ms segura, pero de momento sirve.
Tambin se puede cambiar la propiedad java.security.policy de la
manera indicada en la gura 5-6 de la pg. 93.
Una propiedad no es ms que un nombre que lleva asociado un valor.
93
Figura 5-5 Permiso de seguridad.
Figura 5-6 Archivo de poltica de seguridad.
As, por ejemplo, la propiedad java.version dice cul es la versin de

Java en la que est corriendo el programa, os.name devuelve el nombre
del sistema operativo, user.home devuelve el directorio por defecto del
usuario, etc.
System.getProperties () devuelve una lista de todas las propiedades
disponibles. De hecho, en la API de Java, para este mtodo, sale una
lista con bastantes de las propiedades existentes.
System.setProperty () ja el valor para una propiedad y System. get
Property () permite obtener el valor de una propiedad.
Lanzar rmiregistry
Antes de registrar el objeto remoto, se debe lanzar desde una ventana

de ms-dos o una shell de linux el programa rmiregistry. Este programa
viene con Java y est en el directorio bin de donde se tenga instalado
Java.
Es importante borrar la variable CLASSPATH para que no tenga
ningn valor que permita encontrar nuestros objetos remotos, por lo que
se aconseja eliminar antes de lanzar rmiregistry.
Si rmiregistry est en el PATH de bsqueda de ejecutables (o si se
est situado en el directorio en el que est), se lanzara de la siguiente
94
manera indicada en la gura 5-7 de la pg. 94.
Figura 5-7 Lanzamiento de rmiregristry.
Adems se debe poder indicar cul es el path en el que se puede

encontrar la clase correspondiente al objeto remoto, en el ejemplo, el
path en el que se puede encontrar ObjetoRemoto.class.
Dicho path se da en formato URL, por lo que no admite espacios ni
caracteres extraos.
Si se dej las clases ObjetoRemoto.class, InterfaceRemota.class y ObjetoRemoto_Stubs.class en c:\prueba_servidor, el path, en formato URL,
sera como sigue le://localhost/prueba_servidor. En vez de localhost
puede ponerse la IP.
El cdigo para indicar esto se muestra en la gura 5-8 de la pg. 94.
Figura 5-8 Indicacin de la ubicacin del cdigo base.
Consiste en jar una propiedad de nombre java.rmi.codebase con el

path donde se encuentran los cheros .class remotos.
Se debe ver que haya un gestor de seguridad. Para ello se comprueba
si existe y si no hay, se aade. El cdigo para ello se muestra en la gura
5-9 de la pg. 95.
95
Figura 5-9 Gestor de seguridad.
Para instanciar una clase remota y luego registrarla en el servidor de

rmi es suciente el sencillo cdigo que se muestra en la gura 5-10 de la
pg. 95.
Figura 5-10 Instancia y registra un objeto en el servidor rmi.
La instanciacin no tiene problemas. Para registrarla hay que llamar al mtodo esttico rebind () de la clase Naming. Se le pasan dos
parmetros. Un nombre para poder identicar el objeto y una instancia
del objeto. El nombre que se ha dado debe conocerlo el cliente, para
luego poder pedir la instancia por el nombre.
El mtodo rebind () registra el objeto. Si ya estuviera registrado, lo
sustituye por el que se acaba de pasarle.
El Cliente de RMI
Ahora slo se tiene que hacer el programa que utilice este objeto de
forma remota.
Los pasos que debe realizar este programa son los siguientes:
Pedir el objeto remoto al servidor de rmi. El cdigo para ello se indica
Se llama al mtodo esttico lookup () de la clase Naming. Se le pasa
a este mtodo la URL del objeto. Esa URL es el nombre (o IP) del
96
Figura 5-11 Solicitud de objeto remoto.
host donde est el servidor de rmi (en este caso localhost) y por ltimo
el nombre con el que se registr anteriormente el objeto (en el ejemplo
ObjetoRemoto ).
Este mtodo devuelve un Remote, as que se debe hacer un cast a
InterfaceRemota para poder utilizarlo. El objeto que se recibe aqu es
realmente un ObjetoRemoto_Stubs.
Se procede a llamar al mtodo de suma () segn se muestra en la gura
5-12 de la pg. 96.
Figura 5-12 Llamado a un mtodo.
Para que el cdigo del cliente compile necesita ver en su classpath a InterfaceRemota.class. Para que adems se ejecute sin problemas necesita
adems ver a ObjetoRemoto_Stubs.class, por lo que estas clases deben
estar accesibles desde el servidor o bien tener copias locales de ellas.
Socket
Pasos Para Crear un Servidor

Los pasos requeridos son los siguientes:
1. Crear el socket servidor.
97
2. Aceptar un cliente.
3. Obtener los InputStream y / o OutputStream del cliente.
4. Crear unos InputStream y / o OutputStream ms adecuados a las
necesidades.
5. Leer y escribir datos del y al cliente.
6. Cerrar el socket.
Crear el Socket Servidor

Para hacer el servidor en Java se teine la clase ServerSocket. Al instanciarla se usar el constructor al que se le pasa un nmero de servicio (de
puerto).
Este nmero de puerto puede ser cualquier entero entre 1 y 65535.
Los nmeros de 1 a 1023 estn reservados para servicios del sistema
(como ftp, mail, www, telnet, etc, etc).
Del 1024 en adelante se puede usarlos a gusto. Lo nico es que no
puede haber dos servidores atendiendo al mismo puerto / servicio (ver
Figura 5-13 Creacin del socket servidor.
Aceptar un Cliente
Una vez creado el servidor, se le dice que empiece a atender conexiones

de clientes.
Para ello se llama al mtodo accept (). Este mtodo se queda bloqueado hasta que algn cliente se conecta. Devuelve un socket, que es la
conexin con dicho cliente (ver gura 5-14 de la pg. 98).
98
Figura 5-14 El servidor activa la atencin a un cliente.
Se puede aceptar simultneamente varios clientes, pero para atenderlos se necesita programacin multitarea o algo similar.
Obtener el InputStream y / o OutputStream
Ahora en cliente se tiene la conexin con el cliente (valga la redundancia).

Lo nico que se tiene que hacer es obtener de l el OuputStream o
InputStream con los mtodos getOutputStream () o getInputStream ().
La clase OutpuStream sirve para enviarle datos al cliente.
La clase InputStream sirve para leer datos del cliente (ver la gura
5-15 de la pg. 98).
Figura 5-15 Lectura y envo de datos.
Crear unos InputStream y / o OutputStream Ms

Adecuados a las Necesidades
Si se quiere enviar o recibir tipos normales (enteros, otantes, strings) se

tiene las clases DataInputStream y DataOutputStream.
Estas clases tienen un constructor que admite un InputStream y un
OutputStream respectivamente (ver la gura 5-16 de la pg. 99).
99
Figura 5-16 Objetos para recibir datos (enteros, otantes, strings).
Si se quiere enviar o recibir clases enteras propias nuestras, se tiene

las clases ObjectInputStream y ObjectDataStream.
Al igual que las anteriores, se usa el constructor que admite un InputStream y un OutputStream (ver gura 5-17 de la pg. 99).
Figura 5-17 Objetos para recibir o enviar clases.
Estas nuevas clases tienen mtodos como writeInt (), writeChar (), etc.
Leer y Escribir Datos Del y Al Cliente

Envio / lectura de datos normales (enteros, otantes, strings)
El envo / lectura de datos normales se hace con las clases DataInputStream y DataOutputStream.
No tienen ningn truco especial, basta usar el mtodo adecuado
(writeInt (), writeFloat (), readInt (), etc).
Para strings se usan los mtodos writeUTF () y readUTF (), que envan / leen las cadenas en formato UTF.
Envio / lectura de clases enteras
Para el envio / lectura de clases normales se usan los mtodos readObject () y writeObject () de ObjectInputStream y ObjectOutputStream.
Para poder usar estos mtodos las clases deben implementar la inter-
100
face Serializable.
Las clases de tipos de Java (Integer, Float, String, etc.) implementan
esa interface, as que se pueden enviar / leer a travs de estos mtodos.
Si una clase nuestra contiene atributos que sean primitivos de Java
(int, oat, etc) o clases primitivas (Float, Integer, String, etc.), basta
con hacer que implemente la interface Serializable para poder enviarlas.
No hace falta que se escriba ningn mtodo, simplemente poner que
se implementa (ver gura 5-18 de la pg. 100).
Figura 5-18 Implementa interface Serializable.
Si alguno de los atributos no es primitivo de Java, basta con que

implemente la misma interface Serializable.
Si es as, no se tendr ningn problema (ver gura 5-19 de la pg.
101).
Si alguna de las clases no es Serializable, se tendrn que implementar
los mtodos privados (ver gura 5-20 de la pg. 101).
En el mtodo writeObject () se debe enviar por el ObjectOutputStream
todos los atributos de nuestra clase, en el orden que se considere adecuado.
En el mtodo readObject () se debe ir leyendo del ObjectInputStream
todos los atributos de nuestra clase e ir rellenando nuestros atributos.
El orden en que se lee debe ser el mismo que en el que se escribe y el
formato ledo el mismo que el escrito.
101
Figura 5-19 Implementa interface Serializable.
Figura 5-20 Dene mtodos privados.
Para enviar una de estas clases el cdigo es sencillo (ver gura 5-21
de la pg. 102).
Para leerlo es igual de simple, slo que se tiene que saber qu tipo de
clase se est recibiendo para hacer el cast adecuado (ver gura 5-22 de
la pg. 102).
Se debe ir haciendo varios if con las posibles clases que se nos enven
desde el otro lado.
102
Figura 5-21 Mtodo WriteObjet.
Figura 5-22 Lectura de objetos por socket.
Cerrar el Socket
Para cerrar un socket hay que llamar a la funcin close () (ver gura 5-23
de la pg. 102).
Figura 5-23 Cierre de una conexin cliente y servidor.
Pasos Para Crear un Cliente
Para el cliente se tiene la clase Socket.

Basta instanciarla indicndole contra qu mquina conectarse y el
puerto con el que debe conectarse.
Debe ser el mismo que el puerto que est atendiendo el servidor (ver
El resto es igual que en el servidor.
103
Figura 5-24 Creacin de una conexin cliente.
Los objetos SocketC.java, objMsg.java, objRem.java implementan los

conceptos enunciado en este captulo.
Parte II
Desarrollos Efectuados y
Conclusiones
104
Captulo 6
Desarrollo del Producto

Introduccin
En concordancia con los objetivos que propone esta Tesis, se elaboran
dos versiones del prototipo a los cuales el autor los denomina YOSUKO
Versin 1.0 y YOSUKO Versin 2.0.
Las versiones del prototipo han sido elaboradas con diferentes tcnicas
de programacin de Sistema Experto Basado en Reglas, con la nalidad
de detectar en tiempo real el camino ptimo de comunicacin de los
datos entre las computadoras que tienen la funcin de servir informacin
(servidores) a las distintas computadoras conectadas a la red.
105
106
Objetivos del Prototipo

Los objetivos perseguidos en la construccin del prototipo fueron los
siguientes:
Utilizar software de bajo costo para la funcin de servir informacin entre las distintas mquinas que tienen el rol de servidores
conectadas a la red con tipologa remota.
Detectar la seal ms estable para la transmisin de los datos.
Detectar la ruta ptima de comunicacin entre los servidores.
Transmitir informacin al Sistema Gestor de Bases de Datos (My
SQL) desarrollado bajo la losofa de cdigo abierto que puede ser
utilizado gratuitamente. El lenguaje normalizado que se utiliza
para llevar adelante esta comunicacin con la base de datos es el
Structured Query Language (SQL), que no es ms que un lenguaje
estndar de comunicacin con bases de datos.
Integrar aplicaciones informticas construidas en la dcada de los
70 con las aplicaciones de ltima generacin, utilizando un procedimiento lgico que las comunica.
Estudio Comparativo de Ambas Versiones del Prototipo

El estudio comparativo permite resumir lo siguiente:
Se construy como simulador del objetivo,

fue construido con un procedimiento lgico que integra el lenguaje
YOSUKO Ver. 1.0:
107
de programacin orientado a objetos Java con el lenguaje de programacin procedural Clipper 5.2. El potencial de esta versin
radica en la utilizacin de la tcnica de programacin que se utiliza
para la confeccin del Motor de Inferencia, la regla Modus Ponens
y estrategias de inferencias Encadenamiento de Reglas, la cual se
representa en la sintaxis como &, ejemplo: if &reglas (Ver archivo
fuente Lectorre.prg ).
YOSUKO Ver 2.0: Es el producto nal, que se detalla en forma
completa durante el desarrollo de este captulo.
Los objetivos generales de la Tesis rigen el desarrollo de cada versin

del prototipo, con la premisa de encontrar la mejor solucin para el
planteamiento del problema.
A continuacin se detalla el funcionamiento del protocolo YOSUKO
V2.0, donde se visualiza la diferencia de versiones del prototipo, destacando las tcnicas de programacin utilizadas.
Protocolo YOSUKO V. 2.0.
Introduccin
Esta versin del prototipo est desarrollada totalmente con el lenguaje

de programacin Java, utilizando los conceptos vistos en el captulo 3:
Programacin con el modelo de Sockets, como un mecanismo de

comunicacin entre procesos.
Protocolo TCP/IP.
Programacin RMI.
Conexin al motor de base de datos MySQL, por medio del lenguaje
estndar de comunicacin SQL.
108
Lectura y grabacin de archivos binarios.
Planteo del Problema

El problema estudiado se puede resumir con el siguiente planteo:
1. La mayora de las aplicaciones informticas comerciales de
la provincia de Misiones se encuentran programadas con tecnologas que carecen de la capacidad de utilizar comunicacin
sobre protocolos de red TCP/IP, sintaxis del lenguaje estndar SQL, programacin con el modelo de Sockets, Gestor de
Bases de Datos, entre otros, debido a que el lenguaje de programacin utilizado para la construccin de las aplicaciones
no est diseado para la comunicacin entre cliente / servidor
que requiere la poca actual. Este hecho, exige al programador
emigrar a otros lenguajes de programacin de ltima generacin que contemplen mayores funcionamientos, situacin
que implica costo en la licencia del software, reprogramacin
del sistema de informacin, capacitacin del recurso humano,
modernizacin de la infraestructura tecnolgica, etc.
2. Hoy en da las empresas deben ser competitivas, la informacin debe estar a disposicin en cualquier parte del mundo
las 24 hs., a disponibilidad de los directivos de las mismas.
Situacin que conlleva a estar conectado a un motor de Base
de Datos, disponer de aplicaciones informticas que accedan
a la informacin en tiempo real.
Estudio de Factibilidad para Brindar una Solucin al

Problema
Los aspectos ms relevantes son los siguientes:
Los sistemas operativos Windows 9x o superior y Linux Ver. x,

han creado un mtodo de conexin a travs de la red de Internet,
109
que crea el efecto de un tnel, a travs del cual la informacin se

transmite en forma segura, denominado Red Privada Virtual, Virtual Private Networks (VPN ), permitiendo a las aplicaciones que
se ejecuten en una Intranet a travs de la red Internet. El riesgo
de este mtodo de conexin se presenta cuando la comunicacin
es inestable, existiendo la posibilidad de corromper los archivos.
Otra debilidad que presenta es en el momento de ejecutar una aplicacin informtica que no sea de arquitectura cliente / servidor, ya
que produce lentitud en el funcionamiento del sistema operativo,
ocasionando conicto en la red de comunicaciones.
Otra solucin que se le presenta al programador de aplicaciones, es
utilizar programas de control remoto, por ejemplo VNC que son
las siglas en ingls de Virtual Network Computing (Computacin
en Red Virtual ), o el pcAnywhere, entre otros, que estn basados en
una estructura cliente / servidor, la cual permite tomar el control de
la computadora servidor remotamente a travs de una computadora
cliente; el inconveniente que presenta esta solucin es que el control
del teclado o del mouse (ratn) es mono usuario.
Otra opcin que se presenta como alternativa, es ejecutar una
sesin remota, utilizando el sistema operativo Linux que es uno
de los paradigmas del desarrollo de software libre (y de cdigo
abierto), con el inconveniente de que su funcionamiento se vuelve
lento cuando la comunicacin es inestable.
Conclusin del Estudio de Factibilidad

Como conclusin del estudio de soluciones posibles para resolver el problema formulado, se presentan dos mtodos:
Servidor Centralizado.
Servidor Descentralizado.
110
Desarrollo de la Experiencia
Para desarrollar el protocolo que propone esta Tesis, y mostrar una solucin factible a los problemas mencionados, as como los benecios de tener
servidores descentralizados a nivel de costo, balanceo de carga, etc., se
toma como ejemplo experimental una empresa de transporte de pasajeros
de larga distancia de la ciudad de Posadas, provincia de Misiones, teniendo en cuenta que la informacin de disponibilidad de asientos debe
estar en tiempo real, y centralizada.
Cliente : Empresa de transporte de pasajero de larga distancia de la
ciudad de Posadas, provincia de Misiones.
Problema : Resolver las ventas de boletos en tiempo real, teniendo en
cuenta que posee Puntos de Ventas en Chile, Paraguay, Brasil, Argentina.
Anlisis del Mtodo de Resolucin con Servidor Centralizado

Fortaleza : La informacin depende de una sola central.
Debilidad : Todos los puntos que poseen grandes movimientos de ventas deben tener conexiones punto a punto, estables y ecientes, teniendo
en cuenta que la cada de los enlaces de comunicacin representa p rdida
de dinero para la empresa. El costo aproximado de un enlace punto a
punto en la Argentina por punto de venta es de $ 4.500 Acceso Frame
Relay (desde 64 K a 2 Mb). Si se tiene en cuenta que las boleteras
estn en pases limtrofes, requieren utilizar comunicacin internacional,
la nica opcin en lnea estable a niveles de enlace es el Acceso Satelital
(desde 128 K hasta 512 K), con un costo de $ 1.500 por punto.
Anlisis del Costo de un Servidor Centralizado
Debido a que la informacin debe estar centralizada, el servidor debe

tener la capacidad de soportar las solicitudes de los puntos remotos de
ventas (balanceo de carga), y los ataques de intrusos.
Se requiere de un servicio de recuperacin del servidor en caso de
cada, y demanda que las aplicaciones informticas sean construdas con
estructura cliente / servidor, y sistema gestor de bases de datos.
111
A modo ilustrativo se adjunta un presupuesto de Infraestructura Tecnolgica con un requerimiento mnimo (ver gura 6-1 de la pg. 111.
Figura 6-1 Presupuesto de servidor.
A su vez, el presupuesto del Sistema Gestor de Bases de Datos SQL

Server asciende a un monto de $ 8.000.
Costo total de un servidor centralizado con los accesorios

que se detallan: $26.887,40.
Anlisis del Mtodo de Resolucin con Servidores Descentralizados

Fortaleza : Los principales aspectos son los siguientes:
Optimiza el balanceo de carga, porque se distribuye la informacin.
112
La empresa no depende de la comunicacin, dado que los servidores

centrales se encuentra en los puntos de venta con mayor demanda
de pasajes, es decir una central en Chile, Paraguay, Argentina y
Brasil.
Utiliza aplicaciones de legado (legacy) desarrolladas en la dcada
de los 70, esto implica el requerimiento de servidores de bajo costo.
Debilidad : Los principales puntos son los siguientes:
Demanda mantenimiento de la informacin.

Demanda mantenimiento de los servidores.
Si el sistema de venta estuviera automatizado a travs de aplicativos informticos desarrollados con un lenguaje de programacin
de ltima generacin que requiere de motor de base de datos, no
tendra sentido este mtodo por el costo que demanda por servidor,
aproximadamente $26.887,40.
Anlisis del Costo de un Servidor Descentralizado

Con una aplicacin informtica desarrollada con un lenguaje de programacin no de ltima generacin, no se requiere utilizar un Sistema
Gestor de Bases de Datos, como as tambin un servidor con las caractersticas que se describen en el anlisis de costos del Mtodo de Resolucin con Servidor Centralizado, tratado en el apartado anterior.
Por lo tanto, con un servidor de muy bajos requerimientos, se pueden
implementar aplicaciones informticas, dando solucin al problema formulado en el enunciado de la experiencia.
Costo Aproximado y Especicaciones Tcnicas
1 Placa Materborad Standar.
2 Discos de 80 GB.
1 Banco de memoria de 1 GB.
113
1 Micro procesador tipo Intel 2.3 Ghz.

1 Disquetera.
1 Grabadora de DVD.
1 Monitor de 17 pulgadas.
El costo total aproximado es de $2.000.
El costo aproximado de la UPS es de $1.500.
Costo total del equipamiento: $3.500.

Anlisis de Costo por Tipos de Enlaces de Comunicacin
Se utiliza la Lista de Precios de proveedores locales de la ciudad de
Posadas, Misiones, Argentina, para observar los valores que tiene cada
tipo de conexin:
Comunicacin a travs de Mdem (mxima velocidad de transmisin: 56 K): $25,00.

ADSL (mxima velocidad de transmisin: 5 Mb): $350,00.
Acceso Frame Relay (desde 64 K a 2 Mb): $4.500,00.
Acceso Satelital (desde 128 K hasta 512 K): $1.500,00.
Teniendo en cuenta que el protocolo YOSUKO V. 2.0 se desarroll
con la premisa de funcionar con comunicaciones inestables, de bajo
costo, se va a utilizar el segundo mtodo de resolucin propuesto.
Planteo de Base
Se parte de la hiptesis que existen tres centrales y dos proveedores
de comunicacin por punto, los cuales utilizan comunicacin ADSL con
un costo de $ 350,00.
Objetivo : Detectar el mejor camino.
Cada servidor tiene dos salidas de comunicacin: CPA (Comunicacin Proveedor A) y CPB (Comunicacin Proveedor B).
114
Existen tres servidores A-B-C (MAQUINA A (Posadas), MAQUINA

B (Retiro), MAQUINA C (Neuqun) (ver gura 6-2 de la pg. 114).
Figura 6-2 Costo de la comunicacin.
El Servidor Mquina A Solicita Informacin al Servidor Mquina

C.
Caminos posibles:
CAMA + CAMD.
CAMC + CAMB.
CAMA + CAMB.
CAMC + CAMD.
CAME.
En la introduccin de la Tesis, se menciona que el protocolo YOSUKO

debe estar programado en lenguaje Java, y utilizar un Sistema Experto
Basado en Reglas.
115
Arquitectura Utilizada para Desarrollar el Protocolo

La arquitectura se muestra en la gura 6-3 de la pg. 115.
Figura 6-3 Arquitectura utilizada para el sistema experto.
Base de Conocimiento Yosuko V 1.0.

Reglas de Inferencia: Generadas por el Experto o Ingeniero del Conocimiento.
Se parte de un ejemplo con la nalidad de observar cmo se genera
la base del conocimiento.
El servidor A solicita informacin al servidor C (tambin es
aplicable al caso en que el servidor C solicita informacin al servidor
A).
Caso 1 : Un pasajero quiere viajar de Posadas a Neuqun, o Neuqun
a Posadas.
(CAMA + CAMB) < (CAMC + CAMD) AND (CAMA + CAMB) <
CAME ME VOY POR CAMA + CAMB.
116
(CAMA + CAMD) < (CAMB + CAMC) AND (CAMA + CAMD) <

CAME ME VOY POR CAMA + CAMD.
(CAMB + CAMC) < (CAMA + CAMD) AND (CAMB + CAMC) <
CAME ME VOY POR CAMB + CAMC.
(CAMC + CAMD) < (CAMA + CAMB) AND (CAMC + CAMD) <
CAME ME VOY POR CAMC + CAMD.
(CAME < (CAMA + CAMB)) AND (CAME < (CAMC + CAMD))
ME VOY POR CAME.
El servidor A solicita informacin al servidor B (aplicable al caso
en que el servidor B solicita al servidor A).
Caso 2 : Un pasajero quiere viajar de Posadas a Retiro, o de Retiro a
Posadas.
CAMA < CAMC AND CAMA < (CAME + CAMB) AND CAMA <
(CAMD + CAME) ME VOY POR CAMA.
CAMC < CAMA AND CAMC < (CAME + CAMB) AND CAMC <
(CAMD + CAME) ME VOY POR CAMC.
(CAME + CAMB) < CAMA AND (CAME + CAMB) < CAMC AND
(CAME + CAMB) < (CAME + CAMD) ME VOY POR CAME
+ CAMB.
(CAME + CAMD) < CAMA AND (CAME + CAMD) < CAMC AND
(CAME + CAMD) < (CAME + CAMB) ME VOY POR CAME
+ CAMD.
El servidor B solicita informacin al servidor C (aplicable al caso
en que el servidor C solicita al servidor B).
Caso 3 : Un pasajero quiere viajar de Retiro a Neuqun, o de Neuqun
a Retiro.
CAMB < CAMD AND CAMB < (CAMA + CAME) AND CAMB <
(CAMC + CAME) ME VOY POR CAMB.
117
CAMD < CAMB AND CAMD < (CAMA + CAME) AND CAMD <
(CAMC + CAME) ME VOY POR CAMD.
Nota : Los campos CAMA, CAMB , CAMC y CAMD contienen el
promedio del tiempo exacto que tardan los paquetes de datos en ir y
volver a travs de la red, desde un Servidor a otro Servidor al cual el autor
denomina Tiempo Promedio de Respuesta (TPR); el Motor de Inferencia
toma estos valores, analiza las reglas y obtiene el menor tiempo, con lo
cual establece el mejor camino.
Almacenamiento de las Reglas

Para tomar la decisin, y decidir la programacin del Motor de Inferencia,
se desarrolla tres mtodos de conguracin de reglas.
Almacenamiento de Reglas YOSUKO V1.0. (Mtodo 1)

La estructura del archivo donde se almacenan las reglas del protocolo
YOSUKO V1.0. se muestra en la gura 6-4 de la pg. 117.
Figura 6-4 Estructura del almacenamiento de las reglas.
118
El archivo en el que se graba el conocimiento o reglas se muestra en

la gura 6-5 de la pg. 118.
Figura 6-5 Archivo de reglas.
Debilidades del Primer Mtodo de Resolucin

Las principales debilidades se sealan a continuacin:
El Experto o Ingeniero del Conocimiento, debe generar las
reglas.
Si el lenguaje de programacin no tiene el comando & (por
ejemplo: If &reglas), no se podra programar el algoritmo,
tal como se observa en la gura 6-6 de la pg. 119, y se tendran que agregar internamente las reglas dentro del lenguaje.
De esta manera, el costo que demandara generar el conocimiento
sera muy alto, y sera difcil mantenerlo.
El acceso a la informacin es secuencial.
Almacenamiento de Reglas YOSUKO V2.0. (Mtodo 2)
119
Figura 6-6 Algoritmo del motor de inferencia de YOSUKO V.1.0.
Teniendo en cuenta los problemas de la versin anterior, y el objetivo

de encontrar el Motor de Inferencia ms eciente, se desarrollan 2 (dos)
mtodos:
Reglas de encadenamiento.
Grafos completos (Matriz de Adyacencia).
Generacin de Reglas por Medio del Mtodo Encadenamiento

de Reglas
Se parte del supuesto que se cuenta con un objeto Java en todos los nodos
activos del sistema, el cual tiene por objetivo informar a todos los nodos
que se encuentran en la tabla de nodos activos el valor (TPR), hora,
minuto, segundo. Esta informacin sirve al nodo emisor para analizar si
hay comunicacin con el nodo destino, cuando va a transmitir los datos.
Proceso Para Transmitir
El proceso realizado para transmitir se detalla a continuacin:
120
Por primera vez se carga en memoria el nodo inicial, con todas las
direcciones IP, que van a existir en la red (ver la Tabla de Nodos
Habilitados en la gura 6-7 de la pg. 120, archivo Nodos.dat ).
Figura 6-7 Archivo de nodos.
Se ejecuta el proceso de informar la direccin IP a todos los nodos

que conforman el sistema.
Una vez que todos los nodos tienen grabada la tabla de direcciones
IP, se puede ejecutar el objeto aprender las rutas posibles (encadenamiento de reglas), para llegar a todos los nodos; esto signica
que se realizan dos procesos:
Proceso 1 (Generar el Primer Camino):
1. Lee la tabla de nodos activos.

2. Conecta al nodo destino, por medio de la programacin a travs
del modelo Socket utilizando el puerto XXXX.
3. Verica si existe el nodo destino, caso armativo se transmite el
registro segn diseo de la gura 6-8 de la pg. 122.
4. Se graba en el campo reglas la IP del nodo origen. En este campo
se registran todos los nodos que el archivo recorri para llegar al
nodo destino. Tambin se lo denomina a este campo IP del que
pide .
5. Termina el proceso (generar la primera ruta alternativa).
121
6. El nodo destino lee el archivo contenedor de reglas (ver gura 6-8

de la pg. 122), extrae del campo reglas la IP (IP del que pide).
Ejecuta el comando Ping a la IP que se extrajo, calcula el promedio
(TPR), transmite ese valor a la IP que se hizo el clculo.
Proceso 2 (Generar Otro Camino Alternativo):
1. El nodo origen toma la siguiente IP, que est en la tabla nodos (ver
2. Transmite el registro (paquete), segn diseo de la gura 6-8 de la
pg. 122, a la IP seleccionada.
3. Recibe el paquete la IP seleccionada.
4. Analiza el nodo destino. En caso que no sea igual al nodo destino,
realiza el siguiente proceso:
(a) Toma la IP destino que est grabado en el registro que recibi.
(b) Transmite ese pedido al nodo destino, previa alteracin campo
Reglas (IP del que pide), agregando en dicho campo la IP del
nodo que transmite.
5. Una vez que el pedido lleg al nodo destino, ste le transmite al
nodo origen el registro segn diseo de la gura 6-8 de la pg. 122.
Concluido el proceso, el nodo destino lee el archivo contenedor de
reglas (ver gura 6-8 de la pg. 122), extrae del campo reglas la IP
(IP del que pide). Ejecuta el comando Ping a la IP que se extrajo,
calcula el promedio (TPR), transmite ese valor a la IP que se hizo
el clculo.
A continuacin se muestra un ejemplo:
Dados cuatro nodos IP 1.1 , 1.2 , 1.3 , 1.4, se generan las rutas posibles
entre los nodos 1.1 y 1.3.
Regla No. 1
122
Figura 6-8 Archivo contenedor de reglas.
Figura 6-9 Regla 1 del ejemplo.
Ver la gura 6-9 de la pg. 122.

Regla No. 2
Regla No. 3
Regla No. 4
Para confeccionar la regla, se realiza el siguiente proceso: el nodo 1.2
123
enva al nodo 1.4, el nodo 1.4 enva al nodo 1.3.
Regla No. 5
Para confeccionar la regla, se realiza el siguiente proceso: el nodo 1.4
enva al nodo 1.2, el nodo 1.2 enva al nodo 1.3.
Se denen reglas coherentes, estableciendo ciertas restricciones.

No se puede pedir a la IP, que est, en el campo reglas (del que
pide); ejemplo: El nodo 1.4, no enva (paquete) al nodo 1.2, porque la
124
IP 1.2 est en el campo reglas (IP del que pide). Si no se establece esta
restriccin, entrara en un ciclo repetitivo, entre el nodo 1.2 y el nodo
1.4.
Terminado el proceso y respetada la restriccin, se transmite el archivo
contenedor de reglas, al nodo origen.
Pasos Para Calcular el Valor TPR Los pasos son los siguientes:
Se ejecuta el comando Ping.

Selecciona y suma el valor de los tiempos exactos que tardan los
paquetes de datos en ir y volver a travs de la red, desde un Servidor
a otro Servidor (promedio).
Divide por 4 (se tom 4 muestra).
El valor obtenido se denomina TPR.
En el caso de que uno de los valores diga tiempo espera agotado ,
se penaliza con un valor alto (1000), cosa que el promedio de IP
sea el mayor.
Pasos para Transmitir el Promedio de IP Se toma la ltima IP

que se encuentra en el campo reglas (del que pide), y se transmite el TPR
(promedio).
A continuacin, se observa un ejemplo analizando la cuarta regla:
125
El Nodo 1.3 mira la regla No. 4.

Saca la ltima IP, en este caso es 1.4.
Hace un Ping a 1.4.
Calcula el TPR (promedio) contra ese punto.
Transmite el promedio.
El nodo IP 1.4 recibe ese valor y graba en el campo fecha-horamin.seg. que recibi el pedido (se considera la fecha-hora del servidor que recibe el pedido, porque hay que considerar que los servidores pueden tener diferencias horarias). Este dato es muy importante, para determinar si la comunicacin es reciente.
El Nodo 1.4 analiza el campo IP origen (1.1).
EL Nodo 1.4 es distinto al origen (1.1).
Toma la IP del campo Reglas (del que pide), teniendo en cuenta
que debe ser la IP que se encuentra detrs del nodo que analiza
(1.4), en este ejemplo es 1.2.
Hace Ping a 1.2. y calcula TPR.
Acumula el valor anterior, ms el nuevo valor, y transmite al nodo
1.2.
El Nodo 1.2 analiza el campo IP origen (1.1).
El Nodo 1.2 es distinto al origen (1.1).
Toma la IP del campo Reglas (el que pide), teniendo en cuenta que
debe ser la IP que se encuentra detrs del nodo que analiza(1.2),
en este caso es 1.1.
Hace Ping a 1.1. y calcula TPR.
Acumula y le transmite al nodo 1.1.
El nodo 1.1 detecta que es igual a la IP origen, toma el valor recibido
y actualiza el campo TPR de la regla No. 4.
126
Termina el proceso.
Pasos Para Calcular el Promedio de IP Los pasos se detallan

seguidamente.
1.
Se Ejecuta el comando Ping.

Se extraen los valores de medicin (ver gura 6-14 de la pg. 126).
Figura 6-14 Clculo de ping modelo 1.
Pedidos de la Aplicacin Externa al Nodo 1.1.

El nodo 1.1 recibe un pedido de una aplicacin externa que necesita
transmitir un archivo al nodo 1.3.; para detectar el mejor camino, realiza
el siguiente proceso:
Abre el Archivo Reglas.dat.

Selecciona todas las Reglas (camino) que tienen IP destino 1.3.
Busca el menor valor del campo TPR.
Saca el camino del campo regla (el que pide) y transmite el archivo
en esa secuencia.
127
Grafos Completos (Matriz de Adyacencia)

En la versin YOSUKO V.2. se utiliza tcnica de grafos completo no
dirigido, y se carga el TPR (promedio) en una matriz de adyacencia.
Se congura una matriz de 100 nodos como mximo en el objeto
SocketC.java, permitiendo a este protocolo escuchar 100 direcciones IP.
String Des [] = new String [100]; // Descripcin de los Nodos
String Puertos[] = new String [100]; // Puerto de los Nodos
String IP [] = new String [100]; // IP de los Nodos
Float Ping [][] = new Float [100][100]; // Matriz con los valores TPR
Generacin de Reglas Se generan las reglas en el objeto ABMNodos.java , en el evento (botn) crear reglas cmdCrearR_Click (int Nivel).
Criterio Para Generar las Reglas Dados cuatro nodos: 1,2,3,4, se
realizan todas las combinaciones posibles de ese nmero (rutas posibles),

en el nodo que ejecut el evento. Ejemplos: 1000, 1001, 1002, 1003, 1100,
etc., 2000, 2001, ,2223, etc.
Control de Coherencia Para que sea un Nodo Vlido Las condi-
ciones que se deben cumplir para que una ruta sea vlida son las siguientes:
Debe existir un nodo origen y un nodo destino, al principio de la

combinacin, (se guarda, en la posicin 1 y 2 del vector Regla), si
algunos de estos lugares esta vaco (0), se descarta la regla. Ej:
1200 correcto, 1030: incorrecto, 1000: incorrecto.
Vericar que no exista un cero despus del ltimo nmero mayor a
cero de la combinacin. Ej.: 1200 correcto, 1201: incorrecto, 1302
incorrecto, 1340 correcto.
128
Vericar que no se repita un nodo en toda la regla. Ej.: 1230

correcto, 1321: incorrecto, 2123: incorrecto.
Una vez generadas todas las reglas, de todos los nodos, se graban
en el archivo reglas.txt.
Nota : El nico que tiene derecho a modicar o borrar reglas, en este

objeto, es el servidor, los nodos clientes slo tienen derecho a generar
las reglas. A este proceso se hace referencia en el manual del usuario
YOSUKO V2.0.
Ventajas del Algoritmo Utilizado Las ventajas se pueden resumir
como sigue:
Muy fcil de programar, se mantiene la informacin en memoria.

La cantidad de nodos depende de la cantidad de memoria disponible
en el procesador de cada aplicacin.
El acceso es directo, para detectar el mejor camino sobre la matriz,
nicamente hay que ingresar el nodo origen, y el nodo destino.
Procedimiento Para Calcular el Promedio de IP El procedimiento

es el siguiente:
Se Ejecuta el comando Ping.

Se selecciona el valor TPR (promedio), que viene incorporado en
el comando Ping (ver gura 6-15 de la pg. 129).
Para seleccionar el promedio, el algoritmo busca la palabra ms, y

extrae el nmero.
Se observa que cuando uno de los valores exprese tiempo espera
agotado, el promedio aumenta.
129
Figura 6-15 Clculo TPR segundo mtodo.
Ahora, en el caso de que no haya comunicacin, la sigla ms no

aparece, entonces se penaliza con un valor alto (1000), con el propsito
de que el promedio de IP sea el mayor.
Procedimiento Para Transmitir el Promedio de IP El mtodo
que se utiliza es de un grafo completo no dirigido (ver gura 6-16 de la

pg. 130), es decir todos los nodos del sistema YOSUKO V.2., hacen
ping contra todos los nodos leyendo la tabla nodos.dat.
El Nodo X, captura la respuesta del Ping extrayendo el TPR (promedio), y graba en la Matriz ; se considera el nodo origen como la y el nodo
destino como columna M (Origen,Destino).
El nodo origen toma el valor TPR (promedio), e informa a todos los
nodos de la red. El benecio con este mtodo, es que, cualquier nodo
de la red conoce el estado de toda la red de cualquier nodo, en todo
momento.
130
Figura 6-16 Grafo completo no dirigido.
Estudio Comparativo Entre los dos Mtodos de Resolucin

Se llega a la conclusin de que el segundo mtodo es mejor, por las
siguientes razones:
Calculo de IP : Las consideraciones son las siguientes:
El clculo del promedio en el segundo mtodo lo hace el comando

Ping, en cambio en el primer mtodo lo hace la aplicacin.
En el caso de que el comando Ping cambie la forma de presentar
los datos, el primer mtodo requiere que se reprograme la rutina
de clculo TPR.
En cambio utilizando el segundo mtodo, nicamente se deber
reprogramar, si no aparece la palabra ms.
Generacin de Reglas : Las consideraciones son las siguientes:
El segundo mtodo es ms fcil de programar.
131
En el primer mtodo se debe tener en cuenta que puede caer algn

nodo, cuando est generando las reglas, y no se percibir si le faltan
algunas de ellas. En cambio el segundo mtodo genera las reglas
en forma local, y no depende de la comunicacin.
En el segundo mtodo, todas las reglas de todos los nodos estn
en cada nodo, en cambio en el primer mtodo se encuentran nicamente las reglas de ese nodo.
Transmicin del Promedio de TRP para las IP : Las consideraciones

son las siguientes:
El primer mtodo tiene la desventaja de que debe transmitir al

nodo destino por cada regla que tiene en el archivo contenedor de
reglas ; es decir, N reglas x N nodos.
En cambio, el segundo mtodo nicamente transmite 1 x cantidad
de nodos; por lo tanto es ms eciente el segundo mtodo cuanto
mayor es el nmero de nodos.
Conclusin
El estudio comparativo de los mtodos de resolucin propuestos lleva a la
siguiente conclusin: el protocolo YOSUKO V.2.0 se basar en el mtodo
Grafo completo no dirigido (Matriz de adyacencia).
Captulo 7
Seguridad a Nivel de Informacin

Introduccin
Existen varios factores a la hora de evaluar la seguridad de un sistema.
A continuacin se resumirn algunos conceptos:
Condencialidad: La informacin slo ha de poder ser accedida

por las personas autorizadas. Puede ser de datos (protegindolos
por encriptacin), o condencialidad de ujo (en la que se trata de
ocultar quin es el destinatario).
Integridad: Se necesita saber que los datos recibidos no han podido
ser modicados por alguien distinto del emisor. Adems la integridad de secuencia asegura que los bloques de informacin recibida
han llegado en el orden en que fueron enviados.
132
133
No repudio: Herramienta que permite probar que se tuvo una comunicacin con un determinado usuario, de modo que alguien no
pueda negar el haber recibido algo, ni otro pueda negar haber mandado algo. Esto se suele conseguir con la rma digital.
Control de acceso: Los sistemas deben estar protegidos, de modo
que slo pueda acceder a sus recursos la persona autorizada. Esto
se consigue mediante passwords (contraseas ).
Seguridad fsica: Los soportes fsicos de un sistema deben estar protegidos de descargas, incendios, acceso de personas no autorizadas.
Autenticacin: Se trata de poder saber si algo es de quien dice ser,
si algo no ha sido falsicado. Se suelen usar mecanismos asimtricos
como la rma digital.
Teniendo en cuenta los conceptos de seguridad, se estableci en el

protocolo YOSUKO V2.0., la Seguridad Control de Acceso, y la Seguridad
de Condencialidad .
Se organiz de la siguiente forma:
A Nivel de Aplicacin.
Cuando se Transmite la Informacin.
A Nivel Usuarios.
Seguridad Nivel de Aplicacin

El objetivo de este mdulo es controlar la piratera del software, para
ello, se estableci, como medida de seguridad, el siguiente esquema de
trabajo:
Tener una licencia, que habilite a cada servidor de nodos instalado.

Registrar el producto, cuando se instala por primera vez.
134
Pasos Para Registrar el Producto

El producto se encuentra comprimido, en una la carpeta que se denomina
YOSUKO.
Se debe ejecutar el botn instalar, y cargar los datos que solicita la
Figura 7-1
Pantalla donde se registra el producto.
Una vez concluida esta operacin, el sistema YOSUKO se conecta

con el proveedor, que gener el producto, para registrar, vericar si es
vlido, y que no est duplicado el registro del producto, a travs de una
conexin SQL.
Una vez que se comprob la validez, internamente, el sistema YOSUKO,
con los datos ingresados genera un registro, en el archivo control.dat.
Este mtodo permite controlar que la aplicacin est registrada una
sola vez.
135
Seguridad Cuando se Transmite la Informacin
Este mdulo tiene por objetivo vericar si la informacin transmitida es

de un nodo vlido, activado por la aplicacin.
Se utiliza el mtodo de comparacin entre dos puntos, por medio de
un valor denominado dgito vericador.
Dgito Vericador
Seguidamente se detalla cmo funciona el control.
Ejemplo: Dados dos nodos A,B, el nodo A transmite una informacin
al nodo B y realiza el siguiente proceso:
El nodo A toma su IP y calcula el dgito vericador de la siguiente

forma:
Multiplica por 3 cada nmero que conforma el IP.

Acumula el valor del producto.
El resultado nal del producto acumulado se divide por 11.
El algoritmo se encuentra programado en el objeto socketC.java(),
clase CalcDV():
// Esta rutina devuelve como resultado un nmero, que
se va a usar como dgito vericador
// entre los paquetes de transmisin.
public int CalcDV (String strIP) {
// Recibe como parmetro la IP de la mquina y la convierte en un array de bytes,
// para luego poder procesarlos.
byte IP[] = strIP.getBytes();
int i;
int dv = 0;
// Realiza un bucle por todos los elementos del array (IP),
lo multiplica * 3
136
// y acumula sus valores en la variable dv.

for (i=0; i<10; i++) dv+=IP[i] * 3;
// Luego la sumatoria se divide por 11 y termina el proceso.
dv/=11;
return dv;
}
//
Inserta en el registro a transmitir el dgito vericador.
El nodo B toma la IP del nodo A leyendo el archivo read.dat, y

ejecuta el mismo algoritmo para calcular el dgito vericador.
Verica si el dgito enviado por el nodo A es el mismo valor calculado, por el nodo B.
En el caso que no sea igual al dgito, ignora el pedido, y graba en
el archivo log el mensaje Intruso a nivel transferencia de datos,
controle.
En el caso de que sea igual al dgito, contina el proceso normalmente.
Encriptar y Desencriptar los Datos
Se realiza en el objeto ObjMsg.java () en la clase Encrip () y DesEncrip ().

Se comprob que al sumar o restar cualquier nmero positivo, en un
archivo binario, se altera el contenido del mismo.
Se consider que este algoritmo cumple con los niveles de seguridad
a nivel encriptacin.
Los pasos para lograr la encriptacin son:
Alterar el contenido, del archivo binario, sumando un nmero uno.
137
Transmitir el archivo alterado.

Volver al estado normal. Una vez recibido el nodo receptor, debe
llegar al mismo estado original del archivo. Para lograrlo resta un
uno.
Este mtodo se puede transformar en un algoritmo de alta seguridad.

Se realiza el siguiente proceso:
Sumar un nmero aleatorio byte x byte.

Tomar el nmero aleatorio, pasarlo a binario previa alteracin,
sumando un uno.
Grabar este nmero en una posicin determinada, en el archivo
binario.
Transmitir el archivo.
Una vez que se recibe los datos, el nodo receptor, procede a:
Buscar la posicin donde est el nmero aleatorio.

Transformar al nmero aleatorio en el nmero original (restando
un uno).
Transforma el archivo binario restando el nmero aleatorio.
Seguridad Nivel Usuarios
En este mdulo se registran los usuarios y las claves de todos los nodos
(servidores,clientes) que van a estar activos en la aplicacin.
Secuencia de Control
Cuando la aplicacin se ejecuta a nivel usuario se deben ingresar los
siguientes datos:
138
Nombre de usuario.
Contrasea.
IP del servidor.
El sistema verica si existe el servidor (primer padre ).

En caso armativo, transmite el nombre de usuario y contrasea.
El servidor padre captura estos datos, analiza si existe un usuario con
los datos ingresados, leyendo la tabla control.dat .
En caso armativo emite al nodo cliente el nmero 1. Este dgito le
habilita al nodo cliente para empezar a operar el sistema. Caso contrario
el servidor padre registra en el archivo log un mensaje Intruso a nivel
clave de aplicacin e ignora a este nodo.
En el caso de que no exista el servidor (primer padre), el usuario de
la aplicacin cliente ingresa la IP del servidor (segundo padre ).
En caso de que no exista este servidor, no se podr ejecutar la aplicacin.
En los dos servidores debe estar registrado el usuario (objeto ABMnodos.java ).
Diagrama en Bloque del Sistema

En la gura 7-2 de la pg. 139, se indica el funcionamiento del protocolo
YOSUKO V.2.0.
Cada nodo tiene los mismos objetos. La diferencia que existe entre
un nodo servidor y nodo cliente, es solo el objeto RMI, que est activo
nicamente en el nodo servidor.
Figura 7-2 Esquema funcional de nodos.
Captulo 8
Metodologa de Integracin
de YOSUKO V.2.0 y Aplicaciones Informticas
Introduccin
En el presente captulo se desarrolla la metodologa incorporada en el
protocolo YOSUKO V. 2.0, para lograr el objetivo de integrar las aplicaciones informticas construidas con tecnologas de programacin antiguas
con aplicaciones informticas construidas con las tecnologas de programacin de ltima generacin.
Se parte de la base de que conviven aplicaciones informticas que
carecen de capacidad de comunicacin, con las aplicaciones informticas
programadas bajo los nuevos conceptos de tecnologas de la informacin
y de la comunicacin.
140
Metodologa de Integracin de YOSUKO V.2.0 y Aplicaciones Informticas
141
Con el objetivo de brindar una solucin de bajo costo a este problema que presenta el escenario descripto, se incorpora al algoritmo del
protocolo YOSUKO V. 2.0, las siguientes funciones:
Comunicacin entre procesos.

Comunicacin entre cliente / servidor.
Invocacin de los mtodos remotos, a travs de la programacin
RMI.
Conexin al motor de base de datos MySQL, por medio del lenguaje
estndar de comunicacin SQL.
Lectura y grabacin de archivos binarios.
El Protocolo YOSUKO V. 2.0 y las

Aplicaciones Externas
El diagrama de interaccin del protocolo YOSUKO V.2.0 para integrar
aplicaciones externas se muestra en la gura 8-1 de la pg. 142.
Contenido del Archivo Read.dat
El archivo Read.dat es un archivo binario con la estructura que se
muestra en la gura 8-2 de la pg. 143.
El contenido de los campos del archivo binario Read.dat se detalla a
continuacin:
Estado del Proceso : Este campo se utiliza para que la Aplicacion

Externa y YOSUKO V. 2.0, se pongan de comn acuerdo.
Signicado del Campo:
Figura 8-1
externas.
142
ma de interaccin de YOSUKO con las aplicaciones
Diagra
1. YOSUKO Nodo Local recibe una orden de una Aplicacin

Externa para emitir un pedido a un Nodo Remoto.
2. YOSUKO informa a la Aplicacin Externa que est realizando el pedido solicitado por dicha Aplicacin Externa.
3. YOSUKO informa a la Aplicacin Externa que termin el
proceso de transmitir el pedido.
4. La Aplicacin Externa informa que est realizando una
tarea, YOSUKO espera que termine para continuar el proceso.
5. La Aplicacin Externa informa que termin la tarea y
YOSUKO trasmite el archivo generado por la Aplicacin
Externa.
Cdigo de Actividad : Este campo se utiliza para relacionar el

archivo Read.dat con el archivo Activ.dat y proc.dat.
Nmero Orden de Trabajo: Es un nmero mayor a cero que se
utiliza para relacionar con el archivo proc.dat.
Nombre del Archivo que se va a Transmitir : Este campo contiene
el nombre del archivo que se va a transmitir al Nodo Destino.
143
Figura 8-2 Estructura del archivo Read.dat.
Identicador de Procesos : Es un campo mayor a cero, no repetitivo. La Aplicacin Externa lleva el control, y sirve para que se
diferencien los procesos.
Tiempo de Espera en Minuto : Este campo contiene el tiempo mximo que va a esperar la Aplicacin Externa, al protocolo YOSUKO,
para que realice el pedido solicitado.
Tiempo de YOSUKO : Este campo es utilizado por el protocolo; se
graba la hora, minuto, segundo, del nodo que recibe el pedido.
El protocolo YOSUKO V. 2.0 utiliza otros archivos en forma interna
144
para poder realizar las tareas encomendadas por la Aplicacin Externa.

El diseo del modelo fsico de datos se detalla a continuacin.
Activ.dat : En este archivo se dene el nombre de la actividad;

ejemplo: empresa xxxx, administracin, depsito. etc. (ver la
Figura 8-3 Archivo binario Activ.dat.
Control.dat : Se utiliza para registrar el nodo local (objeto Cong.java ). Si este archivo est vaco, se activa el mdulo registrar el
producto en el servidor de la empresa que va a distribuir el mismo
(ver en el captulo 7, Seguridad a Nivel de Aplicacin (ver estructura del archivo en la gura 8-4 de la pg. 145.
Nodos.dat : Se registran los nodos (Servidores, Clientes ) que

van a estar activos en la red. Adems este archivo se utiliza para vericar si es un usuario vlido dentro del sistema
(ver captulo 7, Seguridad a Nivel Usuario (ver estructura del
archivo en la gura 8-5 en la pg. 146).
Proc.dat : En este archivo se graban los procesos que el programador de la Aplicacin Externa quiere que realice el protocolo
YOSUKO. El detalle de los campos es el siguiente:
145
Figura 8-4 Archivo binario Control.dat.
Cdigo de Actividad : Se utiliza para relacionar el archivo Activ.dat.

Orden de Trabajo : Es un nmero mayor a cero, no se puede
repetir, y se utiliza para diferenciar, los distintos procesos que
pueda tener el protocolo YOSUKO V.2.0.
Tipos de procesos : Puede tener dos estados:
Transmite el pedido y termina el proceso.
Transmite el pedido, espera respuesta, y retrasmite el pedido.
Nmero de Nodo Destino : Indica el punto nal de la transmisin de paquetes, emitidos por el nodo emisor.
Tipos de transmisin : Puede tener 2 estados:
Transmite archivos al nodo destino.
Transmite y ejecuta comandos SQL (Select, Insert, Update, Delete) en el nodo destino.
ID Usuario : Se utiliza para identicar el nombre de usuario
que tiene derecho a ingresar al motor de Base de Datos, y
ejecutar el comando SQL, provisto por la Aplicacin Externa.
Contrasea : Clave para acceder al motor de Base de Datos.
146
Figura 8-5 Archivo binario Nodos.dat.
URL Base de Datos : Es la direccin IP donde reside fsicamente el Motor de Base de Datos.
Puerto: Puerta de entrada donde escucha el Motor de Base
de Datos.
Separador de Campos : Indica al protocolo YOSUKO V.2.0
cmo tiene que presentar la informacin, despus de haber
ejecutado el comando Select.
La estructura del archivo se muestra en la gura 8-6 de la pg. 147.
Descripcin Operativa del Sistema de

Integracin
La Aplicacin Externa, denominado ApliExt a modo de ejemplo, solicita a YOSUKO V. 2.0 que enve un archivo del Nodo 1 al Nodo 3 .
147
Figura 8-6 Archivo binario Proc.dat.
Se realiza de la siguiente forma:
El programador de la ApliExt graba en l Nodo 1:
Archivo Activ.dat :
Actividad = 1, Nombre de la actividad = Sistema Dinmico

de Transferencia, Carpeta de trabajo = D:/ACT1/.
Archivo Proc.dat :
Actividad =1, Orden de trabajo = 1, Tipo de proceso =
1, Nodo destino = 3, Tipo de transmisin = 1.
Archivo Read.dat:
148
Estado = 1, Cdigo de Actividad = 1, Orden de Trabajo

= 1, Nombre del Archivo = MisFotos.zip, Nmero de
proceso = 100, Tiempo de espera = 2.
YOSUKO V 2.0 , en el Nodo 1, realiza el siguiente proceso:

Lee el archivo Read.dat, detecta que tiene un proceso pendi
ente, porque tiene un uno en el campo estado.

Graba el campo estado un dos.
Toma el campo Actividad, y lee el archivo Activ.dat, realiza
una bsqueda secuencial para extraer el nombre de la actividad, y la carpeta del lugar de trabajo.
Lee el archivo Proc.dat , compara los campos Actividad, Orden
de trabajo. Si encuentra un registro con iguales caractersticas, toma los datos tipo de proceso, nodo destino, tipo de
transmisin.
Detecta el mejor camino. Transmite el archivo, primero al
Nodo 2, y despues al Nodo 3. Ver Captulo 6, Grafos Completo
(Matriz de Adyacencia).
Transmite la informacin al Nodo 2.
La Aplicacin Externa denominada ApliVtaBoleto a modo ejemplo, solicita a YOSUKO V. 2.0. que enve un archivo del Nodo 1 al Nodo
3. Espera recibir un archivo procesado por la otra aplicacin externa que
est en el Nodo 3.
El programador de la ApliVtaBoleto graba en el Nodo 1:
Archivo Activ.dat:
Actividad = 2, Nombre de la actividad = Empresa de
Transporte de Pasajeros de Larga Distancia. Carpeta de
trabajo = D:/ACT2/.
Archivo Proc.dat :
Metodologa de Integracin de YOSUKO V.2.0 y Aplicaciones Informticas 149
Actividad = 2, Orden de trabajo = 2, Tipo de proceso =

Archivo Read.dat :
Estado = 1, Cdigo de Actividad = 2, Orden de Trabajo
= 2, Nombre del Archivo = Vtaremo.dbf, Nmero de
Proceso = 101, Tiempo de espera = 1.
YOSUKO V 2.0 en el Nodo 1, realiza el siguiente proceso:
Lee el archivo Read.dat, determina que tiene un proceso pendiente, porque tiene un uno en el campo estado.
una bsqueda secuencial para extraer el nombre de la Actividad, y la Carpeta del lugar de trabajo.
Lee el archivo Proc.dat, compara los campos Actividad, Orden
transmisin.
Detecta el mejor camino. Pasa el archivo, primero por el Nodo
2, y despus por el Nodo 3.
YOSUKO V 2.0 en el Nodo 2 determina que no es el nodo nal de

la transmisin. Pasa el pedido al Nodo 3.
YOSUKO V 2.0 en el Nodo 3 determina que es el nal de la transmisin y realiza lo siguiente:
Analiza el campo Tipo de proceso. En este caso es dos.

Lee el archivo Activ.dat, saca la ubicacin de la carpeta.
Graba el archivo vtaremo.dbf, en la carpeta donde se estableci para esa actividad.
Marca con un cuatro el campo estado, la aplicacin externa,
del nodo 3, determina que tiene que hacer un trabajo, porque
el protocolo YOSUKO del nodo 3, est esperando una respuesta, para enviar de vuelta el archivo.
Terminado el proceso de la Aplicacin Externa ApliVtaBoleto,

se graba en el archivo Read.dat un valor 5 en el campo estado.
Se determina que la aplicacin externa termin el proceso. Entonces, se analiza el tiempo de espera de la aplicacin externa,
si est fuera del lmite de tiempo, marca con un tres el campo
Estado del archivo Read.dat y termina el proceso.
En el caso de que est dentro del tiempo establecido por la
aplicacin externa, toma el archivo vtaremo.dbf, y transmite al nodo 1.
Graba un tres en el campo Estado del archivo Read.dat.
Termina el proceso.
La Aplicacin Externa denominada ApliSql, a modo ejemplo, solicita a YOSUKO V. 2.0 . que enve un archivo, del Nodo 1 al Nodo 3.
Espera recibir un archivo procesado, con la informacin que se extrajo
del Motor de Base de Datos RRRR, que est en el Nodo 3.
El programador de la ApliSql graba en l Nodo 1:
Archivo Activ.dat :
Actividad = 2, Nombre de la actividad = Empresa de
Transporte de Pasajeros de Larga Distancia. Carpeta de
trabajo = D:/ACT2/.
Archivo Proc.dat :
Actividad = 2, Orden de trabajo = 3, Tipo de proceso =
Archivo Read.dat:
Estado = 1, Cdigo de Actividad = 2, Orden de Trabajo = 3, Nombre del Archivo = comando.txt, Nmero
de Proceso = 102, Tiempo de espera = 3, Id Usuario =
KOKI, Contrasea = 123, Base de Datos = RRRR, URL
=192.168.1.1, Puerto = 4000, Separador de Campo = ,.
En el campo comando.txt, va la sentencia SQL Select .
YOSUKO V. 2.0 en el Nodo 1, realiza el siguiente proceso:
Lee el archivo Read.dat, determina que tiene un proceso pendiente, porque tiene un uno en el campo estado.
una bsqueda secuencial, para extraer el nombre de la Actividad, y la Carpeta del lugar de trabajo.
Lee el archivo Proc.dat, compara los campos Actividad, Orden
transmisin.
Detecta el mejor camino. Pasa el archivo, primero por al Nodo
2, y despues al Nodo 3.
YOSUKO V. 2.0 en el Nodo 2, determina que no es el nodo nal

de la transmisin. Pasa el pedido al Nodo 3.
YOSUKO V. 2.0 en el Nodo 3, determina que es el nal de la
transmisin y realiza lo siguiente:
Analiza el campo Tipo de proceso. En este caso es dos.

Lee el archivo Comand.txt, que vino en el paquete recibido.
Analiza el tipo de comando SQL, en este caso es una orden
Select .
Ejecuta el comando SELECT.
Graba en memoria la consulta.
Arma un paquete con la informacin.
Agrega el delimitador de campo,.
Marca con un tres el campo estado.
Analiza el tiempo mximo de espera establecido por la aplicacin externa. Si est fuera del lmite de tiempo, marca con
un tres el campo estado del archivo Read.dat.
Transmite el pedido al Nodo 1.
Termina el proceso.
En caso que sea una orden SQL Insert, Update, Delete, el proceso es
el mismo. Slo que no transmite el archivo al Nodo 1.
Algoritmo del Sistema Integracin

El algoritmo del sistema de integracin se detalla seguidamente:
public void run() {
int IDAct;
int IDOrden;
int IDProc = 0;
long pedTime;
int waitTime;
int i,j,k;
String FileNam;
boolean valid = false;
try {
dbRead = new DB(Read.dat, 7, 20, rw);
dbProc = new DB(Proc.dat, 15, 30, rw);
for (i=0; i<dbRead.getRecCount(); i++) {
dbRead.Go(i);
// Nombre del archivo a transmitir.
FileNam = null;
Est = (int) Integer.valueOf (dbRead.getValue(0).trim());
IDAct = (int) Integer.parseInt(dbRead.getValue(1).trim());
IDOrden = (int) Integer.parseInt(dbRead.getValue(2).trim());
FileNam = dbRead.getValue(3).trim();
IDProc = (int) Integer.parseInt(dbRead.getValue(4).trim());
waitTime = (int) Integer.valueOf(dbRead.getValue(5).trim());
pedTime = (long) Long.valueOf(dbRead.getValue(6).trim());
valid = true;
Term.dbAct.Go(IDAct-1);
// Si es 1, tiene que realizar un proceso.
if (Est == 1) {
for (j=0; j<dbProc.getRecCount(); j++) {
dbProc.Go(j);
if (Integer.valueOf(dbProc.getValue(0).trim()) == IDAct &&
Integer.valueOf(dbProc.getValue(1).trim()) == IDOrden) {
Term.TipoProc = Integer.valueOf(dbProc.getValue(2));
Term.NodDes = (int) Integer.valueOf(dbProc.getValue(3));
Term.IDProc = IDProc;
Term.TSQL = (int) Integer.valueOf(dbProc.getValue(4));
// Solo cuando es SQL
if (Term.TSQL == 2) {
Term.DatosDB[0] = dbProc.getValue(5).trim();
}
// En el caso de que el proceso sea de tipo 1 (enviar y no esperar respuesta),
// se graba un valor 3, indicando que ha terminado.
if (Term.TipoProc == 1) {
dbRead.setValue(0, 3);
Term.addTask(Pedido No + String.valueOf(IDProc).trim() + terminado.);
} else {
// Si es de tipo 2 (enviar y esperar respuesta), marca con un 2, que signica
// en proceso y guarda la hora en que se ejecuto el pedido
dbRead.setValue(6, String.valueOf(actTime.getTime()));
Term.addTask(Esperando respuesta para el Pedido No: + String. valueOf
(IDProc) + ...);
}
dbRead.SaveRec();
Term.cmdSend_Click(Term.dbAct.getValue(2), FileNam, IDAct, waitTime);
break;
}
}
}
// Si es 2, se esta realizando un proceso y tengo que vericar que espere una
// respuesta hasta cierto tiempo.
if (Est == 2) {
if (((actTime.getTime() - pedTime) / 60000) >= waitTime) {
Term.addTask(Tiempo de espera agotado para el Pedido No + String.
valueOf (IDProc));
dbRead.SaveRec();
}
}
if (Est == 4) {
if (((actTime.getTime() - pedTime) / 60000) >= waitTime) {
Term.addTask(Tiempo de espera agotado para Transmitir el Pedido No +
String. valueOf (IDProc));
dbRead.SaveRec();
}
}
// Si es 5 tengo que re-transmitir. Este valor puso la aplicacion externa a
Java.
if (Est == 5) {
Term.addTask(Pedido No + String.valueOf(IDProc) + : OK);
dbRead.setValue(0, 3); // 3: proceso terminado.
dbRead.SaveRec();
Term.TipoProc = 1;
Term.NodDes = IDOrden;
Term.IDProc = IDProc;
Term.cmdSend_Click(Term.dbAct.getValue(2), FileNam, IDAct, 0);
}
}
dbRead.Close();
} catch (Exception e) {
if (!valid && Est == 1) Term.addTask(El Pedido No + String. valueOf
(IDProc).trim() +
posee parametros incorrectos.);
dbRead.SaveRec();
dbRead.Close ();
}
}
Prueba de la Implementacin Efectuada

Los pasos son los siguientes:
Se ingresa al servidor de Base de Datos, como se ilustra en la gura

8-7 de la pg. 157.
Figura 8-7
Ingreso al Servidor MySQL.
Se registra el nmero de serie del producto (ver gura 8-8 de la pg.

158 y gura 8-9 de la pg. 158).
Se instala el primer servidor padre YOSUKO V. 2.0, mquina 1
(ver Manual del Usuario en el Anexo).
Se instala el segundo servidor padre YOSUKO V. 2.0, mquina 2
(ver Manual del Usuario en el Anexo).
Se verica el primer nivel de seguridad, a nivel de aplicacin (ver
captulo 7 y la gura 8-10 de la pg. 159).
1.
158
Figura 8-8 Pantalla de registracin del producto.
Figura 8-9 Pantalla de conrmacin.
Una vez registrado el producto, se registra en la aplicacin YOSUKO

los dos servidores (nodos), indicando el nombre de usuario, contrasea, IP, puerto, actividad (ver gura 8-11 de la pg. 159).
Se da de alta a los Nodos clientes (usuarios o servidores comunes),

en el servidor primer padre.
Se instala en la mquina 3 la versin cliente YOSUKO V. 2.0.
Se verica el segundo nivel de seguridad a nivel usuario, ingresando
mal los datos del usuario cliente. La vericacin la realiza el servi-
159
Figura 8-10 Tabla Usuario de la base de datos YOSUKO.
Figura 8-11 ABM de servidores y terminales.
dor RMI Primer Servidor padre 192.168.80.5 (ver la gura 8-12 de

la pg. 160).
Una vez pasado el nivel de seguridad, el usuario cliente se registra

en la aplicacin (ver gura 8-13 de la pg. 161).
Se registra la actividad (ver gura 8-14 de la pg. 162).
160
Figura 8-12 Error en el segundo nivel de seguridad.
Se cargan los procesos (ver gura 8-15 de la pg. 163).
Se apagan los dos servidores, y se verica el nivel de seguridad a

nivel usuario (ver gura 8-16 de la pg. 163).
Una vez cargados los datos obligatorios en cada Nodo, se prueba la

opcin informar nodos. Este mdulo se utiliza para que los dems
usuarios sepan la cantidad de nodos que existe en la red teniendo
en cuenta la actividad. Una vez completado este paso, se podr
calcular las reglas o rutas, que existen entre los nodos.
La gura 8-17 de la pg. 164 muestra la consola sin nodos, en espera

de que se le informe sobre los dems nodos.
La gura 8-18 de la pg. 165 muestra nodos activos.
Prueba de Transmisin de Paquetes

Los pasos para realizar la prueba de transmisin son los siguientes:
161
Figura 8-13 Registro del cliente en la aplicacin.
Se ejecuta el programa de vieja generacin (legacy o aplicacin

legada o heredada ), para probar los enlaces de comunicacin (ver
gura 8-19 en la pg. 165.
Se transmite un paquete del nodo Posadas (IP 192.168.80.4) al

servidor 5 (IP 192.168.80.1) (ver gura 8-20 de la pg. 166).
Se verica la encriptacin de los datos (ver gura 8-21 de la pg.

166).
162
Figura 8-14 Registro de la actividad.
Prueba con Aplicacin Externa de

Ventas de Boletos
Solicita un pedido de ventas de boletos, desde Posadas a Retiro,

fecha 19/02/2006, 20 horas, como se ve en la gura 8-22 de la pg.
167.
En la gura 8-23 de la pg. 167 se muetra cmo el protocolo

YOSUKO toma el pedido de la aplicacin externa y busca el mejor
camino.
Figura 8-15 Registro de procesos.
Figura 8-16 Vericacin del nivel de seguridad a nivel usuario.
Figura 8-17 Panel sin nodos.
164
165
Figura 8-18 Terminal de control con nodos activos.
Figura 8-19 Pantalla de aplicacin de antigua generacin (lenguaje Clipper

5.2).
Figura 8-20 Transferencia entre dos nodos.
Figura 8-21 Archivo encriptado.
166
167
Figura 8-22 Aplicacin de ventas de boletos.
Figura 8-23 Deteccin del mejor camino por parte de YOSUKO para
atender una aplicacin externa.
Captulo 9
Conclusiones y Futuros Trabajos

Los objetivos generales de la tesis, enunciados en la introduccin, se resumen como sigue:
Se deber desarrollar un sistema experto basado en reglas (en lenguaje

Java).
Se deber gestionar el trco entre servidores remotos, utilizando
comunicacin de bajo costo, detectando el mejor camino.
Se deber poder interactuar con los diferentes motores de bases de
datos o sistemas de archivos de los distintos servidores mediante
comandos de SQL.
Se integrar aplicaciones, desarrolladas en la dcada de los aos
70s, a travs de un contenedor de pedidos.
Se deber utilizar algoritmos de seguridad para dar proteccin a
los datos recibidos o enviados por el contenedor de pedidos.
168
169
Luego de haberse realizado el presente trabajo, se lleg a las siguientes

conclusiones principales :
Se ha desarrollado un sistema experto en lenguaje Java. Se adjunta

un CD con las fuentes del sistema.
Se pudo utilizar con el sistema de protocolo desarrolado enlaces de
comunicacin de bajo costo (ADSL) (ver, Anlisis de Costo por
tipo de Enlaces de Comunicacin, capitulo 6).
La aplicacin desarrollada para gestin de trco entre aplicaciones,
permite interactuar con motores de bases de datos (ver captulo 8).
Por razones de tiempo y costo slo se ha probado con el motor de
Base de Datos MySQL. Quedan como pruebas futuras trabajar con
los motores de base de datos Oracle, Informix, DB2 UDB, etc.
En cuanto a integrar aplicaciones desarrolladas en la dcada de
los aos 70s, se realizaron pruebas intensivas con la aplicacin de
Ventas de Boletos, programada en su oportunidad con el lenguaje
Clipper 5.0. para una conocida empresa de transporte colectivo con
amplia cobertura en el pas y en pases vecinos (ver captulo 8).
Respecto al uso de algoritmos para dar proteccin a los datos, se
implementaron algoritmo de encriptacin y de dgito vericador
(ver captulo 6).
El trabajo desarrollado, una vez implementado a nivel comercial,
permitira:
Ahorro en la reprogramacin del software.

Ahorro en servidores costosos.
Ahorro en motores de bases de datos.
Ahorro en costo de comunicacin.
Ahorro en licencias de software.
Seguridad de datos en el momento de transmitir la informacin.
170
En cuanto a los posibles trabajos futuros se menciona lo siguiente:
Se deber implementar el protocolo desarrollado en los dispositivos

mviles (celulares, pocket PC, asistentes personales, etc.).
Se desarrollarn pruebas con transmisin de imgenes entre celulares, para obtener un sistema de video conferencia.
Se efectuarn vericaciones de funcionamiento con otros motores
de bases de datos, tales como Oracle, Informix, DB2 UDB, etc.
Nota : Adems se destaca que los fuentes de la aplicacin sern uti-
lizados en futuros cursos de postgrado que se tiene previsto impartir.
Parte III
Anexo
171
Captulo 10
Anexo
Detalles de los Objetos Ms Importantes del Protocolo YOSUKO V. 2.0
En esta seccin se describen los objetos ms importante del protocolo
YOSUKO V. 2.0.
Main.java(): Arranca la aplicacin :
LoginC.Java(): Solicita el Nombre del Usuario, Clave, IP del Servidor. Verica por RMI los datos ingresados.
LoginS.Java(): Registra el producto en el Motor de Base de Datos
MySQL. Este mdulo activa la proteccin a nivel software:
Solicita el Nombre del Usuario, Clave, IP local, Puerto.
Conecta a un Motor de Base de Datos MySQL.
172
Anexo
173
Registra en el servidor la licencia.

Graba los datos del servidor en el archivo control.dat.
Una vez hecha la consistencia, se convoca a la pantalla principal.

FrmMain.java(): Formulario principal del sistema:
ABMAct.java(): Se dene la actividad, puede ser el nombre de

una empresa, o algn nombre representativo. Ej. Administracin,
Finanzas etc.:
Es obligatorio ingresar la carpeta de trabajo, el Servidor re-
aliza su transaccin de actividad, en ese espacio del disco.

Los datos ingresado se graban en el archivo Activ.dat.
ABMNodos.java(): En este objeto se registran los nodos (Servidores o Clientes), que estarn activos en la red. Los datos ingresados se utilizan para vericar, a travs de RMI, si el usuario tiene
permitido estar en la red.
ABMProc.java(): En este objeto se denen los proceso que puede
realizar un nodo, con una Aplicacin Externa.
ABMUsers.java(): Es una interfaz de usuario. Se utiliza para capturar los datos, conectar con el servidor (primer padre), y vericar
por RMI la veracidad de los datos.
Cong.java(): En este objeto se congura el servidor local o cliente
local.
DB.java(): Este objeto se utiliza como contenedor de archivos con
extensiones variables (XLS, DOC, EXE, BMO, JPG, etc.). Lee y
graba cualquier tipo archivo.
Graco.java(): Se utiliza para representar grcamente los nodos
que estn conectados, y mostrar el mejor camino, cuando se va a
transmite informacin.
Anexo
174
ObjMsg.java(): Este es un objeto Serializable. Se utiliza para

transmitir la informacin entre los diferentes nodos.
DesEncrip(): Descencripta los datos.
Objrem.java(): En este objeto se implementa la programacin RMI.
SocketC.java(): Se encarga de crear sockets Servidor y sockets
Clientes. Esta clase se extiende de la clase Thread (hilo), para
poder escuchar peticiones de los clientes.
Escribir(ObjMsg Pedido): Se ejecuta cuando se intenta transmitir
un paquete al nodo destino.
LeerNodos(): Se encarga de leer todos los nodos que estn registrados en la tabla Nodos.dat.
CalcDV(): Devuelve como resultado un nmero que se usa como
dgito vericador para los paquetes de transmisin.
run(): Evento que convoca objetos.
ActNodos(): Actualizar Nodos.
RecPed:(): Entrada de Pedidos.
setPing(): Actualizar todos los Valores Ping.
ExecSQL(): Consulta SQL.
InfNodos(): Enva informacin a los Nodos.
LeerPing(): Calcula el Ping.
EnviarMsg(): Enva mensajes.
ClientThread(): Crea un hilo.
ActNodos(): Se ejecuta cuando se recibe un paquete que contiene
informacin de Nodos, para actualizar.
getPing(): Crea un hilo para leer un ping.
Anexo
175
Terminal.java(): Pantalla principal del sistema. Muestra una ventana con todos los Nodos y los estado de la interfaz que se comunica
con la clase SocketC para poder enviar y recibir datos.
timer.setInitialDelay(): Tiempo 1.
timer2.setInitialDelay(): Tiempo 2.
Graph.setEstNodo(): Verica el estado del Nodo y lo pinta.
Graph.repaint(): Dibuja todos los nodos.
Server.LeerPing(): Lee los valores de Ping.
Server.InfNodos(): Informa los nodos activos a toda las terminales.
LeerNodos(): Carga en memoria todos los Nodos que actan en la
Actividad seleccionada.
DrawNodos(): Dibuja en memoria el grco.
Graph.repaint(): Baja en pantalla el grco.
cmdBegin_Click(): Activa el servidor con una conexin Socket.
cmdSend_Click(): Enva un mensaje por medio de Socket.
DrawNodos(): Dibuja los Nodos en forma circular en la pantalla.
(para realizar el grco utiliza la funcin Seno, Coseno).
ActNodos(): Informa el estado de los Nodos.
addTask(String Task()): Agrego el proceso en el rea de texto,
muestra los eventos del Nodo.
CalcRegla(): Calcula la mejor ruta o camino, teniendo en cuenta
el Nodo destino.
ProcThread extends Thread: Se ejecuta cuando se dispara el 1er.
temporizador, cada 2,5 seg. Lee toda la tabla Read.dat en busca
de procesos a realizar.
Anexo
176
Manual del Usuario de YOSUKO V.

2.0
Se adjunta un CD con el contenido que se indica en la gura 10-1 de la
pg. 176.
Figura 10-1 Contenido del CD de la tesis.
Pasos Para la Instalacin Modo Servidor

La PC en donde se ejecutar el sistema YOSUKO V.2.0 deber

tener instalado el Runtime de Java V.5.0_03 o superior, el cual se
adjunta en el CD de Instalacin.
Copiar todos los archivos de instalacin a una carpeta (ej.: C:/Yosuko),
con excepcin del driver para MySQL (mysql-connector-java-3.1.12bin.jar). Esta carpeta ser la Carpeta de Trabajo del Sistema,
la cual se deber congurar en la pantalla Conguracin Terminal,
como se ve en la gura 10-3 de la pg. 180.
Copiar el archivo mysql-connector-java-3.1.12-bin.jar a la carpeta
en donde se instal el Runtime de Java (ej.: C:\jre1.5.0_03\lib\ext\).
Si se encuentra en otra ubicacin, buscar el subdirectorio ..\lib\ext\.
Anexo
177
Ejecutar el archivo rmiRegistry.exe, que se encuentra en el directorio bin del Runtime de Java (ej.: C:\jre1.5.0_03\bin\rmiregistry.exe).
Minimizar la aplicacin rmiregistry.exe y ejecutar Servidor.jar.
Luego de crear las Actividades en la pantalla ABM de Actividades.
Se debern crear las respectivas carpetas de trabajo, caso contrario,
no se podr enviar o recibir informacin. Ver la gura 10-4 de la
pg. 181.
Pasos Para la Instalacin Modo Cliente

La PC en donde se ejecutar el sistema YOSUKO V.2.0 deber

tener instalado el Runtime de Java v.5.0_03 o superior, el cual se
adjunta en el CD de Instalacin.
Copiar todos los archivos del paquete de Instalacin a una carpeta
(ej.: C:/Yosuko), con excepcin del driver para MySQL (mysqlconnector-java-3.1.12-bin.jar). Esta carpeta ser la Carpeta de
Trabajo del Sistema, la cual deber congurarse en la pantalla de
Conguracin del Terminal, como se ve en la gura 10-3 de la pg.
180.
Copiar el archivo mysql-connector-java-3.1.12-bin.jar a la carpeta
en donde se instalo el Runtime de Java (ej.: C:\jre1.5.0_03\lib\ext\).
Si se encuentra en otra ubicacin, buscar el subdirectorio ..\lib\ext\.
Ejecutar la aplicacin Cliente.jar. Luego de crear las Actividades
en la pantalla ABM de Actividades, como de ve la gura 10-4 de la
pg. 181.
Se deber crear las respectivas carpetas de trabajo, caso contrario,
no se podr enviar o recibir informacin.
Deber existir el primer Servidor Padre, caso contrario no se podr
ingresar al sistema.
Anexo
178
Panel de Control
La pantalla Panel de Contol tiene el diseo que se muestra en la gura

10-2 de la pg. 179; el usuario podr poner en marcha el Servidor,
presionando el botn Arrancar.
El graco de la derecha mostrar el estado de los nodos de la red de
la actividad seleccionada en el combo Actividad.
Estado del Nodo: Nodo Local (amarillo), Nodo Activo (verde),

Nodo Inactivo (rojo).
Area de Texto Procesos: Muetra todas las acciones que el sistema
est realizando, las que pueden ser, iniciar servidor, recibir pedidos,
enviar pedidos, recibir informacin de Nodos, redireccionar pedidos,
etc.
Botn Grabar Log: Permite grabar las actividades que tubo el Nodo
en un archivo denominado Proceso.log.
Nota : Slo para la versin Servidor estar disponible el botn Informar Nodos.
Conguracin
La pantalla Conguracin del Terminal (ver gura 10-3 de la pg. 180,
permite congurar el nodo local.
Datos solicitados: ID del Nodo , descripcin, contrasea, IP local,
puerto escucha de pedidos, y la Carpeta de Trabajo. Esta carpeta es
de suma importancia, ya que todos los archivos del paquete de instalacin debern estar ubicados all. La ruta deber colocarse con barras
invertidas y terminar con una de ellas (ej.: c:/Yosuko/).
Anexo
179
Figura 10-2 Pantalla panel de control.
ABM de Actividades
Esta pantalla permite realizar Altas, Bajas y Modicaciones de las distintas Actividades que el Sistema YOSUCO deber ejecutar (ver la
Datos a Ingresar : ID de Actividad, Descripcin, Carpeta de Trabajo
(deber colocarse con barras invertidas y terminar con una barra, ej.:
d:/Actividad1/).
Los archivos de transferencia, dependiendo de la actividad, deben
estar situados en esta carpeta.
ABM de Terminales (Modo Servidor)

Permite realizar Altas, Bajas y Modicaciones a todos los Nodos de la
Red. Slo est activo modo servidor (ver la gura 10-5 de la pg. 181).
Anexo
180
Figura 10-3 Pantalla de conguracin del terminal.
Una vez que el Administrador (Servidor) registra los datos (ID de

Nodo, Descripcin, Contrasea, Puerto, IP, Actividad) de los Nodos
que posean la versin Cliente de YOSUKO, ste deber informar a sus
Clientes quines son los que participan en el intercambio de informacin
dentro de la red.
Para ambas versiones (Cliente y Servidor), el botn Crear Reglas
permitir generar todas las rutas posibles, grabando en el archivo Reglas.dat, para que YOSUKO pueda elegir el mejor camino, para el envo
de pedidos de un Nodo Origen a otro Final.
ABM de Procesos
Esta pantalla es la interfaz de usuario, entre la Aplicacin Externa y el
protocolo YOSUKO V.2.0.
Se registran procesos, que podr realizar el protocolo (ver gura 10-6
de la pg. 182).
Anexo
181
Figura 10-4 Pantalla ABM de actividades.
Figura 10-5 Pantalla de ABM de terminales.
Estos procesos tendrn un No de orden auto numrico dependiendo

de la actividad.
Datos a Ingresar : Tipo de Proceso (Transmitir; Transmitir y esperar respuesta), Nodo destino, Tipo de Transmisin (cualquier tipo de
archivos o comando SQL).
En el caso de que sea un comando SQL, se deber ingresar el Nombre
de Usuario de la Base de Datos, la contrasea de la Base de Datos, el
nombre de la Base de Datos, la direccin URL de la Base de Datos, el
puerto, y el separador de campo (se utiliza cuando ejecuta el comando
SELECT, sirve para diferenciar los campos, de la consulta.).
Figura 10-6 Pantalla para ABM de procesos.
Bibliografa
[1] Abramson, N., Teora de la Informacin y Codicacin - 6/E,
Paraninfo, Espaa, 1986. ISBN 84-283-0232-4.
[2] Bourdette, J., Aplicaciones de Negocio en Java, PC Fornum S.A.,
ISBN 987-9131-79-1, 1998.
[3] Carracedo Gallardo, J., Seguridad en Redes Telemticas. Mc Graw
Hill, Espaa, 2004. ISBN 84-481-4157-1.
[4] Castillo, E.; Cobo, A.; Gmez, P.; Solares, C., Java - Un Lenguaje
de Programacin Multiplataforma para Internet, Paraninfo, ISBN
84-283-2368-2, 1997.
[5] Castillo, E.; Gutirrez, J. M.; Haidi, A. S., Sistemas Expertos y
Modelos de Redes Probabilsticas, Academia de Ingeniera, ISBN 84600-9395-6, 1996.
[6] Castro Marcel (2002). Sistemas Expertos. Consultado en http://
strix.ciens.ucv.ve/ ~iartic/ Material/ PP_Sistemas_Expertos.pdf.
[7] Cathan Cook, Microsoft Corporation, Arquitectura de Bases de
Datos: El Motor de Almacenamiento, artculo publicado en el portal
de Microsoft el 13 de Enero del 2003.
[8] Comer, D. E., Computer Networks and Internets, with Internet Applications - 3/E, Prentice Hall, USA, 2001. ISBN 0-13-091449-5.
[9] Comer, D. E., Hands-On Networking with Internet Technologies 1/E, Prentice Hall, USA, 2002. ISBN 0-13-048003-7.
183
BIBLIOGRAFA
184
[10] Comer, D. E., Internet Book, The: Everything You Need to Know
About Computer Networking and How the Internet Works - 3/E,
Prentice Hall, USA, 2000. ISBN 0-13-030852-8.
[11] Coulouris G.; Dollimire J.; Kindberg, E. Distributed Systems: Concepts and Design, Addison - Wesley, 3sd Edition, 2001.
[12] A. M. Davis; Remontando: Una Necesidad Simple. IEEE Software,
12(5), Septiembre 1995.
[13] Huidobro, J. M., Tecnologas Avanzadas de Telecomunicaciones,
Thomson Paraninfo, Espaa, 2003. ISBN 84-283-2853-6.
[14] Jaworski, J., Java 1.2 al Descubierto, Prentice - Hall, ISBN 84-8322061-X, 1999.
[15] Kennedy, D., Microsoft Corporation, Agrupacin de Conexiones con
Analisys Services de SQL Server 2000, publicado originalmente en
mayo de 2001, actualizado en noviembre de 2002.
[16] Leer, M. McKusick, M. Karels, The Design and Implementation
of the 4.3BSD UNIX Operating System, S.J, Quaterman AddisonWelsey, 1989
[17] Microsoft, Windows NT Workstation Kit de Recursos, McGraw-Hill
/ Interamericana de Espaa, ISBN 84-481-1095-5, 1996.
[18] Poratti, G. G., Redes: La Gua de Referencia Actual y Denitiva,
Mp. Ediciones S.A., ISBN 987-526-208-0, 2004.
[19] Recio, M. J., Redes Locales, ISBN 84-89245-17-7, 1997.
[20] Sheldon, T., Encyclopedia of Networking and Telecommunications 3/E. Mc Graw Hill, USA, 2001. ISBN 0-072-12005-3.
[21] Sheldon, T., LAN Times - Enciclopedia de Redes - Networking 2/E. Mc Graw Hill, Espaa, 1997.
[22] Randall B. Smith, David Ungar. Programming as an Experience:
The Inspiration for Self. Sun Microsystems Laboratories. 1995.
BIBLIOGRAFA
185
[23] Stallings, W., Comunicaciones y Redes de Computadores - 5/E.

Prentice Hall, Espaa, 1999. ISBN 84-89660-01-8.
[24] Stevens Englewood Clis, UNIX Network Programming, NJ: Prentice Hall, 1990.
[25] Stallings, W., Cryptography and Network Security: Principles and
Practice - 2/E, Prentice Hall, USA, 1999. ISBN 0-13-869017-0.
[26] Stallings, W., Data & Computer Communications - 6/E, Prentice
Hall, USA, 2000. ISBN 0-13-084370-9.
[27] Stallings, W., High-Speed Networks and Internets: Performance and
Quality of Service - 2/E, Prentice Hall, USA, 2002. ISBN 0-13032221-0.
[28] Stallings, W., Local and Metropolitan Area Networks - 6/E, Prentice
Hall, USA, 2000. ISBN 0-13-012939-9.
[29] Stallings, W., Network Security Essentials: Applications and Standards - 1/E., Prentice Hall, USA, 2000. ISBN 0-13-016093-8.
[30] Stallings, W., Wireless Communications and Networks - 1/E, Prentice Hall, USA, 2002. ISBN 0-13-040864-6.
[31] Subramanian, M., Network Management: Principles and Practice 1/E. Addison Wesley, USA, 2000. ISBN 0-201-35742-9.
[32] Tanenbaum, A. S., Redes de Computadoras - 3/E. Prentice Hall
Hispanoamericana, Mxico, 1997. ISBN 968-880-958-6.
[33] Tanenbaum, A. S., Van Oteen, M., Distributed Systems: Principles
and Paradigms - 1/E. Prentice Hall, USA, 2002. ISBN 0-13-0888931.
[34] J.E. White, A High-Level Framework for Network-Based Resource
Sharing RFC 707, December 1975
[35] Weiss y Kulikowski, Sistemas Expertos, Prentice-Hall, 1984.
ndice Alfabtico
actividades, 179
ADSL, 3, 113
anexo, 172
API, 33, 87
aplicacin distribuida
seguridad de la, 51
aplicaciones distribuidas
construccin de, 37
diseo, 30
en Internet, 31
applet, 86
ARP, 23
ARPANET, 14
Arpanet, 23
arquitecturas, 10
aspectos
conceptuales, 2
ATM, 12
autenticacin, 52
autenticacin, 35
seguridad, 133
B-ISDN, 10
base
de conocimiento, 69
modelado, 69
bases de datos, 2
broadcasting, 21
cdigo, 88
CDS, 37
clases, 79
cliente, 97, 99, 102, 177
coherencia
control de, 67
COM, 38, 40
computacin
distribuida, 88
entorno de, 37
conclusiones, 168
condencialidad
seguridad, 132
conguracin, 178
conocimiento
abstracto, 59
cadena del, 60
concreto, 59
de control, 58
declarativo, 57
denicin, 60
fuentes, 60
tipos de, 59
control
de acceso, 52
control de acceso
seguridad, 133
CORBA, 42, 88
CPA, 113
CPB, 113
186
NDICE ALFABTICO
dgito
vericador, 135
DARPA, 16
datagrama, 17, 23
estructura, 18
DCE, 37, 39
DCOM, 38, 40
funcionamiento, 41
desencriptar
datos, 136
DFS, 37
direccionamiento, 21
dominio, 25
DTS, 37
encapsulamiento, 81
encriptar
datos, 136
Ethernet, 12, 23
excepciones, 87
FTP, 26
futuros
trabajos, 168
gateways, 20
GDS, 37
grafos, 73, 127
herencia, 83
hiptesis, 4
HTTP, 26
IDL, 42
IIS, 26
impacto
de la investigacin, 5
implementacin
prueba, 157
187
InputStream, 98
integridad
seguridad, 132
Internet, 2, 14, 26
intranet, 26
introduccin
a la seguridad, 132
a los protocolos de comunicacin de datos, 8
a los sistemas distribuidos, 29
al producto desarrollado, 105
IP, 16, 17
IPX, 12
ISO, 10
Java, 4, 27, 80, 85, 176
caractersticas, 86
invocacin remota de mtodos, 44
modelo de objeto distribuido
de, 45
runtime, 176
JDBC, 2, 88
JDK, 47, 49
justicacin
del estudio, 5
JVM, 45, 50
kerberos, 42
LAN, 9
lenguaje
orientado a objetos
propiedades, 80
lista
de adyacencia, 75
mtodos
NDICE ALFABTICO
de comunicacin, 27
marco
conceptual, 6
matriz
de adyacencia, 74
MIT, 42
modelos
de diseo de programas, 6
modus ponens, 64
modus tollens, 64
motor
de inferencia, 69
motor de inferencia, 62
multihilo, 87
MySQL, 106
navegador, 26
no repudio
seguridad, 133
objetivo
general, 3
objetivos
especcos, 4
objeto, 78, 79
componente distribuido
modelo de, 38
remoto, 91
objetos
OCE, 37, 38
ODBC, 2
OLE, 38
OO, 82, 86
ORB, 42
ORPC, 41
OSI
188
funcin, 11
funciones de los niveles, 11
modelo de referencia, 10
niveles, 10
OutputStream, 98
panel
de control, 178
pasar
argumentos y valores
de retorno, 49
plataforma
independencia de la, 86
polimorsmo, 85
POO, 77
POP3, 27
procesos, 180
producto
desarrollo, 105
programacin
orientada a objetos, 77
protocolos
de comunicacin de datos, 8
prototipo
diferentes versiones, 106
objetivos, 106
prueba
aplicacin externa
venta de boletos, 162
de transmisin
de paquetes, 160
PYMES, 5
read.dat, 141
reglas
compilacin, 67
encadenamiento, 66, 67
NDICE ALFABTICO
RMI, 45, 50, 88, 107, 138, 141,

177
cliente de, 95
de Java, 48
capas, 46
rmic, 92
rmiregistry, 93
RML, 88
routing, 20
RPC, 35, 36, 38, 41
ruteo, 19
seguridad, 87
en transmisin de informacin,
135
fsica, 133
nivel aplicacin, 133
nivel usuario, 137
niveles de informacin, 132
poltica de, 89
servidor, 96, 176, 179
centralizado, 110
servidores
de nombres, 24
descentralizados, 111
sesin
remota, 109
sistema
de dominios, 24
de integracin, 146, 152
diagrama
en bloque, 138
experto, 3
basado en reglas, 105
componentes, 58
189
denicin, 57
sistemas
cliente / servidor, 30
distribuidos, 29
expertos, 57
basados en reglas, 62
clasicacin, 61
SMTP, 26
socket, 96, 102
servidor, 97
sockets, 32
SPX, 12
SQL, 4, 106, 107, 141, 145
SSL, 48, 52
stub
del cliente, 36
del servidor, 36
stubs, 92
subredes, 21
TCP, 16, 27, 31, 34, 48
TCP/IP, 10, 12, 15, 32, 107
protocolo, 14
protocolos que trabajan junto
con, 26
tecnologa
cliente / servidor, 2
Telnet, 26
Token Ring, 12
transporte
seguridad en el, 52
TRP, 117, 119, 124
UDP, 27, 34, 48
UNIX, 33
VNC, 109
VPN, 109
NDICE ALFABTICO
WAN, 9
Weiss y Kulikowski
metodologa de, 68
YOSUKO, 105, 107, 113, 115, 127,
138, 140, 141
manual de usuario, 176
objetos, 172
190

Tesis de Trafico

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesis de Trafico

Caricato da

Copyright:

Formati disponibili

Maestra en Informtica y

SISTEMA INTELIGENTE PARA SOLUCIONAR

Estigarribia Oscar Alberto

Magister en Informtica y Computacin

Parte I: Marco Conceptual y Herramientas Utilizadas

Se contina con una revisin de los aspectos ms sobresalientes de la

Parte II: Desarrollos Efectuados y Conclusiones

Parte III: Anexo

Haber llegado a las instancias de presentar esta Tesis de Maestra es

Oscar Alberto Estigarribia

Maestra en Informtica y Computacin

I Marco Conceptual y Herramientas Utilizadas 1

2 Protocolos de Comunicacin de Datos

ARP: Address Resolution Protocol . . . . . . . . . . . .

Denicin de Sistema Experto . . . . . . . . . . . .

5 Programacin Orientada a Objetos

II Desarrollos Efectuados y Conclusiones

6 Desarrollo del Producto

7 Seguridad a Nivel de Informacin

8 Metodologa de Integracin de YOSUKO V.2.0 y Aplicaciones Informticas

9 Conclusiones y Futuros Trabajos

Detalles de los Objetos Ms Importantes del Protocolo YOSUKO

Modelo OSI - Estructura. . . . . . . . . . . . . . . . . .

Grafo completo no dirigido. . . . . . . . . . . . . . . . .

que no justica la inversin de implementar dichas tecnologas.

Justificacin del Estudio

Definicin del Impacto de la Investigacin

Ahorro en la reprogramacin del software.

Resea Sobre Modelos de Diseos de Programas

Programas de red local. Suelen ser programas de bajo costo con

Asimismo, [11, Coulouris Dollimire Kindberg -01] indican respecto

Se ha propuesto el desarrollo de un Sistema Experto con la

Protocolos de Comunicacin de Datos

En resumen, se podra decir que los protocolos son el lenguaje comn

Sincronizacin temporal : Hace referencia a las reglas que debe tener

Protocolos de Comunicacin de Datos

Sincronizacin en el signicado de los mensajes : No slo basta que

Niveles o Capas del Modelo OSI

Protocolos de Comunicacin de Datos

Modelo OSI - Estructura.

Facilitar el estudio de los elementos que componen las redes y los

Funciones de cada uno de los niveles OSI:

Protocolos de Comunicacin de Datos

Establecer una sesin de enlace de datos con igual nivel de

Nivel 3 (red): En este nivel se denen las normas y especicaciones

Protocolos de Comunicacin de Datos

La ventaja de usar paquetes, en vez de, por ejemplo, enviar un

Protocolos de Comunicacin de Datos

Sobre la base del modelo de referencia OSI se desarrollaron otros modelos

Protocolos de Comunicacin de Datos

de datos se encaminaban por otra ruta disponible de la red ARPANET.

Diferencia entre Modelo OSI y TCP/IP.

Protocolos de Comunicacin de Datos

(DARPA) lo puso a disposicin del mundo entero en forma gratuita y sin

Las funciones son las siguientes:

Protocolos de Comunicacin de Datos

Denicin del Nivel IP

Clase A: 8 bits para red, 24 bits para hosts.

Para permitir a los dispositivos intermedios transmitir datagramas,

Protocolos de Comunicacin de Datos

Estructura del Datagrama

Figura 2-3 Estructura del Datagrama.

Versin : Indica a qu versin del protocolo pertenece cada uno de los

Protocolos de Comunicacin de Datos