1: \documentclass[]{llncs}
2: \usepackage{graphicx}
3: \usepackage{epsfig}
4: \usepackage{url}
5: \usepackage{float}
6: \usepackage{color}
7: \usepackage{colortbl}
8:
9: \newcommand {\tabref}[1] {Table~\ref{#1}}
10: \newcommand {\secref}[1] {Section~\ref{#1}}
11: \newcommand {\chapref}[1] {Chapter~\ref{#1}}
12: \newcommand {\figref}[1] {Figure~\ref{#1}}
13: \newcommand {\picref}[1] {Figure~\ref{#1}}
14: \newcommand {\equref}[1] {Equation~\ref{#1}}
15: \newcommand {\appref}[1] {Appendix~\ref{#1}}
16: \newcommand {\seepage}[1] {page~\pageref{#1}}
17: \newcommand {\eg} {e.\,g.\ }
18: \newcommand {\ie} {i.\,e.\ }
19: \newcommand {\cf} {cf.\ }
20: \newcommand {\bi} {\begin{itemize}}
21: \newcommand {\ei} {\end{itemize}}
22:
23: \renewcommand{\textfraction}{0.0}
24: \renewcommand{\topfraction}{1.0}
25: \renewcommand{\bottomfraction}{1.0}
26:
27: \floatstyle{plain}
28:
29: \begin{document}
30:
31: \title{UNICORE - From Project Results\\to Production Grids}
32:
33: \author{A. Streit, D. Erwin, Th. Lippert, D. Mallmann, R. Menday, \\
34: M. Rambadt, M. Riedel, M. Romberg, B. Schuller, Ph. Wieder}
35:
36: \institute{John von Neumann-Institute for Computing (NIC)\\
37: Forschungszentrum J\"{u}lich (FZJ)\\
38: 52425 J\"{u}lich, Germany\\
39: E-mail: {\tt \{a.streit,d.erwin,th.lippert,d.mallmann,r.menday,\\
40: m.riedel,m.rambadt,m.romberg,b.schuller,ph.wieder\}@fz-juelich.de} }
41:
42: \maketitle
43:
44: \begin{abstract}
45: The UNICORE Grid-technology provides a seamless, secure and intuitive access to distributed Grid resources. In
46: this paper we present the recent evolution from project results to production Grids. At the beginning UNICORE was
47: developed as a prototype software in two projects funded by the German research ministry (BMBF). Over the
48: following years, in various European-funded projects, UNICORE evolved to a full-grown and well-tested Grid
49: middleware system, which today is used in daily production at many supercomputing centers worldwide. Beyond this
50: production usage, the UNICORE technology serves as a solid basis in many European and International research
51: projects, which use existing UNICORE components to implement advanced features, high level services, and support
52: for applications from a growing range of domains. In order to foster these ongoing developments, UNICORE is
53: available as open source under BSD licence at SourceForge, where new releases are published on a regular basis.
54: This paper is a review of the UNICORE achievements so far and gives a glimpse on the UNICORE roadmap.
55: \end{abstract}
56:
57: %#########################################################################
58:
59: \section{Introduction}
60: \label{sec:intro}
61: %
62: End of 1998 the concept of ``Grid computing" was introduced in the monograph ``The Grid: Blueprint for a New
63: Computing Infrastructure" by I. Foster and C. Kesselman \cite{Foster:1998:GBN}. Two years earlier, in 1997, the
64: development of the UNICORE - Uniform Interface to Computing Resources - system was initiated to enable German
65: supercomputer centers to provide their users with a {\em seamless, secure, and intuitive access} to their
66: heterogeneous computing resources. Like in the case of the Globus Toolkit\textsuperscript{\textregistered}
67: \cite{Foster:1997:GMI} UNICORE was started before ``Grid Computing" became the accepted new paradigm for
68: distributed computing.
69:
70: The UNICORE vision was proposed to the German Ministry for Education and Research (BMBF) and received funding. A
71: first prototype was developed in the UNICORE\footnote{funded in part by BMBF grant 01 IR 703, duration: August
72: 1997 - December 1999} project \cite{Erwin:2000:UNI}. The foundations for the current production version were laid
73: in the follow-up project UNICORE Plus\footnote{funded in part by BMBF grant 01 IR 001 A-D, duration: January 2000
74: - December 2002} \cite{Erwin:2003:UNI}, which was successfully completed in 2002. Since then UNICORE was used in
75: operation at German supercomputing centers and became a solid basis for numerous European projects. In this paper
76: we will describe the evolution of UNICORE from a prototype software developed in research projects to a Grid
77: middleware used today in the daily operation of production Grids.
78:
79: Although already set out in the initial UNICORE project proposal in 1997, the goals and objectives of the UNICORE
80: technology are still valid:
81: %
82: \bi
83: \item Foremost, the aim of UNICORE is to hide the rough edges resulting from different hardware architectures, vendor
84: specific operating systems, incompatible batch systems, different application environments, historically grown
85: computer center practices, naming conventions, file system structures, and security policies -- just to name the
86: most obvious.
87: %
88: \item Equally, security is a constituent part of UNICORE's design relying on X.509 certificates for the
89: authentication of users, servers, and software, and the encryption of the communication over the internet.
90: %
91: \item Finally, UNICORE is usable by scientists and engineers without having to study vendor or site-specific
92: documentation. A Graphical User Interface (GUI) is available to assist the user in creating and managing jobs.
93: %
94: \ei
95:
96: Additionally, several basic conditions are met by UNICORE: the Grid middleware supports operating systems and
97: batch systems of all vendors present at the partner sites. In 1997 these were for instance large Cray T3E systems,
98: NEC and Hitachi vector machines, IBM SP2s, and smaller Linux clusters. Nowadays the spectrum is even broader, of
99: course with modern hardware, such as IBM p690 systems. The deployed software has to be non-intrusive, so that it
100: does not require changes in the computing centers hard- and/or software infrastructure. Maintaining site autonomy
101: is still a major issue in Grid computing, when aspects of acceptability and usability in particular from the
102: system administrator's point of view are addressed. In addition to UNICORE's own security model, site-specific
103: security requirements (\eg firewalls) are supported.
104:
105: Near the end of the initial funding period of the UNICORE Plus project, a working prototype was available, which
106: showed that the initial concept works. By combining innovative ideas and proven components over the years, this
107: first prototype evolved to a {\em vertically integrated} Grid middleware solution.
108:
109: The remainder of this paper is structured as follows. In section 2 the architecture of UNICORE and its core
110: features are described. European funded projects, which use UNICORE as a basis for their work are described in
111: Section 3, and in Section 4 the usage of UNICORE in production is described. Section 5 gives an outlook on the
112: future development of UNICORE. The paper closes with conclusions and acknowledgements.
113:
114:
115: %#########################################################################
116:
117: \section{The Architecture of UNICORE}
118: \label{sec:arch}
119: %
120: \figref{fig:UNICORE-arch} shows the layered Grid architecture of UNICORE consisting of user, server and target
121: system tier \cite{Romber:2002:UGI}. The implementation of all components shown is realized in Java. UNICORE meets
122: the Open Grid Services Architecture (OGSA) \cite{Foster:2003:TPG} concept following the paradigm of 'Everything
123: being a Service'. Indeed, an analysis has shown that the basic ideas behind UNICORE already realizes this paradigm
124: \cite{Snelling:2002:UGI,Snelling:2003:UOG}.
125:
126: \subsection{User Tier}
127: \label{sec:arch-userT}
128: %
129: The UNICORE Client provides a graphical user interface to exploit the entire set of services offered by the
130: underlying servers. The client communicates with the server tier by sending and receiving Abstract Job Objects
131: (AJO) and file data via the UNICORE Protocol Layer (UPL) which is placed on top of the SSL protocol. The AJO is
132: the realization of UNICORE's job model and central to UNICORE's philosophy of abstraction and seamlessness. It
133: contains platform and site independent descriptions of computational and data related tasks, resource information
134: and workflow specifications along with user and security information. AJOs are sent to the UNICORE Gateway in form
135: of serialized and signed Java objects, followed by an optional stream of bytes if file data is to be transferred.
136: %
137: \begin{figure}[htb]
138: \centering
139: \includegraphics[width=\textwidth]{UNICORE-architecture.eps}
140: \caption{The UNICORE architecture.} \label{fig:UNICORE-arch}
141: \end{figure}
142:
143: The UNICORE client assists the user in creating complex, interdependent jobs that can be executed on any UNICORE
144: site (Usite) without requiring any modifications. A UNICORE job, more precisely a job group, may recursively
145: contain other job groups and/or tasks and may also contain dependencies between job groups to generate job
146: workflows. Besides the description of a job as a set of one or more directed a-cyclic graphs, conditional and
147: repetitive execution of job groups or tasks are also included. For the monitoring of jobs, their status is
148: available at each level of recursion down to the individual task. Detailed log information is available to analyze
149: potential error conditions. At the end of the execution of the job it is possible to retrieve the {\sf stdout} and
150: {\sf stderr} output of the job. Data management functions like import, export, and transfer are available through
151: the GUI as explicit tasks. This allows the user to specify data transfer from one target system to another (\eg
152: for workflows), from or to the local workstation before or after the execution of a job, or to store data
153: permanently in archives.
154:
155: The previously described features already provide an effective tool to use resources of different computing
156: centers both for capacity or capability computing, but many scientists and engineers use application packages. For
157: applications without a graphical user interface, a tool kit simplifies the development of a custom built UNICORE
158: plug-in. Over the years many plug-ins were developed, so that plug-ins already exist for many standard scientific
159: applications, as \eg for CPMD (Car-Parrinello Molecular Dynamics) \cite{Huber:2001:SCP}, Fluent or MSC Nastran.
160:
161: \subsection{Server Tier}
162: \label{sec:arch-serverT}
163: %
164: The server tier contains the Gateway and the Network Job Supervisor (NJS). The Gateway controls the access to a
165: Usite and acts as the secure entry point accepting and authenticating UPL requests. A Usite identifies the
166: participating organization (\eg a supercomputing center) to the Grid with a symbolic name that resolves into the
167: URL of the Gateway. An organization may be part of multiple Grids offering the same or different resources to
168: different communities. The Gateway forwards incoming requests to the underlying Network Job Supervisor (NJS) of a
169: virtual site (Vsite) for further processing. The NJS represents resources with a uniform user mapping scheme and
170: no boundaries like firewalls between them.
171:
172: A Vsite identifies a particular set of resources at a Usite and is controlled by a NJS. A Vsite may consist of a
173: single supercomputer, \eg a IBM p690 System with LoadLeveler, or a Linux cluster with PBS as resource management
174: system. The flexibility of this concept supports different system architectures and gives the organization full
175: control over its resources. Note that, there can be more than one Vsite inside each USite as depicted in
176: \figref{fig:UNICORE-arch}.
177:
178: The NJS is responsible for the virtualization of the underlying resources by mapping the abstract job on a
179: specific target system. This process is called ``incarnation" and makes use of the Incarnation Database (IDB).
180: System-specific data are stored in the IDB describing the software and hardware infrastructure of the system.
181: Among others, the available resources like software, incarnation of abstract commands (standard UNIX command like
182: rm, cp, ...) and site-specific administrative information are stored. In addition to the incarnation the NJS
183: processes workflow descriptions included in an AJO, performs pre- and post-staging of files and authorizes the
184: user via the UNICORE User Database (UUDB). Typically the Gateway and NJS are running on dedicated secure systems
185: behind a firewall, although the Gateway could be placed outside a firewall or in a demilitarized zone.
186:
187: \subsection{Target System Tier}
188: \label{sec:arch-targetsysT}
189: %
190: The Target System Interface (TSI) implements the interface to the underlying supercomputer with its resource
191: management system. It is a stateless daemon running on the target system and interfacing with the local resource
192: manager realized either by a batch system like PBS \cite{openPBS:url} or CCS \cite{Hovestadt:2003:SHR}, a batch
193: system emulation on top of \eg Linux, or a Grid resource manager like Globus' GRAM
194: \cite{GRAM:url,Menday:2003:GEU}.
195:
196: \subsection{Single Sign-On}
197: \label{sec:arch-signon}
198: %
199: The UNICORE security model relies on the usage of permanent X.509 certificates issued by a trusted Certification
200: Authority (CA) and SSL based communication across `insecure' networks. Certificates are used to provide a single
201: sign-on in the client. The client unlocks the user's keystore when it is first started, so that no further
202: password requests are handed to the user. All authentication and authorization is done on the basis of the user
203: certificate. At each UNICORE site user certificates are mapped to local accounts (standard UNIX uid/gid), which
204: may be different at each site, due to existing naming conventions. The sites retain full control over the
205: acceptance of users based on the identity of the individual -- the distinguished name -- or other information that
206: might be contained in the certificate. UNICORE can handle multiple user certificates, \ie it permits a client to
207: be part of multiple, disjoint Grids. It is also possible to specify project accounts in the client allowing users
208: to select different accounts for different projects on one execution system or to assume different roles with
209: different privileges.
210:
211: The private key in the certificate is used to sign each job and all included sub-jobs during the transit from the
212: client to sites and between sites. This protects against tampering while the job is transmitted over insecure
213: internet connections and it allows to verify the identity of the owner at the receiving end, without having to
214: trust the intermediate sites which forwarded the job.
215:
216:
217: %#########################################################################
218:
219: \section{UNICORE Based Projects}
220: \label{sec:projects}
221: %
222: During the evolutionary development of the UNICORE technology, many European and international projects have
223: decided to base their Grid software implementations on UNICORE or to extend the growing set of core UNICORE
224: functions with new features specific to their project focus. The goals and objectives of projects using UNICORE
225: are not limited to the computer science community alone. Several other scientific domains such as bio-molecular
226: engineering or computational chemistry are using the UNICORE technology as the basis of their work. In the
227: following we present short overviews of goals and objectives of UNICORE-based projects and describe additional
228: functions and services contributed to the UNICORE development.
229:
230: \subsection{EUROGRID -- Application Testbed for European Grid Computing}
231: \label{sec:projects-eurogrid}
232: %
233: In the EUROGRID\footnote{funded in part by EC grant IST-1999-20247, duration: November 2000 - January 2004}
234: project \cite{eurogrid:url} a Grid network of leading European High Performance Supercomputing centers was
235: established. Based on the UNICORE technology application-specific Grids were integrated, operated and
236: demonstrated: \bi
237: \item Bio-Grid for biomolecular science
238: \item Meteo-Grid for localized weather prediction
239: \item CAE-Grid for coupling applications
240: \item HPC-Grid for general HPC end-users
241: \ei
242:
243: As part of the project, the UNICORE software was extended by an efficient data transfer mechanism, resource
244: brokerage mechanisms, tools and services for Application Service Providers (ASP), application coupling methods,
245: and an interactive access feature \cite{Mallmann:2001:EAT}. Efficient data transfer is a important issue, as Grids
246: typically rely on public parts of Internet connections. The available limited bandwidth has to be used efficiently
247: to reduce the transfer time and the integrity of the transferred data has to be maintained, even if the transfer
248: is interrupted. Depending on the application domain, additional security and confidentiality concerns need to be
249: considered. This UNICORE high performance data transfer also uses X.509 certificates for authentication and
250: encryption. To achieve not only a fast and secure transfer of data, but also high-performance capabilities,
251: network Quality of Service (QoS) aspects, overlapping of streamed data transfers, and packet assembling and
252: compression techniques are included.
253:
254: In order to optimize the selection of resources -- either done by the users manually or by a metascheduler
255: automatically -- resource brokerage mechanisms and detailed resource description abilities are important. Within
256: the EUROGRID project, mechanisms were added to UNICORE, which allow users to specify their jobs in an abstract way
257: improving the overall resource selection and accounting. In particular for the benefit of the industrial user
258: aspects of security, convenience, and cost efficiency were addressed. To this end, the already existing security
259: concepts of UNICORE were thoroughly evaluated and assessed as being adequate, hence no additional development had
260: to be done. The task of the developed resource broker is to match the abstract specification of the users jobs and
261: their requirements with the available resources in the Grid. The resource broker reports the best match back to
262: the user including an estimate of the costs, which than allows the user to assign the appropriate resources to the
263: job. For the suppliers of Grid resources (\eg supercomputing centers) the resource broker allows to specify
264: information about computational resources, architectures, processing power, storage and archiving facilities,
265: post-processing facilities like visualization equipment, available software packages, and security guarantees. All
266: this data is enhanced by billing information.
267:
268: Supercomputing centers converge from pure providers of raw supercomputing power to Application Service Providers
269: (ASP) running relevant scientific applications. For accounting and billing purposes the ASP needs to know the
270: exact resources consumed by each customer in each run. For measuring the usage of supercomputers standard
271: mechanisms provided by the resource management and operating system can be used, but measuring the usage of
272: licenses requires a sophisticated approach. For some applications, \eg from the Computer Aided Engineering (CAE)
273: domain, this includes a connection to the applications licence manager. Establishing a link to the above mentioned
274: resource broker is required to influence their decisions.
275:
276: For solving complex problems applications from different domains, \eg fluid-structure or
277: electromagnetism-structure, need to be coupled. This is established by using the EUROGRID resource broker
278: functionality and combining it with the available Metacomputing functionality developed in the UNICORE Plus
279: project (\cf \secref{sec:intro}), which allows different schedulers of compute and application resources to
280: cooperate. Finally, an interactive access to control and steer running application is needed for many scientific
281: applications. The interactive use includes an interactive shell to actually login to computing resources using the
282: UNICORE technology and security infrastructure.
283:
284: EUROGRID used the UNICORE technology to provide the above described services and functionalities by developing new
285: components. After the project ended, the developed components were revised and useful additions to the core
286: UNICORE functions are now part of the available UNICORE software.
287:
288:
289: \subsection{GRIP -- Grid Interoperability Project}
290: \label{sec:projects-grip}
291: %
292: Grid computing empowers users and organizations to work effectively in an information-rich environment. Different
293: communities and application domains have developed distinct Grid implementations some based on published open
294: standards or on domain and community specific features. GRIP\footnote{funded in part by EC grant IST-2001-32257,
295: duration: January 2002 - February 2004} \cite{GRIP:url} had the objective to demonstrate that the different
296: approaches of two distinct grids can successfully complement each other and that different implementations can
297: interoperate. Two prominent Grid systems were selected for this purpose: UNICORE and Globus\texttrademark
298: \cite{globus:url}, a toolkit developed in the United States. In contrast to UNICORE, Globus provides a set of APIs
299: and services which requires more in-depth knowledge from the user. Globus is widely used in numerous international
300: projects and many centers have Globus installed as Grid middleware.
301:
302: The objectives of GRIP were: \bi
303: \item Develop software to enable the interoperation of independently developed Grid solutions
304: \item Build and demonstrate prototype inter-Grid applications
305: \item Contribute to and influence international Grid standards
306: \ei
307:
308: During the runtime of the GRIP project the Open Grid Service Architecture was proposed by the Global Grid Forum
309: (GGF) \cite{GGF:url}. The arrival of OGSA also was an opportunity to influence the standards directly which were
310: to be created and to start developments that allow UNICORE to interoperate not only with Globus but with services
311: on the Grid in general, once the definition of the services and their interfaces became mature. OGSA did not
312: change the overall objectives of GRIP, however, it influenced directly some of the technical results.
313:
314: A basic requirement of GRIP was that the Grid interoperability layer should not change the well-known UNICORE user
315: environment. As developers from both communities cooperated in the GRIP project, this goal was reached with only
316: little changes of the UNICORE server components and no changes of the Globus Toolkit. This was achieved by the
317: development of the so called Globus Target System Interface (Globus TSI), which provides UNICORE-access to
318: computational resources managed by Globus. The Globus TSI was integrated into a heterogeneous UNICORE and Globus
319: testbed.
320:
321: To achieve the main objective of GRIP, the interoperability between UNICORE and Globus and initial OGSA services,
322: the following elements had to be implemented: \bi
323: \item The interoperability layer between UNICORE and Globus Version 2
324: \item The interoperability layer between UNICORE and Globus Version 3
325: \item The Access from UNICORE to simple Web services as a first step towards full integration of Web services
326: \item The Interoperability of the certificate infrastructures of UNICORE and Globus
327: \item A resource broker capable of brokering between UNICORE and Globus resources
328: \item The Ontology of the resource description on an abstract level
329: \ei
330:
331: In GRIP, two important application areas were selected to prove that the interoperability layers work as
332: specified: \bi
333: %
334: \item Bio-molecular applications were instrumented in such a way that they are Grid-aware in any
335: Grid environment and capable to seamlessly use UNICORE and Globus managed resources. The techniques developed in
336: GRIP were designed and implemented in a generalized way to ensure that they can be used in other application
337: domains as well.
338: %
339: \item A meteorological application, the Relocatable Local Model (RLM), was decomposed in such
340: a way that the components could execute on the most suitable resources in a Grid, independent of the middleware.
341: \ei
342:
343: The results of the GRIP project are important for understanding general interoperability processes between Grid
344: middleware systems. The experience and knowledge of the GRIP partners allowed to work in many relevant areas
345: within GGF, like security, architecture, protocols, workflow, production management, and applications, and to
346: influence the work in GGF.
347:
348:
349: \subsection{OpenMolGRID -- Open Computing Grid for Molecular Science and Engineering}
350: \label{sec:projects-openmolgrid}
351: %
352: The OpenMolGRID\footnote{funded in part by EC grant IST-2001-37238, duration: September 2002 - February 2005}
353: project \cite{OpenMolGrid:url} was focused on the development of Grid enabled molecular design and engineering
354: applications. {\em In silico} testing \cite{Sild:2005:OAW} has become a crucial part in the molecular design
355: process of new drugs, pesticides, biopolymers, and biomaterials. In a typical design process $O(10^5)$ to
356: $O(10^6)$ candidate molecules are generated and their feasibility has to be tested. It is not economical to carry
357: out experimental testing on all possible candidates. Therefore, computational screening methods provide a cheap
358: and cost effective alternative to reduce the number of candidates. Over the years Quantitative Structure
359: Activity/Property Relationship (QSAR/QSPR) methods have been shown to be reliable for the prediction of various
360: physical, chemical, and biological activities \cite{Karelson:2000:MDQ}.
361:
362: QSPR/QSAR relies on the observation that molecular compounds with similar structure have similar properties. For
363: each specific application a set of molecules is needed for which the target property is known. This requires
364: searching globally distributed information resources for appropriate data. For the purpose of exploring molecular
365: similarity, descriptors are calculated from the molecular structure. Thousands of molecular descriptors have been
366: proposed and are used to characterize molecular structures with respect to different properties. Their calculation
367: puts high demands on computer resources and requires high-performance computing.
368:
369: Based on this complex application the objectives of the OpenMolGRID project were defined as:
370: \bi
371: \item Development of tools for secure and seamless access to distributed information and computational methods
372: relevant to molecular engineering within the UNICORE frame
373: \item Provision of a realistic testbed and reference application in life science
374: \item Development of a toxicity prediction model validated with a large experimental set
375: \item Provision of design principles for next generation molecular engineering systems.
376: \ei
377: %
378: In particular this included to use UNICORE to automatize, integrate, and speed-up the drug discovery pipeline.
379:
380: The OpenMolGRID project addressed the objectives above by defining abstraction layers for data sources (databases)
381: and methods (application software), and integrating all necessary data sources (\eg ECOTOX \cite{ecotox:url}) and
382: methods (\eg 2D/3D Molecular Structure Conversion and Optimization, Descriptor Calculation, Structure Enumeration)
383: into UNICORE. The project developed application specific user interfaces (plug-ins) and a mechanism to generate a
384: complete UNICORE Job from an XML workflow specification. This so called Meta-Plug-in takes care of including all
385: auxiliary steps like data format transformation and data transfers into the job, distributing data parallel tasks
386: over available computational resources, and allocating resources to the tasks. Thereby the molecular design
387: process was significantly improved as the time to build QSAR/QSPR models, the probability for mistakes, and the
388: variability of results was reduced. In addition a command line client (CLC) for UNICORE was developed to enable
389: the data warehouse to use Grid resources for its data transformation processes. The CLC offers the generation of
390: UNICORE jobs from XML workflow description as well as the job submission, output retrieval, status query, and job
391: abortion. The CLC consists of commands, an API, and a queuing component.
392:
393: Besides the technical achievements of OpenMolGRID and the added value for pharmaceutical companies its results
394: will contribute to the standardization of QSAR models.
395:
396:
397: \subsection{VIOLA -- Vertically Integrated Optical Testbed for Large Applications}
398: \label{sec:projects-viola}
399: %
400: The aim of the VIOLA\footnote{funded in part by BMBF grant 01AK605F, duration: May 2004 - April 2007} project
401: \cite{VIOLA:url} is to build up a testbed with the latest optical network technology (multi 10 Gigabit Ethernet
402: links). The goals and objectives of VIOLA are: \bi
403: %
404: \item Testing of new network components and network architectures
405: \item Development and testing of software for dynamic bandwidth management
406: \item Interworking of network technology from different manufacturers
407: \item Development and testing of new applications from the Grid and Virtual Reality (VR) domain
408: %
409: \ei
410:
411: The performance of the new network technology is evaluated with different scientific applications that need a very
412: high network performance and network flexibility. UNICORE is used to build up the Grid on top of the hardware
413: without taking fundamental software modifications. Only an interface to the meta-computer software library
414: MetaMPICH \cite{METAMPICH:url} needs to be integrated into UNICORE. Grid applications from the High Performance
415: Supercomputing and Virtual Reality domain are enhanced for an optimized usage of the available bandwidth and the
416: provided Quality of Service classes. In this context a Meta-Scheduler framework is developed, which is able to
417: handle complex workflows and multi-site jobs by coordinating supercomputers and the network connecting them.
418:
419: \begin{figure}[htb]
420: \centering
421: \includegraphics[width=\textwidth]{VIOLA-superscheduler.eps}
422: \caption{The VIOLA Meta-Scheduler architecture.} \label{fig:VIOLA-supersched}
423: \end{figure}
424:
425: VIOLA's first generation Meta-Scheduler architecture focuses on the scheduling functionality requiring only
426: minimal changes to the UNICORE system. As depicted in \figref{fig:VIOLA-supersched}, the system comprises the
427: Agreement Manager, the Meta-Scheduler itself \cite{Quecke:2000:MAR}, and a Meta-Scheduling plug-in (which is part
428: of the client and not pictured separately). Before submitting a job to a Usite (\cf \secref{sec:arch-serverT}),
429: the Meta-Scheduling plug-in and the Meta-Scheduler exchange the data necessary to schedule the resources needed.
430: The Meta-Scheduler is then (acting as an Agreement Consumer in WS--Agreement terms \cite{GRAAP:url}) contacting
431: the Agreement Manager to request a certain level of service, a request which is translated by the Manager into the
432: appropriate resource management system commands. In case of VIOLA's computing resources the targeted resource
433: management system is the EASY scheduler. Once all resources are reserved at the requested time the Meta-Scheduler
434: notifies the UNICORE Client via the Meta-Scheduling plug-in to submit the job. This framework will also be used to
435: schedule the interconnecting network, but potentially any resource can be scheduled if a respective Agreement
436: Manager is implemented and the Meta-Scheduling plug-in generates the necessary scheduling information. The
437: follow-on generation of the Meta-Scheduling framework will then be tightly integrated within UNICORE/GS (\cf
438: \secref{sec:future-unigrids-GS}).
439:
440:
441: \subsection{NaReGI -- National Research Grid Initiative}
442: \label{sec:projects-naregi}
443: %
444: The Japanese NaReGI project \cite{NAREGI:url} includes the UNICORE technology as the basic middleware for research
445: and development. NaReGI is a collaboration project between industry, academia, and government. The goals and
446: objectives are: \bi
447: %
448: \item Establishment of a national Japanese research Grid infrastructure
449: \item Revitalization of the IT industry through commercialization of Grid middleware and strengthened
450: international competitiveness
451: \item Dissemination of Grid environments throughout industry
452: \item Trailblazing the standardization of Grid technology
453: \item Cultivation of human resources specializing in IT technology for Grids
454: \ei
455:
456: Similar to the GRIP project (\cf \secref{sec:projects}) where an interoperability layer between UNICORE and Globus
457: Toolkit 2 and 3 was developed, the NaReGI project plans to implement such a layer between UNICORE and Condor
458: \cite{CONDOR:url}, called UNICONDORE. This interoperability layer will allow to submit jobs from the UNICORE
459: client to Condor pools and to use Condor commands to submit jobs to UNICORE managed resources.
460:
461: In the first phase of the NaReGI testbed UNICORE provides access to about 3000 CPUs in total with approximately 17
462: TFlops of peak performance. It is expected to increase the integrated peak performance to 100+ TFlops by the end
463: of the project in 2007.
464:
465:
466: %#########################################################################
467:
468: \section{UNICORE in Production}
469: \label{sec:production}
470: %
471: From its birth in two German BMBF-funded projects to its extensive use and further development in a variety of EU
472: and BMBF research projects, the UNICORE technology ran through an evolutionary process transforming from an
473: initial prototype software to a powerful production Grid middleware.
474:
475: \subsection{UNICORE@SourceForge}
476: \label{sec:production-SF}
477: %
478: Since May 2004, the UNICORE technology with all its components is available as open source software under the BSD
479: license. It can be downloaded from the SourceForge repository. Besides the core developers of UNICORE (namely
480: Fujitsu Laboratories of Europe, Intel Germany and the Research Center J\"{u}lich), there are numerous contributors
481: from all over the world, \eg Norway, Poland, China and Russia. The Web site \cite{UNICORE-sourceforge:url} offers
482: a convenient entry point for interested users and developers. In the download section the UNICORE software is
483: bundled in different packages, \eg the client package and individual packages for the different server components
484: Gateway, NJS, TSI/IDB, UUDB (\cf \secref{sec:arch}), and plug-ins. Until January 2005 more than 2800 downloads of
485: UNICORE are counted.
486:
487: A tracker section linked on the Web site establishes a communication link to the core developer community. The
488: corresponding mailing lists allow users to report bugs, to request new features, and to get informed about bug
489: fixes or patches. For the announcement of new software releases a separate mailing list was created. The Grid team
490: at the Research Center J\"{u}lich is responsible for UNICORE@SourceForge. Its work includes coordinating and driving
491: the development effort, and producing consolidated, stable, and tested releases of the UNICORE software.
492:
493: \subsection{Production System on Jump}
494: \label{sec:production-Jump}
495: %
496: Since July 2004 UNICORE is established as production software to access the supercomputer resources of the John
497: von Neumann-Institute for Computing (NIC) at the Research Center J\"{u}lich. These are the 1312-processor IBM p690
498: cluster (Jump) \cite{Jump:url}, the Cray SV1 vector machine, and a new Cray XD1 cluster system. As an alternative
499: to the standard SSH login, UNICORE provides an intuitive and easy way for submitting batch jobs to the systems.
500: The academic and industrial users come from all over Germany and from parts of Europe. The applications come from
501: a broad field of domains, \eg astrophysics, quantumphysics, medicine, biology, chemistry, and climate research,
502: just to name the largest user communities. A dedicated, pre-configured UNICORE client with all required
503: certificates and accessible Vsites is available for download. This alleviates the installation and configuration
504: process significantly. Furthermore, an online installation guide including a certificate assistant, an user
505: manual, and example jobs help users getting started.
506:
507: To provide the NIC-users with adequate certificates and to ease the process of requesting and receiving a
508: certificate, a certificate authority (CA) was established. User certificate requests are generated in the client
509: and have to be send to the CA. Since introduction of UNICORE at NIC, more than 120 active users requested a
510: UNICORE user certificate.
511:
512: A mailing list serves as a direct link of the users to UNICORE developers in the Research Center J\"{u}lich. The list
513: allows to post problems, bug reports, and feature requests. This input is helpful in enhancing UNICORE with new
514: features and services, in solving problems, identifying and correcting bugs, and influences new releases
515: of UNICORE available at SourceForge.
516:
517: \subsection{DEISA -- Distributed European Infrastructure for Scientific Applications}
518: \label{sec:production-DEISA}
519: %
520: Traditionally, the provision of high performance computing resources to researchers has traditionally been the
521: objective and mission of national HPC centers.On the one hand, there is an increasing global competition between
522: Europe, USA, and Japan with growing demands for compute resources at the highest performance level, and on the
523: other hand stagnant or even shrinking budgets. To stay competitive major investments are needed every two years --
524: an innovation cycle that even the most prosperous countries have difficulties to fund.
525:
526: To advance science in Europe, eight leading European HPC centers devised an innovative strategy to build a
527: Distributed European Infrastructure for Scientific Applications (DEISA) \cite{DEISA:url}. The centers join in
528: building and operating a tera-scale supercomputing facility. This becomes possible through deep integration of
529: existing national high-end platforms, tightly coupled by a dedicated network and supported by innovative system
530: and grid software. The resulting virtual distributed supercomputer has the capability for natural growth in all
531: dimensions without singular procurements at the European level. Advances in network technology and the resulting
532: increase in bandwidth and lower latency virtually shrink the distance between the nodes in the distributed
533: super-cluster. Furthermore, DEISA can expand horizontally by adding new systems, new architectures, and new
534: partners thus increasing the capabilities and attractiveness of the infrastructure in a non-disruptive way.
535:
536: By using the UNICORE technology, the four core partners of the projects have coupled their systems using virtually
537: dedicated 1 Gbit/s connections. The DEISA super-cluster currently consists of over 4000 IBM Power 4 processors and
538: 416 SGI processors with an aggregated peak performance of about 22 teraflops. UNICORE provides the seamless,
539: secure and intuitive access to the super-cluster.
540:
541: The Research Center J\"{u}lich is one of the DEISA core partners and is responsible for introducing UNICORE as Grid
542: middleware at all partner sites and for providing support to local UNICORE administrators.
543:
544: All DEISA partners have installed the UNICORE server components Gateway, NJS, TSI, and UUDB to access the local
545: supercomputer resources of each site via UNICORE. \figref{fig:DEISA-architecture} shows the DEISA UNICORE
546: configuration. For clarity only four sites are shown. At each site, a Gateway exists as an access to the DEISA
547: infrastructure. The NJSs are not only registered to their local Gateway, but to all other Gateways at the partner
548: sites as well. Local security measures like firewall configurations need to consider this, by permitting access to
549: all DEISA users and NJSs. This fully connected architecture has several advantages. If one Gateway has a high
550: load, access to the high performance supercomputers through DEISA is not limited. Due to the fully connected
551: architecture, no single point of failure exists and the flexibility is increased.
552: %
553: \begin{figure}[htb]
554: \centering
555: \includegraphics[width=0.95\textwidth]{DEISA-architecture.eps}
556: \caption{The DEISA architecture.} \label{fig:DEISA-architecture}
557: \end{figure}
558:
559: The DEISA partners operate different supercomputer architectures, which are all accessible through UNICORE.
560: Initially all partners with IBM p690 clusters are connected to one large virtual supercomputer. In a second step
561: other supercomputers of different variety are connected to DEISA, making the virtual supercomputer heterogeneous.
562: UNICORE can handle this, as it is designed to serve such heterogeneous architectures in a seamless, secure, and
563: intuitive way.
564:
565: In December 2004 a first successful UNICORE demonstration between the four DEISA core sites FZJ (Research Center
566: J\"{u}lich, Germany), RZG (Computing Center Garching, Germany), CINECA (Italian Interuniversity Consortium, Italy) and
567: IDRIS (Institute for Development and Resources in Intensive Scientific Computing, France) was given. Different
568: parts of a distributed astrophysical application were generated and submitted with UNICORE to all four sites.
569:
570: The experience and knowledge of the researchers, developers, users, and administrators in working with UNICORE in
571: the DEISA project on a large production platform will be used as useful input for future developments of the
572: UNICORE technology. A close synchronization with the UniGrids project (\cf \secref{sec:future-unigrids}) is
573: foreseen.
574:
575:
576: %#########################################################################
577:
578: \section{Future of UNICORE}
579: \label{sec:future}
580: %
581: The current UNICORE software implements a vertically integrated Grid architecture providing seamless access to
582: various resources. Every resource is statically integrated into the UNICORE Grid by providing an interface to the
583: appropriate resource manager.
584:
585: One of the benefits Web services will bring to Grid computing is the concept of loosely coupled distributed
586: services. Merging the idea of ``everything being a service'' with the achievements of the Grid community led to
587: Grid services, enabling a new approach to the design of Grid architectures. The adoption of XML and the drive for
588: standardization of the Open Grid Service Architecture provide the tools to move closer to the promise of
589: interoperable Grids. A demonstrator validated the correspondence of UNICORE's architectural model with the
590: OGSA/OGSI (Open Grid Service Infrastructure \cite{Tuecke:2003:OGSI}) approach, which encouraged the development of
591: an OGSA/OGSI compliant UNICORE Grid architecture in the GRIP project (\cf \secref{sec:projects-grip}).
592:
593: In \cite{Menday:2003:GEU} UNICORE is examined for the evolution of a Grid system towards a service oriented Grid,
594: primarily focussing on architectural concepts and models. Based on the current architecture and the enhancements
595: provided by GRIP, first steps already integrate Web services into UNICORE. This included the provision of OGSI
596: compliant port types parallel to the proprietary ones as well as the design of XML based protocols. This work was
597: continued in the UniGrids project.
598:
599: As mentioned above the development of a Grid middleware is an continuous process of integrating new features,
600: services, and adapting to emerging standards, and UNICORE is no exception. In the following we present new
601: developments, some technical details, and report on projects, which enhance the UNICORE technology to serve the
602: demands of the Grid in the future \cite{Jeffrey:2004:NGG}.
603:
604:
605: \subsection{UniGrids -- Uniform Interface to Grid Services}
606: \label{sec:future-unigrids}
607: %
608: The strength of the UNICORE architecture is well-proven as described above. The rapid definition and adoption of
609: OGSA allow the UNICORE development community to re-cast and extend the concepts of UNICORE through the use of Web
610: services technologies. The goal of the UniGrids\footnote{funded in part by EC grant IST-2002-004279, duration:
611: July 2004 - June 2006} project \cite{UniGrids:url} is to lift UNICORE on an architecture of loosely-coupled
612: components while keeping its 'end-to-end' nature.
613:
614: Thus, the integration of Web services techniques and UNICORE, which already started in the GRIP project (\cf
615: \secref{sec:projects-grip}), will continue in the \mbox{UniGrids} project. Interoperability, through adopting and
616: influencing standards, form the philosophical foundation for UniGrids. The project aims to transform UNICORE into
617: a system with interfaces that are compliant with the Web Services Resource Framework (WS-RF) \cite{WSRF:url} and
618: that interoperate with other WS-RF compliant software components.
619:
620: Such an approach offers great advantages both for the ease of development of new components by aggregation of
621: services and through the integration of non-UNICORE components into the standards-based infrastructure.
622:
623: In this sense, work is continuing in the following areas: \bi
624: %
625: \item Development of a compliant WS-RF hosting environment used for publishing UNICORE job and file services as
626: Web services.
627: \item Support of dynamic virtual organizations by enhancing the UNICORE security infrastructure to allow different
628: usage models such as delegation and collective authorization.
629: \item Development of translation mechanisms, such as resource ontologies, to interoperate with other OGSA compliant
630: systems. Support for Grid economics by developing a Service Level Agreement (SLA) framework and cross-Grid
631: brokering services.
632: \item Development and integration of generic software components for visualization and steering of simulations (VISIT
633: \cite{visit:url}), device monitoring and control, and tools for accessing distributed data and databases.
634: %
635: \ei
636:
637: Applications from the scientific and industrial domain, like biomolecular and computational biology, geophysical
638: depth imaging by oil companies, automotive, risk-management, energy, and aerospace are used to prove the
639: developments in UniGrids.
640:
641: The development in the UniGrids project will lead to UNICORE/GS, which follows the architecture of OGSA through
642: the standardization of WS-RF and related work like \eg the Web Services Notification technology \cite{WSN:url}.
643: The results will be made available under an open source BSD license.
644:
645: \subsubsection{UNICORE/GS}
646: \label{sec:future-unigrids-GS}
647: %
648: Web service technology, and in particular the WS-RF, forms the basis for the UNICORE/GS software. WS-RF is the
649: follow-on to OGSI, but more in line with mainstream Web services architecture \cite{WSARCH:url}. Based on this new
650: technology, UNICORE/GS will retain its key characteristics of seamlessness, security, and intuitiveness from both
651: the user and administrative perspective, but will be built on a service oriented framework. This means that there
652: is a loosening of the coupling between the components of the system. UNICORE/GS keeps the classical UNICORE
653: topology of Usites, each containing a number of Vsites, but provides a new framework for integrating other
654: services and providing common infrastructure functionality as services. This has the implication that new services
655: will be easily integrated into the UNICORE/GS environment. Conversely, UNICORE/GS will be well-prepared to make
656: use of external services.
657:
658: The WS-RF technology is used to model core functionalities such as job submissions and file transfers as
659: WS--Resources. These services are accessible via web service interfaces and thus establishing the UniGrids atomic
660: services layer. This layer will be realized making extensive use of existing UNICORE server components.
661:
662: All services in a Usite are accessible through the UniGrids Gateway that provides a secure entrance into the
663: UNICORE/GS infrastructure. The principal is exactly the same as for classic UNICORE, however, the Gateway now
664: routes messages according to Web Services Addressing (WS--Addressing) \cite{WSA:url}. Authentication is based on
665: transport level HTTPS security, although the intention is to move to Web Services Security (WS--Security)
666: \cite{WSS:url}. Regarding authorized access to resources, the UNICORE User Database (UUDB) will be available as a
667: service to other services in the Usite, and will form the basis for future work concerning virtual organizations
668: and fine-grained authorization schemes.
669:
670: The underlying UniGrids atomic services layer will provide an excellent framework to deploy higher-level services
671: such as co-allocation schedulers, workflow engines, and services for provision and easy access to data-intensive,
672: remotely-steerable simulations.
673:
674: \subsection{NextGrid -- Architecture for Next Generation Grids}
675: \label{sec:future-nextgrids}
676: %
677: In comparison to the UniGrids project which evolves the existing UNICORE Grid system to a service-oriented one,
678: the NextGRID\footnote{funded in part by EC grant IST-2002-511563, duration: September 2004 - August 2007}
679: \cite{nextgrid:url} project aims for the future: The goal is to provide the foundations for the next generation of
680: Grids. NextGRID is not a project based on the UNICORE architecture or Grid system as-is, but institutions and
681: people involved in the UNICORE development from the beginning on contribute expertise and experience to NextGRID.
682:
683: Since it is obvious that there is no such thing as the one and only next generation Grid, and experts envisage the
684: co-existence of multiple Grids with well-defined boundaries and access points, NextGRID is going to define a Grid
685: architecture which can be seen as building blocks for Grids. It does not only provide interoperability by-design
686: between entities which exist within one instantiation of such an architecture, but it also facilitates the
687: interoperability between different Grids developed according to the NextGRID architecture.
688:
689: Although developing a Grid one generation ahead, NextGRID is not starting from scratch. Properties to incarnate
690: and functions to realize future Grids are expertly described in \cite{Priol:2003:NGG} and \cite{Jeffrey:2004:NGG}.
691: These reports frame NextGRID's architectural development while the Open Grid Services Architecture is going to
692: define Grid services and their interactions and does therefore make up a staring point for the conceptualization
693: and design of NextGRID. In addition, regarding the underlying technology and architectural model, NextGRID
694: propagates the usage of Web Services and the adoption of Service-Oriented Achitecture (SOA) \cite{Erl:2004:SOA}
695: concepts and models.
696:
697: NextGRID focuses on security, economic sustainability, privacy/legacy, scalability and usability. The following
698: properties have the highest priorities when carrying out the following work: \bi
699: %
700: \item Developing an architecture for next generation Grids
701: \item Implementing and testing prototypes aligned with the concepts and design of the NextGRID architecture
702: \item Creating reference applications which make use of the NextGRID prototypes
703: \item Facilitating the transition from scientific- to business-oriented Grids by integrating the means to negotiate
704: a certain Quality of Service (QoS) level
705: \item Specifying the methods, processes, and services necessary to dynamically operate Grids across multiple
706: organizations which comprise heterogeneous resources
707: %
708: \ei
709:
710: Since the ongoing UNICORE development in projects like UniGrids shares resources as well as the technological
711: foundation with NextGRID there is a high chance that the outcome of NextGRID will also represent the next step of
712: UNICORE's evolution.
713:
714:
715: %%########################################################################
716:
717: \section{Conclusion}
718: \label{sec:conclusion}
719: %
720: In this paper we presented the evolution of the UNICORE technology from a Grid software with prototype character
721: developed in two German projects to a full-grown, well-tested, widely used and accepted Grid middleware. UNICORE
722: -- Uniform Interface to Computing Resources -- provides a {\em seamless, secure and intuitive} access to
723: distributed Grid resources. Although the UNICORE vision was already coined in 1997, the then stated goals and
724: objectives of hiding the seams of resource usage, incorporating a strong security model, and providing an easy to
725: use graphical user interface for scientists and engineers are still valid today: to achieve these goals and
726: objectives, UNICORE is designed as a vertically integrated Grid middleware providing components at all layers of a
727: Grid infrastructure, from a graphical user interface down to the interfaces to target machines.
728:
729: Initially developed in the German projects UNICORE and UNICORE Plus, UNICORE was soon established as a promising
730: Grid middleware in several European projects. In the GRIP project an interoperability layer between UNICORE and
731: the Globus Toolkit 2 and 3 was developed to demonstrate the interoperability of independently developed Grid
732: solutions, allowing to build and to demonstrate inter-Grid applications from the bio-molecular and meteorological
733: domain. In the EUROGRID project, European high performance supercomputing centers joined to extend UNICORE with an
734: efficient data transfer, resource brokerage mechanisms, ASP services, application coupling methods, and an
735: interactive access. In addition, a Bio-Grid, Meteo-Grid, CAE-Grid, and HPC-Grid were established to integrate a
736: variety of application domains. The main objective of the OpenMolGRID project is to provide a unified and
737: extensible information-rich environment based on UNICORE for solving problems from molecular science and
738: engineering. In the VIOLA project a vertically integrated testbed with the latest optical network technology is
739: built up. UNICORE is used as the Grid middleware for enabling the development and testing of new applications in
740: the optical networked testbed, which provides advanced bandwidth management and QoS features.
741:
742: With these developments UNICORE grew to a software system usable in production Grids. In this context UNICORE is
743: deployed in the large German supercomputing centers to provide access to their resources. At the John von
744: Neumann-Institute for Computing, Research Center J\"{u}lich, many users submit their batch jobs through UNICORE to the
745: 1312-processor 8.9 TFlop/s IBM p690 cluster and the Cray SV1 vector machine. Leading European HPC centers joined
746: in the project DEISA to build a distributed European infrastructure for scientific applications based on UNICORE
747: to build and operate a distributed multi tera-scale supercomputing facility.
748:
749: The future of UNICORE is promising and follows the trend of ``Everything being a Service" by adapting to Open Grid
750: Service Architecture (OGSA) standards. In this context, the UniGrids project continues the effort of the GRIP
751: project in integrating the Web Services and UNICORE technology to enhance UNICORE to an architecture of
752: loosely-coupled components while keeping its ``end-to-end" nature. To this end UNICORE/GS will be developed, which
753: makes UNICORE compliant with the Web Services Resource Framework (WS-RF).
754:
755: Today the UNICORE software is available as open source under a BSD licence from SourceForge for download. This
756: enables the community of core UNICORE developers to grow and makes future development efforts open to the public.
757:
758:
759: %%########################################################################
760:
761: \section{Acknowledgments}
762: \label{sec:ack}
763: %
764: The work summarized in this paper was done by many people. We gratefully thank them for their past, present, and
765: future contributions in developing the UNICORE technology. Most of the work described here was supported and
766: funded by BMBF and different programmes of the European Commission under the respective contract numbers mentioned
767: above.
768:
769: %%########################################################################
770:
771: \newcommand{\noopsort}[1]{}
772: \begin{thebibliography}{10}
773: \expandafter\ifx\csname url\endcsname\relax
774: \def\url#1{\texttt{#1}}\fi
775: \expandafter\ifx\csname urlprefix\endcsname\relax\def\urlprefix{URL }\fi
776:
777: \bibitem{Foster:1998:GBN}
778: {I. Foster, C. Kesselman (Eds.)}, {The Grid: Blueprint for a New Computing
779: Infrastructure}, Morgan Kaufmann Publishers Inc. San Fransisco, 1999.
780:
781: \bibitem{Foster:1997:GMI}
782: I.~Foster, C.~Kesselman, {Globus: A Metacomputing Infrastructure Toolkit},
783: International Journal on Supercomputer Applications 11~(2) (1997) 115--128.
784:
785: \bibitem{Erwin:2000:UNI}
786: {D. Erwin (Ed.)}, {UNICORE - Uniformes Interface f\"{u}r Computing Ressourcen,
787: final project report (in German)}, 2000.
788:
789: \bibitem{Erwin:2003:UNI}
790: {D. Erwin (Ed.)}, {UNICORE Plus Final Report - Uniform Interface to Computing
791: Resources}, Forschungszentrum J\"{u}lich, 2003.
792:
793: \bibitem{Romber:2002:UGI}
794: M.~Romberg, {The UNICORE Grid Infrastructure}, Scientific Programming 10~(2)
795: (2002) 149--157.
796:
797: \bibitem{Foster:2003:TPG}
798: I.~Foster, C.~Kesselmann, J.~M. Nick, S.~Tuecke, {The Physiology of the Grid},
799: in: F.~Berman, G.~C. Fox, A.~J.~G. Hey (Eds.), Grid Computing, John Wiley \&
800: Sons Ltd, 2003, pp. 217--249.
801:
802: \bibitem{Snelling:2002:UGI}
803: D.~Snelling, S.~van~den Berghe, G.~von Laszweski, P.~Wieder, D.~Breuer,
804: J.~MacLaren, D.~Nicole, H.-C. Hoppe, {A UNICORE Globus Interoperability
805: Layer}, Computing and Informatics 21 (2002) 399--411.
806:
807: \bibitem{Snelling:2003:UOG}
808: D.~Snelling, {UNICORE and the Open Grid Services Architecture}, in: {F. Berman,
809: G. Fox, and T. Hey} (Ed.), {Grid Computing: Making The Global Infrastructure
810: a Reality}, {John Wiley \& Sons}, 2003, pp. 701--712.
811:
812: \bibitem{Huber:2001:SCP}
813: V.~Huber, {Supporting Car-Parrinello Molecular Dynamics Application with
814: UNICORE}, in: {Proc. of the International Conference on Computational Science
815: (ICCS 2001)}, 2001, pp. 560--566.
816:
817: \bibitem{openPBS:url}
818: {PBS - Portable Batch System}, \url{http://www.openpbs.org/}.
819:
820: \bibitem{Hovestadt:2003:SHR}
821: M.~Hovestadt, O.~Kao, A.~Keller, A.~Streit, {Scheduling in HPC Resource
822: Management Systems: Queuing vs. Planning}, in: {D. G. Feitelson and L.
823: Rudolph} (Ed.), {Proc. of the 9th Workshop on Job Scheduling Strategies for
824: Parallel Processing}, Vol. 2862 of {Lecture Notes in Computer Science},
825: {Springer}, 2003, pp. 1--20.
826:
827: \bibitem{GRAM:url}
828: {Globus: Research in Resource Management},
829: \url{http://www.globus.org/research/resource-management.html}.
830:
831: \bibitem{Menday:2003:GEU}
832: R.~Menday, P.~Wieder, {GRIP: The Evolution of UNICORE towards a
833: Service-Oriented Grid}, in: {Proc. of the 3rd Cracow Grid Workshop (CGW'03)},
834: 2003, pp. 142--150.
835:
836: \bibitem{eurogrid:url}
837: {EUROGRID - Application Testbed for European Grid Computing},
838: \url{http://www.eurogrid.org}.
839:
840: \bibitem{Mallmann:2001:EAT}
841: D.~Mallmann, {EUROGRID - Application Testbed for European Grid Computing}, in:
842: {Proc. of Industrial GRID Conference 2001}, 2001.
843:
844: \bibitem{GRIP:url}
845: {GRIP - Grid Interoperability Project},
846: \url{http://www.grid-interoperability.org}.
847:
848: \bibitem{globus:url}
849: {The Globus Project}, \url{http://www.globus.org/}.
850:
851: \bibitem{GGF:url}
852: {Global Grid Forum}, \url{www.globalgridforum.org}.
853:
854: \bibitem{OpenMolGrid:url}
855: {OpenMolGRID - Open computing Grid for Molecular Science and Engineering},
856: \url{http://www.openmolgrid.org}.
857:
858: \bibitem{Sild:2005:OAW}
859: S.~Sild, U.~Maran, M.~Romberg, B.~Schuller, E.~Benfenati, {OpenMolGRID: Using
860: Automated Workflows in GRID Computing Environment}, in: {Proceedings of the
861: European Grid Conference 2005}, 2005.
862:
863: \bibitem{Karelson:2000:MDQ}
864: {M. Karelson}, {Molecular Descriptors in QSAR/QSPR}, John Wiley \& Sons, New
865: York, 2000.
866:
867: \bibitem{ecotox:url}
868: {U.S. Environmental Protection Agency ECOTOXicology database},
869: \url{http://www.epa.gov/ecotox/}.
870:
871: \bibitem{VIOLA:url}
872: {VIOLA - Vertically Integrated Optical Testbed for Large Applications in DFN},
873: \url{http://www.viola-testbed.de}.
874:
875: \bibitem{METAMPICH:url}
876: {MetaMPICH - Flexible Coupling of Heterogeneous MPI Systems},
877: \url{http://www.lfbs.rwth-aachen.de/~martin/MetaMPICH/}.
878:
879: \bibitem{Quecke:2000:MAR}
880: G.~Quecke, W.~Ziegler, {MeSch - An Approach to Resource Management in a
881: Distributed Environment}, in: {R. Buyya} (Ed.), Proc. of 1st IEEE/ACM
882: International Workshop on Grid Computing (Grid 2000), Vol. 1971 of {Lecture
883: Notes in Computer Science}, {Springer}, 2000, pp. 47--54.
884:
885: \bibitem{GRAAP:url}
886: {Global Grid Forum GRAAP (Grid Resource Allocation Agreement Protocol) Working
887: Group}, \url{https://forge.gridforum.org/projects/graap-wg/}.
888:
889: \bibitem{NAREGI:url}
890: {NaReGI - National Research Grid Initiative},
891: \url{http://www.naregi.org/index_e.html}.
892:
893: \bibitem{CONDOR:url}
894: {The Condor Project}, \url{http://www.cs.wisc.edu/condor/}.
895:
896: \bibitem{UNICORE-sourceforge:url}
897: {UNICORE at SourceForge}, \url{http://unicore.sourceforge.net}.
898:
899: \bibitem{Jump:url}
900: {Jump - Juelich Multi Processor, 8,9 TFlop/s IBM p690 eServer Cluster},
901: \url{http://jumpdoc.fz-juelich.de}.
902:
903: \bibitem{DEISA:url}
904: {DEISA - Distributed European Infrastructure for Supercomputing Applications},
905: \url{http://www.deisa.org}.
906:
907: \bibitem{Tuecke:2003:OGSI}
908: S.~Tuecke, K.~Czajkowski, I.~Foster, J.~Frey, S.~Graham, C.~Kesselman,
909: T.~Maquire, T.~Sandholm, D.~Snelling, P.~V. (eds.), {The Open Grid Services
910: Infrastructure (OGSI) Version 1.0} (2003).
911:
912: \bibitem{Jeffrey:2004:NGG}
913: {Next Generation Grids 2 -- Requirements and Options for European Grids
914: Research 2005-2010 and Beyond},
915: \url{ftp://ftp.cordis.lu/pub/ist/docs/ngg2_eg_final.pdf} (2004).
916:
917: \bibitem{UniGrids:url}
918: {UniGrids - Uniform Access to Grid Services}, \url{http://www.unigrids.org}.
919:
920: \bibitem{WSRF:url}
921: {OASIS Web Services Resource Framework (WSRF)},
922: \url{http://www.oasis-open.org/committees/wsrf}.
923:
924: \bibitem{visit:url}
925: {VISIT -- A Visualization Toolkit}, \url{http://www.fz-juelich.de/zam/visit/}.
926:
927: \bibitem{WSN:url}
928: {OASIS Web Services Notification (WSN)},
929: \url{http://www.oasis-open.org/committees/wsn}.
930:
931: \bibitem{WSARCH:url}
932: {W3C Web Services Architecture}, \url{http://www.w3.org/TR/ws-arch/}.
933:
934: \bibitem{WSA:url}
935: {Web Services Addressing},
936: \url{http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/}.
937:
938: \bibitem{WSS:url}
939: {OASIS Web Services Security (WSS)},
940: \url{http://www.oasis-open.org/committees/wss/}.
941:
942: \bibitem{nextgrid:url}
943: {NextGRID - Architecture for Next Generation Grids},
944: \url{http://www.nextgrid.org}.
945:
946: \bibitem{Priol:2003:NGG}
947: {Next Generation Grids -- European Grid Research 2005 - 2010},
948: \url{ftp://ftp.cordis.lu/pub/ist/docs/ngg_eg_final.pdf} (2003).
949:
950: \bibitem{Erl:2004:SOA}
951: T.~Erl, {Service-Oriented Architecture: A Field Guide to Integrating XML and
952: Web Services}, Prentice Hall PTR, 2004.
953:
954: \end{thebibliography}
955:
956: \end{document}
957: