Anterior
 Volver
 Siguiente

 
Asunto: Re: Comentarios sobre el modelo de componentes CORBA
Fecha: Tue Jan 18 14:46:15 2000
De: Antonio Vallecillo <av@lcc.uma.es>

 
Si me lo permitís, yo sí que voy a romper una lanza a favor del uso de
interfaces "locales". 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! 
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).
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. 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!
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.
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,
Antonio Vallecillo.
PS. Una pregunta: ¿Cómo traducís correctamente "deployment"?



 Anterior
 Volver
 Siguiente