DAXP – Frequently Asked Questions (FAQ)

1. What is the main purpose of the DAXP protocol?

The main purpose of DAXP (Data & Attribute eXchange Protocol) is to provide an ultra-lightweight, high-performance, and secure streaming data exchange layer that completely bridges the gap between object-oriented applications (e.g., Java) and various data storage or external service layers.

Unlike traditional serialization formats, DAXP does not just transport data; it transports state intent, live data relationships, and on-the-fly validation rules using an optimized, single-pass, byte-by-byte Deterministic Finite Automaton (DFA) parser. It aims to eliminate infrastructure overhead (CPU/Network) while ensuring total system stability during runtime refactoring.

2. How does DAXP differ from JSON?

While JSON is the current web standard, it suffers from massive text overhead and structural rigidity. DAXP solves these systemic flaws:

Bandwidth Optimization: JSON repeatedly transmits verbose string keys (e.g., {"firstName": "John", "lastName": "Doe"}) with every single object. DAXP transmits key-value structures using numeric tokens (tagId) mapped to a dictionary. The dictionary is sent only once during the handshake, reducing payload size drastically.
State Operations (#): JSON can only represent values or null. DAXP introduces explicit lifecycle/state modifiers directly into the stream, such as #N (Force Null), #E (Initialize Empty Container), and #D (Fall back to System Default).
Parsing Complexity: JSON parsing requires multi-pass tree building (e.g., Jackson AST parsing), which triggers high CPU usage and rapid memory allocation (Garbage Collection). DAXP utilizes a single-pass, streaming state machine split by delimiters (| or SOH), allowing direct memory mapping with $O(1)$ state-switching efficiency.
Refactoring Resilience: Changing a variable name in a JSON-backed application breaks the contract with external APIs or databases. In DAXP, developers can rename code properties freely; as long as the @DaxpField(tagId) remains unchanged, the system never breaks.

3. How does DAXP differ from FIX?

The FIX (Financial Information Exchange) protocol is highly efficient and uses a tag-value structure (35=D|49=SENDER|...), but it is historically rigid and struggles with modern software paradigms:

Hierarchical & Nested Objects: FIX is intrinsically flat. Handling complex nested objects or recursive data models requires clunky repeating groups that are hard to parse. DAXP solves this natively using pointer operators (@) that easily map deep, complex object graphs (e.g., 5089@8;9;10 pointing to subsequent structured value blocks).
Composite Primary Keys: FIX has no native concept of object identity or compound keys out of the box. DAXP allows declaring a Composite Primary Key directly within the stream header—even pointing to another fully nested entity as the unique identifier via its pointer system (e.g., $:10@4).
Dynamic Runtime Contracts: FIX relies on rigid, pre-shared XML schemas (FIX Dictionaries). If a tag changes, systems must be taken offline and recompiled. DAXP features Dynamic Runtime Contracts, allowing the data layer to push dictionary updates to the Java application live at runtime without a single second of downtime.

4. How do I adopt DAXP in an existing solution?

You do not need to rewrite your entire system architecture to benefit from DAXP. Adopting it follows a safe, evolutionary approach:

The "Trojan Horse" Proxy (DAXP-Gateway): Introduce a lightweight proxy layer between your Java application and your core Data Store or Legacy API.
Isolate High-Volume Modules: Start by routing your heaviest traffic through DAXP—such as high-frequency transactional data, auditing/logging streams, or massive batch processing where JSON or traditional object-relational mapping (ORM) bottlenecks your CPU.
Annotate Existing DTOs: Simply decorate your existing Java POJOs with DAXP annotations without changing their internal logic:

@DaxpEntity(tagId = 5000, schema = SCHEMA_BASE)
public class CustomerEntity {
@DaxpField(tagId = 5001)
private String lastName;
...
}