Tecnológico de Estudios Superiores de Tianguistenco

División de Ingeniería en Sistemas Computacionales

MATERIA
Sistemas Distribuidos

Nombre del Alumno:

Edwin David Gil Almazán

Grupo:3802
Semestre: 8vo

Nombre del Docente

ISC. Alejandro González Zeta

PERIODO ESCOLAR
MARZO – AGOSTO 2018
 Tianguistenco, Estado de México, 20 abril de 2020

3.2 Objetos distribuidos.

OBJETOS DISTRIBUIDOS
Es aquel que está gestionado por un servidor y sus clientes invocan sus métodos utilizando
un "método de invocación remota". El cliente invoca el método mediante un mensaje al
servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado
se devuelve al cliente en otro mensaje.

OBJETOS DISTRIBUIDOS
Definición:
En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un
servidor y sus clientes invocan sus métodos utilizando un “método de invocación remota”.
El cliente
invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el
método del
objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.
Tecnologías orientadas a los objetos distribuidos:
Las tres tecnologías importantes y más usadas en este ámbito son:
1.         RMI.- Remote Invocation Method.- Fue el primer framework para crear sistemas
distribuidos de Java. El sistema de Invocación Remota de Métodos (RMI) de Java permite,
a un objeto que se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de
otro objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje de
programación Java, es decir, que permite la comunicación entre objetos creados en este
lenguaje.
2.         DCOM.- Distributed Component Object Model.- El Modelo de Objeto
ComponenteDistribuido, esta incluido en los sistemas operativos de Microsoft. Es un juego
deconceptos e interfaces de programa, en el cual los objetos de programa del cliente,
pueden solicitar servicios de objetos de programa servidores en otras computadoras dentro
de una red. Esta tecnología esta asociada a la plataforma de productos Microsoft.
3.         CORBA.- Common Object Request Broker Architecture.- Tecnología introducida
por el Grupo de Administración de Objetos OMG, creada para establecer una plataforma
para la gestión de objetos remotos independiente del lenguaje de programación.
 Ventajas de las Base de Datos Distribuidas

1. • Descentralización.- En un sistema centralizado/distribuido, existe un administrador que

controla toda la base de datos, por el contrario en un sistema distribuido existe un
administrador global que lleva una política general y delega algunas funciones a
administradores de cada localidad para que establezcan políticas locales y así un trabajo
eficiente.
2. • Economía: Existen dos aspectos a tener en cuenta.
 El primero son los costes de comunicación; si las bases de datos están muy
dispersas y las aplicaciones hacen amplio uso de los datos puede resultar más
económico dividir la aplicación y realizarla localmente.
 El segundo aspecto es que cuesta menos crear un sistema de pequeñas
computadoras con la misma potencia que un único computador.
3. • Mejora de rendimiento: Pues los datos serán almacenados y usados donde son
generados, lo cual permitirá distribuir la complejidad del sistema en los diferentes sitios de
la red, optimizando la labor.
4. • Mejora de fiabilidad y disponibilidad: La falla de uno o varios lugares o el de un enlace
de comunicación no implica la inoperatividad total del sistema, incluso si tenemos datos
duplicados puede que exista una disponibilidad total de los servicios.

5. • Crecimiento: Es más fácil acomodar el incremento del tamaño en un sistema distribuido,

por que la expansión se lleva a cabo añadiendo poder de procesamiento y
almacenamiento en la red, al añadir un nuevo nodo.
6. • Flexibilidad: Permite acceso local y remoto de forma transparente.
7. • Disponibilidad: Pueden estar los datos duplicados con lo que varias personas pueden
acceder simultáneamente de forma eficiente. El inconveniente, el sistema administrador
de base de datos debe preocuparse de la consistencia de los mismos.
8. • Control de Concurrencia: El sistema administrador de base de datos local se encarga de
manejar la concurrencia de manera eficiente.
 3.2.1 RMI

RMI es una tecnología desarrollada por Sun para permitir la colaboración de objetos que
están localizados remotamente. Esta tecnología se enmarca en la idea de permitir
colaboración entre Objetos Remotos. La idea no es que los objetos se comuniquen a través
de la programación del usuario de protocolos estándares de red.   La idea es tener un objeto
cliente, donde podamos podamos completar un requerimiento de datos. El cliente luego
prepara el requerimiento que envía a un objeto ubicado en un servidor. El objeto remoto
prepara la información requerida (accediendo a bases de datos, otros objetos, etc).
Finalmente el objeto remoto envía la respuesta al cliente. En lo posible esta interacción
debería ser lo más semejante posible a requerimientos hechos localmente.
En principio se puede anhelar la colaboración de objetos escritos en cualquier lenguaje (no
es el caso de RMI). Esta idea no es simple de lograr, corresponde al esfuerzo del grupo
OMG (Object Management Group, www.omg.org) los cuales propusieron CORBA
(Common Object Request Broker Architecture), el cual define un mecanismo común para
descubrir servicios e intercambiar datos. CORBA usa Object Request Broker (ORB) como
traductores universales para la comunicación entre objetos. Los objetos remotos hablan a
través de estos ORB. El protocolo de comunicación entre objetos y ORB es llamado
Internet Inter-ORB Protocol o IIOP.
La opción propuesta por Microsoft para comunicar objetos remotos es COM (Component
Object Model). Hoy este modelo parece haber sido superado por la tecnología .NET.
Cuando el cliente y servidor son escritos en Java, la generalidad y complejidad de CORBA
no es requerida. En este caso Sun desarrolló RMI, un mecanismo más simple especialmente
pensado para comunicación entre aplicaciones Java.

Invocación Remota de Objetos (RMI)

La idea suena simple, si tenemos acceso a objetos en otras máquinas, podemos llamar a
métodos de ese objeto remoto. RMI maneja los detalles de enviar los parámetros, el objeto
remoto debe ser activado para ejecutar el método y los valores deben ser retornados de
regreso al llamador, ver Figura 1.
 Figura 1: Invocación remota de objetos

3.2.2 Corba
CORBA (Common Object Request Broker Architecture) es un estándar definido por el
grupo de gestión de objetos (OMG) que permite el funcionamiento conjunto de
componentes de software escritos en distintos lenguajes informáticos y que se ejecutan en
distintos sistemas.
CORBA es un estándar para distribuir objetos a través de redes de modo que las
operaciones en dichos objetos puedan llamarse de forma remota. CORBA no está asociado
con ningún lenguaje de programación en particular y cualquier lenguaje que tenga un
enlace CORBA puede utilizarse para llamar e implementar objetos CORBA. Los objetos se
describen en una sintaxis denominada IDL (Interface Definition Language).
CORBA incluye cuatro componentes:
Intermediario para solicitudes de objetos (ORB)
El intermediario para solicitudes de objetos (ORB) maneja la comunicación, ordenación y
desordenación de parámetros, de modo que el manejo de parámetros es transparente para
aplicaciones de cliente y servidor CORBA.
Servidor CORBA
El servidor CORBA crea objetos CORBA y los inicializa con un ORB. El servidor coloca
las referencias a los objetos CORBA dentro de un servicio de denominación de modo que
los clientes puedan acceder a los mismos.
Servicio de nombres
El servicio de denominación mantiene referencias a objetos CORBA.
Nodo CORBARequest
El nodo CORBARequest actúa como cliente CORBA.
El siguiente diagrama muestra las capas de comunicación entre IBM® Integration Bus y
CORBA.

El diagrama ilustra los pasos siguientes.

Las aplicaciones de servidor CORBA crean objetos CORBA y colocan las referencias a
objetos en un servicio de denominación de modo que los clientes puedan llamar a los
objetos.
En el momento de despliegue, el nodo contacta con un servicio de denominación para
obtener una referencia de objeto.
Cuando llega un mensaje, el nodo utiliza la referencia de objeto para llamar a una operación
en un objeto del servidor CORBA.
 3.2.3 COM/DCOM

LA TECNOLOGIA DE OBJETOS DISTRIBUIDOS. (s. f.). Recuperado 20 de abril de

Que es COM y DCOM
Primero COM en Microsoft es la comunicación entre objetos para la comunicación de
ordenadores distintos en una red LAN , WAN incluso en internet ahora con DCOM una
aplicación puede ser distribuida en lugares donde  dan más sentido al cliente como vemos
DCOM es la evolución por así decirlo de COM y al hacer una aplicación en DCOM esta
maneja bajos protocolos de red .

DCOM es una extensión de COM, y éste define como los componentes y sus clientes
interactúan entre sí. Esta interacción es definida de tal manera que el cliente y el
componente pueden conectar sin la necesidad de un sistema intermedio. El cliente llama a
los métodos del componente sin tener que preocuparse de niveles más complejos.
DCOM es una evolución lógica de COM, se pueden utilizar los componentes creados en
aplicaciones basadas en COM, y trasladarlas a entornos distribuidos. DCOM maneja
detales muy bajos de protocolos de red, por lo que uno se puede centrar en la realidad de
los negocios: proporcionar soluciones a clientes.

La arquitectura DCOM
DCOM es una extensión de COM, y éste define como los componentes y sus clientes
interactúan entre sí. Esta interacción es definida de tal manera que el cliente y el
componente pueden conectar sin la necesidad de un sistema intermedio. El cliente llama a
los métodos del componente sin tener que preocuparse de niveles más complejos. La Figura
1 ilustra esto en la notación de COM
Los Componentes y su reutilización
Muchas aplicaciones distribuidas no están desarrolladas
Al existir infraestructuras de hardware, software, componentes, al igual que herramientas,
se necesita poder integrarlas y nivelarlas para reducir el desarrollo y el tiempo de trabajo y
coste. DCOM toma ventaja de forma directa y transparente de los componentes COM y
herramientas ya existentes. Un gran mercado de todos los componentes disponibles haría
posible reducir el tiempo de desarrollo integrando soluciones estandarizadas en las
aplicaciones de usuario. Muchos desarrolladores están familiarizados con COM y pueden
aplicar fácilmente sus conocimientos a las aplicaciones distribuidas basadas en DCOM.
Cualquier componente que sea desarrollado como una parte de una aplicación distribuida es
un candidato para ser reutilizado. Organizando los procesos de desarrollo alrededor del
paradigma de los componentes permite continuar aumentando el nivel de funcionalidad en
las nuevas aplicaciones y reducir el tiempo de desarrollo.
Diseñando para COM y DCOM se asegura que los componentes creados serán útiles ahora
y en el futuro.

COM
El cliente debe realizar las siguientes tareas:
Iniciar la librería COM
Obtener la interfaz
Manipular el objeto a través de su interfaz
Liberar las interfaces
Finalizar la librería COM
Para iniciar la librería COM hay que llamar al método del API COM CoInitialize:
            hr = CoInitialize(NULL);
            if ( SUCCEEDED(hr) )
            {
                        ...
            }
El método CoInitialize inicializa la librería en el thread de ejecución desde el que se
invoque. Es necesario llamar a CoInitialize desde cada thread de la aplicación que quiera
acceder a objetos COM.

OBTENER LA INTERFAZ
Para obtener la interfaz inicial llamamos al método CoCreateInstance, este creará una
nueva instancia de un objeto COM y nos devolverá un puntero a su interfaz.
            IUnknown *pIUnknown = NULL;
            hr = CoCreateInstance(CLSID_UserInfo, NULL,
                                   CLSCTX_INPROC_SERVER, IID_IUnknown,
                                   (LPVOID *)&pIUnknown);
            if (SUCCEEDED(hr))
            {....}

A través del puntero a IUnknow obtener el puntero a la interfaz IUserInfo

                        hr = pIUnknown->QueryInterface(IID-IUserInfo,
                                   (LPVOID *)&pIUserInfo);
                                   if (SUCCEEDED(hr))
                                               {\\manipulación del objeto}

LIBERAR LAS INTERFACES

para liberar las interfaces hay que llamar al método Release, si el objeto COM no tiene más
interfaces referenciadas se borrara automaticamente:

            pIUserInfo->Release();
            pIUnknown->Release();

FINALIZAR LAS LIBRERIAS

La librería COM se finaliza a través del método CoUninitialize, una vez llamado a este
método no se podrá seguir llamando a funciones de la librería COM ni manipulando objetos
COM.

DCOM
En el menú Archivo , seleccione la opción Nuevo proyecto, seleccione EXE estándar y, a
continuación, haga clic en Aceptar. De forma predeterminada, se crea Form1.
En el menú Proyecto, haga clic en la opción Propiedades del proyecto y, a continuación,
seleccione la ficha General.
En el campo Nombre de proyecto, escriba DCOMDemo_Cli.
En el campo Descripción del proyecto, escriba DCOMDemo_Cli Proyecto - Cliente.
En el menú Proyecto, haga clic en Referencias. En la lista de referencias disponibles,
seleccione DCOMDemo_Svr - Servidor.
Coloque un botón de comando en Form1 y cambie el título del botón por Ejecutar.
Coloque el código siguiente en el evento de clic del botón
En el menú Archivo, seleccione Guardar como y, a continuación, guarde el proyecto en la
carpeta c:\DCOMDemo\Client del cliente.
Presione la tecla F5 para ejecutar el cliente en el IDE y probarlo.
En el menú Archivo, seleccione Generar DCOMDemo_Cli para compilar el cliente y, a
continuación, cierre Visual Basic.

DCOM
Distributed Component Object Model (DCOM), en español Modelo de Objetos de
Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar
componentes software distribuidos sobre varios ordenadores y que se comunican entre sí.
Extiende el modelo COM de Microsoft y proporciona el sustrato de comunicación entre la
infraestructura del servidor de aplicaciones COM+ de Microsoft. Ha sido abandonada en
favor del framework .NET.1 2
La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC, o más
específicamente la versión mejorada de Microsoft, conocida como MSRPC.
En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas
de
    Aplanamiento - Serializar y deserializar los argumentos y valores de retorno de las
llamadas a los métodos "sobre el cable".
    Recolección de basura distribuida, asegurándose que las referencias mantenidas por
clientes de las interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha caído o
la conexión de red se pierde.
Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC como el
mecanismo RPC subyacente bajo DCOM. DCE/RPC define reglas estrictas en cuanto al
aplanamiento y a quién es responsable de liberar la memoria.
DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas
tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet.
Sin embargo, las dificultades que suponía conseguir que estas tecnologías funcionasen a
través de cortafuegos y sobre máquinas inseguras o desconocidas, significó que las
peticiones HTTP normales, combinadas con los navegadores web les ganasen la partida.
Microsoft, en su momento intentó y fracasó anticiparse a esto añadiendo un transporte extra
HTTP a DCE/RPC denominado "ncacn_http" (Connection-based, over HTTP).
 Referencias:
2020, de https://cnesther.wordpress.com/2012/06/15/unidad-4-la-tecnologia-de-objetos-
distribuidos/

OBJETOS DISTRIBUIDOS. (s. f.). Recuperado 20 de abril de 2020, de

https://sistemasdistribuidosetitc.weebly.com/objetos-distribuidos.html

(s. f.). RMI: Remote Method Invocation. Recuperado 20 de abril de 2020, de

http://profesores.elo.utfsm.cl/%7Eagv/elo330/2s09/lectures/RMI/RMI.html
Avilez, J. A. M. (s. f.). Unidad 4 COM/DCOM. Recuperado 20 de abril de 2020, de
https://comdcom96.blogspot.com/p/unidad-4-comdcom.html