In software, an object graph is a network of interconnected objects that represent the live state of an application.
At the heart of OA is a powerful idea: The Domain Model is a dynamic, self-describing, observable, navigable Object Graph. Every Object instance and it's references form a live, reactive system. This is the key solution behind Model-as-Software .
The OAObjectGraph supports insert, update, delete, queries, filtering, left joins, groupings, caching, triggers, messaging, transactions, and more. All of this is kept in-sync, and supports distributed clients and real-time synchronization.
OAObjectGraph can be backed by other data stores (ex: relational database, property files, etc). Dynamic lazy loading is a unique feature that is able to do optimizations based on runtime context and behavior.
Internally, OA wires this Object Graph together using its
OAObject
and
Hub<T>
types. It knows how objects connect, how they change, and what should happen when they do — across the UI, persistence,
and when synchronized across distributed instances.
This results in the Application becoming a real-time UI/UX representation from the design of the OABuilder Model. Tables, forms, trees, navigation, searches, filters, and interactions are all driven by the structure of your data.
The Application becomes the visualized Object Graph ... from the designed OABuilder 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.
Supporting inserts, updates, deletes, complex queries, filters, left joins, grouping, joins, merges, unique Id, caching, triggers, messaging, transactions and more — all managed within the Object Graph.
Designed to be data-source agnostic, and seamless integration with relational databases, NoSQL, files, APIs, and more. Data is fetched and saved transparently. OA handles identity, caching, change tracking, dynamic lazy loading across any backend, and more.
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, components, and services the power to dynamically understand and interact with any Object in an Object Graph.
The OAObjectGraph is like a living blueprint.
OA makes the OAObjectGraph the center and foundation — clean, organized, and built to scale.
In most software, the model gets unknowingly built on the fly — scattered across classes, DAOs, UI logic, and services. Over time, it becomes hard to navigate, harder to change, and difficult to reason about.
OAObjectGraph gives you a centralized, structured, and navigable model — like a normalized database, but for your entire application. It’s easy to maintain, evolve, and explain.
OA abstracts away boilerplate and tech sprawl. With a clear model, management, business analysts, and non-technical stakeholders can participate in the design and ownership — as first-class contributors. The Model describes the requirements using the same language and principles that matches the business. Being able to see the Model as a running Application produces a quick feedback loop, allowing the focus on creating a superior product.
Most development time is spent gluing things together — wiring state data to UI, syncing data, processes, messaging, managing persistence, bolting on APIs. It’s hard to get right, often fragile, and even harder to maintain and make adjustments — leading to complexity, limitations, and mounting technical debt. The OAObjectGraph has all of this glue-code included - and more.
Most applications struggle with keeping multiple clients or distributed components in sync — leading to stale data, race conditions, and complex messaging layers. OASync is part of OAObjectGraph that solves this, where changes flow through OA’s optimized sync engine in real time. Calculations and formulas are automatically refreshed.
OAObjectGraph makes the Model not just a technical artifact — but a shared language for your whole team.
OA & OAObjectGraph automate the entire application stack — so you don't have to wire, bind, or repeat anything. Each layer of your system is wired to work directly with your OAObjectGraph.
OAObject & Hub collection
Entity POJO at heart — but wired for everything: metadata, identity, observability, serialization, distributed, sync, object graphs, ...
OAObject
: The Smart Object
OAObject
is the base class for your Object Graph's data objects. It's the Domain Object that defines both the structure and behavior of business data. It represents real-world entities and processes, and is the foundation for automation. 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 to create master-detail, left-join, grouping, sharing, filtering ... and kept realtime - no refresh required. Hub works directly with any other objects, making it perfect for the MVC pattern.
OAObject began as a plain Java class — just fields and getters/setters. What was added makes it a Super Object that automates and eliminates complex development.
The Object Graph is observable, making changes automatically notify listeners, UI components, and other systems.
With OA's lazy loading and runtime awareness, your objects behave as if everything is in memory — even when it's not. References and collections are resolved only when needed, and hints from usage patterns help pre-load the right data at the right time.
OAObject knows its place in the object graph. It can follow relationships, resolve references, and sync intelligently with other systems.
OAObjectGraphs work across computers, where data is streamed/shared and changes are synchronized in real-time. Workloads can be distributed and method calls can run on other client(s). This includes data store access.
Security rules, validations, and even callback capabilities live inside the object. It's protected and auditable. This is all driven from the Model design of the Object Graph.
OA lets you build UI, logic, or integration components that work generically with any
OAObject
subclass. Since all model objects share the same powerful base class and metadata,
components don’t need to know your domain — they just work, leading to high reusability.
OAObjectGraph connects directly to UI components — whether it's using the OA library for Java Swing or Web — using built-in observability and two-way binding. No need for manual listeners or controllers - they are built-in. Just point your component at the object or collection, and everything stays automatically in sync.
OAObject doesn't care where the data comes from. It works with JDBC databases, NoSQL, file-backed caches, APIs, and even remote servers. Relationships and object queries are based on the Model and translated automatically — no DAO classes or SQL required. OA object queries work across servers, caches, databases, and any defined datasources.
Model-View-Controller is a proven and powerful pattern, but has limitations when scaling that has caused it to be under utilized. OA is able to scale MVC, based on a few unique techniques — making it fully automated and scalable across your entire application.
MVC is the foundation of well-structured software — separating concerns, improving testability, and supporting long-term maintainability. OA embraces this pattern, wiring everything from the model outward, with controllers that work with any of your OAObjectGraphs.
In OA, your
OAObjectGraph
(Model), UI components (View), and control logic (Controller) are pre-wired using metadata and property paths. Changes to the model automatically update the UI and sync across distributed clients.
OA’s UI components work with OAObjectGraph's
OAObject
and
Hub,
giving you reusable, dynamic views that reflect the current state of the model.
Using OASync, changes are distributed so all clients are automatically kept in sync.
OA makes MVC scalable, observable, distributed.
OA is optimized for enterprise systems — with built-in sync, caching, and lazy loading — and it can scale out or sit alongside performance-critical paths.
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 fast at what it does: syncing, wiring, observing, and reacting to model changes.
For parts of your app that demand extreme throughput (e.g. trading, telemetry, large queues), OA lets you create “fast path” subsystems — and monitors them without interfering.
Changes are transmitted as compact deltas through a distributed circular queue with built-in throttling, prioritization, fairness, back pressure 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.
OA is ideal for giving raw-performance code access to object-aware components of the application.