Asunto: Re: Persistencia en CORBA
Fecha: Mon Feb 21 10:01:34 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Hola, Juaquín:
Este es un tema muy interesante. Lo primero que te digo es que Jesús
García Molina y yo dirijimos un proyecto fin de carrera (el de Javier
Ros) que contiene una parte en la que se hace una aplicación práctica
del POA y BD. A partir de especificaciones IDL en la que se definen los
objetos que se almacenarán en la base de datos se genera todo el código
que permite acceder a través de sentencias SQL a una base de datos con
Java/JDBC. Hablaré con Ros para ver qué política sigue con su PFC y a
ver si lo deja disponible en alguna página web o en la mía.
Mientras tanto, a ver si te ayuda esta visión un poco por encima:
Joaquin Peña Siles wrote:
> Hola a todos!!
>
> Según lo que he leído hasta ahora, el POA (Portable Object Adapter)
> provee distintas políticas, entre las que se encuentra "RETAIN and
> USE_SERVANT_MANAGER" que permite hacer que los objetos
> sean persistentes de forma que su estado es almacenado mientras
> están inactivos.
>
Efectivamente, aunque la política que permite que se generen
identificadores persistentes es la PERSISTENT de la política "lifespan".
El POA es una cuestión complicada, aunque está muy bien estructurada. Es
sólo cuestión de cuadrar las cosas. La cuestión es que hay SIETE
políticas, cada una con sus propios valores. Cada aplicación (en teoría)
puede elegir un conjunto de políticas que se adaptan a sus necesidades.
Sin embargo, siete políticas con sus distintos valores no hacen fácil
esta elección.
Por ejemplo, la política RETAIN para "ServantRetention" no sería
adecuada para una base de datos. Ésta dicta que el propio ORB debe
mantener una asociación entre OIDs (Identificadores de objetos) y
"servants", es decir, servidores en código nativo. Con el POA, se
separan los servidores físicos de los identificadores de objetos. Así,
un mismo servidor en código nativo puede atender a cientos o miles de
referencias a objetos, con lo que se ahorra memoria en el servidor a
costa de incrementar en cierta medida el tiempo de proceso.
Así, para una base de datos, se pueden crear miles o millones de
referencias de forma automática (utilizando la clave, "key", del objeto
como identificador, en terminología POA, el ObjectId, y llamando a
"create_reference_with_id") y tener, por ejemplo, un único servidor que
acceda a la base de datos y la manipule dependiendo del ObjectId
implicado. Esto es lo que realiza la política "USE_SERVANT_MANAGER" de
"RequestProcessing". Cada vez que se requiere acceso a un nuevo objeto
(el cliente utiliza un OID para acceder a un objeto), se llama al
ServantManager, y este tiene que asociar un objeto "implementación", es
decir, un "servant" con ese identificador OID. Si se utiliza RETAIN, el
Manager es un ServantActivator, y el POA guarda la asociación
servant<->OID. Si se utiliza NON_RETAIN, el Manager es un
ServantLocator.
Si hay millones de objetos, incluso guardar sólo las asociaciones
OID<->servant es ineficiente en cuanto a memoria, y es mejor utilizar
NON_RETAIN. Con estas dos políticas, a saber USE_SERVANT_MANAGER, y
NON_RETAIN, cada llamada a un método de un objeto causa una llamada al
método "preinvoke" del ServantLocator:
Servant preinvoke (in ObjectId oid, in POA adapter, in CORBA::Identifier
operation, out Cookie the_cookie)
Como ves, se retorna un "servant" para ese ObjectId (el ObjectId va
inmerso en el IOR). Se identifica la operación, y se asigna un "cookie"
a ese servant (por otras cuestiones de identidad de objetos CORBA).
A continuación, se lanza la petición original en ese servant creado y
después de que la sirva, se vuelve a llamar al ServantLocator:
void postinvoke(in ObjectId, .... in Cookie the_cokie, in Servant serv)
Con lo que el que implementa esto puede en este método destruir
físicamente la memoria que ocupa este servant "serv", identifiacdo por
el cookie "the_cookie".
Así, en el primer método se puede acceder a la base de datos para
construir el objeto adecuado a partir de los datos de la base de datos,
y el último puede actualizar la BD con los datos del objeto después de
su uso por el método requerido ("operation"). El ServantLocator puede
incluso tener una caché LRU o lo que sea, pero tiene que manejarla él
mismo.
El caso de RETAIN es parecido, aunque no tan escalable. Al mantener el
POA las asociaciones, sólo llama al método "incarnate" del
ServantActivator cuando realmente necesita algún servidor para un
objeto, y llama después a "etherealize" cuando ya no lo necesita más. En
estos métodos también se puede hacer la gestión de cara a la BD.
> Ahora bien, podría alguien decirme donde encontrar información (ya
> he leído a ORFALI) acerca de como se implementa esto o apuntarme
> en términos generales como usar esta política. Sobre todo me gustaría
> saber como hacer que los objetos sean persistentes: ¿Qué base de
> datos usar? ¿Cómo introducir los objetos en la base de datos?...
>
En Orfali no se explica esto porque su libro es anterior (creo) al POA.
Ejemplos no conozco muchos, salvo el que te he dicho del PFC de Ros.
Aunque sin duda, el mejor libro para mirar todo esto es "Advanced CORBA
Programming with C++" de Henning y Vinoski. Aunque centrado en C++, las
explicaciones son válidas para cualquier lenguaje.
>
> Gracias por adelantado, Joaquín.
>
De nada. Encantado.
>
> PD. Está esto relacionado con la forma en que los javabeans se hacen
> persistentes? ¿Serialize?
No. La serialización de objetos CORBA es otro punto. Uno puede almacenar
sus objetos CORBA como desee, aunque propietariamente. Hay una
especificación de "Object Serialization", aunque no sé quién la
implementa (creo que JacORB, y algo he visto en MICO), aunque por ahora
no se está prestando mucho interés, ya que uno puede escribir métodos de
serialización específicos y es raro que los programas CORBA compartan
BD. (Esto es, en CORBA, la interacción normal entre las aplicaciones es
por envío de mensajes, no por compartición de datos en BD.)
Espero que esto te ayude, aunque es un tema demasiado amplio y no da
tiempo a explicarlo por correo.
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;