airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Web based Workflow Execution Interface
Date Sun, 23 Jun 2013 13:46:03 GMT
Hi Sanchit,

Can you please attach the architecture again? You are doing the right thing in understating
DynamicWorkflowRunner. But that gives you an understanding on how the workflow inputs and
context are used in executing the graph. But your project should focus on passing the information
with the right format and right level of details and not so much on how it will be used to
execute. The key challenge I see for your work is to provide complex interfaces so they are
simple and easy to use for basic cases, at the same time provide flexibility and advanced
configurations so power users can override the default workflow execution behavior. 

I have not yet looked at the assembler you sent here, but I would not worry about integrating
with maven build to start with. Thats a worry towards the end. But be cautious of any licenses
right from the beginning. 

On Jun 23, 2013, at 9:16 AM, Sanchit Aggarwal <> wrote:

> Hi Suresh,
> Actually I was going through the attached architecture and got bit confused.
> So its more like interface with a form for the composed workflow, setting all the context
information and the inputs and then invoking the interpreter,(similar to the window displayed
when the workflow is executed ) thus mimicking the xbaya.
> so do we also have to come up with the execution parser similar to the xbaya interpreter
(org.apache.airavata.xbaya.interpretor) or just invoking it using the JSON-XML bridge?
> Also what are your suggestions on using brunch which is an application development assembler
for HTML5 applications. Please find the link here. 
> My only concern is how to integrate it with the present Airavata Maven build?
> Regards
> Sanchit Aggarwal
> MS Research (Computer Science)
> Center for Visual Information Technology
> IIIT Hyderabad, Gachibowli
> Contact - 9581417330
> On Sun, Jun 23, 2013 at 6:20 PM, Suresh Marru <> wrote:
> Hi Sanchit,
> This understanding counters your proposal altogether. Please read what you have proposed,
there is no mention on BPEL/DAG. The native XWF format will give you all the required inputs
and your project is about building an interface to efficiently configure inputs, set the workflow
execution context and launch it to Workflow Interpreter. This execution interface need not
have an understanding of the underlying workflow language. It just needs to understand inputs,
and provide intuitive interfaces to provide inputs, specify resources to run the workflow.
> Suresh
> On Jun 1, 2013, at 10:18 AM, Sanchit Aggarwal <> wrote:
> > Hi Suresh
> >
> > My understanding on the workflow execution is that the Condor DAG/BPEL
> > is formed after the composition of the workflow which is than
> > interpreted by the axis2 based workflow interpreter web service. The
> > workflow execution context is used to specify the parameters for
> > scheduling , handling of inputs etc. This execution context is given
> > from the Xbaya GUI where the context header and other are taken a s a
> > input. Finally a Executable is formed which is then used for running
> > the job by GFac.
> >
> > So according to the above understanding, I guess The Execution
> > interface has to be developed which will export the composed workflow
> > to various workflow languages like BPEL/DAG etc. Please correct me If
> > I am wrong.
> >
> > Since not much has been discussed on the execution interface module of
> > the master project ,could we have more inputs on the same.
> >
> >
> >
> > Regards
> > Sanchit Aggarwal
> >
> >
> >
> > On Fri, May 31, 2013 at 6:36 PM, Suresh Marru <> wrote:
> >> Sanchit,
> >>
> >> Yes lets start the discussion. Please take the lead and post your understanding
and ask specific questions.
> >>
> >> Suresh
> >>
> >> On May 31, 2013, at 7:32 AM, Sanchit Aggarwal <>
> >>
> >>> Hi Heshan/All
> >>>
> >>> I am covering workflow execution interface part of the master project
> >>> in my sub-project.Since the current implementation of the workflow
> >>> execution context specification is expressed in xml schema encompassed
> >>> within the workflow wsdl it has to be re-framed.
> >>> Can we all start discussing here so to get a better understanding of
> >>> workflow execution context and its representation?
> >>>
> >>> Regards
> >>> Sanchit Aggarwal
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message