Asunto: Re: Comentarios sobre el modelo de componentes CORBA
Fecha: Fri Jan 21 17:10:15 2000
De: David Martinez Oliveira <dmartinez@proel.es>
Hola de nuevo Diego
At 16.13 21/1/00 +0100, you wrote:
>Hola, David:
>
>David Martinez Oliveira wrote:
>
>> Hola a todos.
>>
>> En primer lugar me gustaría isaludar a todos los lectores de esta lista.
>> Esta es mi segunda intervención, la primera sobre el sistema que estoy
>> desarrollando EDMA no tuvo demasiado éxito.
>>
>
>Al contrario. Perdona de verdad por no enviarte antes algún tipo de
>comentarios. Ando muy liado, aunque no olvido... lo tengo en la "cola" de
cosas
>pendientes.
Muchas gracias por considerarlo, y te pido disculpas por mi impaciencia
>
>>
>> Desgraciadamente he perdido algunos de los mensajes de esta hebra y espero
>> no malinterpretar lo que aquí se comenta. Si es así me disculpo por
>> anticipado.
>>
>
>Puedes ver los índices (con un diseño que pronto espero mejorar) en
>http://www.ditec.um.es/~dsevilla/corba/ .
Muchas gracias por esta información. Esta conversación sobre el modelo de
componente de CORBA es muy interesante.
>
>>
>> No soy demasiado experto en estos temas y espero no meter la pata demasiado
>> y aprender de todos vosotros, de forma que pueda mejorar EDMA ya que es el
>> elemento central de mi tesis doctoral.
>>
>> Me gustaría comentar como soluciona EDMA algunos de los problemas que
>> estais comentando en esta hebra y que me indicaseis vuestra opinión al
>> respecto.
>>
>> At 18.55 20/1/00 +0100, you wrote:
>> >>En esto tienes razón. Se debe ser muy cuidadoso en identificar y definir
>> >los
>> >>interfaces locales para evitar que en algún momento se puedan (o se
deban,
>> >>por cualquier tipo de exigencia) convertir en no-locales.
>>
>> En EDMA la distribución de componentes se realiza a través del sistema de
>> extensión SIU. Básicamente lo que hace es generar el código proxy/stub de
>> forma dinámica puesto que toda la información de interface está disponible
>> en tiempo de ejecución.
>>
>
>Entiendo lo que dices. Supongo que habrás diseñado algún tipo de sistema de
>introspección para los componentes que te permita preguntarles qué métodos
>tienen y con qué signaturas. ¿Exactamente cómo lo haces? ¿Dónde lo
guardas? ¿Se
>genera automáticamente a partir del código? ¿El entorno de programación lo
>genera de forma automática?
Exactamente, se mantiene toda la información de interface en memoria de
forma que el empaquetado de las llamadas se puede realizar dinámicamente
sin necesidad de un compilador de interface que genere el código
dependiente de la red.
Las clases/componentes EDMA están formadas por un fichero de definición de
interface y por uno de implementación. Cuando se le pide al sistema que
cree un objeto ambos son cargados en memoria y el fichero de interface es
"compilado" en tiempo de ejecución.
Esto puede parecer una operación muy costosa, pero el diseño del sistema
basado en herencia dinámica y acoplamiento débil entre las clases que
forman las distintas jerarquías de herencia, hace que la reutilización de
los interfaces sea muy grande y por lo tanto que estos mantengan un tamaño
reducido con lo que el tiempo de compilación del interface es pequeño.
Este interface solo hace falta procesarlo cuando se crea el primer objeto
de la clase/componente por parte del primer proceso (debido a la memoria
compartida).
Una vez definido el fichero de interface... un fichero de texto con un
formato similar al de los ficheros .INI de windows, el programador no tiene
que preocuparse de nada más.
>
>>
>> De esta forma se puede utilizar cualquier clase diseñada para trabajar
>> localmente de forma remota, simplemente moviendo la complejidad de la
>> comunicación e incluso la semántica de invocación (en el caso general) a
>> este sistema de extensión. La implementación actual es todavía muy
>> rudimentaria y es probable que me esté dejando cosas en el tintero por lo
>> cual cualquier comentario sería bien recibido.
>>
>
>No te preocupes, leeré la documentación y leeré el código, aunque echo de
menos
>una guía rápida de por dónde empezar (quién mejor que tú para guiar...)
Te lo agradezco de veras. La versión que está en el web es un poco vieja y
espero añadir una nueva versión en cuanto encuentre un hueco.
>
>>
>> Como ejemplo de como funcionaría esta forma de trabajar muestro un ejemplo
>> de un posible código:
>>
>> objLocal=NewObj("MICLASE",NULL);
>> objRemoto=NewObj("REMOTO:MICLASE",NULL);
>> objRemoto1=NewObj("REMOTO_ONEWAY:MICLASE",NULL);
>> objRemoto2=NewObj("REMOTO_BLOCKING:MICLASE",NULL);
>>
>> donde REMOTO, REMOTO_ONEWAY, REMOTO_BLOCKING son clases proxy que
>> interceptan todas las interacciones con el objeto realizando la llamada
>> remotamente... se pueden definir todas las clases de estos proxys que se
>> deseen y cada uno todo lo complejo que sea necesario (es código C). Además
>> se pueden seleccionar en tiempo de ejecución simplemente modificando una
>> cadena de caracteres.
>>
>
>Es una muy buena idea. En cierta medida estás implementando un
"contenedor" que
>da soporte a los módulos que se van insertando en tu sistema.
Si, esos contenedores son clases EDMA, y su aplicación es muy general. Los
he utilizado tanto para disponer de un sencillo sistema de distribución de
objetos/componentes, como para la integración de otros sistemas, como Java,
Guile y espero que pronto los objetos CORBA puedan ser utilizados de esta
forma.
>
>>
>> >
>> >Claro, pero lo que ocurre es algo parecido a lo que comentaba en el
caso de
>> >la palabra virtual: Puede ocurrir que desarrolles varios trabajos
>> >utilizando un interfaz local y al tercero te des cuenta de que realmente
>> >necesitas que no lo sea. Pero permitidme injerir en este punto un trocito
>> >de otra carta de Antonio Vallecillo.
>>
>> Con relación a la cuestión de métodos virtuales o no virtuales. EDMA
>> incorpora el concepto de objeto virtual. Cualquier objeto puede ser
>> declarado como virtual y en ese momento, cualquier método virtual o no, o
>> incluso cualquier propiedad del mismo se puede sobrecargar dinámicamente.
>>
>> Este concepto se introdujo ya que parecía más que posible que para una
>> determinada clase en un determinado contexto, un determinado método no
>> debería ser virtual y en otro contexto si que debería serlo, aún cuando la
>> definición de la clase fuera correcta en los dos casos. También sucedía, en
>> algunas de las aplicaciones desarrolladas, que attributos de los objetos
>> eran modelados correctamente como propiedades en la definición de la clase
>> para un caso concreto, pero a medida que la jerarquía de herencia crecía,
>> serían manejadados de una forma más lógica a través de métodos. Bien, esto
>> puede parecer un poco raro pero estas situaciones aparecían en un entorno
>> con herencia dinámica.
>>
>
>Efectivamente, el problema no carece de importancia. Incluso en el caso de
>jerarquías que no son de objetos distribuidos aparece el problema de la
>elección (y el cambio) entre atributos y métodos debido a la evolución
natural
>de las clases; un caso específico del "fragile base class problem" (al menos
>eso creo, por favor, decídmelo).
Si creo que es en eso en lo que consiste el problema. Por lo que he leído
en un libro titulado "Componet Software", el problema de la "clase base
fragil" (FBC) se da a dos niveles. A un nivel sintactico como el que
estamos comentando aquí, y a un nivel semántico en el que el propio
significado de los métodos y propiedades varia a medida que la jerarquía de
clases crece. Bueno, hace tiempo que no trato con estos temas y quizás no
me he explicado demasiado bien.
>
>Esta implementación que dices es muy flexible y acertada. Se parece a las
>facilidades que ofrecen los lenguajes de "script" como Python. Sin duda, un
>buen sistema de programación reflexiva es la base para un buen modelo de
>componentes. CORBA lo soluciona parcialmente con el Interface Repository.
>
>
>> >El problema que planteas de las llamadas "oneway" no me había ocurrido,
>> >pero sí, a la hora de hacer las "colocaciones" habría que ser
cuidadosos en
>> >estos casos, aunque la idea que apunta Diego podría ser la más sencilla
>> >para resolverlo (¡hasta que se acabe el pool de hebras!).
>> >
>>
>> He perdido el mail en el que se plantea este problema, pero me gustaría
>> conocer en que consiste.
>>
>
>Mira en http://www.ditec.um.es/~dsevilla/corba/msg0091.html
Muchas gracias. Me lo miraré.
>
>>
>> Muchas gracias y un saludo
>> David Martínez Oliveira
>
>Gracias a ti por tus comentarios. A ver si saco tiempo y te envío comentarios
>sobre EDMA
>
Sería estupendo y te lo agradecería enormemente.
Muchas gracias por tu amabilidad e interés.
Un saludo
David Martínez Oliveira