3.2 Objetos Distribuidos.
3.2 Objetos Distribuidos.
MATERIA
Sistemas Distribuidos
Grupo:3802
Semestre: 8vo
PERIODO ESCOLAR
MARZO – AGOSTO 2018
Tianguistenco, Estado de México, 20 abril de 2020
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
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.
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.
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))
{....}
pIUserInfo->Release();
pIUnknown->Release();
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/