tesis de trafico

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


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.


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.


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.


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.


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-


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,


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.


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.


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


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


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


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.


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


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


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.


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.


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.


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.


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-


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


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-


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


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


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


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


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.


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


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.


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


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


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


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.


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-


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.


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:


Proporciona un verdadero enfoque orientado a objetos para el de-

sarrollo de apl

tesis de trafico

Documents