Maestra en Informtica yComputacinUniversidad 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 laMaestra
para resolver de manera novedosa y a bajo costo, el problema de la inte-
gracin de aplicaciones de legado (legacy) desarrolladas en los aos 70s,
que requieren intercambiar informacin entre diferentes equipos conecta-
dos 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 comu-
nicaciones de datos, en especial el TCP/IP.
El tercer captulo trata de los sistemas distribuidos, revisndose rp-
idamente aspectos relacionados con sockets, RPC, CORBA, RMI, etc.
En el siguiente captulo se presenta una resea acerca de los princi-
pales 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 seguri-
dad 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 Com-
putacin 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, Myr-
iam 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . iv
I Marco Conceptual y Herramientas Utilizadas 1
1 Aspectos Conceptuales 2
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . 3
Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . . 4
Hiptesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Justicacin del Estudio . . . . . . . . . . . . . . . . . . . . . 5
Denicin del Impacto de la Investigacin . . . . . . . . . . . 5
Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . 6
Resea Sobre Modelos de Diseos de Programas . . . . . 6
2 Protocolos de Comunicacin de Datos 8
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Niveles o Capas del Modelo OSI . . . . . . . . . . . . . . . . . 10
Protocolo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . 14
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . 14
Funciones TCP/IP . . . . . . . . . . . . . . . . . . . . . 16
Denicin del Nivel IP . . . . . . . . . . . . . . . . . . . 17
Estructura del Datagrama . . . . . . . . . . . . . . . . . 18
Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Detalles de Direccionamiento: Subredes y Broadcasting . . . . 21
Fragmentacin y Reensamblado del Datagrama . . . . . . . . 23
v
TABLA DE CONTENIDOS vi
ARP: Address Resolution Protocol . . . . . . . . . . . . . . . 23
Sistema de Dominios . . . . . . . . . . . . . . . . . . . . . . . 24
Protocolos que Trabajan Junto con TCP/lP . . . . . . . . . . 26
Protocolos Usados en el Nivel OSI de Aplicacin, Pre-
sentacin y Sesin . . . . . . . . . . . . . . . . . . 26
Mtodos de Comunicacin . . . . . . . . . . . . . . . . . . . . 27
3 Sistema Distribuidos 29
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Enfoques al Diseo de Aplicaciones Distribuidas . . . . . . . . 30
Aplicaciones Distribuidas en Internet . . . . . . . . . . . . . . 31
Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
RPC - Llamadas a Procedimientos Remotos . . . . . . . . . . 35
Diferentes Enfoques Para la Contruccin de Aplicaciones Dis-
tribuida . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Entorno de Computacin Distribuida . . . . . . . . . . . 37
El Modelo de Objeto Componente Distribuido . . . . . . 38
Arquitectura de Intermediacin de Solicitud de Objetos Co-
munes (CORBA) . . . . . . . . . . . . . . . . . . . . . . 42
Invocacin Remota de Mtodos de Java . . . . . . . . . . . . . 44
El Modelo de Objeto Distribuido de Java . . . . . . . . . . . . 45
Las Tres Capas de la RMI de Java . . . . . . . . . . . . . . . 46
Pasar Argumentos y Valores de Retorno . . . . . . . . . . . . 49
Los Objetos y la Invocacin Remota de Mtodos . . . . . . . . 50
Seguridad de la Aplicacin Distribuida . . . . . . . . . . . . . 51
Seguridad en el Transporte . . . . . . . . . . . . . . . . . . . . 52
Autenticacin y Control de Acceso . . . . . . . . . . . . . . . 52
4 Sistemas Expertos 57
Denicin de Sistema Experto . . . . . . . . . . . . . . . . . . 57
Aspectos Fundamentales de los Sistemas Expertos . . . . . . . 58
Componentes de un Sistema Experto . . . . . . . . . . . 58
Tipos de Conocimiento . . . . . . . . . . . . . . . . . . . 59
Fuentes de Conocimiento . . . . . . . . . . . . . . . . . . 60
Denicin del Conocimiento . . . . . . . . . . . . . . . . 60
Clasicacin de los Sistemas Expertos . . . . . . . . . . . 61
Sistemas Expertos Basados en Reglas . . . . . . . . . . . 62
TABLA DE CONTENIDOS vii
El Motor de Inferencia . . . . . . . . . . . . . . . . . . . 62
Modus Ponens y Modus Tollens . . . . . . . . . . . . . . 64
Resolucin . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Encadenamiento de Reglas . . . . . . . . . . . . . . . . . 66
Encadenamiento de Reglas Orientada a un Objetivo . . . 67
Compilacin de Reglas . . . . . . . . . . . . . . . . . . . 67
Control de la Coherencia . . . . . . . . . . . . . . . . . . 67
Metodologa de Weiss y Kulikowski . . . . . . . . . . . . 68
Base de Conocimiento . . . . . . . . . . . . . . . . . . . 69
Modelado de la Base de Conocimiento . . . . . . . . . . 69
Deniciones y Conceptos Sobre Grafos . . . . . . . . . . . . . 73
5 Programacin Orientada a Objetos 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 Ade-
cuados 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Objetivos del Prototipo . . . . . . . . . . . . . . . . . . . . . 106
Estudio Comparativo de Ambas Versiones del Prototipo . . . 106
Protocolo YOSUKO V. 2.0. . . . . . . . . . . . . . . . . . . . 107
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . 107
Planteo del Problema . . . . . . . . . . . . . . . . . . . . 108
Estudio de Factibilidad para Brindar una Solucin al Prob-
lema . . . . . . . . . . . . . . . . . . . . . . . . . 108
Conclusin del Estudio de Factibilidad . . . . . . . . . . 109
Desarrollo de la Experiencia . . . . . . . . . . . . . . . . 110
Arquitectura Utilizada para Desarrollar el Protocolo . . . 115
Base de Conocimiento Yosuko V 1.0. . . . . . . . . . . . 115
Almacenamiento de las Reglas . . . . . . . . . . . . . . . 117
Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7 Seguridad a Nivel de Informacin 132
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Seguridad Nivel de Aplicacin . . . . . . . . . . . . . . . 133
Seguridad Cuando se Transmite la Informacin . . . . . 135
Seguridad Nivel Usuarios . . . . . . . . . . . . . . . . . . 137
Diagrama en Bloque del Sistema . . . . . . . . . . . . . . . . 138
8 Metodologa de Integracin de YOSUKO V.2.0 y Aplica-
ciones Informticas 140
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
El Protocolo YOSUKO V. 2.0 y las Aplicaciones Externas . . 141
Descripcin Operativa del Sistema de Integracin . . . . . . . 146
Algoritmo del Sistema Integracin . . . . . . . . . . . . . . . . 152
Prueba de la Implementacin Efectuada . . . . . . . . . . . . 157
Prueba de Transmisin de Paquetes . . . . . . . . . . . . . . . 160
Prueba con Aplicacin Externa de Ventas de Boletos . . . . . 162
9 Conclusiones y Futuros Trabajos 168
TABLA DE CONTENIDOS ix
III Anexo 171
10 Anexo 172
Detalles de los ObjetosMs Importantes del Protocolo YOSUKO
V. 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Manual del Usuario de YOSUKO V. 2.0 . . . . . . . . . . . . 176
Pasos Para la Instalacin Modo Servidor . . . . . . . . . 176
Pasos Para la Instalacin Modo Cliente . . . . . . . . . . 177
Panel de Control . . . . . . . . . . . . . . . . . . . . . . 178
Conguracin . . . . . . . . . . . . . . . . . . . . . . . . 178
ABM de Actividades . . . . . . . . . . . . . . . . . . . . 179
ABM de Terminales (Modo Servidor) . . . . . . . . . . . 179
ABM de Procesos . . . . . . . . . . . . . . . . . . . . . . 180
Bibliografa 183
ndice Alfabtico 186
Lista de Figuras
2-1 Modelo OSI - Estructura. . . . . . . . . . . . . . . . . . 11
2-2 Diferencia entre Modelo OSI y TCP/IP. . . . . . . . . . 15
2-3 Estructura del Datagrama. . . . . . . . . . . . . . . . . . 18
3-1 La organizacin de sistema distribuido. . . . . . . . . . . 30
3-2 Estructura del servidor. . . . . . . . . . . . . . . . . . . . 32
3-3 Ejemplo de aplicacin distribuida. . . . . . . . . . . . . . 33
3-4 Utilizacin de sockets. . . . . . . . . . . . . . . . . . . . 34
3-5 Filosofa del RPC. . . . . . . . . . . . . . . . . . . . . . 36
3-6 COM y DCOM. . . . . . . . . . . . . . . . . . . . . . . . 54
3-7 Cmo funciona CORBA. . . . . . . . . . . . . . . . . . . 55
3-8 RMI de Java. . . . . . . . . . . . . . . . . . . . . . . . . 55
3-9 Las tres capas de RMI. . . . . . . . . . . . . . . . . . . . 56
4-1 Esquema resumido del funcionamiento de un sistema ex-
perto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4-2 La cadena del conocimiento. . . . . . . . . . . . . . . . . 61
4-3 Regla modus ponens. . . . . . . . . . . . . . . . . . . . . 65
4-4 Regla modus tollens. . . . . . . . . . . . . . . . . . . . . 66
4-5 Proceso de bsqueda en la base de conocimiento. . . . . 70
4-6 Diceo de la regla mediante UML. . . . . . . . . . . . . . 70
4-7 Etapas en el desarrollo de un SE. . . . . . . . . . . . . . 72
4-8 Tipos de grafos. . . . . . . . . . . . . . . . . . . . . . . . 74
4-9 Notacin de grafos. . . . . . . . . . . . . . . . . . . . . . 74
4-10 Grafo completo. . . . . . . . . . . . . . . . . . . . . . . . 75
5-1 Terminologa de objetos. . . . . . . . . . . . . . . . . . . 79
5-2 Reutilizacin de objeto. . . . . . . . . . . . . . . . . . . . 84
5-3 Interface para RMI. . . . . . . . . . . . . . . . . . . . . . 91
x
LISTA DE FIGURAS xi
5-4 Objeto remoto. . . . . . . . . . . . . . . . . . . . . . . . 92
5-5 Permiso de seguridad. . . . . . . . . . . . . . . . . . . . 93
5-6 Archivo de poltica de seguridad. . . . . . . . . . . . . . 93
5-7 Lanzamiento de rmiregristry. . . . . . . . . . . . . . . . . 94
5-8 Indicacin de la ubicacin del cdigo base. . . . . . . . . 94
5-9 Gestor de seguridad. . . . . . . . . . . . . . . . . . . . . 95
5-10 Instancia y registra un objeto en el servidor rmi. . . . . . 95
5-11 Solicitud de objeto remoto. . . . . . . . . . . . . . . . . . 96
5-12 Llamado a un mtodo. . . . . . . . . . . . . . . . . . . . 96
5-13 Creacin del socket servidor. . . . . . . . . . . . . . . . . 97
5-14 El servidor activa la atencin a un cliente. . . . . . . . . 98
5-15 Lectura y envo de datos. . . . . . . . . . . . . . . . . . 98
5-16 Objetos para recibir datos (enteros, otantes, strings). . 99
5-17 Objetos para recibir o enviar clases. . . . . . . . . . . . . 99
5-18 Implementa interface Serializable. . . . . . . . . . . . . . 100
5-19 Implementa interface Serializable. . . . . . . . . . . . . . 101
5-20 Dene mtodos privados. . . . . . . . . . . . . . . . . . . 101
5-21 Mtodo WriteObjet. . . . . . . . . . . . . . . . . . . . . 102
5-22 Lectura de objetos por socket. . . . . . . . . . . . . . . . 102
5-23 Cierre de una conexin cliente y servidor. . . . . . . . . . 102
5-24 Creacin de una conexin cliente. . . . . . . . . . . . . . 103
6-1 Presupuesto de servidor. . . . . . . . . . . . . . . . . . . 111
6-2 Costo de la comunicacin. . . . . . . . . . . . . . . . . . 114
6-3 Arquitectura utilizada para el sistema experto. . . . . . . 115
6-4 Estructura del almacenamiento de las reglas. . . . . . . . 117
6-5 Archivo de reglas. . . . . . . . . . . . . . . . . . . . . . . 118
6-6 Algoritmo del motor de inferencia de YOSUKO V.1.0. . . 119
6-7 Archivo de nodos. . . . . . . . . . . . . . . . . . . . . . . 120
6-8 Archivo contenedor de reglas. . . . . . . . . . . . . . . . 122
6-9 Regla 1 del ejemplo. . . . . . . . . . . . . . . . . . . . . 122
6-10 Regla 2 del ejemplo. . . . . . . . . . . . . . . . . . . . . 123
6-11 Regla 3 del ejemplo. . . . . . . . . . . . . . . . . . . . . 123
6-12 Regla 4 del ejemplo. . . . . . . . . . . . . . . . . . . . . 123
6-13 Regla 5 del ejemplo. . . . . . . . . . . . . . . . . . . . . 124
6-14 Clculo de ping modelo 1. . . . . . . . . . . . . . . . . . 126
6-15 Clculo TPR segundo mtodo. . . . . . . . . . . . . . . . 129
LISTA DE FIGURAS xii
6-16 Grafo completo no dirigido. . . . . . . . . . . . . . . . . 130
7-1 Pantalla donde se registra el producto. . . . . . . . . . . 134
7-2 Esquema funcional de nodos. . . . . . . . . . . . . . . . . 139
8-1 Diagrama de interaccin de YOSUKO con las aplicaciones
externas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
8-2 Estructura del archivo Read.dat. . . . . . . . . . . . . . 143
8-3 Archivo binario Activ.dat. . . . . . . . . . . . . . . . . . 144
8-4 Archivo binario Control.dat. . . . . . . . . . . . . . . . . 145
8-5 Archivo binario Nodos.dat. . . . . . . . . . . . . . . . . . 146
8-6 Archivo binario Proc.dat. . . . . . . . . . . . . . . . . . . 147
8-7 Ingreso al Servidor MySQL. . . . . . . . . . . . . . . . . 157
8-8 Pantalla de registracin del producto. . . . . . . . . . . . 158
8-9 Pantalla de conrmacin. . . . . . . . . . . . . . . . . . . 158
8-10 Tabla Usuario de la base de datos YOSUKO. . . . . . . . 159
8-11 ABM de servidores y terminales. . . . . . . . . . . . . . . 159
8-12 Error en el segundo nivel de seguridad. . . . . . . . . . . 160
8-13 Registro del cliente en la aplicacin. . . . . . . . . . . . . 161
8-14 Registro de la actividad. . . . . . . . . . . . . . . . . . . 162
8-15 Registro de procesos. . . . . . . . . . . . . . . . . . . . . 163
8-16 Vericacin del nivel de seguridad a nivel usuario. . . . . 163
8-17 Panel sin nodos. . . . . . . . . . . . . . . . . . . . . . . . 164
8-18 Terminal de control con nodos activos. . . . . . . . . . . 165
8-19 Pantalla de aplicacin de antigua generacin (lenguaje Clip-
per 5.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8-20 Transferencia entre dos nodos. . . . . . . . . . . . . . . . 166
8-21 Archivo encriptado. . . . . . . . . . . . . . . . . . . . . . 166
8-22 Aplicacin de ventas de boletos. . . . . . . . . . . . . . . 167
8-23 Deteccin del mejor camino por parte de YOSUKO para
atender una aplicacin externa. . . . . . . . . . . . . . . 167
10-1 Contenido del CD de la tesis. . . . . . . . . . . . . . . . 176
10-2 Pantalla panel de control. . . . . . . . . . . . . . . . . . 179
10-3 Pantalla de conguracin del terminal. . . . . . . . . . . 180
10-4 Pantalla ABM de actividades. . . . . . . . . . . . . . . . 181
10-5 Pantalla de ABM de terminales. . . . . . . . . . . . . . . 181
10-6 Pantalla para ABM de procesos. . . . . . . . . . . . . . . 182
Parte I
Marco Conceptual yHerramientas Utilizadas
1
Captulo 1
Aspectos Conceptuales
Introduccin
La masicacin de las redes computacionales, y el exponencial crec-
imiento de Internet, han cambiado la forma en que los usuarios com-
parten, distribuyen y analizan la informacin.
Adems las nuevas tecnologas en comunicacin, han logrado cen-
tralizar 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 / Servi-
dor con Motores de Bases de Datos, utilizando una conectividad ODBC ,
JDBC , en una gran diversidad de redes locales o de rea amplia, inter-
actuando 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
Aspectos Conceptuales 3
que no justica la inversin de implementar dichas tecnologas.
Las mayoras de las empresas de nuestro medio, se encuentran sis-
tematizadas 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 de-
sarrollar un Sistema Experto Multiplataforma en lenguaje Java, emple-
ando 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 seguri-
dad 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.
Aspectos Conceptuales 4
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 comuni-
cacin 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.
Aspectos Conceptuales 5
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 Investi-gacin
Con esta interfaz de software las empresas obtendrn los siguientes ben-
ecios:
1. Ahorro en la reprogramacin del software.
2. Ahorro en servidores costosos.
3. Ahorro en motores de bases de datos.
4. Ahorro en costo de comunicacin.
5. Ahorro en licencias de software.
6. Ahorro en capacitacin del personal.
7. Seguridad de datos en el momento de transmitir la informacin.
Aspectos Conceptuales 6
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 ejecu-
cin 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 pormlti-
ples 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 con-
cepto 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.
Aspectos Conceptuales 7
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, infor-
macin, 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 ben-
ecios que se tienen al utilizar diversas tecnologas, tales como las rela-
cionadas con los Niveles OSI, Protocolo TCP/IP, Sistema Distribuido,
Sistema Experto Basado en Reglas, Lenguaje Java, Programacin Ori-
entada a Objetos y Programacin RMI.
Captulo 2
Protocolos de Comunicacinde Datos
Introduccin
Desde tiempos muy remotos los seres humanos han desarrollado y asimi-
lado un lenguaje de comunicacin, que les ha permitido entenderse, rela-
cionarse, 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 computa-
doras 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 computado-
ras comunicarse, intercambiar informacin, atender errores que puedan
producirse durante el intercambio, etc.
8
Protocolos de Comunicacin de Datos 9
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 pro-
tocolos 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.
Protocolos de Comunicacin de Datos 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 inter-
pretado. 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 re-
cepcin 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 proced-
imientos 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, Inter-
conexin 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 agrupa-
ciones 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-
Protocolos de Comunicacin de Datos 11
Figura 2-1 Modelo OSI - Estructura.
alidad totalmente llevada a la prctica por los fabricantes de hard-
ware, 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 especica-
ciones tcnicas del hardware de red (tarjetas de red, Hub, cableado,
Protocolos de Comunicacin de Datos 12
conectores, topologas, arquitectura, etc.) y la forma de trans-
misin 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 arqui-
tectura de red usada (Ethernet, ARCnet, Token Ring, ATM, etc.)
y de las especicaciones (ODI, NDIS, etc.) que permiten:
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 especi-
caciones 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.
Protocolos de Comunicacin de Datos 13
La ventaja de usar paquetes, en vez de, por ejemplo, enviar un
archivo completo, es que si ste llega defectuoso, habra que man-
darlo 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 ocu-
paran la red por un cierto tiempo, impidiendo que otras computa-
doras puedan tambin enviar sus archivos. Como consecuencia, la
red se volvera muy impredecible respecto del tiempo de transferen-
cia. 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 mo-
mento 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 especi-
caciones tcnicas que permiten a dos computadoras abrir, estable-
cer 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 especica-
ciones 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.
Protocolos de Comunicacin de Datos 14
Protocolo TCP/IP
Introduccin
Sobre la base del modelo de referenciaOSI 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 patroci-
nado 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 imposibil-
itaba 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 en-
caminados por la mejor ruta alternativa, lo que haca que muchas veces
llegaran a su destino nal desordenados y por diferentes caminos. Gra-
cias 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
Protocolos de Comunicacin de Datos 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 proto-
colo 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 per-
mite 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 de-
teriorado 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
Protocolos de Comunicacin de Datos 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 paque-
tes 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 reen-
viados.
Funciones de IP
Las funciones son las siguientes:
Elegir el camino correcto (rutear) de los paquetes de datos que vi-
ajan mediante la red pasando a travs de los diferentes ruteadores
para llegar a la computadora destino. Los ruteadores son dispos-
itivos 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.
Protocolos de Comunicacin de Datos 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, divi-
dida 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 parmet-
ros 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.
Protocolos de Comunicacin de Datos 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 com-
binaciones 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. To-
dos los fragmentos de un datagrama contienen el mismo identicador (el
identicador se asigna aleatoriamente).
Protocolos de Comunicacin de Datos 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 frag-
mentos, 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 er-
rores 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 data-
grama 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
Protocolos de Comunicacin de Datos 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 interme-
dios). Un gateway es un sistema que conecta a una red con una o ms
redes, generalmente son computadoras normales con ms de una inter-
face de red. En muchos casos, gateways de propsitos especiales proveen
mejor performance y conabilidad que los gateways de propsitos gen-
erales.
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 directa-
mente 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 gate-
ways en la red.
Protocolos de Comunicacin de Datos 21
Existe la posibilidad de que un gateway mande un mensaje especi-
cando 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: Sub-redes 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 direc-
cin 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.
Protocolos de Comunicacin de Datos 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 situa-
ciones 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 individ-
ualmente 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.
Protocolos de Comunicacin de Datos 23
Fragmentacin y Reensamblado delDatagrama
TCP/IP est diseado para usarse para diferentes clases de redes. De-
safortunadamente los diseadores de redes no se ponen de acuerdo acerca
del tamao optimo del paquete a ser enviado. Ethernet puede usar pa-
quetes de 1500 octetos de longitud, mientras que los paquetes de Arpanet
tienen un mximo de alrededor de 1000 octetos. Hay redes de gran ve-
locidad 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 di-
recciones 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.
Protocolos de Comunicacin de Datos 24
Ahora se supone que el host no encuentra la direccin Ethernet asoci-
ada 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 re-
spuesta 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-
Protocolos de Comunicacin de Datos 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 proced-
imiento. 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 infor-
macin 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.
Protocolos de Comunicacin de Datos 26
Protocolos que Trabajan Junto conTCP/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 ejecu-
tar 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 Infor-
mation Server (es un servidor web y FTP). Puede ser instalado en el
sistema operativoWindows NT 4.0, Windows 2000 o Windows XP (Pro-
fesional).
FTP (protocolo de transferencia de archivos): Permite a una com-
putadora 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-
Protocolos de Comunicacin de Datos 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 servi-
dor 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 admin-
istrar 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 comu-
nicacin 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 progra-
mas 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-
Protocolos de Comunicacin de Datos 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 re-
mitente) 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 inter-
conectados. 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
Sistema Distribuidos 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 AplicacionesDistribuidas
Una aplicacin distribuida es una aplicacin cuyo procesamiento se dis-
tribuye 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 sis-
temas 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 consti-
tuyen ejemplos del componente de interfaz de usuario de las aplicaciones
distribuidas.
La capa de procesamiento de la informacin la implementa la apli-
cacin cliente, una aplicacin servidor o una aplicacin con soporte de
servidor. Por ejemplo, una aplicacin puede utilizar un cliente de bases
Sistema Distribuidos 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 servi-
dor 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 servi-
dores 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 Inter-net
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 apli-
caciones de primera generacin admiten la comunicacin cliente / servi-
dor 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 computa-
doras 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 re-
spuesta 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
Sistema Distribuidos 32
Servidor De aplicacin
cliente
ServidorBlack-end
ServidorBlack-end
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 em-
presa, 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
Sistema Distribuidos 33
Aplicacin Financiera
Objeto deBsqueda
Objeto deDistribucin de Informacin
Objetos de Normas Comerciales
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
Sistema Distribuidos 34
otros protocolos de red.
Un socket [24, Stevens-90] es un punto nal de comunicacin, iden-
ticado 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.
Sistema Distribuidos 35
RPC - Llamadas a ProcedimientosRemotos
Se hamencionado que las aplicaciones distribuidas se implementan tpica-
mente 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 es-
perado. 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 en-
teros, 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 proced-
imientos. Siguiendo el ejemplo anterior, el servidor puede especicarse
como una funcin denida de la siguiente manera:
int validate (in char* login, in char *password).
Sistema Distribuidos 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 in-
voca mediante procedimientos, tal como si fuera una librera del sistema.
Figura 3-5 Filosofa del RPC.
Sistema Distribuidos 37
Diferentes Enfoques Para la Contruc-cin 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 tec-
nologas 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
Sistema Distribuidos 38
celda y controlar el acceso a los recursos que estn disponibles den-
tro 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 servi-
cios se usan como alternativa a la construccin de las aplicaciones
distribuidas.
El Modelo de Objeto Componente Distribuido
ElModelo de Objeto Componente Distribuido, oDCOM, es el planteamiento
de Microsoft al desarrollo de sistemas distribuidos.
El DCOM se basa en el COM, que constituye el ncleo de la estrate-
gia de desarrollo orientado a objetos de Microsoft. Dado que el DCOM
es esencialmente una extensin del sistema distribuido del COM, la com-
prensin 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 uti-
lizaba en versiones antiguas de Windows para admitir documentos com-
puestos, o documentos que son el producto de aplicaciones mltiples.)
Sistema Distribuidos 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 in-
terfaz 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 in-
terfaces 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
Sistema Distribuidos 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 mlti-
ples. 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.
Sistema Distribuidos 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 nor-
mas 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 exi-
ble 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-
Sistema Distribuidos 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 So-licitud de Objetos Comunes (CORBA)
La Arquitectura de Intermediacin de Solicitud de Objetos Comunes o
CORBA ofrece otra aproximacin, a la construccin de sistemas dis-
tribuidos. 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 Inter-
mediarios 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 adap-
tador 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.
Sistema Distribuidos 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:
Sistema Distribuidos 44
Proporciona un verdadero enfoque orientado a objetos para el de-
sarrollo de apl
Top Related