UNICOREpro has been designed in a way that computing centers running UNICOREpro application servers completely retain their autonomy to authorize users and allocate resources to them. A site providing services to UNICOREpro is called a UNICOREpro Site, shortened Usite. A Usite may contain one or more computing resources called Virtual Site, shortened Vsite, which may be a single computer, an SMP machine or a cluster of machines. A Vsite is managed by a single NJS.
This structure is reflected in the structure of an UNICOREpro job. A job is modelled as a directed acyclic graph (DAG) of tasks and sub-jobs which may contain other tasks and sub-jobs. On the user level, a task cannot be divided into smaller execution parts. All tasks of a job or sub-job are executed on the same Virtual Site (Vsite). However, a sub-job (i.e. its tasks) may be executed on a different Vsite than the main job.
The interaction between a UNICOREpro client and its server is transaction based and asynchronous. This means that a job is submitted to a UNICOREpro server and only the receipt of the job is acknowledged (transaction). The client does not wait for the completion of the job. The idea behind this is to provide a better support for mobile users and slow connections.
The Pallas UNICOREpro client reflects this by providing two separate parts: the Job Preparation (sometimes called Job Preparation Agent: JPA) and the Job Monitoring (also known as Job Monitoring and Control: JMC).
Each job runs in a dedicated file space on the execution system called the Uspace. The Uspace only exists during the execution of the job. Any files needed by the application have to be imported into the Uspace, either from permanent storage on the execution system (Xspace) or from the local computer the client is running on (Nspace). Vice versa, files that must survive the end of the job have to be exported explicitly.