Implementation of a Geospatial Imagery Digital Library ... - CiteSeerX

DHPC-047 DSTO-TR-0672

Implementation of a Geospatial Imagery Digital Library using Java and CORBA P.D. Coddington, K.A. Hawick, K.E. Kerry, J.A. Mathew, A.J. Silis, D.L. Webb Distributed High-Performance Computing Group Advanced Computational Systems Cooperative Research Centre Department of Computer Science, University of Adelaide Adelaide, SA 5005, Australia [email protected]

P.J. Whitbread, C.G. Irving, M.W. Grigg, R. Jana, K. Tang Defence Science and Technology Organisation DSTO C3 Research Centre, Fernhill Park, ACT 2600, Australia [email protected]

31 July 1998 Abstract

We have implemented a prototype distributed system for managing and accessing a digital library of geospatial imagery over a wide-area network. The system conforms to a subset of the Geospatial and Imagery Access Services (GIAS) speci cation from the U.S. National Imagery and Mapping Agency (NIMA), which de nes an object-oriented application programming interface (API) using the Common Object Request Broker Architecture (CORBA) for remote access to the image server. The GIAS speci cation is being explored by the military in both the U.S. and Australia as a means for creating widely accessible imagery repositories, and also provides a convenient API for interfacing to repositories of geospatial images, such as satellite data archives, for a variety of commercial and research applications. Our prototype GIAS implementation was developed using StudioCentral from Silicon Graphics Inc., which provides a set of C++ class libraries for building digital multimedia repositories. We discuss the issues and problems involved in developing this system using CORBA, Java and C++ native methods, within the constraints of the GIAS speci cation.

1

1 Introduction Handling large archives of digital image data is a challenging problem. Ecient storage, management and dissemination of images requires careful design of both the architecture and the software. The aim of this work is to develop software for managing an online repository of digital geospatial images, produced from aerial photography or earth observation satellites, that can be accessed using the Internet (or an intranet) from clients running on a variety of computers. The repository must also handle the metadata associated with the images, which should be queryable by the client. Such a system enables remote on-demand access to geospatial imagery from potentially very large (Gigabyte or Terabyte) data sets that may not be available to the client via a local area network. This is extremely valuable for geographic information systems (GIS) which make use of remotely sensed geospatial data, including applications such as weather forecasting, climate studies, land management, crop prediction, mineral exploration and environmental studies. The system also has obvious defence applications in the area of photoreconnaisance, and much of the eort in the development and standardization of systems for geospatial imagery access has been driven by the defence sector, particularly in the United States. The U.S. National Imagery and Mapping Agency (NIMA) [1] is developing and publicising standards and speci cations for the U.S. Imagery and Geospatial Information System (USIGS) [2, 3], targeted at use by the U.S. military. This system is also being examined by the Australian defence forces for their imagery archives. Some of the USIGS standards may be adopted (in a revised form) by non-defence organizations such as the Open GIS Consortium [4] and the International Standards Organization. Developing image repository software using the USIGS speci cation provides the advantages of a well-de ned standardised interface, which allows interoperability with other systems and applications. The information explosion has led to a practical need for distributed software systems to manage large multimedia data archives. There are several projects aiming to provide access to digital libraries of geospatial images. These include the Synthetic Aperture Radar Atlas (SARA) at Caltech [5, 6]; NASA's Earth Observing System Data and Information System (EOSDIS) [7]; the Australian Centre for Remote Sensing (ACRES) Digital Catalogue [8]; and our own work on the development of a Webbased interface to an online satellite image archive [9, 10]. New technologies such as the World Wide Web, Java [11] and the Common Object Request Broker Architecture (CORBA) [12] are making it easier to develop distributed client/server systems of this kind. What is currently lacking in these projects is a standardised interface to the various digital image libraries, which would enable clients such as application programs or image catalog browsers to provide on-demand querying and accessing of geospatial imagery from a number of dierent image repositories, which may have a variety of image data from dierent satellites or other earth observing platforms. The GIAS is the rst broad, general, well-de ned standard for storing, querying and accessing geospatial imagery, to be used by a large developer and user community. This is the main reason we have decided to implement our system based on this speci cation. We have developed a prototype system which implements a subset of the GIAS. The prototype repository provides access to an archive of data from the GMS-5 meteorological satellite. This work was a collaboration between the On-Line Data Archives (OLDA) Program of the Advanced Computational Systems Cooperative Research Centre, and the Imagery Management and Dissemination (IMAD) Project group of the Defence Science and Technology Organisation (DSTO).

2 Speci cation of the Image Library The USIGS speci cation is made up of a number of parts, including:

2

    

the speci cation for implementing an image library, and an API for providing access to it, given by the Geospatial and Imagery Access Speci cation (GIAS) [13]; the USIGS Common Object Speci cation (UCOS) [14], which speci es in more detail how objects and methods that are common among dierent parts of USIGS are to be implemented; the USIGS Interoperability Pro le (UIP) [15], which speci es common interfaces and data models for interoperability between dierent parts of USIGS; a metadata model for defence-related geospatial imagery, the Standards Pro le for Imagery Access (SPIA) [16]; the speci cation of a standard image le format for transfer of images and associated metadata, given by the National Imagery Transfer Format (NITF) standard le format [17].

Our initial implementation of the imagery access system concentrates on the GIAS, which is the fundamental component of a library or repository that allows storing, searching and accessing of geospatial imagery. USIGS and the GIAS are speci ed in object-oriented terms, with CORBA being required for client/server interactions. Interfaces, data types and error conditions are de ned for the GIAS [13] and the UCOS [14] using Interface Description Language (IDL) [18], an implementation language independent notation for specifying software interfaces. Hence, for this application, we were required to use an object-oriented programming style using CORBA. However, this approach has obvious advantages for implementing a large, complex, distributed system such as this. The GIAS speci cation is structured so that the main functions of the library, such as adding data, querying the data, and accessing the data, are controlled by dierent managers, each of which is speci ed by a class with well-de ned objects, methods, and exceptions. They may also require one or more abstract classes, which provide objects and methods that are common to several classes. They are more loosely de ned, with the implementation details left up to the developer. For our initial prototype implementation, we focussed on a subset of the GIAS which would provide the basic functionality of an image library. A brief description of the classes implemented is given below. For more detail, see the GIAS speci cation [13]. The Library class is the central point of access to all manager services oered by GIAS for the image library or repository. Its methods are: get manager types returns a list of strings containing the names of all the manager types supported by the library; access criteria speci es which of the access criteria (UserID, Password, and LicenseID) are required for a speci ed manager; get manager authenticates the user with the repository and returns a reference to the requested manager; about returns a name and description for the repository. The Catalog Access Manager (CatalogAccessMgr) class handles queries to the repository and returns the results. Its methods are: submit query allows the user to search for imagery data by querying on the metadata; hit count just returns the number of query matches. Currently there is no agreed standard for querying object relational database management systems (ORDBMS), so dierent vendors and applications use dierent formats. GIAS requires queries to be presented in Boolean Query Syntax (BQS) [13]. The Creation Manager (CreationMgr) class enables data to be added to the image repository. Its methods are: create adds geospatial image data and associated metadata to the image repository; metadata create is the same as create, except that there is no need to specify the image data le. It provides support for data that may not exist in digital form. The GeoDataSet Manager (GeoDataSetMgr) class allows the user to download the image data (and associated metadata) as a le. The methods for this class are: disseminate allows the user to 3

specify a particular product to be downloaded as a le; get subgeo allows the user to specify that they want only data for a particular geospatial region. The Array Access Manager (ArrayAccessMgr) class allows the user to transfer image pixel data (without metadata) directly to the client through CORBA. It has only one method: get region allows the user to specify image pixel data for a particular geospatial region. The Manager Interface and Product Interface are abstract interfaces that are used by all managers. The Manager class includes the get properties method, which allows the client to obtain values of various properties that are speci ed in the GIAS for the dierent managers. The Product class includes Product and GeoProduct objects, which refer to the data products (images plus associated metadata) stored in the repository. Results of any requests are returned as Request objects, for example a DisseminateRequest object is returned by GeoDataSetMgr.disseminate() and a HitCountRequest object is returned by CatalogAccessMgr.hit count(). A scenario for using such a system might be as follows. The client application rst connects to the image library, through the Library interface, and identi es the available managers. The CatalogAccessMgr is used to query the metadata in the library, and returns matching results. The user selects one of the imagery products from the list of results, and downloads the image data using either GeoDataSetMgr to obtain the data as a le or ArrayAccessMgr to obtain the image data as a stream of bytes to be processed or displayed. The GIAS, and even the USIGS, do not specify a complete architecture for developing an imagery management and dissemination system, although they provide the basis for such a system. For example, the GIAS provides a speci cation for remotely interfacing to a single image library, however in a real system, there may be many distributed libraries. The client has to know how to nd a particular library and to search over multiple libraries. This is the function of a trader, and is not speci ed by the GIAS or USIGS. Accessing images may also require the use of tiling and specialised compression techniques. Such issues are handled by the Imagery Management and Dissemination (IMAD) system being developed by DSTO, which includes the GIAS library. IMAD will provide additional functionality such as an Image Query Manager, which is responsible for handling queries over multiple distributed image libraries, and a Context Manager for determining the best method for transferring the image from a particular imagery library to the client, based on the client's capabilities and its network connectivity. There are many other issues involved in creating a distributed digital imagery archive, particularly related to security and performance, that are also outside the scope of the USIGS speci cation. Some of these problems can be dealt with by a middleware system, whose job it is to provide the \plumbing" for complex, distributed applications. The OLDA Program is developing a middleware system known as the Distributed Information Systems Control World (DISCWorld) [20], for building distributed applications involving access to large online data archives. DSTO is building a similar system, known as EXC3ITE, as a Concept Technology Demonstrator for the Australian defence forces command, control, communication and intelligence network. These middleware systems provide services such as a global naming service, security services, and network resource monitoring.

3 Implementation We have implemented an image library server based on the GIAS speci cation, and a simple client to test the functionality of the server using the GIAS interfaces. In this section we discuss some of the salient features of our implementation of the GIAS system. USIGS and GIAS are speci cations for object-oriented systems. It was decided to use Java [11] (rather than C++) for both the GIAS clients and servers, for reasons of portability, ease of program 4

development and maintenance, and for easier integration of the clients with Web browsers. We used the Java Development Kit (JDK) version 1.1.5. Although it would be possible to provide remote access to an image repository in a variety of ways, including Java Remote Method Invocation (RMI) [19], USIGS and GIAS require the use of CORBA. We started developing the prototype using OrbixWeb [21] version 3.0 as the Object Request Broker (ORB), but then switched to the Java version of VisiBroker [22] version 3.1. This was mainly because the evaluation copy of VisiBroker was more advanced, and had more of the CORBA services we required, than the evaluation version of OrbixWeb. In addition, an implementation of VisiBroker was available on the Silicon Graphics (SGI) machine that was used for the server, and proved to be easier to use on the SGI in comparison with OrbixWeb. The GIAS IDL was compiled to Java using VisiBroker's idl2java compiler. The central component of the system is the image repository. In order to save some development eort, and to quickly achieve robustness and reliability, we decided to use a commercial product for this part of the system. The product could not just be a turnkey package, since we needed to develop an interface to it that conformed to the GIAS speci cation. We chose StudioCentral [24] from Silicon Graphics, which is an Asset Management System designed to aid in the development of multimedia-based applications, particularly for the lm-making industry. The StudioCentral API and associated C++ class libraries include support for user authentication and control, repository access, querying, hierarchical data modelling, and asset versioning. Asset metadata is stored in a persistent data store, usually an Informix or Oracle database management system (DBMS), and asset content (the image or multimedia le) is stored on a le server, rather than in the database, for scalability and faster access and dissemination. The DBMS schema is exible enough to handle multiple repositories, content stores, and versions of asset. The programmer writes applications that interact with the persistent store through the StudioCentral API. A StudioCentral application typically involves creating an environment, authenticating with that environment, and attempting to gain a reference to a repository from StudioCentral's repository broker. The application can then check assets in or out, and query data in the persistent store. Each asset is represented as an object conforming to some data model. Data models describe the type of data and consist of user-de ned attributes (such as name, creation time, source) as well as system attributes (repository, content store, version). Data models are extensible so that when a new type of asset is added to the system, a new model can be designed to accommodate it. All of the above make StudioCentral a good candidate for this application. It is a ready-made system for persistent storage of multimedia objects, and provides most of the functionality required for GIAS (plus many additional capabilities that were not needed). However, GIAS requires that the objects be accessible from remote machines, and this is where StudioCentral falls short, since it has no direct support for remote transfer of assets. Our implementation of the GIAS speci cation is built upon version 1.0 of StudioCentral. We used Java for both client and server operations in our implementation. For the server, we need some interface or \wrapper" to match the GIAS interface with the StudioCentral API. The mechanism we used to do this is the Java Native Interface (JNI), which permits Java programs to interoperate with non-Java programs (native methods) such as the StudioCentral C++ libraries. A schematic of the implementation architecture is given in Figure 1. We needed to resolve a major design issue prior to implementation, namely how much of the server functionality should be implemented in Java and how much in C++. Manipulating Java data structures in native methods can be tedious and frustrating. For this reason we wanted to leave as much of this manipulation as possible within Java, and to keep the native code reasonably atomic, such that a Java native method refers to an elementary StudioCentral operation. This aids readability and maintenance of our code. However, we also need access to native data types. Our main problem here is JNI will garbage collect all objects we do not mark as globally referenced, 5

Library Managers Java / CORBA CORBA BQS

StudioCentral query Native Methods SQL

Client

StudioCentral

Java

C++

JDBC Alternative

SQL C++ Database

Figure 1: The architecture of the image repository. including native objects that cannot be marked. In our situation this means that our references to environment structures and repositories will be lost as soon as a native call is complete. We developed a solution whereby we do as much as possible in Java until native operations are required. The design and functionality of StudioCentral have a lot in common with the GIAS, but there are some dierences that make the implementation more dicult. For example, to use StudioCentral, we must pass the environment data values, including username and password, that are required by most of the StudioCentral methods. We must therefore create an environment instance, authenticate and connect to a repository on each native call. The GIAS speci cation expects the user to authenticate with the Library only at the initial request for a manager. We must somehow nd a way of keeping hold of the user's credentials (i.e. saving state) without breaking the GIAS speci cation. This can most easily be done by storing these environment variables on the client, and using a CORBA lter to package them up with each GIAS call on the client, and extract them using the ORB on the server, so they can be passed with the StudioCentral calls.

3.1 GIAS Classes The client rst speci es a host name and tries to bind to a GIAS server on that host through the Library interface. If this is successful, it can then call methods on the Library to nd out information and to obtain references to managers. The get manager method rst authenticates the user with the repository. It then instantiates a manager of the requested type and returns a reference to it after registering it with the Basic Object Adapter (BOA) [23], which is responsible for object activation and acts as a generic interface or speci cation between an ORB and a CORBA object. The manager returned is of class Manager and hence has to be cast or narrowed to the appropriate 6

class to be used as the correct manager type. This method tries to do a bind to a manager type that it does not recognise, in case it is a new manager type. It is not speci ed in the GIAS, UIP, UCOS, or related IDLs, exactly how Product or GeoProduct objects of the abstract Product class are to be implemented. In our system, we have chosen to realise these abstractions as strings, using StringProduct and StringGeoProduct objects. This requires augmenting the GIAS IDL. The CatalogAccessMgr gathers the metadata matching a submit query call and produces a QueryRequest object for return to the client. The manager currently blocks while submit query is executing, but we intend to make this a thread in a later version. The speci cation of CreationMgr states that the create method should be able to extract metadata from the product le, if it is available. Our implementation supports this for GMS5 images, using a perl program invoked using a system call from Java to extract the metadata from the speci ed data le, add any additional metadata that may be required, and construct a StudioCentral metadata le. The metadata and the image product le are then loaded into the repository. An object ID (OID) is returned to the caller in a CreationRequest object. StudioCentral does not support moving les from remote le systems to a repository, so the server program rst has to import the le to the server, which is done using FTP. The calls to StudioCentral should be threaded in the future, particularly since the time taken for the FTP is variable depending on network trac. The GeoDataSetMgr implements the disseminate method by using the OID reference given in the Product object to nd the requested product to be transferred to a speci ed le location using FTP. A new DisseminateRequest object is created and returned to the caller. The get subgeo method allows the user to specify a sub-region of the image (using either pixels geospatial coordinates), which is cropped out of the image. For the get region method of the ArrayAccessMgr, a section of the image is returned to the client using a byte array object rather than as a le.

3.2 BQS Parser SQL is intended to be a general purpose database management language for programmers, and it is necessary to have knowledge of the data schema, which may be complex, in order to construct a query. In order to make SQL more suitable for end-user queries, it is advantageous to de ne a simpler language which allows the user to specify only the data items of interest, and the system is responsible for locating the data within the framework of the data model. Abstracting the physical implementation of the database in this way means that the underlying database application, query language or database schema can be altered without having to notify all clients. Both GIAS and StudioCentral provide query languages of this kind. We have written a parser to convert between the Boolean Query Syntax (BQS) [13] used in GIAS and the query language used in StudioCentral [24]. The basic forms of both languages are quite similar to each other and also to the where clause in an SQL statement, excluding table join constructs. The main dierence between StudioCentral queries and BQS queries is that they were designed for related but similar domains { digital asset management in the case of StudioCentral, and geospatial image libraries in the case of GIAS. BQS has been designed with geospatial applications in mind, and supports domain speci c constructs, such as operations on regions. StudioCentral's query language does not include these domain-speci c operations. These high-level operations can be translated into more complicated SQL constructs, but it is better to have this functionality included into the server rather than expecting end-users to have to generate relatively complex SQL queries. Both the GIAS and StudioCentral are intended to support object management rather than simple data management, however only limited object management is provided by these interfaces and their querying languages. ANSI are currently developing the SQL3 standard [25] for support 7

of object relational databases, and this is currently a draft standard. Various vendors including Oracle (Version 8) and Informix (Universal Server) have developed object relational databases that are loosely based on the draft SQL3 standard, but do not completely conform.

Figure 2: A screen dump of some manager windows from the test client.

3.3 Test Client The test client is a Java application which provides a separate window for every manager, as shown in Figure 2. In this case, a query has been made using the CatalogAccessMgr, one of the products matching the query has been selected and downloaded using the ArrayAccessMgr, and the image displayed in a separate window. A particular application, such as a satellite catalog browser or a environmental application, would have its own specialised user interface, which might be a Java applet that communicates using an ORB built-in to the Web browser, which is available in recent versions of Netscape Communicator.

8

4 Software Engineering and Design Experiences Most of the development team had previous experience using Java, although some had no Java experience and only a minimal exposure to object-oriented languages. Some of the team had CORBA experience or database experience, while others had little or none. One of the problems in this project was that no one person had a very strong knowledge of more than one or two of the component technologies used { Java, CORBA, databases, C++ and StudioCentral { so interfacing between these technologies was a challenge. This is not uncommon for a complex integration of several dierent software products. The system was fairly complex, with a Java client interfacing via CORBA to a Java server which interfaces to C++ class libraries using native methods which in turn interface with the Informix database. If something went wrong, it was often dicult to track it through the dierent interfaces. Integrating all the parts (Java, CORBA, C++ native methods, and StudioCentral), while still conforming to the GIAS speci cation and IDL, was the hardest part of the project. The C++ integration was probably the most taxing part. It can be dicult to program in the same object model as Java using C++, which caused many integration problems. JNI is a major improvement on the native interface provided with JDK 1.0, but still needs improvement to help ease integration with enterprise libraries and legacy systems. An interface for directly accessing C++ objects and methods from a library within our Java code would have been more intuitive and sensible in this application than the interface JNI provides. Improvements in JDK 1.2 should help address this problem. Having a C++ ORB talk to a Java ORB and hence having the managers (written in Java) use CORBA to communicate with the StudioCentral C++ libraries appears to be a possible solution, but we did not have the time to investigate this. CORBA worked quite well as a communications mechanism. It provides a good method for contacting a service and obtaining references to remote objects. Integration of the various parts of the system with CORBA was straightforward, but required a substantial amount of eort in order to package up all the data parameters correctly, check for null values, and handle any special StudioCentral and CORBA exceptions. Once we got around the integration problems, which mostly concerned transferring of data types, it was very stable. We have used fairly simple CORBA features in the prototype. More of the services will be utilised in future versions of the code. CORBA and IDL present problems when integrating with Java. The major problem we had in integrating CORBA with Java code was the use of null strings in Java. This usage resulted in BAD PARAM errors from the CORBA implementation, since null strings are not allowed in the current version of the CORBA speci cation. This also causes a problem when integrating with existing applications, such as StudioCentral in our case, which may require or return null values. A lot of eort was required to track down and deal with all the potential null values. The use of the CORBA type any, which is capable of holding a generic, potentially user-de ned variable, causes extra coding and manipulation as the variables have to packaged up correctly, taking into consideration null values. A potential solution to this would be to use the Java Object class, which can be cast to the appropriate type. The use of stub classes within CORBA does not map easily to the idea of casting in Java and requires narrowing of objects to the appropriate type. For these reasons, the use of the any type is a burden to the Java programmer. Another example of problems with the mapping between Java and IDL is the use of Holder classes in the implementation to pass objects as parameters and return values. These are implemented using the CORBA version of Java's serializable mechanism, again mirroring an existing Java functionality. The use of these features of CORBA instead of the similar features built in to Java requires a lot of code modi cation when using CORBA with Java. StudioCentral is an excellent product within its domain, but our application, requiring a distributed CORBA implementation, was somewhat outside its main functionality. We had problems 9

interfacing to StudioCentral using Java and CORBA, and this was made more dicult by incomplete documentation. The next version of StudioCentral should have Java and CORBA interfaces, which should overcome most of these problems, and make it much easier to use this software for distributed applications such as the GIAS repository. The GIAS speci cation is quite well designed, but rather vague in places. In particular, the Product and GeoProduct objects were not de ned. It is not clear how GIAS clients and servers can be interoperable without knowing the exact form in which a reference to a product is to be returned. This should be addressed in future versions of the speci cation.

5 Conclusions and Future Work We have implemented a distributed, object-oriented image library that conforms to a subset of the GIAS and USIGS standards, and enables storing, managing, searching and accessing of images and associated metadata. Future work will involve creating a more complete implementation of the GIAS, and the updating of our implementation to conform to new versions of the GIAS and USIGS speci cations, which are still under revision. The recently de ned GIAS version 3.1 diers from 3.0 in a number of ways, most notably in how it handles dierent user-speci ed data models for image metadata, and our implementation needs to be re ned to conform to these changes. We are developing a version of the GIAS system using the Java database connectivity (JDBC) package [26] to interface to the database, rather than StudioCentral. This would be more portable, since StudioCentral only runs on Silicon Graphics computers. Portability of the server is not as important as portability of the client, but is still a useful feature. We plan to compare the performance and ease of development between the two systems. The GIAS implementation is only part of a complete imagery access system. It needs to be integrated with higher-level systems such as IMAD, EXC3ITE and DISCWorld, which will provide traders for resource discovery over multiple libraries, and middleware for handling the many issues involved in the creation of a robust, high-performance distributed system. Developing this system was a dicult process. Integration of Java, CORBA and C++ is still on the bleeding edge of software development. Current CORBA implementations are far from being complete, robust and interoperable. Java Virtual Machines are still not advanced enough to live up to the goal of \write once, run anywhere". Java is still a moving target, and the introduction of JDK 1.2 will probably lead to substantial changes in how we interface Java with CORBA and C++. We are hopeful that future versions of Java, ORBs such as VisiBroker, and object-oriented software such as StudioCentral, which should all become more Java- and CORBA-aware, will enable much simpler development of distributed object-oriented systems such as the application presented here.

Acknowledgements This work was supported by the Defence Science and Technology Organisation (DSTO), and the On-Line Data Archives (OLDA) Program of the Research Data Networks (RDN) and Advanced Computational Systems (ACSys) Cooperative Research Centers (CRC). RDN and ACSys are established under the Australian Government's CRC Program.

References [1] U.S. National Imagery and Mapping Association, http://www.nima.mil/. 10

[2] The U.S. National Imagery and Mapping Association, U.S. Imagery and Geospatial Information System (USIGS) Architecture Framework, http://www.nima.mil/aig/products/uaf/html/index.html, November 1997. [3] The U.S. National Imagery and Mapping Association, U.S. Imagery and Geospatial Information System (USIGS) Technical Architecture, http://www.nima.mil/aig/products/uta/html/index.html, November 1997. [4] Open GIS Consortium, http://www.opengis.org/. [5] Roy Williams, SARA Project, http://www.cacr.caltech.edu/~roy/sara/. [6] Roy Williams and Bruce Sears, A High-Performance Active Digital Library, August 1997, http://www.cacr.caltech.edu/~roy/papers/sarcan.pdf. [7] NASA Goddard Space Flight Center, Earth Observing System Data and Information System, http://spsosun.gsfc.nasa.gov/New EOSDIS.html. [8] Australian Centre for Remote Sensing, ACRES Digital Catalogue, http://acs.auslig.gov.au/intro.html. [9] K.A. Hawick and H.A. James, Distributed High-Performance Computation for Remote Sensing, Proc. of Supercomputing '97, San Jose, November 1997. [10] K.A. Hawick and H.A. James, A Web-based Interface for On-Demand Processing of Satellite Imagery Archives, Proc. of the Australian Computer Science Conference (ACSC) '98, Perth, February 1998. [11] Sun Microsystems, The Java Platform, http://java.sun.com/aboutJava/index.html. [12] The Object Management Group, Common Object Request Broker Architecture (CORBA), http://www.omg.org/corba/. [13] The U.S. National Imagery and Mapping Association, USIGS Geospatial and Imagery Access Services (GIAS) Speci cation, version 3.0, http://www.nima.mil/aig/products/uip/gias/072297/gias0722.html, July 1997; version 3.1, N0101-B, http://www.nima.mil/aig/products/uip/gias/020598/index.html, February 1998. [14] The U.S. National Imagery and Mapping Association, USIGS Common Object Speci cation (UCOS), version 1.0, N0104-A, http://www.nima.mil/aig/products/uip/ucos/072297/ucos0722.html, July 1997; version 1.1, N0104-B, http://www.nima.mil/aig/products/uip/ucos/020598/index.html, February 1998. [15] The U.S. National Imagery and Mapping Association, USIGS Interoperability Pro le (UIP), N0102-A, http://www.nima.mil/aig/products/uip/uip/121997/preface.html, July 1997; N0102-B, http://www.nima.mil/aig/products/uip/uip/020598/index.html, February 1998. [16] The U.S. National Imagery and Mapping Association, Standards Pro le for Imagery Access, version 1.1, http://www-ismc.itsi.disa.mil/ciiwg/spia1/spia v1.html, February 1997. [17] The U.S. National Imagery and Mapping Association, National Imagery Transfer Format (NITF) version 2.0, MIL-STD-2500a, http://164.214.2.51/ntb/2500a/2500a.html, 1994. [18] A. Vogel and K. Duddy, Java Programming with CORBA, Wiley, 1997. [19] Sun Microsystems, Java Remote Method Invocation, http://java.sun.com/products/jdk/rmi/. 11

[20] K.A. Hawick et al., DISCWorld: An Environment for Distributed High-Performance Computing, DHPC Technical Report DHPC-042, June 1998, available at http://www.dhpc.adelaide.edu.au/reports/042/abs-042.html. [21] Iona Technologies, OrbixWeb Product Release Home Page. http://www.iona.com/products/internet/index.html. [22] Inprise Corporation, VisiBroker Home Page, http://www.inprise.com/visibroker/. [23] T.J. Mowbray and R. Zahavi, The Essential CORBA: Systems Integration Using Distributed Objects, Wiley, 1995. [24] D. Hayes, StudioCentral Developer's Guide, Document number 007-3246-001, Silicon Graphics Inc., 1997. [25] K.W. Hare, SQL Standards Home Page, http://www.jcc.com/sql stnd.html. [26] Sun Microsystems, The JDBC Database Access API, http://java.sun.com/products/jdbc/.

12