Client Layer

On the top layer a variety of clients is available to the users, ranging from the command-line interface named UCC , the Eclipse-based UNICORE Rich Client to the programming API named HiLA .

UCC

The UNICORE command line client (UCC) is a very versatile command-line tool that allows users to access all features of the UNICORE service layer in a shell or scripting environment. 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. Additionally, workflows can be submitted and controlled with the UCC.
Snapshot of UCC (high-resolution image)

UCC includes several data management functions. Remote storages can be listed and files can be transferred from local to remote as well as from server to server. UCC can be used for administrative purposes as well, for example to list all 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" command allows the execution of scripts written in the Groovy programming language. A dedicated UCC mode for the popular Emacs editor is also available.

UNICORE Rich Client

The Eclipse-based UNICORE Rich Client (URC) offers the full set of functionalities to the users in a graphical representation. It targets a wide range of users with varying Grid and IT experience. It provides a useful graphical view of the Grid, which can be filtered in order to find specific resources, services or files. Detailed resource requirements for jobs (e.g. required number of CPUs, amount of RAM) can be 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.

Security and access control are essential aspects in distributed computing. Dedicated panels deal with setting up security options, so 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.

For a tight integration of various types of applications, the concept of GridBeans was invented. GridBeans are small software packages that provide tailored graphical user interfaces for scientific applications available on the Grid. The same packages are responsible for visualising the output data of scientific simulations once the jobs have been executed and output files have been downloaded to the client machine. Some basic GridBeans for executing scripts (perl, various shells, etc.) and running single commands are available by default. New GridBeans can easily be developed using the respective APIs and documentation.
Snapshot of UCC (high-resolution image)

Why is the Eclipse Framework used as basis? 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 plugin mechanism: every software component in an Eclipse-based client is a plugin, each of which adding a well-defined range of functions. Plugins interact with each other in various ways and almost every plugin provides programming interfaces which can be used to extend its functionality and outer appearance. Following this paradigm, the graphical UNICORE client is extremely extensible. For instance, integration of new Grid services or scientific applications is already accounted for in its design.

HiLA

HiLA is a High Level API for Grid Applications, that allows simple development of clients with just a few lines of code for otherwise complex functionality. It can also be used to integrate UNICORE 6 in user applications to e.g. directly submit simulation jobs to Grid resources without using UNICOREs command line or graphical clients. HiLA provides a single interface with multiple implementations for UNICORE 5, UNICORE 6 and OGSA-BES. HiLA is used to integrate UNICORE 6 access into DESHL (including SAGA support), as part of the DEISA portal, and to connect GAT with UNICORE 6. The nature 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 a object-oriented facade, presenting abstract representations of the underlying resources. Importantly, this includes encapsulating security configuration behind well defined interfaces, further enhancing the uncluttered API.

The resources of the Grid are named following a URI naming scheme, for example:
unicore6:/sites/FZJ_JUGGLE/storages/home or ogsa:/sites/GROW/ tasks/910c9b56-d497-46f8-960f-eaee43e1af37.
The object navigation is based on a container/item model. An example source code is:
Location l = new
Location("unicore6:/sites/GROW/tasks/910c9b56-d97-46af37");
Task t = HiLAFactory.getInstance().locate(l);

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 size() or isDirectory() on Files. HiLA is currently evolving further to allow it to operate concurrently over multiple resources to perform powerful collective data management and monitoring.

Portal

UNICORE 6 services can also be accessd from portals. One example is the support for UNICORE 6 in e.g. GridSphere resp. The Vine Toolkit.

NOTE: this is an external component, not developed and not under control by the UNICORE community.