airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andun Sameera Liyanagunawardana (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AIRAVATA-798) [GSoC] Web based Workflow Composer for Airavata
Date Tue, 26 Mar 2013 18:37:18 GMT

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

Andun Sameera Liyanagunawardana edited comment on AIRAVATA-798 at 3/26/13 6:36 PM:
-----------------------------------------------------------------------------------

Hi Suresh,

I have digged deep in to the source code via debugging to see how the XBaya create Workflows,
persists them local file system, persists them in registry. I understood following things,

- All the workflow design happens on top of the org.apache.airavata.xbaya.ui.graph.GraphCanvas
- The workflow data represented via  the org.apache.airavata.workflow.model.wf.Workflow (
I think this is the DAG representation which you are talking about in Airavat Architecture)
- Local file system persistences, retrieving done via org.apache.airavata.xbaya.core.generators.WorkflowFiler
- Registry based persistence, retrieving has done via the REST client org.apache.airavata.rest.clientUserWorkflowResourceClient

So If I focus on the task of implementing Web based Workflow Composer for Airavata, IMO we
can reuse all three other than 1st one. 1st one have to be replace with a JavaScript based
implementation. When that handles design part all the other things related to workflow can
be done reusing the others. Since WorkflowFiler is a XBaya class, we have to refactor it to
bring inside this web based implementation 

Is that approach is appropriate or do we have to come from the scratch  for this web based
implementation ? (Because you have mentioned that we are in the initial step to move to a
web based UI for Airavata)

Thanks
AndunSLG
                
      was (Author: andunslg):
    Hi Suresh,

I have digged deep in to the source code via debugging to see how the XBaya create Workflows,
persists them local file system, persists them in registry. I understood following things,

- All the workflow design happens on top of the org.apache.airavata.xbaya.ui.graph.GraphCanvas
- The workflow data represented via  the org.apache.airavata.workflow.model.wf.Workflow
- Local file system persistences, retrieving done via org.apache.airavata.xbaya.core.generators.WorkflowFiler
- Registry based persistence, retrieving has done via the REST client org.apache.airavata.rest.clientUserWorkflowResourceClient

So If I focus on the task of implementing Web based Workflow Composer for Airavata, IMO we
can reuse all three other than 1st one. 1st one have to be replace with a JavaScript based
implementation. When that handles design part all the other things related to workflow can
be done reusing the others. Since WorkflowFiler is a XBaya class, we have to refactor it to
bring inside this web based implementation 

Is that approach is appropriate or do we have to come from the scratch  for this web based
implementation ? (Because you have mentioned that we are in the initial step to move to a
web based UI for Airavata)

Thanks
AndunSLG
                  
> [GSoC] Web based Workflow Composer for Airavata 
> ------------------------------------------------
>
>                 Key: AIRAVATA-798
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-798
>             Project: Airavata
>          Issue Type: New Feature
>          Components: Workflow Interpreter, XBaya
>            Reporter: Suresh Marru
>              Labels: gsoc2013, mentor
>
> Apache Airavata users construct workflows by chaining together set of applications and
web services resulting in a graphical representation of workflows. These workflows composed
by drag and drop features build a abstract and high lever workflow languages.Currently Airavata
XBaya services these needs and is implemented in Java Swing. Similarly XBaya was also implemented
in Flex.
> This project focuses on developing a web based version of the workflow composition and
monitoring interface similar in functionality to XBaya. Currently XBaya WSDL operations and
message type definition determines both the number of input/output parameters that the component
has and the data type of each parameter. Messages are general XML and can have deeply-nested
structures.  However, XBaya treats the child elements of the root of a message as independent
parameters. The type of each parameter can be any simple type (string, integer, etc.), array,
or a complex type. The potential student can evaluate the use of WSDL and come up with alternatives.

> The student for this task has to be prepared to work extensively in java script to build
the drag drop interface. WSDL knowledge will be preferred but not mandatory, that can be acquired.

> User community & Impact of the software: Airavata is a general purpose distributed
systems software. It is used to build science gateways supporting research and education in
chemistry, life sciences, biophysics, environmental sciences, geosciences astronomy and nuclear
physics. The goal of airavata is to enhance productivity of these gateways to utilize cyberinfrastructure
of resources (e.g., local lab resources, the Extreme Science and Engineering Discovery Environment
(XSEDE), the Open Science Grid (OSG), University Clusters, Academic and Commercial Computational
Clouds like FutureGrid & Amazon EC2). By using open community based software components
and services like Airavata, gateways will be able to focus on providing additional scientific
capabilities and to expanding the number of supported users. The capabilities of these gateways
will offer clear benefits to society.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message