Anterior
 Volver
 Siguiente

 
Asunto: RE: Comentarios sobre el modelo de componentes CORBA
Fecha: Mon Jan 17 09:02:33 2000
De: "Rafael Corchuelo Gil" <corchu@lsi.us.es>

 
This is a multi-part message in MIME format.

------=_NextPart_000_02A8_01BF5EB0.1EFAEF40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Hola a todos:

En más de una ocasión me he planteado la misma pregunta que ha realizado
Diego y, a forma de pensamiento en voz alta, creo que una razón con los
pies en el suelo puede ser la siguiente:

Supongo que a la hora de incorporarlas en una herramienta de verdad (no en
una de laboratorio) suelen aparecer innumerables pegas que hacen que,
aunque en la teoría las ideas queden bastante claras, en la práctica
resulten difíciles de implementar.  Por ejemplo, hablando de C++, se
conocen muchas técnicas para conseguir que el usuario no tenga que indicar
de forma explícita si una rutina es virtual o no y otras para evitar la
tabla de métodos virtuales que son fuente de ineficiencia en aquellas
aplicaciones en que el número de llamadas a métodos es crítico.  No
obstante los compiladores de C++ siguen obligando, al menos los que yo
conozco, a colocar cuidadosamente la palabra virtual.

En este caso me parece que puede ocurrir algo similar y que entonces en la
propuesta final del modelo de componentes CORBA han decidido cortar por lo
sano e ir por la vía más rápida:  Se especifica de forma explícita qué es
local y de esta forma las
herramientas con las que trabajamos pueden tratar esos casos de forma
especial.  De esta forma se pueden aplicar técnicas como las descritas en
el artículo pero de forma ad hoc, sólo cuando se sabe que hay que
aplicarlas.

A los problemas que apunta Diego yo añadiría uno más:  Dificultad de
reutilización.  Si mañana descubrimos que nos hemos equivocado y que algo
que hemos declarado local resulta que tiene que ser global, entonces
tendremos que ir cambiando las llamadas a ORB::resolve_local por las de
siempre.

Saludos


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


------=_NextPart_000_02A8_01BF5EB0.1EFAEF40
Content-Type: text/x-vcard;
	name="Rafael Corchuelo Gil.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Rafael Corchuelo Gil.vcf"

BEGIN:VCARD
VERSION:2.1
N:Gil;Rafael;Corchuelo
FN:Rafael Corchuelo Gil
ORG:Universidad de Sevilla.  Facultad de Inform=E1tica;Lenguajes y =
Sistemas Inform=E1ticos
TITLE:Profesor Asociado
TEL;WORK;VOICE:+34 95 455 27 70
TEL;WORK;FAX:+34 95 455 71 39
ADR;WORK:;Despacho 1.25;Avda. de la Reina Mercedes =
s/n;Sevilla;Andaluc=EDa;41.012;Espa=F1a
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Despacho 1.25=3D0D=3D0AAvda. de =
la Reina Mercedes s/n=3D0D=3D0ASevilla, Andaluc=3DEDa =3D
41.012=3D0D=3D0AEspa=3DF1a
URL:http://www.lsi.us.es
URL:http://www.lsi.us.es
EMAIL;PREF;INTERNET:corchu@lsi.us.es
REV:20000114T154808Z
END:VCARD

------=_NextPart_000_02A8_01BF5EB0.1EFAEF40--


 Anterior
 Volver
 Siguiente