Distributed Database System

Net DB

NetDB is a software development environment for creating and managing an integrated distributed network database among many workstations and servers to support development of "Occasionally Connected Smart Client" applications using a data-centric coordination strategy as outlined in the Microsoft patterns and practices document Smart Client Architecture and Design Guide.

Applications built on NetDB architecture have a unique capability to allow the user to operate disconnected from the server when network connection is unavailable while seamlessly integrating into the network database once a network connection is available. When the workstation has a network connection to the server, changes made on the workstation are automatically sent to the central server and updates made by other workstations are sent to the workstation. The transfer of data between the workstation and server is done in background even while the user is operating the application that uses the database.

The schema configuration of all the databases in the network, the forms displayed by the application shell and the printable reports are all controlled by one configuration file which is created and manipulated by the NetDB Configuration Editor. Database field definitions are designed to be application oriented with support for features such as legal value selection, constant table lookup and tables within fields.

The Network Database major components:

  1. Schema Analyzer maintains schema integrity and constant data definitions between workstations and server.
  2. Synchronizer insures all workstations and server maintain the current copy of all objects as well as maintain ownership integrity.
Schema Analyzer

The “Schema Analyzer” is not a very visible component of the “Network Database”, but is crucial to ensure the database works consistently across all the machines in the network. This component ensures that the schema definition of the databases on all machines are defined the same and contain any current constant data required by the application. The schema configuration is defined in an XML document that is evaluated by the analyzer and compared with the current schema definition in the database. If there are inconsistencies between the schema definition XML document and the database, the database is adjusted accordingly to reflect the schema definition.

Synchronizer

The “Synchronizer” ensures the definition of database objects on the workstation and server match. Since all workstations are running the synchronizer, then a database object that is created or modified on one workstation is synchronized to the server and then synchronized to all active workstations. No synchronization occurs when the workstation is disconnected from the network.

It is important to recognize that database objects and not individual database tables or records are being synchronized. This is necessary to maintain referential integrity in the databases and allow the database to be used on the workstation while synchronization is occurring

The Network Database objects

Database object defined

  • A record in a primary database table that has a single unique GUID key. This is the primary record of the object. The Schema Analyzer automatically defines the field “modification_date” to this table to store the date of the last changes to the object.
  • A set of records in any set of database tables that all contain the same unique GUID key of the primary record of the object.
  • Business logic that defines the rules by which the object is packed, unpacked, transfer between workstation and server, updated on the workstation and updated on the server. The current implementation of this business logic is embedded in the Bridge Works Service as a series of object classes derived from the base object “BridgeWorks-BWService-BWSystemObjects-Handler”, which contains all the generic code required to implement an object.

    • A database object needs to be consistent within itself so that it can be packed, transferred and then unpack on the destination machine without regards to any other object in the database. This allows the application to be able to use the database on the workstation while the synchronizer is operational. This gives the user the appearance that the database is “alive” such that a database object (such as a Control Data) can be created or modified on one machine and then shortly appear on another machine

    The Synchronizer

    The “Synchronizer” works by maintaining the following “System Header” information for each database object:

  • The GUID key of the primary record of the database object.
  • A 32-bit size value that is the number bytes in all the records of the object. This limits the size of an object to 2 GBytes but not files, files are handled separately and are discussed later.
  • A 64-bit CRC value that is a modified version of the 32-bit Cycle Redundancy Check based on ANSI X3.66 (also known as FIPS PUB 71 and FED-STD-1003, the U.S. versions of CCITT's X.25 link-level protocol) to generate a 64-bit CRC value. This calculation detects changes between two objects that are consider the same but is NOT guarantee to be unique between any two arbitrary objects.

    • A database object on two different machines with the same GUID key are consider to be the same if the size, CRC and modification date are the same. The task of the “Synchronizer” is to compare the list of objects on the workstation with the list of objects on the server to make sure the lists on the two machines are consistent. The term “consistent” means either the object attributes are the same or the difference meet the business rules of the specific object. For instance it is possible to restrict the list of Control Data that is transferred to the workstation based on the “Inventory List” of Control Entities (a.k.a. bridge structures,) therefore a Control Data object may not exist on the current workstation because it is not on the inventory list.