Localización del Servidor
La comunicación de bajo nivel entre cliente y servidor por medio de paso de mensajes (por ejemplo sockets). Esto requiere:
Localizar la dirección del servidor: tanto dirección IP como número de puerto en el caso de sockets.
Enlazar con dicho servidor (verificar si esta sirviendo).
Estas tareas las realiza el resguardo cliente.
En el caso de servicios cuya localización no es estándar se recurre al enlace dinámico (dynamic binding).
Enlace Dinámico
Enlace dinámico: permite localizar objetos con nombre en un sistema distribuido, en concreto, servidores que ejecutan las RPC.
Tipos de enlace:
Enlace no persistente: la conexión entre el cliente y el servidor se establece en cada llamada RPC.
Enlace persistente: la conexión se mantiene después de la primera RPC:
Útil en aplicaciones con muchas RPC repetidas.
Problemas si lo servidores cambian de lugar o fallan.
Enlazador Dinámico
Enlazador dinámico (binder): Es el servicio que mantiene una tabla de traducciones entre nombres de servicio y direcciones. Incluye funciones para:
Registrar un nombre de servicio (versión).
Eliminar un nombre de servicio.
Buscar la dirección correspondiente a un nombre de servicio.
Como localizar al enlazador dinámico:
Ejecuta en una dirección fija de un computador fijo.
El sistema operativo se encarga de indicar su dirección.
Difundiendo un mensaje (broadcast) cuando los procesos comienzan su ejecución.
RPC: Protocolo Básico
cliente
servidor
Desempaqueta
la respuesta
Se registra con un servicio de nombres
(Gp:) recibe petición
(Gp:) Ejecuta el
procedimiento
(Gp:) envía petición
“enlaza con el servidor”
prepara parámetros, envía petición
Semántica Fallos
Problemas que pueden plantear las RPC:
El cliente no es capaz de localizar al servidor. [1]
Se pierde el mensaje de petición del cliente al servidor. [2]
Se pierde el mensaje de respuesta del servidor al cliente. [3]
El servidor falla después de recibir una petición. [4]
El cliente falla después de enviar una petición. [5]
Cliente
Servidor
?
[1]
[2]
[4]
[5]
Cliente no Puede Localizar al Servidor
El servidor puede estar caído
El cliente puede estar usando una versión antigua del servidor
La versión ayuda a detectar accesos a copias obsoletas
Cómo indicar el error al cliente
Devolviendo un código de error (-1)
No es transparente
Ejemplo: sumar(a,b)
Elevando una excepción
Necesita un lenguaje que tenga excepciones
Pérdida de Mensajes del Cliente
Es la más fácil de tratar.
Se activa una alarma (timeout) después de enviar el mensaje.
Si no se recibe una respuesta se retransmite.
Depende del protocolo de comunicación subyacente.
Pérdidas de Mensajes de Respuesta
Más difícil de tratar
Se pueden emplear alarmas y retransmisiones, pero:
¿Se perdió la petición?
¿Se perdió la respuesta?
¿El servidor va lento?
Algunas operaciones pueden repetirse sin problemas (operaciones idempotentes)
Una transferencia bancaria no es idempotente
Solución con operaciones no idempotentes es descartar peticiones ya ejecutadas
Un nº de secuencia en el cliente
Un campo en el mensaje que indique si es una petición original o una retransmisión
Fallos en los Servidores
El servidor no ha llegado a ejecutar la operación
Se podría retransmitir
El servidor ha llegado a ejecutar la operación
El cliente no puede distinguir los dos
¿Qué hacer?
No garantizar nada
Semántica al menos una vez
Reintentar y garantizar que la RPC se realiza al menos una vez
No vale para operaciones no idempotentes
Semántica a lo más una vez
No reintentar, puede que no se realice ni una sola vez
Semántica de exactamente una
Sería lo deseable
Fallos en los Clientes
La computación está activa pero ningún cliente espera los resultados (computación huérfana)
Gasto de ciclos de CPU
Si cliente rearranca y ejecuta de nuevo la RPC se pueden crear confusiones
Aspectos de Implementación
Protocolos RPC
Orientados a conexión
Fiabilidad se resuelve a bajo nivel, peor rendimiento
No orientados a conexión
Uso de un protocolo estándar o un específico
Algunos utilizan TCP o UDP como protocolos básicos
Coste de copiar información aspecto dominante en rendimiento:
buffer del cliente ? buffer del SO local ? red ? buffer del SO remoto + buffer del servidor
Puede haber más copias en cliente para añadir cabeceras
scatter-gather: puede mejorar rendimiento
RPC de Sun
Utiliza como lenguaje de definición de interfaz IDL:
Una interfaz contiene un nº de programa y un nº de versión.
Cada procedimiento específica un nombre y un nº de procedimiento
Los procedimientos sólo aceptan un parámetro.
Los parámetros de salida se devuelven mediante un único resultado
El lenguaje ofrece una notación para definir:
constantes
definición de tipos
estructuras, uniones
programas
RPC de Sun
rpcgen es el compilador de interfaces que genera:
Resguardo del cliente
Resguardo del servidor y procedimiento principal del servidor.
Procedimientos para el aplanamiento (marshalling)
Fichero de cabecera (.h) con los tipos y declaración de prototipos.
Enlace dinámico
El cliente debe especificar el host donde ejecuta el servidor
El servidor se registra (nº de programa, nº de versión y nº de puerto) en el port mapper local
El cliente envía una petición al port mapper del host donde ejecuta el servidor
Ejemplo de Fichero IDL (Sun RPC)
struct peticion {
int a;
int b;
};
program SUMAR {
version SUMAVER {
int SUMA(peticion) = 1;
} = 1;
} = 99;
Programación con un Paquete de RPC
El programador debe proporcionar:
La definición de la interfaz (fichero idl)
Nombres de las funciones
Parámetros que el cliente pasa al servidor
Resultados que devuelve el servidor al cliente
El código del cliente
El código del servidor
El compilador de idl proporciona:
El resguardo del cliente
El resguardo del servidor
Programación con RPC
COMPILADOR C
COMPILADOR C
COMPILADOR C
COMPILADOR C
CABECERA
CABECERA
FICHEROS
FUENTE DEL
CLIENTE
FICHEROS
OBJETO DEL
CLIENTE
FICHEROS
OBJETO DEL
SERVIDOR
EJECUTABLE
DEL
CLIENTE
EJECUTABLE
DEL
SERVIDOR
FICHEROS
FUENTE DEL
SERVIDOR
OBJETO
RESGUARDO
EN CLIENTE
OBJETO
RESGUARDO
EN SERVIDOR
MONTADOR
MONTADOR
BIBLIOT.
RPC
BIBLIOT.
RPC
DESARROLLO
DE LA
INTERFAZ
DESARROLLO
DEL
CLIENTE
DESARROLLO
DEL
SERVIDOR
COMPILADOR IDL
RESGUARDO
EN SERVIDOR
RESGUARDO
EN CLIENTE
CABECERA
FICHERO
DE DEFINICIÓN
DE INTERFAZ
idl.x
repcgen
idl_svc.c
servidor.c
idl.h
idl_xdr.c
idl_clnt.c
cliente.c
Archivos para
el cliente
Archivos
comunes
Archivos para
el servidor
Esquema de una Aplicación
Entornos de Objetos Distribuidos
< Objetos Remotos>
Java RMI
CORBA
Motivación
La extensión de los mecanismos de RPC a una programación orientada a objetos dio lugar a los modelos de objetos distribuidos.
Ventajas:
Los métodos remotos están asociados a objetos remotos.
Más natural para desarrollo orientado a objetos.
Admite modelos de programación orientada a eventos.
Problemas:
El concepto de referencia a objeto es fundamental.
Objetos volátiles y objetos persistentes.
Objetos-Distribuidos
Características:
Uso de un Middleware: Nivel de abstracción para la comunicación de los objetos distribuidos. Oculta:
Localización de objetos.
Protocolos de comunicación.
Hardware de computadora.
Sistemas Operativos.
Modelo de objetos distribuidos: Describe los aspectos del paradigma de objetos que es aceptado por la tecnología: Herencia, Interfaces, Excepciones, Polimorfismo, …
Recogida de basura (Garbage Collection): Determina los objetos que no están siendo usados para a liberar recursos.
Tecnologías de Objetos Distribuidos
Actualmente existen tres tecnologías de desarrollo de sistemas distribuidos basados en objetos:
ANSA (1989-1991) fue el primer proyecto que intentó desarrollar una tecnología para modelizar sistemas distribuidos complejos con objetos.
DCOM de Microsoft.
CORBA de OMG.
Tecnologías Java de Sun Microsytems:
Remote Method Invocation (RMI).
Enterprise Java Beans (EJB).
Jini.
Diferentes entornos de trabajo propietarios.
Java RMI
El soporte para RMI en Java está basado en las interfaces y clases definidas en los paquetes:
java.rmi
java.rmi.server
Características de Java RMI:
Los argumentos y resultados se pasan mediante RMI por valor (nunca por referencia).
Un objeto remoto se pasa por referencia.
Es necesario tratar mayor número de excepciones que en el caso de invocación de métodos locales.
Java RMI
Localización de objetos remotos:
Servidor de nombres: java.rmi.Naming
Ejemplo:
Cuenta cnt = new CuentaImpl();
String url = “rmi://java.Sun.COM/cuenta”;
// enlazamos una url a un objeto remoto
java.rmi.Naming.bind(url, cnt);
….
// búsqueda de la cuenta
cnt=(Cuenta)java.rmi.Naming.lookup(url);
Arquitectura de Java RMI
Arquitectura de Java RMI
Nivel de transporte: se encarga de las comunicaciones y de establecer las conexiones necesarias
Nivel de gestión de referencias remotas: trata los aspectos relacionados con el comportamiento esperado de las referencias remotas (mecanismos de recuperación, etc.)
Nivel de resguardo/esqueleto (proxy/skeleton) que se encarga del aplanamiento (serialización) de los parámetros
proxy: resguardo local. Cuando un cliente realiza una invocación remota, en realidad hace una invocación de un método del resguardo local.
Esqueleto (skeleton): recibe las peticiones de los clientes, realiza la invocación del método y devuelve los resultados.
Desarrollo de Aplicaciones RMI
Registro de Objetos
Cualquier programa que quiera instanciar un objeto de esta clase debe realizar el registro con el servicio de nombrado de la siguiente forma:
Cuenta mi_cuenta=
(Cuenta)Naming.lookup("rmi://"+host+"/"+”MiCuenta");
Antes de arrancar el cliente y el servidor, se debe arrancar el programa rmiregistry en el servidor para el servicio de nombres
OMG
(Object Management Group)
Conjunto de organizaciones que cooperan en la definición de estándares para la interoperabilidad en entornos heteregéneos.
Fundado en 1989, en la actualidad lo componen más de 700 empresas y otros organismos.
OMA
(Object Management Architecture)
Arquitectura de referencia sobre cual se pueden definir aplicaciones distribuidas sobre un entorno heteregéneo. CORBA es la tecnología asociada a esta arquitectura genérica.
Formalmente esta dividida en una serie de modelos:
Modelo de Objetos
Modelo de Interacción
…
ORB
Servicios
FacilidadesComúnes
Interfaces de Dominio
Aplicaciones
OMA
Una aplicación definida sobre OMA esta compuesta por una serie de objetos distribuidos que cooperan entre si. Estos objetos se clasifican en los siguientes grupos:
OMA
Servicios:
Proporcionan funciones elementales necesarias para cualquier tipo de entorno distribuido, independientemente del entorno de aplicación.
Los tipos de funciones proporcionados son cuestiones tales como la resolución de nombres, la notificación asíncrona de eventos o la creación y migración de objetos.
Concede un valor añadido sobre otras tecnologías (por ejemplo RMI).
Están pensados para grandes sistemas.
OMA
Facilidades Comunes:
Proporcionan funciones, al igual que los servicios válidas para varios dominios pero más complejas. Están orientadas a usuarios finales (no al desarrollo de aplicaciones).
Un ejemplo de este tipo de funciones es el DDCF (Distributed Document Component Facility) formato de documentación basado en OpenDoc.
(También denominadas Facilidades Horizontales)
OMA
Interfaces de Dominio:
Proporcionan funciones complejas, al igual que las Facilidades, pero restringidas a campos de aplicación muy concretos. Por ejemplo, telecomunicaciones, aplicaciones médicas o financieras, etc.
Muchos grupos de interés (SIGs) trabajan sobre estas especificaciones.
(También denominadas Facilidades Verticales)
OMA
Aplicaciones:
El resto de funciones requeridas por una aplicación en concreto. Es el único grupo de objetos que OMG no define, pues esta compuesto por los objetos propios de cada caso concreto.
Estos son los objetos que un sistema concreto tiene que desarrollar. El resto (servicios, facilidades) pueden venir dentro del entorno de desarrollo.
OMA
ORB:
(Object Request Broker)
Es el elemento central de la arquitectura. Proporciona las funcionalidades de interconexión entre los objetos distribuidos (servicios, facilidades y objetos de aplicación) que forman una aplicación.
Representa un bus de comunicación entre objetos.
(Gp:) Servidor
void ingresar(long){
….
…. }
Cliente
x->ingresar(30)
ORB
ORB
Para posibilitar la comunicación entre dos objetos cualesquiera de una aplicación se realiza por medio del ORB. El escenario de aplicación elemental es:
IDL de CORBA
(Interface Definition Language)
Es el lenguaje mediante el cual se describen los métodos que un determinado objeto del entorno proporciona al resto de elementos del mismo.
interface Cuenta
{
void ingresar(in long cantidad);
void retirar(in long cantidad);
long balance();
};
IDL de CORBA
Language Mappings:
Traducen la definición IDL a un lenguaje de programación como:
C++,
Ada,
COBOL,
SmallTalk,
Java,
…
Este proceso genera dos fragmentos de código denominados Stub y Skeleton que representan el código de cliente y servidor respectivamente.
IDL de CORBA
El código cliente generado en base a la definición IDL (stub) contiene las llamadas para realizar el proceso de marshalling.
Marshalling: Traducción de los argumentos a un formato intermedio y pedir al ORB su ejecución.
(Gp:) Interface Cuenta
{
void ingresar(in long cantidad);
}
(Gp:) Cuenta.idl
Compilador IDL
Cuenta_Skel.c++
class Cuenta_Stub : …
{
void ingresar(CORBA::Long &cantidad)
{ < MARSHALLING> }
}
Cuenta_Stub.c++
IDL de CORBA
El código servidor generado en base a la definición IDL (skeleton) contiene las llamadas para realizar el proceso inverso (de-marshalling).
De-marshalling: Recuperar del ORB los parametros con los que se invocó el método, construir la llamada y realizar la petición.
Compilador IDL
(Gp:) Cuenta_Stub.c++
class Cuenta_Skel : …
{
virtual
void ingresar(CORBA::Long &cantidad)=0;
void __ingresar()
{
< DE-MARSHALLING>
ingresar(c);
}
}
Cuenta_Skel.c++
IDL de CORBA
Implementación del Objeto:
La implementación del objeto es invocada por los métodos definidos en el Skeleton. Por lo general se trata de una clase derivada del mismo.
class Cuenta_Impl: public Cuenta_Skel
{
void ingresar(CORBA::Long &cantidad)
{
dinero += cantidad;
}
};
(Gp:) ORB
(Gp:) ORB
(Gp:) DII
(Gp:) Stub
(Gp:) ORB
Interface
(Gp:) ORB
Interface
(Gp:) Skel.
(Gp:) DSI
(Gp:) Object Adapter (OA)
(Gp:) Cliente
(Gp:) Objeto Servidor
Componentes de un ORB
La arquitectura completa de comunicaciones de CORBA es la siguiente:
Componentes de un ORB
Stub:
Código cliente asociado al objeto remoto con el que se desea interactuar. Simula para el cliente los métodos del objeto remoto, asociando a cada uno de los métodos una serie de funciones que realizan la comunicación con el objeto servidor.
Skeleton:
Código servidor asociado al objeto. Representa el elemento análogo al stub del cliente. Se encarga de simular la petición remota del cliente como una petición local a la implementación real del objeto.
Componentes de un ORB
DII:
(Dynamic Invocation Interface)
Alternativa al uso de stubs estáticos que permite que un cliente solicite peticiones a servidores cuyos interfaces se desconocían en fase de compilación.
DSI:
(Dynamic Skeleton Interface)
Alternativa dinámica al uso de skeletons estáticos definidos en tiempo de compilación del objeto. Es usado por servidores que durante su ejecución pueden arrancar diferentes objetos que pueden ser desconocidos cuando se compiló el servidor.
Componentes de un ORB
ORB/Interface ORB:
Elemento encargado de (entre otras) las tareas asociadas a la interconexión entre la computadora cliente y servidor, de forma independiente de las arquitecturas hardware y SSOO.
Debido a que tanto clientes como servidores pueden requerir de ciertas funcionalidades del ORB, ambos son capaces de acceder a las mismas por medio de un interfaz.
Las dos principales responsabilidades del ORB son:
Localización de objetos: El cliente desconoce la computadora donde se encuentra el objeto remoto.
Comunicación entre cliente y servidor: De forma independiente de protocolos de comunicación o características de implementación (lenguaje, sistema operativo, …)
Componentes de un ORB
Adaptado de Objetos:
En este elemento se registran todos los objetos que sirven en un determinado nodo. Es el encargado de mantener todas las referencias de los objetos que sirven en una determinada computadora de forma que cuando llega una petición a un método es capaz de redirigírla al código del skeleton adecuado.
Existen dos tipos de Adaptadores de Objetos especificados por OMG:
BOA: (Basic Object Adapter).
POA: (Portable Object Adapter).
Componentes de un ORB
Las principales tareas del Adaptador de Objetos son:
Multiplexar a dos niveles (obnjeto y método) las llamadas.
Mantiene información (almacenada en el Repositorio de Implementaciones) sobre los objetos servidos, siendo el encargado de activarlos si al llegar una petición no se encontraban en ejecución.
Permite diferente modos de activación de los objetos:
Persistente: El estado del objeto se almacena entre varias ejecuciones.
Compartido: Todos los clientes comparten la instancia de objeto.
No-compartido: Cada cliente accede a una instancia diferente del objeto.
Por-método: Cada método solicitado es servido por una instancia de objeto diferente.
Genera las referencias de los objetos dentro del entorno. Esta referencia es única para todos los objetos.
(Gp:) ORB
(Gp:) ORB
(Gp:) DII
(Gp:) Stub
(Gp:) ORB
Interface
(Gp:) ORB
Interface
(Gp:) Skel.
(Gp:) DSI
(Gp:) Object Adapter (OA)
(Gp:) Cliente
(Gp:) Objeto Servidor
Comunicación vía CORBA
Pasos de una comunicación:
1- El cliente invoca el método asociado en el stub que realiza el proceso de marshalling. (Stub cliente)
2- El stub solicita del ORB la transmisión de la petición hacia el objeto servidor. (ORB cliente)
3- El ORB del servidor toma la petición y la transmite el Adaptador de Objetos asociado, por lo general sólo hay uno. (ORB servidor)
(Gp:) 1
(Gp:) 2
(Gp:) 3
(Gp:) 4
(Gp:) 5
(Gp:) 6
(Gp:) 7
Comunicación vía CORBA
4- El Adaptador de Objetos resuelve cuál es el objeto invocado, y dentro de dicho objeto cuál es el método solicitado (Adaptador de Objetos)
5- El skeleton del servidor realiza el proceso de de-marshalling de los argumentos e invoca a la implementación del objeto. (Skeleton servidor)
6- La implementación del objeto se ejecuta y los resultados y/o parámetros de salida se retornan al skeleton. (Implementación del objeto)
7- El proceso de retorno de los resultados es análogo.
(Gp:) ORB
(Gp:) ORB
(Gp:) DII
(Gp:) Stub
(Gp:) ORB
Interface
(Gp:) ORB
Interface
(Gp:) Skel.
(Gp:) DSI
(Gp:) Object Adapter (OA)
(Gp:) Cliente
(Gp:) Objeto Servidor
(Gp:) 1
(Gp:) 2
(Gp:) 3
(Gp:) 4
(Gp:) 5
(Gp:) 6
(Gp:) 7
Implementación de un ORB
El ORB representa a nivel lógico el bus de objetos que comparten tanto clientes como servidores. A nivel de práctico puede estar implementado como:
Residente cliente/servidor: Código que tanto clientes como objetos tiene que enlazar.
Demonio del sistema: Un servicio del sistema encargado de centralizar las peticiones.
Interno al sistema: Integrado dentro del SO.
Librería: Usado cuando tanto clientes como servidores residen dentro del mismo espacio de memoria.
Localización de Objetos
Los objetos de servicio de una aplicación CORBA se encuentran identificados por medio de una referencia única (Identificador de Objeto).
Esta referencia es generada al activar un objeto en el Adaptador de Objetos.
Por medio de esta referencia el ORB es capaz de localizar la computadora y el Adaptador de Objetos donde se encuentra, y éste último es capaz de identificar el objeto concreto dentro del Adaptador.
Localización de Objetos
El ORB proporciona mecanismos para transformar a cadena de caracteres y de cadena de caracteres a dicha referencia :
object_to_string, string_to_object
Ejemplo:
IOR:010000000f00000049444c3a4375656e74613a312e30000002000000000000003000000001010000160000007175696e6f2e64617473692e66692e75706d2e65730041040c000000424f418a640965000009f4030100000024000000010000000100000001000000140000000100000001000100000000000901010000000000
Implementación del Servidor
La implementación del objeto se diseña como una subclase de la clase generada por el compilador (el skeleton) de IDL en base a la definición.
Si el lenguaje usado para la implementación no soporta objetos el mecanismo es diferente.
Cuenta.idl
idl
Cuenta_skel
< DEMARSHALLING>
Cuenta_impl
< implementación>
Clase generada
automáticamente
Implementación
del objeto
Tareas Típicas de un Servidor
El servidor debe realizar las siguientes tareas:
Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Crear un un objeto (de la clase Cuenta_impl).
new Cuenta_impl()
Activar el objeto.
boa->impl_is_ready(…)
Iniciar el bucle de servicio.
orb->run()
Tareas Típicas de un Cliente
El cliente debe realizar las siguientes tareas:
Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Obtener la referencia al objeto (desde un string).
orb->string_to_object(…)
Cambiar la clase del objeto obtenido (down-casting).
Cuenta::_narrow(obj)
Realizar las llamadas al objeto.
cc->…
Otros Modos de Activación
Como alternativa al proceso de arrancar cada uno de los objetos de servicio, existe la posibilidad de indicar al Adaptador de Objetos otros modos de activación:
Esto permite no arrancar la instancia hasta que un cliente la solicite o sea activada explícitamente.
Esta alternativa requiere un ORB del tipo demonio o interno al sistema.
Otros Modos de Activación
1- En primer lugar es necesario arrancar el demonio.
Para la implementación MICO es:
micod -ORBIIOPAddr < direc.>
2- Se registra en el repositorio de implementaciones un nuevo objeto, indicando el mandato para ejecutarlo.
imr create < nombre> < modo>
< programa>
-ORBImplRepoAddr < direc.>
3- En cualquier otro momento se activa el objeto
imr activate < nombre>
-ORBImplRepoAddr < direc.>
ORB
Adaptador de Objetos
Repositorio de
Implementaciones
Nombre
Estado
Referencia
CuentaCorriente
active
IOR:0f…..
Cuenta
Servicios CORBA
Conjunto de objetos o grupos de objetos, que proporcionan una serie de funcionalidades elementales. Estos objetos esta definidos de forma estándar (interfaces IDL concretos).
Sus especificaciones se encuentran recogidas en los documentos COSS (Common Object Services Specifications).
Los servicios definidos son:
Servicio de Nombres
Servicio de Eventos
Servicio de Ciclo de Vida
Servicio de Objetos Persistentes
Servicio de Transacciones
Servicio de Control de Concurrencia
Servicio de Relación
Servicio de Externalización
Servicio de Consulta
Servicio de Licencias
Servicio de Propiedad
Servicio de Tiempo
Servicio de Seguridad
Servicio de Negociación
Servicio de Colección de Objetos
Uso del Servicio de Nombres
Permite asociar un nombre a una referencia de objeto. De esta forma los objetos al activarse pueden darse de alta en el servidor, permitiendo que otros objetos los obtengan su referencia en base a dicho nombre.
Los nombres de los objetos se encuentran organizados en una jerarquía de contextos de nombre.
NameService
Servicio de Nombres
El Servidos de Nombres, al igual que todo objeto del sistema se encuentra previamente activo.
NameService
MiCuenta=IOR:X
Cuenta
bind(“MiCuenta”,IOR:X)
Servicio de Nombres
Un nuevo objeto se arranca y se registra en el servidor de nombres:
NameService
MiCuenta=IOR:X
Cuenta
IOR:NS=resolve_initial_references(“NameService”)
Cliente
Servicio de Nombres
Un cliente localiza al servidor de nombres. Suele existir una función interna del ORB para localizar al servidor de nombres (resolve_initial_references) .
NameService
MiCuenta=IOR:X
Cuenta
IOR:X=resolve(“MiCuenta”)
Cliente
Servicio de Nombres
El cliente le pide al servidor de nombres que resuelva el nombre. Así obtiene la referencia al objeto buscado.
Servicio de Negociación
Este servicio también permite obtener referencias a objetos usando otra información:
Los objetos se exportan en el servidor con una serie de características del servicio que proporcionan.
Los clientes consultan con el servidor cuáles son los objetos ofertados con una serie de características.
Un cliente que buscase un servicio de impresión podría construir una consulta del tipo:
Service=Printer AND
PrinterType=HP AND
OS!=WinNT
A lo cual el servidor le indicará los objetos que existen con dichas características.
Comparativa
CORBA vs DCOM
CORBA es un estándar abierto y no propietario.
CORBA proporciona soporte para diversos SO.
CORBA es más completo y flexible.
CORBA da una salida a los legacy systems
DCOM esta integrado con la tecnología MicroSoft.
DCOM ha tenido una fuerte penetración en el mercado.
Comparativa
CORBA vs RMI
CORBA permite una mayor heterogeneidad en el desarrollo de aplicaciones (RMI sólo se puede desarrollar con Java).
CORBA ademas de las funcionalidades de comunicación, proporciona servicios.
RMI funciona sobre CORBA (IIOP).
RMI es mucho más sencillo y cómodo de usar.
RMI permite el paso de objetos por valor y por referencia.
Ejemplo
El ejemplo esta compuesto por cinco ficheros:
Definición IDL del objeto. (Cuenta.idl)
Cabecera de la implementación del objeto. (Cuenta_impl.h++)
Implementación del objeto.
(Cuenta_impl.c++)
Código servidor. (servidor.c++)
Código cliente. (cliente.c++)
 Página anterior | Volver al principio del trabajo | Página siguiente  |