Otro sistema distribuido basado en 
kernel es Spring
[84]. Este sistema introduce nuevas técnicas
basadas en el modelo de Orientación a Objetos (OO) de tal modo que los
servicios del SO están compuestos por un conjunto de objetos que
cooperan para implementarlos y es factible modificar los mecanismos
empleados en la interacción entre dichos objetos
[75]. Anteriormente, Choices [27]
ya empleó la OO como base para alcanzar un SO flexible y
reconfigurable.
Spring introduce innovaciones como el modelo de subcontrato [84] que permiten adaptar en cierta medida la intercomunicación entre los distintos objetos que constituyen el sistema (por ejemplo, hacer caching o replicación de forma transparente). A grandes rasgos, el modelo de subcontrato consiste en delegar la invocación de métodos remotos a un objeto que implementa el ``subcontrato'' que tiene el cliente con el servidor. Modificando éste se puede alterar la interconexión entre el cliente y el servidor.
En cuanto a los servicios suministrados por el sistema, Spring incorpora Shuttles, Threads, Espacios de Direcciones y Doors como abstracciones fundamentales del sistema, imponiéndose abstracciones pesadas a las aplicaciones. Discutimos éstas abstracciones a continuación.
El sistema de memoria virtual de Spring [96],
que implementa los espacios de direcciones, ejecuta ``fuera'' del
kernel. No obstante, ejecuta con todos los privilegios del núcleo y
además impone su abstracción de Espacio de Direcciones a las
aplicaciones. A efectos de adaptabilidad en el sistema, la gestión de
memoria puede considerarse dentro del núcleo salvo por la existencia
de paginadores externos como ocurría en Mach.
El sistema de gestión de procesos, que emplea Shuttles (similares a los de Off, salvo por el hecho de que no poseen propiedades y no es posible extenderlos), oculta éstos a las aplicaciones. Éstas perciben Threads como abstracción básica, y estos threads están multiplexados por el núcleo sobre los shuttles existentes [84]. No es preciso decir pues que tampoco es posible reemplazar o adaptar el comportamiento y/o la implementación de estas abstracciones en Spring.
Finalmente, el mecanismo básico de IPC en Spring (las doors) es
una adaptación del modelo de gates de MULTICS. Un Shuttle puede
emplear una door para efectuar una transferencia protegida de
control cambiando (posiblemente) su domino de protección. Esta
abstracción está contenida en el núcleo, y se emplean
descriptores
(también contenidos y gestionados por el núcleo) para
exportarla a las aplicaciones. La implicación obvia es que el núcleo
debe intervenir en todos aquellos casos en que una aplicación obtiene
(o pierde) derecho a invocar una door. Como consecuencia, la
implementación de la transferencia de datos entre un cliente y un
servidor está predeterminada en gran medida por el núcleo (dado que
éste debe intervenir y cuidar las transferencias que involucran
transferencias de derechos de invocación de doors. La ventaja
de emplear descriptores y hacer que la transferencia de éstos la
realice el núcleo es que resulta muy simple emplear mecanismos de
cuenta de referencias para liberar recursos que ya no se utilizan.
En pocas palabras, como hemos visto en los párrafos anteriores, Spring es un sistema distribuido que no puede considerarse como un sistema adaptable en realidad, aunque sea elegante y extremadamente flexible.