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