Asunto: Re: [CORBA-Comp] Información sobre el repositoriode
Fecha: Wed Apr 12 09:02:25 2000
De: xabiel Tucos <xabiel@aldebaran.edv.uniovi.es>
> Esta es una pregunta bastante compleja. Puedes ver una muy buena
> explicación en el paper que han remitido a la lista. La idea es que el
> IMR guarda una asociación entre el IOR (en realidad del ObjectId) de un
> objeto y la aplicación/librería dinámica/comando remoto que tiene que
> ejecutar cuando se recibe una petición para ese IOR.
>
> El proceso es el siguiente. Supongamos que hay un servidor para el
> interfaz IDL:Algo:1.0. Este servidor quiere que todos los objetos (del
> tipo IDL:Algo:1.0) que él crea se manejen automáticamente por el
> Implementation Repository, permitiendo así que el servidor se active
> sólo cuando existan referencias en uso a alguno de los objetos que
> implementa (servants), y que se pueda descargar de memoria en el caso en
> el que ningún cliente requiera sus servicios o en el caso en el que la
> máquina esté muy cargada de trabajo. Los pasos que se siguen son los
> siguientes:
>
> 1. El servidor crea su POA interno que le servirá para manejar sus
> objetos implementación (servants). A este POA le asigna un nombre (que
> debe ser único dentro del IMR en particular).
> 2. El servidor exporta hacia algún servicio de publicación (ya sea un
> servidor de Nombres, servidor de Trading, Correo Electrónico, Web, FTP,
> etc.) las referencias (IORs) de los objetos que implementa. Nótese que
> dependiendo de las políticas elegidas en el POA del servidor, no se
> tiene por qué crear ninguna instancia de "servant" para esos objetos: se
> crearán bajo demanda.
> 3. El servidor, para generar los IORs de esos objetos utilizará una
> serie de datos: el nombre de su POA, el identificador de cada objeto
> (ObjectId), que será único dentro de ese POA, y, por último, y esto es
> importante, LA DIRECCIÓN IP Y EL PUERTO DONDE ESCUCHA EL IMR.
> 4. A continuación, el servidor, A TRAVÉS DE UN PROTOCOLO PROPIETARIO
> (esto es importante: CORBA no lo define, pero es que no es necesario) se
> registra en el IMR: Le dice que, cuando reciba una petición sobre un
> objeto cuyo ObjectId contenga el nombre del POA que el servidor ha
> creado tiene que "ejecutar" a ese servidor para que le de servicio a ese
> objeto. La "ejecución" puede ser local, remota, o bien cargar una DLL.
> 5. El servidor de ese tipo de objetos puede ya dormir, a la espera de
> que el IMR lo active cuando un cliente lo necesite.
>
> Cuando un cliente pide una operación a una de esas referencias que ha
> exportado el servidor, intentará conectar con la dirección IP y el
> puerto del IMR. Ëste último, al ver que la petición no es realmente para
> él, tiene que hacer dos tareas:
>
> 1. Lanzar el servidor. Éste creará su POA e informará al IMR (otra vez
> con un protocolo propietario) de cuál es su puerto y dirección IP.
> 2. El IMR lanzará al cliente un mensaje GIOP Location_Forward (no
> recuerdo si es de GIOP 1.1 en adelante), indicándole al cliente la nueva
> localización del objeto. El cliente, al recibir el Location_Forward,
> cambia la referencia y, a partir de ese momento, utiliza la que el IMR
> le ha dado.
>
> Eso es básicamente el funcionamiento.
>
> > Porque la versión que utilicé del JacORB (0.9) no lo tenía, luego
> > estuvimos mirando el VisiBroker y vimos el OAD, pero no pudimos ver si
> > esto era compatible con el repositorio de implementaciones.
> >
>
> El OAD no es lo mismo, ya que se basa en el BOA, que no tenía ninguna de
> estas características. Además, también utiliza el mecanismo propietario
> del "bind" de Visibroker. Es un demonio que está pensado para construir
> "clusters" de ordenadores en la misma red local, y distribuir
> automáticamente las peticiones. El IMR es más general.
>
> >
> > Alguien conoce más información al respecto?
> >
> >
> > Daniel Mayor
> > Ingeniero informático
> > d.mayor@dimension-informatica.es
> > Avenida Cataluña, 9 - 46020 Valencia - España Tel. +34 963 394 000 -
> > Fax +34 963 394 001
Lo primero hola a todos,
he visto que cuando hablais del tema del almacén de implementaciones pones mucho como
ejemplo el del MICO, y en este sentido me gustaría planterar una duda metafísica. ¿no
obliga el IMR a tener que forzar la activación de los servidores?
Es decir, ¿no te obliga a hacer un "IMR create ..." y después un "IMR activate ..." (que
es cuando crea realmente el servidor) ?
Si realmente el funcionamiento es como pienso, ¿qué sentido tiene entonces el almacén de
implementaciones?
¿Qué es lo que me aporta?
Para mi, una de las grandes ventajas es que no se arranque el proceso hasta que no llegue
la primera petición para no estar mientras tanto consumiendo recursos, ¿qué os parece?
¿Cómo lo veis?
Saludos
Xabiel.
--------------------------------------------------------------------------
Esta es la lista de discusión de CORBA y Componentes Software (corba-comp)
--------------------------------------------------------------------------
Suscripcion: Envie un correo a mailto:Majordomo@ditec.um.es?body=subscribe%20corba-comp
Eliminar su suscripcion: mailto:Majordomo@ditec.um.es?body=unsubscribe%20corba-comp
Informacion de la lista: mailto:Majordomo@ditec.um.es?body=info%20corba-comp
Problemas: mailto:corba-comp-owner@ditec.um.es
Indices de la lista: http://www.ditec.um.es/~dsevilla/corba/
--------------------------------------------------------------------------