1. Rich Client Core Components

a RAD framework of class libraries and tools for constructing database applications that are efficient, robust, portable, and secure

2. Distributed Batch Processing Services

a general mechanism for automating repetitive, large-scale jobs in a distributed computing environment, built on top of Base One's core class libraries

3. Grid Computing Middleware

the layer that implements a "Virtual Supercomputer", built upon Base One's Distributed Batch Processing Services and core components

BFC's class libraries are the basic building blocks from which Rich Client applications are constructed:

• Database classes - encapsulating all database storage and retrieval operations
• Screen control classes - elements for creating interactive user interfaces
• Reporting and Graphing classes - integration with Crystal Reports and Pinnacle Graphics
• Number class and Utility classes - components for high-precision arithmetic and a large variety of handy generic functions

• Internet Server
• Data Dictionary
• Security System
• System Administration Facility
• Command Processor
• Database Trace Facility
• Help Creation Facility

Before elaborating further, it should be noted that there is a common feature in all of these programs:

Comprehensive error and exception handling, with meaningful messages, and provisions for automated recovery from failures. The full spectrum of errors, such as database errors (regardless of the database vendor), data entry errors, and disk crashes can all be logged and handled in a uniform fashion.

• rigorous, efficient transaction processing
  automatically synchronizing access and guaranteeing the ability to recover (rollback) from failures, while permitting a high degree of concurrency
   
• intelligent use of local storage for database caching and buffering
  increasing throughput by minimizing network traffic and server load

• optimizations through high-efficiency, DBMS-specific APIs
  using native direct connections instead of ODBC, as appropriate
  
  
• multiple compressed BLOBS (Binary Large Objects)
  extending individual records to include (logically) files such as graphics, text, sounds, Microsoft Office documents, or anything else required, as "attached objects"
  
  
• interactive, script-driven database Command Processor
  for local or remote administrative access to the server's database
  
  
• database trace facility for debugging and performance analysis
  allowing you to trace through any BFC / MFC, COM or .NET application displaying or logging all database function calls, the values of passed parameters, SQL statements, and processing start and completion times.

Since all database access in BFC goes through its Database Classes, any Rich Client application also enjoys the benefits of DBMS portability and network transparency. In addition, Rich Client applications can employ BFC's integrated class libraries for Screen Controls, Reporting and Graphing, Numbers, and Utilities, as well as its administrative tools for Data Dictionary maintenance, Security, System Administration, Command Processor, etc. 

Many of BFC's core facilities were themselves built as Rich Client applications, allowing administrators to perform complex server maintenance tasks without programming. This design has the virtue that it makes it easy to use these tools either locally or remotely, on a LAN, WAN, or across the Internet (through BIS). The programming behind these facilities also was greatly simplified by using the Rich Client architecture. Had we been constrained to develop a "conventional" browser-based implementation for our full set of server administration tools, there is no doubt that programming would have been far more difficult, and the resulting performance, reliability, and interfaces would have suffered.

• supporting back-end database security features for checking/changing passwords, grouping users and granting/revoking database privileges
  
  
• setting per-application access privileges on the basis of user groups
  
  
• defining security groups to control access to a particular set of screen objects, such as dialogs, forms, menus, buttons, web pages, and individual functions. 
  
  
• specifying prohibited actions for a particular set of users through security rules
  
  
• database session monitoring - keeping track of who is logged on, using which application, without cookies, and regardless of what machine they're using

• restricting against multiple logons to the database by the same user
  
  
• establishing custom encryption protocols between clients and servers
  
  
• automatic generation of per-user log files
  
  
• interactive facilities for controlling database access, allowing administrators to force users to log off, restrict logons, and broadcast messages, for example, in preparation for system maintenance or shutdown
  
  
• built-in types of both interactive and batch (non-interactive) users for efficient sharing and pooling of server resources, to handle very large numbers of users, distributed processing, and grid computing applications

In order to use batch processing, large jobs are broken down into smaller pieces that can be run individually, often in parallel, and with some set of interdependencies that determine constraints on the sequence job steps. For example, a large billing routine might be broken into sub-parts, each of which handles a different range of customer numbers. If multiple batch processors are available, the whole billing job could be sped up considerably. Once all of the billing steps are completed, another job might be automatically started to perform some consolidated accounting, and that might be followed by a reporting job, which may again be divided into a set of jobs that can run concurrently, and so on.

Since the Distributed Batch Processing Services are built on top of BFC and its Database Classes, batch programs automatically get the benefit of core features, such as simplified DBMS and network-independent programming, automatic transaction processing, caching, buffering, and local data optimizations, integrated security features, reporting and graphing capabilities, etc.

• robust database-driven architecture, fault-tolerant because it relies only on transaction processing and integrity mechanisms, without the complication of fragile interprocess communication and master/slave relationships. Databases are fully protected from failures by well-established systems for reliability and recovery, as provided and supported by the DBMS vendors themselves, e.g. disk mirroring, multi-processor clusters, transaction logging, remote hot backups, etc.
  
  
• supports a high degree of database concurrency, ensuring scalability with a locking strategy that minimizes database lockouts, so that many users and batch PCs can share a common, dynamic database efficiently. (Programmers can employ basic transaction commits, without resorting to less efficient distributed transaction commit logic.)
  
  
• automatically balances workload across a dynamic pool of available PCs, yielding better overall thoughput by making fuller use of available computing power within an organization, or even outside of it (securely through BIS), freely intermixing low-end Windows PCs with high-end servers.

Any idle PC, whether on the Internet or a LAN, can be turned into a Batch Job Server. This is done by logging on to a Rich Client application using a Batch User ID. The computer automatically becomes a "batch machine" that is capable of running as a Batch Job Server. Batch Job Servers do not need to be configured as Windows servers. That is, a Batch Job Server can run under the inexpensive client versions of Microsoft Windows (such as Windows XP).

For every batch job there is a Batch Job record in the database containing the name of a Batch Function and the circumstances under which it may run. A Batch Function is just a C++ global function or a C# or VB.NET function in a .NET assembly, written according to some simple conventions that allow it to be associated with one or more Batch Job records. As long as end-user interaction is not needed, many existing DOS and Windows programs can also be run as batch jobs.

Using a standard batch administration form, job dependencies can be set so that processing can be done in parallel by multiple machines. Batch jobs can be designed to wait for any combination of criteria, such as: a scheduled date/time or on completion of one or more other batch jobs with specific completion codes.

The overseeing operators monitor the progress of batch jobs from their own workstations, logging on with their own User IDs. With the use of Base One's Internet Server (BIS), operations staff can launch jobs and monitor results from remote locations - while getting the performance benefits of running the jobs on batch machines close to the database.

• exceptional support of Windows PCs, ranging from Windows XP to high-end Windows servers. Using Microsoft's premier developer toolset, Visual Studio, programmers can employ the full range of Windows technologies, including MFC, COM/ActiveX, and .NET, as well as a variety of popular third-party add-ins.
  
  
• highly scalable, fault-tolerant architecture, because it builds on the efficient, database-centric Distributed Batch Processing Services, which use robust native DBMS transaction processing reliability and recovery features.

• requires no specialized hardware or system software, since Base One's design is compatible with standard versions of Windows.
  
  
• works with any major DBMS, because this is a basic feature of Base One's core Database Classes, including automatic support of high-speed native DBMS APIs.
  
  
• provides extra security, in addition to standard DBMS and operating system features, through the Rich Client Security System and BIS custom encryption.
  
  
• enables rapid, controlled applications deployment, because executables can can be installed and updated without touching the Windows registry, system directories, or other operating system files. There are no browser compatibility issues, since no browser is required. For client machines that use Base One's Internet Server (BIS) for data access, there is no need to worry about ODBC settings or DBMS communication software compatibility, because the actual database software need only reside on these servers (BFC handles the rest).