En el diseño del DAMN seguimos una serie de directrices que conviene mostrar:
Esto es necesario para facilitar el uso del sistema a aquellas aplicaciones que no empleen sus propios mecanismos de distribución. Por otro lado, la ausencia de esta característica destruiría la distribución del sistema dado que es el rasgo distintivo de los sistemas distribuidos.
Si garantizamos un bajo nivel de abstracción evitaremos la realización de trabajo que puede no ser útil e incluso estorbar a algunas de las aplicaciones. En este punto, coincidimos con el modelo de sistemas basados en Exokernel [60].
Para poder utilizar recursos remotos es preciso que sus nombres
tengan validez fuera de su nodo. La existencia de una
correspondencia entre los mismos y los empleados por el hardware
permite que las aplicaciones puedan conocer la información que estos
últimos contienen: ubicación, en el caso de direcciones de red;
habilidades, en el caso de las direcciones de memoria física en
arquitecturas como el Intel/PC
; interferencias
causadas por su uso, como la línea de cache utilizada en el caso de
las direcciones de memoria física, etc.
Si las aplicaciones conocen cuales son los recursos disponibles pueden emplear mejores políticas de asignación de recursos.
Las aplicaciones siempre pueden utilizar agregación si necesitan unidades mayores, pero lo contrario no siempre es cierto.
La transparencia en la distribución ofrecida por las abstracciones de un DAMN no debe ocultar la heterogeneidad presente en la red. Esto puede parecer una contradicción, aunque no lo es. Las abstracciones deben poder nombrarse y utilizarse de forma transparente, no obstante, las diferencias derivadas de las distintas arquitecturas empleadas deben mantenerse. Siempre es posible añadir una máquina virtual o aumentar el nivel de abstracción para suministrar un entorno homogéneo a partir de uno heterogéneo (lo recíproco no siempre es cierto).
Dado que un DAMN considera la red como el hardware disponible, los objetos suministrados por el sistema deben ser capaces de migrar. De otro modo sería imposible cambiar de nodo flujos de ejecución al contrario de lo que ocurre en un multiprocesador y la barrera alrededor del nodo local obstruiría el uso de recursos remotos. La persistencia es en realidad una consecuencia de la capacidad de migración, ya que aquella puede considerarse una instancia del problema constituido por ésta (la persistencia puede implementarse como una migración a un almacenamiento ``no-volátil'').
Esto puede parecer perjudicial pero, al contrario, creemos que es beneficioso para el sistema resultante. El diseño de abstracciones escalables hace que la gestión de las mismas sea más complicada y, en muchos casos, ineficiente. Dado que en un DAMN los servicios los suministran realmente las aplicaciones, es razonable pensar que deben ser las aplicaciones que deseen escalabilidad las que la paguen. Por otro lado, si el número de nodos gestionado es demasiado alto siempre resulta conveniente para su administración partir el sistema en varios enlazados entre sí mediante pasarelas (esto es práctica común en los sistemas de comunicaciones actuales).
Para construir un DAMN basta con seguir estas directrices que conducen a un sistema que considera la distribución desde el principio y se sitúa en un bajo nivel de abstracción, manteniendo la adaptabilidad.
Veamos ahora lo que estos puntos suponen en relación a aspectos concretos tales como el nombrado, protección, asignación, revocación y distribución de recursos.