Anterior
 Volver
 Siguiente

 
Asunto: Comentarios sobre el modelo de componentes CORBA
Fecha: Mon Jan 17 09:02:15 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>

 
Hola a todos:

    He estado estudiando con algo de detenimiento la propuesta final
conjunta del modelo de componentes CORBA  (orbos/99-02-05) y me han
surgido algunas ideas. Además, creo que es bueno que comencemos a
comentar esta propuesta.

    En el capítulo 4 (pág. 4-19) se introduce la construcción "local".
Su objetivo, tal y como se explica, es definir interfaces que están
limitados a un uso local (no pueden ser transmitidos por el cable,
etc.). Están destinados a especificar el contrato entre
componente/contenedor, que siempre ocurre de forma local: el contenedor
ofrece al componente los servicios disponibles a través de un contrato
especificado en IDL.

    El componente, puede invocar a la nueva función definida para
obtener referencias a esos objetos locales identificados por una cadena
de caracteres (al igual que sucede con los servicios estándar CORBA):

// PIDL
module CORBA {
interface ORB {
localBase resolve_local(in string name) raises (InvalidName);
};
};

    Mi pregunta es: es claro que este este tipo de construcción (la
palabra clave local) no es necesaria (de hecho, el POA también está
restringido a un uso local y no se especifica con esta sintaxis), pero
¿merece la pena? Sobre todo teniendo en cuenta la existencia de una
operación ORB::resolve_initial_references.

    Mis principales puntos en contra son los siguientes:

    1. A mi me parece algo redundante el método ORB::resolve_local.  La
función ORB::resolve_initial_references se puede utilizar para eso.
    2. Además, implica el manejo de dos tipos de objetos por parte del
sistema de tiempo de ejecución del ORB, los locales y los
tradicionales., con la consiguiente complejidad añadida del compilador
de IDL y de un nuevo tipo de "stub" y "skeleton" para estos objetos
locales.
    3. Aunque se argumenta que estos objetos son más eficientes (ya que
no poseen código para marshaling ni llamadas remotas) el hecho es que se
ha avanzado mucho en lo que los ingleses denominan "collocation
optimizations" (Véase, por ejemplo el artículo de Vinoski y Schmidt
http://www.iona.com/hyplan/vinoski/col18.pdf ), esto es, optimización de
objetos que están en la misma máquina o el mismo proceso, con lo que el
aumento de mejora ya no es un argumento a favor.

    ¿Qué opinais?
    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;



 Anterior
 Volver
 Siguiente