Gamelon® And The Internet
Suggestions for Internet-Related Uses
Gamelon provides the facilities necessary for creation and maintenance of fully self-descriptive structured objects that are type-safe and platform-independent. The Trader and Server libraries provide essential capabilities for distributed object computing, including object identification, logical navigation, transaction management, indexing, object nesting and object hyperlinking. Here are some suggestions about how Gamelon can be used in the Internet environment.
1. Data package for Internet-based distributed computing.
The success of the Internet, and especially of the World Wide Web, for program communications can only be expected to expand into distributed computing that requires much more intimate and efficient integration of networked peer programs. The existing Internet tools, such as WAIS, Gopher, Veronica, Archie, telnet, FTP, email, USENET and the Web, are designed to support interactive session management, not automated program-to- program cooperation. Such cooperation can be obtained by augmenting these tools with shell scripts and the like, but the augmentation is a process that itself requires laborious design, implementation, testing, maintenance and version management, and the people who do such work are expensive and hard-to-find UNIX gurus.
The Object Request Broker (ORB) technology, specified in Object Management Group's Common Object Request Broker Architecture (CORBA), promises significant aid to the automation objective, but CORBA is still in development. Its present version principally supports traditional client-server computing in which object instances (and computing load) remains at the server. We believe that CORBA will be an important networking facility when implementations proliferate, and we have prepared for this by designing Gamelon files to carry all CORBA defined data types. On the other hand, CORBA was not designed to aid the interoperation of distributed programs while not live on a network.
The reason that Gamelon objects can fit into offline distributed computing is that they are internally self-descriptive as to layout and type, and they are supported by a well-defined API that makes it easy for program designers to devise private communication protocols, above the OSI Reference Model transport layer (promulgated by the International Organization for Standardization), that convey semantic content from one program to another. These persistent objects can even be used in asynchronous loosely-coupled communications, such as those mediated by email, because they are so fully self-descriptive and platform independent. The fact that Gamelon is available on seven computer platforms with multiple computer language interfaces makes this prospect even more of a reality.
2. Supplement to a Web browser.
The popularity of Web browsers as interactive research and communication tools is hampered by the fact that the design of the Web does not accommodate easily the recording of user intentions and observations about gathered information; nor does it accommodate easily the preservation of that information in databases. The problem is that the hyperlinks that do exist among data are hard-coded, and the HTML notation which creates those hyperlinks is awkward and unsatisfactory as a facility to create new links among collected items and user annotations. Gamelon can provide an elegant solution to this problem in a way that facilitates eventual mapping of the data (or some of it) into databases.
Gamelon files require no schema or class definition in advance of their receipt and storage of data -- it can be handled when, as and however it arrives. This allows a Web browser to deposit into Gamelon files literally anything it encounters, including other Gamelon files, ASCII text files, GIF, JPEG, MPEG, TIFF, WAV, DICOM, executables and other BLOB files, in plain, compressed or encrypted form. That same browser could parse existing HTML links among some of the received files and recreate them as dynamic Gamelon hyperlinks, it could place internal program structures into the same Gamelon files, and it could provide to the user a means of adding newly-created comments and hyperlinks to the gathered results.
The flexibility of Gamelon files goes yet further. Suppose that one item of gathered information is a Web search result text page that contain columns of figures: after the user finishes adding hyperlinks that give context to browser session results, he or she could decide to preserve only the numerical information of that particular object and to preserve it as a table of binary rather than text numbers -- a program that uses Gamelon can accommodate this deliberate change of data format and type without losing the logical placement, comments and hyperlinks previously associated with the Web result page.
3. Linkage facility to connect disparate data stores.
One of the data management problems often encountered within an enterprise is that important data stores are maintained by differing databases and programs. There are network files, heirarchical files, relational database files, object database files, flat files, and whatever. Furthermore, the programs that govern access to the data often are operated at physically separate locations. It is difficult to keep track of the ways in which data can be extracted from these resources, and it is difficult to supplement them with links that reveal the logical connections of data type and items with one another across resources. Gamelon files provide a means of supporting centralized data access and maintaining logical connections.
The free-form nature of Gamelon files is at the core of this capability. Within Gamelon files areas can be defined to hold the data extraction methods (such as SQL queries, program invocation arguments, etc.) necessary to get at data from disparate resources that can be associated with particular key values, and those Gamelon-stored key values can be hyperlinked to one another. This allows the construction of a data extraction engine that generalizes access to the available resources.
4. Generic storage for extracted archives.
The extraction of data from various stores, mentioned in Section 3, leads to a related problem -- the need for query and reporting engines that can make use of the data. Gamelon files can assist here as well because Gamelon files can emulate various data structures while retaining data type information: this allows the receipt of extracted data into generic files that can be used by a generic query and reporting engine. While it is true that this can be done by mapping data into an object database, the Gamelon approach avoids the necessity of defining classes in advance of data extraction, which allows, in turn, a more interactive style of data store exploration.
5. OO Supplement to a relational database.
It is often said that there is an "impedance mismatch" between object-oriented programming and relational databases. One of the approaches to solving this problem is the creation of object-oriented front-ends to conventional relational databases. This approach can be powerful, but there is a lot of complexity and computational overhead involved in translating from one programming paradigm to another. The use of Gamelon files opens the door to another approach.
Relational databases store data in tables, which are associated with one another by relations, views and supporting indexes. Whenever a new type of data must be stored, a schema must be defined for it which describes the data structure, relations, views and indexes. In contrast, Gamelon files can store elementary data and structures in any organization -- even a dynamic organization -- while retaining accessibility through indexed searches based on object identifiers. This opens the possibility of storing object identifiers and keys in relational tables, so that objects found anywhere in a Gamelon file can be accessed as if they were present in the relational tables.
Such a pairing of Gamelon with a relational database could add sophisticated query and reporting capabilities that Gamelon lacks, while preserving independent object-oriented program access to objects stored in the Gamelon files. For example, if an object-oriented program is designed to bootstrap-load objects from alternate streaming persistent store files, the facilities of the relational database could be used to identify the appropriate stream based on key values located within the stream (perhaps in nested objects), and the facilities of Gamelon could be used to present the stream to the program.
6. Persistent store for program internals.
Many programs are designed to load configuration information and internal working structures from files. Often this information is used only for initialization, but sometimes it preserves session-related state information necessary to allow users to engage in parallel activities and to interrupt the work for periods of time.
Gamelon files can be maintained in rigid layouts, runtime- variable layouts, or any combination of these alternatives. This characteristic arises from the library's use of logical rather than physical organization of files. This would allow, for example, the definition of a session file that contains logically-organized areas for matters as configuration, user preferences, a saved state of internal program structures and a saved collection of partially-processed user data. In such a file, it is likely that the program designer would define a fixed layout for the configuration and user preference areas, a streaming persistent store of variable length for the program internals area, and a collection of various structures and variable sizes for the user data -- all of these can be accommodated easily in a Gamelon file.
In the context of the Internet, one may easily imagine a session object being forwarded from one computer to another to allow different workers to advance a program session through different work stations. This may be accomplished easily with Gamelon files, because they are internally self-descriptive and platform independent. The availability of the library with multiple computer language interfaces, such as C++ and Visual Basic and Java, also simplifies the use of the session object in programs developed by different programming teams on different platforms and with different language environments.
7. Foundation for an embedded Object Database.
A full-service object database can be a powerful foundation for programs that perform distributed computing. Like any generalized facility, however, its use implies considerable cost, complexity and computational overhead. These characteristics, along with the inflexibility associated with the need for class definitions, can present real obstacles to some programming objectives. For example, it would be hard to fit such a facility into a PDA or lightweight software agent. The efficiency and small size of Gamelon files can provide an easy and elegant means of providing specific facilities of an object database within narrow cost, computation and memory limits.
For example, the Gamelon library is only 173K in size on the OS/2 platform, and it has a similar size on other platforms. For embedded applications in which some of the many Gamelon facilities are not required, the library can be pared down to much smaller sizes. The overhead required in a Gamelon file to store completely self-descriptive internal structure and data types is minimal -- the smallest Gamelon file is only 4 bytes long, and the overhead per object can be as little as 1 byte. Memory management within the library is automatic, and very little memory is consumed: a cursor which gives full-function access to Gamelon files requires less than 200 bytes of memory for its existence.
Certain object database facilities were deliberately excluded from the Gamelon library, but the API provides essential support for programmers who wish to create them. These missing facilities principally are queries, result sets and reporting. The programmer who uses Gamelon need only develop the specific higher-level functions that are needed for the purpose at hand, so the absence of generalized database functionality may actually yield benefits in simplicity, less computational overhead, lower memory usage and easier maintainability -- all of which translates into big cost and time savings.
We would be happy to discuss your needs and to offer our Consulting and Programming services. Feel free to contact Jonathan Wilcox to discuss your unique situation.
Copyright (c) 1993-1996 Menai Corporation
Home | Product | Consulting | Programming | Reviews | Company | Site Map | Guest Book
Menai Corporation, 1010 El Camino Real, Suite 300, Menlo Park, California 94025-4335
800-GAMELON (800-426-3566) (US only), 650-853-6450 (voice), 650-853-6453 (fax)
Questions about our products and services: info@menai.com.
Comments about this web site: webmaster@menai.com.
Copyright © 1996-98 Menai Corporation. All Rights Reserved. Menai, Gamelon and gamelon(stylized) are worldwide trademarks of Menai Corporation, registered in the United States of America, and the .[g] logo is a worldwide trademark of Menai Corporation. All other trademarks are owned by their respective owners.