1 Background - mountain.PROJECTS

PETRI PELLIKKA AND KARI KAJUUTTI (ED)a long-term storage for glacier related information products, the methods to insert them intothe storage, as well as the methods required for browsing and searching for information keptin the storage.The glacier information to process, communicate and store in the OMEGA project is ofvarying nature. Some information comes from rather basic measurements, some from verysophisticated (experimental) processing algorithms, some are collected in-situ, and some areremotely sensed to a varying degree (ground, airborne, spaceborne). The OMEGA System isdesigned with flexibility with respect to information content as an important objective. Wewanted it to be flexible with respect to the information it can handle, with respect to thelocation of the storage and processing components, and with respect to key softwarecomponents (like databases or communication middleware).During the project period, the different components have been designed, implemented anddeployed in an iterative process until the operational prototype we have at the end of theproject. The project partners have patiently inserted data into the monitoring system as newversions emerged.At the end of the project, we would describe the status of the OMEGA System as anoperational prototype. During the project the system has proved its capability to storedifferent types of glaciological data products, at different locations, with different types ofmetadata attached, and to present this as a coherent collection for the users.Overall system architectureThe overall system architecture developed for the OMEGA System is distributed in nature.One basic idea have been that the participating partners, as well as other organisations, couldkeep their information in their local store, but still contributing to the community at large bybeing a part of the OMEGA System.All major software components in OMEGA are networked components. They offer and/orutilize their services through network based on Application Programming Interfaces (API’s).Each of the major components might reside (be deployed) on different computers as long asthey can communicate with each other through the Internet. The following Figure 37 is anillustration of the overall system architecture chosen for OMEGA. The boxes represent allmajor network components, and also illustrate a possible deployment schema, by drawingdotted lines on possible machine boundaries. The light grey components are standardcomponents representing such as the MS Access Database, The MS Internet Explorer,different WMS products available on the net or simply the hard disk on a computer. The darkgrey components are developed in the project or the project has contributed to theirdevelopment. The network components communicate with each other through the Internet.Components on the lower dark grey cloud in general communicate through the CORBA IIOPprotocol, while component on the upper light grey cloud communicate through the httpprotocol. The Data Server component provide an interface (CORBA API) for its client to list,read and write OMEGA Products to and from. In Figure 37 the broad arrows illustratespossible read and write operations through the network. For storing the Products, the DataServer rely on a Microsoft Access database plus an external file store for permanent storage.Currently, the project has Data Servers in operation at NORUT IT and University of Helsinki.53