ISPRS Workshop on Service and Application of Spatial Data Infrastructure, XXXVI (4/W6), Oct. 14-16, Hangzhou, China 
ISPRS ' 
98 
In the HEAVEN approach, the applications are deployed on 
Virtual Machine Topologies which are instances of the virtual 
applications environments (Figure 3). Virtual Machines 
Topologies are instantiations of concurrent and possibly 
overlapping networks of Virtual Machines. Virtual Machines 
are instances of abstract hardware and software configurations 
which are defined by the application designers to comply with 
the applications requirements. They include processors, hard 
drives, memory and bandwidth characteristics, sensors, and 
comply with specific QoS and SLA requirements. Although 
different, non distributed and non grid, but oriented to highly 
configurable operating systems, the Virtual Virtual Machine 
concept used to execute specific virtual machines which were 
specialized instances of a generic one. It had some similarities 
with this approach (Folliot, 2000). 
2.3 Underware, Middleware, Upperware 
Virtual environments are tools and facilities dedicated to the 
design, deployment execution, monitoring and maintenance of 
large applications on distributed resources. These resources may 
be computers, file archives, sensors, visualization environments, 
etc. The users do not need to own any one of them. He or she 
may have access to and use any combination of them among a 
set of available resources whenever he or she is granted the 
appropriate rights to do so, using a simple laptop or 
sophisticated apparatus, e.g., an immersive visualization 
environment 
He does not need any technical knowledge of the underlying 
software and hardware tools, except that one he or she is 
currently using. The technical infrastructure, may it be a state- 
of-the-art middleware for grid computing or a large cluster of 
commodity PC connected through a high-speed fiber-optics 
network is made totally transparent to him/her. 
In order to implement this approach, we need a software layer 
masking the underlying infrastructure. Because hardware, 
operating systems and i/o devices are sometimes referred to as 
underware (Walker, 1999), and because middleware is the de 
facto naming for grid management and interface software, we 
name this new layer the upperware. 
Domain 1 
ipplication 
Domain 2 
ipplicatior 
Domain- 
Domain - 
specific 
specific 
PSE 
PSE 
spectrum to be 
covered 
Enabling 
Application 
Technologies 
PSE-hosting 
Domain - 
generic 
specific 
component 
omponent£ 
HEAVEN Upperware 
(generic components; 
Domain n 
Complex 
Problem 
Solving 
Domain • 
specific 
PSE 
! Domain - 
; specific 
domponentb 
Enabling 
Technologies 
Interface to Grid environment 
Infrastructure 
Grid HW/NW/MW environmen 
-> “rented” (e.g. EGEE et al.; 
Figure 5. The HEAVEN architecture 
3. UPPERWARE DESIGN 
From the user point-of-view, the interface with the virtual 
application environment is a high-level graphic interface that 
masks the resource distribution and technical definitions. It is a 
set of dependent tasks connected by a workflow graph (Figure 
6). This approach leaves all the technical aspects to a further 
step, while focusing on the application logic only. The tasks can 
be connected by a control flow graph formed by sequence, 
parallel, interleaved and imbedded loops. 
The tasks correspond to executable codes that are located 
transparently for the users on remote sites. It is the 
responsibility of the application designers to define which 
resources the application needs, where they should be located if 
required, and which complementary properties they should 
exhibit (availability, QoS, etc). None of these resources are 
required to be local and to belong to the users and designers. 
Brokering protocols and usage grants are therefore supported by 
the upperware. Submission of such grants can be negotiated on 
a permanent or one shot policy. The upperware appears 
therefore as a general resource broker, negotiating with the 
remote systems the availability and use of resources, based on 
the local policies and granted access rights. 
The upperware is the generic service layer used to virtualize the 
resources used by the applications. It masks the actual hardware 
and software resources, making possible the design, 
management and concurrent use of dynamic, possibly 
overlapping and cooperating sets of private computing 
infrastructures (Figures 3). In this respect, the upperware 
enables secure virtual private computing environments to co 
exist, in a way similar to virtual private networks designed to 
co-exist on real communication networks: they are called here 
Virtual Machines Topologies (VMT). 
The upperware is built on top of existing grid middleware. It is 
therefore a requisite that is made compatible with current and 
upcoming grid technology standards (OGSA, WSRF, GT4). 
The HEAVEN upperware is a software layer that is based on 
existing grid infrastructures, e.g., EGEE, RENATER, etc. As 
such, it interfaces both the user communities through the high- 
level graphic interfaces described above, and the underlying 
computing environments. It fills the gap between them and the 
application problem-solving environments (Figure 4, 5). It 
includes generic components for interface with grids 
(invocation and negotiation with remote resource brokers, 
authentication and authorization, grants negotiations, etc). It 
also supports specific components dedicated to particular 
application requirements (interfaces with sensor management 
systems, with visualization tools, etc). Finally, it is the basis on 
which the particular application domains solve problems. 
There are several ways to implement the upperware, for 
example relying on a generic Web services implementation and 
the corresponding Web Services Reference Framework defined 
by GGF. Another option is the CORBA component-based 
architecture. There are even full Java implementations of grid- 
aware middleware. The first option is preferable since it 
guarantees the compatibility with the OGSA architecture and 
the hopefully soon available Globus GT4. Further, compatibility 
with fo 
UNICOI 
supporte 
compatii 
and GT3 
a priority 
The obvi 
are their 
to the ap 
Figure 8 
on three 
INRIA c 
network 
the und 
designers 
correspoi 
and the 
also). An 
is given 1 
Our test! 
research 
Sophia-4 
Linux w 
(Figure 7 
Concemi 
Antipolis 
the VTH 
network 
New Gen 
pour la 
network 
network i 
Concemi 
managen - 
applicati« 
the Linu 
intranet r 
for the cl