II. MODELOS FUNDAMENTALES DE LOS SISTEMAS DISTRIBUIDOS Maestría en Ingeniería de Sistemas y Computación Profesor: MSc. Henry Alberto Diosa
CRÉDITOS Colouris, George; Dollimore, Jean and Kindberg, Tim. Sistemas Distribuidos. Conceptos y Diseño. Addison Wesley. Commer, Douglas E. Internetworking with TCP/IP. Vol I. Prentice Hall. 1.991. Tanenbaum, Andrew S. Sistemas Operativos Modernos.Prentice Hall.1.992 Newman, Alexander et al. Using JAVA. Que Corporation. 1996 Hamilton, Dave y Mickey, Williams. Programming Windows NT 4. SAMS Publishing. 1996. Baker, Seán. CORBA Distributed Objects. Addison-Wesley.1997 Cockaine, William R.; Zyda,Michael. Mobile Agents.Manning Publications Co.1998. St. Laurent, Simon; Johnston, Joe;Dumbill, Edd. Programming Web Services with XML-RPC.O Reilly & Associates, Inc. 2001 Vinoski, Steve. Where is Middleware?. IEEE Internet Computing. Marzo-Abril 2002. págs. 83-85.
SOBRE LOS MODELOS ARQUITECTÓNICOS Ver revisión sucinta a arquitecturas de software
Capas de servicios hardware y software en un Sistema Distribuido Servicios y aplicaciones Middleware Sistema operativo( Windows XP, Sun OS, Solaris, Mac OS, Linux, UNIX) Plataforma Hardware de red y computador
MIDDLEWARE
Qué es y dónde está el Middleware? PROCESOS DE USUARIO APLICACIÓN DESARROLLO DE APLICACIONES INTERFACE DE USUARIO MIDDLEWARE DATOS GESTIÓN DE SISTEMAS SISTEMA DE DISTRIBUCIÓN GESTIÓN DE DATOS
Cuáles tecnologías han soportado el Middleware? Remote Procedure Call Pipes Sockets CORBA/DCOM RMI de Java XML-RPC (Progenitor de los servicios Web) Objetos y Agentes de Software Móviles
REMOTE PROCEDURE CALL(I) MÁQUINA CLIENTE STUB DEL CLIENTE STUB DEL SERVIDOR MÁQUINA SERVIDORA PARAM. EMPACADOS LLAMADA PARAM. DESEMPACADOS LLAMADA CLIENTE SERVIDOR REGRESO RESULTADOS DESEMPACADOS RESULTADOS DESEMPACADOS REGRESO NÚCLEO NÚCLEO
REMOTE PROCEDURE CALL(II) MÁQUINA CLIENTE STUB DEL CLIENTE STUB DEL SERVIDOR MÁQUINA SERVIDORA MENSAJE.. n=sum(4,7) SUM 4 7 SUM 4 7 sum(i,j) Int i,j; { Return (i+j); } NÚCLEO NÚCLEO CÁLCULO REMOTO DE SUM (4,7)
PIPES:CANALES (I) * Forma de comunicación de procesos. * Un proceso envía datos por un extremo del tubo y otro proceso lee los datos en el otro extremo. Proceso 1 Proceso 2 Escribe Lee
ANONYMOUS PIPES(I) * Pipes sin nombre * En una sola direccion * No trabajan sobre la red, el cliente y el servidor deben habitar la misma máquina. * Procesos relacionados: Padre - Hijo
ANONYMOUS PIPES(II) STD OUT STD IN Padre H1 H3 STD OUT H4 STDIN H2 Hijo
ANONYMOUS PIPES(III) PADRE HIJO SALVAR STDIN Y STDOUT CREAR HANDLES CREATEPIPE() ASIGNAR STDIN,STDOUT A HANDLE CREATEPROCESS( Hijo ) RESTAURAR STDIN Y STDOUT WRITEFILE( Hacia el hijo ) READFILE( Del hijo ) PROCESO CREADO READFILE( Del padre ) WRITEFILE( Hacia el padre )
NAMED PIPES(I) Utilizan un nombre. Unidireccional o bidireccional. Trabajan en red. Pipes para comunicación entre el servidor y uno o mas clientes.
NAMED PIPES(II) SERVIDOR CREAR CONTROLADOR CREATE NAMED PIPE CONNECT NAMED PIPE CLIENTE CREAR CONTROLADOR CREATE FILE CREATE THREAD READ FILE WRITE FILE WRITE FILE READ FILE DISCONNECT NAMED PIPE
SOCKETS(I)
SOCKETS(II) PROC. EMISOR ESPACIO DEL USUARIO PROC. RECEPTOR PROTOCOLOS DE RED CONTROLADORES DE INTERFACES DE RED HARDWARE
SOCKETS EN EL MODELO OSI SOCKET
INTERACCIÓN SOCKETs CLIENTE/SERVIDOR socket() socket() Open bind() Open bind() Bound Bound socket() Open connect() listen() accept() bind() recv() Connected recvfrom() closesocket() Cliente send() Listenning Bound connect() send() recv() Connected recvfrom() sendto() closesocket() Servidor
LOS NÚMEROS DE PUERTO
IMPLEMENTACIÓN DE SOCKETs EN JAVA
EL MODELO ORIENTADO A OBJETOS ENCAPSULACIÓN PRINCIPIO OPEN/CLOSE HERENCIA REUSABILIDAD POLIMORFISMO ABSTRACCIÓN
MODELO DE REFERENCIA OMA
CORBA CLIENTE IMPLEMENTACIÓN CON OBJETOS INVOCACIÓN DINÁMICA INTERFACES STUB IDL INTERFACE ORB DSI PLANTILLA IDL OA NÚCLEO ORB SERVICIOS CORBA FACILIDADES CORBA
COMO IMPLEMENTAR CORBA? PROCEDIMIENTO BÁSICO
CORBA:ESPECIFICACIÓN IDL DEFINICIÓN INTERFACE IDL //Archivo Ofic_Teatro.idl typedef float Precio; struct Lugar { char fila; unsigned long silla; }; interface Ofic_Teatro { readonly attribute string nombre; readonly attribute unsigned long num_sillas; Precio obtener_precio(in Lugar Lugar_escoge); boolean reserva_una_silla(in Lugar Lugar_escoge, in string Tarj_cradito); COMPILACIÓN ITERFACE IDL idl modificador Ofic_Teatro.idl PRODUCE: Ofic_Teatro.h para ser incluido en la implementación de la clase y en todos los clientes. Ofic_TeatroC.cpp: Archivo fuente a ser compilado e incluido en los clientes de Ofic_Teatro. Incluye el código requerido para hacer equerimientos remotos sobre objetos Ofic_Teatro (Stub) Ofic_TeatroS.cpp: Archivo fuente a ser compilado e inlcuido en la implementación de Ofic_Teatro como servidor que acepta requerimientos remotos (Skeleton)
EL CODIGO C++ PRODUCIDO //ARCHIVO Ofic_Teatro.h #include <CORBA.h> typedef CORBA::Float Precio; struct Lugar { CORBA::Char fila; CORBA::uLong silla; }; class Ofic_Teatro:public virtual CORBA::Object { public: virtual char* nombre() throw (CORBA::SystemException} virtual CORBA::Ulong num_sillas() throw (CORBA::SystemException) virtual Precio obtener_precio (const Lugar& Lugar_escoge) throw (CORBA::SystemException); virtual CORBA::Boolean reserva_una_silla (const Lugar& Lugar_escoge, const char* Tarj_credito) throw (CORBA::SystemException); };
IMPLEMENTACIÓN El programador debe implementar la interface de la clase en código C++, en este caso. Se puede denominar a la implementación Ofic_Teatro_i.h y Ofic_Teatro_i.cpp. La forma de encadenar este código a la interface puede ser: //Archivo Ofic_Teatro_i.h #include Ofic_Teatro.h class Ofic_Teatro_i:public virtual Ofic_TeatroBOAImpl { //declaración de atributos y métodos }; Luego como es costumbre se implementan los métodos u operaciones en otro archivo de Ofic_Teatro_i.cpp que debe incluir Ofic_Teatro_i.h
OBJETO SERVIDOR //c++ en archivo Srv_main.cpp #include Ofic_Teatro_i.h #include <iostream.h> int main() { //se crean los objetos servidores Ofic_Teatro_i mi_oficina(//parámetros de constructor) //forma de hacer disponible el objeto CORBA servidor CORBA::Orbix.imp_is_ready( Ofic_TeatroSrv ); cout << Servidor listo << endl;
REGISTRO DEL SERVIDOR El servidor debe ser registrado de tal manera que éste se ejecute automáticamente cuando un cliente usa un objeto Ofic_Teatro. El sistema mantiene un Implementation Repository(daemon) que hace un mapping del nombre del servidor al nombre del archivo ejecutable que implementa el mismo.para esto se usa el comando putit sobre la máquina local, así: $ putit Ofic_TeatroSrv < camino completo.exe del servidor> c:\> putit Ofic_TeatroSrv < camino completo.exe del servidor>
ESCRIBIR UN CLIENTE #include Ofic_Teatro.h #include <iostream.h> int main() { Ofic_Teatro_var reserva; //Ofic_Teatro_var es generada por compiladoridl reserva = Ofic_Teatro::_bind( :Ofic_TeatroSrv ); CORBA::String_var sunombre = reserva->nombre(); cout << Ël nombre es << sunombre << endl; cout << Número sillas << reserva ->num_sillas() <<endl; Lugar p= { D, 45}; cout << El precio de la silla D45 es << reserva->obtener_precio(p); if (reserva->reserva_una_silla(p, 1234890674689032 )) cout << La silla ha sido reservada con éxito << endl; else cout << La silla no pudo ser reservada << endl; }
REMOTE METHOD INVOCATION RMI permite que un objeto que se ejecuta bajo el control de una JVM pueda invocar métodos de un objeto que se encuentre en ejecución bajo el control de una JVM instalada en un host diferente. La máquina que contiene el objeto cuyos métodos se pueden invocar se llama servidor. La máquina que invoca métodos sobre el objeto remoto se llama cliente.
ARQUITECTURA RMI
SEGURIDAD RMI no implementa ninguna política de seguridad en la capa de transporte. Las comunicaciones se realizan en "texto plano", por lo que, conceptos de seguridad no se tienen en cuenta. El servidor RMI no autentifica las peticiones de acceso sobre sus objetos, de forma que un posible cliente ilícito podría tener acceso a los objetos.
PAQUETES DE JAVA RMI Cliente: java.rmi Define clases, interfaces y excepciones usadas por el cliente. Servidor: java.rmi.server Define clases, interfaces y excepciones usadas por el servidor. Localización de Objetos: java.rmi.registry Define clases, interfaces y excepciones usadas para nombrar y localizar objetos remotos. Recogida de basura: java.rmi.dgc Define clases, interfaces para recogida de basura distribuida.
PROCESO DE DESARROLLO 1. Definir la interface remota 2. Programar la clase implementación 3. Compilar la clase implementación 4. Ejecutar el compilador de stubs (rmic) con la clase compilada. 5. Arrancar el registro RMI en el servidor (rmiregistry) 6. Ejecutar la aplicación servidor. 7. Ejecutar la aplicación cliente.
XML-RPC Creado por Dave Winer de Userland Software, Bob Atkinson, Mohsen Al- Ghosein de Microsoft y Don Box de Developmentor. Permite efectuar llamados a funciones a través de redes soportándose en una arquitectura RPC que combina XML y el protocolo HTTP.
VENTAJAS DE XML-RPC Integración de múltiples ambientes computacionales que no requieran compartir estructuras de datos complejas. Ofrece a los integradores la oportunidad de usar un vocabulario y enfoque estándar para intercambiar información.
DESVENTAJAS DE XML-RPC Hereda la ineficiencia del protocolo HTTP Genera vulnerabilidad en los firewalls por reutilizar HTTP. No sirve para proyectos donde se desea escalar a un tiempo de transacción mínimo para millones de transacciones a la vez.
OBJETOS Y AGENTES DE SOFTWARE MÓVILES EL ENFOQUE PREDOMINANTE HASTA HOY CLIENTE......!!! SERVIDOR
OBJETOS Y AGENTES DE SOFTWARE MÓVILES EL ENFOQUE DE PROGRAMACIÓN REMOTA...... CLIENTE SERVIDOR
CONCEPTOS OSMs Y ASMs (I): LUGARES Y AGENTES APLICACIÓN COMPRAS VENTA TIQUETES VENTA FLORES GESTOR DIRECTORIO COMUNICADOR PERSONAL SERVIDOR DE APLICACIONES
CONCEPTOS OSMs Y ASMs (II): CÓDIGO Y ESTADO VIAJAN VENTA TIQUETES COMUNICADOR PERSONAL SERVIDOR DE APLICACIONES
CONCEPTOS OSMs Y ASMs (III): LOS AGENTES PUEDEN DIALOGAR?......? VENTA TIQUETES COMUNICADOR PERSONAL SERVIDOR DE APLICACIONES
CONCEPTOS OSMs Y ASMs (IV): LOS AGENTES PUEDEN CONECTARSE?......? VENTA TIQUETES COMUNICADOR PERSONAL SERVIDOR DE APLICACIONES
CONCEPTOS OSMs Y ASMs (V): AUTORIDADES VENTA FLORES VENTA TIQUETES X COMUNICADOR PERSONAL SERVIDOR DE APLICACIONES
CONCEPTOS OSMs Y ASMs (VI): PERMISOS... X? VENTA TIQUETES COMUNICADOR PERSONAL SERVIDOR DE APLICACIONES
Qué componentes soportan la tecnología de OSMs y ASMs? Lenguaje de programación para programar agentes y lugares. Un motor o interpretador para este lenguaje. Protocolos de comunicación que permitan a los motores residir en diferentes computadores para enviar e intercambiar agentes.
NORMATIVIDAD MASIF(Mobile Agent System Interoperability Facility) Especification Adoptada por OMG (Object Management Group) en Febrero de 1998
HERRAMIENTAS DE DESARROLLO Voyager Grasshopper Caffeine Aglets Odyssey
VENTAJAS Reducción de costos de comunicación Permite asincronía Genera mercado de Servicios
CLASIFICACIÓN DE MIDDLEWARE SEGÚN STEVE VINOVSKI RPC vs. Mensajería Asíncrona. Dependiente del lenguaje vs. Independiente del lenguaje. Propietario vs. Basado en estándares. Empotrado vs. De ámbito empresarial
MODELOS DE DISTRIBUCIÓN BIEN POSICIONADOS HOY OMG: CORBA, CCM, OMA y MDA Sun: Java, JavaBeans, EJB, JWSDP Microsoft: COM, OLE/ActiveX, COM+,.NET CLR Otras tecnologías Advantage Plex Hitachi Appgallery Groove Transceiver
Conceptos a considerar en arquitecturas de sistemas distribuidos
Modelo C/S Client invocation invocation Server result Server result Client Key: Process: Computer:
Servicios proporcionados por múltiples servidores Service Client Server Server Client Server
Servidor Proxy Client Proxy server Web server Client Web server
Procesos Peer-to-Peer (P2P) Application Coordination code Application Coordination code Application Coordination code
Código Móvil:Applets a) Cliente requiere resultados y descarga el código del applet Cliente Applet Web Server b) Cliente interactúa con el applet Cliente Applet Web Server
Cliente delgado/cliente robusto Estación de trabajo Presentación Presentación Presentación Presentación Presentación Función Función Función Gestion Datos Red Presentación Función Función Función Gestion Datos Gestion Datos Gestion Datos Gestion Datos Gestion Datos Presentación distribuida thin Presentación remota Función distribuida Gestión remota de datos Bases de datos distribuidas thick
Dispositivos móviles gateway Music service Alarm service Internet Discovery service Hotel wireless network Camera TV/PC Laptop PDA Guests devices
Requisitos de diseño de SD 1. Altas prestaciones (t de respuesta, throughput, balanceo de cargas) 2. QoS 3. Replicación y uso de caché 4. Fiabilidad (Tolerancia a fallos, seguridad)
MODELOS FUNDAMENTALES PARA RAZONAR SOBRE SISTEMAS DISTRIBUIDOS 1. Modelo de Interacción: Aborda las prestaciones y dificultad de poner límites temporales en un sistema distribuido. 2. Modelo de fallos: Intenta dar una especificación precisa de los posibles fallos en procesos y canales de comunicación. 3. Modelo de seguridad: Discute sobre las posibles amenazas para los procesos y canales de comunicación.
FACTORES SIGNIFICATIVOS DEL MODELO DE INTERACCIÓN 1. Prestaciones de los canales de comunicaciones: Latencia, ancho de banda, jitter o fluctuación del retardo 2. Relojes de computadores y eventos de temporización: Tasa de deriva de reloj y sincronización de relojes
VARIANTES DEL MODELO DE INTERACCIÓN 1. Sistemas distribuidos síncronos: 1. Tiempo de ejecución de cada etapa de un proceso tiene ciertos límites inferior y superior. 2. Cada mensaje transmitido sobre un canal se recibe en un tiempo limitado conocido. 3. Cada proceso tiene un reloj local cuya tasa de deriva sobre el tiempo real tiene un límite conocido. 2. Sistemas distribuidos asíncronos. No hay limitaciones sobre: 1. La velocidad de procesamiento. 2. Los retardos de transmisión de mensajes. 3. Las tasas de deriva de reloj son arbitrarias.
EL ORDENAMIENTO DE EVENTOS X send 1 m 1 receive 4 receive Y 2 receive send 3 m 2 receive Physical time Z receive receive send A m 3 m 1 m 2 receive receive receive t 1 t 2 t 3
MODELO DE FALLO Fallos por omisión: Por omisión de procesos, por omisión de comunicaciones. Fallos arbitrarios Fallos de temporización Enmascaramiento de fallos Fiabilidad y comunicación uno a uno
MODELO DE SEGURIDAD 1. Protección de objetos 2. Aseguramiento de procesos e interacciones 3. Modelar amenazas de seguridad: A procesos, a canales de comunicación. 4. Técnicas para vencer las amenazas: Autenticación, criptografía, canales seguros. 5. Desarrollar modelos de seguridad.