At each provider site the messages passed from the client 
layer to the interoperability structure need to be interpreted 
and acted upon. This is achieved through two routes. The 
most direct is a message directed at a data server which has 
knowledge of all the services related to its data set and 
passes the message to the correct service. At sites providing 
several data sets, the message might need to be interpreted 
against several data set servers and this would be handled by 
the Local Search Service. This is equivalent to the 
Distributed Information Manager, but only deals with the 
data held locally. 
Data at a site is organized into one or more collections of 
related items. Each collection forms a data set which will 
contain both data and meta-data, the discrimination between 
these being provider and data set specific. To each data set 
one or more services are attached; the services may operate 
on all types of data in the data set or only one part of it, e.g., 
a relational database management system (DBMS) to an 
inventory table. Descriptions of these services and the parts 
of the data set they operate on are passed to the advertising 
service, establishing a 'data scope' against which users 
requests can be evaluated against. These services are called 
*type' services in the concept since one type of service may 
be related to all data of that type (e.g., a text query service 
could be used for all text data within one data set and across 
all data sets at one site). Careful design of the type services 
should mean that they are adaptable by other providers for 
similar data. It is possible that a particular type of data 
would have more than one 'type' service associated with it, 
(e.g., two different text query services to support different 
access protocols) and that a type service would deal with 
more than just a single data type (e.g., an OO DBMS could 
deal with inventory data and the associated browse data). 
3.3 User Interfaces to the Services 
As for the provider layer, the architectural concept does not 
mandate how the user interfaces should work, only that they 
are compatible with one or more of the protocols that the 
interoperability infrastructure supports. The GCDIS / 
UserDIS concept seeks to encourage community 
development of components, and it is likely that the client 
layer is one of the areas where this will have the most 
impact. 
Three categories of access to the interoperability layer are 
considered in the architectural concept: 
general access interfaces: It is assumed that general 
interfaces which are applicable to a group of similar 
services across all data in the network (e.g. text search). 
This type of interface will be the main access to the 
services of EOSDIS and many of the large archives and 
will be similar in concept to the present day EOSDIS 
Version 0 and ESA's User Interface Terminal (Simpson 
et al., 1993) interfaces. The general interfaces will be 
customized in their operation by specific information 
from the service provider (e.g. vocabulary), etc. 
specialized access interfaces: The above approach would 
support dynamic modification of an existing interface, 
but would not support special interfaces for specific 
services, e.g. an interface which is particularly oriented 
towards the coincident location and analysis of sea 
surface temperature ‘images’ and sub-surface profile 
36 
measurements of temperature and salinity. In this case 
the service provider might be able to provide a software 
module which would be dynamically linked into the 
user’s interface and provide a completely specialized 
interface, configured to a specific service/provider. 
object access interfaces: Finally, objects resulting from 
previous queries should be capable of initiating further 
service requests. For example a search of an image 
inventory might result in a results object which 
contains the inventory records matching the query and a 
reference in the object which would enable a user to 
automatically initiate a browse service and review the 
image being referenced by one of the inventory records. 
4. DEVELOPMENT ISSUES/APPROACH 
The EOSDIS architectural concept described here offers 
several important advantages for some future development of 
GCDIS and/or UserDIS. First, data providers have complete 
freedom of choice as to how they wish to organize data into 
types. They may want to use EOSDIS provided type services 
or data type servers, or they may decide to create their own 
and link them into the local search and retrieval service 
software. They may even decide to replace all data types 
with a fully integrated database management system (and 
appropriate schema); several research projects and 
commercial ventures in the area of object databases are in 
progress and may mature during the lifetime of the global 
change program (Stonebraker and Rowe, 1986; Haas et al., 
1990; Lamb et al., 1991). 
Secondly, the concept supports the inclusion of legacy 
systems into the network. A site is only required to 
advertise only those services it wishes to support in the 
GCDIS/UserDIS context; there is no minimum set of services 
which a site must provide. For example, a site may only be 
able to offer text search and file transfer, but would still be 
able to contribute to the network. 
Thirdly, the architecture provides an open ended approach to 
earth science data search and retrieval. Searches can be 
manipulated at the level of the intersite search service, local 
information manager service, or at the level of the data type 
server. Search capabilities can be negotiated among 
services and do not enter into the protocols themselves. 
This permits the future application of results of ongoing 
research, e.g., in areas of query and schema translation, 
query optimization, and search languages might be adaptable 
to earth science data types (Ordille and Miller, 1993; 
Morrissey, 1990). For example, future search engines may 
be able to assist users through intelligent searching using 
knowledge bases created by the earth science community, 
and data providers could then advertise "knowledge" about 
their data holdings rather than indexes (Smith er al., 1989). 
Fourth, the architecture makes no principal distinction 
between various levels of earth science metadata (e.g., 
directory versus inventory), or between metadata and data. 
This is in realization that, in a GCDIS and UserDIS 
environment, different organizations may very well have 
differing concepts for these objects. The widely differing 
data holdings at these organizations also will likely lead to 
differing interpretations of what is index, what is data, and 
what can be searched within a reasonable time. Despite this 
variability in data it is important that searches on multiple 
data sets provide results which can be compared effectively 
by the us 
mechanism 
of result. 
introductioi 
(Hellersteir 
Finally, tl 
evolutiona 
component: 
all compon 
interface a 
developmer 
of compon 
computer s. 
improved i 
whether the 
then, over 
Moreover b 
accommodz 
which can 
components 
syndrome, | 
and support 
Although tl 
balance be 
capabilities 
anarchy on 
GCDIS / U 
quality arez 
suffers as 
terms empk 
unmanaged 
service rel 
example, so 
or minutes, 
provider ex] 
The solutio 
scope of an 
service pro 
voluntary. ] 
facilitate the 
a reliable ne 
preconditioi 
provide fee 
response (if 
mechanisms 
conventions 
As describe 
computer sc 
the GCDIS 
will need t« 
compatible 
encouraging 
improved so 
in the future 
The GCDIS 
from the tra 
concept into 
NASA will | 
an open inte 
provide data 
to be develoj