Anterior
 Volver
 Siguiente

 
Asunto: [CORBA-Comp] Re: [CORBA-Comp]Información sobre el
Fecha: Fri Apr 14 16:16:17 2000
De: "Diego Sevilla Ruiz (dsevilla@um.es)" <dsevilla@ditec.um.es>

 
Hola, Xabiel y todos:

"xabiel Tucos (Javier Garcia Pañeda)" wrote:

> Hola Diego (y todos los demás),
>
> bueno, lo primero agradecerte las respuestas.
>

Gracias a vosotros por este intercambio de conocimiento tan revitalizante.

> Lo segundo, decir que quizás no enfoqué bien el tema desde el principio, mencioné el ejemplo del
> MICO porque los otros ORBs con los que trabajo habitualmente (TAO y BACUS) no tienen IMR, por lo
> menos en las versiones que yo estoy manejando (posiblemente el BACUS 4 si la tenga). Entoces mi
> duda es: ¿cual es la función exacta del almacén de implementaciones?, al trabajar con el MICO
> (nunca suelo trabajar en modo biblioteca) me planteo ¿qué aporta el almacén de implementaciones si
> no te activa automáticamente los servidores (por lo menos en los modos shared, ... que yo llama
> estandar, si que tienes razón de forma incorrecta,  pero con cierto conocimiento de causa puesto
> que si tu tienes un servidor compartido en el IMR no puedes lanzarlo no compartido (no funciona).

Bueno, por fin he tenido tiempo de mirar la implementación a fondo del MICO, cosa no muy fácil, por
cierto, sobre todo teniendo en cuenta que tendría que estar ahora dándome un paseo por ahí... ¡con la
buena tarde que hace! ;-).

Os contaré la exploración del código que he hecho y a las conclusiones que he llegado. Está demasiado
ligado a MICO, por lo que será difícil de entender para quien no lo haya utilizado. De todas maneras,
los conceptos que aparecen (espero) ayudarán a aclarar aún más el IMR. Al final, y como adelanto, se
llega a que la activación AUTOMÁTICA Y BAJO DEMANDA SÍ ES POSIBLE. Lo que pasa es que (no sé por qué)
no aparece en los ejemplos (puede ser porque no es estándar). En cuanto pueda la programo.

Al mirar el código del MICO me he centrado en la interrelación del cliente del IMR (el ejecutable imr)
con el código del IMR (en el ejecutable micod). En el fichero $MICO/daemon/poamediator.cc veo que la
función "create_impl", a la que llama imr cuando se le pone la opción "create", no crea realmente el
servidor (esto ya lo sabíamos), sino que lo añade en la tabla famosa del IMR. La función
"force_activation", llamada por "imr activate" realmente sí lo crea (llamando a "create_impl"), con lo
que estamos en el caso que sabíamos.

Ahora bien, es curioso observar el comportamiento cuando se recibe una invocación sobre un objeto que
maneja este IMR (ya esté activado o no): este código genérico está implementado en la función "invoke"
(Dynamic Skeleton Interface (DSI)?). El código es explícito y lo muestro a continuación:

CORBA::Boolean
POAMediatorImpl::invoke (MsgId id, CORBA::Object_ptr obj,
                         CORBA::ORBRequest *req,
                         CORBA::Principal_ptr pr,
                         CORBA::Boolean response_exp)
{
    // [...]

  /*
   * Look up ServerId in Map
   */
    // Esto es, el nombre del POA que hemos registrado. Hasta aquí, conforme a la especificación del
IMR que habíamos visto

  if ((*it).second.pstate != Active) {
    /*
     * No? Restart it.
     */
    if (!create_server (svid.c_str())) {
      /*
       * failed.
       */
        [...]
    }

    /*
     * Server has been started, but is not active yet. We must queue
     * the request until the server announces its readiness by calling
     * activate_impl().
     */

    invqueue.add (new MICO::ReqQueueRec (id, req, obj, pr, response_exp));
    return TRUE;
}


Es claro que si el servidor no está funcionando (no está "Active") se reinicia  a través de la llamada
a create_server, cuyo el código también es claro. Si el modo no es el de librería, se construye una
línea de comandos a la que se le pasan como parámetros

(1) su identificador de POA, y
(2) el IOR del IMR que lo lanzó

Pero lo verdaderamente importante es el último comentario. Mientras EL SERVIDOR NO LLAME A
activate_impl EN ESTE MEDIATOR, las peticiones se encolarán. Esto se hace, sin duda, para dejar tiempo
al servidor para que restaure su estado interno, posiblemente salvado en una base de datos al
desactivarse.

DE ESTO SE SIGUE QUE, para que esto funcione, el servidor se debe implementar de manera que:

* Compruebe si en el IMR existe una entrada para él mismo (esto siempre debe ocurrir) y no está
activa, en cuyo caso debe activarla utilizando el método "activate_impl" cuando haya restaurado su
estado interno (es decir, su POA y todos los objetos que dependen de él y que no se puedan activar
automáticamente).

Este último punto no lo tienen en cuenta ninguno de los ejemplos, y se tiene que llevar a cabo a
través de los interfaces del IMR que se listan en $MICO/include/mico/imr.idl (ImplRepository,
POAMediator, OAMediator, etc.) Así, por ejemplo, la entrada del IMR se debe encontrar con una llamada
a ImplRepository::find_by_name ó ImplRepository::find_by_repoid. El POAMediator se encuentra con una
llamada a "bind", por ejemplo. El imr_client.cc lo hace así:

    obj = orb->bind ("IDL:omg.org/CORBA/POAMediator:1.0", [...]);

Con esto, en teoría, YA debe haber activación automática. Sin embargo, no lo he probado: tomadlo con
cautela. En cuanto pueda haré alguna prueba. A mi también me interesa el tema.

>
> Creo que también ocurre con el modo "poa" que si no me equivoco es el único que hay para cuando se
> trabaja con el POA) ? ¿y si no tiene esta función (por lo menos en alguno de los tipos de
> activaciones) cuál es su funcion?
>

Me he limitado al modo POA porque es el que me interesa. Con el BOA supongo que pasará algo parecido.

>
> En resumen, ¿qué gano en el MICO o en cualquier otro utilizandolo en vez de lanzar el servidor
> directamente?
>

Ahora ya si. Ya tienes el IMR al completo ;-)

>
> ¿Cómo lo ves desde tu modesta (aunque experta e interesante) opinión? (o la de cualquiera de los
> demás también interesante, sin duda )
>
> De momento y puesto que no lo tengo muy claro la opción 2 que mencionas es la que suelo utilizar (o
> con ServantActivator).
>
> Saludos
>     Xabiel.
>

    Saludos.
    diego.

PD. Es curioso cómo el "opensource" puede ayudar en ciertos momentos. La verdad es que nunca terminaré
de agraceder el esfuerzo y la gran labor que los programadores que donan el código fuente de sus
programas están haciendo por los demás.

>
> "Diego Sevilla Ruiz (dsevilla@um.es)" wrote:
>
> > Hola, Xabiel:
> >
> >     Varias puntualizaciones:
> >
> > "xabiel Tucos (Javier Garcia Pañeda)" wrote:
> >
> > > "Diego Sevilla Ruiz (dsevilla@um.es)" wrote:
> > >
> >
> > [...]
> >
> > >
> > > 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
> > >
> >
> >     En primer lugar, no soy un experto en MICO y tampoco tengo tiempo de estudiar todas sus
> > características, aún así...
> >
> >     Los modos de activación shared, unshared, etc. son terminología BOA. Esto nunca se
> > especificó bien (por eso nació el POA): ni su interfaz ni por supuesto el ámbito temporal de los
> > servidores con respecto al de sus objetos, por lo tanto la implementación de MICO es una
> > elección propia (creo que hace algún comentario al respecto en la documentación de MICO).
> >
> >     Teniendo esto claro, he visto (tienes razón) que los servidores que no están basados en
> > librería dinámica se tienen que iniciar con "activate", que realmente carga el servidor en
> > memoria (que en realidad es lo que NO quereis).
> >
> >     Contra esto se pueden tomar dos decisiones:
> >
> > 1. Bien implementar los servidores con librerías dinámicas (con lo cual, MICO, y esto que quede
> > claro, EN SU IMPLEMENTACIÓN PARTICULAR, ofrece la posibilidad de esta activación y carga
> > automática).
> > 2. Bien utilizar un servidor "pequeño" que se encargue él de cargar de forma automática los .so
> > de los objetos implementación que sopote. Puede utilizar un mecanismo de ServantLocator en su
> > POA.
> >
> >     Sin embargo, como el interfaz del IMR no es estándar (y es ahí precisamente donde los
> > distintos vendedores añaden valor a su ORB), esto es lo que ofrece MICO. A lo mejor (no lo he
> > visto) el de ORBacus 4 sí que permite que se lancen servidores bajo demanda.
> >
> >     Por otro lado, se me olvidó comentar que el OAD de Visibroker 3.x estaba basado en BOA. Sin
> > embargo, Visibroker 4 ya incluye el POA, y quizá esta nueva versión sí que imcluya un IMR en
> > condicones.
> >
> >     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/
--------------------------------------------------------------------------

 Anterior
 Volver
 Siguiente