Anterior
 Volver
 Siguiente

 
Asunto: Re: [CORBA-Comp] Información sobre
Fecha: Wed Apr 12 11:55:27 2000
De: xabiel Tucos <xabiel@aldebaran.edv.uniovi.es>

 
"Diego Sevilla Ruiz (dsevilla@um.es)" wrote:

> Hola a todos:
>
> "xabiel Tucos (Javier Garcia Pañeda)" wrote:
>
> > > 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) ?
> >
>
> Esto no es cierto. De hecho,  este es el script que se utiliza en MICO para lanzar por
> demanda un servidor de un objeto "Hello" guardado en una DLL (.so): Como ves, con el imr
> SÓLO se necesita imr create, es decir, establecer la entrada de la tabla de
> implementaciones, con imr create, y después se lanza el cliente con la dirección del IMR.
>
> #!/bin/sh
>
> PATH=../../daemon:../../coss/naming:../../imr:../../ir:$PATH
> ADDR=inet:`uname -n`:14333
>
> # we need an implementation repository, that is why we start micod
> micod -ORBIIOPAddr $ADDR &
> micod_pid=$!
> sleep 1
>
> trap "kill $micod_pid" 0
>
> imr create Hello library `pwd`/server.s? IDL:Hello:1.0 \
>   -ORBImplRepoAddr $ADDR
>
> ./client local: -ORBImplRepoAddr $ADDR #-ORBDebugLevel 5
>
> >
> > Si realmente el funcionamiento es como pienso, ¿qué sentido tiene entonces el almacén de
> > implementaciones?
>
> Como ves en el script de arriba, se conserva la filosofía del IMR que escribí.
>
> >
> > ¿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.
> >
>
>     Saludos.
>     diego.
>

Hola Diego,

vamos a ver, pero, ese tipo de funcionamiento ¿es sólo en modo librería o tambien se puede en
los modos estándar (shared, unshared, ...)?

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/
--------------------------------------------------------------------------

 Anterior
 Volver
 Siguiente