About DAXP

DAXP was created as a response to practical problems observed in system integration, microservices communication, database access, and business application development.

The first inspiration came from the FIX protocol. While working on my own trading platform, FixTerminal, I had to deal with differences between FIX 4.2 and FIX 4.4. I noticed that a tag-based communication model is powerful, compact, and precise. However, although FIX allows custom tags, its extension model is not flexible enough for modern, dynamic applications.

The second motivation came from microservices. In many systems, JSON-based APIs create strong dependencies between services. Each change in the data model or API contract often requires changes in many components. As a result, systems that are formally distributed may still behave like a distributed monolith.

A similar problem exists in many banking and enterprise systems. ORM-based solutions often create a tight relationship between application classes, database tables, and API structures. In my opinion, an application should not be strongly dependent on the physical database model, and the database should not force the shape of the application.

DAXP introduces a flexible, tag-based, self-describing communication model. It allows applications to exchange data using dynamic dictionaries of attributes, metadata, validation rules, dependencies, and business context. These dictionaries can be generated through auto-documentation mechanisms directly from the application, annotations, validation rules, or other definition sources.

One of the key ideas behind DAXP is that a database can be treated as another communication participant, not only as a storage layer hidden behind ORM. Oracle Database, microservices, desktop applications, backend components, and external systems may all communicate using the same DAXP protocol.

Transaction control may also become part of the DAXP message structure. This means that transactional communication does not have to be limited only to the relation between an application and a database. Two independent applications may also exchange messages in a transactional mode, if they understand the same transaction context.

DAXP may also be especially useful in communication between applications and AI systems, including LLMs. Instead of sending loosely defined JSON structures, an application can provide AI with precise, self-describing messages that include data meaning, types, validation rules, dependencies, and business context. This can reduce ambiguity and improve the quality of communication between software systems and artificial intelligence.

The next important step for DAXP is an implementation directly in Oracle PL/SQL. The goal is to reduce dependency on classic ORM solutions and create a more natural communication layer between applications and databases.

DAXP was not created as a theoretical experiment. It is based on practical experience with FIX, microservices, JSON, ORM, Oracle, PL/SQL, and banking systems. Its purpose is to reduce coupling between components, support version-independent communication, and provide a more flexible foundation for modern applications.