The volume andnumber of data setsabout Earth arerapidly growing.However, sharingand integratingthem is difficult dueto incompatible dataformats andplatforms. Wepropose an abstractmodel forinformation sharingand integration anduse it to develop anarchitecture forbuilding open,component-based,interoperablesystems.

Ageographic information system is acomputer-based tool for mappingand analyzing geospatial relation-ships between data sets. GIS data

sets tend to have complex formats and large filesizes. Moreover, the volume of data about Earthis rapidly increasing. Due to the enormous costsinvolved in acquiring, producing, exploiting, anddisseminating geospatial data such as satelliteimagery, it’s practically impossible for a singleorganization to own all the data it needs.

Current GISs are monolithic and platform-dependent applications containing redundantfunctions and databases, and it’s difficult to shareGIS data and geoprocessing methods among dif-ferent software and hardware platforms. They alsorequire excessive training because of the diverseuser interfaces and they lack facilities to easilyaccommodate new methods and data types as theybecome available. Recent development of Internetmap servers lets organizations build Web-basedGISs in which users can view geospatial data viaWeb browsers. However, these proprietary GISsdon’t provide an easy way to integrate data among

map servers or between the user’s local data setsand map servers. To achieve integration, the userusually must download the data and process themlocally. The exchange of data at the file level isinefficient, cumbersome for updating, and mayinvolve complicated data conversions.1

A new computing paradigm for geoprocessingis necessary to move spatial informationexchange from file transfer to a higher level. Anew method should overcome barriers caused byincompatible GIS application platforms and mul-tiple data sources and enable users to share,extend, and integrate functionality from differentGISs in a distributed environment. To do justthat, we propose an architecture for buildingopen and interoperable GIS applications. An openand interoperable GIS adopts industry standardsto create and manage GIS objects that performspatial tasks in a distributed environment.Furthermore, encapsulating geospatial data andmethods in a GIS object makes it possible forusers to access information regardless of the loca-tions of data sources and the application plat-forms involved in the implementation. (See the“Previous Work” sidebar for other approaches.)

Proposed architectureOur architecture is based on an abstract model

for information sharing and integration thatenables peer-to-peer, object-oriented communica-tion among data-handling applications via anobject bus. In the proposed architecture, clientapplications access common object request brokerarchitecture (Corba) objects for services. Thus, datasharing moves from the file-transfer level to thelevel of distributed objects conducting heavy trans-actions between multiple clients and servers.Corba interfaces in the middleware let server-sideobject implementations be transparent to clients.System implementation may involve using Java orother computer languages, as well as proprietaryvendor applications. Consequently, the proposedmiddleware architecture provides a new way forGISs to share data and functionality in a platform-,vendor-, and location-neutral environment.

In addition, both users and developers benefitsignificantly from our techniques. Users have time-ly access to geospatial data and geoprocessingmethods in a single, integrated, and virtual system.Developers gain the power of sharing and inte-grating GIS objects on the network through stan-dard object interfaces. Another contribution isusing Enterprise JavaBeans. We implement Corbaobjects with EJBs in the middleware. A major

62 1070-986X/02/$17.00 © 2002 IEEE

A MiddlewareArchitecture forOpen andInteroperableGISs

Steven H. Wong and Steven L. SwartzNational Oceanic and Atmospheric Administration

Dilip SarkarUniversity of Miami

Feature Article

advantage of EJBs is that the bean developer andthe client application programmer don’t need tobe concerned with service details such as transac-tion support, security, remote object access, andmany other complicated error-prone issues.

Thus, taking advantage of the component-based feature of EJBs and Corba compatibility, ourproposed architecture improves a GIS’s flexibilityand extensibility. We can also add functionality toa GIS by adding new components—GIS beans inthe middleware. Clients can be Web browsers orany client application built around the Corbaobjects’ distributed services, such as C++ and Javaapplications.

An abstract modelTo provide a technology-independent frame-

work that shares a variety of GIS data sets in a dis-tributed, object-oriented, and peer-to-peerfashion, we’ve designed an abstract model forinformation sharing and integration (see Figure1). In this model, both data holders and value-adders are data handlers that create program-ming objects to encapsulate data and processingmethods to share and integrate information andservices. Data holders might be governmentagencies, for example, that own raw data whilevalue adders might be vendors that enhance thedata’s usability. Object interfaces are comparableacross boundaries of data handlers. Data handlersmake objects available by plugging them into theobject bus. The plug-in capability of the objectsis achieved by publishing them with a protocolthat can be transported on the network.

Client applications serve as middlemenbetween end users and the services offered on theobject bus. Data holders, value adders, or thirdparties can create client applications in severalforms. Examples of these clients are Java appletsthat can run in Web browsers and C++ applica-

tions. Specifically, client applications

❚ collect information from objects on the objectbus,

63

Raw data Data holder Value adder

Client application

End user

Object bus

Figure 1. An abstract model for information

sharing and integration. There can be multiple

data holders, value adders, and client

applications.

Previous WorkThe Geospatial and Imagery Access Services (GIAS) specification from

the US National Imagery and Mapping Agency (NIMA) is a milestone pro-ject dealing with geoprocessing interoperability. GIAS is a component inthe US Imagery and Geospatial Information Service (USIGS) architecture(see http://164.214.2.59/sandi/arch/). GIAS defines an object-orientedapplication-programming interface (API) using Corba to remotely accessand manipulate geospatial imagery.1 Applying a subset of GIAS,Coddington et al.2 have implemented a prototype distributed system formanaging and accessing a digital library of geospatial imagery over a wide-area network. Cobb et al.3 have investigated a system design for a Web-based object-oriented mapping database in which a Java clientcommunicates with map applications in Smalltalk servers through a Corbainterface. Wang and Jusoh4 built a Web-based experimental GIS capable ofintegrating data from multiple servers via Corba interfaces. Abel et al.5 pro-posed an architecture for a virtual GIS.

The OpenGIS Specification from the OpenGIS Consortium6 is a com-prehensive specification of a software framework for distributed access togeospatial data and geoprocessing resources. OGIS represents the GISindustry’s most ambitious effort to facilitate the sharing and interoperabil-ity of spatial data so far. Among the more than 200 members of theOpenGIS Consortium are the Environmental Systems Research Institute,Microsoft, Oracle, and Sun Microsystems. NetGIS7 experimentally imple-ments OpenGIS Simple Features Specification for Corba8 on the client sideusing a Java applet.

References1. USIGS Geospatial and Imagery Access Services (GIAS) Specification, version 3.1,

US National Imagery and Mapping Association, 1998.

2. P.D. Coddington et al., Implementation of a Geospatial Imagery Digital Library

Using Java and Corba, tech. report DHPC-047, http://www.dhpc.adelaide.

edu.au/reports/index.html, 1998.

3. M.A. Cobb et al., “An OO Database Migrates to the Web,” IEEE Software, vol.

15, no. 3, May/June 1998, pp. 18-21.

4. F.J. Wang and S. Jusoh, “Integrating Multiple Web-Based Geographic

Information Systems,” IEEE MultiMedia, vol. 6, no. 1, Jan.–Mar. 1999, pp. 49-

61.

5. D. Abel et al., “Towards Integrated Geographical Information Processing,”

Int’l J. Geographical Information Science, vol. 12, no. 4, June 1998, pp. 353-

371.

6. The OpenGIS Guide, 3rd ed., Open GIS Consortium Technical Committee,

http://www.opengis.org/techno/guide.htm, 1998.

7. J. Kahkonen, “Interactive Visualisation of Geographical Objects on the

Internet,” Int’l J. Geographical Information Science, vol. 13, no. 4, June 1999, pp.

429-438.

8. OpenGIS Simple Features Specification for Corba, revision 1.0, Open GIS

Consortium, http://www.opengis.org/techno/specs.htm, 1998.

❚ present information to the end user through auser interface,

❚ incorporate information into the user’s localdata sets,

❚ let the user send local data to data handlersthat create and publish new objects encapsu-lating the user’s data, and

❚ enhance the data with a set of processingmethods.

In the real world, the data-holder and value-adder roles become indistinct, especially in an envi-ronment in which multiple data handlers exist.Objects published by these data handlers comple-ment and interact with one another throughdynamic transactions at a peer-to-peer level. Inother words, an object can both request and pro-vide services. In the process, new data are generatedand stored in servers operated by data handlers.Note that transactions conducted among objectson the object bus are transparent to end users.

Integrating geospatial data and functionalitywith mainstream business software is a shift inthe GIS industry.2 Together with other businessobjects on the object bus, GIS objects providedata and services in a distributed client–serverenvironment represented by our model’s frame-work. To design system architecture based on theabstract information model, we must adoptindustry standards and define object interfaces toensure interoperability and connectivity amongapplications across enterprises.

Corba interfaces for GIS objectsThe goal for open and interoperable comput-

ing is to let applications communicate with oneanother no matter where they’re located or whodesigned them. Corba can address this goal. Twoimportant aspects of Corba3 facilitate the inter-operable computing paradigm:

❚ The Interface Definition Language (IDL) andthe application programming interfaces (APIs)enable client–server object interaction withina specific implementation of an object requestbroker. The ORB serves as an object bus thathandles all communication between a clientand a server object.

❚ The Internet interORB protocol (IIOP) makesany Corba-conformant ORB instantly usable

across the Internet without requiring anyadditional programming. IIOP’s speed andefficiency lets it easily handle transaction-based functions. Companies like Netscape andAOL, Oracle, IONA, Inprise, IBM, ComputerAssociates, and dozens of others are incorpo-rating Corba/IIOP in their products.4 In fact,Netscape has incorporated ORBs in itsNetscape Communicator 4.x.

For applying Corba to GISs, the OpenGISSimple Features Specification for Corba5 providesCorba IDL interfaces that define GIS Corba objectattributes and behaviors. This specification letsdevelopers create interoperable GIS applications toaccess and manipulate geospatial features with“simple” geometry (points, lines, and polygons).In the future, OpenGIS will likely formulate Corbaspecifications for more spatial types such as 3D fea-tures and raster coverages. (For brevity, the phraseOpenGIS for Corba in this article stands for theOpenGIS Simple Features Specification for Corba.OpenGIS for Corba might occasionally includefuture specifications for additional spatial types.)

The current paradigm for GIS applicationsrepresents the view that geoprocessing function-ality is tightly coupled to its internal data mod-els and structures. With GIS objects conformingto OpenGIS for Corba, GIS applications becometemporary collaborations of GIS Corba objectsthat hide data models and structures.

We can implement Corba objects using Java,C++, or other computer languages. The advan-tages of using Java as the implementation lan-guage include portability across platforms,robustness through runtime memory manage-ment, easy program development and mainte-nance, easy client integration with Web browsers,object orientation, security, and multithreading.

EJBs are a component-based Java technologyfor server-side object implementation. The EJBspecification6 lays out the format of a bean and aset of services that the EJB container in which thebean runs must provide. This makes EJBs a pow-erful development methodology for componentand distributed applications. Neither the beandeveloper nor the client application programmerneed to be concerned with service details such astransaction support, security, remote objectaccess, or many other complicated error-proneissues. The EJB server and container transparent-ly provide these services for developers.Furthermore, EJBs offer portability. A bean devel-oped on one EJB server should run on other EJB

64

IEEE

Mul

tiM

edia

servers that meet the EJB specification, which wasdesigned to be 100 percent Corba compatible. AnEJB is actually a Corba server object defined usingJava remote method invocation semantics.4

Our proposed architecture uses OpenGIS forCorba as an interface for communicationbetween clients and GIS objects via the CorbaORB object bus. We can implement these objectsusing EJBs in the middleware servers that canobtain data from backend database servers. Wecan assemble and reuse the GIS beans withoutmuch difficulty, a benefit of a component archi-tecture. To the best of our knowledge, researchershaven’t adequately addressed applying EJBs togeospatial processing in the GIS community.

Figure 2 elaborates on how data holders andvalue adders can benefit from the model inFigure 1. Information services from both dataholders and value adders are published throughCorba objects. A data holder adopts middlewareEJBs to implement the services and obtain infor-mation drawn from the raw data. In the process,we can create and archive derivative data. EJBscan also request services from Corba objects onthe bus. This lets a value adder

❚ connect to Corba objects from data holders,

❚ add functionality to the objects, and

❚ publish new Corba objects.

Moreover, we can add additional derivative datato the value adder’s database.

GIS beans can communicate with databaseservers through Java database connectivity(JDBC) and OpenGIS for Structures QueryLanguage (SQL). The OpenGIS for SQL specifica-tion defines a standard SQL schema that supportsstorage, retrieval, query, and update of geospatialfeature collections via the open database con-nectivity (ODBC) or JDBC API. (The OpenGISSimple Features Specification for SQL is currentlyavailable.7 The commercial products that con-form to this specification are Oracle SpatialOption8 and ESRI Spatial Database Engine.9)

System architectureFigure 3 (next page) depicts our architecture for

building open and interoperable GISs. It’s a Corba-based implementation of the abstract model forinformation sharing and integration. In this archi-tecture, objects in clients and servers communicatethrough the Corba ORB object bus using the IIOP.

The architecture’s core components are Corbaobjects in middleware Corba subsystems. EJBs andobject wrappers in middleware servers capture theCorba objects’ characteristics and implement theirbusiness logic. We propose to connect the EJBs tobackend database servers through JDBC andOpenGIS for SQL. Clients interact with the GISthrough Corba or HTML interfaces.

Corba subsystemsThe Corba subsystems are OpenGIS Corba,

Metadata Corba, Security Corba, andOpenVendor Corba. These subsystems publishCorba objects for clients to use. A client can bean application or an object accessing the Corbaobjects. Therefore, an object in one Corba sub-system can be a client of an object in anotherCorba subsystem.

To enable easy communication betweenCorba objects and EJBs, we use Java classes tomaterialize Corba objects. One of the softwareproducts that accomplishes that is VisiBroker forJava from Borland/Visigenic.10 The Corba objectsin the form of Java classes can delegate tasks toEJBs through Java naming and directory inter-faces (JNDIs).

OpenGIS Corba subsystem. The OpenGIS forCorba specification5 defines GIS Corba objects inthis subsystem. Client applications interact withthese objects through their interfaces to access andmanipulate spatial information comprised of geo-metric features such as points, lines, and polygons.The OpenGIS for Corba contains three groups ofinterfaces: feature interfaces, spatial reference sys-tem interfaces, and geometry interfaces.

A Feature object represents a real-world entityor an abstraction of the real world. It’s constructedfrom geometry objects, attributes (properties), aspatial referencing system, and associated meth-

65

Ap

ril–June 2002

Database EJBs

(Data holder)

(Raw data andderivative data)

Corba objects

Database

(Derivativedata)

EJBs or otherimplementations

(Value adder)

Corba objects

Java applets, C++, and so on

End user

Corba ORB IIOP (Object bus)

(Client applications)

Figure 2. An

implementation of the

abstract model for

information sharing

and integration with

Corba-based

specifications. The

thin arrow between

EJBs and the object

bus indicates that

EJBs can request

information and

services from objects

on the bus.

ods. A Geometry object has coordinates that canbe mapped into real-world positions by aSpatialReferenceInfo object representing a spatialreference system. A GIS layer is a collection of fea-tures. For example, a GIS layer might containtopographical features such as elevation contours(lines). A ContainerFeatureCollection orQueryableContainerFeatureCollection object rep-resents a GIS layer. Each GIS layer exposes itself toclients through either Corba naming or Corbatrader (catalog) services (the white and yellow

pages, respectively, of a Corba service). More than50 interfaces are defined in OpenGIS for Corba,5

providing a rich set of geospatial characteristics.The OpenGIS object server in the middleware

(see [5] in Figure 3) implements the GIS Corbaobjects. We use EJBs (GIS beans) as componentscontaining the business logic for geospatial dataaccess and manipulation. The GIS beans acceptand process requests from GIS Corba objects. TheEJBs obtain necessary information from backenddatabase servers through JDBC and OpenGIS for

66

IEEE

Mul

tiM

edia

Value-addingvendor application

Web browsers withHTML and forms

HTTP ORB IIOP

TCP/IP

HTTP ORB IIOP

Web client

Corbaclient/server[11]

[1]

Web browsers with Java applet

OpenVendorCorba

HTTPserver

Javaservlets

Objectwrappers

VendorGIS objects

Vendor APIs

Web/Corbaclient [2]

Customizedapplication

Corbaclient [3]

OpenGIS Corba

OpenGIS SOL

JDBC JDBC

Security Corba

Metadata Corba

OpenGISobject

server [5]

GISEJBs

VendorGIS

objects

MetadataEJBs

SecurityEJBs

[10]

Metadataserver [6]

Securityserver [7]

[4] Web server

VendorGIS application

[9]

Database server[8]

Database server[8]

Clientapplications

Internet/intranetprotocols

MiddlewareCorbasubsystems

Middlewareservers

Databaseinterfaces

Databaseservers

Figure 3. An

architecture for open

and interoperable GIS.

Dotted lines with

hollow arrows denote

requests for services.

Solid lines with solid

arrows denote

implementations of

services.

SQL interfaces. These GIS beans can be clients ofCorba objects outside of the OpenGIS Corba sub-system (see the dotted line between GIS EJBs [5]and the ORB object bus in Figure 3). Through thisclient–server mechanism, GIS beans can requestservices from Corba objects published by GISs inother organizations. GIS beans can also delegatecertain implementations to objects in the Open-Vendor Corba subsystem that maintains vendorGIS applications (see [9] in Figure 3) noncompliantwith the OpenGIS specifications. (See the “SampleMechanism” sidebar, next page, for an example.)

Vendor GIS applications that comply with theOpenGIS for Corba specification may be pluggedinto the middleware to implement some of thefunctionality of the OpenGIS Corba subsystem.This mechanism, along with the OpenVendorCorba subsystem we discuss later, provides exten-sibility to the system on the server side, which letsthe GIS systematically incorporate commercialtechnology advances. Thanks to Corba interfaces,all implementations of vendor applications aretransparent to clients regardless of vendors’ com-pliance to the OpenGIS for Corba specifications.

Metadata Corba subsystem. The MetadataCorba subsystem contains metadata Corbaobjects that let users access information aboutGIS layer attributes and methods. The metadataobjects contain attributes that are mapped to cer-tain attributes defined in the Federal GeographicData Committee (FGDC) metadata standard.11

Clients access these metadata objects to searchavailable GIS databases and database schemadescriptions. Metadata EJBs in the metadata serv-er (see [6] in Figure 3) implement the businesslogic of metadata Corba objects. The metadataEJBs obtain information about available GIS lay-ers through two mechanisms:

❚ by accessing the backend database server viaJDBC and

❚ by accessing FeatureType objects contained inGIS layers in the OpenGIS Corba subsystem.

The dotted line between the metadata EJBs andthe ORB object bus in Figure 3 indicates the lat-ter mechanism.

Most of the metadata for a GIS layer can befound in its FeatureType object. However, themetadata in the FeatureType object might not beorganized according to the FGDC metadata stan-dard. Metadata EJBs in the metadata server query

the FeatureType object to obtain a GIS layer’smetadata and present the information to clientsin compliance with the FGDC metadata standard.

The Metadata Corba subsystem presents meta-data held by the database servers to the GIS users.The users can then make out the meanings(semantics) of attributes in the GIS layers(OpenGIS Corba objects) and make informedchoices for spatial and nonspatial features. TheMetadata Corba subsystem, however, doesn’tinteract with metadata from other GISs to discov-er useful GIS layers from other GISs. This would bethe task of the OpenGIS catalog services currentlyunder development,12 raising the GIS interoper-ability from a syntactic to a semantic level.13

In the future, we expect to replace MetadataCorba objects with OpenGIS catalog Corba inter-faces.14 With the catalog services playing the roleof the interface between clients and metadata,the metadata’s format becomes transparent tothe clients. We can reuse the metadata EJBs inthe current architecture to implement part of thecatalog service interfaces in the improved archi-tecture. We expect

❚ the catalog services to return metadata infor-mation about GIS layers held in its databaseservers in response to requests from catalogservices of other GISs. To this end, we canreuse most of the metadata EJBs from the cur-rent middleware servers to serve the catalogCorba objects.

❚ the catalog services to discover useful geospa-tial features from other GISs by querying cat-alog interfaces of other GISs dynamically. Wemust create new metadata EJBs to help thecatalog Corba objects with this task.

❚ the OpenGIS Catalog Service to be a majormechanism to dynamically resolve semanticheterogeneity between attributes from GISlayers held in different GISs.

Security Corba subsystem. The SecurityCorba subsystem contains security Corba objectsthat facilitate the authorized access of certain GISdatabases. EJBs in the security server implementthe security objects (see [7] in Figure 3). The secu-rity EJBs access the security database via JDBC.The system manager manages the security data-base from a database management system(DBMS) or a client application that communi-cates with the Security Corba objects.

67

Ap

ril–June 2002

68

This hypothetical example demonstrates an application inter-operating with an ArcView application in a distributed environ-ment. In this example, a Corba client requests and obtains serviceson behalf of a MapInfo (from MapInfo Corporation) user from theOpenGIS Corba subsystem (see Figure A). The GIS applicationthat provides the service is an ArcView application, most likely ina different computer system. ArcView GIS (from ESRI) doesn’t con-form to the OpenGIS for Corba specification. Therefore, we can’t

plug it into the OpenGIS Corba subsystem in a straightforwardmanner as in item [10] in Figure 3. Within our proposed archi-tecture’s framework, the GIS EJBs in item [5] of Figure 3 delegatesthe requests from the Corba client to the OpenVendor Corba sub-system that connects to the ArcView application.

The ArcView project (application) named Miami_Land_Projectcontains database tables, database displays (views), ArcViewscripts (Avenue1 codes), and so on for land-use information of

Miami, Florida. The datainclude attributes for par-cel polygons, aerial pho-tos covering the Miamiarea, and zoning divisionpolygons. ArcView pro-vides a C library calledAVExec to facilitate pro-grams written in C orC++ to execute ArcViewAvenue statements.1 Wecreated an OpenVendorCorba object calledMiami Land with C++.It’s an instance of theCorba class ArcViewCorba (see the “ExampleIDL Descriptions forCorba Interfaces”onpage 74 sidebar for apartial description). ArcViewCorba delegates itsmethod calls to the C++class ArcViewObjectWrapper that has meth-ods executing ArcViewAvenue statementsthrough the AVExec Clibrary. ArcViewCorbaOpenVendor Corba

ORB IIOPHTTP

HTTP

TCP/IP

ORB IIOP

Miami Land InfoOpenGIS layer

ArcViewCorbaWrapper C++ class

Mapinfo Javacustomized application

Corbaclient

AVExec ArcViewvendor API

ArcView applicationMiami_Land_Project

Miami Land OGIS catalog Corba

Security Corba

JDBC

Clientapplications

Internet/intranetprotocols

MiddlewareCorbasubsystems

Middlewareservers

Databaseinterfaces

Databaseservers

ArcViewCorbaOpenVendorCorba object

QueryableContainerFeature-Collection Corba object

[1]

[8]

[5][7] [2] [4]

[3]

[6]

ArcViewCorbaConnector

GIS EJBs

MetadataEJBs

SecurityEJBs

Securityserver

Metadataserver

[9]

VendorGIS objects

Database serverDatabase server

Figure A. A MapInfo

client accesses data in

ArcView through

OpenGIS Corba inter-

faces. Dotted lines

with hollow arrows

denote requests for

services. Solid lines

with solid arrows

denote implemen-

tations of services.

Sample Mechanism

The Security Corba subsystem acts as a gate-keeper for the Corba objects in other subsystems.Client applications must be authenticated bysecurity objects before they can interact with GISCorba objects.

OpenVendor Corba subsystem. TheOpenVendor Corba subsystem enables vendor-neutral use of vendor GIS applications and legacygeospatial data that don’t comply with the OpenGISspecifications. The GIS EJBs in the OpenGIS object

69

Ap

ril–June

object can provide geospatial services from multiple types of GISlayers from an ArcView project, which the current OpenGIS spec-ifications don’t support. In this example, these multiple types ofGIS layers include vector polygons (parcels and zoning divisions)and raster images (aerial photos).

The following steps show how the MapInfo application userobtains a parcel polygon from the remote ArcView applicationthrough an OpenGIS Corba interface:

1. The MapInfo user asks for a parcel polygon in the Miami areato overlay on some GIS layers in the user’s local computer.The end user doesn’t know where the parcel polygon is.

2. We can customize certain MapInfo applications, such asMapXtreme Java Edition, with Java (see http://www.mapinfo.com/software/mapxtreme/java/index.html).Therefore, a MapInfo application itself can be a Corba clientwritten in Java. The client contacts an OpenGIS CatalogCorba object (likely in a remote server transparent to theclient) with the request for retrieval of the parcel given itsextent and spatial reference system (see [1] and [2] in FigureA). The Catalog Corba object sends the request to metada-ta EJBs (see [3] in Figure A) that search the information froma backend database. The metadata EJB finds out dynamical-ly that an OpenGIS Corba object called Miami Land Info canprovide the polygon. This mechanism helps resolve thesemantic variability of GIS data sets. The Miami Land Infoobject is an instance of the QueryableContainerFeatureCollection Corba class (see the “Example IDL Descriptionsfor Corba Interfaces” sidebar, on page 74).

3. After the authentication process involving the SecurityCorba objects (see [4] in Figure A), the client requests theparcel polygon from the Miami Land Info Corba object byissuing a method call get_geometry of the Corba object,supplying the parcel’s extent as a rectangle and the spatialreference system as a string for input parameters (see [5] inFigure A). Note the client is unaware of the location or thename of the server where the Corba object is deployed.

4. The Miami Land Info Corba object has an attribute(ImplementorEjbName) indicating that the GIS EJBArcViewCorbaConnector implements the Corba object.Another attribute (OpenVendorCorbaObjName) in theMiami Land Info Corba object indicates it’s associated withthe Miami Land OpenVendor Corba object. The Miami Land

Info Corba object relays the get_geometry request to theArcViewCorbaConnector EJB (see [6] in Figure A) along withthe name of the OpenVendor Corba object (Miami Land).

5. The ArcViewCorbaConnector EJB obtains a reference to theMiami Land OpenVendor Corba object and passes theget_geometry request to it (see [7] in Figure A).

6. The Miami Land object relays the get_geometry requestto the C++ class ArcViewObjectWrapper, along with thename of the ArcView project (Miami_Land_Project, storedin the ArcViewProjectName attribute) with which theCorba object is associated (see [8] in Figure A).

7. The C++ object ArcViewObjectWrapper has a get_geome-try method that calls the ArcView project (Miami_Land_Project) through AVExec, supplying the parcel’s extentand the spatial reference system (see [9] in Figure A).

8. The ArcView application understands the statements fromthe ArcViewObjectWrapper carried by AVExec, finds the par-cel, transforms the parcel polygon into the specified spatialreference system, and returns the parcel polygon as a stringcontaining the coordinates of the polygon’s nodes.

9. ArcViewObjectWrapper repackages the returned polygonstring into a WKSGeometry object.2 The WKSGeometryobject is eventually returned to the Java client through theMiami Land OpenVendor Corba object, theArcViewCorbaConnector EJB, and the Miami_Land_InfoOpenGIS Corba object.

10. The Java client integrates the WKSGeometry object into theMapInfo application by, possibly, converting theWKSGeometry parcel object into a polygon in MapInfo for-mat. The user sees the parcel overlaid on other GIS layers.The user can perform a geospatial operation on the parcelpolygon object like any local geographical object, such ascomputing the polygon’s area.

References1. Using Avenue, Environmental Systems Research Institute, 1996.

2. OpenGIS Simple Features Specification for Corba, revision 1.0, Open

GIS Consortium, http://www.opengis.org/techno/specs.htm,

1998.

server (see [5] in Figure 3), along with other clients,can take advantage of the functionality provided invendor GIS packages through OpenVendor Corbaobjects. Vendor neutrality is achieved becauseclients only communicate with the Corba inter-faces. Clients don’t need to be concerned about thedata models and structures of vendor applicationsused to implement these interfaces.

Some vendor GIS applications provide geospa-tial functionality unavailable in the currentOpenGIS specifications such as 3D mapping.OpenVendor Corba objects can complement thecurrent OpenGIS specifications by providingclients the special geospatial functionalitythrough Corba interfaces. When OpenGIS speci-fication for the functionality is available, we cancreate new OpenGIS Corba objects and link themto the OpenVendor Corba objects to provide thefunctionality through standard interfaces.

Server-side implementation of the OpenVendorCorba objects involves using object wrappers writ-ten in Java, C, C++, or other languages that aremapped to Corba. The object wrappers are objectsthat access the functionality in vendor applicationsthrough APIs the vendors provide.

Placing the OpenVendor Corba objectsbetween clients and vendor APIs makes it possiblefor most vendor applications to plug into the GIS.As a result, the GIS can maintain a heterogeneousvendor environment to fill functionality gaps thatmight exist in the OpenGIS Corba subsystem.Through the OpenVendor Corba interfaces, a ven-dor application can implement the business logicof some GIS EJBs in the OpenGIS Corba subsystem.This approach promotes reusing functionality andincreases the system’s responsiveness to new com-mercial methodologies. (See the sidebar “SampleMechanism” for an example that illustrates access-ing a proprietary GIS through this subsystem.)

Client applicationsClient applications perform one or both of

these tasks: creating a user interface to interactwith the user or requesting services from Corbaobjects or HTTP servers on the user’s behalf.

Three types of client applications are Web,Corba, and Web/Corba clients. A Web client (see[1] in Figure 3) follows guidelines in the OpenGISWeb Map Server Interface ImplementationSpecification,15 a product of the OpenGIS WebMapping Testbed (see http://www.opengis.org/wmt/index.htm), to access geospatial data frommultiple servers in different sites. It uses HTMLpages for the user interface. Java servlets dynami-

cally create these HTML pages (see [4] in Figure 3).These Java servlets are actually Corba clientsbecause they obtain services from GIS objects in theCorba subsystems, which the dotted line betweenthe Java servlets and the ORB object bus in Figure3 indicates. The Java servlets generate and renderdisplay elements from these GIS objects. The Webclient may also connect to Web servers operated byvalue-adding vendors (see [11] in Figure 3).

A Corba client implements a customized userinterface using a computer language with map-ping to Corba interfaces. Typical Corba clientsinclude Java servlets and customized client appli-cations written in C, C++, Java, and so on (see [4]and [3] in Figure 3). Java servlets request servicesfrom Corba objects on behalf of Web clients andreturn results in HTML format to Web clients.Customized client applications can create flexibleand powerful user interfaces because they areonly limited by the capacity of the computer lan-guages used for client-side implementation. A cus-tomized client application enables client–serverintegration of GIS data. In addition to being ableto incorporate geospatial information from Corbaobjects into local data sets, an end user can createGIS layers from local data sets and publish the GISlayers through the OpenGIS Corba subsystem.The published GIS objects encapsulate data fromthe end user’s local data sets and contain a set ofgeoprocessing methods. This information inte-gration mechanism is a powerful tool by which aGIS application can spatially enable end users’data sets, enhance the data with processing meth-ods, and facilitate data sharing.

The Corba client/server (see [11] in Figure 3)is a Corba client and a server that provides ser-vices beyond those offered by Corba objects ofwhich it’s a client. To provide the extended ser-vices to its clients, the value-adding Corbaclient/server might let users connect to it eitherthrough its Web server or its Corba interfaces.The Corba client/server provides extensibility tothe architecture on the client side. In fact, underthis setting, any GIS can be a Corba client/serverto another GIS. Services offered by objects fromdifferent GISs complement one another regard-less of the software and hardware platformsinvolved in their implementations.

A Web/Corba client runs in a Corba-enabledWeb browser (see [2] in Figure 3). It loads Javaapplets from a Web server. These Java applets caninteract with the user through its graphical userinterface (GUI) and communicate with Corbaobjects to obtain services. Similar to a customized

70

IEEE

Mul

tiM

edia

client application, an end user of a Web/Corbaclient application can integrate GIS Corba objectsinto local data sets and create new GIS layers fromlocal data sets. However, because of restrictions theJava security model imposes, this is relatively dif-ficult to accomplish because it involves runningtrusted applets signed by “trusted” servers.16

ImplementationWe carried out a prototype implementation of

our architecture to demonstrate its feasibility andvalidity. The implementation focuses on themiddleware in which we implemented a subsetof OpenGIS for Corba5 using Java, EJBs, and aDBMS. Implemented objects include GIS Corbaobjects that can be published on the Internet oran intranet for clients to use as well as GIS EJBsthat implement the business logic of the Corbainterfaces and access spatial data from databasescompliant with the OpenGIS for SQL specifica-tion. On the client side, we implemented a sim-ple customized Java application to access andquery published GIS Corba objects.

We used real-world data on oceanography forthis implementation. The oceanographic datasets are a subset of data from the study of FloridaBay conducted by the Southeast Fisheries ScienceCenter of the National Oceanic and AtmosphericAdministration (NOAA) Fisheries.

We created these four GIS layers from the fourdata sets using methods we explain next:

❚ a point GIS layer (Station), corresponding tolocations of water property sampling stations;

❚ a polygon layer (Sub-basin), corresponding todivision of Florida Bay into sub-basins;

❚ a line layer (Tidal Amp), corresponding to con-tours of the bay’s tidal amplitudes; and

❚ a line layer (Effort), corresponding to routeshelicopters use for surveying wading-birds andlarge-fish survey.

Figure 4 (next page) shows both the logical andphysical configuration of the prototype imple-mentation.

Server-side implementationIn this implementation, we retrieved GIS data

from an Oracle database using an Oracle spatialoption8 that conforms to the OpenGIS SimpleFeatures Specification for SQL.7 According to the

SQL schema defined in the specification, each GISlayer is stored as a feature table. Oracle spatial pro-vides utilities for creating, loading, and indexingspatial feature tables (GIS layers) from the real-world oceanographic data sets. We can query alltables for a GIS layer like any table in a relationaldatabase management system. Spatial queries on afeature table can be performed by the SQL func-tions that have been implemented using theOpenGIS Simple Features Specification for SQL.

GIS EJBs that implement GIS Corba objectsaccess GIS feature tables and spatial SQL functionsin the Oracle database through JDBC and theOpenGIS Simple Features Specification for SQL.

We have implemented several necessary Corbainterfaces for client applications to access GIS lay-ers in the Internet/intranet environment. Theseinterfaces include QueryableContainerFeature-Collection, QueryResultSetIterator, and Corba-ObjManager. All Corba interfaces are in Javaclasses.

CorbaObjManager is a new Corba interface wedefined to function as a gatekeeper. All clientapplications must go through this interface toobtain handles for other Corba objects. ItsgetGisLayer method takes the user’s name andpassword and the name of a GIS layer as stringsand returns a reference to a QueryableContainer-FeatureCollection object to the client. If data forthe GIS layer don’t exist, the method throws aLayerNotCreated exception. CorbaObjManageris part of the security Corba subsystem.

QueryableContainerFeatureCollection andQueryResultSetIterator Corba interfaces are definedin OpenGIS for Corba. We implement methods ofthese Corba objects with EJBs. A QueryableContainerFeatureCollection object represents a GISlayer. Given a query string and other parametersto define a query’s scope, a client application caninvoke the evaluate method of the GIS layer toobtain information in the GIS layer. The evalu-ate method returns a QueryResultSetIteratorobject for the client to navigate the query’s resultset. We can deploy these Corba objects (in theform of Java classes) to any server that has a Javavirtual machine. Figure 4 shows the deploymentof Corba objects in a Windows NT server.

SpLayer is a GIS EJB that we create to implementthe business logic of the QueryableContainer-FeatureCollection Corba object, which delegates allrequests from client applications to methods in theSpLayer. SpLayer can communicate with other GISEJBs to fulfill requests from QueryableContainer-FeatureCollection objects. The QueryResultSet-

71

Ap

ril–June 2002

Iterator EJB implements methods in Query-ResultSetIterator Corba interface. The EJB holds andnavigates the result set for a spatial query.

We implemented two methods with this GISbean: advance and get_geometry_by_name.The advance method advances the iterator to thenext record in the result set. Initially, the iteratoris positioned before the first record. Calling theget_geometry_by_name method of the Query-ResultSetIterator EJB with the geometry field’sname as the input parameter returns aWKSGeometry object. The WKSGeometry objectdefined in the Open GIS Consortium’s specifica-

tion5 is used as a basic object representing geom-etry of simple features (points, lines, and poly-gons, and so on) and is exchanged between clientand server objects. Methods in the SpLayer GISbean perform these tasks:

❚ process requests from clients and carried bythe QueryableContainerFeatureCollectionCorba object,

❚ fetch data from an Oracle server using spatialfunctionality in the Oracle spatial option, and

72

IEEE

Mul

tiM

edia

ORB IIOP

TCP/IP

ORB IIOP

QueryResultSet-Iterator

QueryResultSet-Iterator

GISEJBsSpLayer

Java applicationCorbaclient

End user

OpenGIS SQL

JDBC

CorbaObjManager

Database

Oracle8i database serverinstalled on Sun Enterprise server

Clientapplications

Internet/intranetprotocols

MiddlewareCorbasubsystems

Middlewareservers

Databaseinterfaces

Databaseservers

QueryableContainerFeature-Collection (OpenGIS layers)

Effort,Station,Subbasin,Tidal Amp

OpenGISCorba objects(Java classes)

Security Corbaobjects(Java classes)

Windows NT server

[2]

[3]

[4]

[5]

[9] [6], [10]

[8] [1][7], [11]

Figure 4. Logical and

physical configuration

of the prototype

implementation.

Dotted lines with

hollow arrows denote a

request for services.

Solid lines with solid

arrows denote

implementation of

services. Dotted lines

with solid arrows

denote returning objects

once a service is

rendered.

❚ return results to the QueryableContainer-FeatureCollection Corba object throughQueryResultSetIterator EJB and QueryResult-SetIterator Corba object.

Corba objects and GIS EJBs communicatethrough the JNDIs protocol. We used Oracle8iEnterprise Database Server as an EJB server and acontainer in which GIS EJBs are deployed (seeFigure 4).

Client-side implementationWe have developed a customized Java applica-

tion (see [3] of Figure 3) with a minimal GUI. It canconnect to GIS Corba objects and invoke a subset ofmethods in these objects. The purpose in this imple-mentation phase is to ensure middleware compo-nents of the architecture work in a coordinatedmanner. Our future implementation will includesignificant improvements in both the user interfaceand interactions with the Corba subsystems.

The GUI has a window to display GIS mapsand tool buttons for the user to interact withthese maps. The tool buttons perform these tasks:

❚ zoom in and out,

❚ pan,

❚ overlay GIS layers from different sources,

❚ display the cursor’s coordinates in a status baras the cursor moves over the layers on thescreen, and

❚ move a layer upward or downward in relationto other layers.

In a real query, the Corba client interacts withthe middleware Corba interfaces, and GIS EJBsassist the Corba objects to access a GIS layerstored in a feature table in the database (seeFigure 4). To access GIS Corba objects, the Javaclient first contacts the CorbaObjManager Corbaobject that is published on the Internet or anintranet. The Corba ORB IIOP facilitates thiscommunication. The client requests a referenceto a GIS layer, such as the Tidal Amp, by sendinga GetGisLayer call defined in the CorbaObj-Manager interface (see [1] in Figure 4 and the“Example IDL Desciptions for Corba Interfaces”sidebar, next page). The client presents a username, a password, and the name of requestedGIS layer (Tidal Amp) as input parameters.

In the current implementation, the Corba-ObjManager stores a set of valid user names andpasswords in its Java class. A future implementa-tion will let the CorbaObjManager access userinformation from a database through JDBC. Oncethe validity of a user is confirmed by Corba-ObjManager, the client obtains a reference to theTidal Amp Corba object, an instance of theQueryableContainerFeatureCollection OpenGISCorba interface. The client then invokes the eval-uatemethod of the GIS layer Tidal Amp (see [2] inFigure 4), starting a query. The Tidal Amp Corbaobject delegates the query task to the evaluatemethod of a SpLayer GIS EJB, along with the nec-essary information (for example, theFeatureTableName attribute) for the EJB to locatethe feature table for the Tidal Amp GIS layer in theOracle database (see [3] in Figure 4 and the“Example IDL Desciptions for Corba Interfaces”sidebar). This is done through the JNDI protocol,without the client’s awareness. The SpLayer EJBqueries the feature table through JDBC andOpenGIS Simple Features Specification for SQLinterfaces (see [4] in Figure 4). The Query-ResultSetIterator EJB that holds the result set of thequery (see [5] in Figure 4) is wrapped inside aQueryResultSetIterator Corba object (see [6] inFigure 4) and returns to the client (see [7] in Figure4). This lets the client navigate all spatial featuresof the GIS layer Tidal Amp, using the combinationof the advance and get_geometry_by_namemethods of the QueryResultSetIterator Corba inter-face (see [8] in Figure 4). Keeping transparent to theclient, the QueryResultSetIterator Corba object del-egates the method calls to QueryResultSetIteratorEJB (see [9] in Figure 4), which holds the result setof the evaluate query. The advancemethod iter-ates through the records in the result set. Theget_geometry_by_name method returns aWKSGeometry object (see [10] and [11] in Figure4). The WKSGeometry Java objects encapsulatespatial features of the Tidal Amp GIS layer that canbe used to generate display elements to be passedto the Java client’s GUI for rendering. Other GISlayers (Effort, Station, and Sub-basin) can also beaccessed in the same way and overlaid on oneanother.

In the next implementation phase, we pro-pose to use WKSGeometry objects to wrap spatialdata on the end user’s computer. TheseWKSGeometry objects can be passed to aQueryableContainerFeatureCollectionFactoryCorba object5 that then creates new GIS layers onthe server side for publication on the network.

73

Ap

ril–June 2002

74

We only define some of the attrib-utes and methods we mention in thisarticle in the interfaces here. In thissidebar, we provide an explanation ofFigure B and then give two otherexamples (see Figures C and D) forfurther reference. For detailed docu-mentation on the standard Corba IDL,see the Open GIS Consortium’s spec-ification.5

Figure B gives the Queyable-ContainerFeatureCollection Corbainterface. We added the three read-only attributes to the interface forour architecture:

❚ readonly attribute string

ImplementorEjbName; is thename of the EJB that implementsthis Corba object.

❚ readonly attribute string

OpnVendorCorbaOjbName; isthe name of the OpenVendorCorba object from which thisCorba object can obtain servicesthrough the EJB. It can be anempty string meaning noOpenVendor Corba object isneeded for service.

❚ readonly attribute string

FeatureTableName; is thename of the feature table inDBMS that stores data for the GISlayer. It can be an empty string ifthis Corba object depends totallyon the OpenVendor Corba objectfor services.

The subsequent operation(Geometry get_geometry(in

NVPairSeq geometry_context)

raises (InvalidParams);) isinherited from Feature interface thatis inherited by FeatureCollection.Geometry context can be informationon a spatial reference system, abounding polygon, and so on. Thisfinal operation in Figure B is inheritedfrom QueryEvaluator.

Example IDL Descriptions for Corba Interfaces

module OGIS {

interface QueyableContainerFeatureCollection :

FeatureCollection, QueryEvaluator {

readonly attribute string ImplementorEjbName;

readonly attribute string OpnVendorCorbaOjbName;

readonly attribute string FeatureTableName;

Geometry get_geometry(in NVPairSeq geometry_context) raises

(InvalidParams);

QueryResultSetIterator evaluate(in string query,in QLType

q1_type, in

NVPairSeq params) raises (QueryLanguageTypeNotSupported,

InvalidQuery, QueryProcessingError);

};

};

Figure B. The QueyableContainerFeatureCollection Corba interface.

#include “OGIS.idl”

module GisCorba {

interface CorbaOjbManager {

exception LayerNotCreated { string why; };

OGIS::QueryableContainerFeatureCollection getGisLayer(

in string username, in string password, in string

GisLayerName ) raises (LayerNotCreated);

};

};

Figure C. The CorbaOjbManager Corba interface.

#include “OGIS.idl”

module OpenVendorCorba {

interface ArcViewCorba {

readonly attribute string ArcViewProjectName;

OGIS::WKSGeometry get_geometry ( in OGIS::NVPairSeq

geometry_context );

};

};

Figure D. The ArcViewCorba Corba interface.

We can convert the Java application into aJava applet, so that users can use a Corba-enabledWeb browser (such as Netscape Navigator 4.x, see[2] in Figure 3) to access and interact with GISCorba objects. Future implementations on theclient side will improve the client GUI andinclude more types of clients such as aWeb/Corba or C++ client. Client applications willprovide users reliable and timely access to a sin-gle, virtual GIS with spatial and nonspatial infor-mation from a network of geographicallydistributed, physically separated servers.

The proposed system architecture is the foun-dation for the design and implementation of aninteroperable GIS: the Spatially Enabled Fisheriesand Environmental Database System (SEFEDS) atthe Southeast Fisheries Science Center.1

Performance issuesWe ran several tests to study a prototype sys-

tem’s performance. In one test, we deployed allCorba objects, EJBs, and spatial databases in anOracle8i database server running on a SunEnterprise 250 server with a single CPU at 400MHz and a 256-Mbyte main memory. On ourLAN T1 line (100 Mbits per second), it took anaverage of 4 seconds for the Java client applica-tion running on a number of Intel desktops to ini-tialize a connection to the Oracle database andthe CorbaObjManager Corba object deployed inthe Oracle8i database. It took about 2 seconds forthe CorbaObjManager object to connect to aQueryableContainerFeatureCollection Corbaobject that initializes its corresponding SpLayerEJB. After that, the CorbaObjManager objectreturned a reference to the QueryableContainer-FeatureCollection Corba object to the client thatcan then invoke methods of the latter Corbaobject. The method calls to query and iterategeospatial features of a relatively small GIS layer(less than 1-Mbyte file size) completed within asecond. The performance for connections degrad-ed moderately in the Internet environment,adding extra seconds depending on the networksetup. The connections are only necessary oncefor each client per processing session.

In another test, we deployed Corba objects inone Windows NT server. We deployed EJBs andspatial databases in the Oracle8i database serverwe just mentioned, as Figure 4 shows. We onlyran this test on the LAN environment, and wecan compare its performance with the first test.

Our study results reveal that the prototype sys-tem’s performance is adversely affected by estab-

lishing connections between the client and Corbaobjects, between Corba objects and EJBs in theOracle database server, and between EJBs inside theEJB container (in our case, the Oracle database serv-er). However, once connected, a client can invokemethods in Corba objects and obtain returnedresults quickly. We believe that the following mea-sures will improve the system performance:

❚ Upgrade the main memory and increase thecapacity and number of CPUs for the SunEnterprise server.

❚ For each Corba object, create a pool of con-nections to EJBs in the Oracle server to reducethe need to establish a database connectionon the fly.

❚ For each EJB, create a pool of connections tothe Oracle database that stores GIS layers infeature tables to avoid frequently establishingthe expensive database connection.

❚ Explore cache technology to reduce the fre-quency of accessing the physical databases.

ConclusionGIS applications based on our architecture in

its current form are interoperable syntactically. Atthis level of interoperability, before using a GISlayer correctly, the user must acquire knowledgeon the semantics of attributes of the underlyingGIS layer12 through studying the metadata of theGIS layer. Researchers have conducted much worktoward solving the GIS semantic heterogeneity.17,18

We envision that the future OpenGIS catalog ser-vice14 will improve our ability to resolve semanticheterogeneity in distributed GISs by enablingmetadata servers to interact with one anotherdynamically. MM

AcknowledgmentsWe thank Chris Snyder for his help with our

Java GUI and his comments on this article. Wealso appreciate Marinell Davis’ assistance withOracle8i. We are fortunate to have Geoff Sutcliffeproviding valuable feedback on this study. Wethank the reviewers whose constructive sugges-tions have improved the presentation and litera-ture survey. This research was carried out in partunder the auspices of the Cooperative Institutefor Marine and Atmospheric Studies (CIMAS), aJoint Institute of the University of Miami and theNOAA, cooperative agreement #NA67RJ0149.

75

Ap

ril–June 2002

References1. S.H. Wong, A Corba-Based Middleware Architecture

for Building Open and Interoperable Geographic Infor-

mation Systems, master’s thesis, Dept. of Computer

Science, Univ. of Miami, 2000.

2. M.J. Egenhofer et al., “Progress in Computational

Methods for Representing Geographical

Concepts,” Int’l J. Geographical Information Science,

vol. 13, no. 8, Dec. 1999, pp. 775-796.

3. The Complete Corba/IIOP 2.5 Specification, Object

Management Group, http://www.omg.org/

technology/documents/formal/corba_iiop.htm,

1998.

4. R. Orfali and D. Harkey, Client/Server Programming

with Java and Corba, 2nd ed., John Wiley & Sons,

New York, 1998.

5. OpenGIS Simple Features Specification for Corba, revi-

sion 1.0, Open GIS Consortium, http://www.

opengis.org/techno/specs.htm, 1998.

6. Enterprise JavaBeansTM Specification, version 1.1,

Sun Microsystems, http://java.sun.com/products/

ejb/docs.html, 1999.

7. OpenGIS Simple Feature Specification for SQL,

revision 1.1, Open GIS Consortium, http://www.

opengis.org/techno/specs.htm, 1999.

8. Oracle8i Spatial User’s Guide and Reference, release

8.1.5, Oracle, 1998.

9. J. Gaskill and D. Brooks, “Understanding ArcSDE,”

http://www.esri.com/software/arcinfo/arcsde/

understanding_arcsde_uc20000.ppt, 2000.

10. VisiBroker for Java Product Documentation, Borland,

http://www.borland.com/techpubs/books/vbj/vbj3

3/pdf_index.html, 2000.

11. Federal Geographic Data Committee, Content Stan-

dard for Digital Geospatial Metadata, http://www.

fgdc.gov/metadata/contstan.html.

12. An Overview of the Web Mapping Testbed, Open GIS

Consortium, http://opengis.opengis.org/wmt/

wmtinsert.pdf, 2000.

13. Y. Bishr, “Overcoming the Semantic and Other Barri-

ers to GIS interoprability,” Int’l J. Geographical Infor-

mation Science, vol. 12, no. 4, June 1998, pp.

299-314.

14. OpenGIS Catalog Interface Implementation Specifica-

tion, revision 1.0, Open GIS Consortium, http://

www.opengis.org/techno/specs/99-051.pdf, 2000.

15. OpenGIS Web Map Server Interfaces Implementation

Specification, revision 1.0.0, Open GIS Consortium,

http://www.opengis.org/techno/specs/00-028.pdf,

2000.

16. C.S. Horstmann and G.Cornell, Core Java, Sun

Microsystems Press, Palo Alto, Calif., 1998.

17. T. Devogele, C. Parent, and S. Spaccapietra, “On

Spatial Database Integration,” Int’l J. Geographical

Information Science, vol. 12, no. 4, June 1998,

pp. 335-352.

18. R. Laurini, “Spatial Multi-Database Topological Con-

tinuity and Indexing: A Step Towards Seamless GIS

Data Interoprability,” Int’l J. Geographical Information

Science, vol. 12, no. 4, June 1998, pp. 373-402.

Steven H. Wong is a physical sci-

entist at the Southeast Fisheries

Science Center of NOAA Fisheries.

His research interests include object

systems and architecture and

applying geographic information

systems and remote sensing to the study of marine fishery

ecology. He has a BS in marine geology from the

Shandong College of Oceanography, China; an MS in

marine geology from the University of Miami; and an MS

in computer science from the University of Miami, Florida.

Dilip Sarkar is an associate pro-

fessor of computer science at the

University of Miami, Coral

Gables. His research interests

include design and analysis of

algorithms, parallel and distrib-

uted processing, middleware and Web computing, mul-

timedia communication over broadband and wireless

networks, fuzzy systems, and neural networks. He has

a BTech in electronics and electrical communication

engineering from the Indian Institute of Technology,

Kharagpur; an MS in computer science from the Indian

Institute of Science, Bangalore; and a PhD in comput-

er science from the University of Central Florida.

Steven L. Swartz is the director for

the Protected Species and

Biodiversity Division, Southeast

Fisheries Science Center of NOAA

Fisheries. His current research

interests include marine mammal

studies and applying information technology to marine

fisheries studies. He has a BA in biology from the

University of California, Santa Barbara, and a PhD in

marine science from the University of California, Santa

Cruz.

Readers may contact Wong at the Southeast Fisheries

Science Center, NOAA Fisheries, 75 Virginia Beach Dr.,

Miami, FL 33149, email Steven.Wong@noaa.gov.

76

IEEE

Mul

tiM

edia