1.
Ing. Raúl Jaziel torres torres <br />Matrícula: 1162800<br />Sistemas Distribuidos<br />

2.
Introducción<br />A lo largo del tiempo, se ha pretendido lograr que el<br />procesamiento de la información no se haga en un solo<br />equipo, sino que mas bien se haga en diferentes incluso<br />que estén en lugares lejanos.<br />Es así como nacieron los sistemas distribuidos, en esta<br />presentación conoceremos las principales plataformas<br />que trabajan como sistemas distribuidos.<br />Al finalizar se escogerá una sola para implementar el<br />proyecto propuesto, mostrando las razones por las cuales<br />se eligió .<br />

3.
Definición Sistemas Distribuidos<br />Un sistema distribuido se define como una colección de computadores<br />autónomos conectados por una red, y con el software distribuido<br />adecuado para que el sistema sea visto por los usuarios como una<br />única entidad capaz de proporcionar facilidades de computación.<br />Entre las plataformas en las cuales se pueden implementar esta<br />metodología están:<br />Sockets<br />CORBA<br />RMI<br />DCOM<br />SERVLETS<br />Java Beans<br />

4.
Sockets<br />Son puntos o mecanismos de comunicación entre procesos que<br />permiten que un proceso que se ejecuta en un ordenador, hable (emita<br />o reciba información) con otro proceso, incluso estando estos<br />procesos en distintas máquinas de una red. <br />Las implementaciones de sockets soportan los siguientes protocolos<br />de comunicaciones:<br />Dominio Unix<br />Dominio Internet (TCP/IP)<br />Dominio Xerox NS<br />La comunicación entre procesos a través de sockets se basa en la<br />filosofía CLIENTE-SERVIDOR<br />

5.
Sockets<br />El mecanismo de comunicación vía sockets tiene los<br />siguientes pasos: <br />El proceso servidor crea un socket con nombre y espera la conexión. <br /> El proceso cliente crea un socket sin nombre. <br />El proceso cliente realiza una petición de conexión al socket servidor. <br />El cliente realiza la conexión a través de su socket mientras el proceso servidor mantiene el socket servidor original con su nombre. <br />

6.
CORBA<br />Es un middlewaremarco de trabajo estándar y abierto<br />de objetos distribuidos que permite a los componentes<br />en la red interoperar en un ambiente común independiente de la<br />plataforma, lenguaje de desarrollo, sistema operativo o el tipo<br />de red que se este utilizando.<br />Trabaja con 2 pilares fundamentales, que son: ORB (Object<br />RequestBroker), que es un componente software que dirige la<br />comunicación entre objetos CORBA, y el segundo es el IDL, que<br />se encarga de definir las interfaces de los componentes de la<br />aplicación sobre los que se construyen las aplicaciones CORBA<br />

7.
CORBA<br />Tres de las principales diferencias entre el modelo de<br />objetos de CORBA y los modelos tradicionales radican<br />en la forma semi-transparente de distribuir los objetos<br />en CORBA, el tratamiento de las referencias a objetos y<br />el uso de los llamados adaptadores de objetos (como el<br />BOA -Basic ObjectAdapter-).<br />Para un cliente CORBA, una llamada a un método<br />remoto es exactamente igual a una llamada a un<br />método local. <br />

8.
RMI <br />Es el sistema de invocación remota de métodos, que<br />permite a un objeto que se está ejecutando en una<br />Máquina Virtual Java (VM) llamar a métodos de otro<br />objeto que está en otra VM diferente. RMI proporciona<br />comunicación remota entre programas escritos en Java<br />Las aplicaciones RMI normalmente comprenden dos<br />programas separados: un servidor y un cliente. RMI<br />proporciona el mecanismo por el que se comunican y se<br />pasan información del cliente al servidor y viceversa<br />

9.
RMI<br />Cuando se utiliza RMI para desarrollar aplicaciones distribuida,<br />se deben seguir los siguientes pasos:<br />Diseñar e implementar los componentes de la aplicación: Lo primero es definir la arquitectura de la aplicación y determinar los componentes que seran objetos locales y los que seran remotos.<br />Compilar fuentes y generar los Stubs: Este es un proceso de dos pasos. En el primer paso, se utiliza el compilador javac para compilar los ficheros fuentes de Java, los cuales contienen las implementaciones de las interfaces remotas, las clases del servidor, y del cliente. En el segundo paso es utilizar el compilador rmic para crear los stubs de los objetos remotos. RMI utiliza una clase stub del objeto remoto como un proxy en el cliente para que los clientes puedan comunicarse con un objeto remoto particular<br />

10.
RMI<br />Hacer accesible las Clases a través de la Red: Los ficheros de clases Java con sus interfaces remotas, los stubs y otras clases que necesitamos descargar en los clientes, deben estar accesible a través de un servidor Web.<br />Ejecutar la Aplicación: Se debe ejecutar o lanzar el registro de objetos remotos y luego el servidor y el cliente.<br />

11.
DCOM<br />El Modelo de Objeto Componente Distribuido, es un protocolo que<br />permite a componentes de software comunicarse de una manera<br />segura, eficiente y confiable con otros componentes, localizados en<br />otro computador de una red Microsoft.<br />La arquitectura DCOM esta basada en:<br />Objeto DCOM: Es un componente que soporta una o mas interfaces.<br />Interface DCOM: no es mas que un grupo predefinido de funciones relacionadas.<br />Clase DCOM : Es aquella que implementa una o mas interfaces.<br />Servidor DCOM: Provee la estructura necesaria alrededor de un objeto para hacerlo disponible a los clientes.<br />

12.
DCOM<br />Para implementar DCOM se pueden seguir estos pasos, usando<br />como lenguaje de programación el lenguaje Java.<br />Crear el IDL DCOM (y ODL) para su objeto<br />Generar GUIs para sus interfaces IDL<br />Crear el archivo de typelibrary<br />Crear los wrappers java para las clases DCOM en Java<br />Implementar sus clases DCOM en Java<br />Compilar su implementación<br />Registrar su clase Java<br />Escribir el Código Cliente<br />Compilar el Cliente<br />Registrar el Cliente<br />Iniciar el cliente<br />

13.
SERVLETS<br />Son módulos que extienden los servidores orientados<br />a petición-respuesta, como los servidores web<br />compatibles con Java.<br />Los Servlets son un sustituto eficaz de los CGI ‘s ya que<br />proveen la forma de generar documentos dinámicos<br />que son fáciles de escribir y ejecutar. También evitan el<br />problema de desarrollar la programación según la<br />plataforma utilizada. <br />

14.
SERVLETS<br />La interfaz ServletRequest permite al servlet acceder a<br />información como, los nombres de parámetros pasados<br />por el cliente, el protocolo usado por el cliente, y los<br />nombres de los hosts remotos que hacen la solicitud y el<br />servidor que la recibe. <br />Esta interfaz permite a los servlets el acceso a métodos<br />que permiten manejar la presentación de la respuesta<br />como salida en el navegador, a través de los cuales<br />consiguen los datos desde el cliente que usa protocolos<br />como HTTP POST , etc.<br />

15.
Java Beans<br />Un Java Bean o Bean es un componente hecho en<br />software que se puede reutilizar y que puede ser<br />manipulado de forma visual por una herramienta de<br />programación en lenguaje Java.<br />Para tal manipulación se define una interfaz en el<br />momento de diseño, a través de la cual se puede<br />interrogar al componente y conocer sus propiedades y<br />los tipos de eventos o sucesos que puede generar como<br />respuesta a diversas acciones.<br />

16.
Las características de los Java Beans son:<br />Introspection: Permite analizar a la herramienta de programación o IDE como trabaja el Bean<br />Customization: El programador puede alterar la apariencia y la conducta del Bean. <br />Events: Informa al IDE de los sucesos que puede generar en respuesta a las acciones del usuario o del sistema, y también los sucesos que puede manejar. <br />Properties: Una propiedad es un atributo del JavaBean que afecta a su apariencia o a su conducta<br />Persistence: Se puede guardar el estado de los Beans que han sido personalizados por el programador, cambiando los valores de sus propiedades <br />

17.
Arquitectura Elegida para el Proyecto<br />La arquitectura que elegí para que en dado caso se<br />implementara el proyecto propuesto como sistema<br />distribuido es: Sockets<br />Las razones por las cuales elegí esta arquitectura son:<br />Fácil implementación<br />Se tiene un mayor control sobre la comunicación<br />Consume menos ancho de banda<br />Es mas seguro<br />

18.
Implementación<br />Como vimos en la presentación la implementación<br />de sockets se hacen mediante 4 pasos que son:<br />El proceso servidor crea un socket con nombre y espera la conexión. <br /> El proceso cliente crea un socket sin nombre. <br />Para estos primeros dos pasos tenemos que escoger el<br />tipo de socket y el dominio sobre el cual se quiere<br />implementar este.<br />

19.
Implementación<br />Entre los diferentes tipos que existen y dominios elegí<br />los siguientes:<br />SOCK_STREAM: Sirve para establecer comunicaciones<br />confiables en modo conectado ningún dato transmitido se<br />pierde, los datos llegan en el orden que han sido<br />transmitidos). En eldominioInternet está asociado al protocolo<br />TCP. <br />AF_INET: Protocolos de Internet, donde el cliente y el servidor<br />pueden estar en cualquier máquina de la red Internet. <br />

20.
Implementación<br />Los pasos que siguen son:<br />3) El proceso cliente realiza una petición de conexión al socket servidor. <br />4) El cliente realiza la conexión a través de su socket mientras el proceso servidor mantiene el socket servidor original con su nombre. <br />En el servidor se haría asi la llamada:<br />intsocket ( intdominio, inttipo, intprotocolo ) crea un<br /> socket sin nombre de un dominio, tipo y protocolo específico <br /> dominio : AF_INET, <br /> tipo : SOCK__STREAM <br /> protocolo : 0 ( protocolo por defecto ) <br />

21.
Implementación<br />intbind ( intdfServer, structsockaddr* direccServer, intlongDirecc ) <br />intlisten ( intdfServer, intlongCola ) <br />Intaccept ( intdfServer, structsockaddr* direccCliente, int* longDireccCli) <br />En el cliente se seguirían las siguientes instrucciones:<br />intsocket ( intdominio, inttipo, intprotocolo ) <br />intconnect ( intdfCliente, structsockaddr* direccServer, intlongDirecc ) <br />

22.
Implementación<br />Por último en esta tabla se muestra las llamadas que se<br />producirían en el sistema:<br />