At the highest level, jBASE can be considered to consist of three components, each of which may be used separately or together to solve application development issues.

Application Development Environment
The first component is the Application Development Environment. This consists of several products. First and most importantly is the Basic language (jBC). This is the traditional language for developing applications in jBASE. The language, while loosely based on Dartmouth Basic, has been greatly enhanced and includes syntax that deals efficiently and powerfully with the benefits of the multidimensional database architecture. In addition to jBC, we also offer several interface products, which provide similar capabilities to jBC but can be used from different development environments. These products, known generically as jBASE OBjEX, provide an interface from two environments, Microsoft's COM and Java. The COM based OBjEX allows access to the jBASE database and application development environment from such products as Visual Basic and Delphi as well as products that support Visual Basic for Applications (VBA) including members of the Microsoft Office Suite. jBASE OBjEX provides a similar capability for Java based development tools, such as JBuilder, Visual Age for Java, Cold Fusion, etc. Using these tools a developer can take advantage of all the functionality of the jBASE database management system as well as the additional benefits of the jBC language. Modules written in jBC, perhaps existing business rules, can be called from Java and COM based applications. 

Middleware
The second component is Middleware. This component takes software developed in an ADE, (not necessarily jBC), and provides the ability to access a database, which may not necessarily be the jBASE database. The most important part of the jBASE middleware component is the jBASE External Device Interface (jEDI). The jEDI is a layer of software that is used by all Input and Output operations within the jBASE system. No matter what method an application uses to access the jBASE I/O mechanism the code used is identical. The jEDI itself can be thought of as having two parts. The first is the interface between the application and the jEDI. Every time an application accesses data from the jEDI interface, whether using Java, jBC, ODBC or directly from a 'C' program, the program will end up calling the same functions. This interface converts the I/O operation into what is known as a canonical form. The second part of the jEDI is the interface from the canonical form to the database itself. This interface, again a formal interface, can be thought of as a series of database drivers.

The jBASE middleware component provides the ability to access any type of data source using this mechanism. When the application requests data from the data source, the jEDI turns that request from a language dependent form into the canonical form and then into a form the data source can understand. These data sources are usually databases, but can be of different types. If there is a well-defined method of getting data out of an environment, a jEDI can be written to access the data and provide the interface to jBASE.

The standard jBASE product has jEDIs provided for the jBASE database. There are several types of jBASE files, j1 through j5, (j5 to be in a future release) and each of them has their own jEDI. Also included are jEDIs for the operating system files (e.g. directories and text files).

Another part of the jBASE middleware component is the jBASE Data Provider (jDP). This provides a standards based interface to the jBASE database (or more correctly to the jEDI). Any products adhering to the ODBC, OLE DB, JDBC or ADO standards can retrieve data from the jEDI interface and of course, therefore, from the jBASE database.

Database Management System
The third and final component of jBASE is the Database Management System. It is a Non First Normal Form database. This means tables can be embedded within other tables. This removes the necessity of having to perform the extremely resource hungry joins of the traditional Relational model.

jBASE provides very efficient support for multi-user applications. It has a locking mechanism that prevents users from overwriting data that is being updated by another user. It provides transaction management facilities where the application can be split into units of work, transactions, that group database activities together. An example in the banking world would be grouping a debit and credit together, ensuring that either both updates are done or neither.

Physically j1 through j4 jBASE files are hashed files. This is a very efficient way of ensuring a uniform distribution of data throughout the database, providing very fast access to all data held by jBASE. This method, however, needs a significant of administration and maintenance in a very volatile environment, where data is being added, removed or changed significantly over short periods of time. To improve on this potential inefficiency, we are introducing the j5 file system that will be a hybrid journaled and logged file system. This file system will provide self sizing and enhanced resilience, as well as being a 64 bit file system which removes any file size limit.

Summary
So jBASE is really three separate parts that can be used independently but when used together provide a superb technological platform on which to base future application development. With its openness, flexibility and power, the jBASE product meets or surpasses the requirements for world-class business applications.

Click here for news release on TRG becoming a jBase partner.