The Alexandria testbed will be a unique assemblage of custom and commercial "off-the-shelf" components, and one that must evolve considerably over the life of the project. Two principles will guide the integration and evolution of this system. First, the Alexandria system architecture will be specified primarily in terms of its interfaces. These interfaces will be defined and specified as a result of our experience on the prototype. In addition to these external interfaces, internal interfaces such as mass storage and DBMS must be precisely specified. The goal is to make these as vendor-neutral as possible, so that the architecture may take maximum advantage of progress in the marketplace. For example, the Alexandria catalogues will use off-the-shelf extensible object-oriented database such as O2 or ObjectStore. Extensibility will permit integration of new access methods as well as index structures in the DBMS. Second, the Alexandria testbed will include extensive facilities for binding or "gluing" components to the standard interfaces. These facilities will include scripting tools, on-the-fly data format translators, and graphical programming tools and interface builders.
Populating the Alexandria database will be a substantial effort as much of the data to be loaded into Alexandria is not currently in digital form. Maps, aerial photographs, and printed text will have to be mechanically scanned in addition to having their metadata entered. Even most of the data which are already digitized (tapes, CD ROMS, etc.) must be physically loaded into the system. This loading phase must be carefully structured and streamlined to avoid potential bottlenecks. Once again, our experience with the prototype will be extremely beneficial in identifying correct technologies for the Alexandria ingest and storage components, such as parallelization.
Due to the large size and extensible nature of the testbed a discipline for controlling changes to the system is necessary in order to avoid confusion, misinterpretation and interference. Therefore, it is important to have a rigorous configuration management approach both at the component and at the system level. During the initial prototyping phase the objects that need to be placed under configuration management need to be identified, and the relationships between these objects, such as "uses" relations, need to be defined.