«

»

Application Specification Language (ASL)

Language motivation and goals

Application deployment process in grid environment is a non-trivial task and the user has to first determine what resources are available and then decide which is the most suitable resource for that particular application. Typically, HPC applications are developed using a specific programming language and parallel programming paradigm (e.g., compiler directive-based, threads, message-passing, combination of threads and message-passing) and often times the programming paradigm chosen decides the application deployment platform. If the application uses a shared-memory programming paradigm then the application can be only deployed on a shared memory system whereas an application developed using the message-passing paradigm can be deployed on both distributed memory and shared memory systems. Furthermore, applications might require specific processor architecture, amount of memory, disk space, etc. to deliver desired performance and scalability. An application developer could describe these application requirements and dependencies using some sort of application descriptors and also add hints about various performance implications and space/time tradeoffs. For commercial software packages, information about licensing and subscription could also be provided by the descriptors. A resource broker could also take advantage of such descriptors during resource selection and job scheduling. While the task of application deployment on a grid is quite challenging, the task of using various applications deployed on the grid is not any simpler. Users have a variety of applications to choose from for performing a specific task. Many applications exist that provide the same or similar functionality, yet often there are subtle differences among those such as programming paradigms used (e.g., shared memory, distributed memory), algorithms employed (e.g., search, sort methods), resource requirements (e.g., memory size, number of processors), numerical accuracy, scalability, and performance. While these differences are interesting to a domain-expert, for an end users who is interested in getting a problem solved with a particular quality of service (QoS) requirement (say, find the most accurate solution for this problem, or find the fastest solution to this problem) there are too many options to choose from. In order to make the best possible application selection that matches users QoS requirement, a typical user would require significant domain expertise, HPC expertise, as well as application expertise. To address these goals of user accessibility, there is a need to standardize and simplify the process of application deployment and use on the grid. As a step in that direction, we present a new language specification along the lines of JSDL called the Application Specification Language (ASL) that can be used to describe details of a given application. ASL allows an individual application to be represented in heterogeneous world of grid computing by capturing its purpose, functionality, and options. Using ASL, application descriptions can be made available for immediate use or further advancements among applications such as application deployers, automated interface generators, job schedulers, and application-specific on-demand help provisioning. ASL can also be used to describe how an application is compared and/or combined with other matching services and software, thus also supporting idea of workflow systems. This ability to specify the composition of services can facilitate the creation of new and added functionality, as well as enabling further advancement of existing tools that can take advantage of the provided information.

Language description

ASL is an XML based language where each document consists of four distinct yet related sections. These sections provide segregation of information collection and retrieval and include the following: application name and description, installation requirements, job invocation requirements, and hints.

Application name and description

The application name and description section contains the most basic information about an application and acts as the application identification component. It specifies the name and version of the application as can be found in an application repository. This section also contains sub-elements such as the application description describing the application in a human readable format. The description identifies the problem the application solves and maps the application to an application category.

Installation requirements

The installation requirements section of an ASL document contains a set of required elements that describe the pre-installation requirements as well as the installation procedure. Some of the examples of this type of element set include minimum processor speed, processor architecture, minimum amount of disk needed for installation of the application, libraries, applications required for the installation procedure (e.g., compilers, (un)packaging tools), licenses needed for application installation, network requirements, and required amount of disk space for the installation.

Job invocation requirements

The job invocation requirements section focuses on providing a user with the information needed to execute the application. Starting with the executable name, it also provides the available switches and minimum hardware requirements, as well as allows the developer to specify the number of input and output files with examples of their respective formats. This section does not represent a duplication of effort found in JSDL/RSL, but it is alternatively used to specify requirements for the entire application. Such specification is needed not only when executing a single job, but to describe the available options and how to use them. Rather than specifying exact input files and other job-specific parameters, the category defines application requirements, such as: the required input files, required format of those files, any output files and corresponding format, libraries required to invoke the application, and licenses needed to run it. This capability can be viewed as a more detailed version of man pages in UNIX. This category allows the developer to be shielded through a contract-like document enforcing application requirements before correct execution.

Hints

Due to the inherent variability of applications, information describing an application may not be adequately captured in the preceding sections of ASL due to non-compliance and uniqueness of the application. The purpose of information in this Hints section is to allow detailed descriptions for areas of high application complexity, either for application users or other developers who may use this application as a base for development. This section contains instructions and comments, mostly in natural language, providing additional application information. Another important goal behind this section and its element set is that it can be accessed and edited by a wide user group thus providing opportunities for collaboration and community effort to be aggregated in single space.

Current schema

Examples of ASL documents

  • QuerySplit.asl – a sequential application written in perl
  • dBLAST.asl – a grid-enabled, master-worker application for efficiently executing BLAST jobs on the grid.
  • MatMul.asl – an MPI implementation of Cannon’s matrix-matrix multiplication algorithm.
  • pga.asl – a parallel implementation of genetic algorithm application for data mining.

People

Publications

  • Afgan E., Bangalore P., “Application Specification Language (ASL) – A Language for Describing Applications in Grid Computing”, 4th International Conference on Grid Service Engineering and Management – GSEM 2007, Leipzig, Germany, Sept. 24-26, 2007. PDF
  • Afgan E., Bangalore P., Gray J., “A Domain-Specific Language for Describing Grid Applications”, Designing Software-Intensive Systems: Methods and Principles