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).

To further understand the power of the jEDI architecture, let's examine a real software application, T24, the world's premier Banking Software, from TEMENOS. This product currently runs on jBASE and uses the standard jBASE database. The plan is to also offer T24 on DB2 and Oracle. This will be accomplished by writing a jEDI for each of these two databases. The jEDI will translate the T24 request for data, or the request to write some data, into the comparable operation for DB2 or Oracle.

This means that no matter where the data resides, jBASE, DB2 or Oracle, the T24 application code will remain exactly the same, obviously benefiting application development schedules, maintainability and flexibility.

Currently, the T24 application takes advantage of the multivalue capabilities of the jBASE database (a Non First Normal Form database). This functionality is not supported by flat databases such as DB2 and Oracle, therefore the jEDI must also convert the sophisticated multidimensional architecture of the jBASE database into the multiple joined tables of the flat relational model.

The question that everyone has about this architecture is how it will affect performance. The answer is that jEDI architecture does not. This is not to say that T24 will perform the same using the jBASE database versus using DB2. This is not the case; the performance characteristics will be completely different for each scenario. However, assuming that a jEDI is written efficiently, the source code is simply compiled into an application calling the native database access methods, in exactly the same way as it would be done by any other Application Development Environment.

The jEDI architecture also provides several other benefits. The first is that application specific logic can be added to the jEDI. A very good example of this is the sophisticated security model of T24. This security model prevents unauthorized access to sensitive banking operations and data. This is currently done at the application level, so any access to the T24 database must go through the application. This is not a ideal situation since it would be much more efficient and useful if clients could access T24 data directly from analysis products such as Microsoft Excel or reporting tools such as Crystal Reports without having to go through intermediary steps. If the security model were implemented within the jEDI, all accesses would implicitly use this security model and could be accessed using whatever standard tools are required. (This functionality is planned for a future release of T24).

The jEDI interface proves beneficial in the way it is used by other products in the jBASE product suite. A good example is Transaction Journaling. Transaction Journaling records every time the database is updated and can be used to maintain a hot standby system. This is accomplished by passing the journal entry to another process, which applies that journal entry to another separate database. These journal entries are created at the jEDI level and are therefore database independent. This means that jBASE can mirror different types of databases, ensuring that a jBASE, Oracle or DB2 system are replicated quickly and efficiently using data written to any one of them from the T24 application.

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.