Asunto: Re: Comentarios sobre el modelo de componentes CORBA
Fecha: Fri Jan 21 16:26:15 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
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.
>
> 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/ .
>
> 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?
>
> 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...)
>
> 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.
>
> >
> >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).
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 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
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;