Persistence means that the lifetime of objects is beyond the lifetime of the applications that are using them. Since a user typically deals with basically the same or similar problems during subsequent usage of an application, the objects which are modeling these problems should survive an intermediate termination of the application.
The Persistence Module was specifically created to meet this demand. It was inspired by concepts also available in CORBA [52]. Arbitrary objects are registered, or in some sense requested, from the Persistent Storage Manager of the Persistence Module, by using a unique path of names to identify them, and a default initialization pattern, in case it was requested the first time. Once this registration has been performed, the object is automatically stored to disk before the application terminates, and it is restored when it is requested again. Each user of SIESTA owns a separate database of persistent objects.
Using this name service, multiple modules can access the same object without knowing anything about each other. This is necessary to decouple modules from each other. Given that two modules need to share some data, one of them, which can be considered the server, instantiates the object and registers it with the Persistent Storage Manager, and the other one simply asks for that object. Thereby, the latter module does not even need to know where the object came from. Thus, the name service contributes to a strict de-coupling of SIESTA's modules.