Asunto: Re: reflective middleware
Fecha: Fri Mar 3 09:36:05 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Hola Angel y todos:
Angel Garcia Ba~nos wrote:
> Hola,
>
> Respecto a lo que dicen Diego y Luis, y sobre todo, con 'animo de
> aprender sobre el tema, siempre me ha llamado la atenci'on el tema de la
> reflectividad, la introspecci'on, la interfase din'amica, etc.
>
> > intentaba decir con los lenguajes de programación "Reflective": tener EN
> > TIEMPO DE EJECUCIÓN información sobre las entidades que se están manejando.
> > Dentro del contexto de un lenguaje de programación, esta información puede
> > ser el tipo (clase) de cierto objeto, el conjunto de métodos que responde
> > junto con los argumentos de cada método, el árbol de jerarquía de herencia,
> > etc. Esto hace que se puedan añadir en tiempo de ejecución nuevos objetos o
> > elementos al sistema y que el sistema sea capaz de manejarlos: sólo
> > necesita obtener la información necesaria de cada "componente" nuevo.
>
> Disponer de un mecanismo que permita en run-time dotar a los objetos de
> la posibilidad de averiguar cosas sobre otros objetos es algo
> aparentemente muy potente.
>
> Sin embargo, las aplicaciones que se plantean en estos temas son muy
> limitadas: browsers (para que un humano examine objetos), gateways,
> monitorizaci'on y poco mas.
>
Estas son las capacidades que se han explotado hasta ahora, aunque hay más. Por
ejemplo, el modelo OLE ha tenido mucho éxito, y se aplica ampliamente en muchos
ámbitos. Uno puede incrustar cualquier tipo de objetos OLE, con tal que cumplan
una serie de reglas (un conjunto de interfaces).
>
> > del "componente". Es decir, los distintos "componentes" tendrán un API de
> > reflexión a través del cual se les podrá consultar el conjunto de variables
> > de configuración y se les podrá "configurar" estableciendo valores para las
> > distintas variables que éstos acepten.
>
> Enseguida se llegan a las limitaciones sem'anticas: de que le sirve
> saber a un objeto que hay otro objeto que dispone en su interfase de
> cierta funci'on con tres par'ametros de entrada de tipo, char, float y
> string. Al objeto le falta la sem'antica: ?que hace esa funci'on?, ?para
> que sirven los par'ametros? Es decir, puedes obtener informaci'on mas o
> menos gen'erica de los objetos, pero ?que hacer luego con ella?
>
> Es decir, si se dispone de antemano (en tiempo de compilaci'on) de
> informaci'on de todas las posibles variables de configuraci'on (como lo
> de la cantidad de memoria que mencionas, o cosas similares) entonces es
> posible escribir un programa que las tenga en cuenta. En caso contrario,
> si un objeto aparece un dia especificando que requiere tarjeta de sonido
> (por ejemplo), pues ning'un otro objeto va a saber que hacer con eso,
> que significa o que posibilidades tiene.
>
En esto tienes parte de razón, y siempre he pensado más o menos así. Sin
embargo, la idea esencial es diseñar toda la infraestructura de introspección
(esa era la palabra, gracias) es que sea lo suficientemente general para un
ámbito específico.
Es algo parecido a lo que pasa con los sistemas operativos. Uno no piensa que el
sistema operativo no va a poder soportar las nuevas aplicaciones que se vayan
desarrollando.
Lo que comentas es un problema que siempre aparece con el software que
evoluciona. Sin embargo, tiene algunas críticas:
1. Si desarrollas un nuevo componente, lo tienes que hacer conforme a algún
modelo de utilización, es decir, tienes que hacer que pueda funcionar en un
determinado sistema. Si incluye una necesidad de una "tarjeta de sonido" es
porque tiene que tener la seguridad de que al menos alguna versión del software
que le tiene que dar soporte admite esta funcionalidad.
2. Si el sistema de reflexión se ha diseñado bien, debe contemplar (COSA QUE NO
SE HA HECHO HASTA AHORA) *también* las extensiones, es decir, las mejoras. Si
las soporta, significa que todos los nuevos componentes desarrollados deben ser
"compatibles hacia atrás", o lo que es lo mismo, deben poder negociar las
capacidades en el momento de instanciación.
Date cuenta que, al menos como yo lo pienso, *TODO* está en el diseño. Por
ejemplo... el nuevo componente necesita un "reproductor de audio". Así, por
ejemplo en CORBA, especifica un RepositoryId de un interfaz que utilizará y para
el que necesita una implementación. El sistema de soporte, puede entonces buscar
en librerías que implementen ese RepositoryId, buscarlas, instalarlas como una
librería dinámica, buscar la factoría para este tipo de objetos, instanciar uno
de ellos, y devolver una referencia al objeto creado al componente que lo
necesita.
También se puede ver como que el componente es de la "versión 2". Un buen diseño
de introspección debe ser compatible hacia arriba y hacia abajo. Es decir, tener
la posibilidad de instalar nueva funcionalidad para servir a nuevos clientes y
también debe asegurar que los clientes "versión 2" también pueden al menos
indicar soporte de "versión 1" que necesitan un nuevo soporte "versión 2". Es
decir, tanto el sistema soporte (desde ahora contenedor) como el componente
tienen que seguir cierta "evolución paralela".
Esto se puede ver de forma más sencilla pensando en interfaces COM. Los
interfaces COM son tan sencillos y potentes que son un soporte seguro para la
evolución de los sistemas. De hecho, esto ya se ha hecho en COM. Por ejemplo,
con el interfaz IClassFactory e IClassFactory2:
En principio, se puede buscar entre los interfaces que implementa un componente.
Esto se hace a través de IUnknown, que es universal.
1. Si se encuentra IClassFactory2, se utiliza. Esto es un ejemplo de un
contenedor de nueva versión y un componente de nueva versión.
2. Si no se encuentra IClassFactory2, se utiliza IClassFactory (lo tiene que
tener por compatibilidad hacia atrás). Este es el caso de un contenedor de nueva
versión utilizando un componente de versión antigua
3. Si se busca inicialmente IClassFactory, el componente también lo tiene. Este
es el caso de un contenedor de version antigua utilizanto un componente tanto de
versión nueva como antigua.
He aquí los cuatro casos para el problema concreto de la CREACIÓN DE OBJETOS
(versiones nuevas y antiguas de ambos elementos: contenedor y componente). La
idea es que estos conceptos se extiendan a cada vez más ámbitos, creando los tan
traidos y llevados "frameworks" (como lo es OLE para documentos compuestos).
>
> > etc. si utilizamos un middleware de objetos, objetos distribuidos, CORBA,
> > DCOM, etc.), se tienen que idear mecanismos que permitan obtener
> > información específica del middleware y configurar los "componentes" que
> > forman parte del sistema distribuido de una forma más o menos genérica.
>
> Veo dos alternativas: o la informaci'on que obtienes no es tan
> gen'erica, para que pueda ser procesada de forma autom'atica por otros
> objetos, o si no, la informaci'on debe ser procesada finalmente por un
> operador humano.
>
> A mi me parece que ello (reflectividad, introspecci'on, interfase
> din'amico) es entonces un peque~no enga~no.
>
> Que pensais?
> Angel
>
Me alegro de tus comentarios... me has hecho pensar mucho ;-)
Saludos.
diego.
>
> --
> Angel Garcia Ba~nos
> Ingeniero de Telecomunicaciones - UPM - MADRID - ESPA~NA
> Doctor en Telecomuniaciones - UPV - VALENCIA - ESPA~NA
> Profesor Universidad del Valle - CALI - COLOMBIA
> Tel: (572)3303436, Fax: (572)3392361, email: angarcia@univalle.edu.co
> Web: http://eiee.univalle.edu.co/~angarcia
--
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;