The Opal toolkit provides a mechanism to wrap up existing scientific applications rapidly as Web services, and expose them to various clients. The implementation provides features such as scheduling (e.g. using Condor and SGE via Globus or DRMAA) and security (using GSI-based certificates), Furthermore, the service provides job and data management (by executing every job in a separate working directory), and state management (by storing the service state via Hibernate into a database such as HSQL, PostgreSQL, MySQL or DB2). The application developer specifies a configuration for a scientific application and deploys the application as a service following a small sequence of steps. End-users can now access this application remotely using the WSDL of the service.
The WSDL for the service is defined inside wsdl/opal.wsdl. Stub generators provided by Web service toolkits are then used to generate the client and server-side bindings for the services. In our case, the services are implemented in Java using the Apache Axis toolkit, while the clients can be in any language.
The WSDL defines operations to do the following:
Get application metadata (getAppMetadata): This returns metadata about the application. This includes usage information, along with any number of arbitrary application-specific metadata specified as an array of info elements, e.g. description of the various options that are passed to the application binary. Ideally, these elements should be arbitrary XML's (specified by xsd:any tags). However, due to the limitations of certains toolkits in other languages (e.g. ZSI in Python), we specify them as Strings for now. You may embed XML tags inside them using CDATA sections. The metadata also (optionally) includes the types element, which describes the command-line arguments for the application, described in the Advanced Submission Form section
Launch job (launchJob): This operation requires the list of arguments as a string, and an array of structures representing the input files. The structure contains the name of the input file and either the contents in Base64 encoded binary form or a MIME attachment, or simply a location (URL) to the associated file. The operation returns a Job ID that can be used to retrieve job status and outputs.
Query job status (queryStatus): This operation expects a Job ID to query the status of a running job. A status code, message, and URL of the working directory for the job are returned.
Get job outputs (getOutputs): This operation returns the outputs from a job that is identified by a Job ID. The output consists of the urls for the standard output and error, and an array of structures representing the output files. The structure contains the name of the output file and the url from where it can be downloaded.
Get output file by name (getOutputAsBase64ByName): This operation returns the contents of an output file as Base64 binary. The input is a data structure that contains the Job ID for a particular job, and the name of the file to be retrieved.
Destroy job (destroy): This operation destroys a running job identified by a Job ID.
Get job statistics (getJobStatistics): This operation returns basic job statistics including start time, activation time and completion time for a given Job ID.
Launch blocking job (launchJobBlocking): This operation requires the list of arguments as a string, and an array of structures representing the input files. The structure contains the name of the input file and the contents in Base64 encoded binary form. The operation blocks until the remote execution is complete, and returns job outputs (as described above) as the response. This operation may only be appropriate for jobs that are not long running.
Get system information (getSystemInfo): This operation returns basic system information for the Opal server, including the number of total and free CPUs, number of jobs running, number of jobs queued, the job manager being used, etc.
Please see here for some Opal use cases.