Asunto: Re: [CORBA-Comp] Información sobre el
Fecha: Wed Apr 12 11:01:18 2000
De: "Diego Sevilla Ruiz (dsevilla@um.es)" <dsevilla@ditec.um.es>
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.
--
Diego Sevilla Ruiz -- http://www.ditec.um.es/~dsevilla/
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-367570
E-mail: dsevilla@ditec.um.es
$_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
"\@". "\007f". "DDq". "DD5". "\204".
"\@". "DT4CE". "D54E". "DD". "\244".
"\021". "dBDTC". "\010DD". "\200\$FD\024".
"GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
(/./g) {$q= ord$q; for(a, b){$z[$c]
=$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------