3.1 Intersite Architecture 
The intersite architecture is necessary to connect the 
services offered by providers to needs expressed by users in 
terms of requests to the system. Three classes of software 
component are envisaged for this layer: 
Advertising Service: The services offered by providers on 
the network need to be advertised to users. The 
advertising service is used by other components in the 
intersite architecture to perform their function. 
Request Broker Service: This service performs the 
matching between a user request and the services 
offered. In the many cases the user (e.g., a process) may 
have specified the service to be connected to, in others 
the broker will have to parse a ‘request description’ and 
use the advertising service to establish which services 
could satisfy the request. The request broking activity 
might involve user interaction. 
Distributed Information Manager : Where multiple sites 
are needed to resolve a request then an Inter-site Search 
Service is required to manage the process. The service 
will break up the query if necessary and generate a plan 
containing sub-requests which will be processed at 
individual sites. The sub-requests will generally be 
characterized by queries and operations, where an 
operation is usually some manipulation of results to 
provide output in the form or context requested by the 
user. The optimization of the division of a user request 
into a request plan is a difficult problem and in the 
short-term might involve the user in the planning 
process. 
An example of the use of the Distributed Information 
Manager to handle a coincident, content-based search is 
shown in Figure 2. In this case, the request is divided 
into three sub-requests: a query is made on the TOMS 
binned product to extract an ozone mask of the ozone 
hole for the required date, the mask is transferred to the 
second service provider which extracts cloud and sea-ice 
free fragments of the binned phytoplankton 
concentration product derived from Sea-WiFS data, 
which are then mosaiced on a separate compute server to 
form a single multi-date concentration map. 
Clearly this is not a trivial problem, and represents the 
vision of what should be possible in the future rather 
than what can immediately be developed. Issues such as 
optimization of the query plan, incompatibility of 
vocabularies, etc., all need to be addressed before such a 
vision is achievable. However there are clear 
evolutionary steps on the way to the vision, each of 
which give the user more support for resolving science 
questions. The purpose of the intersite architecture is to 
enable this evolution without a need to leave the 
architecture framework. 
  
What is the distribution of Phytoplankton Concentration 
underneath the ozone hole in the ice-free ocean 
for dates nearest October 15, 1995 
  
   
   
Request 
phytoplankton concentration map 
masked for sea-ice and cloud 
(values tagged with date) 
Fig 2. 
The main issues related to the development of these three 
intersite components are related to vocabulary management 
and mapping, service and client incompatibility 
management and support for multi-protocol access to a 
dataset. These issues are considered further in NASA, 1994a. 
The interoperability layer assumes that each of its services 
can be distributed. There will probably be more than one 
example of a request broker or distributed information 
manager. They can differ in the scope of their capabilities or 
TOMS (Dobson threshold,dates) 
   
  
   
  
  
patial intersect with Ozone Hole 
  
  
    
  
  
TOMS 
[Level 3 binned 
product] 
  
   
Ozone Hole Mask 
SeaWiFsS (chlorophyll, dates, 
  
SeaWiFS 
[Level 3 binned 
product] 
mask)) 
   
  
  
  
  
   
  
  
  
  
   
  
Cloud-free and Sea- 
Ice free fragments 
combine cloud-free and ice- 
free values into distribution 
  
  
   
  
Example - Use of Inter-Site Request Agent to Resolve Coincident Search 
to which services and providers they give access; that is, 
intersite services can themselves be heterogeneous. For 
example, a distributed information manager might provide 
relatively basic inter-site request capability across a wide 
range of services, or more sophisticated capabilities over a 
smaller subset. 
34 
3.2. Pro 
Arc 
Each prov 
managemer 
community, 
a service wi 
site, but it 
access data 
data passed 
The main 
provider ser 
this section 
e autono 
e adverti 
* Support 
* Support 
service 
* Support 
e the role 
Provider sit 
and manag 
political anc 
of how the 
part of the : 
the site offe 
externally. 
provider arc 
Sites adveri 
are not adve 
The adverti: 
within the i 
the service 
essentially e 
a provider s 
can refer to 
Data Pi