Universal Architecture for Data
Aggregation and Processing Technologies (U-ADAPT)
U-ADAPT significantly advances the current state of art
in brokered data exchange between diverse data sources and diverse
application systems. The
data brokering technology transforms the current primitive level
information to a framework for persistent, “queriable” objectified data exchange medium. This provide the basis for a robust and scalable data
distribution and processing system. Key innovations of the U-ADAPT architecture include:
-
Information exchange through a “Persistent Object based Hyperspace” that is highly flexible for the client systems to latch
onto.
-
The highest level of maturity within the “data exchange
continuum”.
-
Persistent Objects that are naturally adaptable to Intelligent Agent based Knowledge Discovery and Advanced Information Processing.
-
Object Hyperspaces that can cater to simultaneous handling of static or dynamic data from databases, as well as real-time data streams.
-
A distributed and scalable architecture that is easily replicated and highly fault-tolerant.
-
An architecture that supports both role-based and activity-based encryption and security through add-on functions to the U-Broker Interface.
-
An architecture that supports Rapid Application Development (RAD) through the simplified interfaces provided by the U-Broker Interface.
As indicated in Figure 1 below the continuum of representation to reality can be thought of
as phases of data maturity. As we go closer to reality, the
object-oriented nature of data tends to become more and more
important to map the relations, interfaces, and functions of the
basic data. Generally, data representations and presentations in
today’s databases reach Level 2 maturity. However, the XML/SOAP/U-ADAPT
technologies can combine to provide very powerful Level 3 maturity.
In Level 3, transitive closure of objects and functions when
operations are conducted on them is a key feature. This is critical
to provide massive data processing interfaces where processing logic
may span over several views and iterations. This would solve several
of the architectural issues surrounding data processing
methodologies (two-layer/three layer SQL-bound systems) that are
commonly used today.
Figure 1. Data Continuum – Representation vs. Reality
|
)
)