By way of example, FIG. 4 summarizes activation, deactivation and persisting state of components in one or more implementations. A deactivated component among classes 440 is activated by the runtime 442 into server memory 444 of a selected server of a cluster, e.g., an activation of component M may be activated from a deactivation as needed. Once activated, the activated component M may recall state and store state from/to persistent storage 446, if any, as desired. Note that the persistent storage 446 may be accessible regardless of the physical server on which a component is currently activated, e.g., via centralized and/or replicated storage, for example, which may be on a per-cluster basis. Alternatively however, state may be read from/stored to many different kinds of media, e.g., mobile phones, consoles, cloud storage services, and so forth. Such storage nay not always be accessible, e.g., devices like phones/consoles; however it is likely that components that depend on access to devices are only needed when the device is accessible.

As also shown in FIG. 4, an activated component X is deactivated by the runtime 442 based upon one or more deactivation criteria, such as based upon (lack of) usage, e.g., when not having performed any work for some time. Note that a component may also be allowed to deactivate itself, e.g., by calling a deactivate function. At any time, and as part of deactivation before deactivation completes, the component X may persist state to the persistent storage 446, if any, as desired. The component X is then deactivated.