|
Corporations spend copious amounts of time and money building read-only golden copies of master reference data. While this is effective for reporting, data warehousing analyses, and business intelligence, these corporations must duplicate their efforts to build transactional applications that cover the same data domain.
ObjectRiver has built the first
transactional, audited, event-driven master data
management system. This system combines the efforts of
cleansed information from warehouses and generates a
master database that captures transactions and
encapsulates them into business events. These events can
be delivered to workflow and messaging services for
forwarding to interested parties.
Business
Transaction
ObjectRiver business objects
are represented in the native language of the business
programmer. In the figure below, the cloud on the left
represents a Java business object. A typical application
reads one or more business objects from the master data store.
The application then modifies the
business objects that constitute the transaction, and commits
the changes. The ObjectRiver transaction processing engine
updates the business object, calculates a
change record for history and auditing, stores it,
and places all the objects and changes into
a business event queue.
How it works:
A transaction is a grouping of work items
that must all be completed in order for the transaction
to be complete. For an ObjectRiver transaction to be
completed, all database and history operations must
succeed. Operations are carried out in this
order:
- Start the database
transaction
- Obtain transaction IDs
- Determine which database
tables and rows are involved in the transaction
- Calculate object checksums
- Generate history records
for auditing
- Generate SQL
- Execute SQL
- Write history records
- Send the transaction to the
business event queue
- Commit the database transaction
ObjectRiver
MDM employs "optimistic locking," a technique
that avoids unnecessary locking of database records. Each
time a business object is updated,
the transaction engine increments the object's
version number. Version numbers are compared prior
to update, to make sure no data
has changed since the application read the
object.
Serverless
Processor Architecture and Performance
The ObjectRiver transaction processing engine is serverless, meaning it is embedded within the runtime.
In almost all cases, enterprises are forced to funnel transactions through a transaction processing server, which ultimately reduces throughput. Applications like ETL (Extract Transform Load) are typically batched and run as a separate process. In a serverless architecture, the application only needs to get a database connection to execute a transaction.
The transaction processing engine is very high performance,
because it is built on top of the native
database transaction processing infrastructure.
ObjectRiver uses stored procedures, masks, and clustered
indexing to achieve unprecedented performance. The
architecture provides ultimate flexibility for configuring
the database for new hardware solutions like blades or
grid computing.
Business Events
Business events are a byproduct of a transaction executed against the master data store. ObjectRiver’s Business Event Factory manufactures business events to drive processes. The business event contains all of the business objects that changed during the course of a transaction. Events can be forwarded to downstream data warehouses, silos, and rules engines.
Summary
ObjectRiver leverages database transaction processing capabilities to provide a high-speed transaction processing engine, with auditing and business event queuing.
Business Events
| 
