since data can only be 
BMS, etc.). The users 
d and access relevant 
iciently as possible. 
) support the mission 
and maintaining the 
/ providing the best 
nity. To achieve the 
flexibility to organize 
propriate way for their 
figure existing services 
1ew user requirements 
e providers, there will 
mpatibilities between 
and a user’s query, or 
service(s). The system 
s will exist and assist 
ively as possible. 
erdisciplinary science. 
:annot be resolved by a 
provider. The system 
e concept of multi-site 
and managed between 
ype of request and how 
re 2. 
ture are, therefore, the 
let a scientist locate, 
vailable in the network 
s which would help a 
"- problems, ‘e.g, of 
oxgy, and tool input and 
functions which would 
yllaborate on research 
hitectural concern from 
)SDIS towards global 
cience focus of GCDIS 
vhich are wider in scope 
ts alone were being 
n the GCDIS/USerDIS 
ized below: 
y in the user 
es. Users will also be 
? à common 
nt system. The 
should be encouraged 
mmunity, though this 
ticipation in the 
es and organizations 
ment of specific 
ions on the number of 
> data/services they 
jle to cope successfully 
topology. 
management or 
xities will be voluntary, 
m, such as EOSDIS, can 
ent authority. The 
ymmodate autonomously 
managed provider sites and not assume a single 
management approach to development, operation, user 
authentication or data protection. In particular the 
system should not depend on the availability of 
network wide management information. 
* The data management solutions should be scalable, and 
cost effective to scale. The design of components 
should avoid limits on capacity which preclude low-end 
providers or restrict what high-end providers can offer. 
* The architecture must help the user work effectively 
within an environment characterized by variability of 
quality in terms of responsiveness, reliability, 
accuracy, availability, and throughput. 
Taken together, these characteristics present some 
.significant challenges to the design and development of 
EOSDIS if it is to be part of a wider data system and be a 
major supplier of components for such a system. It is 
important therefore that EOSDIS establishes what it is able 
to achieve within its cost and schedule budgets, and leaves 
open to future development those aspects beyond its scope. 
3. ARCHITECTURAL CONCEPT 
The architectural concept for EOSDIS is shown in Figure 1 
and described in further detail in NASA 1994b. It can be 
divided into three layers: the client layer, the service 
provider layer and the interoperability infrastructure. 
Individual sites, which may host one or more of these layers, 
are heterogeneous and autonomously managed. The user 
layer is characterized by client environments, which may be 
interactive (e.g., workstation graphical interface) or process 
environments (e.g., analysis algorithm). The 
interoperability layer is characterized by a set of distributed 
services which assess user needs against service offerings 
and connect the user with appropriate service providers. 
Finally, the provider layer is characterized by organizations 
who choose, or are mandated by their management authority, 
to provide a set of services related to data collections or to 
computer resources that they can offer. This includes the 
traditional data center concept and also specialist value- 
added service providers, whether commercial or government 
related (e.g. education specialists). Since the service 
provider layer must allow autonomous management and 
development, the details given here are limited to those 
which allow sites to interoperate. The architectural concept 
then, is in essence the interoperability infrastructure (the 
Intersite Architecture) and how the user and data provider 
services interface to this infrastructure. 
  
     
Interactive Client 
Process Client 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
Fig 1-: 
33 
Conceptual Architecture Overview