maestría en informática y...

Maestría en Informática yComputación

Universidad Nacional de Misiones

TESIS DE MAESTRÍA

SISTEMA INTELIGENTE PARA SOLUCIONARPROBLEMAS DE TRÁFICO EN REDES ANIVEL DE LA CAPA DE APLICACIÓN

Presentada por:Estigarribia Oscar Alberto

para la obtención del título deMagister en Informática y Computación

Dirigida por elMgter. David Luis la Red Martínez

Tema de Estudio y Director de tesis aprobados por el Consejo Académico

de la Maestría en Informática y Computación de la Facultad de Ciencias

Económicas de la Universidad Nacional de Misiones.

ii

Prefacio

El presente trabajo de Tesis de Maestría se ha realizado con el propósitode integrar diversos conocimientos adquiridos en el desarrollo de laMaestríapara resolver de manera novedosa y a bajo costo, el problema de la inte-gración de aplicaciones de legado (legacy) desarrolladas en los años 70s,que requieren intercambiar información entre diferentes equipos conecta-dos mediante Internet, utilizando un gestor de tráfico de requerimientosy respuestas a nivel de capa de aplicación.

El mencionado gestor de tráfico, llamado protocolo YOSUKO, fuedesarrollado utilizando el lenguaje multiplataforma Java y gran parte desus posibilidades de gestión de tráfico y de seguridad.

Contenido

Esta Tesis está dividida en tres partes claramente definidas:

Parte I: Marco Conceptual y Herramientas Utilizadas

Esta parte está integrada por los primeros cinco capítulos.

Se comienza con un capítulo dedicado a los objetivos del trabajo, lashipótesis de partida, la justificación del proyecto planteado y algunosaspectos del marco conceptual empleado.

Se continúa luego con un capítulo dedicado a los protocolos de comu-nicaciones de datos, en especial el TCP/IP.

El tercer capítulo trata de los sistemas distribuidos, revisándose ráp-idamente aspectos relacionados con sockets, RPC, CORBA, RMI, etc.

En el siguiente capítulo se presenta una reseña acerca de los princi-pales aspectos referidos a los sistemas expertos, empleados en el desarrollode la tesis.

iii

Se continúa con una revisión de los aspectos más sobresalientes de laprogramación orientada a objetos y del lenguaje Java, especialmente losaspectos utilizados en el desarrollo de la tesis, tales como los relativos alos sockets.

Parte II: Desarrollos Efectuados y Conclusiones

Se inicia esta parte con un capítulo dedicado a los principales aspectosdel desarrollo del producto de software.

Se prosigue con un capítulo dedicado a diferentes aspectos de seguri-dad considerados en el producto desarrollado.

Seguidamente se describe la interacción del software desarrollado conotras aplicaciones preexistentes para lograr procesamiento destribuido,con gestión de tráfico inteligente desde la aplicación desarrollada, todoello a través de Internet.

Finalmente se presentan las conclusiones y posibles trabajos futuros.

Parte III: Anexo

En esta parte se describen los objetos más importantes del productodesarrollado, como así también el Manual del Usuario de dicho producto.

iv

Agradecimientos

Haber llegado a las instancias de presentar esta Tesis de Maestría esel mérito de muchas personas que han sido los mentores, impulsores ymi apoyo para seguir adelante hasta esta meta, a quienes les debo miagradecimiento.

Ante todo quiero expresar la más profunda gratitud a mi familia porel apoyo, la paciencia, la comprensión y tolerancia durante el tiempode desarrollo de la Maestría, y muy especialmente a mi madre, quienfrecuentemente me decía “hijo, te pueden sacar todas tur pertenencias,pero nunca lo que está en tu mente”..

En particular, a dos de mis profesores y guías. En primer lugar,al Prof. Mgr. David la Red Martínez, quien fuera mi docente cuandocursaba mis estudios universitarios, y posteriormente en este postgrado,donde además ha sido un director de tesis ejemplar. En segundo lugar,mi agradecimiento es para el Prof. Dr. Enrique Castillo Ron, quienen una demostración de altruísmo y condiciones académicas y humanassuperiores, nos ha permitido lograr este crecimiento.

A las autoridades de la Universidad Nacional de Misiones, y de laFacultad de Ciencias Económicas. En particular al Decano Mgr. AldoMontini, por su permanente apoyo a la Maestría en Informática y Com-putación en la Facultad de Ciencias Económicas de la UNaM.

A todos los docentes de la Maestría, tanto argentinos como españoles,por su esfuerzo y dedicación.

A mis colegas y compañeros de facultad y de maestría, con quienes hecompartido esta importante experiencia, en especial a Carlos Brys, Myr-iam Kurtz y Marcelo Marinelli, por el permanente aliento para concluirla tarea emprendida.

Oscar Alberto Estigarribia

Maestría en Informática y ComputaciónFacultad de Ciencias EconómicasUniversidad Nacional de Misiones

Posadas-Misiones, Argentina, Febrero de 2006.

Tabla de Contenidos

Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiContenido . . . . . . . . . . . . . . . . . . . . . . . . . . iiAgradecimientos . . . . . . . . . . . . . . . . . . . . . . . iv

I Marco Conceptual y Herramientas Utilizadas 1

1 Aspectos Conceptuales 2

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . 3

Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . 4

Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Justificación del Estudio . . . . . . . . . . . . . . . . . . . . . 5Definición del Impacto de la Investigación . . . . . . . . . . . 5Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . 6

Reseña Sobre Modelos de Diseños de Programas . . . . . 6

2 Protocolos de Comunicación de Datos 8

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Niveles o Capas del Modelo OSI . . . . . . . . . . . . . . . . . 10Protocolo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . 14

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 14Funciones TCP/IP . . . . . . . . . . . . . . . . . . . . . 16Definición del Nivel IP . . . . . . . . . . . . . . . . . . . 17Estructura del Datagrama . . . . . . . . . . . . . . . . . 18

Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Detalles de Direccionamiento: Subredes y Broadcasting . . . . 21Fragmentación y Reensamblado del Datagrama . . . . . . . . 23

v

TABLA DE CONTENIDOS vi

ARP: Address Resolution Protocol . . . . . . . . . . . . . . . 23Sistema de Dominios . . . . . . . . . . . . . . . . . . . . . . . 24Protocolos que Trabajan Junto con TCP/lP . . . . . . . . . . 26

Protocolos Usados en el Nivel OSI de Aplicación, Pre-sentación y Sesión . . . . . . . . . . . . . . . . . . 26

Métodos de Comunicación . . . . . . . . . . . . . . . . . . . . 27

3 Sistema Distribuidos 29

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Enfoques al Diseño de Aplicaciones Distribuidas . . . . . . . . 30Aplicaciones Distribuidas en Internet . . . . . . . . . . . . . . 31Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32RPC - Llamadas a Procedimientos Remotos . . . . . . . . . . 35Diferentes Enfoques Para la Contrucción de Aplicaciones Dis-

tribuida . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Entorno de Computación Distribuida . . . . . . . . . . . 37El Modelo de Objeto Componente Distribuido . . . . . . 38

Arquitectura de Intermediación de Solicitud de Objetos Co-munes (CORBA) . . . . . . . . . . . . . . . . . . . . . . 42

Invocación Remota de Métodos de Java . . . . . . . . . . . . . 44El Modelo de Objeto Distribuido de Java . . . . . . . . . . . . 45Las Tres Capas de la RMI de Java . . . . . . . . . . . . . . . 46Pasar Argumentos y Valores de Retorno . . . . . . . . . . . . 49Los Objetos y la Invocación Remota de Métodos . . . . . . . . 50Seguridad de la Aplicación Distribuida . . . . . . . . . . . . . 51Seguridad en el Transporte . . . . . . . . . . . . . . . . . . . . 52Autenticación y Control de Acceso . . . . . . . . . . . . . . . 52

4 Sistemas Expertos 57

Definición de Sistema Experto . . . . . . . . . . . . . . . . . . 57Aspectos Fundamentales de los Sistemas Expertos . . . . . . . 58

Componentes de un Sistema Experto . . . . . . . . . . . 58Tipos de Conocimiento . . . . . . . . . . . . . . . . . . . 59Fuentes de Conocimiento . . . . . . . . . . . . . . . . . . 60

Definición del Conocimiento . . . . . . . . . . . . . . . . 60Clasificación de los Sistemas Expertos . . . . . . . . . . . 61Sistemas Expertos Basados en Reglas . . . . . . . . . . . 62

TABLA DE CONTENIDOS vii

El Motor de Inferencia . . . . . . . . . . . . . . . . . . . 62

Modus Ponens y Modus Tollens . . . . . . . . . . . . . . 64Resolución . . . . . . . . . . . . . . . . . . . . . . . . . . 65Encadenamiento de Reglas . . . . . . . . . . . . . . . . . 66Encadenamiento de Reglas Orientada a un Objetivo . . . 67Compilación de Reglas . . . . . . . . . . . . . . . . . . . 67Control de la Coherencia . . . . . . . . . . . . . . . . . . 67Metodología de Weiss y Kulikowski . . . . . . . . . . . . 68Base de Conocimiento . . . . . . . . . . . . . . . . . . . 69

Modelado de la Base de Conocimiento . . . . . . . . . . 69

Definiciones y Conceptos Sobre Grafos . . . . . . . . . . . . . 73

5 Programación Orientada a Objetos 77

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Clases y Objetos . . . . . . . . . . . . . . . . . . . . . . 79Propiedades de un Lenguaje Orientado a Objetos . . . . . . . 80

Encapsulamiento . . . . . . . . . . . . . . . . . . . . . . 81Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . 85

Lenguaje Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Características Destacables del Lenguaje Java . . . . . . 86Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Pasos Para Crear un Servidor . . . . . . . . . . . . . . . 96Crear el Socket Servidor . . . . . . . . . . . . . . . . . . 97Aceptar un Cliente . . . . . . . . . . . . . . . . . . . . . 97Obtener el InputStream y / o OutputStream . . . . . . . 98Crear unos InputStream y / o OutputStream Más Ade-

cuados a las Necesidades . . . . . . . . . . . . . . 98Leer y Escribir Datos Del y Al Cliente . . . . . . . . . . 99Cerrar el Socket . . . . . . . . . . . . . . . . . . . . . . . 102Pasos Para Crear un Cliente . . . . . . . . . . . . . . . . 102

II Desarrollos Efectuados y Conclusiones 104

6 Desarrollo del Producto 105

TABLA DE CONTENIDOS viii

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Objetivos del Prototipo . . . . . . . . . . . . . . . . . . . . . 106Estudio Comparativo de Ambas Versiones del Prototipo . . . 106Protocolo YOSUKO V. 2.0. . . . . . . . . . . . . . . . . . . . 107

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 107Planteo del Problema . . . . . . . . . . . . . . . . . . . . 108Estudio de Factibilidad para Brindar una Solución al Prob-

lema . . . . . . . . . . . . . . . . . . . . . . . . . 108Conclusión del Estudio de Factibilidad . . . . . . . . . . 109Desarrollo de la Experiencia . . . . . . . . . . . . . . . . 110Arquitectura Utilizada para Desarrollar el Protocolo . . . 115Base de Conocimiento Yosuko V 1.0. . . . . . . . . . . . 115

Almacenamiento de las Reglas . . . . . . . . . . . . . . . 117Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7 Seguridad a Nivel de Información 132

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Seguridad Nivel de Aplicación . . . . . . . . . . . . . . . 133

Seguridad Cuando se Transmite la Información . . . . . 135Seguridad Nivel Usuarios . . . . . . . . . . . . . . . . . . 137

Diagrama en Bloque del Sistema . . . . . . . . . . . . . . . . 138

8 Metodología de Integración de YOSUKO V.2.0 y Aplica-

ciones Informáticas 140

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140El Protocolo YOSUKO V. 2.0 y las Aplicaciones Externas . . 141Descripción Operativa del Sistema de Integración . . . . . . . 146

Algoritmo del Sistema Integración . . . . . . . . . . . . . . . . 152Prueba de la Implementación Efectuada . . . . . . . . . . . . 157

Prueba de Transmisión de Paquetes . . . . . . . . . . . . . . . 160Prueba con Aplicación 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 ObjetosMás Importantes del Protocolo YOSUKOV. 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Manual del Usuario de YOSUKO V. 2.0 . . . . . . . . . . . . 176Pasos Para la Instalación Modo Servidor . . . . . . . . . 176Pasos Para la Instalación Modo Cliente . . . . . . . . . . 177Panel de Control . . . . . . . . . . . . . . . . . . . . . . 178Configuración . . . . . . . . . . . . . . . . . . . . . . . . 178ABM de Actividades . . . . . . . . . . . . . . . . . . . . 179ABM de Terminales (Modo Servidor) . . . . . . . . . . . 179ABM de Procesos . . . . . . . . . . . . . . . . . . . . . . 180

Bibliografía 183

Índice Alfabético 186

Lista de Figuras

2-1 Modelo OSI - Estructura. . . . . . . . . . . . . . . . . . 112-2 Diferencia entre Modelo OSI y TCP/IP. . . . . . . . . . 152-3 Estructura del Datagrama. . . . . . . . . . . . . . . . . . 18

3-1 La organización de sistema distribuido. . . . . . . . . . . 303-2 Estructura del servidor. . . . . . . . . . . . . . . . . . . . 323-3 Ejemplo de aplicación distribuida. . . . . . . . . . . . . . 333-4 Utilización de sockets. . . . . . . . . . . . . . . . . . . . 343-5 Filosofía del RPC. . . . . . . . . . . . . . . . . . . . . . 363-6 COM y DCOM. . . . . . . . . . . . . . . . . . . . . . . . 543-7 Cómo funciona CORBA. . . . . . . . . . . . . . . . . . . 553-8 RMI de Java. . . . . . . . . . . . . . . . . . . . . . . . . 553-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. . . . . . . . . . . . . . . . . 614-3 Regla modus ponens. . . . . . . . . . . . . . . . . . . . . 654-4 Regla modus tollens. . . . . . . . . . . . . . . . . . . . . 664-5 Proceso de búsqueda en la base de conocimiento. . . . . 704-6 Diceño de la regla mediante UML. . . . . . . . . . . . . . 704-7 Etapas en el desarrollo de un SE. . . . . . . . . . . . . . 724-8 Tipos de grafos. . . . . . . . . . . . . . . . . . . . . . . . 744-9 Notación de grafos. . . . . . . . . . . . . . . . . . . . . . 744-10 Grafo completo. . . . . . . . . . . . . . . . . . . . . . . . 75

5-1 Terminología de objetos. . . . . . . . . . . . . . . . . . . 795-2 Reutilización de objeto. . . . . . . . . . . . . . . . . . . . 845-3 Interface para RMI. . . . . . . . . . . . . . . . . . . . . . 91

x

LISTA DE FIGURAS xi

5-4 Objeto remoto. . . . . . . . . . . . . . . . . . . . . . . . 925-5 Permiso de seguridad. . . . . . . . . . . . . . . . . . . . 935-6 Archivo de política de seguridad. . . . . . . . . . . . . . 935-7 Lanzamiento de rmiregristry. . . . . . . . . . . . . . . . . 945-8 Indicación de la ubicación del código base. . . . . . . . . 945-9 Gestor de seguridad. . . . . . . . . . . . . . . . . . . . . 955-10 Instancia y registra un objeto en el servidor rmi. . . . . . 955-11 Solicitud de objeto remoto. . . . . . . . . . . . . . . . . . 965-12 Llamado a un método. . . . . . . . . . . . . . . . . . . . 965-13 Creación del socket servidor. . . . . . . . . . . . . . . . . 975-14 El servidor activa la atención a un cliente. . . . . . . . . 985-15 Lectura y envío de datos. . . . . . . . . . . . . . . . . . 985-16 Objetos para recibir datos (enteros, flotantes, strings). . 995-17 Objetos para recibir o enviar clases. . . . . . . . . . . . . 995-18 Implementa interface Serializable. . . . . . . . . . . . . . 1005-19 Implementa interface Serializable. . . . . . . . . . . . . . 1015-20 Define métodos privados. . . . . . . . . . . . . . . . . . . 1015-21 Método WriteObjet. . . . . . . . . . . . . . . . . . . . . 1025-22 Lectura de objetos por socket. . . . . . . . . . . . . . . . 1025-23 Cierre de una conexión cliente y servidor. . . . . . . . . . 1025-24 Creación de una conexión cliente. . . . . . . . . . . . . . 103

6-1 Presupuesto de servidor. . . . . . . . . . . . . . . . . . . 1116-2 Costo de la comunicación. . . . . . . . . . . . . . . . . . 1146-3 Arquitectura utilizada para el sistema experto. . . . . . . 1156-4 Estructura del almacenamiento de las reglas. . . . . . . . 1176-5 Archivo de reglas. . . . . . . . . . . . . . . . . . . . . . . 1186-6 Algoritmo del motor de inferencia de YOSUKO V.1.0. . . 1196-7 Archivo de nodos. . . . . . . . . . . . . . . . . . . . . . . 1206-8 Archivo contenedor de reglas. . . . . . . . . . . . . . . . 1226-9 Regla 1 del ejemplo. . . . . . . . . . . . . . . . . . . . . 1226-10 Regla 2 del ejemplo. . . . . . . . . . . . . . . . . . . . . 1236-11 Regla 3 del ejemplo. . . . . . . . . . . . . . . . . . . . . 1236-12 Regla 4 del ejemplo. . . . . . . . . . . . . . . . . . . . . 1236-13 Regla 5 del ejemplo. . . . . . . . . . . . . . . . . . . . . 1246-14 Cálculo de ping modelo 1. . . . . . . . . . . . . . . . . . 1266-15 Cálculo TPR segundo método. . . . . . . . . . . . . . . . 129

LISTA DE FIGURAS xii

6-16 Grafo completo no dirigido. . . . . . . . . . . . . . . . . 130

7-1 Pantalla donde se registra el producto. . . . . . . . . . . 1347-2 Esquema funcional de nodos. . . . . . . . . . . . . . . . . 139

8-1 Diagrama de interacción de YOSUKO con las aplicacionesexternas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8-2 Estructura del archivo Read.dat. . . . . . . . . . . . . . 1438-3 Archivo binario Activ.dat. . . . . . . . . . . . . . . . . . 1448-4 Archivo binario Control.dat. . . . . . . . . . . . . . . . . 1458-5 Archivo binario Nodos.dat. . . . . . . . . . . . . . . . . . 1468-6 Archivo binario Proc.dat. . . . . . . . . . . . . . . . . . . 1478-7 Ingreso al Servidor MySQL. . . . . . . . . . . . . . . . . 1578-8 Pantalla de registración del producto. . . . . . . . . . . . 1588-9 Pantalla de confirmación. . . . . . . . . . . . . . . . . . . 1588-10 Tabla Usuario de la base de datos YOSUKO. . . . . . . . 1598-11 ABM de servidores y terminales. . . . . . . . . . . . . . . 1598-12 Error en el segundo nivel de seguridad. . . . . . . . . . . 1608-13 Registro del cliente en la aplicación. . . . . . . . . . . . . 1618-14 Registro de la actividad. . . . . . . . . . . . . . . . . . . 1628-15 Registro de procesos. . . . . . . . . . . . . . . . . . . . . 1638-16 Verificación del nivel de seguridad a nivel usuario. . . . . 1638-17 Panel sin nodos. . . . . . . . . . . . . . . . . . . . . . . . 1648-18 Terminal de control con nodos activos. . . . . . . . . . . 1658-19 Pantalla de aplicación de antigua generación (lenguaje Clip-

per 5.2). . . . . . . . . . . . . . . . . . . . . . . . . . . . 1658-20 Transferencia entre dos nodos. . . . . . . . . . . . . . . . 1668-21 Archivo encriptado. . . . . . . . . . . . . . . . . . . . . . 1668-22 Aplicación de ventas de boletos. . . . . . . . . . . . . . . 1678-23 Detección del mejor camino por parte de YOSUKO para

atender una aplicación externa. . . . . . . . . . . . . . . 167

10-1 Contenido del CD de la tesis. . . . . . . . . . . . . . . . 17610-2 Pantalla panel de control. . . . . . . . . . . . . . . . . . 17910-3 Pantalla de configuración del terminal. . . . . . . . . . . 18010-4 Pantalla ABM de actividades. . . . . . . . . . . . . . . . 18110-5 Pantalla de ABM de terminales. . . . . . . . . . . . . . . 18110-6 Pantalla para ABM de procesos. . . . . . . . . . . . . . . 182

Parte I

Marco Conceptual yHerramientas Utilizadas

1

Capítulo 1

Aspectos Conceptuales

Introducción

La masificación 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 información.

Además las nuevas tecnologías en comunicación, han logrado cen-tralizar o distribuir la información en tiempo real, brindando grandesbeneficios a las empresas o al ser humano que utiliza estas herramientaspara la toma de decisiones.

Muchos sistemas actualmente poseen la Tecnología 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 significa un granbeneficio 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 justifica la inversión de implementar dichas tecnologías.

Las mayorías de las empresas de nuestro medio, se encuentran sis-tematizadas con lenguaje de programación que no tienen la capacidadde utilizar las tecnologías actuales, trayendo consecuencias drásticas anivel costo y organización, debido a que tienen que volver a programarlos sistemas existentes, comprar nuevos equipamientos (servidor, router,rack, etc.), licencias de software, capacitación al personal, etc.

Además hay empresas que debido a su actividad, necesitan tener lainformación en tiempo real. Ej.: empresas de transporte de pasajeros quese informatizan, utilizando las técnicas Cliente / Servidor, centralizandola información en un solo servidor, pero existe el inconveniente con lospuntos de ventas remotos, donde no se puede utilizar comunicación debajo costo (ADSL). Debido a que un corte de comunicación representagran perdida de dinero, se ven obligado a contratar proveedores, quegaranticen la comunicación punto a punto, ej.: Telecom, Telefónica.

Objetivo General

Teniendo en cuenta los inconveniente antes mencionados, se propuso de-sarrollar un Sistema Experto Multiplataforma en lenguaje Java, emple-ando comunicación de bajo costo, permitiendo gestionar tráfico entreservidores remotos, teniendo en cuenta como métrica la del camino másrápido, detectado mediante sondeo en tiempo real, e integrando softwaredesarrollado en la década de los 70s, con tecnología Clientes Servidor,Motor de Bases de Datos, e interconexión a Internet, y brindando seguri-dad a la información transmitida.

Para evaluar el sistema se realizarían pruebas con la interfaz, y lasnuevas tecnologías, demostrando la efectividad en costo y velocidad.


Objetivos Específicos

Diseñar y desarrollar un Sistema Experto basado en reglas (en lenguajeJava), con el fin de lograr los siguientes objetivos:

1. Gestionar el tráfico entre servidores remotos, utilizando comuni-cación de bajo costo, detectando el mejor camino según el criterioya mencionado.

2. Interactuar con los diferentes Motores de Bases de datos o sistemasde archivos de los distintos servidores mediante comandos de SQL.

3. Integrar aplicaciones, desarrollada en la década de los 70s, a travésde un contenedor de pedidos; estas aplicaciones se podrán ejecutaren forma local o remota.

4. Utilizar algoritmos de seguridad para dar protección a los datosrecibidos o enviados por el contenedor de pedidos.

5. Diseñar pruebas que permitan evaluar la efectividad del software.

Hipótesis

Es posible desarrollar un Sistema Experto para gestión de tráfico, a nivel,de capa de aplicación, capaz de integrar software confeccionado en ladécada de los 70s, con tecnología Cliente / Servidor, Motor de Bases deDatos, interconectado con varios servidores, proveyendo seguridad a lainformación transmitida.


Justificación del Estudio

Ante el avance de las exigencias de los negocios, es una necesidad paramuchas empresas PYMES (que carecen de la posibilidad de utilizar lasnuevas soluciones integrales por su elevado costo), el desarrollo de unainterfaz con un Sistema Experto para gestión del tráfico entre servidoresen los que opera el software aplicativo de legado (heredado).

Definición del Impacto de la Investi-gación

Con esta interfaz de software las empresas obtendrán los siguientes ben-eficios:

1. Ahorro en la reprogramación del software.

2. Ahorro en servidores costosos.

3. Ahorro en motores de bases de datos.

4. Ahorro en costo de comunicación.

5. Ahorro en licencias de software.

6. Ahorro en capacitación del personal.

7. Seguridad de datos en el momento de transmitir la información.


Marco Conceptual

Reseña Sobre Modelos de Diseños de Programas

Actualmente existen varios modelos de diseño de programas, los que sedetallan seguidamente:

Modelo 1:

Programas de red local. Suelen ser programas de bajo costo conun tratamiento de ficheros y bloqueos dentro de una red local. Poseensistemas más o menos avanzados de generación de informes.

Modelo 2:

Son programas de modelo 1, muy planificados, para realizar ejecu-ción remota. Utilizan lenguaje SQL con tecnología ODBC o JDBC, yéstos se enlazan con bases de datos relacionales, implicando generalmenteservidores costosos y comunicación de alto costo para lograr rendimiento.Además se debe contar con una buena política de seguridad con respectoa la protección de los servidores.

Modelo 3:

Aplicaciones distribuidas, cuyos procedimientos se distribuye pormúlti-ples computadoras de una red, y que son capaces de servir a usuariosmúltiples. Se implementan como sistemas cliente / servidor, organizadosde conformidad con la interfaz de usuario [14, Jaworski-99]. También sedenominan aplicaciones RMI (Invocación Remota de Métodos).

[32, Tanenbaum-97-01] Expresa que “Un sistema distribuido es aquélal 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 diversosprocesadores deberá ser invisible (transparente) al usuario. Otra formade expresar esta misma idea es diciendo que el usuario verá al sistemacomo un uniprocesador virtual y no como una colección de máquinasdiferentes”.


Asimismo, [11, Coulouris Dollimire Kindberg -01] indican respectode un sistema distribuido que es un “Sistema en el cual componentes dehardware y software, localizados en computadores diferentes y en red, secomunican y coordinan sus acciones sólo por paso de mensajes”.

¿Por qué utilizar aplicaciones distribuida?. Existen esencialmente treslíneas de justificación:

1. Compartir recursos de una manera más natural, estos pueden serde variados tipos: capacidad de procesamiento, periféricos, infor-mación, accesibilidad, etc.

2. Distribuir la carga, los procesos pueden ser delegados según criterios(posición geográfica, capacidad de procesamiento, seguridad, etc.).

3. Optimizar su ejecución y distribución de resultados, es decir, lograrla ejecución de aplicaciones en ambientes más adecuados.

Se ha propuesto el desarrollo de un Sistema Experto con la

arquitectura del modelo 3.

Antes de tomar la decisión se han evaluado en forma sintética los ben-eficios que se tienen al utilizar diversas tecnologías, tales como las rela-cionadas con los Niveles OSI, Protocolo TCP/IP, Sistema Distribuido,Sistema Experto Basado en Reglas, Lenguaje Java, Programación Ori-entada a Objetos y Programación RMI.

Capítulo 2

Protocolos de Comunicaciónde Datos

Introducción

Desde tiempos muy remotos los seres humanos han desarrollado y asimi-lado un lenguaje de comunicación, que les ha permitido entenderse, rela-cionarse, compartir conocimientos, y progresar. Del mismo modo, en unared, para establecer la comunicación entre las computadoras, se requiereun lenguaje común, el protocolo es dicho lenguaje.

Los protocolos son estándares software que se instalan en las computa-doras de una red para definir el lenguaje, las reglas, los procedimientos,y las metodología utilizadas, para que las máquinas de la red, puedanentenderse entre ellas. El uso de protocolos, permite a las computado-ras comunicarse, intercambiar información, atender errores que puedanproducirse durante el intercambio, etc.

8

Protocolos de Comunicación de Datos 9

En resumen, se podría decir que los protocolos son el lenguaje común

que utilizan las computadoras para poder comunicarse dentro de una redLAN (red de área local) o WAN (red de área extensa).

Todo protocolo deberá tener muy bien estudiado tres aspectos:

• La sincronización temporal.

• La sincronización en el orden de los campos de un paquete.

• La sincronización en el significado que se dé a los mensajes de loscampos de un paquete.

Estos tres requisitos deben ser cumplidos a la perfección por los pro-tocolos para un correcto funcionamiento de la red.

A continuación se describe cada uno de ellos:

• Sincronización temporal : Hace referencia a las reglas que debe tenerdefinidas el protocolo, para que los paquetes enviados y recibidos através de la red sean cronometrados y sincronizados en el tiempo.Por ejemplo, cada paquete enviado tiene un tiempo de vida útil,y después de que dicho tiempo expira, el paquete no es tenido encuenta y carece de validez. Esa marca de tiempo que tienen lospaquetes es útil cuando una computadora destino recibe, de otra,varias versiones de un mismo paquete.

• Sincronización en el orden de los campos de un paquete: Todopaquete de datos que viaja a través de la red está subdividido endiferentes campos. Una analogía similar a ello serían los camposque tiene el registro de un archivo de datos. Cada campo cumpleuna función específica dentro del paquete de datos; por ejemplo,hay campos para indicar la dirección de destino del paquete, ladirección de origen del paquete (remitente), la sección de datos oinformación, la longitud del paquete, el código de verificación deerror o paridad, el tiempo de vida del paquete, la identificación delpaquete, el tipo de servicio para el que será usado el paquete, laversión del protocolo.


• Sincronización en el significado de los mensajes: No sólo basta quelos campos de un paquete estén en el lugar apropiado y tengan unalongitud fija para lograr que un paquete sea correctamente inter-pretado. Además, los protocolos deben tener reglas que definanla sintaxis o el lenguaje apropiados en cada uno de los mensajesinmersos en los campos del paquete, durante la transmisión o re-cepción de los mensajes a través de la red, para así lograr unacorrecta interpretación y evitar el uso de idiomas diferentes.

Niveles o Capas del Modelo OSI

La comunicación entre las computadoras de una red requiere proced-imientos muy complejos, en los que intervienen el hardware, el softwarey los lenguajes de comunicación (también denominados protocolos).

Varias arquitecturas basadas en capas partieron del modelo OSI y apartir de éste se generaron muchas otras como TCP/IP y B-ISDN .

El modelo de referencia OSI (Open Systems Interconnection, Inter-conexión de Sistemas Abiertos) es un modelo de siete capas desarrolladopor la Organización Internacional de Normas (ISO). En la figura 2-1 dela pág. 11 se describe el modelo de capas de OSI.

Los niveles OSI se caracterizan por ser :

• Lógicos: Independientes de lo físico; independientes de las agrupa-ciones de software y hardware que existen actualmente.

• Funcionales: Cada nivel cumple una tarea específica.

• Jerárquicos: Cada nivel tiene autoridad sobre su inmediato inferiory desarrolla tareas más generales o menos especializadas que sunivel inferior.

• Ideales: Actualmente su implementación es más un modelo, unmarco de referencia, una norma, un deseo o una utopía que una re-


Figura 2-1 Modelo OSI - Estructura.

alidad totalmente llevada a la práctica por los fabricantes de hard-ware, software y protocolos de red.

El modelo de referencia OSI tiene como función:

• Facilitar el estudio de los elementos que componen las redes y losprocesos que permiten la comunicación entre ellas.

• Mejorar la compatibilidad, estandarización y reglamentación entrelos diferente fabricantes de software y hardware de red.

• Minimizar las actualizaciones provocadas por los avances y cambiosen la tecnología de software y hardware.

Funciones de cada uno de los niveles OSI:

Cada uno de los niveles OSI posee una función particular, las que sedetallan brevemente a continuación:

• Nivel l (físico): En este nivel se definen las normas y especifica-ciones técnicas del hardware de red (tarjetas de red, Hub, cableado,


conectores, topologías, arquitectura, etc.) y la forma de trans-misión de las señales eléctricas u ópticas (bits) de un ordenador aotro a través del cableado.

• Nivel 2 (enlace de datos): En este nivel se definen las normas yespecificaciones técnicas de los controladores (drivers) de la arqui-tectura de red usada (Ethernet, ARCnet, Token Ring, ATM, etc.)y de las especificaciones (ODI, NDIS, etc.) que permiten:

— Establecer una sesión de enlace de datos con igual nivel deotra computadora de la red.

— La conversión de los datagramas recibidos desde el nivel dered (nivel 3) en “tramas”; la trama es la estructura de datosusada en este nivel a través de la cual viaja la información.

— La detección y corrección de errores que se puedan presentar.

— El reenvío de tramas que no llegaron a destino.

• Nivel 3 (red): En este nivel se definen las normas y especificacionestécnicas de los protocolos de red instalados en las computadoras(por ejemplo, IPX de SPX/PX, o IP del TCP/IP), que permitenfragmentar los paquetes del nivel de transporte en data gramasy encaminarlos de una computadora a otra mediante ruteadores,hasta llegar a la computadora destino; cada ruteador (servidor quese encuentra en el medio, es decir, entre la computadora que envíael mensaje y la que lo recibe) debe elegir el camino correcto de lospaquetes que arriban a él, para que éstos se encaminen a través delos ruteadores que hay en las distintas sub redes y puedan llegar a lacomputadora destino, para ello, esos ruteadores deben actuar comoun agente de tránsito, dando prioridad a determinados paquetes yevitando las redes muy congestionadas (donde la pérdida de tiempoes muy grande) o los caminos poco seguros (donde el número lepérdidas de paquetes es muy alto).

• Nivel 4 (transporte): En este nivel se definen las normas y especi-ficaciones técnicas de los protocolos de transporte instalados en lascomputadoras (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 unarchivo completo, es que si éste llega defectuoso, habría que man-darlo todo nuevamente en vez de enviar un solo paquete, con laconsecuente pérdida de tiempo y aumento del congestionamientode tráfico. Además, si se enviara el archivo entero, los datos ocu-parían la red por un cierto tiempo, impidiendo que otras computa-doras puedan también enviar sus archivos. Como consecuencia, lared se volvería muy impredecible respecto del tiempo de transferen-cia. Además, se debe controlar el orden en que se envían o recibenlos paquetes y si los paquetes enviados llegan; de lo contrario, volvera trasmitirlos; si los paquetes enviados no llegan porque en ese mo-mento la red está muy congestionada, este nivel deberá reducir elnúmero de paquetes trasmitidos, para evitar reenvíos de paquetesque congestionan aún más la red.

• Nivel 5 (sesión): En este nivel se definen las normas y especifi-caciones técnicas que permiten a dos computadoras abrir, estable-cer y cerrar una sesión (diálogo, transmisión) entre ellas. Al abriruna sesión, ambas máquinas efectúan un reconocimiento mutuo yacuerdan detalles como la seguridad, el tamaño de los paquetes o lavelocidad de transmisión. Un vez abierta la sesión, este nivel definecuál de las dos computadoras transmite y durante cuánto tiempo.

• Nivel 6 (presentación): Aquí se definen las normas y especifica-ciones técnicas que permiten traducir, encriptar y comprimir losdatos recibidos (caracteres o gráficos) del nivel de aplicación, paraentregarlos en un lenguaje comprensible al nivel de sesión, y a lainversa. Es decir, este nivel permite procesar los datos recibidosdel nivel de sesión que vienen de otra computadora y entregarlos alnivel de aplicación en un lenguaje comprensible.

• Nivel 7 (aplicación): Su función es proporcionar servicios a losprogramas de aplicación de red (correo electrónico, transferenciade archivos, acceso a bases de datos o servicios de directorio), porejemplo, visualizar en pantalla, transferir archivos o imprimir haciaotras computadoras que se encuentren en la misma red.


Protocolo TCP/IP

Introducción

Sobre la base del modelo de referenciaOSI se desarrollaron otros modelosde red y arquitecturas completas para las redes de comunicación. Estemodelo se desarrolló a partir de un proyecto de investigación patroci-nado por el Departamento de Defensa de los Estados Unidos denominadoARPANET .

Esta red debería permanecer funcionando en caso de que algunos delos nodos de la red o incluso sus conexiones fueran dañados por algúnmotivo. La red ARPANET empezó conectando centros de investigacióndel gobierno y luego universidades hasta convertirse en la red más popularde uso público hasta el momento: Internet.

Las computadoras de Arpanet tenían la capacidad de fragmentar ungran archivos de información en pequeños paquetes de datos, para luegoenviarlos por la red. Este envío fragmentado de información imposibil-itaba que cualquier PC se adueñara de la red durante mucho tiempo.Cada paquete de datos lanzado a la red tenía una dirección de origen (dela computadora que lo enviaba) y otra de destino (de la computadoraque lo recibía).

Los paquetes enviados por una PC a la red Arpanet podían ser en-caminados por la mejor ruta alternativa, lo que hacía que muchas vecesllegaran a su destino final desordenados y por diferentes caminos. Gra-cias a que los paquetes enviados por la red eran numerados, la máquinaque se hallaba en la dirección de destino, al recibir dichos paquetes, lospodía ordenar, agrupar y reconstruir para crear el archivo original.

Si algún paquete se extraviaba, la computadora destino pedía que se lereenviara el paquete faltante. A esa habilidad conseguida en ARPANET(poder encaminar los paquetes de datos) se la conoce como conmutaciónde paquetes. Esto cumplía los objetivos buscados por el Departamentode Defensa de los Estados Unidos dado que, si durante la guerra quedabadestruido algún enlace (fibra óptica, microonda o satélite), 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 / lnternetProtocol, lo que en español significa Protocolo de Control de Transmisión/ Protocolo Internet).

TCP/IP difiere del modelo de referencia OSI en que no maneja sietecapas sino cinco (en el modelo de TCP/IP no hay capas para sesión ypresentación), según muestra la siguiente figura 2-2 de la pág. 15.

Figura 2-2 Diferencia entre Modelo OSI y TCP/IP.

Este lenguaje común que se instala en las computadoras de la red per-mite llevar a cabo la comunicación entre diferentes plataformas, sistemasoperativos, topologías y arquitecturas por el mejor camino disponible.Eso significa que, en las redes interconectadas, si existe algún camino de-teriorado o congestionado con excesivo tráfico de información, los ruteadoresTCP/IP buscan el mejor camino alternativo.

Luego del éxito y difusión que tuvo el protocolo TCP/IP, la Agenciade Investigaciones Avanzadas de Proyectos de Defensa de Estados Unidos


(DARPA) lo puso a disposición del mundo entero en forma gratuita y sinningún tipo de restricciones, y así, llegó a ser el protocolo de comunicaciónque 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 envían y reciben los paque-tes de datos durante una transmisión a través de la red, entre dosmáquinas 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 buenestado; 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 través de los diferentes ruteadorespara llegar a la computadora destino. Los ruteadores son dispos-itivos o computadoras que vinculan las redes entre sí. Su funciónes encaminar los paquetes de datos recibidos para que continúen eltrayecto hacia su destino final. Tanto las PCs que envían o recibendatos a través de la red como los ruteadores que encaminan dichospaquetes, hacen uso del protocolo IP para lograr una comunicaciónestandarizada, y así, entenderse y cumplir sus objetivos.


Definición del Nivel IP

El protocolo IP surgió para interconectar redes. El principal trabajo deIP es buscar una ruta para que los datos lleguen al destino. Con respectoal modelo OSI (7 capas) podemos ubicar a este protocolo en el tercer nivel(Capa de Red).

Una de las principales características de IP es que no esta orientadoa conexión, esto quiere decir que

para la transmisión de datos entre dos host no se construye ningúnvínculo que los conecte antes del envío de los mismos.

IP utiliza como unidad de transmisión el datagrama.

Cada host se individualiza mediante una dirección de 32 bits, divi-dida en 4 octetos. En ella se especifica un identificador de red y unidentificador de host.

Para administrar estas direcciones se definieron 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 lavida de una trama.

Para permitir a los dispositivos intermedios transmitir datagramas,éste cuenta con un encabezado en el que se especifican todos los parámet-ros de control necesarios para que el datagrama llegue a destino (direcciónorigen, dirección destino, tipo de protocolo, etc.).

Además del encabezado, el datagrama contiene la porción de datosque se está queriendo transmitir.

El encabezado tiene una parte fija de 20 octetos y una parte opcionalde longitud variable.


Estructura del Datagrama

La estructura se muestra en la figura 2-3 de la pág. 18.

Figura 2-3 Estructura del Datagrama.

Versión: Indica a qué versión del protocolo pertenece cada uno de losdatagramas. Mediante la inclusión de la versión en cada datagrama, nose excluye la posibilidad de modificar los protocolos mientras la red se

encuentra en operación.

H Len: Especifica la longitud que tiene el encabezado en palabras de32 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 elencabezado como los datos, está expresado en bytes.

Identificador del Datagrama: Se necesita para permitir al destinodeterminar a qué datagrama pertenece el fragmento recién llegado. To-dos los fragmentos de un datagrama contienen el mismo identificador (elidentificador se asigna aleatoriamente).


Bit D: Si este campo está seteado con 1 indica que el datagrama nose puede fragmentar.

Bit M : Si este bit se encuentra en 1 significa que existen más frag-mentos, todos los fragmentos excepto el último deberán tener este bitseteado en 1.

Offset: Es el desplazamiento del fragmento dentro del datagramaoriginal. Se utiliza para regenerar el datagrama original.

TTL (Time To Live): Es un contador que se utiliza para limitar eltiempo de vida de los paquetes. Cada vez que el datagrama pasa porun router el campo TTL se decrementa en 1, cuando llega a cero eldatagrama 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 encabezadoen palabras de 16 bits, las suma en complemento a 1 y al resultado loscomplementa a 1.

Direcciones Origen y Destino: Especifican las direcciones IP del hostorigen y del host destino respectivamente.

Opciones: Este campo se utiliza con fines de seguridad, informe deerrores, depuración, así como para otro tipo de información. Permitetambién incluir a versiones de protocolos subsiguientes información queno está presente en el diseño 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 cómose hace. La tarea de encontrar cómo llevar un datagrama al destino es


conocida como routing.

Es necesario conocer el modelo en que IP está basado. IP asume quecada host esta conectado a una red local, también se asume que el hostpuede enviar el datagrama dentro de la misma red. Pero el problemasurge cuando se quiere enviar un datagrama a un host que se encuentraen 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 másredes, generalmente son computadoras normales con más de una inter-face de red. En muchos casos, gateways de propósitos especiales proveenmejor performance y confiabilidad que los gateways de propósitos gen-erales.

El ruteo en IP se basa en el número de red de la dirección destino.Cada computadora tiene una tabla de números de red. Para cada númerode red se tiene un gateway que es el que se intentará alcanzar si se deseaenviar 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 teóricamente el mejor ubicado paraacceder a la red.

Cuando una computadora desea enviar un datagrama, primero chequeasi la dirección destino está en su red local, si esto ocurre el datagramapuede enviarse directamente, de otra manera el sistema espera encontraruna entrada en la tabla para la dirección destino y utiliza ese gatewaypara enviar el datagrama.

Las tablas pueden volverse muy grandes por lo cual existen técnicaspara reducir el tamaño de las mismas. Una de estas técnicas consiste endefinir un “default gateway” que es la única salida hacia fuera de la red.Este gateway debe conectar a la red local con las demás redes. En estecaso no necesitaremos tener una entrada por cada red en el mundo, sinoque simplemente tenemos un gateway como default, y si no encontramosuna ruta específica para un datagrama, éste es enviado al gateway default.

Un gateway por default se puede definir aunque existan varios gate-ways en la red.


Existe la posibilidad de que un gateway mande un mensaje especifi-cando que él no es la mejor opción e informando cual sí lo es.

La mayor parte de las interfaces de red son diseñadas para usar estetipo mensajes para agregar o modificar entradas en la tabla.

Se recomienda que los host en forma individual no traten de buscar elcamino hacia el destino final por ellos mismos, sino que dejen esta tareaa los gateways.

Para que los gateways puedan armar sus tablas de ruteo se necesitanprotocolos de ruteo.

Detalles de Direccionamiento: Sub-redes y Broadcasting

Algunas organizaciones creen conveniente dividir su número de red ensubredes, esto se realiza utilizando algunos de los bits de la dirección IPreservados para host. Para determinar a que subred pertenece una direc-ción se utiliza una máscara (se efectúa un AND lógico entre la direccióny la máscara).

Supongamos que se cuenta con una red R1 a la que le fue asignadauna dirección de Clase B 128.6; y se desea usar el tercer octeto de ladirección IP para indicar cuáles host son Ethernet dentro de la red.

Esta división no tiene sentido fuera de R1, una computadora de otrared enviará los datagramas direccionados a 128.6 de la misma manera.De esta manera las computadoras fuera de R1 no tendrán diferentes rutaspara 128.6.4 o 128.6.5. Pero dentro de la red R1, a las direcciones 128.6.4y 128.6.5 se las ve como redes separadas. En efecto los gateways dentrode la Red R1 tienen entradas separadas para cada subred, mientras quelos gateways que se encuentran afuera de R1 cuentan con una entradapara 128.6.


Dentro de las direcciones IP los números 0 y 255 tienen un significadoespecial, o son reservado para máquinas que no conocen su dirección . Enciertas circunstancias es usado por máquinas que no conocen el númerode red en la que se encuentra, aún conociendo su propio número de host,por ejemplo 0.0.0.23 es un máquina que conoce su número de host perodesconoce el número de red a la cual pertenece.

El número 255 es usado para “broadcast”. Un mensaje de broadcastes aquel que todos los host pueden leer. Este es usado en algunas situa-ciones donde se desconoce la dirección del host con el que se desea unacomunicación. Algunas veces no se conoce la dirección del “name server”más cercano, en este caso se debe enviar un Request como broadcast.

Existen casos en donde un host está interesado en enviar la mismainformación a varios host. Es más simple entonces, enviar un simplebroadcast a las máquinas en cuestión que enviar un datagrama individ-ualmente a cada host. Para enviar este tipo de broadcast se debe usar unadirección que está construida usando el número de red seguido de unos enla parte de la dirección que corresponda al número de host (por ejemplosi la máquina se encuentra sobre la red 128.6.4 deberá usar 128.6.5.255como broadcast).

La implementación de broadcast depende del medio físico, en muchoscasos no es posible usarlo, sin embargo sí es posible sobre Ethernet.

Debido a que 0 y 255 son usados para direcciones desconocidas yde broadcast respectivamente, un host nunca debe tener asignado comodirección ni la 0 y ni la 255.

Las direcciones nunca deben comenzar con 0 o 127.


Fragmentación y Reensamblado delDatagrama

TCP/IP está diseñado para usarse para diferentes clases de redes. De-safortunadamente los diseñadores de redes no se ponen de acuerdo acercadel tamaño optimo del paquete a ser enviado. Ethernet puede usar pa-quetes de 1500 octetos de longitud, mientras que los paquetes de Arpanettienen un máximo de alrededor de 1000 octetos. Hay redes de gran ve-locidad que pueden usar paquetes de mayor longitud. En principio sepuede pensar que IP utiliza el paquete más pequeño, pero esto causaserios problemas de performance; cuando se transfiere archivos grandes,los grandes paquetes son más eficientes que los chicos. Por lo tanto loque es deseable es usar el tamaño más largo posible.

Se supone que se cuenta con dos host en diferentes redes Ethernet(capaces de transmitir paquetes de 1500 octetos) conectadas a través deuna red que las vincula pero que transmite paquetes de 200 octetos. Lamáquina origen transmite un datagrama de 1500 octetos. Cuando éstepaquete llega al link de 200 octetos debe ser fragmentado a este númeropara poder llegar a la red destino y ser reensamblado en el host destino.A este proceso se lo llama fragmentación 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á elfuncionamiento de este protocolo mediante un ejemplo:

Se supone que se tiene un Host 128.6.4.194 (A) que se quiere conectarcon el Host 128.6.4.7 (B). Verificamos primero que B se encuentre sobrela misma red, entonces se examina la tabla de ARP local para verificarque existe la dirección Ethernet asociada a la dirección IP en cuestión,si es así se envía el datagrama.


Ahora se supone que el host no encuentra la dirección Ethernet asoci-ada en la tabla de ARP local, entonces se utiliza el protocolo ARP paraenviar un Request. Todos los Host escuchan el ARP Request. Cuandoun host interpreta que el ARP Request es para él, responde. Esta re-spuesta se hace mediante un ARP Reply informando al que originó elrequest la dirección Ethernet del que responde. El host origen salvarála información en la tabla de ARP local para enviar futuros paquetesdirectamente.

La mayoría de los host tratan a las tablas de ARP como una caché ylimpian periódicamente las entradas que no son usadas.

Se debe notar que la forma de enviar en ARP Request es por mediode un paquete de “broadcast”. Los ARP request no se pueden enviardirectamente a un Host determinado. Muchos host utilizan los ARPRequest que le arriban para actualizar su propia tabla ARP.

Sistema de Dominios

Generalmente, el software de red utiliza direcciones IP de 32 bits paraenviar datagramas, sin embargo los usuarios prefieren utilizar nombresen lugar de números. De esta manera se podría contar con una basede datos que permita asociar nombres a direcciones IP, esto implicaríatener una tabla con las direcciones-nombres del resto de los Host. Estasolución es simple si contamos con una red pequeña, pero se vuelve pocopráctica para redes de gran tamaño.

En el caso de redes grandes en lugar de tablas se tiene un conjuntode servidores de nombres interconectados.

Los servidores de nombres forman un árbol que se corresponde conuna estructura institucional. Estas instituciones conforman el sistemade dominios y delegan la autoridad sobre los nombres a institucionesjerárquicamente 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 Informática.Para saber dónde se encuentra EDU, se debe consultar a un servidorraíz. EDU mantiene a las instituciones educacionales. El servidor raízcuenta con varios servidores para EDU, por lo tanto se debe consultar aEDU acerca del servidor para UNLP y así sucesivamente hasta completarla dirección. 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 raíz es el servidorde nombres del nivel más alto de los dominios tal como EDU. De estamanera un simple query sobre el server raíz llevará a UNLP.

Además el software recuerda las consultas anteriores, esto permiterecordar dónde buscar los servidores para un nombre dado. Cada una deéstas piezas de información tiene un tiempo de vida asociado (del ordende días), luego de este tiempo la información expira y debe ser obtenidanuevamente.

Cada nombre de dominio es un nodo en una base de datos. El nodopuede tener registros que especifican un número de propiedades diferentes(por ejemplo: direcciones IP, tipo de computadora y una lista de serviciosprovistos para una computadora). Un programa puede preguntar por unapieza específica de información, o por toda la información acerca de unnodo dado. También es posible definir un alias para un nodo de la basede datos.

El sistema de dominios también puede usarse para almacenar infor-mación acerca de los usuarios, listas de mail y otros objetos.

Existe un standard que define la operación sobre las base de datos,tales como protocolos usados para realizar consultas sobre ellas. Cadared 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 enlos niveles de aplicación, presentación y sesión, trabajan otros protocolosque colaboran para desempeñar determinadas funciones.

Protocolos Usados en el Nivel OSI de Aplicación,

Presentación y Sesión

HTTP (protocolo de transferencia de hipertexto): Desde una aplicaciónllamada “navegador”, permite a una computadora cliente leer y ejecu-tar páginas web (archivos HTML) de un servidor web que se encuentradentro de la Intranet o en Internet. Estas páginas pueden incluir texto,imágenes, sonido, video y vínculos a otros archivos HTML, a los que sepuede 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 elsistema 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 servidorFTP situado dentro de la Intranet o en Internet. En Windows NT 4.0,2000 Y XP (Profesional), se puede crear un servidor FTP mediante laaplicación Internet Información Server (IIS).

TELNET : Permite que una computadora tenga acceso remoto sobreotra, e incluso, que ejecute sus programas a distancia a través de Internet.

SMTP (Protocolo Simple de Transferencia de Correo): Permite queuna computadora con TCP/IP pueda enviar a través de Internet correoelectrónico (e-mail) a un servidor SMTP, proporcionado generalmentepor el proveedor de Internet, que será el encargado de reenviar los men-


sajes recibidos para que lleguen a destino.

POP3 (Protocolo de Oficina de Correo versión 3): Permite que unacomputadora con TCP/IP pueda recibir correo electrónico desde un servi-dor POP3, proporcionado por el de Internet. En Internet encontraremosmuchos servicios que nos ofrecen la posibilidad de tener una cuenta decorreo de tipo POP3. Esto significa, justamente, la posibilidad de admin-istrar una aplicación denominada “cliente de correo electrónico”, comopuede ser Outlook Express, Eudora entre otros programas.

Métodos de Comunicación

Los protocolos de transporte se utilizan para enviar información de unpuerto a otro consiguiendo así que haya comunicación entre los programasde aplicación. Utilizan un método de comunicación orientada a conexióno bien un método sin conexión.

TCP es un protocolo orientado a conexión y UDP es un protocolode transporte sin conexión.

El protocolo TCP orientado a conexión establece un vínculo de comu-nicación entre una dirección del puerto fuente y una dirección del puertodestino. Los puertos se conectan entre sí a través de este vínculo hastaque la conexión finaliza y el vínculo se rompe. Un ejemplo de protocoloorientado a conexión es una conversación telefónica. Esta se establece,la comunicación tiene lugar y la conexión finaliza.

La fiabilidad de la comunicación que se establece entre los progra-mas fuente y destino se asegura a través de mecanismos de detección ycorrección de errores que se implementan en el TCP.

TCP implementa la conexión como un flujo de bytes desde la fuentehasta el destino. Esta característica permite el uso de clases de E/S deflujo que ofrece Java.io.

El protocolo sin conexión UDP difiere del protocolo orientado a conex-


ión en que no establece un vínculo mientras dura la conexión. Un ejemplode protocolo sin conexión es el correo postal. Para enviar algo por correo,simplemente se escribe la dirección de destino (y opcionalmente un re-mitente) en el sobre y se echa al buzón.

Cuando se usa UDP, un programa de aplicación escribe el puertode destino y la dirección IP en un datagrama y envía este último a sudestino. UDP es menos de fiar que TCP debido a que en el protocolono hay seguridad de entrega o mecanismos de detección y corrección deerrores.

Los protocolos de aplicación como son FTP, SMTP y HTTP utilizanTCP para ofrecer una comunicación fiable y basada en un flujo entre losprogramas clientes y servidor. Otros protocolos utilizan UDP, cuando lavelocidad de entrega es más importante que la fiabilidad.

Capítulo 3

Sistema Distribuidos

Introducción

La forma más elemental de interpretar un sistema distribuido es la deun sistema computacional compuesto por diferentes procesadores inter-conectados. Normalmente, esta interconexión estará soportada por unared abierta, basada en un conjunto de protocolos estándar que permitala colaboración entre aplicaciones, escalabilidad y portabilidad.

Esta interpretación no es, sin embargo, completa; los componentesde una aplicación distribuida pueden residir en la misma máquina o endistintos nodos de la red y, por lo tanto, al hablar de las interconexionesno se trata tanto de que se produzcan a través de enlaces hardware, sinode comunicaciones entre procesos.

Las siguientes secciones muestran los principales conceptos: enfoquesal diseño de aplicaciones distribuidas, aplicación distribuida en Internet,sockets, RPC - llamadas a procedimientos remotos, diferentes enfoques

29

Sistema Distribuidos 30

para la construcción de una aplicación distribuida, el modelo de objetodistribuido de Java y seguridad en una aplicación distribuida.

Enfoques al Diseño de AplicacionesDistribuidas

Una aplicación distribuida es una aplicación cuyo procesamiento se dis-tribuye por múltiples computadoras de una red.

Las aplicaciones distribuidas son capaces de servir a la vez a usuariosmúltiples y, dependiendo de su diseño, hacer uso más adecuado de losrecursos de procesamiento.

Las aplicaciones distribuidas se implementan típicamente como sis-temas cliente / servidor , organizados de conformidad con la interfaz deusuario, el procesamiento de la información y las capas de procesamientode la información como se ilustra en la figura 3-1 de la pág. 30.

Figura 3-1 La organización de sistema distribuido.

La capa de interfaz de usuario viene implementada por una aplicacióncliente. Los programas de correo electrónico y navegadores web consti-tuyen ejemplos del componente de interfaz de usuario de las aplicacionesdistribuidas.

La capa de procesamiento de la información la implementa la apli-cación cliente, una aplicación servidor o una aplicación con soporte deservidor. Por ejemplo, una aplicación 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 admitirla comunicación entre el cliente y un servidor de base de datos, y el servi-dor de base de datos puede usar software de información para procesarla información solicitada por un cliente.

La capa de almacenamiento de la información la implementan servi-dores de bases de datos, servidores Web, servidores FTP, servidores dearchivo y cualquier otro servidor cuya finalidad sea la de almacenar yrecuperar información.

Aplicaciones Distribuidas en Inter-net

La popularidad de la Internet y de la Web ha supuesto la congestión dela red. Las computadoras son accesibles directamente entre sí a travésdel protocolo TCP/IP.

Esta conectividad mundial ha hecho crecer las aplicaciones distribuidasque se ejecutan en la estructura cliente / servidor de Internet. Estas apli-caciones de primera generación admiten la comunicación cliente / servi-dor en base a protocolos específicos de la capa de aplicación como sonHTTP, FTP Y SQL*NET (ver figura 3-2 de la pág. 32).

Normalmente un programa cliente se ejecuta en múltiples computa-doras Host. El cliente utiliza TCP para conectarse con un servidor queescucha en un puerto conocido. El cliente realiza una o más solicitudes alservidor. Este servidor procesa las solicitudes del cliente, posiblementeutilizando programas de pasarela o servidores de fondo y reenvía la re-spuesta al cliente.

Por ejemplo, una aplicación financiera que se esté ejecutando en laPC puede invocar métodos de objetos que se estén ejecutando en otraPC que pertenezca a la Intranet de la empresa. Puede ser que estos


Servidor De aplicación

cliente

ServidorBlack-end

ServidorBlack-end

cliente

cliente

Figura 3-2 Estructura del servidor.

objetos busquen en las bases de datos de empresas la información quela aplicación financiera está utilizando, que procesen esta información deacuerdo con las reglas comerciales de la empresa y que la faciliten a suaplicación financiera.

Los resultados que haya calculado la aplicación financiera pueden serautomáticamente reenviados a un objeto de distribución de información,el cual pondrá los resultados a disposición de otros empleados de la em-presa, además de a los agentes y clientes seleccionados. La figura 3-3 dela pág. 33 ilustra este ejemplo de aplicación distribuida.

Sockets

La comunicación entre cliente / servidor se realiza a bajo nivel sobre undeterminado protocolo de red, siendo TCP/IP el más empleado. Cadadispositivo en red recibe una dirección IP única (al menos en el ámbito


Aplicación Financiera

Objeto deBúsqueda

Objeto deDistribución de Información

Objetos de Normas Comerciales

Figura 3-3 Ejemplo de aplicación distribuida.

de esa red) que la identifica para sus comunicaciones. Un punto finalde comunicaciones queda definido por la dirección IP y un número depuerto, es decir, un mismo dispositivo puede tener múltiples líneas decomunicación abiertas, al menos una por cada puerto empleado.

La popularidad actual de TCP/IP se debe a Internet, que lo empleacomo protocolo de red, y ha sido el protocolo empleado en máquinasUnix desde su inicio.

A principios de los ’80 la distribución UNIX de Berkeley introdujo elmodelo de sockets como un mecanismo de comunicación entre procesos[16, Leffler McKusick Karels-89], que se ha convertido en el estándarde facto para programación en red sobre TCP/IP. Sin embargo, su API(interfaz de programación de aplicaciones) puede en principio usarse con


otros protocolos de red.

Un socket [24, Stevens-90] es un punto final de comunicación, iden-tificado en TCP/IP mediante la dirección IP y un puerto. Existen dostipos de sockets: orientados a conexión (TCP) y sin conexión, tambiénllamados datagramas (UDP).

TCP crea un circuito virtual entre los procesos que comunica, por loque los sockets sobre TCP se consideran fiables. Los datagramas no sonfiables ni se asegura el orden o no duplicación de los datos enviados, peropermiten el envío de mensajes broadcast, a más de un destino final.

Un servidor que emplea sockets debe asociarse a una determinadadirección, donde espera continuamente la llegada de datos.

Un cliente debe conocer cuál es esa dirección específica para enviarledatos.

La información que se transmite no tiene ningún significado para lossockets, que actúan únicamente como puntos de entrada y salida paralas comunicaciones. Es la aplicación la que debe interpretar esos datos yproducir, posiblemente, una respuesta (ver figura 3-4 de la pág. 34).

Figura 3-4 Utilización de sockets.


RPC - Llamadas a ProcedimientosRemotos

Se hamencionado que las aplicaciones distribuidas se implementan típica-mente como sistemas cliente / servidor; seguidamente se verá un ejemplosencillo de autentificación.

Un cliente suministra un nombre (login) y una clave (password), yel servicio comprueba su validez. Empleando sockets, el cliente debeconectarse al servidor y enviar en una cadena de bytes la informaciónnecesaria, el nombre y la clave, que se supone son cadenas de caracteres.

No existe ningún requisito, sobre cómo enviar esa información, y elservidor debe especificar qué formato espera. Por ejemplo, un primerbyte que indique la longitud del nombre, seguido por tantos bytes comocaracteres tengan el nombre, y luego otro byte que indique la longitudde la clave y tantos bytes como caracteres tenga esa clave.

Es responsabilidad del cliente, aplicar correctamente el formato es-perado. Y este formato debe especificarse con mayor detalle: qué ordende bytes se espera, qué codificación de caracteres, ASCII o EBCDIC, etc.Además, la aplicación debe gestionar los errores de comunicaciones.

Desde el punto de vista del servidor [22, Smith Ungar-95], si precisasoportar varios clientes simultáneamente, es también la aplicación la quedebe incluir toda la lógica de concurrencia y de gestión de múltiplesclientes.

Una librería puede soportar el formateo/deformateo de determinadostipos de datos, definiendo cómo transferir cadenas de caracteres, tipos en-teros, etc. Si tanto el servidor como el cliente emplean la misma librería,parte de los anteriores problemas se solucionan. suministra este soportede librería, a la vez que realiza una abstracción de llamadas a proced-imientos. Siguiendo el ejemplo anterior, el servidor puede especificarsecomo una función definida de la siguiente manera:

int validate (in char* login, in char *password).


Al emplear un compilador RPC sobre esta definición, se generan dosporciones de código. Una se llama stub del cliente, y lo que hace esproporcionar un procedimiento con la misma definición dada.

El cliente invoca este procedimiento (ver la figura 3-5 de la pág. 36),y éste automáticamente prepara la cadena de bytes a enviar al servidor,formateando los datos y enviándolos a través del socket.

La segunda porción de código se denomina stub del servidor, verificacontinuamente el socket donde recibe la información, que deformatea yenvía al servidor. Cuando se elabora la respuesta, ésta se envía por elcamino inverso.

De esta forma, se accede al servidor como si fuera local, al que se in-voca mediante procedimientos, tal como si fuera una librería del sistema.

Figura 3-5 Filosofía del RPC.


Diferentes Enfoques Para la Contruc-ción de Aplicaciones Distribuida

Entorno de Computación Distribuida

El Entorno de Computación Distribuida (DCE) constituye otro enfoquepara la construcción de aplicaciones distribuidas.

El DCE fue desarrollado por la Open Software Foundation, a la quese llama ahora Open Group. DCE integra una serie de servicios y tec-nologías fundamentales para construir aplicaciones distribuidas.

Los sistemas distribuidos están organizados en celdas, que son gruposde recursos, servicios y usuarios de procesamiento que admiten funcionescomunes y que comparten un conjunto común de servicios del DCE. Porejemplo, se pueden organizar las celdas de acuerdo con las funcionesde la empresa. En este caso, se puede tener celdas separadas para losdepartamentos financiero, de producción y de marketing.

Los servicios y tecnologías que se usan, en una celda del DCE constande:

• Servicios de Directorio: Almacenan los nombres de los recursosque están disponibles dentro del entorno distribuido. El Serviciode Directorio de Celda (CDS) admite los nombres en una celda,mientras que el Servicio de Directorio Global (GDS) admite losnombres en todas las celdas de una empresa. GDS implementa elservicio de directorio X.500.

• Servicio de Archivos Distribuidos (DFS): Un servicio opcional delOCE que proporciona un sistema de archivos perfecto que operaen todas las computadoras que hay en una celda.

• Servicio de Horas Distribuidas (DTS): Se usa para sincronizar lahora 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 están disponibles den-tro de la misma.

• Llamadas de Procedimientos Remotos (RPC): Reemplazan a lossockets TCP como mecanismo básico para la comunicación cliente/ servidor. Las RPC se implementan como capa que se construyepor encima de la capa de transporte TCP/IP y gestiona de formatransparente las cuestiones relativas al manejo de la conexión y delos protocolos.

• Hilos del OCE : Parecidos a los hilos de Java. Se trata de procesosligeros que simplifican el diseño de aplicaciones cliente / servidor.

• El DCE se dice que es de soporte intermedio, ya que no se tratade un producto autónomo, sino de un paquete de servicios que seintegra en un sistema operativo o entorno operativo. Estos servi-cios se usan como alternativa a la construcción de las aplicacionesdistribuidas.

El Modelo de Objeto Componente Distribuido

ElModelo de Objeto Componente Distribuido, oDCOM, es el planteamientode Microsoft al desarrollo de sistemas distribuidos.

El DCOM se basa en el COM, que constituye el núcleo de la estrate-gia de desarrollo orientado a objetos de Microsoft. Dado que el DCOMes esencialmente una extensión del sistema distribuido del COM, la com-prensión de este último es fundamental para entender el primero.

Comprensión del COM

COM es el fruto de la tecnología Incrustación y Vinculación de Objetos,de Microsoft.

El COM era una solución 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 múltiples.)


Los objetos COM constituyen instancias de las clases y se organizanen interfaces. Las interfaces son simples colecciones de métodos.

A los objetos COM sólo se puede acceder a través de sus métodos,y cada objeto COM se implementa dentro de un servidor. Un servidorse puede implementar como biblioteca de vínculos dinámicos, procesoindependiente o servicio operativo.

El COM evita los detalles de la implementación y presenta una in-terfaz única y uniforme para todos los objetos, independientemente decómo esté implementado cada objeto.

La biblioteca del COM es clave para implementar esta interfaz comúnentre los objetos.

Está presente en todo sistema que admita el COM y proporcionaun directorio de todas las clases que estén disponibles en ese sistema.La biblioteca del COM mantiene información sobre las clases que estándisponibles en el registro del sistema.

Cuando un objeto COM accede a otro, en primer lugar invoca a lasfunciones de la biblioteca del COM. Estas funciones se pueden utilizarpara crear un objeto COM a partir de su clase u obtener un indicador asus interfaces.

El tiempo de ejecución del COM es un proceso que da soporte ala biblioteca del COM para implementar sus funciones. Lo admite elAdministrador de Control de Servicios.

El objeto invocante utiliza señalizadores de interfaz para invocar losmétodos del objeto al que accede a través de la biblioteca del COM.Los señalizadores que usan los objetos COM pueden ser empleados porobjetos que están escritos en cualquier lenguaje de programación.

El lenguaje de definición de interfaz que se usa para definir las in-terfaces y métodos del COM procede del DCE. El COM define tambiénun estándar de interfaz binaria. Este estándar ayuda a promocionar laindependencia del lenguaje.

Nota: El COM difiere de otros sistemas orientados a Objetos en susoporte a la herencia. Las clases del COM no heredan la implementación


de métodos a partir de sus superclases. Solo heredan la definici6n de esasinterfaces. Esto implica que todos los métodos deben ser implementadosde nuevo cada vez que se declare una subclase.

El COM ofrece una solución a este problema, llamada agregación.Utilizando la agregación, una clase puede heredar una interfaz completacopiando la interfaz de su superclase. No obstante,1a clase no puedeomitir los métodos individuales de la interfaz de herencia.

Del COM al DCOM

El DCOM es esencialmente el COM distribuido sobre computadoras múlti-ples. El DCOM permite a los objetos COM que se ejecutan en unacomputadora crear objetos COM en otras computadoras y acceder a susmétodos. La ubicación del objeto remoto es transparente.

Utilizando el DCOM se accede a los objetos remotos de una maneraexactamente igual que a los objetos locales.

Con el fin de que un objeto que está en un sistema local acceda a losmétodos de un objeto que está en un sistema remoto, el sistema localdebe registrar la clase del objeto remoto en su registro local.

El objeto local inconsciente de la ubicación del objeto al que estáaccediendo, crea el objeto remoto y/u obtiene un indicador a sus métodosmediante la invocación de las funciones de su biblioteca del COM local.La biblioteca del COM procesa las llamadas de función por medio de sutiempo de ejecución del COM local.

El tiempo de ejecución del COM comprueba la clase del objeto al quese está accediendo en el registro del sistema.

Si el registro indica que la clase se define en el registro de una máquinaremota, el tiempo de ejecución del COM local contactará con el tiempode ejecución del COM de la máquina remota y le pedirá que cree el objetoremoto o que se invoquen sus métodos.

El tiempo de ejecución del COM remoto llevará a cabo la petición siésta la aceptan las normas de seguridad del sistema.


Los procesos del tiempo de ejecución del COM de máquinas separadasse comunican entre sí por medio de un mecanismo de la RPC que sedenomina RPC de objetos, u ORPC.

La ORPC se basa en la RPC de Microsoft, que es, en esencia, la RPCdel DCE.

La ORPC puede ser configurada para utilizar una serie de protocolosde transporte, pero funciona mejor con el UDP. Dado que la mayoría delos corta fuegos bloquean al UDP, es necesario utilizar el TCP junto a laORPC 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 restringirseen una aplicación determinada. La figura 3-6 de la pág. 54 resume elfuncionamiento del DCOM.

Modo de Funcionamiento del DCOM

Si bien el DCOM es un producto de Microsoft, constituye un estándarabierto que se ha transportado a otras plataformas, como UNIX.

Microsoft trata de que el DCOM sea una solución de plataformacruzada para el desarrollo de aplicaciones distribuidas. Así, los usuariosde Windows la han recibido muy bien, pero el éxito en las aplicacionesde plataformas cruzadas ha sido más bien mediocre.

Una de las características a destacar del DCOM es el soporte que daa las aplicaciones.

La seguridad del DCOM integra y amplía el modelo de seguridad deWindows NT. Permite que se tomen decisiones de control de acceso conun alto nivel de granularidad. Por ejemplo, resulta posible especificar sia un objeto se le permite crear o invocar a los métodos de otro.

El DCOM también ofrece una seguridad en la comunicación flexi-ble y fuerte. Se pueden usar una serie de mecanismos de encriptaciónpara proteger la información en la forma en que ésta se transmite de unobjeto COM a otro. Windows NT 5.0 amplía estas posibilidades de en-


criptación a la autenticación basada en Kerberos, a la encriptación y alcontrol de acceso (Kerberos es un potente mecanismo de protección quefue desarrollado por el Instituto de Tecnología de Massachusetts).

Arquitectura de Intermediación de So-licitud de Objetos Comunes (CORBA)

La Arquitectura de Intermediación de Solicitud de Objetos Comunes oCORBA ofrece otra aproximación, a la construcción 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 métodosde objetos de otras computadoras. CORBA, al contrario que el DCOM,es una solución abierta y no está vinculada a ningún sistema operativodeterminado.

Debido a esto, CORBA constituye una buena opción a la construcciónde aplicaciones orientadas a objetos distribuidos.

CORBA utiliza los objetos que están accesibles a través de los Inter-mediarios de Solicitud de Objetos (ORB). Estos ORB se emplean paraconectar objetos entre sí por una red. Un objeto de una computadora(objeto cliente) invoca a los métodos de otro objeto de otra computadora(objeto servidor) a través de un ORB.

La interfaz del cliente al ORB es un fragmento adaptador que estáescrito en Lenguaje de Definición de Interfaz (IDL). El fragmento adap-tador es un proxy local de un objeto remoto. El IDL proporciona unmecanismo de programación independiente del lenguaje para describirlos métodos de un objeto.

La interfaz del ORB con el servidor se hace a través de un esqueletodel IDL. Este esqueleto dota al ORB de un mecanismo independiente dellenguaje que sirve para acceder al objeto remoto.


La invocación remota de métodos de CORBA tiene lugar como sigue:

• El objeto cliente invoca los métodos del fragmento adaptador delIDL que se corresponde con un objeto remoto.

• Este fragmento adaptador comunica las invocaciones de métodosal ORB.

• El ORB invoca los métodos correspondientes del esqueleto del IDL.

• Este esqueleto invoca los métodos de la implementación remota deobjetos servidor.

• El objeto servidor devuelve el resultado de la invocación de métodosa través del esqueleto del IDL, que devuelve el resultado al ORB.

• El ORB a su vez devuelve el resultado al fragmento adaptador delIDL, mientras que este fragmento adaptador devuelve el resultadoal objeto diente.

La figura 3-7 de la pág. 55 muestra el ORB como una sola capa delos hosts de cliente y servidor. Esta es la forma normal en que se ve elORB.

Caben una serie de implementaciones del ORB. Por ejemplo, los ORBhermanos pueden ser implementados en los hosts de cliente y servidor, oun ORB de sistema central puede ser implementado en un servidor local.También son posibles otras implementaciones ORB.

Ahora que ya se sabe cómo funciona CORBA, podría preguntarsecómo se usa para desarrollar aplicaciones distribuidas. La respuesta esque CORBA proporciona un enfoque flexible al desarrollo de aplicacionesdistribuidas.

Ofrece un nivel muy bueno de granularidad en la implementación desistemas cliente / servidor. En lugar de depender de clientes y servidoresmonolíticos (como es el caso de los navegadores y servidores Web), tantolos clientes como los servidores se pueden distribuir sobre varios hosts.

Las ventajas que tiene CORBA sobre otros enfoques de integraciónde aplicaciones distribuidas son significativos:


• Proporciona un verdadero enfoque orientado a objetos para el de-sarrollo de aplicaciones distribuidas.

• Es independiente del lenguaje. Se puede utilizar para conectarobjetos que se desarrollen en cualquier lenguaje de programación,siempre y cuando se pueda suministrar a los objetos un fragmentoadaptador del IDL.

• Se reconoce como un estándar internacional y lo admiten casi todaslas principales marcas.

Invocación Remota de Métodos deJava

Habida cuenta de los diferentes enfoques relacionados con el desarrollode las aplicaciones distribuidas de las secciones anteriores, cabría pregun-tarse por qué Java no toma el mejor enfoque en lugar de usar la RMI.Existen varias razones para explicar esto:

• Sockets TCP: Java los admite. Puede construir aplicaciones tradi-cionales cliente / servidor en base a sockets usando Java en unaintranet o en Internet. Los applets y servlets de Java se puedenusar para distribuir la capa de procesamiento de información de laaplicación entre el cliente y el servidor. Aunque Java admita sock-ets TCP, JavaSoft decidió que se necesitaba un enfoque más densopara el desarrollo de las aplicaciones distribuidas, como el que pro-porciona CORBA, con el fin de desarrollar aplicaciones distribuidasavanzadas por medio de Java.

• DCE : Se basa en la RPC, que constituye un enfoque orientado aprocedimientos para el desarrollo de aplicaciones distribuidas. LaRPC no se acopla bien con las aplicaciones distribuidas orientadasa objetos. El enfoque que la invocación remota de métodos que


admite CORBA se adapta mucho mejor al modelo de objetos deJava.

• DCOM : Se basa en la RPC del DCE, pero ofrece posibilidades deprogramación orientadas a objetos a través de objetos, interfacesy métodos del COM. Además, el DCOM proporciona servicios deseguridad amplios. El entorno de desarrollo Java de Microsoft,Visual J++, ofrece la posibilidad de acceder a objetos COM yDCOM desde Java. No obstante, esta posibilidad constituye másbien un puente a las tecnologías de herencia que una extensióndistribuida del modelo de objetos Java.

• CORBA: Proporciona un enfoque excelente a la construcción deaplicaciones distribuidas orientadas a objetos. Y Java sí que ad-mite CORBA. Sin embargo, CORBA está diseñada para admitirun modelo de objetos independiente del lenguaje. La RMI de Javaposee todas las ventajas de CORBA, pero está especialmente adap-tada al modelo de objetos Java. Esto hace que la RMI de Java seamucho más eficaz y fácil de usar que CORBA en lo que respecta aaplicaciones de Java puro.

El Modelo de Objeto Distribuido deJava

El Modelo de Objeto Distribuido que usa Java permite que los objetosque se ejecutan en una JVM invoquen a los métodos de objetos que seejecutan en otras JVM. Estas otras JVM pueden ejecutarse como procesoseparado en la misma computadora o en otras computadoras remotas.

El objeto que hace la invocación del método se denomina objetocliente (Hijo).

El objeto cuyos métodos se están invocando se denomina objeto servi-dor (Padre).


El objeto cliente también recibe el nombre de objeto local y se diceque se ejecuta de forma local.

El objeto servidor también se denomina objeto remoto y se dice quese ejecuta de forma remota.

En el Modelo de Objeto Distribuido de Java, un objeto cliente nuncahace referencia directa a un objeto remoto. En lugar de ello, hace refer-encia a una interfaz remota que implementa el objeto remoto.

El uso de interfaces remotas permite que los objetos servidor se difer-encien entre sus interfaces locales y remotas. Por ejemplo, un objetopodría proporcionar métodos a los objetos que se ejecutaran dentro de lamisma JVM que se sumarían a los que proporciona a través de su interfazremota.

El uso de interfaces remotas también permite que los objetos servidorpresenten modos diferentes de acceso remoto.

Por ejemplo, un objeto servidor puede proporcionar al mismo tiempouna interfaz de administración remota y una interfaz de usuario remota.

Por último, el uso de interfaces remotas permite que la posición delobjeto servidor dentro de su clase jerárquica se abstraiga de la maneraen que éste se utiliza. Esto permite compilar los objetos cliente pormedio de la interfaz remota, eliminando la necesidad de que los archivosde clases del servidor estén presentes localmente durante el proceso decompilación.

Las Tres Capas de la RMI de Java

Aparte de las interfaces remotas, el modelo utiliza clases pertenecientesal fragmento adaptador y al esqueleto de forma muy parecida a como lohace CORBA:


• Las clases de fragmento adaptador actúan como proxies locales delos objetos remotos.

• Las clases de esqueleto actúan como proxies remotos.

• Ambas clases implementan la interfaz remota del objeto servidor.

• La interfaz cliente invoca a los métodos del objeto fragmento adap-tador local.

• El fragmento adaptador local comunica estas invocaciones de méto-dos al esqueleto remoto, mientras que este último invoca a los méto-dos del objeto servidor.

• El objeto servidor devuelve un valor al objeto esqueleto.

• El objeto esqueleto devuelve el valor al objeto fragmento adaptador,mientras que este último devuelve el valor al cliente.

La figura 3-8 de la pág. 55 resume el uso de los fragmentos adapta-dores y esqueletos.

Si se es un programador de CORBA, se notará la ausencia de los IDLy ORB en la figura 3-8 de la pág. 55 (IDL Y ORB se requieren por partede CORBA, ya que es neutral al lenguaje).

Las clases de fragmento adaptador y esqueleto las genera automáti-camente el compilador RMIC a partir del objeto servidor (el compiladorRMIC es una herramienta estándar del JDK ). Estas clases son clasesverdaderas de Java y no dependen de un IDL externo.

No se necesita un ORB, ya que la RMI de Java es una solución deJava puro. El objeto cliente y el fragmento adaptador se comunican pormedio de las invocaciones normales de métodos de Java, al igual quelo hacen el esqueleto y el objeto servidor. El fragmento adaptador y elesqueleto se comunican a través de una capa de referencia remota.

Esta capa de referencia remota admite la comunicación entre el frag-mento adaptador y el esqueleto. Si el fragmento adaptador se comunica


con más de una instancia de esqueleto (no admitida activamente), el ob-jeto fragmento adaptador se comunicará con esqueletos múltiples de unmodo multidifusión.

Hoy por hoy, la API RMI sólo define las clases que admiten una comu-nicación unidifusión entre un fragmento adaptador y un solo esqueleto.La capa de referencia remota también puede ser utilizada para activarlos objetos servidor cuando se invoquen remotamente.

La capa de refencia remota del host local se comunica con la capa dereferencia remota del host remoto a través de la capa de transporte de laRMI.

La capa de transporte configura y administra las conexiones que se danentre objetos a los que se puede acceder normalmente y determina cuándolas conexiones están en compás de espera y se vuelven inoperativas. Lacapa de transporte utiliza por defecto sockets TCP para comunicarseentre los hosts local y remoto, no obstante, se puede usar también otrosprotocolos de capa de transporte, como SSL y UDP.

La figura 3-9 de la pág. 56 ilustra las tres capas que se usan paraimplementar la RMI de Java.

En esta vista ampliada del modelo:

• El objeto cliente invoca a los métodos del fragmento adaptadorlocal del objeto servidor.

• El fragmento adaptador local utiliza la capa de referencia remotapara comunicarse con el esqueleto del servidor.

• La capa de referencia remota utiliza la capa de transporte paraestablecer una conexión entre los espacios de direciones locales yremotas y para obtener una referencia del objeto esqueleto.

Con el fin de que se pueda acceder remotamente a un objeto servidor,éste se debe registrar a sí mismo con el registro remoto. Esto lo haceasociando su instancia de objeto a un nombre.


El registro remoto es un proceso que se ejecuta en el host del servidory se crea ejecutando el programa rmiregistry, otra herramienta del JDK.

El registro remoto mantiene una base de datos de objetos servidory los nombres en virtud de los cuales se puede hacer referencia a esosobjetos.

Cuando un cliente crea una instancia de la interfaz de un objeto servi-dor (es decir, su fragmento adaptador local):

• La capa de transporte del host local se comunica con la capa detransporte del host remoto para determinar si el objeto al que se hahecho referencia existe y para ver el tipo de interfaz que implementael objeto al que se ha hecho referencia.

• La capa de transporte del lado del servidor utiliza el registro remotopara acceder a esta información.

• Un proceso separado, al que se llama Demonio de Sistema de Ac-tivación de la RMI de Java, da soporte a la activación de objetosremotos. Este proceso se ejecuta por medio del programa rmid delJDK en el sistema remoto.

Pasar Argumentos y Valores de Re-torno

Para que un objeto cliente pase un argumento como parte de la invocaciónremota de métodos, el tipo de argumento deberá ser serializable.

Un tipo serializable es un tipo primitivo, o de referencia, susceptiblede ser escrito o leído en un flujo. En la práctica, todos los tipos primitivosde Java son serializables, y también lo son todas las clases e interfaces queimplementan o amplían la interfaz Serializable. Esta interfaz se defineen el paquete java.io.


Las referencias a objetos se usan dentro de la JVM que contiene elobjeto.

Cuando un objeto local se pasa como argumento a una invocaciónremota de métodos, el objeto local se copiará de la JVM local a la JVMremota. Sólo se copian las variables de campo no estáticas y no transi-torias.

Cuando se pasa un objeto remoto a través de una invocación remotade métodos dentro de la misma JVM, se pasará la referencia al objetoremoto. Esto se debe a que la JVM remota contiene el objeto al que seestá haciendo referencia.

Cuando un objeto servidor está devolviendo un objeto como conse-cuencia de la invocación remota de métodos, el objeto se copiará de laJVM remota a la JVM local.

Los Objetos y la Invocación Remotade Métodos

ElModelo de Objeto Distribuido de Java constituye una extensión naturaldel Modelo de Objetos de Java que hay en una sola JVM. Este modeloimplementa la RMI de un modo fácil de usar y establece unos requisitosmínimos para que se pueda acceder a los objetos remotamente. Estosrequisitos son:

• La clase del objeto debe implementar una interfaz que amplíe la in-terfaz Remote. Esta interfaz debe definir los métodos que el objetova a permitir que se invoquen remotamente. Estos métodos debenarrojar la excepción RemoteException.

• La clase del objeto debe ampliar la clase RemoteServer. Esto sehace normalmente ampliando la subclase UnicastRemoteObject deRemoteServer.


• Las clases de fragmento adaptador y el esqueleto de la clase de ob-jeto deben ser creados por medio del compilador rmic. El fragmentoadaptador debe ser distribuido al host del cliente.

• La clase, interfaz y clase del esqueleto del objeto remoto debenestar en la CLASSPATH del host remoto. El demonio de activaciónremota y el registro remoto deben estar activados.

• .Se debe crear una instancia de objetos remotos, y se debe registraren el registro remoto. Los métodos bind ( ) y rebind ( ) de la claseNaming se ulizan para registrar un objeto con su nombre asociado.El objeto remoto debe instalar un administrador de seguridad parapermitir la carga de las clases de la RMI.

Seguridad de la Aplicación Distribuida

El modelo de objetos distribuidos de Java implementa la seguridad através del uso de cargadores de clase y administradores de seguridad dela misma forma que lo hace para applets y aplicaciones.

El cargador de clases confía en las clases que se cargan desde el hostlocal. No se permite cargar las clases desde una red, a menos que unadministrador de seguridad esté presente y permita la carga de clases deforma remota.

Se coloca automáticamente un administrador de seguridad para quelos applets se vayan cargando.

El administrador de seguridad que se usa en las aplicaciones dis-tribuidas de Java es la clase RMISecurityManager.

Se debe establecer una instancia de esta clase a través del métodosetSecurityManager() de la clase System al principio de la ejecución deun objeto cliente o servidor.

Se pueden desarrollar administradores de seguridad menos restrictivos


subclasificando RMISecurityManager y omitiendo sus métodos.

Seguridad en el Transporte

Dado que la RMI utiliza TCP/IP para la comunicación en redes, estásujeto a las debilidades del paquete de protocolos TCP /IP.

Las mejoras del JDK 1.2 a la RMI ofrecen la posibilidad de crearsockets personalizados sobre una base objeto a objeto.

Los sockets personalizados pueden hacer que la RMI utilice el pro-tocolo SSL de Netscape para proteger la información a medida que secomunica entre los objetos locales y remotos. Esto se hace creando unaRMI- SocketFactory personalizada.

Autenticación y Control de Acceso

La autenticación es el proceso de verificación de la identidad de unapersona u objeto que actúa en nombre propio.

El control de acceso es el proceso de restringir el acceso a los recursoso servicios que están basados en la identidad de un objeto o de unapersona.

La autenticación y el control de acceso trabajan mano a mano. Sinuna autenticación consistente, las personas sin escrúpulos podrían hac-erse pasar por personas de toda confianza. Sin control de acceso, laautenticación no tiene dientes.

La autorización y el control de acceso son importantes en las aplica-ciones distribuidas. Por ejemplo, puede ser que se desee limitar los obje-tos capaces de invocar remotamente a los métodos de un objeto servidor


determinado a aquellos objetos que se ejecutan en un host específico oen un conjunto de hosts, o que actúan en nombre de una persona deter-minada.

La API RMI no proporciona las clases e interfaces que admiten di-rectamente la autenticación y el control de acceso.

No obstante, se pueden construir estas posibilidades por encima delas clases que ofrece la API RMI. Por ejemplo, el método getClientHost() de la clase RemoteServer puede utilizarlo un objeto servidor paradeterminar el nombre del host desde el que se inicia la invocación remotade métodos. Esto se puede usar para limitar el acceso de la RMI a unalista especificada de hosts, pero este enfoque no es infalible.

Existen formas de que hosts maliciosos se hagan pasar por hosts deconfianza. No obstante, puede ser usado para proporcionar un nivellimitado de protección.

Se pueden implementar una autenticación y un control de acceso másavanzados a través del uso de certificados digitales en la aplicación dis-tribuida general que admita la RMI.

Los corta fuegos pueden ser utilizados para proteger las aplicacionesdistribuidas que se ejecutan en una intranet. Se utilizan normalmentepara restringir el acceso a la aplicación distribuida a aquellos hosts queestén en una intranet corporativa o en un segmento seleccionado de unaintranet.

Sin embargo, los corta fuegos crean problemas propios. Si hay uncorta fuego en la ruta de comunicación entre objetos cliente y servidor,este corta fuego puede evitar que se produzcan invocaciones remotas demétodos.

Afortunadamente, JavaSoft ha reconocido el problema, y la claseRMISocketFactory ofrece la posibilidad de usar una RMI con un cortafuego. Esta clase utiliza enfoques alternativos a la comunicación cliente/ servidor susceptibles de emplearse para burlar las restricciones de se-guridad que imponen muchos corta fuegos.

Servidor de objetos

Objeto remoto COM

Servidor de objetos

Objeto local COM

Biblioteca COM

Tiempo de Ejecución COM(SCM)

Tiempo deEjecuciónCOM(SCM)

nivel detransporte

nivel detransporte

registro registro

Figura 3-6 COM y DCOM.


Host del cliente Host del cliente

Objetivo cliente Objetivo cliente

ORB

FRAGMENTO IDL

ESQUELETO DE IDL

Figura 3-7 Cómo funciona CORBA.

OBJETO CLIENTE

FRAGMENTO ESQUELETO

OBJETO SERVIDOR

Figura 3-8 RMI de Java.


Objeto Cliente

Fragmento

Nivel de Transporte

Nivel de Transporte

Esqueleto

Objeto Servidor

Nivel deReferencia Remota

Nivel deReferencia Remota

Figura 3-9 Las tres capas de RMI.

Capítulo 4

Sistemas Expertos

Definición de Sistema Experto

Un sistema experto (SE) puede definirse como un sistema informático(hardware y software) que simula a los expertos humanos en un área deespecialización dada [5, Castillo Gutierrez Haidi-96].

La más poderosa contribución de los sistemas expertos es poner alservicio de los analistas noveles la experiencia adquirida por aquellaspersonas consideradas verdaderos especialistas en el área.

Un SE es un software que imita el comportamiento de un expertohumano en la solución de un problema. Pueden almacenar conocimien-tos de expertos para un campo determinado y solucionar un problemamediante deducción lógica de conclusiones.

Son programas que contienen tanto conocimiento declarativo (hechosa cerca de objetos, eventos y/o situaciones) como conocimiento de control

57

Sistemas Expertos 58

(información acerca de los cursos de una acción), para emular el procesode razonamiento de los expertos humanos en un dominio en particulary/o área de experiencia [5, Castillo Gutierrez Haidi-96].

Los sistemas expertos son programas que reproducen el proceso int-electual de un experto humano en un campo particular, pudiendo mejo-rar su productividad, ahorrar tiempo y dinero, conservar sus valiososconocimientos y difundirlos más fácilmente.

El esquema resumido de funcionamiento de un SE se muestra en lafigura 4-1 de la pág. 58.

Figura 4-1 Esquema resumido del funcionamiento de un sistema experto.

Aspectos Fundamentales de los Sis-temas Expertos

Componentes de un Sistema Experto

Una característica decisiva de los SE es la separación entre conocimiento(reglas, hechos) por un lado y su procesamiento por el otro. A ello seañade una interfaz de usuario y un componente explicativo.


A continuación se muestra una breve descripción de cada uno de loscomponentes:

1. La Base de Conocimientos de un SE contiene el conocimiento delos hechos y de las experiencias de los expertos en un dominio de-terminado.

2. El Mecanismo de Inferencia de un SE puede simular la estrategiade solución de un experto.

3. El Componente Explicativo explica al usuario la estrategia de solu-ción encontrada y el porqué de las decisiones tomadas.

4. La Interfaz de Usuario sirve para que éste pueda realizar una con-sulta en un lenguaje lo más natural posible.

5. El Componente de Adquisición ofrece ayuda a la estructuración eimplementación del conocimiento en la base de conocimientos.

Tipos de Conocimiento

Existen dos tipos de conocimiento:

• Conocimiento abstracto: Es de validez general y se almacena per-manentemente.

• Conocimiento concreto: Es de validez particular y se almacenatemporalmente. Son los datos o hechos de un problema específicoque es resuelto por el SE.

Para el presente trabajo se usarán los dos tipos de conocimiento.El primero, como se usarán marcos de problema elementales, seránde validez general y se almacenarán permanentemente y el tipo deconocimiento concreto será empleado cuando se resuelva un prob-lema específico partiendo de lo general a lo particular.


Fuentes de Conocimiento

Existen dos tipos de fuentes de conocimiento:

• Fuentes Primarias: acceso directo al conocimiento (experto hu-mano, libros, textos, Internet, etc.).

• Fuentes Secundarias: acceso indirecto a la información (referencias,publicaciones, etc.).

Definición del Conocimiento

El conocimiento es materia de estudio de distintas disciplinas, tales comola filosofía, la gestión empresarial y, más recientemente la informática;existe varias definición, según el punto de vista e interés de quienes sepronuncien.

Para la definición de conocimiento varios autores interesados en lainformática, se apoyan en la definición, de dato e información.

Según la Real Academia Española dice:

• Dato: Antecedente necesario para llegar al conocimiento exacto, deuna cosa o para deducir las consecuencias legítimas de un hecho.

• Información: Acción y efecto de informar o informarse.

• Conocimiento: Acción y efecto de conocer. Noción, ciencia, sabiduría.Cada una de las facultades sensoriales del hombre en la medida enque están activas.

• Sabiduría:Conocimiento reutilizado y proceso de retroalimentaciónde los conocimientos (el aprendizaje como cuna del conocimiento).

En la figura 4-2 de la pág. 61 se señala la llamada cadena del conocimiento.


Figura 4-2 La cadena del conocimiento.

Clasificación de los Sistemas Expertos

Los sistemas expertos se clasifican de acuerdo al tipo de conocimiento

que se utiliza:

• SE basado en reglas: La construcción de la base de conocimiento esen base a reglas, lo cual, en algunos casos se elabora sencillamente;la explicación de las conclusiones es simple. El motor de inferenciase realiza con algoritmos complejos, lo cual es relativamente lento,además de que el aprendizaje estructural es complejo.

• SE basado en probabilidades: La construcción de la base de conocimientoes en base a frecuencias lo cual requiere de mucha información,la explicación de las conclusiones resulta más compleja. El mo-tor de inferencia se realiza con algoritmos simples, el aprendizajeparamétrico es sencillo.

Se empleará el conocimiento basado en reglas porque la informacióncon que se cuenta es de tipo determinístico.


Sistemas Expertos Basados en Reglas

Los sistemas basados en reglas son los más comúnmente utilizados. Susimplicidad y similitud con el razonamiento humano han contribuido parasu popularidad en diferentes dominios. Las reglas son un importante par-adigma de representación del conocimiento [5, Castillo Gutierrez Haidi-96].

Una regla es una afirmación lógica que relaciona dos o más objetos eincluye dos partes, la premisa y la conclusión. Cada una de estas partesconsiste en una expresión lógica con una afirmación objeto - valor conec-tadas mediante los operadores lógicos y, o, o no [5, Castillo GutierrezHaidi-96].

Las reglas representan el conocimiento utilizando un formato SI -ENTONCES (IF - THEN), es decir tienen 2 partes:

• La parte SI (IF): Es el antecedente, premisa, condición o situación.

• La parte ENTONCES (THEN): Es el consecuente, conclusión, ac-ción o respuesta.

Las reglas pueden ser utilizadas para expresar un amplio rango deasociaciones.

Una declaración de que algo es verdadero o es un hecho conocido, esuna afirmación.

El conjunto de afirmaciones se conoce frecuentemente con el nombrede base de afirmaciones. De igual forma, al conjunto de reglas se lodenomina base de reglas.

El Motor de Inferencia

Se ha mencionado que hay dos tipos de elementos: los datos (hechos oevidencia) y el conocimiento (el conjunto de reglas almacenado en la basede conocimiento).


El motor de inferencia usa ambos para obtener nuevas conclusioneso hechos. Por ejemplo, si la premisa de una regla es cierta, entonces laconclusión de la regla debe ser también cierta.

Los datos iniciales se incrementan incorporando las nuevas conclu-siones. Por ello, tanto los hechos iniciales o datos de partida como lasconclusiones derivadas de ellos forman parte de los hechos o datos de quese dispone en un instante dado.

Las conclusiones pueden clasificarse en dos tipos: simples y compues-tas.

Las conclusiones simples son las que resultan de una regla simple.

Las conclusiones compuestas son las que resultan de más de una regla.

Para obtener conclusiones, los expertos utilizan diferentes tipos deregla y estrategias de inferencias y control.

Las reglas son las siguientes:

• Modus Ponens.

• Modus Tollens.

• Resolución.

Las estrategias de inferencias son las siguientes:

• Encadenamiento de reglas.

• Encadenamiento de reglas orientado a un objeto.

• Compilación de reglas, que son utilizadas por el motor de inferencia

para obtener conclusiones simples y compuestas.

Las dos primeras reglas de inferencia se usan para obtener conclu-siones simples y el resto de reglas y estrategias para obtener conclusionescompuestas.

Nótese, sin embargo, que ninguna de las estrategias anteriores, si seimplementan solas, conduce a todas las conclusiones posibles. Por ello


deben implementarse varias reglas y estrategias en el sistema expertopara que el motor de inferencia sea capaz de obtener tantas conclusionescomo sea posible.

Modus Ponens y Modus Tollens

El Modus Ponens es quizás la regla de inferencia más comúnmente uti-lizada.

Se usa para obtener conclusiones simples. En ella se examina lapremisa de la regla y, si es cierta, la conclusión pasa a formar partedel conocimiento.

Como ilustración, supóngase que se tiene la regla, “Si A es cierto,entonces B es cierto” y que se sabe además que “A es cierto”. Entonces,tal como muestra la figura 4-3 de la pág. 65, la regla Modus Ponensconcluye que “B es cierto”.

Esta regla de inferencia, que parece trivial, debido a su familiaridad,es la base de un gran número de SE.

La regla de inferencia Modus Tollens se utiliza también para obtenerconclusiones simples.

En este caso se examina la conclusión y si es falsa, se concluye que lapremisa también es falsa. Por ejemplo, supóngase de nuevo que se tienela regla, “Si A es cierto, entonces B es cierto”, pero se sabe que “B esfalso”.

Entonces, utilizando la regla Modus Ponens no se puede obtenerninguna conclusión, pero, tal como se muestra en la figura 4-4 de lapág. 66, la regla Modus Tollens concluye que “A es falso”.

Aunque muy simple y con muchas aplicaciones útiles, la regla ModusTollens es menos utilizada que la Modus Ponens.

La reglaModus Ponens se mueve hacia delante, es decir, de la premisaa la conclusión de una regla, mientras que la regla Modus Tollens semueve hacia atrás, es decir, de la conclusión a la premisa.


Figura 4-3 Regla modus ponens.

Las dos reglas de inferencia no deben ser vistas como alternativas sinocomo complementarias.

La regla Modus Ponens necesita información de los objetos de lapremisa para concluir, mientras que la regla Modus Tollens necesita in-formación sobre los objetos de la conclusión.

De hecho, para un motor de inferencia que solamente utiliza ModusPonens, la incorporación de la regla de inferencia Modus Tollens puedeser considerada como una expansión de la base de conocimiento mediantela adición de reglas.

Resolución

Las reglas de inferencias Modus Ponens y Modus Tollens puede ser uti-lizada para obtener conclusiones simples. Por otra parte, las conclusionescompuestas, que se basan en dos o más reglas, se obtienen usando el lla-mado mecanismo de resolución.


Figura 4-4 Regla modus tollens.

Encadenamiento de Reglas

Una de las estrategias de inferencia más utilizada para obtener conclu-siones compuestas es el llamado encadenamiento de reglas.

Esta estrategia puede utilizarse cuando las premisas de ciertas clasescoinciden con conclusiones de otras.

Cuando se encadenan las reglas, los hechos pueden dar lugar a nuevoshechos. Esto se repite sucesivamente hasta que no pueda obtenerse másconclusiones.

El tiempo que consume este proceso hasta su terminación depende,por una parte, de los hechos conocidos, y por otra, de las reglas que seactivan.


Encadenamiento de Reglas Orientada a un Objetivo

El algoritmo de encadenamiento de reglas orientado a un objetivo re-quiere del usuario seleccionar, en primer lugar, una variable o nodo obje-tivo; entonces el algoritmo navega a través de reglas en búsqueda de unaconclusión para el nodo objetivo.

Si no se obtiene ninguna conclusión con la información existente, en-tonces el algoritmo fuerza a preguntar al usuario en busca de nueva infor-mación sobre los elementos que son relevantes para obtener informaciónsobre el objetivo.

Compilación de Reglas

Otra forma de tratar con reglas encadenadas consiste en comenzar con unconjunto de datos (información) y tratar de alcanzar algunos objetivos.Esto se conoce con el nombre de compilación de reglas.

Cuando ambos, datos y objetivos, se han determinado previamente,las reglas pueden ser compiladas, es decir, pueden escribirse los objetivosen función de los datos para obtener las llamadas ecuaciones objetivo.

En el presente trabajo se ha utilizadoModus Ponens y encadenamientode reglas.

Control de la Coherencia

En situaciones complejas, incluso verdaderos expertos pueden dar in-formación inconsistente (por ejemplo, reglas inconsistentes y/o combi-naciones de hechos no factibles). Por ello es muy importante controlarla coherencia del conocimiento tanto durante la construcción de la base

de conocimiento como durante los procesos de adquisición de datos yrazonamiento.

Si la base de conocimiento contiene información inconsistente (porejemplo, reglas y/o hechos), es muy probable que el SE se comporte deforma poco satisfactoria y obtenga conclusiones absurdas.


El objetivo del control de la coherencia consiste en:

• Ayudar al usuario a no dar hechos inconsistentes, por ejemplo, dán-dole al usuario las restricciones que debe satisfacer la informacióndemandada.

• Evitar que entre en la base de conocimiento cualquier tipo deconocimiento inconsistente o contradictorio.

El control de la coherencia debe hacerse controlando la coherencia delas reglas y la de los hechos.

Un conjunto de reglas se denomina coherente si existe, al menos, unconjunto de valores de todos los objetos que producen conclusiones nocontradictorias.

En consecuencia, un conjunto coherente de reglas no tiene por quéproducir conclusiones no contradictorias para todos los posibles conjuntosde valores de los objetos. Es decir, es suficiente que exista un conjuntode valores que conduzcan a conclusiones no contradictorias.

Metodología de Weiss y Kulikowski

Para el desarrollo de un sistema experto Weiss y Kulikowski sugieren lassiguientes etapas para el diseño e implementación de un SE :

• Planteamiento del problema: La primera etapa en cualquier proyectoes normalmente la definición del problema a resolver. Puesto queel objetivo principal de un SE es responder a preguntas y resolverproblemas, esta etapa es quizás la más importante en el desarrollodel mismo. Si el sistema está mal definido, se espera que el sistemasuministre respuestas erróneas.

• Encontrar expertos humanos que puedan resolver el problema: Enalgunos casos, sin embargo, las bases de datos pueden jugar el papeldel experto humano.


• Diseño de un SE : Esta etapa incluye el diseño de estructuras paraalmacenar el conocimiento, el motor de inferencia, el subsistema deexplicación, la interfaz de usuario, etc.

Base de Conocimiento

No es el único componente de un SE. Si lo fuera un SE podría ser tan

solo una lista de reglas condicionales if - then.

Lo que se necesita es un mecanismo para operar a lo largo de la base

de conocimiento para resolver un problema. A tal mecanismo se le conoce

como motor de inferencia.

Otra pieza necesaria es el área de trabajo que contenga las condi-

ciones del problema; esta captura puede realizarse mediante una lista

de verificación, preguntas y respuestas de opción múltiple o un sistema

extremadamente sofisticado sentado en el idioma natural.

Para interactuar con el sistema experto el usuario captura las condi-

ciones de un problema en la interfaz del usuario, y las almacena en el

área de trabajo.

El motor de inferencia se vale de tales condiciones para buscar una

solución en la base de conocimiento. La figura 4-5 de la pág. 70 muestra

un diagrama de secuencias de este proceso1.

Modelado de la Base de Conocimiento

La representación de UML para las reglas es similar a la de objetos.

Se debe contar con uno de los atributos para que sea la parte if, otra

la parte then, y agregar otros atributos conforme sea necesario.

El diseño de una regla mediante UML se esquematiza en la figura 4-6

de la pág. 702.

1Joseph Schmuller-2000.2Joseph Schrnuller-2000.


Figura 4-5 Proceso de búsqueda en la base de conocimiento.

Figura 4-6 Diceño de la regla mediante UML.

Para balancear la proliferación respecto a la necesidad de la simplici-dad, primero se crea un sencillo icono que representa a la regla, se llenala parte de if y la parte de then, seguidamente se debe de incorporarcierta información de identificación para cada regla, se agrega su nombre

en la parte superior; con esto se logra:

1. Convertir a cada regla en única.

2. Mostrar adónde ir en el catálogo de reglas para obtener una de-scripción y explicación completa de la regla.


Si una regla es parte de un subgrupo de reglas, se puede trataral subconjunto como un paquete. Luego agregar el paquete deinformación al identificador de la forma usual propia del UML,hacer que el nombre del paquete anteceda a un par de dos puntos(::), que antecedan al identificador.

Concluido el paso de análisis de requisitos, se pasa al siguiente paso,el diseño del SE :

• Elección de la herramienta de desarrollo: Debe decidirse si realizarun SE a medida utilizando lenguaje de programación.

• Desarrollo y prueba de un prototipo: Si el prototipo no pasa laspruebas requeridas, las etapas anteriores (con las modificacionesapropiadas) deban ser repetidas hasta que se obtenga un prototiposatisfactorio.

• Refinamiento y generalización: En esta etapa se corrigen los fallosy se incluyen nuevas posibilidades no incorporadas en el diseñoinicial.

• Mantenimiento y puesta al día: En esta etapa el usuario planteaproblemas o defectos del prototipo, corrige errores, actualiza el pro-ducto con nuevos avances, etc.

Todas estas etapas influyen en la calidad del SE resultante, que siem-pre debe ser evaluado en función de las aportaciones de los usuarios.

Las etapas en el desarrollo de un SE se indican en la figura 4-7 de lapág. 723.

La diferencia fundamental entre un programa tradicional y un SE

puede resumirse como sigue:

Un programa tradicional puede esquematizarse de la siguiente man-era:

3Enrique Castillo, José Manuel Gutiérrez, y Ah S. Hadi. [CAT, 1999].


Figura 4-7 Etapas en el desarrollo de un SE.


Un SE estaría definido de la siguiente forma:

Las ventajas que se obtiene al utilizar un SE son las siguientes:

• Mayor acceso al conocimiento experto.

• Rápida obtención de conclusiones y soluciones.

• Resultados objetivos.

• Conclusiones realistas en situaciones críticas.

Definiciones y Conceptos Sobre Grafos

Un grafo es un conjunto de vértices V (o nodos) y un conjunto de arcosE que se conectan entre sí.

El concepto de grafos puede definirse de forma más general, por ejem-plo, puede permitirse que dos nodos estén conectados por más de unaarista, o incluso que un nodo esté conectado consigo mismo.

Sin embargo, en el campo de los SE, los grafos se utilizan para repre-

sentar un conjuntos de variables proposicionales (nodos) y una relación

de dependencia entre ellas (aristas).


Las aristas de un gráfico pueden ser dirigidas o no dirigidas, depen-diendo de si se considera o no, el orden de los nodos.

En la práctica esta distinción dependerá de la importancia del ordenen que se relacionan los objetos.

En la figura 4-8 de la pág. 74 de muestran ejemplos de grafos y en lafigura 4-9 de la pág. 74 notaciones de los mismos.

Figura 4-8 Tipos de grafos.

Figura 4-9 Notación de grafos.

Los grafos pueden ser extendidos mediante la adición de rótulos (la-bels) a los arcos. Estos rótulos pueden representar costos, longitudes,distancias, pesos, etc.

Un grafo no dirigido se denomina completo si contiene una aristaentre cada par de nodos (ver figura 4-10 de la pág. 75).

Un grafo puede ser representado en memoria numéricamente, uti-lizando determinado tipos de matrices, como la matriz de adyacencia.


Figura 4-10 Grafo completo.

Un grafo se puede representar mediante una matriz A tal que A[i,j] =1 si hay un arco que conecta vi con vj, y 0 si no. La matriz de adyacenciade un grafo no dirigido, es simétrica.

Una matriz de adyacencia permite determinar si dos vértices estánconectados o no en tiempo constante, pero requieren O(n2) bits de memo-ria. Esto puede ser demasiado para muchos grafos que aparecen en apli-caciones reales, en donde |E|<<n2.

Otro problema es que se requiere tiempo O(n) para encontrar la listade vecinos de un vértice dado.

La matriz de adyacencia permite comprobar si existe algún caminoentre cada par de nodos, también puede calcularse la longitud de todoslos caminos que unan cada par de nodos

La representación mediante listas de adyacencia consiste en almace-nar, para cada nodo, la lista de los nodos adyacentes a él.

Ejemplo:

v1: v2

v2: v2, v3


v3: v1, v4

v4: v3

Esto utiliza espacio O(|E|) y permite acceso eficiente a los vecinos,pero no hay acceso al azar a los arcos.

Nota : En el presente trabajo se utiliza modus ponens, encade-namiento de reglas en la versión Yosuko 1.0, y en la versión Yosuko2.0 se utiliza la técnica de grafos completos, con matriz de adyacencia,destacándose los beneficios e inconveniente encontrados en cada caso.

Capítulo 5

Programación Orientada a Ob-jetos

Introducción

La programación orientada a objetos (POO) es una técnica de progra-mación que trata de mejorar las antiguas técnicas de programación lineal

y programación estructurada.

Con los lenguajes estructurados fue posible escribir programas mod-eradamente complejos de una forma bastante sencilla; sin embargo, us-ando incluso la programación estructurada, cuando los proyectos alcan-zan cierto tamaño, su complejidad se vuelve demasiado difícil para sercontrolada por un programador.

La POO toma las mejores ideas de la programación estructurada ylas combina con nuevos y poderosos conceptos que animan o alientan unanueva visión de la tarea de la programación.

77

Programación Orientada a Objetos 78

La POO permite descomponer fácilmente un problema en subgruposde partes relacionadas. Entonces, se puede traducir estos subgrupos enunidades autocontenidas llamadas objetos.

Las principales ventajas de utilizar la técnica de programación orien-tada a objeto son las siguientes:

• Los programas son más fáciles de modificar.

• Los programas son fáciles de mantener.

• El código desarrollado es mucho más portable y reutilizable quecon otros paradigmas.

Objeto

Un objeto es un conjunto constituido por una o varias variables y, op-cionalmente por métodos.

Un objeto es cualquier entidad lógica del mundo real que se puedaimaginar.

Objetos fisicos: Automóviles, aviones, animales mamíferos etc.

También se puede decir que tienen determiandas característica, ycomportamiento, ej. una casa.

Características: Número de pisos, altura total en metros, color de lafachada, número de ventanas, número de puertas, ciudad, calle y númerodonde está ubicada, etc.

Operaciones: Construir, destruir, pintar fachada, modificar algunade las características, como por ejemplo, abrir una nueva ventana, etc.

Evidentemente, cada objeto puede definirse en función de multitudde características y se pueden realizar innumerables operaciones sobre él.


Ya en términos de programación, será misión del programador deter-minar qué características y que operaciones interesa mantener sobre unobjeto. Por ejemplo, sobre el objeto casa puede no ser necesario conocersu ubicación y por lo tanto, dichas características no formarán parte delobjeto definido por el programador. Lo mismo podría decirse sobre lasoperaciones.

En terminología de programación orientada a objetos, a las caracterís-ticas del objeto se les denomina atributos y a las operaciones métodos (verfigura 5-1 de la pág. 79).

Cada uno de estos métodos es un procedimiento o una función pertenecientea un objeto.

Figura 5-1 Terminología de objetos.

Un objeto está formado por una serie de características o datos (atrib-utos) y una serie de operaciones (métodos). No puede concebirse única-mente en función de los datos o de las operaciones sino en su conjunto.

Clases y Objetos

En la POO hay que distinguir entre dos conceptos íntimamente ligados,la clase y el objeto.

De forma análoga a cómo se definen las variables en un lenguaje deprogramación, cuando se declara un objeto hay que definir el tipo de

objeto al que pertenece. Este tipo es la clase.

En C, se definen dos variables X e Y de tipo entero de la formasiguiente: int X,Y;.


En este caso, X e Y son variables, y el tipo de dichas variables esentero.

La forma de declarar objetos en Java es la misma:

Ccasa casa1, casa2

En este caso, casa1 y casa2 son efectivamente variables, pero untanto especiales, son objetos.

Además, el tipo de objetos es Ccasa. Este tipo es la clase del objetos.

Analogía

VARIABLE = OBJETO

TIPO = CLASE

Al declarar casa1 y casa2 como objetos pertenecientes a la claseCcasa, se está indicando que casa1 y casa2 tendrán una serie de atribu-tos (datos) como son nPuertas, nVentanas y color ; y, además, una seriede métodos (operaciones que se pueden realizar sobre ellos) como son:abrirVentanas(), cerrarVentanas(), etc.

Propiedades de un Lenguaje Orien-tado a Objetos

Las propiedades que debe cumplir un lenguaje para ser considerado OO(orientado a objetos) son las siguientes:

• Encapsulamiento.

• Herencia.

• Polimorfismo.


Encapsulamiento

El encapsulamiento consiste en la propiedad que tienen los objetos deocultar sus atributos, e incluso los métodos, a otras partes del programau otros objetos.

La forma natural de construir una clase es la de definir una seriede atributos que, en general, no son accesibles fuera del mismo objeto,sino que únicamente pueden modificarse a través de los métodos que sondefinidos como accesibles desde el exterior de esa clase.

class Ccasa {

int nPuertas, nVentanas;

String color;

public Ccasa(int np, int nv, String co) {

nPuertas=np;

nVentanas=nv;

color=co;

}

public void pintar(String co) {

color=co;

}

public void abrirVentanas(int n) {

nVentanas=nVentanas+n;

}

public void cerrarVentanas(int n) {

nVentanas=nVentanas-n;

if (nVentanas<0)


nVentanas=0;

}

public void abrirPuertas(int n) {

nPuertas=nPuertas+n;

}

public void cerrarPuertas(int n) {

nPuertas=nPuertas-n;

if (nPuertas<0)

nPuertas=0;

}

}

Ccasa casa1,casa2;

La forma normal de declarar la clase Ccasa consiste en definir unaserie de atributos no accesibles desde cualquier parte del programa, sinoúnicamente a través de determinados métodos. Así, si se quiere abrir unanueva ventana en la casa casa1, la filosofía tradicional de un programadorconsistiría en realizar lo siguiente:

casa1.N_VENTANAS := casa1.N_VENTANAS + 1;

Sin embargo, la forma natural de hacerlo en POO es llamando almétodo casa1.abrirVentanas(1). Ese método (procedimiento) se encar-gará de incrementar en 1 el atributo nVentanas. Esto no quiere decir queel atributo nVentanas no pueda ser accedido de la forma tradicional (sise hubiera definido como “public”) pero, para que el lenguaje pueda serconsiderado como OO, debe permitir la posibilidad de prohibir el accesoa los atributos directamente.


Herencia

Es una de las principales ventajas de la POO.

Esta propiedad permite definir clases descendientes de otras, de formaque la nueva clase (la clase descendiente) hereda de la clase antecesoratodos sus atributos y métodos.

La nueva clase puede definir nuevos atributos y métodos o inclusopuede redefinir atributos y métodos ya existentes (por ejemplo: cam-biar el tipo de un atributo o las operaciones que realiza un determinadométodo).

Es la forma natural de definir objetos en la vida real. La mayoría de lagente diría, por ejemplo, que un chalet es una casa con jardín. Tiene lasmismas características y propiedades u operaciones que pueden realizarsesobre una casa y, además, incorpora una nueva característica, el jardín.

En otras ocasiones, se añadirá funcionalidad (métodos) y no atrib-utos. Por ejemplo: un pato es un ave que nada. Mantiene las mismascaracterísticas que las aves y únicamente habría que declarar un métodosobre la nueva clase (el método nadar).

Esta propiedad permite la reutilización del código, siendo muy fácilaprovechar el código de clases ya existentes, modificándolas mínimamentepara adaptarlas a las nuevas especificaciones.

Ejemplo: Se supone que tenemos construida la clase Ccasa y quer-emos definir una nueva clase que represente a los chalets. En este casopuede ser conveniente definir un nuevo atributo que represente los met-ros cuadrados de jardín. En lugar de volver a definir una nueva clase“desde cero”, puede aprovecharse el código escrito para la clase Ccasa dela siguiente forma (ver además la figura 5-2 de la pág. 84):

class Cchalet extends Ccasa {

int mJardin;

public Cchalet(int np, int nv, String co, int nj) {

super(np,nv,co);


mJardin=nj;

}

}

Cchalet chalet1,chalet2;

Figura 5-2 Reutilización de objeto.

Como puede verse, únicamente hay que declarar que la nueva claseCchalet es descendiente de Ccasa (extends Ccasa) y declarar el nuevoatributo.

Evidentemente, el método constructor hay que redefinirlo para poderinicializar el nuevo atributomJardin. Pero los método para Abrir/Cerrarpuertas ventanas no es necesario definirlos, son heredados de la claseCcasa y pueden utilizarse, por ejemplo de la siguiente forma:

chalet1.pintar(”Blanco”);


Polimorfismo

El polimorfismo permite que un mismo mensaje enviado a objetos declases distintas haga que estos se comporten también de forma distinta(objetos distintos pueden tener métodos con el mismo nombre o inclusoun mismo objeto puede tener nombres de métodos idénticos pero condistintos parámetros). Por ej.:

class Ccasa {

public Ccasa(int np, int nv, String co) {

nPuertas=np;

nVentanas=nv;

color=co;

}

public Ccasa() {

nPuertas=0;

nVentanas=0;

color=“”;

}

Tiene dos métodos con el mismo nombre pero parámetros distintos.En el primer caso se inicializarán los atributos del objeto con los parámet-ros del método y en el segundo caso se inicializarán a cero, por ejemplo.

Además, si tenemos dos objetos casa1 y chalet1 y se llama al métodochalet1.abrirVentanas(2) se ejecutará el código del procedimiento abrir-Ventanas de la clase Cchalet y no de la clase Ccasa.

Lenguaje Java


Características Destacables del Lenguaje Java

Independencia en la Plataforma

Una de las razones más importante para utilizar Java, es la indepen-dencia de la plataforma.

Java se ejecuta en la mayor parte de plataformas de hardware y soft-

ware, entre las que se incluyenWindows 95, 98, NT, 2000, XP,Macintosh,

y varias gamas de UNIX.

Los navegadoresWeb compatibles con Java, como Netscape Navigator

e Internet Explorer, admiten los applets de Java.

Cambiando el software existente a Java, se podrá hacer inmediata-

mente compatibles estas plataformas de software. Sus programas serán

más portátiles y se eliminará toda dependencia con el sistema operativo.

Si bien C y C++ son compatibles en todas las plataformas com-

patibles con Java, estos lenguajes no son compatibles al margen de la

plataforma. Las aplicaciones en C y C++ que se implementan en una

plataforma de sistema operativo, por regla general se entrelazan demasi-

ado con el sistema nativo de ventanas y con las posibilidades de red

específicas del sistema operativo. El cambio de plataforma de sistema

operativo requiere como mínimo una recompilación, así como un redis-

eño importante en la mayoría de casos.

Orientación a Objetos

Java es un lenguaje verdaderamente orientado a objetos. No sólo

ofrece la posibilidad de implementar principios orientados a objetos, sino

que también pone en práctica tales principios.

Se pueden desarrollar programas orientados a objetos en C++, pero

no es necesario hacerlo; también se puede usar C++ para escribir pro-

gramas en C.

Java no permite salirse de la estructura orientada a objetos. O se

suscribe totalmente al enfoque del desarrollo orientado a objetos o no se

podrá programar en Java


Seguridad

Java es uno de los primeros lenguajes de programación que tiene en

cuenta la seguridad como parte de su diseño.

El lenguaje, el compilador, el intérprete y el entorno de tiempo de

ejecución de Java fueron desarrollados pensando en la seguridad.

El compilador, el intérprete, la API y los navegadores compatibles

con Java contienen todos ellos varios niveles de medidas de seguridad,

diseñados para reducir el riesgo del compromiso de seguridad, pérdida de

datos, integridad del programa y daños a los usuarios del sistema.

Características Varias

El lenguaje Java ofrece muchas características que lo hacen más atrac-

tivo que C o C++ para el desarrollo de software moderno.

Al principio de la lista nos encontramos con el soporte intrínseco de

Java al multihilo, lo cual falta tanto en C como enC++.

Otras características son sus posibilidades de manipulación de ex-cepciones, que fueron recientemente introducidas en C++, su adherencia

estricta al desarrollo de software orientado a clases y objetos, y su soporte

de recolección automática de basura.

Aparte de estas características, Java implementa un estilo de pro-

gramación común que elimina la posibilidad de salirse del paradigma de

programación orientado a clases y a objetos para desarrollar programas

orientados a funciones del tipo C.

La API Java

Las clases predefinidas de la API Java ofrecen una base conjunta e in-dependiente de la plataforma que se usa para el desarrollo de programas.

Estas clases ofrecen la posibilidad de desarrollar programas de ventana

y de red que se ejecutan en una amplia gama de hosts.

El soporte para la API Java, con la invocación remota de métodos,

conectividad de bases de datos y seguridad, no lo supera la API de ningún

otro lenguaje. Además, ningún otro lenguaje ofrece una potencia inde-


pendiente de la plataforma que se utilice como la API Java.

Su distribución ha recorrido un largo camino para dar soporte a

la computación totalmente distribuida con su soporte RML CORBA y

JDBC.

Estas API ofrecen la posibilidad de desarrollar e integrar objetos re-

motos en programas autónomos y aplicaciones Web basadas en applets.

Generación Rápida de Código

Dado que Java es un lenguaje de interpretación, se puede utilizar para

hacer rápidamente prototipos de aplicaciones que requerirían bastante

más soporte en lenguajes como C o C++.

La API Java también contribuye a la posibilidad de admitir la gen-

eración rápida de código. Las clases de la API Java ofrecen un receptáculo

integrado y fácil de utilizar para el desarrollo de software específico de la

aplicación.

Dado que la API Java ofrece soporte para ventanas de alto nivel, redes

y bases de datos, se pueden construir más rápidamente los prototipos

personalizados de aplicación teniendo estas clases como fundamento.

Facilidad de Documentación y Mantenimiento

En esencia, el software de Java se documenta automáticamente cuandose utilizan los comentarios doc y la herramienta javadoc para generar

documentación para el software.

La excelente documentación de la API Java constituye un ejemplo de

las posibilidades superiores de documentación que ofrece Java.

Dado que el software de Java está inherentemente mejor estructurado

y documentado que el de C o C++, por lo general es más fácil de

mantener. Aparte de esto, la orientación de paquete del software de

Java ofrece una modularidad considerable en el diseño, desarrollo, docu-

mentación y mantenimiento del software.

RMI (Remote Method Invocation o Invocación de MétodosRemotos)


Introducción

Al igual que con los RPC (Remote Procedure Call o Llamada a Pro-cedimientos Remotos) de C en Linux, es posible hacer que un programa

en Java llame a métodos de objetos que están instanciados en otro pro-

grama distinto, incluso que estén corriendo en otra máquina conectada

en red.

Estos métodos, aunque los llamemos desde este ordenador, se ejecutan

en el otro.

Este método tiene la ventaja de que si, por ejemplo, tenemos un orde-

nador capaz de realizar cuentas muy rápidamente y otro capaz de dibujar

gráficos maravillosos y además necesitamos hacer un programa con varias

cuentas y varios gráficos, podemos implementar en el ordenador de las

cuentas aquellas clases que calculan cuentas, en el ordenador de gráficos

aquellas clases de pintado y hacer que cada ordenador haga lo que mejor

puede hacer.

Cuando al hacer un gráfico necesitemos calcular cuentas, llamaremos

a la clase remota que hace las cuentas, y éstas se harán en el ordenador

de las cuentas, devolviendo el resultado al de los gráficos.

Las clases que se necesitan para configurar un RMI son las siguientes:

• InterfaceRemota: Es una interfaz Java con todos los métodos quese quiera poder invocar de forma remota, es decir, los métodos sellaman desde el cliente, pero se ejecutarán en el servidor.

• ObjetoRemoto: Es una clase con la implementación de los métodosde InterfaceRemota. A esta clase sólo la ve el servidor de rmi.

• ObjetoRemoto_Stubs: Es una clase que implementa InterfaceRe-

mota, cada método se encarga de hacer una llamada a través de lared al ObjetoRemoto del servidor, espera el resultado y lo retorna.Esta clase es la que ve el cliente y no necesita codificarla, Java lohace automáticamente a partir de ObjetoRemoto.

Política de Seguridad


Se precias también un archivo de política de seguridad. En estearchivo se indica al servidor de rmi y al cliente de rmi, qué conexionespueden o no establecerse. Debe haber un fichero de política de seguridaden el servidor de rmi y otro en el cliente.

En la pc/máquina servidor de rmi se debe correr dos programas:

• rmiregistry: Este es un programa que proporciona Java. Una vezarrancado, admite que se registren en él objetos para que puedanser invocados remotamente y admite peticiones de clientes paraejecutar métodos de estos objetos.

• Servidor : Este es un programa que se debe confeccionar. Se debeinstanciar el ObjetoRemoto y registrar en el rmiregistry. Una vezregistrado el ObjetoRemoto, el servidor no muere, sino que quedavivo. Cuando un cliente llame a un método de ObjetoRemoto, elcódigo de ese método se ejecutará en este proceso.

En la pc/máquina del cliente se debe correr el programa:

• Cliente: Este programa debe pedir al rmiregistry de la pc/máquinaservidor una referencia remota al ObjetoRemoto. Una vez que laconsigue (obtiene un ObjetoRemoto_Stbus), se pueden hacer lasllamadas a sus métodos. Los métodos se ejecutarán en el Servidor,pero el Cliente quedará bloqueado hasta que el Servidor terminede ejecutar el método.

Ejemplo: cómo realizar una operación suma en un objeto remoto.

La interface de la clase remota Hacer es una interfaz, con los métodosque se quiera, llamar remotamente. Esta interface sería como la se indicaen la figura 5-3 de la pág. 91.

Se tiene que heredar de la interface Remote de Java, si no el objetono será remoto. Se añade además los métodos que se quiera, pero todosdeben lanzar la excepción java.rmi.RemoteException, que se producirási hay algún problema con la comunicación entre los dos ordenadores ocualquier otro problema interno de rmi.


Figura 5-3 Interface para RMI.

Todos los parámetros y valores devueltos de estos métodos deben sertipos primitivos de Java o bien clases que implementen la interfaz Seri-

alizable de Java. De esta forma, tanto los parámetros como el resultadopodrán “viajar” por red del cliente al servidor y al revés.

El Objeto Remoto

Se debe hacer una clase que implemente esa InterfaceRemota, es decir,que tenga los métodos que se quiere llamar desde un cliente rmi.

El servidor de rmi se encargará de instanciar esta clase y de ponerlaa disposición de los clientes. Esa clase es la que se llama objeto remoto.

Esta clase remota debe implementar la interfaz remota que se hadefinido (y por tanto implementará también la interfaz Remote de Java),definir métodos como hashCode(), toString(), equals (), etc., de formaadecuada a un objeto remoto. También debe tener métodos que permitaobtener referencias remotas, etc.

La forma sencilla de hacer esto es hacer que la clase herede de Uni-

castRemoteObject.

El código sería similar al mostrado en la figura 5-4 de la pág. 92.

Otra opción es no hacerlo heredar de UnicastRemoteObject.

Una vez compilado se obtiene el fichero ObjetoRemoto.class, se nece-sita crear la “clase de stubs”.

Para que desde un programa en un ordenador se pueda llamar a unmétodo de una clase que está en otro ordenador, está claro que de alguna


Figura 5-4 Objeto remoto.

manera se debe enviar un mensaje por la red de un ordenador a otro,indicando que se quiere llamar a determinado método de determinadaclase y además pasar los parámetros de dicha llamada.

Una vez ejecutado el método, el ordenador que lo ha ejecutado debeenviar un mensaje con el resultado.

La clase de stubs es una clase con los mismos métodos que ObjetoRe-moto, pero en cada uno de esos métodos está codificado todo el tema delenvío del mensaje por la red y la recepción de la respuesta.

Afortunadamente para el programador, no se tiene que codificar todoeste problema de mensajes de ida y vuelta. Java proporciona una her-ramienta llamada rmic a la que se le pasa la clase ObjetoRemoto y de-vuelve la clase de stubs ObjetoRemoto_stubs.

Sólo se tiene que poner en la variable de entorno CLASSPATH eldirectorio en el que está la clase ObjetoRemoto y ejecutar rmic.

Además se tiene el archivo de política de seguridad, que se muestraen la figura 5-5 de la pág. 93.

Con este contenido, se dan todos los permisos a todo el mundo. Noes la opción más segura, pero de momento sirve.

También se puede cambiar la propiedad “java.security.policy” de lamanera indicada en la figura 5-6 de la pág. 93.

Una propiedad no es más que un nombre que lleva asociado un valor.


Figura 5-5 Permiso de seguridad.

Figura 5-6 Archivo de política de seguridad.

Así, por ejemplo, la propiedad “java.version” dice cuál es la versión deJava en la que está corriendo el programa, “os.name” devuelve el nombredel sistema operativo, “user.home” devuelve el directorio por defecto delusuario, etc.

System.getProperties() devuelve una lista de todas las propiedadesdisponibles. De hecho, en la API de Java, para este método, sale unalista con bastantes de las propiedades existentes.

System.setProperty() fija el valor para una propiedad y System. get

Property() permite obtener el valor de una propiedad.

Lanzar rmiregistry

Antes de registrar el objeto remoto, se debe lanzar desde una ventanade ms-dos o una shell de linux el programa rmiregistry. Este programaviene con Java y está en el directorio bin de donde se tenga instaladoJava.

Es importante borrar la variable CLASSPATH para que no tenganingún valor que permita encontrar nuestros objetos remotos, por lo quese aconseja eliminar antes de lanzar rmiregistry.

Si rmiregistry está en el PATH de búsqueda de ejecutables (o si seestá situado en el directorio en el que está), se lanzaría de la siguiente


manera indicada en la figura 5-7 de la pág. 94.

Figura 5-7 Lanzamiento de rmiregristry.

Además se debe poder indicar cuál es el path en el que se puedeencontrar la clase correspondiente al objeto remoto, en el ejemplo, elpath en el que se puede encontrar ObjetoRemoto.class.

Dicho path se da en formato URL, por lo que no admite espacios nicaracteres extraños.

Si se dejó las clases ObjetoRemoto.class, InterfaceRemota.class y Ob-

jetoRemoto_Stubs.class en c:\prueba_servidor, el path, en formato URL,sería como sigue “file://localhost/prueba_servidor”. En vez de localhostpuede ponerse la IP.

El código para indicar esto se muestra en la figura 5-8 de la pág. 94.

Figura 5-8 Indicación de la ubicación del código base.

Consiste en fijar una propiedad de nombre java.rmi.codebase con elpath donde se encuentran los ficheros .class remotos.

Se debe ver que haya un gestor de seguridad. Para ello se compruebasi existe y si no hay, se añade. El código para ello se muestra en la figura5-9 de la pág. 95.


Figura 5-9 Gestor de seguridad.

Para instanciar una clase remota y luego registrarla en el servidor de

rmi es suficiente el sencillo código que se muestra en la figura 5-10 de lapág. 95.

Figura 5-10 Instancia y registra un objeto en el servidor rmi.

La instanciación no tiene problemas. Para registrarla hay que lla-mar al método estático rebind() de la clase Naming. Se le pasan dosparámetros. Un nombre para poder identificar el objeto y una instanciadel objeto. El nombre que se ha dado debe conocerlo el cliente, paraluego poder pedir la instancia por el nombre.

El método rebind() registra el objeto. Si ya estuviera registrado, losustituye por el que se acaba de pasarle.

El Cliente de RMI

Ahora sólo se tiene que hacer el programa que utilice este objeto deforma remota.

Los pasos que debe realizar este programa son los siguientes:

Pedir el objeto remoto al servidor de rmi. El código para ello se indicaen la figura 5-11 de la pág. 96.

Se llama al método estático lookup() de la clase Naming. Se le pasaa este método la URL del objeto. Esa URL es el nombre (o IP) del


Figura 5-11 Solicitud de objeto remoto.

host donde está el servidor de rmi (en este caso localhost) y por últimoel nombre con el que se registró anteriormente el objeto (en el ejemploObjetoRemoto).

Este método devuelve un Remote, así que se debe hacer un “cast” aInterfaceRemota para poder utilizarlo. El objeto que se recibe aquí esrealmente un ObjetoRemoto_Stubs.

Se procede a llamar al método de suma() según se muestra en la figura5-12 de la pág. 96.

Figura 5-12 Llamado a un método.

Para que el código del cliente compile necesita ver en su classpath a In-terfaceRemota.class. Para que además se ejecute sin problemas necesitaademás ver a ObjetoRemoto_Stubs.class, por lo que estas clases debenestar accesibles desde el servidor o bien tener copias locales de ellas.

Socket

Pasos Para Crear un Servidor

Los pasos requeridos son los siguientes:

1. Crear el socket servidor.


2. Aceptar un cliente.

3. Obtener los InputStream y / o OutputStream del cliente.

4. Crear unos InputStream y / o OutputStream más adecuados a lasnecesidades.

5. Leer y escribir datos del y al cliente.

6. Cerrar el socket.

Crear el Socket Servidor

Para hacer el servidor en Java se teine la clase ServerSocket. Al instan-ciarla se usará el constructor al que se le pasa un número de servicio (depuerto).

Este número de puerto puede ser cualquier entero entre 1 y 65535.

Los números de 1 a 1023 están reservados para servicios del sistema(como ftp, mail, www, telnet, etc, etc).

Del 1024 en adelante se puede usarlos a gusto. Lo único es que nopuede haber dos servidores atendiendo al mismo puerto / servicio (verfigura 5-13 de la pág. 97).

Figura 5-13 Creación del socket servidor.

Aceptar un Cliente

Una vez creado el servidor, se le dice que empiece a atender conexionesde clientes.

Para ello se llama al método accept(). Este método se queda blo-queado hasta que algún cliente se conecta. Devuelve un socket, que es laconexión con dicho cliente (ver figura 5-14 de la pág. 98).


Figura 5-14 El servidor activa la atención a un cliente.

Se puede aceptar simultáneamente varios clientes, pero para atender-los se necesita programación multitarea o algo similar.

Obtener el InputStream y / o OutputStream

Ahora en cliente se tiene la conexión con el cliente (valga la redundancia).

Lo único que se tiene que hacer es obtener de él el OuputStream oInputStream con los métodos getOutputStream() o getInputStream().

La clase OutpuStream sirve para enviarle datos al cliente.

La clase InputStream sirve para leer datos del cliente (ver la figura5-15 de la pág. 98).

Figura 5-15 Lectura y envío de datos.

Crear unos InputStream y / o OutputStream Más

Adecuados a las Necesidades

Si se quiere enviar o recibir tipos normales (enteros, flotantes, strings) setiene las clases DataInputStream y DataOutputStream.

Estas clases tienen un constructor que admite un InputStream y unOutputStream respectivamente (ver la figura 5-16 de la pág. 99).


Figura 5-16 Objetos para recibir datos (enteros, flotantes, strings).

Si se quiere enviar o recibir clases enteras propias nuestras, se tienelas clases ObjectInputStream y ObjectDataStream.

Al igual que las anteriores, se usa el constructor que admite un In-putStream y un OutputStream (ver figura 5-17 de la pág. 99).

Figura 5-17 Objetos para recibir o enviar clases.

Estas nuevas clases tienen métodos como writeInt(), writeChar(), etc.

Leer y Escribir Datos Del y Al Cliente

Envio / lectura de datos normales (enteros, flotantes, strings)

El envío / lectura de datos normales se hace con las clases DataIn-putStream y DataOutputStream.

No tienen ningún truco especial, basta usar el método adecuado(writeInt(), writeFloat(), readInt(), etc).

Para strings se usan los métodos writeUTF () y readUTF (), que en-vían / leen las cadenas en formato UTF.

Envio / lectura de clases enteras

Para el envio / lectura de clases normales se usan los métodos read-Object() y writeObject() de ObjectInputStream y ObjectOutputStream.

Para poder usar estos métodos las clases deben implementar la inter-


face Serializable.

Las clases de tipos de Java (Integer, Float, String, etc.) implementanesa interface, así que se pueden enviar / leer a través de estos métodos.

Si una clase nuestra contiene atributos que sean primitivos de Java(int, float, etc) o clases primitivas (Float, Integer, String, etc.), bastacon hacer que implemente la interface Serializable para poder enviarlas.

No hace falta que se escriba ningún método, simplemente poner quese implementa (ver figura 5-18 de la pág. 100).

Figura 5-18 Implementa interface Serializable.

Si alguno de los atributos no es primitivo de Java, basta con queimplemente la misma interface Serializable.

Si es así, no se tendrá ningún problema (ver figura 5-19 de la pág.101).

Si alguna de las clases no es Serializable, se tendrán que implementarlos métodos privados (ver figura 5-20 de la pág. 101).

En el método writeObject() se debe enviar por el ObjectOutputStreamtodos los atributos de nuestra clase, en el orden que se considere ade-cuado.

En el método readObject() se debe ir leyendo del ObjectInputStreamtodos los atributos de nuestra clase e ir rellenando nuestros atributos.

El orden en que se lee debe ser el mismo que en el que se escribe y elformato leído el mismo que el escrito.


Figura 5-19 Implementa interface Serializable.

Figura 5-20 Define métodos privados.

Para enviar una de estas clases el código es sencillo (ver figura 5-21de la pág. 102).

Para leerlo es igual de simple, sólo que se tiene que saber qué tipo declase se está recibiendo para hacer el “cast” adecuado (ver figura 5-22 dela pág. 102).

Se debe ir haciendo varios if con las posibles clases que se nos envíendesde el otro lado.


Figura 5-21 Método WriteObjet.

Figura 5-22 Lectura de objetos por socket.

Cerrar el Socket

Para cerrar un socket hay que llamar a la función close() (ver figura 5-23de la pág. 102).

Figura 5-23 Cierre de una conexión cliente y servidor.

Pasos Para Crear un Cliente

Para el cliente se tiene la clase Socket.

Basta instanciarla indicándole contra qué máquina conectarse y elpuerto con el que debe conectarse.

Debe ser el mismo que el puerto que está atendiendo el servidor (verfigura 5-24 de la pág. 103).

El resto es igual que en el servidor.


Figura 5-24 Creación de una conexión cliente.

Los objetos SocketC.java, objMsg.java, objRem.java implementan losconceptos enunciado en este capítulo.

Parte II

Desarrollos Efectuados yConclusiones

104

Capítulo 6

Desarrollo del Producto

Introducción

En concordancia con los objetivos que propone esta Tesis, se elaborandos versiones del prototipo a los cuales el autor los denomina YOSUKOVersión 1.0 y YOSUKO Versión 2.0.

Las versiones del prototipo han sido elaboradas con diferentes técnicasde programación de Sistema Experto Basado en Reglas, con la finalidadde detectar en tiempo real el camino óptimo de comunicación de losdatos entre las computadoras que tienen la función de servir información(servidores) a las distintas computadoras conectadas a la red.

105

Desarrollo del Producto 106

Objetivos del Prototipo

Los objetivos perseguidos en la construcción del prototipo fueron lossiguientes:

• Utilizar software de bajo costo para la función de servir informa-ción entre las distintas máquinas que tienen el rol de servidoresconectadas a la red con tipología remota.

• Detectar la señal más estable para la transmisión de los datos.

• Detectar la ruta óptima de comunicación entre los servidores.

• Transmitir información al Sistema Gestor de Bases de Datos (My

SQL) desarrollado bajo la filosofía de código abierto que puede serutilizado gratuitamente. El lenguaje normalizado que se utilizapara llevar adelante esta comunicación con la base de datos es elStructured Query Language (SQL), que no es más que un lenguajeestándar de comunicación con bases de datos.

• Integrar aplicaciones informáticas construidas en la década de los’70 con las aplicaciones de última generación, utilizando un proced-imiento lógico que las comunica.

Estudio Comparativo de Ambas Ver-siones del Prototipo

El estudio comparativo permite resumir lo siguiente:

• YOSUKO Ver. 1.0: Se construyó como simulador del objetivo,fue construido con un procedimiento lógico que integra el lenguaje


de programación orientado a objetos “Java” con el lenguaje de pro-gramación procedural “Clipper 5.2”. El potencial de esta versiónradica en la utilización de la técnica de programación que se utilizapara la confección del Motor de Inferencia, la regla Modus Ponensy estrategias de inferencias Encadenamiento de Reglas, la cual serepresenta en la sintaxis como “&”, ejemplo: if &reglas (Ver archivofuente Lectorre.prg).

• YOSUKO Ver 2.0: Es el producto final, que se detalla en formacompleta durante el desarrollo de este capítulo.

Los objetivos generales de la Tesis rigen el desarrollo de cada versióndel prototipo, con la premisa de encontrar la mejor solución para elplanteamiento del problema.

A continuación se detalla el funcionamiento del protocolo YOSUKOV2.0, donde se visualiza la diferencia de versiones del prototipo, desta-cando las técnicas de programación utilizadas.

Protocolo YOSUKO V. 2.0.

Introducción

Esta versión del prototipo está desarrollada totalmente con el lenguajede programación Java, utilizando los conceptos vistos en el capítulo 3:

• Programación con el modelo de Sockets, como un mecanismo decomunicación entre procesos.

• Protocolo TCP/IP.

• Programación RMI.

• Conexión al motor de base de datos MySQL, por medio del lenguajeestándar de comunicación SQL.


• Lectura y grabación de archivos binarios.

Planteo del Problema

El problema estudiado se puede resumir con el siguiente planteo:

1. La mayoría de las aplicaciones informáticas comerciales dela provincia de Misiones se encuentran programadas con tec-nologías que carecen de la capacidad de utilizar comunicaciónsobre protocolos de red TCP/IP, sintaxis del lenguaje están-dar SQL, programación con el modelo de Sockets, Gestor deBases de Datos, entre otros, debido a que el lenguaje de pro-gramación utilizado para la construcción de las aplicacionesno está diseñado para la comunicación entre cliente / servidorque requiere la época actual. Este hecho, exige al programadoremigrar a otros lenguajes de programación de última gen-eración que contemplen mayores funcionamientos, situaciónque implica costo en la licencia del software, reprogramacióndel sistema de información, capacitación del recurso humano,modernización de la infraestructura tecnológica, etc.

2. Hoy en día las empresas deben ser competitivas, la informa-ción debe estar a disposición en cualquier parte del mundolas 24 hs., a disponibilidad de los directivos de las mismas.Situación que conlleva a estar conectado a un motor de Basede Datos, disponer de aplicaciones informáticas que accedana la información en tiempo real.

Estudio de Factibilidad para Brindar una Solución al

Problema

Los aspectos más relevantes son los siguientes:

• Los sistemas operativosWindows 9“x” o superior y Linux Ver. “x”,han creado un método de conexión a través de la red de Internet,


que crea el efecto de un túnel, a través del cual la información setransmite en forma segura, denominado Red Privada Virtual, Vir-tual Private Networks (VPN ), permitiendo a las aplicaciones quese ejecuten en una Intranet a través de la red Internet. El riesgode este método de conexión se presenta cuando la comunicaciónes inestable, existiendo la posibilidad de corromper los archivos.Otra debilidad que presenta es en el momento de ejecutar una apli-cación informática que no sea de arquitectura cliente / servidor, yaque produce lentitud en el funcionamiento del sistema operativo,ocasionando conflicto en la red de comunicaciones.

• Otra solución que se le presenta al programador de aplicaciones, esutilizar programas de control remoto, por ejemplo VNC que sonlas siglas en inglés de Virtual Network Computing (Computación

en Red Virtual), o el pcAnywhere, entre otros, que están basados enuna estructura cliente / servidor, la cual permite tomar el control dela computadora servidor remotamente a través de una computadoracliente; el inconveniente que presenta esta solución es que el controldel teclado o del mouse (ratón) es mono usuario.

• Otra opción que se presenta como alternativa, es ejecutar unasesión remota, utilizando el sistema operativo Linux que es unode los paradigmas del desarrollo de software libre (y de códigoabierto), con el inconveniente de que su funcionamiento se vuelvelento cuando la comunicación es inestable.

Conclusión del Estudio de Factibilidad

Como conclusión del estudio de soluciones posibles para resolver el prob-lema formulado, se presentan dos métodos:

• Servidor Centralizado.

• Servidor Descentralizado.


Desarrollo de la Experiencia

Para desarrollar el protocolo que propone esta Tesis, y mostrar una solu-ción factible a los problemas mencionados, así como los beneficios de tenerservidores descentralizados a nivel de costo, balanceo de carga, etc., setoma como ejemplo experimental una empresa de transporte de pasajerosde larga distancia de la ciudad de Posadas, provincia de Misiones, te-niendo en cuenta que la información de disponibilidad de asientos debeestar en tiempo real, y centralizada.

Cliente: Empresa de transporte de pasajero de larga distancia de laciudad de Posadas, provincia de Misiones.

Problema: Resolver las ventas de boletos en tiempo real, teniendo encuenta que posee Puntos de Ventas en Chile, Paraguay, Brasil, Argentina.

Análisis del Método de Resolución con Servidor Centralizado

Fortaleza: La información depende de una sola central.

Debilidad: Todos los puntos que poseen grandes movimientos de ven-tas deben tener conexiones punto a punto, estables y eficientes, teniendoen cuenta que la caída de los enlaces de comunicación representa pé rdidade dinero para la empresa. El costo aproximado de un enlace punto apunto en la Argentina por punto de venta es de $ 4.500 Acceso Frame

Relay (desde 64 K a 2 Mb). Si se tiene en cuenta que las boleteríasestán en países limítrofes, requieren utilizar comunicación internacional,la única opción en línea estable a niveles de enlace es el Acceso Satelital

(desde 128 K hasta 512 K), con un costo de $ 1.500 por punto.

Análisis del Costo de un Servidor Centralizado

Debido a que la información debe estar centralizada, el servidor debetener la capacidad de soportar las solicitudes de los puntos remotos deventas (balanceo de carga), y los ataques de intrusos.

Se requiere de un servicio de recuperación del servidor en caso decaída, y demanda que las aplicaciones informáticas sean construídas conestructura cliente / servidor, y sistema gestor de bases de datos.


A modo ilustrativo se adjunta un presupuesto de Infraestructura Tec-nológica con un requerimiento mínimo (ver figura 6-1 de la pág. 111.

Figura 6-1 Presupuesto de servidor.

A su vez, el presupuesto del Sistema Gestor de Bases de Datos SQLServer asciende a un monto de $ 8.000.

Costo total de un servidor centralizado con los accesorios

que se detallan: $26.887,40.

Análisis del Método de Resolución con Servidores Descentral-

izados

Fortaleza: Los principales aspectos son los siguientes:

• Optimiza el balanceo de carga, porque se distribuye la información.


• La empresa no depende de la comunicación, dado que los servidorescentrales se encuentra en los puntos de venta con mayor demandade pasajes, es decir una central en Chile, Paraguay, Argentina yBrasil.

• Utiliza aplicaciones de legado (legacy) desarrolladas en la décadade los ’70, esto implica el requerimiento de servidores de bajo costo.

Debilidad: Los principales puntos son los siguientes:

• Demanda mantenimiento de la información.

• Demanda mantenimiento de los servidores.

• Si el sistema de venta estuviera automatizado a través de aplica-tivos informáticos desarrollados con un lenguaje de programaciónde última generación que requiere de motor de base de datos, notendría sentido este método por el costo que demanda por servidor,aproximadamente $26.887,40.

Análisis del Costo de un Servidor Descentralizado

Con una aplicación informática desarrollada con un lenguaje de pro-gramación no de última generación, no se requiere utilizar un SistemaGestor de Bases de Datos, como así también un servidor con las carac-terísticas que se describen en el análisis de costos del Método de Resolu-ción con Servidor Centralizado, tratado en el apartado anterior.

Por lo tanto, con un servidor de muy bajos requerimientos, se puedenimplementar aplicaciones informáticas, dando solución al problema for-mulado en el enunciado de la experiencia.

Costo Aproximado y Especificaciones Técnicas

1 Placa Materborad Standar.

2 Discos de 80 GB.

1 Banco de memoria de 1 GB.


1 Micro procesador tipo Intel 2.3 Ghz.

1 Disquetera.

1 Grabadora de DVD.

1 Monitor de 17 pulgadas.

El costo total aproximado es de $2.000.

El costo aproximado de la UPS es de $1.500.

Costo total del equipamiento: $3.500.

Análisis de Costo por Tipos de Enlaces de Comunicación

Se utiliza la Lista de Precios de proveedores locales de la ciudad dePosadas, Misiones, Argentina, para observar los valores que tiene cadatipo de conexión:

• Comunicación a través de Módem (máxima velocidad de trans-misión: 56 K): $25,00.

• ADSL (máxima velocidad de transmisión: 5 Mb): $350,00.

• Acceso Frame Relay (desde 64 K a 2 Mb): $4.500,00.

• Acceso Satelital (desde 128 K hasta 512 K): $1.500,00.

Teniendo en cuenta que el protocolo YOSUKO V. 2.0 se desarrollócon la premisa de funcionar con comunicaciones inestables, de bajo

costo, se va a utilizar el segundo método de resolución propuesto.

Planteo de Base

Se parte de la hipótesis que existen tres centrales y dos proveedoresde comunicación por punto, los cuales utilizan comunicación ADSL conun costo de $ 350,00.

Objetivo: Detectar el mejor camino.

Cada servidor tiene dos salidas de comunicación: “CPA” (Comuni-cación Proveedor A) y “CPB” (Comunicación Proveedor B).


Existen tres servidores A-B-C (MAQUINA A (Posadas), MAQUINAB (Retiro), MAQUINA C (Neuquén) (ver figura 6-2 de la pág. 114).

Figura 6-2 Costo de la comunicación.

El Servidor Máquina “A” Solicita Información al Servidor Máquina

“C”.

Caminos posibles:

• CAMA + CAMD.

• CAMC + CAMB.

• CAMA + CAMB.

• CAMC + CAMD.

• CAME.

En la introducción de la Tesis, se menciona que el protocoloYOSUKOdebe estar programado en lenguaje Java, y utilizar un Sistema Experto

Basado en Reglas.


Arquitectura Utilizada para Desarrollar el Protocolo

La arquitectura se muestra en la figura 6-3 de la pág. 115.

Figura 6-3 Arquitectura utilizada para el sistema experto.

Base de Conocimiento Yosuko V 1.0.

Reglas de Inferencia: Generadas por el Experto o Ingeniero del Conocimiento.

Se parte de un ejemplo con la finalidad de observar cómo se generala base del conocimiento.

El servidor “A” solicita información al servidor “C” (también esaplicable al caso en que el servidor “C” solicita información al servidor“A”).

Caso 1 : Un pasajero quiere viajar de Posadas a Neuquén, o Neuquéna Posadas.

(CAMA + CAMB) < (CAMC + CAMD) AND (CAMA + CAMB) <CAME ME VOY POR CAMA + CAMB.


(CAMA + CAMD) < (CAMB + CAMC) AND (CAMA + CAMD) <CAME ME VOY POR CAMA + CAMD.

(CAMB + CAMC) < (CAMA + CAMD) AND (CAMB + CAMC) <CAME ME VOY POR CAMB + CAMC.

(CAMC + CAMD) < (CAMA + CAMB) AND (CAMC + CAMD) <CAME ME VOY POR CAMC + CAMD.

(CAME < (CAMA + CAMB)) AND (CAME < (CAMC + CAMD))ME VOY POR CAME.

El servidor “A” solicita información al servidor “B” (aplicable al casoen que el servidor “B” solicita al servidor “A”).

Caso 2 : Un pasajero quiere viajar de Posadas a Retiro, o de Retiro aPosadas.

CAMA < CAMC AND CAMA < (CAME + CAMB) AND CAMA <(CAMD + CAME) ME VOY POR CAMA.

CAMC < CAMA AND CAMC < (CAME + CAMB) AND CAMC <(CAMD + CAME) ME VOY POR CAMC.

(CAME + CAMB) < CAMA AND (CAME + CAMB) < CAMC AND(CAME + CAMB) < (CAME + CAMD) ME VOY POR CAME+ CAMB.

(CAME + CAMD) < CAMA AND (CAME + CAMD) < CAMC AND(CAME + CAMD) < (CAME + CAMB) ME VOY POR CAME+ CAMD.

El servidor “B” solicita información al servidor “C” (aplicable al casoen que el servidor “C” solicita al servidor “B”).

Caso 3 : Un pasajero quiere viajar de Retiro a Neuquén, o de Neuquéna Retiro.

CAMB < CAMD AND CAMB < (CAMA + CAME) AND CAMB <(CAMC + CAME) ME VOY POR CAMB.


CAMD < CAMB AND CAMD < (CAMA + CAME) AND CAMD <(CAMC + CAME) ME VOY POR CAMD.

Nota: Los campos CAMA, CAMB , CAMC y CAMD contienen elpromedio del tiempo exacto que tardan los paquetes de datos en ir yvolver a través de la red, desde un Servidor a otro Servidor al cual el autordenomina Tiempo Promedio de Respuesta (TPR); elMotor de Inferencia

toma estos valores, analiza las reglas y obtiene el menor tiempo, con locual establece el mejor camino.

Almacenamiento de las Reglas

Para tomar la decisión, y decidir la programación delMotor de Inferencia,se desarrolla tres métodos de configuración de reglas.

Almacenamiento de Reglas YOSUKO V1.0. (Método 1)

La estructura del archivo donde se almacenan las reglas del protocoloYOSUKO V1.0. se muestra en la figura 6-4 de la pág. 117.

Figura 6-4 Estructura del almacenamiento de las reglas.


El archivo en el que se graba el conocimiento o reglas se muestra enla figura 6-5 de la pág. 118.

Figura 6-5 Archivo de reglas.

Debilidades del Primer Método de Resolución

Las principales debilidades se señalan a continuación:

— El Experto o Ingeniero del Conocimiento, debe generar lasreglas.

— Si el lenguaje de programación no tiene el comando “&” (porejemplo: “If &reglas”), no se podría programar el algoritmo,tal como se observa en la figura 6-6 de la pág. 119, y se ten-drían que agregar internamente las reglas dentro del lenguaje.De esta manera, el costo que demandaría generar el conocimientosería muy alto, y sería difícil mantenerlo.

• El acceso a la información es secuencial.

Almacenamiento de Reglas YOSUKO V2.0. (Método 2)


Figura 6-6 Algoritmo del motor de inferencia de YOSUKO V.1.0.

Teniendo en cuenta los problemas de la versión anterior, y el objetivode encontrar el Motor de Inferencia más eficiente, se desarrollan 2 (dos)métodos:

• Reglas de encadenamiento.

• Grafos completos (Matriz de Adyacencia).

Generación de Reglas por Medio del Método Encadenamiento

de Reglas

Se parte del supuesto que se cuenta con un objeto Java en todos los nodosactivos del sistema, el cual tiene por objetivo informar a todos los nodosque se encuentran en la tabla de nodos activos el valor (TPR), hora,minuto, segundo. Esta información sirve al nodo emisor para analizar sihay comunicación con el nodo destino, cuando va a transmitir los datos.

Proceso Para Transmitir

El proceso realizado para transmitir se detalla a continuación:


• Por primera vez se carga en memoria el nodo inicial, con todas lasdirecciones IP, que van a existir en la red (ver la Tabla de NodosHabilitados en la figura 6-7 de la pág. 120, archivo Nodos.dat).

Figura 6-7 Archivo de nodos.

• Se ejecuta el proceso de informar la dirección IP a todos los nodosque conforman el sistema.

• Una vez que todos los nodos tienen grabada la tabla de direccionesIP, se puede ejecutar el objeto aprender las rutas posibles (encade-namiento de reglas), para llegar a todos los nodos; esto significaque se realizan dos procesos:

Proceso 1 (Generar el Primer Camino):

1. Lee la tabla de nodos activos.

2. Conecta al nodo destino, por medio de la programación a travésdel modelo Socket utilizando el puerto XXXX.

3. Verifica si existe el nodo destino, caso afirmativo se transmite elregistro según diseño de la figura 6-8 de la pág. 122.

4. Se graba en el campo reglas la IP del nodo origen. En este campose registran todos los nodos que el archivo recorrió para llegar alnodo destino. También se lo denomina a este campo IP del quepide.

5. Termina el proceso (generar la primera ruta alternativa).


6. El nodo destino lee el archivo contenedor de reglas (ver figura 6-8de la pág. 122), extrae del campo reglas la IP (IP del que pide).Ejecuta el comando Ping a la IP que se extrajo, calcula el promedio(TPR), transmite ese valor a la IP que se hizo el cálculo.

Proceso 2 (Generar Otro Camino Alternativo):

1. El nodo origen toma la siguiente IP, que está en la tabla nodos (verfigura 6-7 de la pág. 120).

2. Transmite el registro (paquete), según diseño de la figura 6-8 de lapág. 122, a la IP seleccionada.

3. Recibe el paquete la IP seleccionada.

4. Analiza el nodo destino. En caso que no sea igual al nodo destino,realiza el siguiente proceso:

(a) Toma la IP destino que está grabado en el registro que recibió.

(b) Transmite ese pedido al nodo destino, previa alteración campoReglas (IP del que pide), agregando en dicho campo la IP delnodo que transmite.

5. Una vez que el pedido llegó al nodo destino, éste le transmite alnodo origen el registro según diseño de la figura 6-8 de la pág. 122.Concluido el proceso, el nodo destino lee el archivo contenedor dereglas (ver figura 6-8 de la pág. 122), extrae del campo reglas la IP(IP del que pide). Ejecuta el comando Ping a la IP que se extrajo,calcula el promedio (TPR), transmite ese valor a la IP que se hizoel cálculo.

A continuación se muestra un ejemplo:

Dados cuatro nodos IP 1.1 , 1.2 , 1.3 , 1.4, se generan las rutas posiblesentre los nodos 1.1 y 1.3.

Regla No. 1


Figura 6-8 Archivo contenedor de reglas.

Figura 6-9 Regla 1 del ejemplo.

Ver la figura 6-9 de la pág. 122.

Regla No. 2


Regla No. 3


Regla No. 4


Para confeccionar la regla, se realiza el siguiente proceso: el nodo 1.2




envía al nodo 1.4, el nodo 1.4 envía al nodo 1.3.


Regla No. 5


Para confeccionar la regla, se realiza el siguiente proceso: el nodo 1.4envía al nodo 1.2, el nodo 1.2 envía al nodo 1.3.

Se definen reglas coherentes, estableciendo ciertas restricciones.

No se puede pedir a la IP, que esté, en el campo reglas (del quepide); ejemplo: El nodo 1.4, no envía (paquete) al nodo 1.2, porque la



IP 1.2 está en el campo reglas (IP del que pide). Si no se establece estarestricción, entraría en un ciclo repetitivo, entre el nodo 1.2 y el nodo1.4.

Terminado el proceso y respetada la restricción, se transmite el archivocontenedor de reglas, al nodo origen.

Pasos Para Calcular el Valor TPR Los pasos son los siguientes:

• Se ejecuta el comando Ping.

• Selecciona y suma el valor de los tiempos exactos que tardan lospaquetes de datos en ir y volver a través de la red, desde un Servidora otro Servidor (promedio).

• Divide por 4 (se tomó 4 muestra).

El valor obtenido se denomina TPR.

En el caso de que uno de los valores diga tiempo espera agotado,

se penaliza con un valor alto (1000), cosa que el promedio de IPsea el mayor.

Pasos para Transmitir el Promedio de IP Se toma la última IPque se encuentra en el campo reglas (del que pide), y se transmite el TPR(promedio).

A continuación, se observa un ejemplo analizando la cuarta regla:


• El Nodo 1.3 mira la regla No. 4.

• Saca la última IP, en este caso es 1.4.

• Hace un Ping a 1.4.

• Calcula el TPR (promedio) contra ese punto.

• Transmite el promedio.

• El nodo IP 1.4 recibe ese valor y graba en el campo fecha-hora-min.seg. que recibió el pedido (se considera la fecha-hora del servi-dor que recibe el pedido, porque hay que considerar que los servi-dores pueden tener diferencias horarias). Este dato es muy impor-tante, para determinar si la comunicación es reciente.

• El Nodo 1.4 analiza el campo IP origen (1.1).

• EL Nodo 1.4 es distinto al origen (1.1).

• Toma la IP del campo Reglas (del que pide), teniendo en cuentaque debe ser la IP que se encuentra detrás del nodo que analiza(1.4), en este ejemplo es 1.2.

• Hace Ping a 1.2. y calcula TPR.

• Acumula el valor anterior, más el nuevo valor, y transmite al nodo1.2.

• El Nodo 1.2 analiza el campo IP origen (1.1).

• El Nodo 1.2 es distinto al origen (1.1).

• Toma la IP del campo Reglas (el que pide), teniendo en cuenta quedebe ser la IP que se encuentra detrás del nodo que analiza(1.2),en este caso es 1.1.

• Hace Ping a 1.1. y calcula TPR.

• Acumula y le transmite al nodo 1.1.

• El nodo 1.1 detecta que es igual a la IP origen, toma el valor recibidoy actualiza el campo TPR de la regla No. 4.


• Termina el proceso.

Pasos Para Calcular el Promedio de IP Los pasos se detallanseguidamente.

• Se Ejecuta el comando Ping.

• Se extraen los valores de medición (ver figura 6-14 de la pág. 126).

1.

Figura 6-14 Cálculo de ping modelo 1.

Pedidos de la Aplicación Externa al Nodo 1.1.

El nodo 1.1 recibe un pedido de una aplicación externa que necesitatransmitir un archivo al nodo 1.3.; para detectar el mejor camino, realizael siguiente proceso:

• Abre el Archivo Reglas.dat.

• Selecciona todas las Reglas (camino) que tienen IP destino 1.3.

• Busca el menor valor del campo TPR.

• Saca el camino del campo regla (el que pide) y transmite el archivoen esa secuencia.


Grafos Completos (Matriz de Adyacencia)

En la versión YOSUKO V.2. se utiliza técnica de grafos completo nodirigido, y se carga el TPR (promedio) en una matriz de adyacencia.

Se configura una matriz de 100 nodos como máximo en el objetoSocketC.java, permitiendo a este protocolo escuchar 100 direcciones IP.

String Des [] = new String [100]; // Descripción de los Nodos

String Puertos[] = new String [100]; // Puerto de los Nodos

String IP [] = new String [100]; // IP de los Nodos

Float Ping [][] = new Float [100][100]; // Matriz con los valores TPR

Generación de Reglas Se generan las reglas en el objeto ABMNo-dos.java, en el evento (botón) crear reglas cmdCrearR_Click(int Nivel).

Criterio Para Generar las Reglas Dados cuatro nodos: 1,2,3,4, serealizan todas las combinaciones posibles de ese número (rutas posibles),en el nodo que ejecutó el evento. Ejemplos: 1000, 1001, 1002, 1003, 1100,etc., 2000, 2001, –— ,2223, etc.

Control de Coherencia Para que sea un Nodo Válido Las condi-ciones que se deben cumplir para que una ruta sea válida son las sigu-ientes:

• Debe existir un nodo origen y un nodo destino, al principio de lacombinación, (se guarda, en la posición 1 y 2 del vector Regla), sialgunos de estos lugares esta vacío (0), se descarta la regla. Ej:1200 correcto, 1030: incorrecto, 1000: incorrecto.

• Verificar que no exista un cero después del último número mayor acero de la combinación. Ej.: 1200 correcto, 1201: incorrecto, 1302incorrecto, 1340 correcto.


• Verificar que no se repita un nodo en toda la regla. Ej.: 1230correcto, 1321: incorrecto, 2123: incorrecto.

• Una vez generadas todas las reglas, de todos los nodos, se grabanen el archivo reglas.txt.

Nota: El único que tiene derecho a modificar o borrar reglas, en esteobjeto, es el servidor, los nodos clientes sólo tienen derecho a generarlas reglas. A este proceso se hace referencia en el manual del usuarioYOSUKO V2.0.

Ventajas del Algoritmo Utilizado Las ventajas se pueden resumircomo sigue:

• Muy fácil de programar, se mantiene la información en memoria.

• La cantidad de nodos depende de la cantidad de memoria disponibleen el procesador de cada aplicación.

• El acceso es directo, para detectar el mejor camino sobre la matriz,únicamente hay que ingresar el nodo origen, y el nodo destino.

Procedimiento Para Calcular el Promedio de IP El procedimientoes el siguiente:

• Se Ejecuta el comando Ping.

• Se selecciona el valor TPR (promedio), que viene incorporado enel comando Ping (ver figura 6-15 de la pág. 129).

Para seleccionar el promedio, el algoritmo busca la palabra “ms”, yextrae el número.

Se observa que cuando uno de los valores exprese “tiempo esperaagotado”, el promedio aumenta.


Figura 6-15 Cálculo TPR segundo método.

Ahora, en el caso de que no haya comunicación, la sigla “ms” noaparece, entonces se penaliza con un valor alto (1000), con el propósitode que el promedio de IP sea el mayor.

Procedimiento Para Transmitir el Promedio de IP El métodoque se utiliza es de un grafo completo no dirigido (ver figura 6-16 de lapág. 130), es decir todos los nodos del sistema YOSUKO V.2., hacenping contra todos los nodos leyendo la tabla nodos.dat.

El Nodo “X”, captura la respuesta del Ping extrayendo elTPR (prome-dio), y graba en laMatriz ; se considera el nodo origen como fila y el nododestino como columna M (Origen,Destino).

El nodo origen toma el valor TPR (promedio), e informa a todos losnodos de la red. El beneficio con este método, es que, cualquier nodode la red conoce el estado de toda la red de cualquier nodo, en todomomento.


Figura 6-16 Grafo completo no dirigido.

Estudio Comparativo Entre los dos Métodos de Resolución

Se llega a la conclusión de que el segundo método es mejor, por lassiguientes razones:

Calculo de IP: Las consideraciones son las siguientes:

• El cálculo del promedio en el segundo método lo hace el comandoPing, en cambio en el primer método lo hace la aplicación.

• En el caso de que el comando Ping cambie la forma de presentarlos datos, el primer método requiere que se reprograme la rutinade cálculo TPR.

• En cambio utilizando el segundo método, únicamente se deberáreprogramar, si no aparece la palabra “ms”.

Generación de Reglas: Las consideraciones son las siguientes:

• El segundo método es más fácil de programar.


• En el primer método se debe tener en cuenta que puede caer algúnnodo, cuando está generando las reglas, y no se percibirá si le faltanalgunas de ellas. En cambio el segundo método genera las reglasen forma local, y no depende de la comunicación.

• En el segundo método, todas las reglas de todos los nodos estánen cada nodo, en cambio en el primer método se encuentran única-mente las reglas de ese nodo.

Transmición del Promedio de TRP para las IP: Las consideracionesson las siguientes:

• El primer método tiene la desventaja de que debe transmitir alnodo destino por cada regla que tiene en el archivo contenedor dereglas; es decir, N reglas x N nodos.

• En cambio, el segundo método únicamente transmite 1 x cantidadde nodos; por lo tanto es más eficiente el segundo método cuantomayor es el número de nodos.

Conclusión

El estudio comparativo de los métodos de resolución propuestos lleva a lasiguiente conclusión: el protocolo YOSUKO V.2.0 se basará en el métodoGrafo completo no dirigido (Matriz de adyacencia).

Capítulo 7

Seguridad a Nivel de Informa-ción

Introducción

Existen varios factores a la hora de evaluar la seguridad de un sistema.A continuación se resumirán algunos conceptos:

• Confidencialidad: La información sólo ha de poder ser accedidapor las personas autorizadas. Puede ser de datos (protegiéndolospor encriptación), o confidencialidad de flujo (en la que se trata deocultar quién es el destinatario).

• Integridad: Se necesita saber que los datos recibidos no han podidoser modificados por alguien distinto del emisor. Además la integri-dad de secuencia asegura que los bloques de información recibidahan llegado en el orden en que fueron enviados.

132

Seguridad a Nivel de Información 133

• No repudio: Herramienta que permite probar que se tuvo una co-municación con un determinado usuario, de modo que alguien nopueda negar el haber recibido algo, ni otro pueda negar haber man-dado algo. Esto se suele conseguir con la firma digital.

• Control de acceso: Los sistemas deben estar protegidos, de modoque sólo pueda acceder a sus recursos la persona autorizada. Estose consigue mediante passwords (contraseñas).

• Seguridad física: Los soportes físicos de un sistema deben estar pro-tegidos de descargas, incendios, acceso de personas no autorizadas.

• Autentificación: Se trata de poder saber si algo es de quien dice ser,si algo no ha sido falsificado. Se suelen usar mecanismos asimétricoscomo la firma digital.

Teniendo en cuenta los conceptos de seguridad, se estableció en elprotocoloYOSUKO V2.0., la Seguridad Control de Acceso, y la Seguridadde Confidencialidad.

Se organizó de la siguiente forma:

• A Nivel de Aplicación.

• Cuando se Transmite la Información.

• A Nivel Usuarios.

Seguridad Nivel de Aplicación

El objetivo de este módulo es controlar la piratería del software, para

ello, se estableció, como medida de seguridad, el siguiente esquema de

trabajo:

• Tener una licencia, que habilite a cada servidor de nodos instalado.

• Registrar el producto, cuando se instala por primera vez.


Pasos Para Registrar el Producto

El producto se encuentra comprimido, en una la carpeta que se denomina

YOSUKO.

Se debe ejecutar el botón instalar, y cargar los datos que solicita la

figura 8-8 de la pág. 158.

Figura 7-1 Pantalla donde se registra el producto.

Una vez concluida esta operación, el sistema YOSUKO se conecta

con el proveedor, que generó el producto, para registrar, verificar si es

válido, y que no esté duplicado el registro del producto, a través de una

conexión SQL.

Una vez que se comprobó la validez, internamente, el sistemaYOSUKO,

con los datos ingresados genera un registro, en el archivo control.dat.

Este método permite controlar que la aplicación esté registrada una

sola vez.


Seguridad Cuando se Transmite la Información

Este módulo tiene por objetivo verificar si la información transmitida es

de un nodo válido, activado por la aplicación.

Se utiliza el método de comparación entre dos puntos, por medio de

un valor denominado dígito verificador.

Dígito Verificador

Seguidamente se detalla cómo funciona el control.

Ejemplo: Dados dos nodos A,B, el nodo A transmite una informaciónal nodo B y realiza el siguiente proceso:

• El nodo A toma su IP y calcula el dígito verificador de la siguienteforma:

— Multiplica por 3 cada número que conforma el IP.

— Acumula el valor del producto.

— El resultado final del producto acumulado se divide por 11.

— El algoritmo se encuentra programado en el objeto socketC.java(),clase CalcDV():

∗ // Esta rutina devuelve como resultado un número, quese va a usar como dígito verificador

∗ // entre los paquetes de transmisión.

∗ public int CalcDV (String strIP) {

∗ // Recibe como parámetro la IP de la máquina y la con-vierte en un array de bytes,

∗ // para luego poder procesarlos.

∗ byte IP[] = strIP.getBytes();

∗ int i;

∗ int dv = 0;

∗ // Realiza un bucle por todos los elementos del array (IP),lo multiplica * 3


∗ // y acumula sus valores en la variable dv.

∗ for (i=0; i<10; i++) dv+=IP[i] * 3;

∗ // Luego la sumatoria se divide por 11 y termina el pro-ceso.

∗ dv/=11;

∗ return dv;

∗ }

∗ //––––––––––––––––––––

— Inserta en el registro a transmitir el dígito verificador.

• El nodo B toma la IP del nodo A leyendo el archivo read.dat, yejecuta el mismo algoritmo para calcular el dígito verificador.

• Verifica si el dígito enviado por el nodo A es el mismo valor calcu-lado, por el nodo B.

• En el caso que no sea igual al dígito, ignora el pedido, y graba enel archivo log el mensaje “Intruso a nivel transferencia de datos,controle”.

• En el caso de que sea igual al dígito, continúa el proceso normal-mente.

Encriptar y Desencriptar los Datos

Se realiza en el objeto ObjMsg.java() en la clase Encrip() y DesEncrip().

Se comprobó que al sumar o restar cualquier número positivo, en unarchivo binario, se altera el contenido del mismo.

Se consideró que este algoritmo cumple con los niveles de seguridada nivel encriptación.

Los pasos para lograr la encriptación son:

• Alterar el contenido, del archivo binario, sumando un número uno.


• Transmitir el archivo alterado.

• Volver al estado normal. Una vez recibido el nodo receptor, debellegar al mismo estado original del archivo. Para lograrlo resta ununo.

Este método se puede transformar en un algoritmo de alta seguridad.

Se realiza el siguiente proceso:

• Sumar un número aleatorio byte x byte.

• Tomar el número aleatorio, pasarlo a binario previa alteración,sumando un uno.

• Grabar este número en una posición determinada, en el archivobinario.

• Transmitir el archivo.

Una vez que se recibe los datos, el nodo receptor, procede a:

• Buscar la posición donde está el número aleatorio.

• Transformar al número aleatorio en el número original (restandoun uno).

• Transforma el archivo binario restando el número aleatorio.

Seguridad Nivel Usuarios

En este módulo se registran los usuarios y las claves de todos los nodos(servidores,clientes) que van a estar activos en la aplicación.

Secuencia de Control

Cuando la aplicación se ejecuta a nivel usuario se deben ingresar lossiguientes datos:


— Nombre de usuario.

— Contraseña.

— IP del servidor.

El sistema verifica si existe el servidor (primer padre).

En caso afirmativo, transmite el nombre de usuario y contraseña.

El servidor padre captura estos datos, analiza si existe un usuario conlos datos ingresados, leyendo la tabla control.dat.

En caso afirmativo emite al nodo cliente el número 1. Este dígito lehabilita al nodo cliente para empezar a operar el sistema. Caso contrarioel servidor padre registra en el archivo log un mensaje Intruso a nivel

clave de aplicación e ignora a este nodo.

En el caso de que no exista el servidor (primer padre), el usuario dela aplicación cliente ingresa la IP del servidor (segundo padre).

En caso de que no exista este servidor, no se podrá ejecutar la apli-cación.

En los dos servidores debe estar registrado el usuario (objeto ABMno-

dos.java).

Diagrama en Bloque del Sistema

En la figura 7-2 de la pág. 139, se indica el funcionamiento del protocoloYOSUKO V.2.0.

Cada nodo tiene los mismos objetos. La diferencia que existe entreun nodo servidor y nodo cliente, es solo el objeto RMI, que está activoúnicamente en el nodo servidor.

Figura 7-2 Esquema funcional de nodos.

Capítulo 8

Metodología de Integraciónde YOSUKO V.2.0 y Aplica-ciones Informáticas

Introducción

En el presente capítulo se desarrolla la metodología incorporada en el

protocolo YOSUKO V. 2.0, para lograr el objetivo de integrar las aplica-ciones informáticas construidas con tecnologías de programación antiguascon aplicaciones informáticas construidas con las tecnologías de progra-mación de última generación.

Se parte de la base de que conviven aplicaciones informáticas quecarecen de capacidad de comunicación, con las aplicaciones informáticasprogramadas bajo los nuevos conceptos de tecnologías de la informacióny de la comunicación.

140

Metodología de Integración de YOSUKO V.2.0 y Aplicaciones Informáticas 141

Con el objetivo de brindar una solución de bajo costo a este prob-lema que presenta el escenario descripto, se incorpora al algoritmo delprotocolo YOSUKO V. 2.0, las siguientes funciones:

• Comunicación entre procesos.

• Comunicación entre cliente / servidor.

• Invocación de los métodos remotos, a través de la programaciónRMI.

• Conexión al motor de base de datos MySQL, por medio del lenguajeestándar de comunicación SQL.

• Lectura y grabación de archivos binarios.

El Protocolo YOSUKO V. 2.0 y lasAplicaciones Externas

El diagrama de interacción del protocolo YOSUKO V.2.0 para integraraplicaciones externas se muestra en la figura 8-1 de la pág. 142.

Contenido del Archivo Read.dat

El archivo Read.dat es un archivo binario con la estructura que semuestra en la figura 8-2 de la pág. 143.

El contenido de los campos del archivo binario Read.dat se detalla acontinuación:

• Estado del Proceso: Este campo se utiliza para que la AplicacionExterna y YOSUKO V. 2.0, se pongan de común acuerdo.

— Significado del Campo:


Figura 8-1 Diagrama de interacción de YOSUKO con las aplicaciones

externas.

1. YOSUKONodo Local recibe una orden de una AplicaciónExterna para emitir un pedido a un Nodo Remoto.

2. YOSUKO informa a la Aplicación Externa que está real-izando el pedido solicitado por dicha Aplicación Externa.

3. YOSUKO informa a la Aplicación Externa que terminó elproceso de transmitir el pedido.

4. La Aplicación Externa informa que está realizando unatarea, YOSUKO espera que termine para continuar el pro-ceso.

5. La Aplicación Externa informa que terminó la tarea yYOSUKO trasmite el archivo generado por la AplicaciónExterna.

• Código de Actividad: Este campo se utiliza para relacionar elarchivo Read.dat con el archivo Activ.dat y proc.dat.

• Número Orden de Trabajo: Es un número mayor a cero que seutiliza para relacionar con el archivo proc.dat.

• Nombre del Archivo que se va a Transmitir : Este campo contieneel nombre del archivo que se va a transmitir al Nodo Destino.


Figura 8-2 Estructura del archivo Read.dat.

• Identificador de Procesos: Es un campo mayor a cero, no repet-itivo. La Aplicación Externa lleva el control, y sirve para que sediferencien los procesos.

• Tiempo de Espera en Minuto: Este campo contiene el tiempo máx-imo que va a esperar la Aplicación Externa, al protocolo YOSUKO,para que realice el pedido solicitado.

• Tiempo de YOSUKO: Este campo es utilizado por el protocolo; segraba la hora, minuto, segundo, del nodo que recibe el pedido.

El protocolo YOSUKO V. 2.0 utiliza otros archivos en forma interna


para poder realizar las tareas encomendadas por la Aplicación Externa.

El diseño del modelo físico de datos se detalla a continuación.

• Activ.dat : En este archivo se define el nombre de la actividad;ejemplo: empresa xxxx, administración, depósito. etc. (ver lafigura 8-3 de la pág. 144).

Figura 8-3 Archivo binario Activ.dat.

• Control.dat: Se utiliza para registrar el nodo local (objeto Con-

fig.java). Si este archivo está vacío, se activa el módulo registrar elproducto en el servidor de la empresa que va a distribuir el mismo(ver en el capítulo 7, Seguridad a Nivel de Aplicación (ver estruc-tura del archivo en la figura 8-4 de la pág. 145.

— Nodos.dat: Se registran los nodos (Servidores, Clientes) quevan a estar activos en la red. Además este archivo se uti-liza para verificar si es un usuario válido dentro del sistema(ver capítulo 7, Seguridad a Nivel Usuario (ver estructura delarchivo en la figura 8-5 en la pág. 146).

• Proc.dat: En este archivo se graban los procesos que el progra-mador de la Aplicación Externa quiere que realice el protocoloYOSUKO. El detalle de los campos es el siguiente:


Figura 8-4 Archivo binario Control.dat.

— Código de Actividad: Se utiliza para relacionar el archivo Ac-tiv.dat.

— Orden de Trabajo: Es un número mayor a cero, no se puederepetir, y se utiliza para diferenciar, los distintos procesos quepueda tener el protocolo YOSUKO V.2.0.

— Tipos de procesos: Puede tener dos estados:

∗ Transmite el pedido y termina el proceso.

∗ Transmite el pedido, espera respuesta, y retrasmite el pe-dido.

— Número de Nodo Destino: Indica el punto final de la trans-misión de paquetes, emitidos por el nodo emisor.

— Tipos de transmisión: Puede tener 2 estados:

∗ Transmite archivos al nodo destino.

∗ Transmite y ejecuta comandos SQL (Select, Insert, Up-date, Delete) en el nodo destino.

— ID Usuario: Se utiliza para identificar el nombre de usuarioque tiene derecho a ingresar al motor de Base de Datos, yejecutar el comando SQL, provisto por la Aplicación Externa.

— Contraseña: Clave para acceder al motor de Base de Datos.


Figura 8-5 Archivo binario Nodos.dat.

— URL Base de Datos: Es la dirección IP donde reside física-mente el Motor de Base de Datos.

— Puerto: Puerta de entrada donde escucha el Motor de Basede Datos.

— Separador de Campos: Indica al protocolo YOSUKO V.2.0

cómo tiene que presentar la información, después de haberejecutado el comando Select.

La estructura del archivo se muestra en la figura 8-6 de la pág. 147.

Descripción Operativa del Sistema de

Integración

La Aplicación Externa, denominado “ApliExt” a modo de ejemplo, so-licita a YOSUKO V. 2.0 que envíe un archivo del Nodo 1 al Nodo 3 .


Figura 8-6 Archivo binario Proc.dat.

Se realiza de la siguiente forma:

• El programador de la ApliExt graba en él Nodo 1:

— Archivo Activ.dat:

∗ Actividad = 1, Nombre de la actividad = “Sistema Dinámicode Transferencia”, Carpeta de trabajo = “D:/ACT1/”.

— Archivo Proc.dat:

∗ Actividad =1, Orden de trabajo = 1, Tipo de proceso =1, Nodo destino = 3, Tipo de transmisión = 1.

— Archivo Read.dat:


∗ Estado = 1, Código de Actividad = 1, Orden de Trabajo= 1, Nombre del Archivo = “MisFotos.zip”, Número deproceso = 100, Tiempo de espera = 2.

• YOSUKO V 2.0 , en el Nodo 1, realiza el siguiente proceso:

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

— Graba el campo estado un dos.

— Toma el campo Actividad, y lee el archivo Activ.dat, realizauna búsqueda secuencial para extraer el nombre de la activi-dad, y la carpeta del lugar de trabajo.

— Lee el archivo Proc.dat, compara los campos Actividad, Ordende trabajo. Si encuentra un registro con iguales característi-cas, toma los datos tipo de proceso, nodo destino, tipo detransmisión.

— Detecta el mejor camino. Transmite el archivo, primero alNodo 2, y despues al Nodo 3. Ver Capítulo 6, Grafos Completo(Matriz de Adyacencia).

— Transmite la información al Nodo 2.

La Aplicación Externa denominada “ApliVtaBoleto” a modo ejem-plo, solicita a YOSUKO V. 2.0. que envíe un archivo del Nodo 1 al Nodo

3. Espera recibir un archivo procesado por la otra aplicación externa queestá en el Nodo 3.


• El programador de la ApliVtaBoleto graba en el Nodo 1:


∗ Actividad = 2, Nombre de la actividad = “Empresa deTransporte de Pasajeros de Larga Distancia”. Carpeta detrabajo = D:/ACT2/.



∗ Actividad = 2, Orden de trabajo = 2, Tipo de proceso =2, Nodo destino = 3, Tipo de transmisión = 1.


∗ Estado = 1, Código de Actividad = 2, Orden de Trabajo= 2, Nombre del Archivo = “Vtaremo.dbf”, Número deProceso = 101, Tiempo de espera = 1.

• YOSUKO V 2.0 en el Nodo 1, realiza el siguiente proceso:

— Lee el archivo Read.dat, determina que tiene un proceso pen-diente, porque tiene un uno en el campo estado.


— Toma el campo Actividad, y lee el archivo Activ.dat, realizauna búsqueda secuencial para extraer el nombre de la Activi-dad, y la Carpeta del lugar de trabajo.


— Detecta el mejor camino. Pasa el archivo, primero por el Nodo2, y después por el Nodo 3.

• YOSUKO V 2.0 en el Nodo 2 determina que no es el nodo final dela transmisión. Pasa el pedido al Nodo 3.

• YOSUKO V 2.0 en el Nodo 3 determina que es el final de la trans-misión y realiza lo siguiente:

— Analiza el campo Tipo de proceso. En este caso es dos.

— Lee el archivo Activ.dat, saca la ubicación de la carpeta.

— Graba el archivo “vtaremo.dbf”, en la carpeta donde se es-tableció para esa actividad.

— Marca con un cuatro el campo estado, la aplicación externa,del nodo 3, determina que tiene que hacer un trabajo, porqueel protocolo YOSUKO del nodo 3, está esperando una re-spuesta, para enviar de vuelta el archivo.


— Terminado el proceso de la Aplicación Externa ApliVtaBoleto,se graba en el archivo Read.dat un valor 5 en el campo estado.

— Se determina que la aplicación externa terminó el proceso. En-tonces, se analiza el tiempo de espera de la aplicación externa,si está fuera del límite de tiempo, marca con un tres el campoEstado del archivo Read.dat y termina el proceso.

— En el caso de que está dentro del tiempo establecido por laaplicación externa, toma el archivo “vtaremo.dbf”, y trans-mite al nodo 1.

— Graba un tres en el campo Estado del archivo Read.dat.

— Termina el proceso.

La Aplicación Externa denominada “ApliSql”, a modo ejemplo, so-licita a YOSUKO V. 2.0 . que envíe un archivo, del Nodo 1 al Nodo 3.Espera recibir un archivo procesado, con la información que se extrajodel Motor de Base de Datos RRRR, que está en el Nodo 3.


• El programador de la ApliSql graba en él Nodo 1:


∗ Actividad = 2, Nombre de la actividad = “Empresa deTransporte de Pasajeros de Larga Distancia”. Carpeta detrabajo = D:/ACT2/.


∗ Actividad = 2, Orden de trabajo = 3, Tipo de proceso =2, Nodo destino = 3, Tipo de transmisión = 2.


∗ Estado = 1, Código de Actividad = 2, Orden de Tra-bajo = 3, Nombre del Archivo = “comando.txt”, Númerode Proceso = 102, Tiempo de espera = 3, Id Usuario =KOKI, Contraseña = 123, Base de Datos = RRRR, URL=192.168.1.1, Puerto = 4000, Separador de Campo = “,”.En el campo comando.txt, va la sentencia SQL Select.


• YOSUKO V. 2.0 en el Nodo 1, realiza el siguiente proceso:

— Lee el archivo Read.dat, determina que tiene un proceso pen-diente, porque tiene un uno en el campo estado.


— Toma el campo Actividad, y lee el archivo Activ.dat, realizauna búsqueda secuencial, para extraer el nombre de la Activi-dad, y la Carpeta del lugar de trabajo.


— Detecta el mejor camino. Pasa el archivo, primero por al Nodo2, y despues al Nodo 3.

• YOSUKO V. 2.0 en el Nodo 2, determina que no es el nodo finalde la transmisión. Pasa el pedido al Nodo 3.

• YOSUKO V. 2.0 en el Nodo 3, determina que es el final de latransmisión y realiza lo siguiente:

— Analiza el campo Tipo de proceso. En este caso es dos.

— Lee el archivo Comand.txt, que vino en el paquete recibido.

— Analiza el tipo de comando SQL, en este caso es una orden

Select.

— Ejecuta el comando SELECT.

— Graba en memoria la consulta.

— Arma un paquete con la información.

— Agrega el delimitador de campo“,”.

— Marca con un tres el campo estado.

— Analiza el tiempo máximo de espera establecido por la apli-cación externa. Si está fuera del límite de tiempo, marca conun tres el campo estado del archivo Read.dat.

— Transmite el pedido al Nodo 1.


— Termina el proceso.

En caso que sea una orden SQL Insert, Update, Delete, el proceso esel mismo. Sólo que no transmite el archivo al Nodo 1.

Algoritmo del Sistema Integración

El algoritmo del sistema de integración se detalla seguidamente:

public void run() {

int IDAct;

int IDOrden;

int IDProc = 0;

long pedTime;

int waitTime;

int i,j,k;

String FileNam;

boolean valid = false;

try {

dbRead = new DB(”Read.dat”, 7, 20, ”rw”);

dbProc = new DB(”Proc.dat”, 15, 30, ”rw”);

for (i=0; i<dbRead.getRecCount(); i++) {

dbRead.Go(i);

// Nombre del archivo a transmitir.


FileNam = null;

Est = (int) Integer.valueOf (dbRead.getValue(0).trim());

IDAct = (int) Integer.parseInt(dbRead.getValue(1).trim());

IDOrden = (int) Integer.parseInt(dbRead.getValue(2).trim());

FileNam = dbRead.getValue(3).trim();

IDProc = (int) Integer.parseInt(dbRead.getValue(4).trim());

waitTime = (int) Integer.valueOf(dbRead.getValue(5).trim());

pedTime = (long) Long.valueOf(dbRead.getValue(6).trim());

valid = true;

Term.dbAct.Go(IDAct-1);

// Si es 1, tiene que realizar un proceso.

if (Est == 1) {

for (j=0; j<dbProc.getRecCount(); j++) {

dbProc.Go(j);

if (Integer.valueOf(dbProc.getValue(0).trim()) == IDAct &&

Integer.valueOf(dbProc.getValue(1).trim()) == IDOrden) {

Term.TipoProc = Integer.valueOf(dbProc.getValue(2));

Term.NodDes = (int) Integer.valueOf(dbProc.getValue(3));

Term.IDProc = IDProc;

Term.TSQL = (int) Integer.valueOf(dbProc.getValue(4));

// Solo cuando es SQL

if (Term.TSQL == 2) {


Term.DatosDB[0] = dbProc.getValue(5).trim();






}

// En el caso de que el proceso sea de tipo 1 (enviar y no esperar respuesta),

// se graba un valor 3, indicando que ha terminado.

if (Term.TipoProc == 1) {

dbRead.setValue(0, ”3”);

Term.addTask(”Pedido No ” + String.valueOf(IDProc).trim() + ” termi-

nado.”);

} else {

// Si es de tipo 2 (enviar y esperar respuesta), marca con un 2, que significa

// en proceso y guarda la hora en que se ejecuto el pedido


dbRead.setValue(6, String.valueOf(actTime.getTime()));

Term.addTask(”Esperando respuesta para el Pedido No: ” + String. valueOf

(IDProc) + ”...”);

}

dbRead.SaveRec();

Term.cmdSend_Click(Term.dbAct.getValue(2), FileNam, IDAct, waitTime);


break;

}

}

}

// Si es 2, se esta realizando un proceso y tengo que verificar que espere una

// respuesta hasta cierto tiempo.

if (Est == 2) {

if (((actTime.getTime() - pedTime) / 60000) >= waitTime) {

Term.addTask(”Tiempo de espera agotado para el Pedido No” + String.

valueOf (IDProc));


dbRead.SaveRec();

}

}

if (Est == 4) {

if (((actTime.getTime() - pedTime) / 60000) >= waitTime) {

Term.addTask(”Tiempo de espera agotado para Transmitir el Pedido No” +

String. valueOf (IDProc));


dbRead.SaveRec();

}

}

// Si es 5 tengo que re-transmitir. Este valor puso la aplicacion externa a

Java.


if (Est == 5) {

Term.addTask(”Pedido No ” + String.valueOf(IDProc) + ”: OK”);

dbRead.setValue(0, ”3”); // 3: proceso terminado.

dbRead.SaveRec();

Term.TipoProc = 1;

Term.NodDes = IDOrden;

Term.IDProc = IDProc;

Term.cmdSend_Click(Term.dbAct.getValue(2), FileNam, IDAct, 0);

}

}

dbRead.Close();

} catch (Exception e) {

if (!valid && Est == 1) Term.addTask(”El Pedido No ” + String. valueOf

(IDProc).trim() +

” posee parametros incorrectos.”);


dbRead.SaveRec();

dbRead.Close ();

}

}


Prueba de la Implementación Efec-

tuada

Los pasos son los siguientes:

• Se ingresa al servidor de Base de Datos, como se ilustra en la figura8-7 de la pág. 157.

Figura 8-7 Ingreso al Servidor MySQL.

• Se registra el número de serie del producto (ver figura 8-8 de la pág.158 y figura 8-9 de la pág. 158).

• Se instala el primer servidor padre YOSUKO V. 2.0, máquina 1(ver Manual del Usuario en el Anexo).

• Se instala el segundo servidor padre YOSUKO V. 2.0, máquina 2(ver Manual del Usuario en el Anexo).

• Se verifica el primer nivel de seguridad, a nivel de aplicación (vercapítulo 7 y la figura 8-10 de la pág. 159).


1.

Figura 8-8 Pantalla de registración del producto.

Figura 8-9 Pantalla de confirmación.

• Una vez registrado el producto, se registra en la aplicación YOSUKOlos dos servidores (nodos), indicando el nombre de usuario, con-traseña, IP, puerto, actividad (ver figura 8-11 de la pág. 159).

• Se da de alta a los Nodos clientes (usuarios o servidores comunes),en el servidor primer padre.

• Se instala en la máquina 3 la versión cliente YOSUKO V. 2.0.

• Se verifica el segundo nivel de seguridad a nivel usuario, ingresandomal los datos del usuario cliente. La verificación la realiza el servi-


Figura 8-10 Tabla Usuario de la base de datos YOSUKO.

Figura 8-11 ABM de servidores y terminales.

dor RMI Primer Servidor padre 192.168.80.5 (ver la figura 8-12 dela pág. 160).

• Una vez pasado el nivel de seguridad, el usuario cliente se registraen la aplicación (ver figura 8-13 de la pág. 161).

• Se registra la actividad (ver figura 8-14 de la pág. 162).


Figura 8-12 Error en el segundo nivel de seguridad.

• Se cargan los procesos (ver figura 8-15 de la pág. 163).

• Se apagan los dos servidores, y se verifica el nivel de seguridad anivel usuario (ver figura 8-16 de la pág. 163).

• Una vez cargados los datos obligatorios en cada Nodo, se prueba laopción informar nodos. Este módulo se utiliza para que los demásusuarios sepan la cantidad de nodos que existe en la red teniendoen cuenta la actividad. Una vez completado este paso, se podrácalcular las reglas o rutas, que existen entre los nodos.

La figura 8-17 de la pág. 164 muestra la consola sin nodos, en esperade que se le informe sobre los demás nodos.

La figura 8-18 de la pág. 165 muestra nodos activos.

Prueba de Transmisión de Paquetes

Los pasos para realizar la prueba de transmisión son los siguientes:


Figura 8-13 Registro del cliente en la aplicación.

• Se ejecuta el programa de vieja generación (legacy o aplicaciónlegada o heredada), para probar los enlaces de comunicación (verfigura 8-19 en la pág. 165.

• Se transmite un paquete del nodo Posadas (IP 192.168.80.4) alservidor 5 (IP 192.168.80.1) (ver figura 8-20 de la pág. 166).

• Se verifica la encriptación de los datos (ver figura 8-21 de la pág.166).


Figura 8-14 Registro de la actividad.

Prueba con Aplicación Externa deVentas de Boletos


• Solicita un pedido de ventas de boletos, desde Posadas a Retiro,fecha 19/02/2006, 20 horas, como se ve en la figura 8-22 de la pág.167.

• En la figura 8-23 de la pág. 167 se muetra cómo el protocoloYOSUKO toma el pedido de la aplicación externa y busca el mejorcamino.

Figura 8-15 Registro de procesos.

Figura 8-16 Verificación del nivel de seguridad a nivel usuario.


Figura 8-17 Panel sin nodos.


Figura 8-18 Terminal de control con nodos activos.

Figura 8-19 Pantalla de aplicación de antigua generación (lenguaje Clipper5.2).


Figura 8-20 Transferencia entre dos nodos.

Figura 8-21 Archivo encriptado.


Figura 8-22 Aplicación de ventas de boletos.

Figura 8-23 Detección del mejor camino por parte de YOSUKO paraatender una aplicación externa.

Capítulo 9

Conclusiones y Futuros Traba-jos

Los objetivos generales de la tesis, enunciados en la introducción, se re-sumen como sigue:

• Se deberá desarrollar un sistema experto basado en reglas (en lenguajeJava).

• Se deberá gestionar el tráfico entre servidores remotos, utilizandocomunicación de bajo costo, detectando el mejor camino.

• Se deberá poder interactuar con los diferentes motores de bases dedatos o sistemas de archivos de los distintos servidores mediantecomandos de SQL.

• Se integrará aplicaciones, desarrolladas en la década de los años70s, a través de un contenedor de pedidos.

• Se deberá utilizar algoritmos de seguridad para dar protección alos datos recibidos o enviados por el contenedor de pedidos.

168

Conclusiones y Futuros Trabajos 169

Luego de haberse realizado el presente trabajo, se llegó a las siguientesconclusiones principales:

• Se ha desarrollado un sistema experto en lenguaje Java. Se adjuntaun CD con las fuentes del sistema.

• Se pudo utilizar con el sistema de protocolo desarrolado enlaces decomunicación de bajo costo (ADSL) (ver, Análisis de Costo portipo de Enlaces de Comunicación, capitulo 6).

• La aplicación desarrollada para gestión de tráfico entre aplicaciones,permite interactuar con motores de bases de datos (ver capítulo 8).Por razones de tiempo y costo sólo se ha probado con el motor deBase de Datos MySQL. Quedan como pruebas futuras trabajar conlos motores de base de datos Oracle, Informix, DB2 UDB, etc.

• En cuanto a integrar aplicaciones desarrolladas en la década delos años 70s, se realizaron pruebas intensivas con la aplicación deVentas de Boletos, programada en su oportunidad con el lenguajeClipper 5.0. para una conocida empresa de transporte colectivo conamplia cobertura en el país y en países vecinos (ver capítulo 8).

• Respecto al uso de algoritmos para dar protección a los datos, seimplementaron algoritmo de encriptación y de dígito verificador(ver capítulo 6).

• El trabajo desarrollado, una vez implementado a nivel comercial,permitiría:

— Ahorro en la reprogramación del software.

— Ahorro en servidores costosos.

— Ahorro en motores de bases de datos.

— Ahorro en costo de comunicación.

— Ahorro en licencias de software.

— Seguridad de datos en el momento de transmitir la informa-ción.

Conclusiones y Futuros Trabajos 170

En cuanto a los posibles trabajos futuros se menciona lo siguiente:

• Se deberá implementar el protocolo desarrollado en los dispositivosmóviles (celulares, pocket PC, asistentes personales, etc.).

• Se desarrollarán pruebas con transmisión de imágenes entre celu-lares, para obtener un sistema de video conferencia.

• Se efectuarán verificaciones de funcionamiento con otros motoresde bases de datos, tales como Oracle, Informix, DB2 UDB, etc.

Nota: Además se destaca que los fuentes de la aplicación serán uti-lizados en futuros cursos de postgrado que se tiene previsto impartir.

Parte III

Anexo

171

Capítulo 10

Anexo

Detalles de los Objetos Más Impor-tantes del Protocolo YOSUKOV. 2.0

En esta sección se describen los objetos más importante del protocoloYOSUKO V. 2.0.

Main.java(): Arranca la aplicación:

• LoginC.Java(): Solicita el Nombre del Usuario, Clave, IP del Servi-dor. Verifica por RMI los datos ingresados.

• LoginS.Java(): Registra el producto en el Motor de Base de DatosMySQL. Este módulo activa la protección a nivel software:

— Solicita el Nombre del Usuario, Clave, IP local, Puerto.

— Conecta a un Motor de Base de Datos MySQL.

172

Anexo 173

— Registra en el servidor la licencia.

— Graba los datos del servidor en el archivo control.dat.

Una vez hecha la consistencia, se convoca a la pantalla principal.

FrmMain.java(): Formulario principal del sistema:

• ABMAct.java(): Se define la actividad, puede ser el nombre deuna empresa, o algún nombre representativo. Ej. Administración,Finanzas etc.:

— Es obligatorio ingresar la carpeta de trabajo, el Servidor re-aliza su transacción de actividad, en ese espacio del disco.

— Los datos ingresado se graban en el archivo Activ.dat.

• ABMNodos.java(): En este objeto se registran los nodos (Servi-dores o Clientes), que estarán activos en la red. Los datos ingresa-dos se utilizan para verificar, a través de RMI, si el usuario tienepermitido estar en la red.

• ABMProc.java(): En este objeto se definen los proceso que puederealizar un nodo, con una Aplicación Externa.

• ABMUsers.java(): Es una interfaz de usuario. Se utiliza para cap-turar los datos, conectar con el servidor (primer padre), y verificarpor RMI la veracidad de los datos.

• Config.java(): En este objeto se configura el servidor local o clientelocal.

• DB.java(): Este objeto se utiliza como contenedor de archivos conextensiones variables (XLS, DOC, EXE, BMO, JPG, etc.). Lee ygraba cualquier tipo archivo.

• Grafico.java(): Se utiliza para representar gráficamente los nodosque están conectados, y mostrar el mejor camino, cuando se va atransmite información.

Anexo 174

• ObjMsg.java(): Este es un objeto Serializable. Se utiliza paratransmitir la información entre los diferentes nodos.

• DesEncrip(): Descencripta los datos.

• Objrem.java(): En este objeto se implementa la programación RMI.

• SocketC.java(): Se encarga de crear sockets Servidor y socketsClientes. Esta clase se extiende de la clase Thread (hilo), parapoder escuchar peticiones de los clientes.

• Escribir(ObjMsg Pedido): Se ejecuta cuando se intenta transmitirun paquete al nodo destino.

• LeerNodos(): Se encarga de leer todos los nodos que están registra-dos en la tabla Nodos.dat.

• CalcDV(): Devuelve como resultado un número que se usa comodígito verificador para los paquetes de transmisión.

• run(): Evento que convoca objetos.

• ActNodos(): Actualizar Nodos.

• RecPed:(): Entrada de Pedidos.

• setPing(): Actualizar todos los Valores Ping.

• ExecSQL(): Consulta SQL.

• InfNodos(): Envía información a los Nodos.

• LeerPing(): Calcula el Ping.

• EnviarMsg(): Envía mensajes.

• ClientThread(): Crea un hilo.

• ActNodos(): Se ejecuta cuando se recibe un paquete que contieneinformación de Nodos, para actualizar.

• getPing(): Crea un hilo para leer un ping.

Anexo 175

• Terminal.java(): Pantalla principal del sistema. Muestra una ven-tana con todos los Nodos y los estado de la interfaz que se comunicacon la clase SocketC para poder enviar y recibir datos.

• timer.setInitialDelay(): Tiempo 1.

• timer2.setInitialDelay(): Tiempo 2.

• Graph.setEstNodo(): Verifica el estado del Nodo y lo pinta.

• Graph.repaint(): Dibuja todos los nodos.

• Server.LeerPing(): Lee los valores de Ping.

• Server.InfNodos(): Informa los nodos activos a toda las terminales.

• LeerNodos(): Carga en memoria todos los Nodos que actúan en laActividad seleccionada.

• DrawNodos(): Dibuja en memoria el gráfico.

• Graph.repaint(): Baja en pantalla el gráfico.

• cmdBegin_Click(): Activa el servidor con una conexión Socket.

• cmdSend_Click(): Envía un mensaje por medio de Socket.

• DrawNodos(): Dibuja los Nodos en forma circular en la pantalla.(para realizar el gráfico utiliza la función Seno, Coseno).

• ActNodos(): Informa el estado de los Nodos.

• addTask(String Task()): Agrego el proceso en el área de texto,muestra los eventos del Nodo.

• CalcRegla(): Calcula la mejor ruta o camino, teniendo en cuentael Nodo destino.

• ProcThread extends Thread: Se ejecuta cuando se dispara el 1er.temporizador, cada 2,5 seg. Lee toda la tabla Read.dat en buscade procesos a realizar.

Anexo 176

Manual del Usuario de YOSUKO V.2.0

Se adjunta un CD con el contenido que se indica en la figura 10-1 de lapág. 176.

Figura 10-1 Contenido del CD de la tesis.

Pasos Para la Instalación Modo Servidor


• La PC en donde se ejecutará el sistema YOSUKO V.2.0 deberátener instalado el Runtime de Java V.5.0_03 o superior, el cual seadjunta en el CD de Instalación.

• Copiar todos los archivos de instalación a una carpeta (ej.: C:/Yosuko),con excepción del driver paraMySQL (mysql-connector-java-3.1.12-bin.jar). Esta carpeta será la “Carpeta de Trabajo” del Sistema,la cual se deberá configurar en la pantalla Configuración Terminal,como se ve en la figura 10-3 de la pág. 180.

• Copiar el archivo mysql-connector-java-3.1.12-bin.jar a la carpetaen donde se instaló elRuntime de Java (ej.: C:\jre1.5.0_03\lib\ext\).Si se encuentra en otra ubicación, buscar el subdirectorio ..\lib\ext\.

Anexo 177

• Ejecutar el archivo rmiRegistry.exe, que se encuentra en el directo-rio bin delRuntime de Java (ej.: C:\jre1.5.0_03\bin\rmiregistry.exe).

• Minimizar la aplicación rmiregistry.exe y ejecutar Servidor.jar.

• Luego de crear las Actividades en la pantalla ABM de Actividades.

• Se deberán crear las respectivas carpetas de trabajo, caso contrario,no se podrá enviar o recibir información. Ver la figura 10-4 de lapág. 181.

Pasos Para la Instalación Modo Cliente


• La PC en donde se ejecutará el sistema YOSUKO V.2.0 deberátener instalado el Runtime de Java v.5.0_03 o superior, el cual seadjunta en el CD de Instalación.

• Copiar todos los archivos del paquete de Instalación a una carpeta(ej.: C:/Yosuko), con excepción del driver para MySQL (mysql-connector-java-3.1.12-bin.jar). Esta carpeta será la “Carpeta deTrabajo” del Sistema, la cual deberá configurarse en la pantalla deConfiguración del Terminal, como se ve en la figura 10-3 de la pág.180.

• Copiar el archivo mysql-connector-java-3.1.12-bin.jar a la carpetaen donde se instalo elRuntime de Java (ej.: C:\jre1.5.0_03\lib\ext\).Si se encuentra en otra ubicación, buscar el subdirectorio ..\lib\ext\.

• Ejecutar la aplicación Cliente.jar. Luego de crear las Actividadesen la pantalla ABM de Actividades, como de ve la figura 10-4 de lapág. 181.

• Se deberá crear las respectivas carpetas de trabajo, caso contrario,no se podrá enviar o recibir información.

• Deberá existir el primer Servidor Padre, caso contrario no se podráingresar al sistema.

Anexo 178

Panel de Control

La pantalla Panel de Contol tiene el diseño que se muestra en la figura10-2 de la pág. 179; el usuario podrá poner en marcha el Servidor,presionando el botón Arrancar.

El grafico de la derecha mostrará el estado de los nodos de la red dela actividad seleccionada en el combo Actividad.

• Estado del Nodo: Nodo Local (amarillo), Nodo Activo (verde),Nodo Inactivo (rojo).

• Area de Texto Procesos: Muetra todas las acciones que el sistemaestá realizando, las que pueden ser, iniciar servidor, recibir pedidos,enviar pedidos, recibir información de Nodos, redireccionar pedidos,etc.

• Botón Grabar Log: Permite grabar las actividades que tubo el Nodoen un archivo denominado Proceso.log.

Nota: Sólo para la versión Servidor estará disponible el botón Infor-

mar Nodos.

Configuración

La pantalla Configuración del Terminal (ver figura 10-3 de la pág. 180,permite configurar el nodo local.

Datos solicitados: ID del Nodo , descripción, contraseña, IP local,puerto “escucha” de pedidos, y la Carpeta de Trabajo. Esta carpeta esde suma importancia, ya que todos los archivos del paquete de insta-lación deberán estar ubicados allí. La ruta deberá colocarse con barrasinvertidas y terminar con una de ellas (ej.: “c:/Yosuko/”).

Anexo 179

Figura 10-2 Pantalla panel de control.

ABM de Actividades

Esta pantalla permite realizar Altas, Bajas y Modificaciones de las dis-tintas “Actividades” que el Sistema YOSUCO deberá ejecutar (ver lafigura 10-4 de la pág. 181.

Datos a Ingresar : ID de Actividad, Descripción, Carpeta de Trabajo(deberá colocarse con barras invertidas y terminar con una barra, ej.:“d:/Actividad1/”).

Los archivos de transferencia, dependiendo de la actividad, debenestar situados en esta carpeta.

ABM de Terminales (Modo Servidor)

Permite realizar Altas, Bajas y Modificaciones a todos los Nodos de laRed. Sólo está activo modo servidor (ver la figura 10-5 de la pág. 181).

Anexo 180

Figura 10-3 Pantalla de configuración del terminal.

Una vez que el Administrador (Servidor) registra los datos (ID deNodo, Descripción, Contraseña, Puerto, IP, Actividad) de los Nodosque posean la versión Cliente de YOSUKO, éste deberá informar a susClientes quiénes son los que participan en el intercambio de informacióndentro de la red.

Para ambas versiones (Cliente y Servidor), el botón “Crear Reglas”permitirá generar todas las rutas posibles, grabando en el archivo Re-

glas.dat, para que YOSUKO pueda elegir el mejor camino, para el envíode pedidos de un Nodo Origen a otro Final.

ABM de Procesos

Esta pantalla es la interfaz de usuario, entre la Aplicación Externa y elprotocolo YOSUKO V.2.0.

Se registran procesos, que podrá realizar el protocolo (ver figura 10-6de la pág. 182).

Anexo 181

Figura 10-4 Pantalla ABM de actividades.

Figura 10-5 Pantalla de ABM de terminales.

Estos procesos tendrán un No de orden auto numérico dependiendode la actividad.

Datos a Ingresar : Tipo de Proceso (Transmitir; Transmitir y es-perar respuesta), Nodo destino, Tipo de Transmisión (cualquier tipo dearchivos o comando SQL).

En el caso de que sea un comando SQL, se deberá ingresar el Nombrede Usuario de la Base de Datos, la contraseña de la Base de Datos, elnombre de la Base de Datos, la dirección URL de la Base de Datos, elpuerto, y el separador de campo (se utiliza cuando ejecuta el comandoSELECT, sirve para diferenciar los campos, de la consulta.).

Figura 10-6 Pantalla para ABM de procesos.

Bibliografía

[1] Abramson, N., Teoría de la Información y Codificación - 6/E,Paraninfo, España, 1986. ISBN 84-283-0232-4.

[2] Bourdette, J., Aplicaciones de Negocio en Java, PC Fornum S.A.,ISBN 987-9131-79-1, 1998.

[3] Carracedo Gallardo, J., Seguridad en Redes Telemáticas. Mc GrawHill, España, 2004. ISBN 84-481-4157-1.

[4] Castillo, E.; Cobo, A.; Gómez, P.; Solares, C., Java - Un Lenguaje

de Programación Multiplataforma para Internet, Paraninfo, ISBN84-283-2368-2, 1997.

[5] Castillo, E.; Gutiérrez, J. M.; Haidi, A. S., Sistemas Expertos y

Modelos de Redes Probabilísticas, Academia de Ingeniería, ISBN 84-600-9395-6, 1996.

[6] Castro Marcel (2002). Sistemas Expertos. Consultado en http://strix.ciens.ucv.ve/ ~iartific/ Material/ PP_Sistemas_Expertos.pdf.

[7] Cathan Cook, Microsoft Corporation, Arquitectura de Bases de

Datos: El Motor de Almacenamiento, artículo publicado en el portalde Microsoft el 13 de Enero del 2003.

[8] Comer, D. E., Computer Networks and Internets, with Internet Ap-

plications - 3/E, Prentice Hall, USA, 2001. ISBN 0-13-091449-5.

[9] Comer, D. E., Hands-On Networking with Internet Technologies -1/E, Prentice Hall, USA, 2002. ISBN 0-13-048003-7.

183

BIBLIOGRAFÍA 184

[10] Comer, D. E., Internet Book, The: Everything You Need to Know

About Computer Networking and How the Internet Works - 3/E,Prentice Hall, USA, 2000. ISBN 0-13-030852-8.

[11] Coulouris G.; Dollimire J.; Kindberg, E. Distributed Systems: Con-

cepts and Design, Addison - Wesley, 3sd Edition, 2001.

[12] A. M. Davis; Remontando: Una Necesidad Simple. IEEE Software,12(5), Septiembre 1995.

[13] Huidobro, J. M., Tecnologías Avanzadas de Telecomunicaciones,

Thomson Paraninfo, España, 2003. ISBN 84-283-2853-6.

[14] Jaworski, J., Java 1.2 al Descubierto, Prentice - Hall, ISBN 84-8322-061-X, 1999.

[15] Kennedy, D., Microsoft Corporation, Agrupación de Conexiones con

Analisys Services de SQL Server 2000, publicado originalmente enmayo de 2001, actualizado en noviembre de 2002.

[16] Leffler, M. McKusick, M. Karels, The Design and Implementation

of the 4.3BSD UNIX Operating System, S.J, Quaterman Addison-Welsey, 1989

[17] Microsoft,Windows NT Workstation Kit de Recursos, McGraw-Hill/ Interamericana de España, ISBN 84-481-1095-5, 1996.

[18] Poratti, G. G., Redes: La Guía de Referencia Actual y Definitiva,Mp. Ediciones S.A., ISBN 987-526-208-0, 2004.

[19] Recio, M. J., Redes Locales, ISBN 84-89245-17-7, 1997.

[20] Sheldon, T., Encyclopedia of Networking and Telecommunications -3/E. Mc Graw Hill, USA, 2001. ISBN 0-072-12005-3.

[21] Sheldon, T., LAN Times - Enciclopedia de Redes - Networking -2/E. Mc Graw Hill, España, 1997.

[22] Randall B. Smith, David Ungar. Programming as an Experience:

The Inspiration for Self. Sun Microsystems Laboratories. 1995.

BIBLIOGRAFÍA 185

[23] Stallings, W., Comunicaciones y Redes de Computadores - 5/E.Prentice Hall, España, 1999. ISBN 84-89660-01-8.

[24] Stevens Englewood Cliffs, UNIX Network Programming, NJ: Pren-tice Hall, 1990.

[25] Stallings, W., Cryptography and Network Security: Principles and

Practice - 2/E, Prentice Hall, USA, 1999. ISBN 0-13-869017-0.

[26] Stallings, W., Data & Computer Communications - 6/E, PrenticeHall, USA, 2000. ISBN 0-13-084370-9.

[27] Stallings, W., High-Speed Networks and Internets: Performance andQuality of Service - 2/E, Prentice Hall, USA, 2002. ISBN 0-13-032221-0.

[28] Stallings, W., Local and Metropolitan Area Networks - 6/E, PrenticeHall, USA, 2000. ISBN 0-13-012939-9.

[29] Stallings, W., Network Security Essentials: Applications and Stan-

dards - 1/E., Prentice Hall, USA, 2000. ISBN 0-13-016093-8.

[30] Stallings, W., Wireless Communications and Networks - 1/E, Pren-tice Hall, USA, 2002. ISBN 0-13-040864-6.

[31] Subramanian, M., Network Management: Principles and Practice -1/E. Addison Wesley, USA, 2000. ISBN 0-201-35742-9.

[32] Tanenbaum, A. S., Redes de Computadoras - 3/E. Prentice HallHispanoamericana, México, 1997. ISBN 968-880-958-6.

[33] Tanenbaum, A. S., Van Oteen, M., Distributed Systems: Principles

and Paradigms - 1/E. Prentice Hall, USA, 2002. ISBN 0-13-088893-1.

[34] J.E. White, A High-Level Framework for Network-Based Resource

Sharing RFC 707, December 1975

[35] Weiss y Kulikowski, Sistemas Expertos, Prentice-Hall, 1984.

Índice Alfabético

actividades, 179ADSL, 3, 113anexo, 172API, 33, 87aplicación distribuida

seguridad de la, 51aplicaciones distribuidas

construcción de, 37diseño, 30en Internet, 31

applet, 86ARP, 23ARPANET, 14Arpanet, 23arquitecturas, 10aspectos

conceptuales, 2ATM, 12autenticación, 52autentificación, 35

seguridad, 133

B-ISDN, 10base

de conocimiento, 69modelado, 69

bases de datos, 2broadcasting, 21

código, 88

CDS, 37clases, 79cliente, 97, 99, 102, 177coherencia

control de, 67COM, 38, 40computación

distribuida, 88entorno de, 37

conclusiones, 168confidencialidad

seguridad, 132configuración, 178conocimiento

abstracto, 59cadena del, 60concreto, 59de control, 58declarativo, 57definición, 60fuentes, 60tipos de, 59

controlde acceso, 52

control de accesoseguridad, 133

CORBA, 42, 88CPA, 113CPB, 113

186

ÍNDICE ALFABÉTICO 187

dígitoverificador, 135

DARPA, 16datagrama, 17, 23

estructura, 18DCE, 37, 39DCOM, 38, 40

funcionamiento, 41desencriptar

datos, 136DFS, 37direccionamiento, 21dominio, 25DTS, 37

encapsulamiento, 81encriptar

datos, 136Ethernet, 12, 23excepciones, 87

FTP, 26futuros

trabajos, 168

gateways, 20GDS, 37grafos, 73, 127

herencia, 83hipótesis, 4HTTP, 26

IDL, 42IIS, 26impacto

de la investigación, 5implementación

prueba, 157

InputStream, 98integridad

seguridad, 132Internet, 2, 14, 26intranet, 26introducción

a la seguridad, 132a los protocolos de comuni-

cación de datos, 8a los sistemas distribuidos, 29al producto desarrollado, 105

IP, 16, 17IPX, 12ISO, 10

Java, 4, 27, 80, 85, 176características, 86invocación remota de méto-

dos, 44modelo de objeto distribuido

de, 45runtime, 176

JDBC, 2, 88JDK, 47, 49justificación

del estudio, 5JVM, 45, 50

kerberos, 42

LAN, 9lenguaje

orientado a objetospropiedades, 80

listade adyacencia, 75

métodos


de comunicación, 27marco

conceptual, 6matriz

de adyacencia, 74MIT, 42modelos

de diseño de programas, 6modus ponens, 64modus tollens, 64motor

de inferencia, 69motor de inferencia, 62multihilo, 87MySQL, 106

navegador, 26no repudio

seguridad, 133

objetivogeneral, 3

objetivosespecíficos, 4

objeto, 78, 79componente distribuidomodelo de, 38

remoto, 91objetos

invocación remota de méto-dos, 50

OCE, 37, 38ODBC, 2OLE, 38OO, 82, 86ORB, 42ORPC, 41OSI

función, 11funciones de los niveles, 11modelo de referencia, 10niveles, 10

OutputStream, 98

panelde control, 178

pasarargumentos y valoresde retorno, 49

plataformaindependencia de la, 86

polimorfismo, 85POO, 77POP3, 27procesos, 180producto

desarrollo, 105programación

orientada a objetos, 77protocolos

de comunicación de datos, 8prototipo

diferentes versiones, 106objetivos, 106

pruebaaplicación externaventa de boletos, 162

de transmisiónde paquetes, 160

PYMES, 5

read.dat, 141reglas

compilación, 67encadenamiento, 66, 67


RMI, 45, 50, 88, 107, 138, 141,177

cliente de, 95de Java, 48capas, 46

invocación remota de méto-dos, 6

rmic, 92rmiregistry, 93RML, 88routing, 20RPC, 35, 36, 38, 41ruteo, 19

seguridad, 87en transmisión de información,

135física, 133nivel aplicación, 133nivel usuario, 137niveles de información, 132política de, 89

servidor, 96, 176, 179centralizado, 110

servidoresde nombres, 24descentralizados, 111

sesiónremota, 109

sistemade dominios, 24de integración, 146, 152diagramaen bloque, 138

experto, 3basado en reglas, 105componentes, 58

definición, 57sistemas

cliente / servidor, 30distribuidos, 29expertos, 57basados en reglas, 62clasificación, 61

SMTP, 26socket, 96, 102

servidor, 97sockets, 32SPX, 12SQL, 4, 106, 107, 141, 145SSL, 48, 52stub

del cliente, 36del servidor, 36

stubs, 92subredes, 21

TCP, 16, 27, 31, 34, 48TCP/IP, 10, 12, 15, 32, 107

protocolo, 14protocolos que trabajan junto

con, 26tecnología

cliente / servidor, 2Telnet, 26Token Ring, 12transporte

seguridad en el, 52TRP, 117, 119, 124

UDP, 27, 34, 48UNIX, 33

VNC, 109VPN, 109


WAN, 9Weiss y Kulikowski

metodología de, 68

YOSUKO, 105, 107, 113, 115, 127,138, 140, 141

manual de usuario, 176objetos, 172

maestría en informática y...

Documents