Anterior
 Volver
 Siguiente

 
Asunto: Re: reflective middleware
Fecha: Thu Mar 2 14:50:53 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>

 
Hola, Luis.

    No es que yo sea un experto, pero también quiero aportar mi grano de
arena.

Luis Anido Rifon wrote:

> Hola:
>
> Hace unas semanas aparecio en esta lista el "call for papers" de un
> workshop bajo la denominacion "Reflective Middleware". Simplemente me
> gustaria comentar estos terminos para intentar abrir un pequeño debate
> terminologico en la lista.
>
> * Middleware. El pasado mes de octubre-noviembre, no recuerdo ahora
> exactamente, asisti a un seminario en el que presentaban las nuevas
> posibilidades de CORBA 3.0. En el se dio la siguiente definicion de
> middleware: "Middleware es el software de conectividad que consiste en
> un conjunto de servicios capacitadores, que permiten interactuar a
> multiples procesos que se ejecutan en distintas maquinas a traves de la
> red". Salvando el termino capacitadores, que entiendo como aquellos
> elementos que permiten esa interaccion, el resto de la definicion es
> clara, al mismo tiempo que amplia. Middleware es todo aquello que
> permite la comunicacion entre elementos software que se ejecutan en
> diferentes maquinas, middleware es CORBA y middleware son sockets TCP/IP
> por ejemplo. Por favor, corregidme si me equivoco.
>

Efectivamente, middleware se refiere a eso y además es un término muy
amplio. Middleware se puede considerar como todo aquello que se encuentra
entre el software y el hardware. Así, tanto los sockets como los ORBs son
middleware. Parece que últimamente es un término panacea que "vende mucho".
Sin embargo, no todos los middleware son iguales. Mientras que los sockets
no ofrecen control de tipos ni homogeneización de arquitecturas, CORBA,
DCOM, etc., ofrecen estas posibilidades.

Una pregunta: ¿el seminario fue de Ideal Objects en Madrid?  Yo estuve
allí.

>
> * Reflective. Aqui si que no puedo ni tan siguiera intuir a que se
> refiere este termino. Revisando la convocatoria para el workshop
> mencionado anteriormente, tampoco he podido extraer ninguna otra
> conclusion:
>
> http://www.comp.lancs.ac.uk/computing/RM2000/
>
> Os agraceria que abriesemos una pequeña "tormenta de ideas" sobre estos
> terminos, tanto middleware, aunque parece mas claro, como sobre el, para
> mi, desconocido reflective.
>

Esto es un paso adelante. "Reflective" se refiere a lo mismo que se
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.
Piensa en una herramienta RAD convencional, en la que puedes instalar
nuevos controles gráficos, por ejemplo.

    En middleware las cosas se amplían con consideraciones de red y de
distribución. Aparte de lo anterior, (es decir, tipos, métodos, herencia,
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.

    Me explico. Al tratar con middleware, y  más específicamente en el
contexto de CORBA que es el que mejor conozco, se tienen que tener en
cuenta ciertas cosas. Imaginemos, siguiendo con el ejemplo de la
herramienta RAD que ahora ésta es distribuida: es decir, puede incluir
"componentes" remotos. A estos componentes se les tiene que indicar, al
menos,

1. dónde pueden encontrar (el IOR) del Interface Repository,
2. dónde pueden encontrar el servidor de nombres local, si procede
3. dónde pueden localizar a los "componentes" que forman parte de la misma
aplicación (es decir, dotarlos de mecanismos de comunicación bidireccional
con los otros "componentes" que forman el sistema.

    Si en vez de utilizar los "componentes" de forma remota, se tuviera la
posibilidad o la necesidad de "traer" físicamente el componente pare
ejecutarlo en la propia máquina del ambiente de desarrollo RAD, se tendrían
que especificar también cuestiones como:

1. Acciones a realizar para "instalar" el "componente" de forma local (es
decir, si hay que instalar una librería dinámica, si hay que ejecutar un
programa ejecutable, etc)
2. Cuál es la factoría que tenemos que utilizar para crear objetos de este
tipo de "componente".
3. Máximo permitido de memoria que podría utilizar (esto permite que el
componente se autoconfigure para ajustarse a las limitaciones impuestas,
como por ejemplo, limintar el tamaño de sus tablas internas en memoria (en
el caso de que tuviera), etc.
4. Cuestiones como también dónde puede encontrar el Interface Repository,
Implementation Repository, Servicio de nombres, etc.

    Todas estas configuraciones y también la obtención de información del
"componente" se debe habilitar a través de los mecanismos de "reflexión"
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.

    Nota que siempre he escrito elementos o componentes entre comillas.
Esto lo he hecho así porque no se fija una granularidad para los
componentes ni la palabra "componente" tiene ningún significado especial.
Uno puede considerar un componente lo que quiera. De hecho, y como ejemplo,
este mecanismo de configuración de "componentes" se utiliza en TAO  para
especificar parámetros de los servicios estándar de CORBA que se inician
(por ejemplo, el servidor (el módulo ejecutable) del servicio de nombres).

    No se si esto traerá más dudas que ayuda, aunque como ya he dicho,
todavía estoy yo intentando tener una visión algo más clara sobre esto. De
todas formas, en la lista seguro que hay personas con una visión mucho más
clara que yo y me podrán corregir. Eso es lo bueno de las listas de
discusión, ¿no? ;-)

    Saludos.
    diego.

>
> Muchas gracias a todos,
>
> Luis Anido
> Universidad de Vigo

--
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;



 Anterior
 Volver
 Siguiente