4
et)
m-
ted
hi-
tis-
el-
lue;
op-
sed
| or
ele-
ded
ele-
] as
in-
02).
nbi-
rain
de-
re-
ict's
tion
hich
1ake
nts.
red
5) to
ly a
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXX V, Part B4. Istanbul 2004
wide range of services and possibly to reach larger groups
of users. Figure 1 illustrates the interactions that take place
as GSP-nodes provide services to their users.
Users interact with the different GSP-nodes to request their
specific services. Figure 1 shows these interactions as dash-
ed-lines. GSP-nodes may make use of architectural ele-
ments available in other GSP-nodes in order to realise a
particular service. These interactions between GSP-nodes
are shown in Figure 1 as solid lines running from node
to node. All connections mentioned here are established
through a network.
At the bottom of Figure | we can see that additional data
collections located at non-GSP-nodes may still be accessed
if needed, either by users or service providers. This is
achieved by making use of the conventional data discovery
functionality, of the clearinghouse server. These interac-
tions appear in Figure 1 as dashed-dot-lines.
>
2.2 GSP-node
Figure 2 shows the internal configuration of a GSP-node.
The service repository contains the descriptions of avail-
able architectural elements (service descriptions), either
data definitions, process definitions, or previously assem-
bled service chains.
The geo-processing units are responsible for the execution
of the various functions of the node. These units use geo-
data and applications during operation as specified in the
definitions stored in the service repository. The service de-
sign unit is in charge of defining how the different services
are realised. The underlying principles of this architec-
ture are based on OGC technical baseline specifications for
OpenGIS Services (OGC, 2002).
The process of generating service chains within the GSI
can be broken down into three major activities: defining
and registering elementary services, assembling a service
chain and delivering the results. Three different roles can
be identified from these activities: service providers, ser-
vice consumers and end users.
Service providers are responsible for describing and mak-
ing their elementary services available for others to use.
We denote the entities that provide these elementary ser-
vices as components. Service providers make use of a
GSP- Node (a) cm
geo-data
Collection |"
= Se. m
processing [^3 Y m
; definitions. - i
data SO)
definitions Ly
Service crea ee
repository 4
t
7 — — — 4 - --
; I
Y 4
f =
| User (1) | ... User (n). |
Figure 2: GSI-node internal structure
1229
framework (design methodology) that enables the mod-
elling of these components. These models act as descrip-
tors that specify the function and the interaction point(s) of
the components.
Service consumers use available components to design more
complex services. Service consumers make use of the same
framework used by the service providers to assemble indi-
vidual components into chains. They define these chains
by adding control components that govern the relations be-
tween the elementary components used in the chain.
These control components help ensuring that the constraints
and conditions defined at the interaction points of the elc-
mentary components are satisfied. The resulting chain is
described as a service realisation. The service can be re-
alised by instantiating the behaviour portrayed in the spec-
ification. End users trigger the definition and execution of
service specifications by posting requests to the system.
3 ARCHITECTURAL ELEMENTS
To deal with the issues concerning the internal structure
of a service, we have to identify and characterise the ar-
chitectural elements within a distributed geo-information
system. First of all we ignore details of implementation
and communication of these elements in order to focus on
the functions they provide and the constraints that apply to
their interactions with one another.
Architectural elements basically encompass the different
components of the system, however, here we refer to a
component in a slightly different manner than the way this
term is used by the software engineering community. The
term component in software engineering disciplines refers
to a self-contained unit of independent deployment, with
well-defined interfaces that has no persistent state (Szyper-
ski, 2002). Usually, a component provides a particular
function or group of related functions. A component is
a reusable unit of composition that can be used to form
applications with other components in the same or other
computers in a distributed network.
We refer to a component not only to represent units of soft-
ware, but in general to any architectural element of the Sys-
tem that provides a function required in a larger processi ng
chain. Such processing chain is formally described in a
service realisation. Components in this context can thus
be used, for example, to refer to some abstract representa-
tions of data. or to an action or set of actions performed by
a human, and that may yield a necessary result or provide
a required function. In order to create abstract representa-
tions of components of geo-information systems, GSDM
makes use of architectural elements. GSDM ignores the
details of component implementation to focus on the roles
of components, the constraints upon their interaction with
other components, and their use of data.
We distinguish three different types of architectural ele-
ments within a GSI system (see Figure 3):
