Asunto: Re: [CORBA-Comp] Bonobo
Fecha: Thu May 4 17:47:08 2000
De: "Diego Sevilla Ruiz (dsevilla@um.es)" <dsevilla@ditec.um.es>
Hola, Javi:
Javier Carlos Ros Sánchez wrote:
>
> Estoy tratando de echarle un vistazo a la arquitectura de
> componentes Bonobo, porque creo que puede ser muy interesante y
> necesario tener en Linux una arquitectura de este estilo, de
> libre distribución que permita el desarrollo de aplicaciones a
> partir de componente, como se hace en un entorno Windows.
>
> Lo primero con lo que me he encontrado es algo que ya me llamó
> la atención de Windows, pero bueno entonces no tenía nadie a
> quien llorarle ;) Me refiero a la interfaz Unknown ( o
> IUnknown en Windows), en esta interfaz se definen tres métodos:
> ref, unref y query_interface.
>
> Empezando por los primeros podemos encontrar el siguiente
> parrafo en "by The GNOME Project - Mathieu Lacage & Dirk-Jan C.
> Binnema":
>
> "When writing code, you should be careful to balance ref's and
> unref's. If there are too few unref, effectively you have a
> memory leak, especially if the component is implemented in a
> shared library. Especially, make sure components are released
> (unref'ed) before going out of scope. On the other hand, if
> there are too many unref's, you may kill the component
> prematurely, while your client code needs it."
>
> Y es algo que a mí me preocupa, sobre todo desde que los
> componentes pueden ser utilizados de forma remota (gracias a
> CORBA :) )
Es normal que te preocupe, porque no hay solución satisfactoria
hasta ahora. Esto es indispensable para que un servidor sepa
cuándo sus clientes no lo necesitan más. Conforme clientes llamen
a su método "ref", sabrá que todavía sigue siendo útil hasta que
éstos llamen a su método "unref".
No te debe sorprender este esquema. En CORBA se utiliza un
esquema de conteo de referencias distribuido:
* Los clientes tienen conteo de referencias en sus objetos
"proxy". Estos métodos de CORBA::Object (duplicate y release) son
sólo locales al cliente
* Los servidores pueden heredar (al menos en C++) de
PortableServer::RefCountServantBase, que implementa conteo de
referencias EN EL SERVIDOR, manejado por las activaciones y las
desactivaciones que el POA realiza en los objetos dependiendo de
su política.
Tanto en cliente como el servidor deben tener mucho cuidado en
manejar de forma correcta sus referencias (con duplicate/release)
al igual que ocurre en COM con ref/unref. La diferencia entre COM
y CORBA es que mientras en CORBA las operaciones afectan sólo al
proxy, en COM afectan directamente al servidor. En CORBA, las
operaciones del tipo ref/unref sobre el servidor se implementan
"ad hoc": como habrás visto, muchos interfaces IDL incluyen una
aplicación "destroy", que equivale, estrictamente con un "unref"
de IUnknown.
>
> Yo pienso que debe haber otra solución, a mí lo único que se me
> ha ocurrido (que también me parece un poco chapucero) en
> obligar al servidor a tener una lista de los clientes que tiene
> (convirtiendo a estos en objetos CORBA también), y que el
> servidor les pregunte si siguen vivos cada cierto tiempo, otra
> forma sería que los clientes tuvieran que refrescar su estado
> en el servidor cada x tiempo, o serían dados de baja.
El problema de esto es la escalabilidad. Es claro que en un
sistema distribuido sometido a fallos potenciales, si se quiere
llevar una cuenta fiable de objetos cliente que están "vivos", se
debe hacer una especie de "ping" para saberlo. El problema es que
un cliente que haya caído se comporta exactamente igual que otro
que, aunque esté funcionando, tarde mucho en contestar. Así pues,
cada cierto tiempo se comprueban los objetos cliente, pero ¿cada
cuanto tiempo?.
El otro problema es la cantidad de objetos clientes. ¿Cuántos
objetos clientes? ¿Merece la pena tener una lista para cada
objeto servidor con el conjunto de objetos cliente? ¿Merece la
pena cargar la red con este tráfico de "ping"? ¿Cuánto se
tardaría en reconocer que todos los clientes están vivos, si
tenemos en cuenta, por ejemplo, que todos ellos tardan "casi" el
tiempo máximo permitido para responder? Es lo que Michi Henning
llama "The Pacific Ocean Problem" en su artículo "Binding,
Scalability and Migration in CORBA"
(http://www.ooc.com.au/staff/michi/cacm.pdf), que ya salió antes
en esta lista.
Hay soluciones más sutiles y más complejas, pero la idea es tener
en cuenta el carácter "dinámico" del ambiente y tener en cuenta
que habrá objetos que no responderán en un momento dado, pudiendo
volver a responder más tarde, etc. Un diseño de una aplicación
seria debería contemplar esto. A propósito, mira en las news de
CORBA una respuesta del citado Henning a un problema parecido:
http://x29.deja.com/threadmsg_ct.xp?thitnum=10&AN=618974929.1&mhitnum=1&CONTEXT=957454430.367984648
>
> Bueno que os parece el tema, está el problema ya resuelto y
> estoy yo aquí haciendo el palurdo?, que solución se os ocurre?.
>
> Lo del query_interface es otro tema bastante interesante, ya
> que tampoco es una solución que me deje demasiado buen sabor de
> boca, eso no debería solucionarlo CORBA de alguna forma ya que
> parece que es función suya.
¿Por qué no te deja buen sabor de boca? ¿Qué propones en vez de
eso? La solución del CORBA Component Model viene en dos partes:
* Como el IR (Interface Repository) no es obligatorio, se define
el interfaz Components::Navigation (heredado por cualquier
componente CORBA) que incluye operaciones equivalentes a
"query_interface", como "describe_facets".
* En el IR se incluye un nuevo elemento (ComponentDef) que
permite "navegar" por los distintos interfaces al igual que un
"InterfaceDef" lo permite por las distintas operaciones y
atributos.
>
> Un saludo.
>
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/
--------------------------------------------------------------------------