Service Layer

The middle tier or service layer comprises all services and components of the UNICORE Service-Oriented Architecture (SOA) based on WS-RF 1.2, SOAP, and WS-I standards.

Gateway

The Gateway component acts as the entry point to a UNICORE site and performs the authentication of all incoming requests. From the UNICORE perspective it is the "door to the outside world" in a site firewall and may serve several resources/target systems behind it.

XNJS

The XNJS component is the job management and execution engine of UNICORE 6; the heart of a UNICORE 6 site. It provides storage resources, file transfer services and job management services. The functionality of the XNJS is accessible via two service interfaces in UNICORE's WS-RF hosting environment:

UNICORE's proprietary interface is called UAS (= UNICORE Atomic Services) and offers the full functionality to higher level services, clients and users.
A standardised set of interfaces based on open, common standards (OGSA-*) is available in UNICORE 6 in addition to the UAS. Currently implemented standards are OGSA-BES and HPC-P, used for the creation, monitoring and control of jobs.

The UNICORE job definition is compliant with the JSDL (+ JSDL HPC extensions) standard. For file transfers (site-to-site and client-to-site), a variety of protocols are available (HTTPs, OGSA Byte-IO, GridFTP and UDT).

IDB

The IDB (Incarnation Data Base) performs the job incarnation, namely the mapping of the abstract job description in JSDL to the concrete job description for a specific resource. Information about available applications and resource characteristics has to be defined in this database.

XUUDB

For authorisation of users the XNJS uses the XUUDB user database to perform the mapping from X.509 certificates to the actual users' logins and roles. The XUUDB component is a Web service in itself, so it can be used from multiple UNICORE installations, e.g. within the same computing centre. Full X.509 certificates are used as base line, while the access control is based on XACML policies. Proxy certificates are optionally supported in UNICORE 6 e.g. to use GridFTP.

UVOS

As an alternative to the XUUDB, a Virtual Organisation (VO) service can be used for user authorisation. The UNICORE VO Service (UVOS) uses the SAML standard and offers a wide variety of features.

Registry

Like many service-oriented environments, a global service registry is available, where the different services can register once they are started. A single service registry is necessary to build-up and operate a distributed UNICORE infrastructure. This service registry is contacted by the clients in order to "connect to the Grid". Therefore it is the central service of a UNICORE 6 Grid. Like the XNJS, the service registry runs in UNICORE's WS-RF hosting environment.

CIS

The Common Information Service (CIS) is the information service of UNICORE 6. It gathers both static and dynamic information from all connected XNJS, which are then displayed either in raw XML or human-readible text form. As longitude and latitude information is also stored, a google maps view allows a geographical representation of the Grid infrastructure.

CIS is based on the GLUE 2.0 standard from. Like with the registry, a central CIS is necessary in an operational UNICORE infrastructure.

Workflow Engine

The workflow support in UNICORE 6 is implemented as a two-layered architecture consisting of a workflow engine and the service orchestrator layers. Besides enhanced scalability this also has the benefit of a plugable workflow engine. Different workflow description dialects, which comply to domain-specific requirements, can be plugged in. Due to the service oriented approach, even plugging in a complete different workflow engine is possible. The currently available workflow engine is based on the open-source Shark XPDL engine and was developed within the Chemomentum project.

The workflow features of UNICORE 6 can be used from both the graphical UNICORE Rich client as well as from the command line with UCC.

Service Orchestrator

The service orchestrator layer is responsible to executing the individual tasks in a workflow, handling job execution and monitoring on the Grid. Different brokering strategies are implemented to find the best suited resources for each workflow step. Other brokering strategies can easily be plugged-in. To increase performance and scalability of the service orchestrator layer, multiple instances can be installed.