Spiralcraft Framework Design Attributes

Recursively Extensible

The Spiralcraft framework is designed to help others build their own domain specific frameworks, which can in-turn be further specialized. To achieve this goal, every core framework facility provides extension mechanisms that maintain flexibility and contain complexity across multiple layers of repackaging and domain specialization.

Data Oriented

A (DAL) data abstraction layer in the framework core provides a type system and a common Tuple based data interface. The DAL is used pervasively throughout the framework to interact with both transient and persistent data that is modeled with relational or reference semantics.

By providing a clean separation between the domain model and storage implementations, the DAL permits a developer or integrator to use a storage subsystem appropriate for the deployment environment without changing application code, and to integrate data from arbitrary sources regardless of the underlying storage implementation.

Internally, the DAL is integrated with the configuration model to support the use of data to persist the structure and configuration of framework components.

Modular

The framework supports the declarative composition, extension and "wiring" of components, which can be repackaged into modules and incorporated into larger or more domain-specific systems.

The mechanisms of composition and extension are accessible through a variety of means: a fluent XML syntax, a template syntax, via the data access layer, programmatically, or through the expression language used for "wiring" and dependency resolution.

Using a context-aware dependency resolution and message passing mechanism, granular components designed to function as a unified set can be woven into heterogeneous containership hierarchies and separated by unrelated components while maintaining the ability to coordinate within their own set. This allows for the flexible recombination of modules while minimizing integration code, and provides the means to modify component behavior based on context, for example, to support ancillary usage scenarios during development, testing, debugging, constrained deployment, etc.

The composition, extension, "wiring", and configuration mechanisms are type-safe and early-binding, and make extensive use of type inference, which results in most programming or configuration errors being caught at "load-time". This provides an environment that can easily integrate additional code or configuration at runtime while still retaining most of the reliability and performance benefits of pre-computing type logic and data paths.

Performant

The Spiralcraft architecture is based on a "data flow" paradigm, which allows for efficient performance without limiting parallelism. The objective of the platform, from a performance perspective, is to be flexible enough to use memory and CPU resources efficiently under many general purpose scenarios, and to facilitate horizontal scaling when required.

The "data flow" paradigm, as applied to this architecture, views an individual component instance as an element of a "data pipeline" which is configured within some application context, pulls data from inputs, performs some transformation, and generates some output which is made available to the components connected to it. Component instances are internally stateless and capable of handling multiple threads simultaneously without synchronization, while any state that must be considered is generally treated as a form of data that is managed by the infrastructure.

This architecture is memory efficient because the component graph is instantiated once, regardless how many users, sessions, threads, or states are associated with the application. State itself is managed as data, and is generally small when compared to the size of the component graph.

Run-time CPU efficiency and overall latency is improved by the pre-computation of type logic and data paths (known as "binding") for a given component graph such that metadata processing only occurs during load-time and is not "interpreted" repeatedly at run-time.

Pre-computation of data paths provides an opportunity for specific optimizations to be considered at run-time when implementation details are available- e.g. an expression can be translated into a different language such as SQL and prepared to run on a database server that contains the target data.

Garbage collection and memory efficiency is improved over systems that explode parts of the component graph by associating a new instance with each additional user or data item- in this architecture, additional users or data items will at the most generate additional state data.