A one-paragraph summary of Polyhedra:
Polyhedra is a family of programmable, event-driven, real-time, persistent database management system with an active, relational, fault-tolerant, client-server architecture and a 4GL object-oriented client; it is multiplatform, and capable of being used for fault-tolerant, distributed, real-time applications on a heterogeneous network of computers. Servers can be accessed locally or remotely by client applications using our JDBC and ODBC libraries, our proprietary C++ client API, and, for PCs running Linux or Windows, via ODBC drivers. Finally, there are interfaces allowing direct interaction with data-gathering and machine-control devices.
These points are covered individually in the following paragraphs.
In classical programming languages, such as C and Pascal, programmers can define and name their own data types: for example, one could set up a (not very) complex data type called Position, consisting of two integers that were referred to as the x-part and the y-part. The object-based programming methodology extends this concept, by allowing one to associate functions and procedures with the data type definition, thus grouping together the information about an object with the functionality of interrogating and manipulating the object. It is often possible to hide the data from exterior view, so that the only way of accessing the data of an object is via the supplied functions and procedures. The functions and procedures of a data type are referred to as its 'methods', and the complete definition of a data type plus its methods is known as a 'class' definition; the component data types making up the data type part of a class definition set up the 'attributes' of that class. Given an object, it will be an 'instance' (or 'member') of a particular class definition; the methods of that class can be use to manipulate the object, and the value of the object is defined by the state of its attributes.
Object-oriented ('O-O') programming systems such as C++ extend upon object-based systems, by saying (a) one class can 'derive from' another class, inheriting all its data and functionality (attributes and methods); (b) in the specification of a new class, one can add extra attributes and methods over and above those inherited from the parent class; and, (c) the new class can provide a new definition of an inherited method, to be used in place of the old method when operating on an instance of the new class.
O-O is a more flexible concept than the earlier approaches, encapsulation is much improved and so it allows better modelling of real-world concepts by programs. Code re-use is very much enhanced and by building up gradually through a hierarchy of classes, it becomes easier to document, inspect and test the extra features added at each stage. It is these properties that have led to the widespread adoption of the object-oriented methodology in recent years.
However, when it comes to distributed systems and the need for persistent data, the concepts of the O-O methodology becomes much harder to grasp; this, compounded by the lack of mature standards for the support of the concept of distributed objects or the distribution of objects means that other philosophies are needed when developing critical, supportable, distributed applications
The relational model is a way of looking at and organising information, without reference either to its semantics or how it is stored on disc. It builds on the mathematical concept of a 'relation', and one will hear purists talking of 'tuples'; pragmatically, however, one can view a relational database as a set of base tables, each of which contains a set of records all of the same structure.
Most relational databases are set up, inspected and altered via an interface language called SQL. This has statements for setting up the database structure (defining the forms of the various base tables), and then just 4 other statements of everyday use: INSERT for adding a record to a base table, DELETE to remove selected records, UPDATE to alter attribute values for selected records in a table, and SELECT to retrieve information from one or more tables. Apart from INSERT, there are no statements for dealing with individual records: instead, they operate on all records that match the supplied criteria. The result of a select statement always looks like a table, though it may be empty or contain just one 'record'.
The SQL language is covered by an ISO standard.
In practice, when dealing with database systems that will have to hold multi-megabytes of information, the person designing a relational database has to know the semantics of the information that will be stored in it, and also the kind of queries that will be made. The designer will then have to indicate to the relational database management system (the RDBMS) how information is to be stored on disc, otherwise performance will suffer. On the other hand, the user who wants to store and retrieve information does not need to worry about this, and has only a simple interface to master. It is this simplicity that led to the widespread acceptance of relational database technology from the mid-Eighties onward. However, the relational model is only concerned with data, and not the rules that control the manipulation of the data given some semantics. What is really needed, is a system which combines the benefits of O-O technology within an individual process, combined with the simplicity of the relational model for interrogating and manipulating data from afar.
Microsoft Windows NT and UNIX platforms are essentially general-purpose computers, though in practice they are often used in a dedicated fashion, running a specific set of applications. There are also operating systems which are designed from scratch to be operated in a dedicated mode, often on computers with limited resources - little memory and no disc store for example - which have to be used economically. These computers are often 'embedded' inside a system, so that the computer is only a component of the product. If the product is being sold in quantity, the pressure to reduce the cost of individual components (such as the computer) is high.
While 'embedded operating systems' may provide a UNIX-like interface to the application programmer, the limited resources available mean that even those software packages that can be ported may not operate harmoniously in these environments.
The databases you build with Polyhedra are object-oriented, but are viewed externally as SQL relational databases. As required of an O-O system, inside the database we provide inheritance and re-definable methods, as described below.
We have extended standard SQL so that you can say one table is 'derived from' another; thus one can have a table called 'machine', say, (with information about size, position, last service date and next service date), and then derive from that tables 'cutter', 'presser', 'wrapper', say, each with added attribute appropriate to that machine type. If you issue the command 'select * from machine' you will see an entry for each record in cutter, presser and wrapper; the attributes returned will be those defined in the machine table. If however you say 'select * from cutter' you will get back one entry for every record in the cutter table, and the attributes returned will be those defined in cutter together with those inherited from the definition of the machine table. (In a 'traditional' relational database one would have had to define 'cutter' as a table whose primary key was a foreign key to the machine table, and then have had to use a join to determine all information about a cutter.)
To complement the attribute definition for a class (table), true object oriented systems allow you to supply 'methods' or handlers - functions and procedures that operate on objects (records) of that class. Thus you can supply a definition of what should happen when an object is created or deleted, say; in Polyhedra, one can also say what should happen when particular attributes are altered. This allows you to design a database which is self-maintaining, where all the necessary integrity checks and knock-on actions are performed efficiently inside the database process, simplifying the design and implementation of the client applications. It also means that the level of normalisation required in the database can be reduced, simplifying both the design of the database and of the queries made on it by clients, since the handlers can maintain the data consistency normally only achieved by strict normalisation.
Polyhedra also supports 'virtual methods', another must-have for a true object-oriented system. If you define a procedure for one class, it can be redefined in any subclass. For example, one could add a 'checkAlarmStatus' procedure to the machine class, and redefine it to do the appropriate action in each of cutter, presser and wrapper.
'CL', the method definition language in Polyhedra, is a 4GL, giving much greater readability (and maintainability) than a third-generation language such as C++. For efficiency and portability, it is compiled into 'bytecode' for an abstract machine and this bytecode is interpreted at runtime.
Inside the database, everything is an object, with a 4GL method language: this means object and inter-object integrity can be readily expressed and efficiently enforced; 'knock-on' effects can likewise be performed inside the database, simplifying the job of those writing client application code. Their job is also simplified by the use of the well-understood relational model for data access.
As mentioned above, Polyhedra allows you to define methods to be invoked when individual attributes of an object (in a given class) are changed. Methods can also be supplied for invocation when objects are created and deleted and also for invocation when a database is restarted.
Polyhedra was designed initially for use in process control applications - where data volumes are relatively small but responsiveness is essential - though its usefulness extends far beyond that field. To achieve its responsiveness, the whole database is kept in store; data persistence is handled by allowing snapshots to disc and optionally by journalling information about transactions to disc. Depending on the computer in use (and also on the complexity of any methods invoked), the number of transactions per second is measured in the hundreds (Windows '95 on a Pentium, say) to the thousands (a modern UNIX workstation). When working over a network, the transactional rate achievable by an individual client process is much lower, as to be expected, but overall performance offered to a collection of clients remains unchanged.
The Polyhedra database can communicate with a variety of Programmable Logic Controllers (PLCs) and Remote Telemetry Units (RTUs) as used, for example, for monitoring and controlling machinery. Information about the drivers, networks of devices, individual devices and points on those devices appear as objects of appropriate type in the database, to which handlers can be attached; consequently, state and value changes can be processed inside the database. A kit is available to allow you to write your own drivers in C++, which can then be linked in to the database or run as separate processes (which do not have to be running on the same computer as the database, or even on the same type of computer!).
Active, relational client-server architecture
Polyhedra clients communicate with Polyhedra servers by issuing SQL requests: INSERT, UPDATE and DELETE statements to change the contents of the tables (classes) and SELECT to interrogate the contents. Table joins are supported, as are complex WHERE clauses so that you can retrieve just the information you require. However, use of the class inheritance facilities on the database often means that joins are unnecessary. The queries you make can be 'active' - which means that the server remembers your query, and later when the database contents change it sends you the 'deltas' to bring you up-to-date. No need to poll!
Further efficiencies are gained by allowing 'object queries' (both one-shot and active) to allow individual objects in the server with known primary key values to be queried without involving the SQL interpreter. In addition, when active queries have been established, updates can be made via those queries, again avoiding the SQL overhead.
The Polyhedra RTRDB - the main Polyhedra object-relational database component - can act as both client and server, so that a database on one machine, could set up active queries onto another database on the same or another machine.
The client-server connections are dynamic: there is no need to preconfigure which clients are able to talk to which server processes. Connections can be established and dropped as and where appropriate, and there is no limit on the number of concurrent connections from a client or to a server.
'CL', the same 4GL used to define methods in Polyhedra databases, can be used with the CLC module to build client applications. A limited number of non-graphical classes are provided, and applications can build their own classes from these to achieve the effects they need. CLC applications can connect to any number of Polyhedra servers, and such connections can be set up and dropped dynamically as the need arises.
Polyhedra runs on a variety of UNIX platforms, and also on Microsoft Windows 95 and Windows NT, and on embedded operating systems such as pSOS and VxWorks. The Polyhedra support environment takes care of any data reformatting required when communicating between disparate platforms. Completed Polyhedra applications are platform-independent, aiding future migration.
One can set up a pair of Polyhedra databases in a fault-tolerant configuration, where one acts as a hot standby for the other: the two databases will typically be on separate computers, not necessarily of the same type. The standby database will have an up-to-date copy of the information in the master database, and so will be ready to swap to master mode if the other database crashes for any reason, such as a machine failure. When the database, previously the master, is next restarted, it will then be set up as a standby for the new master database, in case that one crashes for any reason. Alternatively, where one machine is of lesser performance than the other it is possible to set up the system so that the database on the more powerful computer will automatically be given control once it has been restarted.
If one is using a fault-tolerant database setup, the Polyhedra clients can simply be told which are the servers that are involved, and will automatically switch from one to the other as needed, with no interaction required from the user; in fact, by default such switching will be invisible to the higher-level application code, so that Polyhedra applications written without fault-tolerance in mind can be upgraded with ease.
To allow Windows/95 and Windows NT applications such as Microsoft Access and Visual Basic to interact with Polyhedra, ODBC and DDE drivers are available. These run on the Windows machine, appearing as data servers to the Windows software, and as Polyhedra clients to the Polyhedra servers to which they provide access. These Polyhedra servers could be running on the same machine, or could be running on another machine, not necessarily running Windows, providing that the computers involved can communicate over a network.
To allow fully-flexible access to Polyhedra servers, two separate client API kits are available, each allowing programmers to connect to, query and update one or more Polyhedra servers concurrently. One is based on the callback programming model, which is well suited to event-driven applications, while the other is based on the international-standard ODBC model.
Polyhedra features >