AppSchemes - MondoAurora/Dust2014 GitHub Wiki

Possible application schemes (by the dynamism of the application structure). Naturally, security is an increasing issue with the more dynamic systems.

MemoryStatic

The build phase generates memory-fixed binary from the configurations and source codes. All entities and aspects are created and stored in the cloud, all business logic is mapped behind the aspects. The system reacts to the external events with pre-generated listener components sending the also pre-generated messages to each other.

Typical environment: embedded, low memory, real-time applications.

MetaStatic

All type declarations and logic connections appear as generated codes; so the kernel does not require configuration loading (thus the type scheme is static, extension is not required). On the other hand, the working instances are not pre-populated into the cloud: new instances can be generated or loaded, discarded. The required mechanisms must exist in the Data and Memory component.

Typical environment: this is a "normal" application today, the application structure resides in source, not in external configuration. A good reason to create such application is security, such a desktop application is harder to tamper.

Java note: On the other hand, in this case the whole application exists in the same classloader environment, there is no automatism to deny peeking into other units.

LogicStatic

In this environment, the Meta layer is flexible: new Meta information (Types) can be loaded from configurations at runtime. It is also possible that part of the kernel itself comes from configuration, in this case the components required for loading that info exist in generated sources. However, logic assignment is still static, there is no way to extend the actual functionality with new binaries/worker classes.

Typical environment: thin client application, where the GUI managing objects are required to provide the interface functionality, and is responsible to display and visually manage various objects of dynamically loaded types. In this case, the type-related business logic runs on server frontend side (validation, error messages, etc); modifications, transaction and lock management run at the server backend.

Dynamic

The dynamic environment is able to load new business logic at runtime (in Java, all units get separate classloaders to avoid illegal access to other units). In this way, the application contains several units as independent binaries (jars), which are loaded by the application only on demand. The application deployment configuration contains the required information about how to access these components.

Typical environment: when some applications share the same components (database access, GUI libraries, etc.); they are deployed as shared services and accessed by multiple applications.

Extendable

In this case, the application (or rather, framework) has access to a central component library, and may access new Meta types and binaries at runtime - which may not be available at the time of the application development or installation.

Typical environment: plugin architectures, like an image manipulation system with new algorithm extensions, or a medical system that allows new equipment integration.

---

The kernel layers must be implemented to transparently support any of these scenarios; and should be tailored to contain only the required features (the less dynamic systems appear in the more memory-sensitive environments).