PrimalForces Blog

He tratado de extraer en esencia los conceptos que los investigadores de Sun Microsystems Laboratories (Jim Waldo, et al) y que además se trata de un documento que data de Noviembre de 1994, y a mi entender parte de lo que plantean se ha implementado en cierta manera en algunos lenguajes y/o tecnologías que están de modè hoy en día.
Los autores plantean como tesis que la “visión unificada de objetos” está equivocada, afirman que hay diferencias fundamentales entre las interacciones entre objetos distribuidos y las interacciones entre objetos no-distribuidos, los cuales luego clasifican dentro de sendas categorías: cómputo distribuido y cómputo local. Y plantean como temas centrales los problemas relacionados con: Latencia, acceso a la memoria, “falla parcial” y concurrencia.

La visión común a la que refieren es en esencia que en el cómputo distribuido orientado a objetos no hay una distinción, desde el punto de vista del programador, entre objetos que comparten un espacio de direccionamiento y objetos que están en dos máquinas con diferentes arquitecturas y localizados en continentes diferentes. Comparan esta visión con la de RPC afirmando que puede verse como una extensión del mismo. Establecen que según esta visión el sistema son “objetos todo el tiempo”, un sólo paradigma para el uso de objetos sin importar la locación del mismo. Por supuesto la realidad es distinta en la práctica la invocación a una función de un objeto local no es la misma que para un objeto ubicado en otro continente.

Describen que éste modelo posee tres fases:

• 1.La primera fase consiste en escribir la aplicación sin importar su distribución y como se implementa la comunicación entre objetos.
• 2.La fase siguiente es realizar ajustes de desempeño, “concretando” la distribución de los objetos en las locaciones y los métodos de comunicación correspondientes.
• 3.Por último probar con “balas reales”, realizarlo con objetos cuidadosamente seleccionados para trabajar sobre todo con todo tipo de “fallas parciales” que se presenten.

La conclusión en estos puntos es que la visión que se expone está basada alrededor de unos principios que a la vez son falsos.

• Existe un diseño orientado a objetos único y natural para una aplicación determinada, sin importar donde sera implementada.
• Las fallas y desempeño están atados a la implementación de los componentes de una aplicación y en la etapa de diseño deben dejarse de lado (concepto de la máquina perfecta).
• La interfaz de un objeto es independiente del contexto en el cual va a ser utilizado.

Los autores sostienen que se ha fallado en reiteradas ocasiones al tratar de lograr esta visión única, por la simple razón que programar aplicaciones distribuidas es muy distinto de programar aplicaciones no-distribuidas, ya que los problemas más difíciles no se refieren a aquellos que implican poner o sacar cosas del “cable”, sino que los problemas en los sistemas distribuidos tienen más que ver con la falla parcial, la carencia de una administración de recursos central, desempeño, la concurrencia y el acceso a memoria compartida. Acerca de lo que exponen los autores en este aspecto, se ve claramente que deja en un segundo plano, todo lo referente a comunicaciones y en especial al marshalling.

Centran entonces su atención en tres temas como principales: Latencia, Acceso a memoria y falla parcial y concurrencia.
En cuanto a la latencia reconocen una diferencia de cuatro o cinco ordenes de magnitud entre una llamada local y otra remota. Si se ignora esta diferencia asegura que el diseños tendrá un pobre desempeño. De este modo en el diseño deben tenerse en cuenta qué objetos se distribuirán, cuáles estarán corriendo en el mismo espacio de direccionamiento. El argumento tal de que las redes y el hardware son cada vez es más rápidos en la transmisión de la información para solucionar el problema de la latencia no es suficiente ya que no soluciona los problemas del acceso a memoria, falla parcial y concurrencia.

Se rompe con el mito de que la calidad de servicio lo da la calidad de la implementación que se seleccione como la más óptima. Pero la robustez de un sistema no está dado por la simple función de la implementación de las interfaces que componen al sistema.
Ponen como ejemplo práctico del error que supone de ocultar las distinciones entre sistemas distribuidos y no-distribuidos a NFS, es muy común que ocurran fallas relacionadas con las comunicaciones y resulten en corrupción de datos en el caso de “soft-mounts” o que los sistemas queden colgados en el caso de “hard-mounts”.

Como conclusión los autores establecen que mezclar los modelos local y distribuido sea poco inteligente su intento y sin éxito. Y sostienen que hay que aceptar que ambos modelos son irreconciliables, y que deben considerarse en el momento de diseño.

Si bien el artículo data de hace unos siete años atrás (1994) muchas de estos conceptos aún siguen vigentes, en mi experiencia personal, el uso de EJB en el caso del lenguaje Java es lo que los autores hacen referencia como considerar todos objetos Remotos, aunque en el modelo de programación permite también esos objetos que se encuentran en el “middle ground” que tienen comportamiento local y remoto a la vez. Si bien los autores no hacen más referencia que a su existencia hoy en día la tecnología aplicada al lenguaje (Java2EE) trata a todos estos objetos como remoto con la salvedad de que sus interfaces locales están compliadas de una forma distinta a las remotas, pero la forma de invocación sigue las reglas de objetos distribuidos. Personalmente he experimentado crisis enteras por pasar por alto en la etapa de diseño y arquitectura de un sistema que componentes del mismo van a ser remotos y cuales locales. Terminando por irse al extremo de hacer todo remoto impactando seriamente en el desempeño del sistema, e incluso por las características de la implementación de la tecnología, en serios problemas de recursos de memoria poniendo fuera de servicio un sistema con solo una pequeña cantidad de usuarios, lo cual determina que el sistema no es escalable, del cual se supone es el principal beneficio de la computación distribuida.