NexusDB

When it comes to extensibility, NexusDB has no equal. NexusDB stands alone from its competitors by realizing extensibility in three ways: custom Sub-Engines, Monitors/Extenders and Plug-ins.

Custom Sub-Engines

Custom Sub-Engines are completely unique to NexusDB. Sub-Engines are layers of implementation that you can replace or modify based on your database needs. For example, sub-engines can change the way NexusDB stores its data, compares its key values or structures its indexes. The reason why this is so unique is that great care was taken to keep the core engine working on the interface defined by the abstract base class of each sub-engine. This way, the core engine does not need to be modified to enhance and adapt NexusDB's significant operations to your needs. No other database is as flexible.

Here are NexusDB's sub-engines and their associated responsibilities:

• Record engine - Defines the logical layout of the data for a record; interprets the contents of the physical block of data.
  
• Blob Engine - Defines the logical and physical format of blobs.
  
• AutoInc engine - Can customize the sequence of AutoInc fields.
  
• Encryption Engine - Encrypts the data in the database; implement different encryption algorithms based on your security requirements.
  
• Indices Engine - Maintains a list of Index Engines and notifies them when data changes; can have a different Index Engine for each index on a table.
  
• Index Engine - Controls the way the index is implemented; has virtual methods for data modifications to enable maintenance. For example, bit-mapped indexes and other algorithms can be implemented here.
  
• Key engine - Comparison and generation of key values.

Each sub engine has a well defined interface and is registered to particular database objects within the data dictionary. No other database has this architecture or enables this much flexibility.

Monitors/Extenders

NexusDB has an internal event infrastructure that you can hook into by means of Monitors and Extenders. Monitors/Extenders allow to change the default behavior of database events that are fired on particular changes or conditions that occur within NexusDB's core engine. These function very much like triggers but due to its integration into the core of the database engine are actually much more powerful. Monitors and extenders always work together.

Monitors get notified on creation of server internal objects such as sessions, databases, cursors, ... At this time the monitor can attach extenders to these objects.

Extenders can be attached to a variety of server internal objects. Once created they get notifications of events occurring within these objects (e.g. the posting of a record in a Cursor object) and can stop, change or extend the default behavior (e.g. disallowing post for certain users).

Monitors and Extenders can be used for many purposes: logging, custom security systems, referential integrity, ...

The event mechanism within NexusDB is extensive and complete; Monitors and Extenders empower you to exploit this mechanism.

Plug-ins

Plug-ins utilize NexusDB's transport system to build completely integrated, custom distributed services. Plug-ins provides a middleware solution to enable remote interface invocation within NexusDB's infrastructure. The mechanics are very similar to an RPC (Remote Procedure Call) system.

There are three components that need to be created to leverage the Plug-in architecture: a Plug-in Engine, a Remote Plug-in Engine and a Plug-in Command Handler. The Plug-in Engine is the actual implementation of the extension or service. The Remote Plug-in Engine is the interface a remote client invokes methods upon locally. The Plug-in Command Handler dispatches the commands received from the Remote Plug-in to the actual Plug-in Engine implementation.

The Plug-in Engine and the Remote Engine are analogous to NexusDB's Server Engine and Remote Server Engine. The Plug-in Command Handler is analogous to NexusDB's Server Command Handler. These components use the existing transport layer to make this happen seamlessly.

Plug-ins open up a world of possibilities and can be used for things like Server Administration or Diagnostic information. Plug-ins enable the client to leverage the existing database connection and transport mechanism. The Plug-in model parallels the core server model utilization so using it is very natural. All this adds up to a flexible middleware solution with virtually no additional overhead.