ontext requested by the 
ivision of a user request 
ult problem and in the 
user in the planning 
Distributed Information 
content-based search is 
>, the request is divided 
/ is made on the TOMS 
one mask of the ozone 
ask is transferred to the 
xtracts cloud and sea-ice 
inned phytoplankton 
from Sea-WiFS data, 
parate compute Server to 
ration map. 
lem, and represents the 
ble in the future rather 
veloped. Issues such as 
an, incompatibility of 
addressed before such a 
ever. there are .clear 
to the vision, each of 
rt for resolving science 
itersite architecture is to 
a need to leave the 
   
  
Ozone Hole Mask 
    
  
  
d-free and Sea- 
ree fragments 
  
puter 
ver 
  
  
it Search 
ey give access; that is, 
e heterogeneous. For 
manager might provide 
apability across a wide 
ated capabilities over a 
  
3.2 Provider Interfaces to the Intersite 
Architecture 
Each provider site chooses, or is mandated by its 
management, to provide certain services to the system 
community, or some part of that community. In many cases 
a service would be related to data set(s) held at the providers 
site, but it is not mandatory; a service potentially could 
access data held at another site, or even provide a service for 
data passed to it from another site as part of a request. 
The main issues to be resolved in the interfacing of a 
provider services to the entire system are briefly described in 
this section; they are: 
* autonomous internal organization 
* advertising services to users 
* support for searching 
* support for notifications to users when new data and/or 
services are available - subscription services 
* support for incompatibility management 
* the role of data servers. 
Provider sites should be allowed to autonomously organize 
and manage their internal services and data to permit 
political and technical flexibility and therefore a definition 
of how the provider organizes their data and services is not 
part of the architectural concept. What matters is the what 
the site offers for external access and how it can be accessed 
externally. The following discussion defines how the 
provider architecture is represented to the system. 
Sites advertise their services to the system; services which 
are not advertised do not exist from the system perspective. 
The advertisements are managed by the advertising service 
within the interoperability infrastructure and describe what 
the service is and how it can be accessed. Since data is 
essentially equivalent to a service (a user can't access data at 
a provider site without some sort of service), advertisements 
can refer to data and services. 
Data Provider 
   
t nde 
Sites which offer data searching must have an external 
interface for accepting searches (e.g. from the Distributed 
Information Manager), and a service for processing these 
requests. This is called the Local Information Manager, and 
is equivalent to the Distributed Information Manager, in that 
it resolves inexact search requests into exact queries which 
can be placed on individual data servers. This might involve 
some interaction with the user. 
Sites may let users (or programs) subscribe to data which 
they store or distribute. This might be used, for example, to 
inform a user when new data is acquired for their particular 
study area which exceeds a certain quality threshold. To 
make this available the site must offer an external interface 
for a subscription service. Users can indicate their areas of 
interest in a search language which are then routed like other 
searches to services which can monitor the subscription. 
These subscription services then send notifications of new 
information items in those areas matching the user's request 
whenever they are found as part of the routine processing and 
archiving activity (see Figure 3). 
The importance of this concept is that it will free scientists 
from mundane information/data hunting, allowing them to 
specify interests periodically and then receive notifications 
of new data and/or services that are relevant to those 
interests. The acceptance of this functionality and its 
implementation could have a major impact on the way data 
and information systems are developed for the future. 
The nature of the architectural concept described here will 
result in potential incompatibilities between the user tools 
in the client layer and the services provided. Characteristics 
of data, tools, services, etc. which are essential for 
determining incompatibility will be captured in an 
‘interoperability profile’. This profile is specific to the 
type of object under consideration (e.g. data format profile). 
Providers will need to adhere to common conventions for 
describing an interoperability profile, and they need to 
provide external interfaces for obtaining, exchanging and 
negotiating such profiles. Using these profiles it will be 
possible to warn users of potential incompatibilities, and 
offer advice on how to mitigate them. 
Notifications 
& Data 
  
  
  
   
Data Provider 
  
Request 
Broker 
   
    
Subscriptions 
  
  
  
Advertising 
Service 
  
Notifications 
  
  
  
& Data 
  
   
   
  
Fig 3: Subscription Service Concept 
35