Architecture

From Pelennor

This page is for discussion of Pelennor high-level architecture. There should be no discussion of specific languages or technologies of implementation.

Pelennor's architecture should be layered rather than monolithic.

Storage Layer

1. backend data storage (standard or custom filesystems, relational databases, network peers, etc.)
2. storage abstraction layer (caching, distribution, notification)
3. security layer (signing and encryption, access controls)
4. semantics layer (entity roles and relationships)
5. data rules layer (transactions, versioning, conflict resolution, referential integrity) - these are somewhat optional features, but there should be a low-level rules API

This is the core API. Notice that there is no mention of object mapping or persistence. There's no need to force object-oriented methodology at this layer. Simplicity is needed for auditability. In fact, everything here could potentially be implemented in tight low-level code for performance or small footprint for embedded devices.

A proper graph or block diagram is necessary to make these clearer, as each layer has multiple related components and there are some inter-layer relationships. Some refactoring may be needed to minimize dependancies. Some inter-layer communication may be optional, but recommended, parts of the API. For example, the storage abstraction layer may desire call backs from the semantics and/or rules layer to optimize granularity of replicated data. If we want to fetch a large, logical data set, such as a "document" comprised of 100+ u-forms, it should be possible to do this in one transaction with a network peer. (or at least to fetch as many of the entities as this peer has a copy of)

Application Services Layer

1. search and retrieval API
2. service and object mapping (optional)

Hm.. this needs quite a bit more thought..