DAXP 
Data & Attribute eXchange Protocol
Business Models Should Be Stable.
Technologies Should Be Replaceable.
For years, enterprise integration has focused on technologies. REST or SOAP. JSON or XML. HTTP or Kafka. These choices matter, but they are not the real problem.
The real problem is that modern systems exchange implementation models instead of business models.
- ORM frameworks tightly couple application code to database structures.
- JSON APIs expose those implementation structures to the outside world.
As a consequence, database schemas become object models, object models become API contracts, and API contracts become dependencies for other systems. Every internal change propagates through the entire ecosystem. The result is a distributed monolith.
DAXP takes a different approach.
DAXP introduces a technology-independent canonical data model that exists independently of programming languages, databases, serialization formats, and transport protocols.
Applications exchange business concepts—not implementation details.
Every system remains free to choose its own internal architecture while exposing the same stable integration contract.
This allows:
- independent evolution of applications,
- gradual modernization of legacy systems,
- coexistence of PL/SQL, Java, .NET, Go and other technologies,
- replacement of implementations without changing integration,
- treating databases as first-class applications rather than passive data stores.
DAXP is not designed to replace HTTP or TCP. It is designed to replace implementation coupling with a stable, canonical model that survives technology changes.
Because technologies evolve.
Business models should remain stable.
DAXP Is an open communication protocol that combines compact numeric tags with dynamic data dictionaries.
Messages carry data efficiently. Dictionaries define their meaning, data types, validation rules, relationships and business context
See how DAXP works
A DAXP application exchanges compact data using stable numeric tags:
...|
$:6=2000|2001=100045|
2002=Anna|
2003=Nowak|
2004=
2005^N|
...
The meaning of these tags is defined by a dictionary that is itself exchanged as a DAXP message:
DAXP|V=0.7|EN=UTF-8|CX=CRM|$:1=$:DIC_DATA|$:3=...|
...
$:4=13|$:5=T|$:6=2001|$:20=LNG|$:12=Customer id|
$:4=14|$:5=T|$:6=2002|$:20=STR|$:167=20|$:168=2|
$:4=15|$:5=T|$:6=2003|$:20=STR|$:167=20|$:168=2|
$:4=16|$:5=T|$:6=2004|$:20=STR|
...
$:4=24|$:5=F|$:6=2001|$:7=2000|$:11=customerId|
$:4=25|$:5=F|$:6=2002|$:7=2000|$:11=name|
$:4=26|$:5=F|$:6=2003|$:7=2000|$:11=surname|
$:4=27|$:5=F|$:6=2004|$:7=2000|$:11=email|
...
$:4=36|$:5=E|$:6=2000|$:115=2001;2002;2003;2004;2005;2006;2007|...
From this dictionary, the application can determine that:
2000 CUSTOMER entity
2001 customerId LONG
2002 name STRING min=2 max=20 chars
2003 surname STRING min=2 max=20 chars
2004 email STRING
The transmitted message remains compact, while its types, field names, entity structure, validation rules and business meaning are available through the dynamic dictionary.
One transport endpoint. Multiple message types.
When DAXP is transported over HTTP, an application can expose a single shared endpoint for multiple business operations.
The endpoint receives DAXP frames, while the message type — such as CRM.REQ, CRM.UPDATE, or CRM.DELETE — determines how each message is routed and processed.
New message types can be introduced at the protocol level without requiring a separate HTTP endpoint for every operation.
Explore DAXP Java Quick Start
Note: These examples are intentionally simplified and illustrate only selected DAXP concepts.
They do not represent the complete syntax or the full capabilities of the protocol.