The future by design.
| |
AxleBase
The future by design. |
|
|
summary description applications home page documentation inquiries policy letter queued caution |
Advanced Technology In A Database Manager Description ( Please scroll down. ) |
tests limitations change log demonstrators date protocol syslink protocol nomenclature research |
Technology And Web Site
__________________________________________________
_________________________
_________________________
Not Objectives Heavy concurrent access.
( Big name brands such as MySql, Microsoft SQL Server, Oracle, and IBM DB2 should be considered for ordinary needs. Ordinary systems and AxleBase require very different engineering for best performance and to avoid catastrophic stress failure.)
_________________________ Anybody who knows standard SQL can immediately query an AxleBase database. AxleBase uses the standard ANSI-92 SQL language. He does not require a super-computer query language. When a user wants to use one of his advanced technology functions, it is added as an extension to the basic standard SQL. The employment of his extensions never alters or interferes with the canonical SQL syntax, lexicon, or construct. They merely slide into the standard construct when needed. To insure support of standard ANSI-92 SQL without confusion of users, the extensions are hidden and will be found only by studying the documentation. Furthermore, the documentation of each extension openly and explicitly states that the subject extension is a deviation from the ANSI-92 SQL standard.
_________________________ Can be compiled or built into any software that needs a database manager. Includes a complete programming interface with complete SQL commands. This feature was a design objective and is not an after-thought. He is a dynamic link library, a DLL, that runs inside host software. AxleBase is ODBC compliant so he can support any host's database drivers.
_________________________ His interface allows him to be totally controlled by the host system. The interface has over a hundred commands, many of which are overloaded and configurable. It is thoroughly covered in his documentation with hundreds of examples. The interface includes an error protocol that is designed for the host interface. Each error return includes a standard error number for unattended action, and includes a human language message. Free demonstrators are available upon request with AxleBase embedded. (See the demonstrators page for details.)
_________________________ A database server is a host that provides communication between a database manager and its client computers. AxleBase is the database manager. AxleBase is designed to be embedded in any host, including a server, thereby turning it into a database server. Embedded in a server, AxleBase provides all features (and much more) of a high-end database server. Multi-threaded servers are supported. AxleBase handles all database functions including local and remote object locking. The server can use multiple AxleBase instances to service multiple inbound client threads. Any instance on a thread can assume the role of master database controller under the host's control. A free database server demonstrator, with AxleBase embedded, is available free of charge. (See the demonstrators page for details.)
__________________________________________________
_________________________ An understanding of the AxleBase technology requires advanced concept abstraction and a general understanding of computer and network infrastructure. If you are not a data professional, then discussion of this section with a database administrator ( DBA ) or a computer science professor is recommended. The AxleBase technology sets him far above the enterprise class wielding quantities that are usually found only in astrophysics because they are so vast. There was no name for his class when he was created because he was the only one in it, but the big-name brands and open-source hobbiests have begun to follow with attempts at AxleBase-class systems, thereby recognizing the class. The average DBA can use AxleBase "out of the box" like a normal database manager. Other than that, he makes no attempt to be politically correct. His advanced features were designed without apology to provide tools for the master DBA who can visualize and work with high level abstractions to achieve unbelievable goals. User Consideration :
Project State :
_________________________ Objective Met :
The number is so big that an example might help. If the books in the biggest library in the world, the Library Of Congress, were converted to electronic characters for computer storage, then a single AxleBase table could hold the entire library. Furthermore, that single table could hold millions of those libraries. And each database can hold many tables. Tests have reached a table size of 843 trillion rows containing 67 petabytes of data on desktop computers; thousands of Libraries Of Congress. Tests must continue pushing since that is only a fraction of his design limit. ( An internal alteration would allow him to address quantities near planck values.) What he is not :
Special Language For Vast Storage :
Very Large Returns :
Indexing :
His Size :
( Test Data :
( He does not need a bigger or faster platform, and misguided attempts to enhance his platform might interfere with systems as advanced as is he. His engineering compensates for platform shortcomings which is why he can run on desktop computers.) ( Those who are not having fun watching the big name-brands trying to catch up are simply unaware. However, theft by the open-source community was very disappointing.)
_________________________ Objective Met :
( Perhaps unbelievable, so here is a blatant statement: The software engineering expands and enhances the hardware. ) AxleBase was the world's first database manager that was designed to automatically distribute each of his data objects across multiple storage sites so that multiple small storage sites can hold a very large data object. AxleBase defaults to using local storage. His activity is then like that of any other database manager, and his administration is as simple and simpler than some. The difference is that the DBA can give him a permission list of computers and disks that he can use for storage of a table that will grow into a large size. Special Administrative Requirements :
OLTP :
Distributed Query Language :
Speed :
System Utilities :
Since distribution can be a powerful tool for the DBA, it is not limited to very large tables. Even small tables of only millions of records can be distributed. Also, tables can be placed on separated computers. Indices can be relocated. Etc., etc. Objects can be distributed merely to increase processing speed. Research into indexing, error handling, and many other areas has yielded sub-systems inside AxleBase that are designed especially for large distributed entities. AxleBase is designed for the network as an abstraction to allow database distribution across any kind of network. Data can be stored on any kind of operating system that can be queried by the base operating system. Database distribution can be done on the cheapest desktop computers. Benefit analysis of an AxleBase installation can sometimes show cheap desktop computers giving the best performance even for wealthy organizations. So what does all that mean in human terms? It means that the Library Of Congress can easily be stored and queried on a few cheap personal computers. (If you understand that awesome power, then prepare for a real shock in the next sub-section.) Multiple Instances :
Data Safety :
( Reiteration :
_________________________ No appology is made for the complexity of the technology in this section. It is designed for the professional, capable, and creative DBA. It is expected to be implemented and administered only by men of intelligence. Objective Met :
AxleBase was the world's first database manager whose design objectives included the distribution of itself. (This is in addition to the data distribution that was covered in the previous sub-section.) He delivers astronomical computing power through decoupled systemic parallelization of cheap personal computers. ( His development lab uses the cheapest and oldest computers that can be found in local stores.) Now, back to human terms to help grasp this technology. It means that the Library Of Congress that you stored on a few cheap personal computers in the last sub-section can be queried by other cheap PC's with the speed of million dollar computers. Nomenclature :
Distributed Operating System :
Distributed Supercomputer Language :
OLTP :
Query Distribution :
Table Aliasing :
System Utilities :
Security :
Multiple Instances :
Data Portals :
Concurrency :
Why the axsys ?
( Reiteration :
( Interesting Behavior :
_________________________ Objective Met :
Neither a distributed system nor a distributed database requires distribution of the other. However, a distributed system's power is wasted when managing a standard localized database. ( Recognizing that the AxleBase technology may be the most advanced in the world, after covering the practical "nuts and bolts", the documentation introduces the DBA to theoretical realms that are opened by the technology. It thereby gives him a conceptual over-view so that he can critically monitor and assess the application and performance of the technology.)
_________________________ AxleBase can be operated as a standard database manager. Even as a desktop database manager. As such, he will appear to be a "run of the mill" DBMS. Objective Met :
The DBA can select from various axsys startup methods. At the most extreme, he can design his axsys so that it instantiates, monitors, and repairs itself. The DBA designs the axsys that he wants, enters its parameters, prepares the infrastructure, and powers up. Then AxleBase does the rest while the DBA monitors. (No slight intended for the DBA whose job never ceases, but the essence of the above is correct.) The axsys mechanism allows the DBA to specify nodes by location or he can generalize configurations so that any instance that comes on line will assume the functions of a required node. Such a volunteer node will automatically register itself with monitors and controllers in the axsys. AxleBase allows alteration of all aspects of a functioning axsys, including the architecture, without taking it down. It can continue to operate while the DBA changes it to meet changing needs, even when its power is altered greatly. Tools include the ability to command all nodes to reconfigure. If the data is distributed, every AxleBase entity knows how to find it and manage it. If the system is distributed, each entity can become a node as it comes on line so that the axsys configures itself as it wakes up. If both the data and the system are distributed, each AxleBase entity knows what to do when he comes on line. Traditional computer system logic requires that the host in each node be the controller, but the objective is to keep the host as simple as possible. Therefore, the node configuration is online in each AxleBase instance and the interface includes local host service. That allows each host to query its AxleBase instance for instructions. Therefore, if desired, a single generalized host server can be created which can follow the configuration directives of its local AxleBase instance. All of this technology is documented in detail for the DBA. Although the advanced technology requires capable DBA's, database users need know little or nothing about it and may even be unaware of it because AxleBase hides it. Example :
More autonomic behavior is covered in the Fault Tolerance sub-section.
_________________________ A Stable Foundation :
Fault Space Assessment :
Objective Met :
Careful design of the distributed system, as guided by the documentation, on a large and reasonably stable network can actually increase robustness as the distribution increases. Instead of a feared theoretical exercise, the skilled DBA can turn the distributed database manager into a solid operational asset. Model Flexibility :
Communication Disruption :
Lost Node Recrescense :
Query Corruption :
_________________________ The distributed system object that is created by AxleBase is an axsys. An axsys object is AxleBase in his distributed form. As with any computer object, the axsys creation event is referred to as an instantiation. An organization that needs an axsys requires a unique axsys, so each will be designed by the local DBA and system staff to meet those needs. AxleBase has the flexibility to meet nearly any conceivable design and is prepared for any implementation "out of the box". It should be remembered that the axsys is a system and an entity despite its distribution. AxleBase expresses strengths and characteristics in his distributed form that are not found in his local form. Those are addressed in the documentation. The axsys consists primarily of nodes, each of which is a computer that is controlled by an AxleBase instance inside its host software, which is a server. The AxleBase instance in each node configures that node for its specialized operation in the extended entity. The host can be a simple server that is designed to run AxleBase.
The documentation includes suggested and detailed descriptions of the types of node hosts that the DBA might want to deploy. The primary jobs of an axsys host are :
The host needs no database programming. It needs little knowledge of the embedded AxleBase instance. Common tcp/ip communication is the only complex need. The SysLink application-level communication protocol is provided as a courtesy to simplify communication. His primary interface of over a hundred commands can be used by a server or any other host. Additionally, AxleBase offers a simplified interface specially designed for lightweight servers. It is an orthogonal abstraction of the entire primary interface into a single command. A command can be created on a distant controller instance and shot into the target nodes through that interface. The AxleBase self-configuration in each node allows the various types of hosts to be similar servers, perhaps with slight alterations for node types. The result is a lightweight node host and reduced programming for the local organization's axsys. ( The demonstration server uses Windows socket programming. Some thought might be given to sharing the demonstration server code, but production servers are expected to be even smaller and to have a more robust design. The demonstrator has a GUI for demonstration monitoring, whereas production servers can be built as operating system services.)
_________________________ Objective Met :
Clarification :
AxleBase Virtualization Types :
Updates :
Source Location :
Concatenation :
Quantity Limit :
Size Limits :
Indexing :
Table Aliasing :
Security :
Text :
ODBC and Gateway :
SQL :
Fault Tolerance :
Table Integrity :
Purpose :
_________________________ AxleBase can deliver extremely detailed and long-term persisted auditing for governments and other organizations. His core architecture contains a detailed audit trail that is usually not manifested and cannot be defeated because it is part of the internal system structure. System design routinely discards the activity by default, but the organization that needs it can easily put it into service. Additional audit tools can be turned on if needed. When they are turned on, any table created in the database is created with additional non-updatable audit data fields that are added to the audit trail. This feature is not intended to suggest that AxleBase be used for heavy-duty on line transaction processing or heavy concurrent usage. Those are not his purpose. For such purposes, please consider one of the many fine normal database managers on the market from MySql, Microsoft, Oracle, I.B.M., etc.
_________________________ The management of a normal database is like that of any normal database manager. For more powerful configurations and uses, the interface has a complete set of advanced commands, utilities, and tools for the DBA. Research into the advanced features identified special needs for support of the DBA. The documentation guides the DBA with suggestions for system design and management. Only the documentation can adequately present the tools because the list is long and involved. The following may be indicative of the power given to the DBA.
__________________________________________________
_________________________ In an extravagant age where value and power are defined by cost, AxleBase stands alone against the trend. He is so radically different that some thought was given to placing this cost sub-section in his Advanced Technologies section. Objective Met :
In an age when every computer user thinks that he must have a huge disk drive and every manager requires the most expensive storage, AxleBase delivers huge storage and very high speed from the cheapest and smallest disk drives that can be found. Disk drives are used for years in the AxleBase lab until they die. Do not expect slow speed when he runs on desktop machines. Sometimes, yes, but years were invested in engineering him to deliver phenomenal speed from them. You will notice that the tests on the Test page were run on very cheap machines, some of which were very old. ( For those who need to spend money, AxleBase can also use expensive high-end multi-processor servers. But it is the intent of the AxleBase technology to make such expenditures ridiculous.) Networks, also, can be low end. AxleBase will settle for any network that can be afforded. Some types of operations, such as the join of large tables, can benefit from a faster network, but that is not required. AxleBase is built upon the concept of frugal simplicity. His internal simplicity that generates great power has demonstrated that, because of our inability to build sophisticated software systems, we have hardly touched the capabilities of the existing hardware investment. The rhetoric of software engineering has camouflaged a failure. ( If a giant software company tells you that you must have million-dollar mainframes, or billion-dollar super-computers for size and performance, or a cloud-computing contract, please refer them to the published AxleBase test results.)
_________________________
Computers Because he, his tables, and his databases can be distributed, AxleBase is expected to use a variety of equipment and operating systems. He is expressly engineered for high performance on low-end desktop computers. However, he and his data can be placed on large servers if desired. Manager :
Data :
Network His internal architecture and code are designed with generalized communication theory in mind because he was purposed for the generic computer network. That means that he can be expected to run on any of today's networks. His architecture, error handling, and tools are expected to perform to spec even on the internet. He is kept above all network protocol layers. His error handling protocols, management tools, and internal communication protocols ride totally on top of, and are independent of, network protocols. Since he adds his own layer to the network stack, any network that reliably services his communication protocol will suffice. LAN, grid, cloud, mesh, wireless, etc. are irrelevant to him. His advanced technologies are designed to morph into the network architectures that are being investigated. He requires only the continued transparency and dependability of the original Unix communications. Although irritating to the users, network delay is irrelevant to AxleBase even when he is a distributed system. Since he was designed with even the internet in mind, he and the DBA can compensate for unforeseen delays. AxleBase is designed with low-quality media in mind. Personal experience has shown that large networks are sometimes noisier than can be tolerated by precision database operations. The AxleBase architecture and tools address that issue in his distributed operations. An AxleBase installation can be made so vast that it can actually exceed the geographical and hardware boundaries of local networks. The DBA is given tools to manage such an entity, and the documentation gives some guidance. ( The power of today's network arises from the fact that it was designed to provide transparent and unobtrusive communication between Unix systems. Even the noise and mayhem on the internet cannot defeat its power. But if idle hands begin interfering with applications that use networks to communicate, then all is lost.)
_________________________ Although not a glamorous feature, this one has dictated to all other project development because it should be a moral imperative for software. The AxleBase interface is based upon a few unusual ideas. 1. Data belongs to its creator ; not to a giant software company. 2. Technologies, even those as profoundly advanced as AxleBase, fade away, and sometimes with them the data that they contain. 3. Security should be in :
The result of those three factors is an unusual design in AxleBase that puts all data and system configuration within reach of its owner. Data is not captured by the system to lock people into AxleBase. Data is stored as standard ASCI text. The DBA can access his data with any text readers or other text handlers. Yes, even notepad. (Of course, AxleBase also has export and import tools.) The decision was made for AxleBase to even store numbers and dates as plain ASCII text to meet this moral imperative. (This is not to denigrate other systems that store numbers and dates as unprintable and unreadable characters, but to insure that AxleBase data is accessible.) Even definitions and system configurations are in readable text. Table definitions, for example, are identified with the data and can be opened in notepad. Data will not be lost for want of a definition. ( If a giant software or cloud-computing company tells you that complete accessibility will slow operations, please refer them to the test page on this web site. If they tell you that it will defeat security, please refer them to the security section on this page.) ( Control Codes :
_________________________ AxleBase security is so sophisticated that it goes up to the VPN level (virtual private network). Therefore, he allows his security to be addressed in layers and discrete functions for administrative simplicity. Basic Security Security administration can become complex in any database manager and especially in an AxleBase installation, so security defaults to off upon installation. The DBA can then begin turning on security as he learns and as needed in the installation. AxleBase offers basic security at three levels that can be controlled by the DBA.
Basic AxleBase security uses the standard crud model. Crud permissions are applicable at all three levels. After security is turned on, every permission for every object defaults to "no". Enabling security also enables the passthrough control, which is separate from crud controls. Passthrough access can be controlled by name and password at the domain and at the database level. For example, if access is restricted at the domain level, then the databases in that domain can be accessed only by user name and password at the domain level before encountering the database passthrough controls. Encryption and Authentication AxleBase contains his own encryption and authentication mechanisms with selectable encryption depths. Encryption depths are set by the DBA in the database attributes. Encryption may be ordered at several points. The DBA can set the system toggle to encrypt communications. If the DBA has not ordered encryption, then the client may order an encrypted data return within each query. A client with an embedded AxleBase instance may configure its local instance to encrypt all traffic. Since AxleBase is embedded in the user's host, the user is free to use third party encryption and/or authentication for traffic going through it. That choice is neither recommended nor discouraged. Professionals who are dedicated to encryption and/or authentication would be expected to deliver better tools for that task. Of course, if clients without embedded AxleBase instances will be allowed to query AxleBase servers, then all must use third-party encryption. AxleBase will not participate in third-party solutions. Also, clients must have AxleBase instances to use AxleBase encryption, decryption, authentication, and verification. AxleBase authentication is extremely verbose and will remain so. It can add several thousand bytes to a transmission. Also, AxleBase encryption is extremely verbose and will remain so. It adds greatly to the size of every transmission.
Tracking Logging can be turned on when needed by the DBA. There are independent logging toggles within each database and within each domain. That allows logging at multiple levels when needed. Logs capture data, structure, and management operations. Extremely low level tracking can be implemented by the DBA by enabling auditing. System auditing goes down to the row level and is persisted through every data revision of every row. ( See the Audit sub-section on this page. )
Distributed System Security Basic security automatically extends with system distribution into an axsys. Whether security is turned on before or after system distribution, the extended system is entirely subject to the DBA's security administration. If it is turned on after distribution, then the ReloadNode command can tell all nodes to reboot to reload node and system configurations. The administration of basic security remains the same for a distributed system. However, the distribution raises the internal complexity, and the DBA must understand how the distribution model effects each type of node. Each node is subject to control by parts of the security of various levels and that control varies by node type. (The documentation, of course, covers all of this.) At this point, AxleBase security may seem to become complex, but for those who need it, it may actually simplify security. For example, the following may eliminate the complex administration of Microsoft's active directories. Syslink is a communication protocol that was designed to provide controlled security at the application level. It was designed specifically for internal use by the distributed AxleBase, but was released publicly so that other systems could communicate with AxleBase. Syslink provides communication security at the application level setting on top of the network stack. It is designed to carry a heavy data load with extreme security requirements through unfamiliar and hostile environments. It requires that participants recognize no transmissions and no parts of transmissions outside the protocol. The syslink protocol mandates a formally structured envelope around the message. Various slots are provided in the envelope for specific optional components of the transmission. If the DBA turns on the system authentication toggle, then authentication must accompany every transmission. The syslink protocol provides an authentication slot within the envelope for that purpose. The syslink protocol provides various standard messages for communication at the host level. Recognition of those messages and responses are required. Those, also, must be within the envelope. System logic requires that the host be the controller, which permits the host to provide a more elegant syslink solution to handling communication traffic. However, the syslink protocol with all of its options and its confusing multiple binary payloads is a heavy-weight, so processing it can become complex. Therefore, AxleBase presents an optional interface that can handle syslink traffic in both directions. That interface is designed as a service to the user to simplify host construction. It allows the host to pass traffic directly to and from AxleBase without processing. AxleBase will assume the entirety of the security burden, transmission parsing and translation, and response transmission construction. (Since the use of the syslink interface indicates that the host needs help, the abstracted API's are used inside the syslink interface.) If the syslink interface is used, the DBA will continue to need a means of communicating with node hosts. Therefore, AxleBase recognizes the standard syslink commands. If, for example, the DBA tells all nodes to reboot their computers, the AxleBase instances will recognize the command after parsing and pass it to their hosts. The syslink protocol specifically allows multiple encryption layers and AxleBase can encrypt multiple layers. Separate system toggles allow the DBA to specify message encryption and/or syslink encryption. When both of those toggles are on, the message is encrypted, inserted into the envelope, and the entire envelope is then encrypted. Impacted encryption hides whether or not authentication is enclosed and hides plain-text information in the envelope such as the various identifications provided by the protocol AxleBase has a syslink attribute toggle for the DBA. If the host uses the abstracted syslink interface to AxleBase, the syslink protocol is on, and impacted encryption is on, then AxleBase will doubly encrypt and decrypt all traffic. Every inbound message will be decrypted without preliminary checking and any unrecognized transmissions that result will be discarded. All outbound traffic will be doubly encrypted and handed to the host for immediate transmission. Authentication can be required with double encryption. The protocol envelope carries various identifications in specified slots, and those can be validated by reciptients. ODBC ODBC is recognized as beneficial for world-wide data exchange needs. Therefore, AxleBase supports the entire ODBC standard for hosts that use an ODBC driver. However, the security benefits of the AxleBase-syslink combination should be considered before adopting ODBC. The AxleBase-syslink option might be used even within local networks of large organizations for the communication of highly sensitive data in this age of diminished personal integrity. Resource Discovery By intent, AxleBase provides no resource discovery. Also, although he can produce SOAP with the SOAP error protocol in response to SQL queries, he refuses SOAP inquiries. Also, he ignores information requests at the SysLink level. ( AxleBase contains no "back door" and no other intentional weakening of the security sub-system.)
_________________________ Due to his advanced technologies, concurrency is a more complex topic for AxleBase than it is for standard database managers. So please bear with this unusual delivery of the topic. Please note that the AxleBase objectives do not include heavy concurrency. (For heavy concurrent usage, please consider one of the many fine normal database managers on the market from MySql, Microsoft, Oracle, I.B.M., etc.) Database Server When embedded within a multi-client server, the concurrency problem is lessened tremendously to that of a standard database manager. A multi-client server must have a queuing mechanism to accept multiple client requests. Most of the concurrency issues then become handled by the server's client queuing mechanism so that the clients cannot interfere with each other. The server queues client requests as they come in and presents each sequentially to one or more AxleBase threads for servicing. Impact Of Multiple Independent Instances Unlike standard database managers, AxleBase and his databases are designed to allow multiple instances and multiple servers to operate against each database. That creates a far more complex situation than is that of a single database server. All units operate independently while updating, locking, unlocking, reading, etc. at high speeds. Concurrency problems are thereby increased for all of those AxleBase instances. (Even multiple administrators are not disallowed except by security.) This facet is addressed in the design of AxleBase and in the design of his databases. You will see below that tests have not yet (Hopefully, soon.) produced a failure. Distributed Database Impact A well designed distributed AxleBase database can withstand concurrency stress as well as can a standard database. In most instances, distribution of an AxleBase database actually makes it more robust. Distributed System Impact A distributed database manager increases concurrency stress because it uses multiple independent nodes hitting on a database simultaneously; i.e., the axsys generates its own concurrency. The instantiation of the axsys is done in such a way that it allows the DBA to design around much of this increased problem, but the problem remains and is addressed below. Stress Tests Concurrency stress testing of AxleBase disregards the normal database server situation because that is elmentary. His stress testing concentrates on the more complex simultaneous activity of multiple disconnected systems using a database because each of those systems independently handles all concurrency problems without inter-system communication. All that can be said at this time is that testing of multiple systems that are simultaneously using a database at high speed has not produced a failure. (Please see the Tests page.) But all that was thereby proven is simply that; testing has not produced a failure in the AxleBase lab. The inability to force failure is not considered a positive result. The lack of failure may be due to the internal safeguards, but it could simply be due to the limited funds for test equipment. A failure must be produced in the AxleBase lab before the concurrency limit can be known. Until a failure is produced, only an estimate can be made. Based only on subjective experience in the lab, it appears that an AxleBase database may support twenty or thirty concurrent users, and maybe as few as ten or twelve, or maybe far more. ( Service Load :
( Additional noteworthy system behavior during stress testing is noted in the documentation.) Artificially Induced Failure Tests Since a failure has not yet been produced, concurrency failures have been artificially forced under carefully controlled test-bed conditions to observe the results. In all cases, the system reacted graciously to failure, protecting the data, returning error messages to the user, and maintaining operational stability. Again, that was under rigidly controlled and stepped test-bed conditions to observe the results.
_________________________ ( No, this is not a joke. ) The many advanced features in AxleBase were not allowed to become excuses for sloppy programming and excessive interface complexity. The interface was kept as simple as possible. If AxleBase is embedded in a desktop system, then anybody who has used a desktop database manager can use AxleBase. Proof is in the AxHandle demonstrator that allows point and click use of databases. If AxleBase is embedded in a database server, then anybody who has used a standard database server can use AxleBase. Proof is in the AxHandle and AxServer demonstrators that allow point and click use of databases. Infrastructure AxleBase is designed to run on old and simple computers and networks. If the organization knows how to turn on cheap desktop computers and connect them in a low-end peer-to-peer network, then AxleBase will be happy running on it. The comical thing about it is that AxleBase will then deliver high speed performance. Of course, if the organization wants it, the DBA can run AxleBase on high-end servers with fancy disk configurations, special hardware using routed optical networks, and every other conceivable complexity. But AxleBase does NOT require it.
Distributed Databases Creating a distributed database is about as difficult as notepad. If the DBA wants to build a distributed database, he creates a text file listing source permissions for each table, and drops them into the database. That is all. AxleBase will handle everything else from then on. (Of course, AxleBase has a tool with which to do it, but most of us like the simplicity of notepad.) There is certainly complexity in the administration of distributed data objects, their computers, etc., and capable people are required by that fact, but AxleBase operation requires little. Host Software Since AxleBase was designed from the ground up to be embedded in whatever an organization may need, he must be embedded. The organization must have access to programming talent. Beginning programmers cannot do it. The biggest requirement is in computer communication. The programmer must understand socket programming or its equivalent, and that can become complex, not in its volume, but in compensating for the ineptitude of the socket builders. The AxleBase interface will become just a bunch of commands that the programmer will use. Little database knowledge is needed and can be had in consultation with the data professionals. Therefore, an advanced, or possibly intermediate, programmer with a knowledge of communications will be required for the host. However, with all that said, depending on the needs of the organization, the hosts will probably be small and simple.
Complexity There is an area of certain complexity. Designing, configuring, booting, and administering a distributed system will be complex. It will require people who are capable and knowledgeable. But it is kept as simple as possible. The operation of the axsys is encapsulated deep within AxleBase wherever possible.
_________________________ The world has many powerful software systems that are confined to their single in-house computer system. Many others can be installed on other computers, but are akin to Tinker Toys that require an installation staff of skilled technicians and programmers. A packaged software system is identifiable by its ability to be transmitted intact without disruption or degradation for installation on similar computers without special programming for immediate operation. That means, at this time in history, that the system can be delivered on disks or across a data connection. AxleBase is packaged. Not only is he packaged, but he fits on a small part of a single CD. He has a small installation program, and after it is run, which takes a few seconds, AxleBase is immediately ready for operation on the new computer.
__________________________________________________ None :
This declaration is of service to those who would seriously consider AxleBase because he was almost created in isolation. The basic structure and mechanisms is an area that may be especially sensitive to isolation. That area includes critical basic components and sub-systems such as data storage, cryptography, indexing, etc. It appears to be adequate, but the fact that it may differ from the big names in the market by a very great margin should not be ignored. For example, the date arithmetic, which has been in service for years, was recently found to have a subtle bug that effected the entire system. All advanced theory, algorithms, techniques, system design, and coding in AxleBase are original work. Obviously, some of it is now pervasive and whether it was developed first in the AxleBase shop is an argument worthy only of lawyers, but it was certainly independently developed there, and seems to have been first noted on the AxleBase web site over the past decade. ( * Exceptions :
( Recognition :
__________________________________________________ AxleBase began as a personal research project with a thesis of impossibility. Because it was an exploration, impossible feats were attempted, so the existence of AxleBase is due to the fact that it was undertaken as research. At every stage, that stage was believed impossible and it was attempted "because it was there", as the mountain climber said. Do not ever expect AxleBase to toast bread and take out the trash. His purpose is database management. Bells and whistles are left to others. ( HTML, XML, SOAP, etc. were done early in his development because the big names were doing them, but are now a bit of embarrassment and are subject to removal.) Exciting changes are ahead. Major upgrades are envisioned for existing sub-systems and mechanisms. Additionally, the intense and prolonged research into the limits of computer systems that has given rise to AxleBase can be expected to continue. It has been hard, thus far, to do pure research that has not resulted in practical and valuable development in AxleBase. Already, a new research idea points toward an exciting technology that might eclipse all other AxleBase technologies. Relativistic Effects :
Internal Communication :
System Port :
__________________________________________________ This description page covers features in broad strokes with omission of many interesting details. Even some features are omitted. The documentation presents a hundred thousand words of detailed feature descriptions with practical instructions and discussion of advanced theory where appropriate. It covers each of the many commands in detail with numerous examples. Also, some things are so new and different that they just may not "make sense" without hands-on experience. For that, the free demonstrators use all of the features that have been described and much more with point-and-click ease. Brief questions may also be sent to the developer on the inquiries page, or through regular email to this domain.
__________________________________________________ All of the described technologies and far more can be used by the free demonstrators. See the demonstrator page.
__________________________________________________ |
|
Copyright 2003 - 2012 John Ragan |
|
|
Web site maintained with Notepad and command line FTP. |
|