Asunto: Re: Comentarios sobre el modelo de componentes CORBA
Fecha: Thu Jan 20 10:01:55 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Hola Antonio y todos:
Antonio Vallecillo wrote:
> Si me lo permitís, yo sí que voy a romper una lanza a favor del uso de
> interfaces "locales".
Lo imaginaba y lo esperaba. Mi idea fue que surgieran opiniones en contra. Por
eso la critiqué de forma tan (¿demasiado?) vehemente.
> Aunque comparto casi todas las preocupaciones que
> Diego y Corchuelo han señalado, no debemos de olvidar algo muy importante:
> la semántica de las invocaciones a objetos locales y remotos es distinta!
En eso tienes toda la razón. Es la principal causa.
>
> Así por ejemplo, en COM las invocaciones son todas locales, y por eso
> cuando nació DCOM tuvieron que ampliar el HREF, y que los objetos tuvieran
> que tener en cuenta posibles errores de transmisión en las invocaciones y
> las respuestas. El problema es que no se quiso distinguir, se considera
> entonces a todas remotas, y pagan justos por pecadores (hasta las llamadas
> más locales e "inocentes" tienen que admitir como posible valor de retorno
> un error de transmisión).
¿Pero no se tiene que pagar ese precio por la independencia de localización?
>
> CORBA se encuentra en el extremo opuesto. En CORBA todas las llamadas son
> en teoría remotas (los objetos están a priori todos distribuidos), y el
> problema es cómo especificar que una llamada tenga de ser obligatoriamente
> local. El motivo de querer especificar algo así es para determinar una
> semantica concreta del comportamiento de esa llamada, y evitar los
> problemas que pueden ocasionarse si determinadas llamadas locales se
> implementan finalmente como remotas. Un ejemplo interesante es el de los
> "interceptores" (generalización de los filtros de Orbix ya casi aceptada
> por OMG para CORBA), que deben residir en el mismo "espacio" que el objeto
> al que envuelven, y por tanto NO pueden ser implementados mediante servants
> basados en POAs.
En esto también tienes razón. Y de hecho, al mirar el documento de
Portable Interceptors (orbos/99-12-02), en la página 4-26 me encuentro con:
local interface Interceptor {
Mi principal crítica era que la inclusión de "local" sólo sirviera para servir
al estándar de componentes. Al ver que también se utiliza en este contexto (y
que, siguiendo con esta misma filosofía se podrían incluir en algunos más), sí
que veo adecuado la inclusión de esta construcción "local".
Gracias por aportar esta idea. Realmente no se me había ocurrido mirar ahí. Y
eso que el nuevo ORBacus 4 ya incluye los PI, aunque no la construcción
"local" del IDL.
> De igual forma, podemos encontrarnos con problemas en
> aquellas aplicaciones que hagan uso de prioridades, pues aquí también se
> manifiestan claramente diferencias semánticas entre las llamadas locales y
> remotas a objetos (pueden ocasionar lo que se denomina "inversión de
> prioridades").
> La "colocación automática" tampoco resuelve todos los problemas. Por
> ejemplo, la semántica de las operaciones "oneway" dicta que un objeto puede
> invocar a una operación así y proseguir su ejecución sin esperar que el
> objeto remoto ejecute la llamada. Si realizamos la "colocación" de uno de
> estos métodos, el sistema de ejecución lo ejecutará dentro de la hebra de
> control del objeto llamante. Esto hace que la invocación se convierta en
> "sincrona", bloqueando al objeto cliente mientras dura la ejecución del
> método. Justo lo que no queremos hacer!
También se podría utilizar otro hilo que se encargara de este tipo de
peticiones si las peticiones en un solo sentido son relevantes para una
aplicación. O también coger el siguiente de un "pool" de hilos.
>
> Otros ejemplos y justificaciones pueden encontrarse también en el artículo
> de Schmidt, Wang y Vinoski que menciona el propio Diego, y en uno anterior
> de Schmitd sobre ORBs de tiempo Real (Computer Comms, Abril 98).
> En resumen, no es solo cuestión de una política a seguir durante el
> "deployment" de los componentes de la aplicación, o de reparto de cargas,
> sino de poder especificar unívocamente, durante la fase de diseño (i.e. a
> nivel de interfaz o IDL), la semántica concreta de una invocación. Y hemos
> de ser conscientes de la diferencia de semántica que existe entre las
> llamadas locales y remotas a procedimientos! Además, el problema es que es
> algo --desde mi punto de vista-- inevitable, por mucho que lo queramos
> enmascarar mediante distintas técnicas.
Tienes razón. Estoy encantado de poder contar con vuestra capacidad de
análisis. Ayuda mucho a un principiante como yo que le clarifiquen las ideas.
>
> Otra cosa es que para la mayoría de los casos no haga falta entrar a ese
> nivel tan preciso, pues como mencionaban Diego y Corchuelo, su uso
> indiscriminado o inconsciente puede comprometer la reusabilidad de los
> componentes y aumentar innecesariamente sus limitaciones de uso. Sin
> embargo, yo sí que veo necesario la existencia de un interfaz "local" para
> ciertas aplicaciones y objetos específicos.
> Siento discrepar,
>
Al contrario. Muchas gracias por hacerlo.
> Antonio Vallecillo.
> PS. Una pregunta: ¿Cómo traducís correctamente "deployment"?
A mi me gusta la traducción "implantación" o "despliegue", aunque esto también
lleva a confusión con "implementation" ¿cómo se traduce entonces esta,
"desarrollo"? Parece razonable, entonces "desarrollo" para "implementation" y
"implantación" para "deployment".
Gracias de nuevo.
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;