ArticlePDF Available

Abstract and Figures

In the last three years activities in Grid computing have changed; in particular in Europe the focus moved from pure research-oriented work on concepts, architectures, interfaces, and protocols towards activities driven by the usage of Grid technologies in day-to-day operation of e-infrastructure and in applicationdriven use cases. This change is also reected in the UNICORE activities [1]. The basic components and services have been established, and now the focus is increasingly on enhancement with higher level services, integration of upcoming standards, deployment in e-infrastructures, setup of interoperability use cases and integration of applications. The development of UNICORE started back more than 10 years ago, when in 1996 users, supercomputer centres and vendors were discussing "what prevents the efficient use of distributed supercomputers?". The result of this discussion was a consensus which still guides UNICORE today: seamless, secure and intuitive access to distributed resources. Since the end of 2002 continuous development of UNICORE took place in several EU-funded projects, with the subsequent broadening of the UNICORE community to participants from across Europe. In 2004 the UNICORE software became open source and since then UNICORE is developed within the open source developer community. Publishing UNICORE as open source under BSD license has promoted a major uptake in the community with contributions from multiple organisations. Today the developer community includes developers from Germany, Poland, Italy, UK, Russia and other countries. The structure of the paper is as follows. In Section 2 the architecture of UNICORE 6 as well as implemented standards are described, while Section 3 focusses on its clients. Section 4 covers recent developments and advancements of UNICORE 6, while in section 5 an outlook on future planned developments is given. The paper closes with a conclusion.
Content may be subject to copyright.
Jül - 4319
Mitglied der Helmholtz-Gemeinschaft
Jülich Supercomputing Centre (JSC)
UNICORE 6 – Recent and Future
Advancements
Achim Streit, Piotr Bala, Alexander Beck-Ratzka,
Krzysztof Benedyczak, Sandra Bergmann, Rebecca Breu,
Jason Milad Daivandy, Bastian Demuth, Anastasia Eifer,
André Giesler, Björn Hagemeier, Sonja Holl,
Valentina Huber, Nadine Lamla, Daniel Mallmann,
Ahmed Shiraz Memon, Mohammad Shahbaz Memon,
Michael Rambadt, Morris Riedel, Mathilde Romberg,
Bernd Schuller, Tobias Schlauch, Andreas Schreiber,
Thomas Soddemann, Wolfgang Ziegler
Berichte des Forschungszentrums Jülich 4319
UNICORE 6 – Recent and Future
Advancements
Achim Streit, Piotr Bala, Alexander Beck-Ratzka,
Krzysztof Benedyczak, Sandra Bergmann, Rebecca Breu,
Jason Milad Daivandy, Bastian Demuth, Anastasia Eifer,
André Giesler, Björn Hagemeier, Sonja Holl,
Valentina Huber, Nadine Lamla, Daniel Mallmann,
Ahmed Shiraz Memon, Mohammad Shahbaz Memon,
Michael Rambadt, Morris Riedel, Mathilde Romberg,
Bernd Schuller, Tobias Schlauch, Andreas Schreiber,
Thomas Soddemann, Wolfgang Ziegler
Berichte des Forschungszentrums Jülich; 4319
ISSN 0944-2952
Jülich Supercomputing Centre (JSC) Jül-4319
Vollständig frei verfügbar im Internet auf dem Jülicher Open Access Server (JUWEL)
unter http://www.fz-juelich.de/zb/juwel
Zu beziehen durch: Forschungszentrum Jülich GmbH, Zentralbibliothek, Verlag
D-52425 Jülich · Bundesrepublik Deutschland
02461/61-6123 · Telefax: 02461/61-6103 · e-mail: zb-publikation@fz-juelich.de
FORSCHUNGSZENTRUM J
¨
ULICH GmbH
J¨ulich Supercomputing Centre
D-52425 J¨ulich, Tel. +49 2461 61-6402
UNICORE 6 Recent and
Future Advancements
Achim Streit, Piotr Bala, Alexander Beck-Ratzka, Krzysztof Benedyczak,
Sandra Bergmann, Rebecca Breu, Jason Milad Daivandy, Bastian Demuth,
Anastasia Eifer, Andr´e Giesler, Bj¨orn Hagemeier, Sonja Holl,
Valentina Huber, Nadine Lamla, Daniel Mallmann, Ahmed Shiraz Memon,
Mohammad Shahbaz Memon, Michael Rambadt, Morris Riedel,
Mathilde Romberg, Bernd Schuller, Tobias Schlauch, Andreas Schreiber,
Thomas Soddemann, Wolfgang Ziegler
February 2010
Authors
Achim Streit, Sandra Bergmann, Rebecca Breu, Jason Milad Daivandy, Bastian
Demuth, Andr´e Giesler, Bj¨orn Hagemeier, Sonja Holl, Valentina Huber, Nadine
Lamla, Daniel Mallmann, Ahmed Shiraz Memon, Mohammad Shahbaz Memon,
Michael Rambadt, Morris Riedel, Mathilde Romberg, Bernd Schuller
J¨ulich Supercomputing Centre (JSC)
Forschungszentrum J¨ulich GmbH
J¨ulich, Germany
Piotr Bala, Krzysztof Benedyczak
Interdisciplinary Center for Mathematical and Computational Modeling (ICM)
Warsaw University
Warsaw, Poland
Thomas Soddemann, Wolfgang Ziegler
Fraunhofer Institute for Algorithms and Scientific Computing (SCAI)
Sankt Augustin, Germany
Anastasia Eifer, Tobias Schlauch, Andreas Schreiber
Simulation and Software Technology,
German Aerospace Center (DLR)
Cologne, Germany
Alexander Beck-Ratzka
Max Planck Institute for Gravitational Physics
Potsdam, Germany
7
8
Contents
1 Intro duction 7
2 Architecture and Standards 9
2.1 Client Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 System Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Using UNICORE 13
3.1 Eclipse-based URC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Command-line client UCC . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Programming API HiLA . . . . . . . . . . . . . . . . . . . . . . . 15
4 Recent Developments 17
4.1 Virtual Organisation Management . . . . . . . . . . . . . . . . . 17
4.2 Shibboleth Integration in URC . . . . . . . . . . . . . . . . . . . 18
4.3 Interactive Access with X.509-based SSH . . . . . . . . . . . . . 19
4.4 DataFinder Integration . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Java-GAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Application Support through GridBeans . . . . . . . . . . . . . . 21
4.7 Monitoring of UNICORE 6 Services . . . . . . . . . . . . . . . . 23
4.8 Remote administration of UNICORE 6 . . . . . . . . . . . . . . . 24
4.8.1 Dynamic Service Deployment . . . . . . . . . . . . . . . . 24
4.8.2 AdminService . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.9 New Workflow Constructs for-each-loop . . . . . . . . . . . . . 25
5 Future Developments 27
5.1 Execution Environments . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Licence Management . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1 Current Situation . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2 SmartLM Solution . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Enhanced Remote Administrative Tools . . . . . . . . . . . . . . 28
6 Summary 29
9
10
Chapter 1
Introduction
In the last three years activities in Grid computing have changed; in particular
in Europe the focus moved from pure research-oriented work on concepts, ar-
chitectures, interfaces, and protocols towards activities driven by the usage of
Grid technologies in day-to-day operation of e-infrastructure and in application-
driven use cases. This change is also reflected in the UNICORE activities [1].
The basic components and services have been established, and now the focus is
increasingly on enhancement with higher level services, integration of upcoming
standards, deployment in e-infrastructures, setup of interoperability use cases
and integration of applications.
The development of UNICORE started back more than 10 years ago, when in
1996 users, supercomputer centres and vendors were discussing ”what prevents
the efficient use of distributed supercomputers?”. The result of this discus-
sion was a consensus which still guides UNICORE today: seamless, secure and
intuitive access to distributed resources.
Since the end of 2002 continuous development of UNICORE took place in
several EU-funded projects, with the subsequent broadening of the UNICORE
community to participants from across Europe. In 2004 the UNICORE software
became open source and since then UNICORE is developed within the open
source developer community. Publishing UNICORE as open source under BSD
license has promoted a major uptake in the community with contributions from
multiple organisations. Today the developer community includes developers
from Germany, Poland, Italy, UK, Russia and other countries.
The structure of the paper is as follows. In Section 2 the architecture of
UNICORE 6 as well as implemented standards are described, while Section 3
focusses on its clients. Section 4 covers recent developments and advancements
of UNICORE 6, while in section 5 an outlook on future planned developments
is given. The paper closes with a conclusion.
11
12
Chapter 2
Architecture and Standards
The architecture of UNICORE 6 is three-layered in client layer, service layer
and system layer as shown in Fig. 2.1.
2.1 Client Layer
On the top layer a variety of clients are available to the users, ranging from
graphical clients such as the Eclipse-based URC, a command-line interface
named UCC to a programming API named HiLA. For more details on these
clients see Section 3. For a tight integration of various types of applications,
the GridBean concept [2] was invented, which offers an API to easily imple-
mented graphical client extensions and connect them with UNICORE 6’s core
functionalities (cf. Section 4.6 for a few GridBean examples).
2.2 Service Layer
The middle layer comprises all services and components of the UNICORE
Service-Oriented Architecture (SOA). Figure 2.1 shows three sets of services,
the left and right one containing services at a single site while the middle shows
the central services, such as the central registry, the workflow services and the
information service, which serve all sites and users in a UNICORE Grid. The
Gateway component [3] acts as the entry point to a UNICORE site and per-
forms the authentication of all incoming requests. It is used for both the central
services and the single site services. The XNJS component [4] is the job man-
agement and execution engine of UNICORE 6. It performs the job incarnation,
namely the mapping of the abstract job description to the concrete job descrip-
tion for a specific resource according to the rules stored in the IDB (Incarnation
Database). The functionality of the XNJS is accessible via two service inter-
faces in UNICORE 6’s WS-RF hosting environment. UNICORE 6’s proprietary
interface is called UAS (UNICORE Atomic Services) [2] and offers the full func-
tionality to higher level services, clients and users. In addition to the UAS,
a standardised set of interfaces based on open, common standards is available
(depicted as ”OGSA-*” in Figure 2.1).
For authorisation of users the XNJS uses the XUUDB user database to
perform the mapping from X.509 certificates to the actual users’ logins. The
13
Figure 2.1: UNICORE 6 architecture
XUUDB component is a Web service in itself, which allows it to be used from
multiple UNICORE installations, e.g. within the same computing centre. Like
in many service-oriented environments, a central service registry is available,
where the different services can register once they are started. The central
service registry is necessary to build-up and operate a distributed UNICORE
infrastructure. This service registry is contacted by the clients in order to ”con-
nect to the Grid”. An infrastructure may have multiple central registries. From
the beginning, workflow support is of major importance for UNICORE. The two
layered design with a separation of the workflow engine and the service orches-
trator was primarily done for better scalability, but also offers the possibility to
plug-in domain-specific workflow languages and workflow engines. The work-
flow engine originates from the EU-project Chemomentum [5]. Besides simple
job-chains, while- and for-loops, workflow variables and conditional execution
are supported. The service orchestrator deals with brokering the execution,
monitoring of the workflow and its respective parts as well as provides call-back
mechanisms to the workflow engine. The resource brokering is performed via
pluggable strategies. More details are found in [5]. The workflow capabilities are
offered to the users on the client layer via the URC. Furthermore, the definition,
submission, monitoring and control of workflows is also possible from the UCC.
A Tracing Service collects runtime information from the workflow system, and
allows generating performance metrics. End users can use the tracer service to
visualise the execution of a complex workflow from within the URC.
14
2.3 System Layer
On the bottom layer the TSI (Target System Interface) component is the inter-
face between UNICORE and the individual resource management/batch system
and operating system of a Grid resource. In the TSI component the abstracted
commands from the Grid layer are translated to system-specific commands, e.g.
in the case of job submission, the specific commands like llsubmit or qsub of
the resource management system are called. The TSI component is performing
the proper setting of users’ UID and invocation of his/her environment. There-
fore the TSI component needs to be executed with root privileges. All other
UNICORE 6 components at a site are executed under a standard user account,
preferably a dedicated, UNICORE-related account. The TSI is available for
a variety of commonly used batch systems such as Torque, LoadLeveler, LSF,
SLURM, OpenCCS, etc. The USpace is UNICORE’s job directory. A separate
directory exists for every job, where the XNJS and TSI store all input data and
where all output including stdout and stderr is written to. The TSI also allows
access to local filesystems such as the user’s Home directory. These are called
UNICORE Storages and can be used in stage-in and stage-out operations.
2.4 Standards
Common open standards are of major importance to realise interoperable world-
wide Grid infrastructures in order to satisfy scientists that require resources
in more than one Grid. In order to increase the interoperability with Grid
infrastructures that deploy other middleware solutions, several standards from
the Open Grid Forum and OASIS are used in UNICORE 6 in various domains
(cf. to the boxes on the right in Figure 2.1). A full Web services stack based on
WS-RF 1.2, SOAP, and WS-I is implemented to build UNICORE 6’s service-
oriented architecture.
In security, full X.509 certificates are used as base line, while the access
control is based on XACML policies. A support for SAML-based VOMS (virtual
organisation management service) [6] is available as well as support for proxy
certificates. Apart from standards in the area of security, standards play also
a significant role in the area of information. In that context, the information
service of UNICORE 6 named as CIS (Common Information Service) [7] is
based on the GLUE 2.0 [8] information model and thus allows for a standardised
way of exposing computational resources. It gathers both static and dynamic
information from all connected XNJSs, which are then displayed either in raw
XML or human-readable text form. As longitude and latitude information is
also stored, a Google maps view illustrates a geographical representation of the
Grid infrastructure. For job management, OGSA-BES [9] and several profiles
(i.e. HPC-BP [10], HPC-FSP [11]) are used for the creation, monitoring and
control of jobs, including data-staging, whilst job definition is compliant with
the JSDL standard [12] and its profiles. In the area of data management and
transfer, OGSA-ByteIO can be used for data transfer, both for site-to-site and
client-to-site transfers [13]. For a transfer of data from and to external storage,
15
the GridFTP [14] transfer protocol can be used as an alternative to the default
HTTP based mechanism. On the system layer a TSI version for the DRMAA
standard [15] is available enabling a standardised interface between the TSI and
the batch system.
16
Chapter 3
Using UNICORE
In the following we will describe UNICORE’s core clients; namely the Eclipse-
based graphical URC, the command-line client UCC as well as the programming
API HiLA.
3.1 Eclipse-based URC
Since the beginning, UNICORE has offered graphical clients realising UNI-
CORE’s baseline slogan by providing seamless, secure and intuitive access to
Grid resources. Today the Eclipse-based UNICORE Rich Client (URC) [16],
shown in Figure 3.1, constitutes the most complete implementation of this idea.
Basing the major UNICORE client on the Eclipse rich client platform [17]
comes with several benefits. First of all, Eclipse is widely known and commonly
used due to its well designed and flexible graphical interfaces. This lowers
the entry barrier for new users, as many of them are already familiar with the
tool. Furthermore, although being written in Java, an Eclipse-based application
contains some platform specific code. Through this approach, it looks just like a
native application with a smoother integration into different platforms. Finally,
the Eclipse platform has a very sophisticated plug-in mechanism: every software
component in an Eclipse-based client is a plug-in, each of which adding a well-
defined range of functions. Plug-ins interact with each other in various ways
and almost every plug-in provides programming interfaces which can be used
to extend its functionality and outer appearance. Following this paradigm, the
URC is extremely extensible. For instance, integration of new Grid services or
scientific applications is already accounted for in its design.
This client targets a wide range of users with varying Grid and IT experi-
ence. It provides a useful graphical view of the Grid, which can be filtered in
order to find specific resources, services or files. As one of its main tasks, it
can be used to submit computational jobs to Grid resources. To this end, small
software packages provide tailored graphical user interfaces for many scientific
applications available on the Grid. The same packages are responsible for visu-
alising the output data of scientific simulations once the jobs have been executed
and output files have been downloaded to the client machine. Detailed resource
requirements for jobs (e.g. required number of CPUs, amount of RAM) can be
17
Figure 3.1: The UNICORE Rich Client (URC)
specified. Users are enabled to design complex scientific workflows that combine
several applications to automate the completion of difficult tasks. To this end,
a fully-fledged workflow editor is provided. It allows for graphical programming
where building blocks like loops or if-statements can be arranged with just a
few mouse clicks. As security and access control are essential aspects in dis-
tributed computing, dedicated panels deal with setting up security options so
that users can specify whom they trust and how to identify themselves on the
Grid. Experienced users can perform various administrative tasks on the Grid
by accessing specific parts of the user interface.
3.2 Command-line client UCC
The UNICORE Commandline Client (UCC) [18] is a versatile command-line
tool that allows users to access all features of the UNICORE service layer in
a shell or scripting environment (cf. Figure 3.2 for an overview of available
commands). It allows to run jobs, monitor their status and retrieve generated
output, both in single job mode or in a powerful and flexible batch mode for
multiple jobs; workflows can be submitted and controlled as well. Additionally,
UCC includes several data management functions. Remote storages can be
listed and files can be transferred from local to remote and vice versa as well as
from server to server. UCC can be used for administrative purposes as well, for
example to list jobs, or to perform some clean-up. An important feature of UCC
is its extensibility. New commands can easily be added, and the run-groovy
18
command allows the execution of scripts written in the Groovy programming
language which can access a variety of UNICORE-internal functions for more
flexibility. A dedicated UCC mode for the popular Emacs editor is also available.
Figure 3.2: Available Commands of the UNICORE Commandline Client (UCC)
3.3 Programming API HiLA
HiLA is a High Level API for Grid Applications [19], which allows simple devel-
opment of clients with just a few lines of code for otherwise complex functional-
ity. It provides a single interface with multiple implementations for UNICORE
5, UNICORE 6 and OGSA-BES. HiLA was mainly developed in the EU-funded
DEISA [20] and A-WARE [21] projects. It is used to integrate UNICORE 6
access into DESHL [22] (including SAGA [23] support) as part of the DEISA
portal, and to connect GAT [43] with UNICORE 6 (cf. Section 4.5. The na-
ture of the HiLA API leads to a concise coding toolkit for building collective
tier Grid services and client interfaces. Following the UNICORE principle of
seamlessness, the design of the API models the Grid through an object-oriented
fa¸cade, presenting abstract representations of the underlying resources. Impor-
tantly, this includes encapsulating security configuration behind well defined
interfaces, further enhancing the API.
In HiLA resources of the Grid are named following a URI naming scheme, e.g.
unicore6://sites/GROW/tasks/910c9b56-d97-46af37 for a job or unicore6:
//sites/FZJ_JUGGLE/storages/home for the user’s home directory. The object
navigation is based on a container/item model, navigation of locatable resources
19
is done generically. Types of objects referenced by locations can be inferred
and thus it is possible to call object specific operations such as status() or
getOutcomeFiles() on jobs. HiLA is currently evolving further to allow it to
operate concurrently over multiple resources to perform powerful collective data
management and monitoring.
Listing 3.1: The HILA API
Location l = new Location (
" unicore6 :// sites /GROW / tasks /910 c9b56 -d97 -46 af37 " );
Task t = HiLAF actor y . getIn stanc e (). locate ( l);
assertTrue ( T askStat us . RUNNING , t. status ());
List < File > fl = t. get Outc ome Fil es ();
As can be seen in Listing 3.1, the resources of the Grid are named following
a URI naming scheme, another example for a storage resource representing the
user’s home directory would be unicore6://sites/FZJ_JUGGLE/storages/home.
The Listing also shows that the object navigation is based on a container/item
model, navigation of locatable resources is done generically. Types of objects
referenced by locations can be inferred and thus it is possible to call object
specific operations such as status() or getOutcomeFiles() on jobs. HiLA
is currently evolving further to allow it to operate concurrently over multiple
resources to perform powerful collective data management and monitoring.
20
Chapter 4
Recent Developments
In the following section, recent developments are reported one by one, that
enhance the functionalities of UNICORE 6. They were done in the context of
various projects and by different teams.
4.1 Virtual Organisation Management
The UNICORE Virtual Organizations System (UVOS) [25] was created in course
of the EU-funded Chemomentum project [5]. However due to its openness and
standards-compliance UVOS can be used with other Grid middlewares, too.
UVOS communicates with other Grid components using standard protocols and
provides tools and features which will make it useful in both OGSA (so SOA)
and WWW environments.
A key element of UVOS is the central server which acts both as authenti-
cation service and attribute authority. It is used by two kinds of clients: con-
sumers and management clients. Consumers do not modify the UVOS content
but query it. The modification of the VO data can be performed using manage-
ment clients: graphical and command line. The UVOS system is highly portable
and all UVOS server operations are available via the web services interface. The
UVOS consumers use open standard SAML 2.0 as a communication protocol
and the server implements core SAML specification together with additional
profiles:
XACML Attribute Profile [26]
SAML Attribute Query Deployment Profile for X.509 Subjects [27]
SAML Attribute Self-Query Deployment Profile for X.509 Subjects [27]
OGSA Attribute Exchange Profile Version 1.2 [28]
UVOS organises VO members within a hierarchical group structure. Top
level groups of this structure are called virtual organisations. The virtual organ-
isations are however not different than other groups therefore group membership
is inherited in UVOS: members of a subgroup automatically become members of
the parent group. Group members may have assigned a set of attributes. A sin-
gle entity can possess multiple representations, for example in different formats.
21
These equivalent incarnations of the same entity are called identities and are
usually invisible for an outside user. Every entity has a unique label and one or
more tokens that represent it. Tokens must be in one of the supported formats,
which currently are: a full X.509 certificate, an X.500 distinguished name, or an
e-mail address with an password used for authentication. A token along with
its type is called an identity. All of the identities that compose an entity shar-
ing the same characteristics (attributes, group membership, permissions, etc.).
UVOS internally uses entities.
UVOS provides two management clients: the command line client (UVOS
CLC) and VO Manager. The UVOS VO Manager is a powerful GUI application
based on the Eclipse Rich Client platform like the URC and offers an intuitive
interface to create and handle users related information.
4.2 Shibboleth Integration in URC
This section describes the approach how Shibboleth [29] and advanced autho-
risation technologies such as SAML2 [30] and XACML [31] are combined to
achieve Single Sign-On (SSO) among multiple UNICORE 6 Grid sites.
Shibboleth is a standards-based identity management system and an open
source implementation of the SAML2 Web SSO profile [26] aiming to fulfill sin-
gle sign-on across or within organisational boundaries. It consists of three main
components namely the Service Provider (SP), the Identity Provider (IdP) and
the Where-Are-You-From (WAYF) or Discovery Service (DS) which requires
user to authenticate and authorise while using a Web browser. This creates a
mismatch with the UNICORE 6 security model, as in UNICORE 6 the client
usually is a non-Web browser and uses X.509 certificates for user authentication
and SOAP for message exchange, which is not possible by using Shibboleth in
a straight forward manner. Therefore a GridShib-Certificate Authority (CA)
[32] is endorsed as a SP, thus enabling the Shibboleth clients (Web browser)
to retrieve X.509 based Short Lived Grid Credentials (SLC) with embedded
SAML2 assertions on authentication with their IdP; the embedded SAML as-
sertion manifests the subject’s attributes.
Nonetheless, the GridShib-CA does not solve the problem of using Shibbo-
leth with UNICORE 6 as it still restricts the user to use a Web browser to
fetch the user’s SLC. Therefore a client API was developed by extending the
architecture defined in [33], the component is generalised to allow any non-Web
browser client to communicate with a GridShib-CA, as shown in Figure 4.1.
The GUI prototype is developed as an Eclipse-based URC plug-in in order
to facilitate the client to fetch her SLC by inputting the Gridshib-CA URL,
username, and password. The request (besides fetching SLC) from client to the
UNICORE 6 server is bipartite; in the first step it extracts the SAML asser-
tion and public key information from the SLC and then sends the request in
combination with the job submission as a SOAP message with all the identity
information in its headers. On the server side, before the invocation of the Tar-
get System service, the SAML assertion is extracted from the SOAP header and
processed, which requires checking the attributes against UNICORE 6 XACML
policies and XUUDB entries. This process leads to the decision whether the
service access request is denied or granted. The UNICORE 6 authorisation
and authentication framework is inherently based on pluggable mechanism by
22
Figure 4.1: Architecture of bridging Shibboleth and UNICORE 6
using handlers, some of which provide capabilities of handling SAML2 asser-
tions namely SAMLInHandler and SAMLOutHandler as described in [6]. Bridg-
ing Shibboleth and the UNICORE 6 security model enables authentication and
authorisation interoperability with all other middlewares supporting Shibboleth
and GridShib-CA.
4.3 Interactive Access with X.509-based SSH
The key component and warrantor for security on the server side is a SOCKS 5
proxy [34]. It only routes traffic to the standard SSH server, once the connection
has been authenticated using the XUUDB. Thereby X.509-based authentication
with the security level of UNICORE 6 is enabled. After successful authentica-
tion, all traffic from and to a designated SSH Server is routed (delegated) by
the SOCKS 5 proxy component.
On the client side, the URC realises the interaction with the SOCKS Proxy
and establishes the actual SSH connection. For this purpose, the URC is ex-
tended with Eclipse plug-ins, which provide terminal emulation and SSH com-
munication functionality. The URC is extended with Eclipse plug-ins, which
provide a terminal emulation and SSH communication functionality. The ter-
minal plug-in is based on the terminal emulation software from the gEclipse
project [35]. It offers a standard VT100 emulation, which allows the display of
graphical output from programs using the curses library.
The plug-ins have been designed in an extensible way, so that different com-
munication providers (apart from the X.509-enabled and SOCKS 5 based ap-
23
proach) can be plugged in. These communication providers are likewise imple-
mented as Eclipse plug-ins which encapsulate the connection and communica-
tion logic and extend the functionality of the terminal plug-in. It is important
to note that the X.509 based SOCKS communication provider connects to the
SOCKS 5 proxy server with the users certificate, which is available within the
keystore of the URC, and provides terminal access to a specific target site with-
out any further password input.
Currently, three different communication providers have been implemented:
the X.509 enabled and SOCKS 5 based SSH solution, GSI-SSH known from the
Globus Toolkit [36], and standard plain SSH with password. The latter plug-
in could in principle also be used without UNICORE 6 in any other Eclipse
framework.
4.4 DataFinder Integration
The amount of data handled by applications is ever growing and data retrieval
for later use becomes a serious problem. The level of support for data manage-
ment is very different in current systems for resource management (UNICORE 6,
Globus Toolkit, gLite) and distributed data management (dCache [37], Storage
Resource Broker [38], Integrated Rule-Oriented Data System [39], Chemomen-
tum [5], and DataFinder [40]).
Most of the considered systems support a kind of storage virtualisation. Ad-
ditionally, some systems provide metadata management functionalities allowing
simple annotations on data objects which are achieved using a metadata cata-
log. Unfortunately, further means regarding data organisation are missing. An
exception from that rule are the data-related services developed in the Chemo-
mentum project [5] and the DataFinder [40] system which are providing sophis-
ticated means for data organisation. Here it has been decided to use DataFinder
as basis for a dedicated data management system as it offers required means
for data organisation and its productive use in various scenarios at the German
Aerospace Centre provides a good basis demonstrating and investigating the
system.
The developed data management system [41] delivers logical organisation
of data objects and abstracts common data management concepts hiding the
specifics of storage systems. On this basis advanced means for data organisa-
tion through metadata management functionalities and support of custom data
models are provided. Moreover, the integration with UNICORE 6 is achieved by
the data management client API which has been integrated in the UNICORE
Rich Client. The developed system and its compatibility with DataFinder have
been successfully validated in the project AeroGrid [42].
4.5 Java-GAT
Making applications Grid-aware requires the knowledge of the API of different
Grid middlewares. The complexity of these systems, both in terms of underly-
ing technology and functionality, remains high. The Grid Application Toolkit
(GAT) [43], a high-level API for accessing Grid services, provides application
developers with a unified, simple and middleware-independent interface to the
24
Grid. It allows developers to easily include Grid functionality in application
codes. This is performed by writing plug-ins for the different Grid middlewares.
The GAT architecture is divided to two parts: GAT engine and GAT adap-
tors (Figure 4.2). The GAT-API delivers the commands to the GAT engine
which selects a GAT adaptor. An adaptor converts a file copy or job submis-
sion statement written in the GAT-API into a corresponding statement of a
Grid middleware. GAT uses the first adaptor which does not fail but it is also
possible to force usage of selected adaptors.
Figure 4.2: JavaGAT software architecture.
GAT has first been implemented in C within the European project GridLab
[44]; the development of the Java version of GAT (JavaGAT) has also been
started during the GridLab project. The C Implementation comes with a C++
and a Python wrapper. While C-GAT is out of support, JavaGAT is still main-
tained by the Free University of Amsterdam, and JavaGAT is used within the
project AeroGrid [42]. One of the major advantages of JavaGAT compared to
C-GAT is that JavaGAT enables the Grid access without an additional instal-
lation of a Grid middleware.
The UNICORE adaptor for JavaGAT [45] has been implemented recently
within the scope of the D-Grid project DGI2-FG1 [46]. The implementation is
based on HiLA [19] (cf. Section 3.3) as it supports the access to UNICORE 6 via
an easy and unique API. Furthermore it is not necessary to install components
of UNICORE on the submitting host.
4.6 Application Support through GridBeans
Application support in the URC is realised by the GridBean concept [47]. It
is a plug-in technology that allows to create and configure an application Grid
job via feature rich interfaces, so called GridBeans, that represent the appli-
cation’s behaviour. Each GridBean consists of a GridBean model and one or
more graphical panels. The GridBean model stores the application parameters
25
and represents an abstract Grid job description. The panels provide graphical
components for the preparation and validation of user input. The URC itself
contains a set of standard panels for each GridBean. These include a file panel to
define input and output files, a resource panel to specify resource requirements,
and a variables panel to set environment variables. In addition, GridBeans can
provide own panels in order to set application specific parameters and files as
well as to monitor application behaviour, or to visualise output results, e.g. to
represent a molecular 3D structure or to display various statistics over time.
The advantage of the GridBean technology is that GridBeans can be easily
developed and independently distributed to the users. The URC distribution
package contains by default the Script GridBean, shown at the left hand site of
Figure 4.3, which provides an interface for editing and submitting any kind of
scripts and the new Generic GridBean, which offers generic panel elements for
individually configuring and submitting any application installed on the target
system. Furthermore, several GridBeans were developed for specific scientific
applications, e.g. for molecular dynamics simulations packages Gaussian [48]
and AMBER [49].
Figure 4.3: The left screenshot shows the standard Script GridBean, to submit
any kind of scripts. The middle screenshot shows the Gaussian GridBean, and
the right screenshot shows the AMBER GridBean.
The AMBER GridBean was established within a new GridBean concept, the
sequence GridBeans [50]. This concept was developed to manage applications,
which consist of a set of programs that require to be executed in a sequence one
program after another on the same target system. As the molecular dynamic
simulation package AMBER consists of approximate 50 programs, and for one
molecular simulation a sequence of different programs is required, the AMBER
GridBean was realised by usage of this new sequence concept. This provides a
sequence framework, which we extended with GridBean models, one for each
26
required program. These extensions are managed and organised by the frame-
work. Moreover, the framework also provides an automatic build of graphical
interfaces for sequence of programs and for each program itself, in order to
reduce the developers efforts in supporting new applications. The automated
GUI, as shown at the right hand site of Figure 4.3, allows for designing the
sequence and setting up the inputs and parameters for the individual programs
without being familiar with the application batch system commands.
The Gaussian GridBean assists a user with the preparation of the input
for submission to Gaussian quantum chemistry program. Gaussian98 and it’s
latest version Gaussian09 is designed to predict energies, molecular structures,
vibrational frequencies and numerous molecular properties for a broad range
of molecular systems in the gas phase and in solution, and it can model both
their ground state and excited states. The Gaussian GridBean makes preparing
complex input easy for many types of Gaussian calculations. It displays the
availability of Gaussian and it’s versions on remote systems and allows a user to
generate the input parameters automatically without necessity to know of the
internal format of the input file. In addition, it allows to set up environment
variables, e.g. in order to indicate the locations of the scratch files on a remote
system. The user input and specific resource settings will be verified to check
correctness of a job setting before a job can be submitted to a remote system.
4.7 Monitoring of UNICORE 6 Services in
Operation
Running Grid middleware on distributed systems always means running a quite
complex infrastructure. The more systems are connected in the Grid the more
complex the installation will get. The users of the Grid require 24/7 availability
of the services they need. Hence the administrator’s goal should be to get infor-
mation about any problems before the user runs into problems. Therefore, it is
essential to have efficient monitoring tools for the respective Grid middleware.
For UNICORE 6 a tool called SIMON 6 has been developed to check for
the health status of every UNICORE 6 component. Besides easy installation
and configuration, a central design requirement for SIMON 6 was to check not
only the availability of the UNICORE 6 services but also their functionality.
A service which is available in the process list does not necessarily deliver the
expected functionality.
To be able to check both availability and functionality at the same time,
SIMON 6 uses the UNICORE 6 internal job description. The jobs are submitted
via the UCC into the UNICORE 6 Grid isochronously and automatically.
The SIMON 6 concept design is shown in Figure 4.4: The availability and
functionality tests are submitted into the UNICORE infrastructure using the
Gateway as the entry point. All UNICORE 6 components (registry, workflow
engine, XNJS, XUUDB and TSI) are monitored one after the other, and af-
terwards the results come back to SIMON 6 again. If any problem with the
UNICORE 6 components occur, the administrator will be informed by email or
a short text message to his/her mobile phone.
27
Figure 4.4: SIMON 6 concept design
4.8 Remote administration of UNICORE 6
The decentralised topology and distributed operation of a Grid make a strong
case for remote administration capabilities of crucial Grid components. UNI-
CORE 6 is being enhanced by different mechanisms to address those needs.
4.8.1 Dynamic Service Deployment
Given the fact that UNICORE 6 exposes its services as Web services, service
administration (installation and removal) plays a crucial role in maintaining
administrative flexibility. However, until recently, installing a new Web service
to a UNICORE 6 server had been a manual process requiring a restart, thus
interrupting the availability of the services. The conflict between flexibility and
availability has been resolved by extending UNICORE 6 with dynamic deploy-
ment capabilities allowing for installation and removal of services at runtime.
These capabilities have been integrated into the underlying Web service frame-
work of UNICORE 6 by developing a dedicated deployment manager that takes
a JAR (Java archive) file containing the Web service classes, creates a class
loader for this Web service to load its classes, deploys the Web service and
modifies the service configuration.
There are two ways to dynamically deploy UNICORE 6 services. Either
via an administration Web service interface, which can be toggled at runtime,
allowing a local administrator to overrule a remote one. Or on the file system
level by copying (either locally or remotely) a Web service JAR into a specified
directory triggering an automatic automatic deployment task. This scenario
requires the JAR file to contain deployment-specific metadata that can be sup-
plied within the JAR manifest (a simple text file) or as a Java annotation in
the Web service interface class.
4.8.2 AdminService An Administration Web Service
Facade
The AdminService is a Web service tailored to administrative functionality. In
its current shape, it provides means for:
28
(un)deploying UNICORE 6 services
(de)activating dynamic and automatic deployment of UNICORE 6 services
creating/inspecting/deleting/terminating UNICORE 6 service resources
listing available UNICORE 6 services and UNICORE 6 service resources
getting/setting UNICORE 6 configuration properties
retrieving mutual dependencies among UNICORE 6 services (dependen-
cies have to be annotated on service source code level)
In addition the AdminService logs all its actions and outcomes (success or
failure and cause) in a retrievable manner. Since there might be scenarios in
which remote administrators shouldn’t be privy to all UNICORE 6 configura-
tion properties (e.g. keystore and database passwords), local administrators
must explicitly enable remote access (either ’read’ or ’read-write’). Addition-
ally, a mechanism has been added to allow local administrators to set UNICORE
configuration properties at runtime without having to use an application pro-
gramming interface as well as to overrule remote administrators. Essentially
it is a periodically parsed configuration file containing key-value pairs denoting
UNICORE 6 system properties with corresponding values.
4.9 New Workflow Constructs for-each-loop
The UNICORE workflow system offers basic workflow constructs like while-
loops for repeating certain tasks automatically and if-statements for altering
the flow of execution based on the evaluation of conditions. These constructs
can also be nested in order to address more complex tasks. In addition, the
system supports the parallel execution of many similar jobs or sub-workflows
by introducing the for-each-loop. This powerful construct helps to minimise the
effort of creating workflows with many jobs and reduce the size of the resulting
workflow descriptions. There are numerous usage scenarios where extensive
parallel job processing is desired and for-each-loops can be applied. For covering
these scenarios, the for-each-loop offers two different modes of operation.
The first mode provides means to iterate over sets of differing parameter
values. To this end, the user can declare one or more workflow variables. For
each of these variables, he/she may then specify a set of possible values to iterate
over. This is done by setting an initial variable value, a modifier expression that
is used to alter the value from one iteration to the next, and an exit condition
that defines the last value in the set. The variables can be referred to within
the body of the for-each-loop (the loop body is a simple container that can hold
jobs or sub-workflows). The most common use case for this mode would take
the declared variables as input parameters for jobs in the loop body. If multiple
variables are declared, all combinations of possible values for the variables are
generated and sweeped.
The second operational mode of the for-each-loop helps to iterate over a set
of files. The user may specify any number of files he/she wishes to include in
the set. Each iteration in this mode will then deal with one of the declared
files, e.g. by importing it into the working directory of a job and processing it
29
with an application program. The files in the set can be located in different
places (e.g. on the client computer, on UNICORE 6 storages, on FTP servers,
etc.) and the file addresses may contain wildcards if the files’ source locations
support this. Since the number of files or variable values to iterate over can be
very large, the user may limit the amount of iterations that should be processed
in parallel in order to keep congestion of the Grid reasonable.
30
Chapter 5
Future Developments
5.1 Execution Environments
Scientific applications require different execution environments on computing
resource, e.g. a parallel MPI execution. These environments are mostly defined
by the execution mode as well as its specific parameters and variables. Since
UNICORE 6 users want to work in different execution environments, the usage
of different and configurable execution environments should be ensured in Grid
infrastructures. To facilitate this, a new design concept is developed to sup-
port the execution of applications in different execution environments within
UNICORE 6. This new development provides a powerful and easy to use con-
figuration mechanism in the URC. In detail, a new section in the URC resource
panel, to set the execution environment will be added. It will allow for mod-
ifying parameters as well as variables, and provides an immediate validation
of those. All available execution environments, their parameters, variables and
validators of a specific system are described by the system administrator in the
XNJS and its IDB. These descriptions are exported by the URC and are auto-
matically graphically displayed in the new section of the resource panel, to be
configured by the user.
To sum up, this new execution environment concept, will provide users with
additional options for easier and more precise definition of their application
execution on the Grid.
5.2 Licence Management
5.2.1 Current Situation
The currently existing licensing models for commercial applications are focussing
on software used on compute resources within an administrative domain. Li-
censes are provided on the basis of named users, hostnames, or sometimes as a
site license for the administrative domain of an organisation. These licensing
models make it almost impossible to run license protected applications in a dis-
tributed service oriented infrastructure, because the licenses are usually bound
to hardware within the domain of the user and do not allow access from the
outside thus enforcing local use of the protected applications only.
31
Grid environments are usually spread across multiple organisations and their
administrative domains, and virtualised infrastructures, like utility and cloud
computing, hide the underlying hardware and their performance indicators, e.g.
CPU type and frequency, that are often used in license agreements. While
current mechanisms limit the usage of licensed software in Grid environments
and virtualised infrastructures, the changing paradigms of IT infrastructures
towards usage of virtualised environments and infrastructures make overcoming
these limitations vital.
5.2.2 SmartLM Solution
The SmartLM solution [51] is a generic and flexible licensing virtualisation tech-
nology based on standards for new service-oriented business models. The solu-
tion implements software licenses as Grid services, providing platform-indepen-
dent access just like other Grid resources and being accessible from resources
outside organisational boundaries. This enables users to execute license pro-
tected applications on all compute resources within a UNICORE operated Grid
infrastructure.
In order to overcome the limitations of the current monolithic licensing
model, licenses are reformulated as manageable Grid resources or even Grid
services using Service Level Agreements (SLAs) based on the WS-Agreement
specification [52]. Secure agreements are used to transport licenses through the
Grid and to make them available on the resource to which a user has been
granted access for the execution of the application. The license agreement and
conditions of use for an application are reached through negotiation between
service providers and service customers. Thus, allowing managing and orches-
trating licenses in a job or workflow together with other resources like compute
nodes, data storage, and network Quality of Service (QoS). The solution is cur-
rently being integrated into the major Grid middleware UNICORE and Globus.
New service-oriented business models for this approach have been identified and
a number of widely-used license-protected commercial applications are currently
adapted to be executed under control of the new licensing mechanisms and will
become part of a high quality show-case to convince more ISVs to adapt their
applications.
5.3 Enhanced Remote Administrative Tools
Apart from recent remote administration extensions (cf. to Section 4.8), there
are additional ones still under development, both on the client and service lay-
ers. On the server-side, the AdminService is in the process of being extended
with mechanisms allowing for remote and dynamic modification of the UNI-
CORE 6 access policy, thus further enhancing administrative flexibility. Cur-
rently, the URC is being extended with an administration view that will expose
AdminService operations in an intuitive way, allowing for prompt and remote
administrative reactions at runtime.
32
Chapter 6
Summary
In this paper we presented recent and future advancements of the UNICORE
Grid technology. UNICORE has a three layered architecture with client, service
and system layer. The three available clients graphical, command-line and
API allow to submit jobs and workflows satisfying the users’ requirements
and favourite working styles. Several standards from the Web services and Grid
domain are implemented in UNICORE 6 so that standards-based interfaces are
offered. This makes UNICORE 6 an ideal Grid middleware to be used for
interoperability of Grid e-infrastructures worldwide.
Recent functional additions to UNICORE 6 contain a support for VOs and
Shibboleth in the security domain, an interactive access based on X.509 certifi-
cates and the integration of the DataFinder for improved data management. The
support for applications from users is improved through new application-specific
GridBeans and the implementation of JavaGAT as a new client to UNICORE.
In addition new workflow constructs to allow for-each-loops and an iteration
over file-sets was added. To improve the operational aspects of UNICORE 6 a
new monitoring tool was developed, which allows to monitor both the availabil-
ity and functionality of UNICORE 6 services. Furthermore the administration
capabilities of UNICORE 6 were enhanced with a dynamic service deployment
technology.
Future advancements of UNICORE 6 contains improved Execution Envi-
ronments to e.g. specify in a more intuitive way the parameters and variables
of MPI jobs. Furthermore license management solutions will be developed and
integrated with UNICORE 6, that address the usage of licenses in distributed
environments across multiple administrative domains. Finally enhanced remote
administration tools will be added to UNICORE 6. This will enable a further
uptake of UNICORE 6 both in the academic and commercial domain.
33
34
Bibliography
[1] A. Streit, D. Erwin, Th. Lippert, D. Mallmann, R. Menday, M. Rambadt,
M. Riedel, M. Romberg, B. Schuller, and Ph. Wieder: UNICORE From
Project Results to Production Grids. L. Grandinetti (Edt.), Grid Computing:
The New Frontiers of High Performance Processing, Advances in Parallel
Computing 14, Elsevier, 2005, pp. 357 376
[2] M. Riedel, B. Schuller, D. Mallmann, R. Menday, A. Streit, B. Tweddell,
M.S. Memon, A.S. Memon, B. Demuth, Th. Lippert, D. Snelling, S. van den
Berghe, V. Li, M. Drescher, A. Geiger, G. Ohme, K. Benedyczak, P. Bala,
R. Ratering, and A. Lukichev: Web Services Interfaces and Open Standards
Integration into the European UNICORE 6 Grid Middleware. Proceedings
of 2007 Middleware for Web Services (MWS 2007) Workshop at 11th Inter-
national IEEE EDOC Conference ”The Enterprise Computing Conference”,
2007, Annapolis, Maryland, USA, IEEE Computer Society, ISBN 978-0-7695-
3338-4, pp. 57 60
[3] R. Menday: The Web Services Architecture and the UNICORE Gateway.
Proceedings of International Conference on Internet and Web Applications
and Services (ICIW 2006), Guadeloupe, French Caribbean, 2006, IEEE Com-
puter Society Press, p. 134
[4] B. Schuller, R. Menday, and A. Streit: A Versatile Execution Management
System for Next-Generation UNICORE Grids. In Proc. of 2nd UNICORE
Summit 2006 in conjunction with EuroPar 2006, Dresden, Germany, LNCS
4375, Springer, pp. 195 204
[5] B. Schuller, B. Demuth, H. Mix, K. Rasch, M. Romberg, S. Sild, U. Maran,
P. Bala, E. del Grosso, M. Casalegno, N. Piclin, M. Pintore, W. Sudholt,
and K.K. Baldridge: Chemomentum UNICORE 6 based infrastructure for
complex applications in science and technology. Proceedings of 3rd UNICORE
Summit 2007 in Springer LNCS 4854, Euro-Par 2007 Workshops: Parallel
Processing, pp. 82 93
[6] V. Venturi, M. Riedel, A.S. Memon, M.S. Memon, F. Stagni, B. Schuller,
D. Mallmann, B. Tweddell, A. Gianoli, V. Ciaschini, S. van de Berghe, D.
Snelling, and A. Streit: Using SAML-based VOMS for Authorization within
Web Services-based UNICORE Grids. Proceedings of 3rd UNICORE Summit
2007 in Springer LNCS 4854, Euro-Par 2007 Workshops: Parallel Processing,
pp. 112 120
35
[7] A.S. Memon, M.S. Memon, Ph. Wieder, and B. Schuller: CIS: An Informa-
tion Service based on the Common Information Model. Proceedings of 3rd
IEEE International Conference on e-Science and Grid Computing, Bangalore,
India, December, 2007, IEEE Computer Society, ISBN 0-7695-3064-8, pp. 465
472
[8] S. Andreozzi et.al. GLUE Specification v. 2.0, OGF Grid Final Document
(GFD) #147, http://www.ogf.org/documents/GFD.147.pdf
[9] I. Foster et.al. OGSA Basic Execution Service Version 1.0, OGF Grid Final
Document (GFD) #108, http://www.ogf.org/documents/GFD.108.pdf
[10] B. Dillaway et.al. HPC Basic Profile, Version 1.0, OGF Grid Final Docu-
ment (GFD) #114, http://www.ogf.org/documents/GFD.114.pdf
[11] G. Wasson et.al. HPC File Staging Profile, Version 1.0, OGF Grid Final
Document (GFD) #135, www.ogf.org/documents/GFD.135.pdf
[12] M. Marzolla, P. Andreetto, V. Venturi, A. Ferraro, A.S. Memon, M.S.
Memon, B. Twedell, M. Riedel, D. Mallmann, A. Streit, S. van de Berghe,
V., Li, D. Snelling, K. Stamou, Z.A. Shah, and F. Hedman: Open Standards-
based Interoperability of Job Submission and Management Interfaces across
the Grid Middleware Platforms gLite and UNICORE. Proceedings of Inter-
national Interoperability and Interoperation Workshop (IGIIW) 2007 at 3rd
IEEE International Conference on e-Science and Grid Computing, Bangalore,
India, December, 2007, IEEE Computer Society, ISBN 0-7695-3064-8, pp. 592
599
[13] M. Morgan et.al. OGSA ByteIO Specification, OGF Grid Final Document
(GFD) #87, http://www.ogf.org/documents/GFD.87.pdf
[14] Grid Ecosystem GridFTP,
http://www.globus.org/grid software/data/gridftp.php
[15] M. Riedel, R. Menday, A. Streit, and P. Bala: A DRMAA-based Tar-
get System Interface Framework for UNICORE. Proceedings of Second In-
ternational Workshop on Scheduling and Resource Management for Parallel
and Distributed Systems (SRMPDS’06) at Twelfth International Conference
on Parallel and Distributed Systems (ICPADS’06), Minneapolis, USA, IEEE
Computer Society Press, pp. 133 138
[16] Eclipse-based UNICORE Rich Client (URC),
http://www.unicore.eu/download/unicore6/
[17] Eclipse, http://www.eclipse.org/
[18] UNICORE Command-line Client (UCC),
http://www.unicore.eu/documentation/manu-als/unicore6/ucc,
download: http://www.unicore.eu/download/unicore6/
[19] HiLA 1.0,
http://www.unicore.eu/community/development/hila-reference.pdf
[20] DEISA Distributed European Infrastructure for Supercomputing Appli-
cations, http://www.deisa.eu/
36
[21] A-WARE project, http://www.a-ware-project.eu/
[22] T.M. Sloan, R. Menday, T. Seed, M. Illingworth, and A.S. Trew: DESHL –
standards-based access to a heterogeneous European supercomputing infras-
tructure. In Proc. 2nd IEEE International Conference on e-Science and Grid
Computing eScience 2006.
[23] S. Jha et.al. A Simple API for Grid Applications (SAGA), OGF Grid Final
Document (GFD) #90, http://www.gridforum.org/documents/GFD.90.pdf
[24] Grid Application Toolkit GridLab Project,
http://www.gridlab.org/WorkPackages/wp-1/documentation.html
[25] The UVOS project, http://uvos.chemomentum.org
[26] J. Hughes et al.: Profiles for the OASIS Security Assertion Markup Lan-
guage (SAML) V2.0, OASIS Standard, 15 March 2005, http://docs.oasis-
open.org/security/saml/v2.0/
[27] T. Scavo: SAML V2.0 Deployment Profiles for X.509 Subjects,
OASIS Committee Specification, 27 March 2008. http://docs.oasis-
open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy-x509-cs-01.pdf
[28] V. Venturi, T. Scavo, D. Chadwick: OGSA Attribute Exchange Profile
Version 1.2. Open Grid Forum, 2007.
[29] Shibboleth, http://shibboleth.internet2.edu
[30] SAML Specifications, http://saml.xml.org
[31] OASIS eXtensible Access Control Markup Language (XACML),
www.oasis-open.org/committees/xacml
[32] T. Barton, J. Basney, T. Freeman, T. Scavo, F. Siebenlist, V. Welch, R.
Ananthakrishnan, B. Baker, M. Goode and K. Keahey: Identity Federation
and Attribute-based Authorization through the Globus Toolkit, Shibboleth,
GridShib, and MyProxy. 5th Annual PKI R&D Workshop, 2006.
[33] A. Faroughi, R. Faroughi, P. Wieder, W. Ziegler: Attributes and VOs:
Extending the UNICORE Authorisation Capabilities. Proceedings of Euro-
Par 2007 Workshops: Parallel Processing, HPPC 2007, UNICORE Summit
2007, and VHPC 2007, Revised Selected Papers, Springer, 2008, LNCS 4854,
ISBN 978-3-540-78472-2, pp. 121 130
[34] SOCKS 5, http://www.rfc-editor.org/rfc/rfc1928.txt
[35] gEclipse Project, http://www.geclipse.eu/
[36] The Globus Alliance, http://www.globus.org/
[37] P. Fuhrmann, V. ulzow: dCache Storage System for the Future. In
Euro-Par 2006 Parallel Processing, Springer, 2006, pp. 1106 1113
[38] C. Baru, R. Moore, A. Rajasekar, M. Wan: The SDSC Storage Resource
Broker. In Proceedings of CASCON, 1998
37
[39] A. Rajasekar, M. Wan, R. Moore, W. Schroeder: A prototype rule-based
distributed data management system. In HPDC workshop on ”Next Genera-
tion Distributed Data Management”, 2006
[40] T. Schlauch, A. Schreiber: Datafinder A Scientific Data Management
Solution. In: Ensuring the Long-Term Preservation and Value Adding to
Scientific and Technical Data, PV 2007, Oberpfaffenhofen, Germany.
[41] UNICORE DataFinder project,
http://tor-2.scai.fraunhofer.de/gf/project/unicoredata/
[42] AeroGrid, http://www.aero-grid.de
[43] G. Allen, K. Davis, T. Dramlitsch, T. Goodale, I. Kelley, G. Lanfermann,
J. Novotny, T. Radke, K. Rasul, M. Russell, E. Seidel, O. Wehrens: The
GridLab Grid Application Toolkit. Proceedings of the 11th IEEE Interna-
tional Symposium on High Performance Distributed Computing (HPDC),
2002, IEEE Computer Society, p. 411
[44] GridLab: A Grid Application Toolkit and Testbed, http://www.gridlab.org
[45] A. Beck-Ratzka, T. Zangerl: GAT beginners guide.
http://www.aei.mpg.de/˜alibeck/documents/gat-usage.pdf
[46] D-Grid: The German Grid Initiative., http://www.d-grid.de
[47] R. Ratering, A. Lukichev, M. Riedel, D. Mallmann, A. Vanni, C. Cacciari,
S. Lanzarini, K. Benedyczak, M. Borcz, R. Kluszcynski, P. Bala, and G.
Ohme. GridBeans: Supporting e-Science and Grid Applications. Second IEEE
International Conference on e-Science and Grid Computing: IEEE Conference
Proceedings, 2006, p. 45
[48] Gaussian, http://www.gaussian.com/
[49] The Amber Molecular Dynamics Package, http://ambermd.org/
[50] S. Holl, M. Riedel, B. Demuth, M. Romberg, A. Streit, V. Kasam: Life Sci-
ence Application Support in an Interoperable E-Science Environment. Pro-
ceedings of IEEE International Symposium of Computer-Based Medical Sys-
tems (CBMS) 2009, to appear
[51] SmartLM project, http://www.smartlm.eu/
[52] A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig,
T. Kakata, J. Pruyne, J. Rofrano, S. Tuecke, M. Xu: Web Ser-
vices Agreement Specification. OGF Grid Final Document (GFD) #107,
http://www.ggf.org/documents/GFD.107.pdf
38
Mitglied der Helmholtz-Gemeinschaft
Jül - 4319
Jülich Supercomputing Centre (JSC)
UNICORE 6 – Recent and Future
Advancements
Achim Streit, Piotr Bala, Alexander Beck-Ratzka,
Krzysztof Benedyczak, Sandra Bergmann, Rebecca Breu,
Jason Milad Daivandy, Bastian Demuth, Anastasia Eifer,
André Giesler, Björn Hagemeier, Sonja Holl,
Valentina Huber, Nadine Lamla, Daniel Mallmann,
Ahmed Shiraz Memon, Mohammad Shahbaz Memon,
Michael Rambadt, Morris Riedel, Mathilde Romberg,
Bernd Schuller, Tobias Schlauch, Andreas Schreiber,
Thomas Soddemann, Wolfgang Ziegler
Jül-4319
Februar 2010
ISSN 0944-2952
... The main contribution of this article is to identify the workflow problems that need to be solved with respect to coupling a glacier continuum model and a discrete element model in an optimized way, in order to elicit corresponding requirements that address -among others -portability, performance improvements, and CPU utilization, and to implement an automated workflow based on the UNICORE (Streit et al., 2010) distributed computing middleware, in particular using the UNICORE workflow management system (Memon et al., 2007). We demonstrate this by combining ice flow modelling and discrete calving into a high-level easy-to-use and performance-optimized scientific workflow. ...
... Hence, it is important to implement the glacier modelling case study with a WMS that provides a rich graphical front-end and simultaneously offers a generic and seamless execution and monitoring of applications on HPC-based infrastructures in particular. Considering this requirement, the glacier model coupling case study is automated via our standards-based workflow management system (Memon et al., 2007), which is a part of the Uniform Interface to Computing Resources (UNICORE) (Streit et al., 2010) distributed computing middleware. It is specifically designed to support HPC applications deployed in a massively parallel environment. ...
... UNICORE (Streit et al., 2010) is a distributed computing middleware that provides abstractions for job submission and management on different kinds of job scheduling systems. Hence, jobs can be submitted to a cluster without needing to know about the internal job scheduling system used by that cluster. ...
Article
Full-text available
Scientific computing applications involving complex simulations and data-intensive processing are often composed of multiple tasks forming a workflow of computing jobs. Scientific communities running such applications on computing resources often find it cumbersome to manage and monitor the execution of these tasks and their associated data. These workflow implementations usually add overhead by introducing unnecessary input/output (I/O) for coupling the models and can lead to sub-optimal CPU utilization. Furthermore, running these workflow implementations in different environments requires significant adaptation efforts, which can hinder the reproducibility of the underlying science. High-level scientific workflow management systems (WMS) can be used to automate and simplify complex task structures by providing tooling for the composition and execution of workflows – even across distributed and heterogeneous computing environments. The WMS approach allows users to focus on the underlying high-level workflow and avoid low-level pitfalls that would lead to non-optimal resource usage while still allowing the workflow to remain portable between different computing environments. As a case study, we apply the UNICORE workflow management system to enable the coupling of a glacier flow model and calving model which contain many tasks and dependencies, ranging from pre-processing and data management to repetitive executions in heterogeneous high-performance computing (HPC) resource environments. Using the UNICORE workflow management system, the composition, management, and execution of the glacier modelling workflow becomes easier with respect to usage, monitoring, maintenance, reusability, portability, and reproducibility in different environments and by different user groups. Last but not least, the workflow helps to speed the runs up by reducing model coupling I/O overhead and it optimizes CPU utilization by avoiding idle CPU cores and running the models in a distributed way on the HPC cluster that best fits the characteristics of each model.
... However, the existing methods [6,10] of managing planners in systems with a hybrid structure, in conditions of uncertainty [1,5], require a large number of complex mathematical calculations [4,3], so we consider methods of a multi-agent approach for managing distributed computing at the Grid system level and managing calculations at the application level distributed computing in a cluster Grid system, integrated with traditional meta-planners and local resource managers of grid system nodes to optimize the work of planners. ...
... Information about the computational characteristics of Grid system nodes is collected by a meta-monitoring Complex [4] using Control and measuring devices in the form of a data file structure a. Information about the current indicators of the volume of computing work in the nodes of the Grid system is also collected by the metamonitoring complex in the form of a data file structure b. It is assumed that between the components of structure b on the one hand and the computational characteristics of nodes a, given by the action 1 for the task flow management object 1 ′ and 2 , distributions 1 and 2 on the other hand there is some abstract connection b = F(a, r 1 , 1 ′ , d 1 , w 2 , d 2 ). ...
Article
Full-text available
Modern information technologies include the use of server systems, virtualization technologies, communication tools for distributed computing and development of software and hardware solutions of data processing and storage centers, the most effective of such complexes for managing heterogeneous computing resources are hybrid GRID- distributed computing infrastructure combines resources of different types with collective access to these resources for and sharing shared resources. The article considers a multi-agent system that provides integration of the computational management approach for a cluster Grid system of computational type, the nodes of which have a complex hybrid structure. The hybrid cluster includes computing modules that support different parallel programming technologies and differ in their computational characteristics. The novelty and practical significance of the methods and tools presented in the article are a significant increase in the functionality of the Grid cluster computing management system for the distribution and division of Grid resources at different levels of tasks, the ability to embed intelligent computing management tools in problem-oriented applications. The use of multi-agent systems for task planning in Grid systems will solve two main problems - scalability and adaptability. The methods and techniques used today do not sufficiently provide solutions to these complex problems. Thus, the scientific task of improving the effectiveness of methods and tools for managing problem-oriented distributed computing in a cluster Grid system, integrated with traditional meta-planners and local resource managers of Grid nodes, corresponding to trends in the concept of scalability and adaptability.
... The UNICORE software package is developed at the research center in Jülich and by further partners [15], [23]. It provides different components for handling HPC environments as well as a workflow editor, a web interface (UNICOREportal) and a more advanced graphical user interface, the UNICORE rich client (URC). ...
Conference Paper
Full-text available
The mass spectroscopic fragmentation of small molecules such as metabolites can be simulated with QCEIMS. In this paper we present our work dealing with the containerization of the complex and interdependent software stack. The simulation protocol has been mapped to a UNICORE workflow enabling convenient access to powerful computing resources. To offer a maximum of convenience to the users a simple portal was deployed hiding the complexity of technical details.
... Based on the analysis of the above requirements, we took the steps (essentially, an abstract workflow) depicted in Fig. 1 and implemented it as automated scientific workflow using the UNICORE [12] workflow management system. UNI-CORE is based on multi-tier architecture with servers and clients: the server layer offers a set of web service interfaces to manage remote workflow job submissions and data access on a variety of HPC resource management systems, for instance Torque, SLURM and Load Leveler; the client layer consist of a GUI called the UNICORE Rich Client (URC) and a command line interface. ...
Conference Paper
Full-text available
The progress of remote sensing technologies leads to increased supply of high-resolution image data. However, solutions for processing large volumes of data are lagging behind: desktop computers cannot cope anymore with the requirements of macro-scale remote sensing applications; therefore, parallel methods running in High-Performance Computing (HPC) environments are essential. Managing an HPC processing pipeline is non-trivial for a scientist, especially when the computing environment is heterogeneous and the set of tasks has complex dependencies. This paper proposes an end-to-end scientific workflow approach based on the UNICORE workflow management system for automating the full chain of Support Vector Machine (SVM)-based classification of remotely sensed images. The high-level nature of UNICORE workflows allows to deal with heterogeneity of HPC computing environments and offers powerful workflow operations such as needed for parameter sweeps. As a result, the remote sensing workflow of SVM-based classification becomes re-usable across different computing environments, thus increasing usability and reducing efforts for a scientist.
Chapter
Full-text available
Eddy current testing (ECT) is one of the most extensively used non-destructive techniques for inspecting electrically conductive materials at very high speeds that does not require any contact between the test piece and the sensor. However, the characterization of a crack is not easy to obtain, and for this purpose, other eddy current evaluation methods are still under investigation.
Chapter
Grid computing implies cooperation and sharing resources belonging to distributed machines. Users can send their tasks on remote computing resources instead of executing them locally. Subsequently, Tasks scheduling is an important problem in a grid.
Chapter
Computational methods for protein structure prediction enable determination of a three-dimensional structure of a protein based on its pure amino acid sequence. However, conventional calculations of protein structure may be time-consuming and may require ample computational resources, especially when carried out with the use of ab initio methods. In this chapter, we will see how Cloud Services may help to solve these problems by scaling the computations in a role-based and queue-based Cloud4PSP system, deployed in the Microsoft Azure cloud. The chapter shows the system architecture, the Cloud4PSP processing model, and results of various scalability tests that speak in favor of the presented architecture.
Article
Full-text available
This paper describes the recent results of the GridShib and MyProxy projects to integrate the public key infrastructure (PKI) deployed for Grids with different site authentication mechanisms and the Shibboleth identity federation software. The goal is to enable multi-domain PKIs to be built on existing site services in order to reduce the PKI deployment and maintenance costs. An authorization framework in the Globus Toolkit is being developed to allow for credentials from these different sources to be merged and canonicalized for policy evaluation. Successes and lessons learned from these different projects are presented along with future plans.
Article
Full-text available
In a distributed Grid environment with ambitious service demands the job submission and management interfaces provide functionality of major importance. Emerging e-Science and Grid infrastructures such as EGEE and DEISA rely on highly available services that are capable of managing scientific jobs. It is the adoption of emerging open standard interfaces which allows the distribution of Grid resources in such a way that their actual service implementation or Grid technologies are not isolated from each other, especially when these resources are deployed in different e-Science infrastructures that consist of different types of computational resources. This paper motivates the interoperability of these infrastructures and discusses solutions. We describe the adoption of various open standards that recently emerged from the Open Grid Forum (OGF) in the field of job submission and management by well-known Grid technologies, respectively gLite and UNICORE. This has a fundamental impact on the interoperability between these technologies and thus within the next generation eScience infrastructures that rely on these technologies.
Article
Full-text available
Current distributed data management systems implement internal consistency constraints directly within the software. If these constraints change over time, the software must be rewritten. A new approach towards data management system based on the dynamic execution of rules is discussed. By building upon the experiences gained with the Storage Resource Broker data grid, a scalable rule-based data management system can be designed.
Article
This document profiles the File staging capabilities of the Job Submission Description Language (JSDL) for use by HPC Basic Profile-compliance services. It includes clarifications, refinements, interpretations and amplifications of JSDL which promote interoperability.
Article
Chemomentum, Grid Services based Environment to enable Innovative Research, is an end-user focused approach to exploit Grid computing for diverse application domains. Building on top of UNICORE 6, we are designing and implementing a flexible, user-friendly Grid system focussing on high-performance processing of complex application workflows and management of data, metadata and knowledge. This paper outlines Chemomentum vision, application scenarios, technical challenges, software architecture and design of the system.
Conference Paper
This paper describes the DESHL -- an open standards-based means for accessing the DEISA consortium¿s heterogeneous supercomputing Grid. The paper provides some background on DEISA before giving an overview of the functionality and architecture of the DESHL.
Conference Paper
Large-scale scientific research often relies on the collaborative use of Grid and e-Science infrastructures that provide computational or storage related resources. One of the ideas of these modern infrastructures is to facilitate the routine interaction of scientists and their workflows with advanced problem solving tools and computational resources. While many production Grid projects and e-Science infrastructures have begun to offer services for the usage of resources to end-users during the past several years, the corresponding emerging standards defined by GGF and OASIS still appear to be in flux. In this paper, we present the GridBean technology that bridges the gap between the constantly changing basic Grid or e-Science infrastructures and the need of stable application development environments for the Grid users.
Conference Paper
The provision and processing of information in an e- Science environment are essential tasks. For this purpose, most environments provide information services which aggregate data from different information sources and make it available to users and other services. In this paper we present CIS, an extensible information service with an underlying unified information model. Designed according to service-oriented architectural principles, CIS consumes data from sources like Ganglia, formats it according to the Common Information Model, and delivers it against XQuery requests. We realised the information service in a Web Services environment and integrated it into an implied volatility application within the NextGRID project and the UNICORE middleware.
Conference Paper
The UNICORE grid system provides a seamless, secure and intuitive access to distributed grid resources. In recent years, UNICORE 5 is used as a well-tested grid middleware system in production grids (e.g. DEISA, D-Grid) and at many supercomputer centers world-wide. Beyond this production usage, UNICORE serves as a solid basis in many European and International research projects and business scenarios from T-Systems, Philips Research, Intel, Fujitsu and others. To foster ongoing developments in multiple projects, UNICORE is open source under BSD license at SourceForge. More recently, the new Web services-based UNICORE 6 has become available that is based on open standards such as the Web services addressing (WS-A) and the Web services resource framework (WS-RF) and thus conforms to the open grid services architecture (OGSA) of the open grid forum (OGF). In this paper we present the evolution from production UNICORE 5 to the open standards-based UNICORE 6 and its various Web services-based interfaces. It describes the interface integration of emerging open standards such as OGSA-BES and OGSA-RUS and thus provides an overview of UNICORE 6.