In software, an Object Graph is a structured network of object instances and their relationships, representing the live state and logical structure of an application.
OA centers around the concept of a dynamic, self-describing, distributed Object Graph that is fully observable and runtime-aware. This graph is built from instances of OAObject and connected through Hub<T> collections.
These components form a runtime fabric that manages identity, relationships, state propagation, distributed synchronization, and change observability — enabling a seamless integration across UI layers, persistence, and distributed systems.
The result is a software system that renders itself in real time based directly on the OABuilder-defined domain model.
Each OAObjectGraph
includes metadata defined through annotations and loaded at runtime. This includes everything about the object graph: properties, relationships, validation rules, security, calculations, display hints, events, and more.
Supports full data operations: inserts, updates, deletes, queries, joins, caching, transactions, messaging, and more — all managed within the Object Graph.
Designed to be data-source agnostic. Uses OADatasSource interface to support connections to any datasource. Seamlessly integrates with relational databases, NoSQL, files, APIs, and more. OA handles identity, caching, lazy loading, and change tracking across any backend.
With property paths like
order.customer.company.name
or
customer.orders:open().deliveries.late()
, OA can dynamically navigate and reason about Object Graphs.
OAObjectGraph supports callbacks that plug into lifecycle events and business rules: such as validation, enablement, calculations, or permission checks.
OAObjectGraphs expose their own metadata via reflective services — giving tools and services the ability to dynamically understand and interact with any object in the graph.
Connected across multiple instances, OAObjectCache ensures every change — create, update, delete — is synchronized across the distributed graph in real time.
The OAObjectGraph is the live blueprint of the Software.
OA & OAObjectGraph provide full-stack automation by establishing declarative bindings across all layers of the application. The UI, business logic, data access, messaging, and synchronization layers are connected to the OAObjectGraph, eliminating the need for manual wiring, redundant bindings, or boilerplate integration code.
OAObject
&
Hub
OAObject
: The Smart Object
OAObject
is the base class for your object graph's data objects. It defines both the structure and behavior of business data and represents real-world entities and processes. It automatically handles relationships, change tracking, observability, queries,
security, sync, REST, APIs, serialization, validation, hooks, lazy loading, and more.
Hub<OAObject>
: The Smart Collection
Hub<OAObject>
is an observable, sync-aware collection. Hubs are wired together to support master-detail, joins, grouping, filtering, and sharing — all in real time with no manual refresh needed. Hubs work directly with any object type, making them ideal for MVC
patterns.
OAObject began as a plain Java class — just fields and getters/setters. What was added turns it into a "Super Object" that automates and eliminates complex development patterns.
The object graph is fully observable. Changes automatically notify listeners, UI components, and dependent systems — with no manual code needed.
Thanks to lazy loading and runtime awareness, your objects behave as if everything is already loaded. References are resolved on demand, and OA prefetches intelligently based on usage.
Each object knows its place in the graph. OAObject can follow relationships, resolve references, and sync intelligently across clients and systems.
OAObjectGraphs work across machines. Changes are streamed and synchronized in real time. Workloads can be distributed and methods invoked on remote clients — including data access.
OAObjects enforce security, validations, and callbacks. These rules live in the model and execute automatically at runtime — making your app auditable and protected by design.
Components can work with any OAObject subclass because of shared metadata and consistent interfaces. This makes your UI, logic, and integrations highly reusable and domain-agnostic.
OAObjectGraph supports auto-binding to UI components — both in Java Swing and Web. Manual listeners and controllers aren't needed. Just point a component to a hub or object, and it stays in sync.
OAObject supports JDBC, NoSQL, REST APIs, file-based caches, and remote servers — all driven by the model. No DAOs, no SQL. Queries are expressed as object paths and work across systems.
Thanks to unique lazy loading techniques, object caching, and sibling hinting, OA apps behave as if the full Object Graph is always present — without actually loading it all at once.
OA is optimized for syncing, observing, and reacting to changes across the object graph — with minimal overhead and maximum responsiveness.
For high-throughput areas like trading or telemetry, OA allows separate “fast path” subsystems — while still observing them without adding overhead.
Changes are transmitted as compact deltas through a distributed circular queue with built-in throttling, prioritization, fairness, backpressure, and filtering — keeping traffic minimal and state synchronized.
OA tracks client state and request patterns to decide what to fetch, preload, or skip — avoiding duplicate requests, N+1 issues, and unnecessary processing.
OA was designed to work across distributed nodes, clients, and services. It's used in systems with thousands of users and apps running in parallel.