The following question helps you to identify your requirements and navigates you to the scenario or to the combination of tools that will most likely help you to implement your ideas.
OK, then you can start implementing the scenario we recommended based on your answer for the question in the computational resources navigation section. Now, that you have decided on the way of workunit generation, please proceed to the question on application porting. Please, note that your choice regarding application porting will not effect the recommended scenario, only additional components might be needed to be installed under you BOINC project.
BOINC is prepared for such a situation, basically this is used mostly (mainly in public volunteer BOINC projects). In order to develop a workunit generator you will need a BOINC API (native BOINC facility) or a DC-API (high-level) interface that will talk to the BOINC backend system. We recommend to use the latter one as it is simpler and easier to use.
Now you can start implementing the scenario we recommended based on your answer for the question in the computational resources navigation section. Now, that you have decided on the way of workunit generation, please proceed to the question on application porting. Please, note that your choice regarding application porting will not effect the recommended scenario, only additional components might be needed to be installed under you BOINC project.
BOINC has its native tool for creating workunits from command line, called create_work. In case you are satisfied with his low-level tool, you can find it in the SZTAKI-BOINC package.
Alternatively, we recommend to use the web-service (SOAP) interface of the 3G Bridge, where workunit generation is done by 3G Bridge and the web-service interface provides an easy-to-use simplified command-line interface (CLI). Please, not that this interface does not support authentication, therefore please use it locally or make it safe by an appropriate firewall configuration.
The 3G Bridge with its WS CLI (SOAP) interface is already part of the Basic and Cloud scenarios, however if your answer in the computational resources navigation section resulted in a Core setup, we recommend you to upgrade it to the Basic setup.
Now, that you have decided on the way of workunit generation, please please proceed to the question on application porting. Please, note that your choice regarding application porting will not effect the recommended scenario, only additional components might be needed to be installed under you BOINC project.
BOINC has its native CLI tool for remote submission, called RemoteJobs. However, before using this tool, check the latest SZTAKI-BOINC version for this facility, since our package is not relying on the latest BOINC version.
Alternatively, we recommend to use the web-service (REST) interface of the 3G Bridge, where workunit generation is done by 3G Bridge and the web-service interface provides an easy-to-use simplified command-line interface (CLI). This interface supports authentication through an appropriate configuration of the apache server.
The 3G Bridge with its WS CLI (REST) interface is already part of the Basic and Cloud scenarios, however if your answer in the computational resources navigation section resulted in a Core setup, we recommend you to upgrade it to the Basic setup.
Now, that you have decided on the way of workunit generation, please please proceed to the question on application porting. Please, note that your choice regarding application porting will not effect the recommended scenario, only additional components might be needed to be installed under you BOINC project.
In order to use a web-based portal for submitting jobs (and workflows) we recommend to install gUSE (grid and cloud User Support Environment). The gUSE portal offers rich set of functionalities for handling your jobs and workflows. gUSE is capable of submitting job to 3G Bridge via its SOAP web-service interface.
The 3G Bridge with its WS CLI (SOAP) interface is already part of the Basic and Cloud scenarios, however if your answer in the computational resources navigation section resulted in a Core setup, we recommend you to upgrade it to the Basic setup.
Based on your answers at this point, we recommend you to use a Basic or Cloud setup with a SOAP WS interface combined with a gUSE portal. However, our complex setup called University Desktop Grid is a very similar configuration, so we recommend to go for it if it suits to your needs.
Now, that you have decided on the way of workunit generation, please proceed to the question on application porting. Please, note that your choice regarding application porting will not effect the recommended scenario, only additional components might be needed to be installed under you BOINC project.
For the automatic job transfer between different infrastructures there are alternatives. For bridging gLite jobs to your desktop grid site we have a scenario called gLite to DG] that you can use immediately. If you have a different type of grid infrastructure, please [[:contact|contact to the SZTAKI Desktop Grid team since there are other grid infrastructures (e.g. ARC, UNICORE) for which there are bridges, but not yet published on this site. Even more, the SZTAKI Desktop Grid team can give you assistance in developing a bridging solution for new infrastructure as well, if not yet available. Generally, if you are thinking in bridging jobs among DIFFERENT infrastructure, please go to the question on Bridging alternatives.
Now, that you have decided on the way of workunit generation, please proceed to the question on application porting. Please, note that your choice regarding application porting will not effect the recommended scenario, only additional components might be needed to be installed under you BOINC project.
