airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Marru (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AIRAVATA-991) Craft the Airavata 1.0 API
Date Tue, 18 Feb 2014 20:42:19 GMT

    [ https://issues.apache.org/jira/browse/AIRAVATA-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904558#comment-13904558
] 

Suresh Marru commented on AIRAVATA-991:
---------------------------------------

Hi All,

As we work through the API and Data models, we need to determine how simple application execution
(the application itself may be complex process like a large MPI, but a single invocation)
and composite applications (embodied in workflows) should be handled. There are multiple ways
of doing this:

1) Have the API functions separate from workflows to create, launch and get status and data
for a single node application. The API server absorbs the difference, the rest of the system
is agnostic of the simple vs composite executions and the resulting data.

2) Have two different parallel paths all the way through the system.

3) Have the API functions, data model agnostics, but at the registry level the data is organized
differently for wokrlfows and applications. 

4) Within Airavata, keep the entire trace agnostic (except the orchestrator invoking gfac
directly or through interpreter) and expect the clients to do the heavy lifting.

Thoughts? 


> Craft the Airavata 1.0 API
> --------------------------
>
>                 Key: AIRAVATA-991
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-991
>             Project: Airavata
>          Issue Type: Story
>          Components: Airavata API
>    Affects Versions: 0.11
>            Reporter: Suresh Marru
>            Assignee: Suresh Marru
>             Fix For: 1.0
>
>
> An important goal for Airavata 1.0 release is to draft a public facing API which  includes
subset of functionality exposed by the internal SPI and higher level functions which can be
realized by one of more internal components. 
> Airavata clients have to be abstracted from internal component level details and would
like to interact through API through higher order method. Some of the capabilities include
abilities to Register gateways, computational credentials, register and manage applications,
create, configure and launch experiments (binding them to applications/workflows), monitor
real-time and poll based progress, query for generated data and analyze results. 
> These capabilities can be realized by one or more internal Airavata components and the
API layers abstracts these out and maps appropriately. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message