Legion Web Service
|Language:||English • Español|
Legion Web Services (LWS)
LWS is an abstract layer because it represents a specification and not a particular implementation. A list of methods that must be exposed by a web service is given. With the implementation of these methods on top of a Grid Management System, the consumer application should be able to completely manage the grid. In a following section the customized implementation for BOINC is presented. Sometimes the concept of task is not implemented in a Grid Management Systems, so it is up to LWS to implement it. The methods LWS must expose are:
- Task_Inf: Allows retrieving the information of a task.
- Task_Progress: Allows retrieving the progress of a task.
- Task_Cancel: Allows canceling a task.
- Task_Result: Allows retrieving the result of a task.
- Task_List: Allows listing running tasks.
- Task_Create: Allows creating a task. A configuration file (config.xml) is a required parameter of this method - More details here. This file should indicate the input filenames, result filenames, the command line to run the executable files and specification of loops for the generation of computing units.
- User_Add: Allows adding a user.
- User_Validate: Allows validating user’s credentials.
The implementation must support the SOAP with Attachments (SwA) standard since the transfer of binary files is mandatory.
Legion Web Services for BOINC (LWSB)
In order to allow Legion Framework to work with BOINC, a custom LWS component was developed. The main purpose of LSWB is to provide access to the resources of a BOINC Desktop Grid via SOAP and not only for LWI consumption, but it is intended to provide a general-purpose web services interface for BOINC. BOINC doesn’t support the concept of task as we see in Legion, so it was necessary to implement it in LWSB. We chose Python as the language to implement the LWSB component because there are already several tools for BOINC written in that language. The developed component allows the BOINC server to interact with LWI for adding and authenticating users, to create tasks made up of smaller work units following the config.xml specification, to post-process a task, to retrieve the status of tasks, to retrieve the result of tasks when finished and canceling a task.
In order to work with tasks, it was necessary to save some information about them. With this in mind, a table named 'Task' was created inside the BOINC Project database scheme. This table stores the information associated with the task: name, how many work units it has, the current state which could be: creating, executing, canceled or finished; also, there are fields for storing execution time, CPU time and consumed FLOPS which are obtained from the work units as they are being completed. The way for relating work units inside a task is by using a field named hash whose value is shared between work units in the 'batch' field of the table 'workunit'.
Furthermore, a set of libraries were developed for reading the config.xml file, distributing the input files, and for creating the files required by BOINC: job.xml, work unit templates, result templates. Also a custom Assimilator was developed in order to update the fields in the table Task as work units were finished and in order to execute additional operations such as result-files concatenation and/or compression. After the execution of the task is finished, the Assimilator copies the result-files to a preconfigured folder and sends an email alerting the operator. In case an error happens during execution of a work unit belonging to a task, the Assimilator automatically cancels the task and alerts the operator with an email.