airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Grampurohit <>
Subject Re: Airavata GSoC 2013 Master Project
Date Mon, 15 Apr 2013 11:43:38 GMT
Hi ,

Adding to above discussions  and my take on the application.

Referring back to the Airavata wiki ,It can be observed that there  are
four  major components
Application Registration UI,
Web based workflow composer,
Web based experiment builder,
Web based workflow monitor.

Application Registration UI (front end) can be built using html5 along with
javascript . As suggested by subho we can build the web interface  in  MVC
model . Apart from AngularJs and Backbone JS which were suggested , I think
we can also go for Spine JS . It is similar to backbone js but has some
advantages over it . One good thing about the Spine is that the library is
broken into separate files. Spine core, ajax, local storage and routes are
separate files so it’s possible to pick which one to include in our apps
and avoid loading unnecessary code.And also it also has good documentation
. Moving on, Application Registration UI talks to Airavata service
interface (API)  in turn to Registry  . This is currently done using
SAOP/WSDL . As we are trying to build a browser based portal we could use
JSON for communication between UI and Airavata server. Here if you think
changing to JSON suddenly  is not a good idea then what I suggest is  we
can build a interface before  (Airavata service interface api) where in it
again converts JSON to SOAP . So the communication with browser and our new
interface will be JSON while that between our new interface and Airavata
server will be in SOAP. In this was we can solve the problem.

[2]Going to second part that is Web Based workflow composer . Here as
suggested by andun we can use any of the libraries for drag and drop
We in our project(openshift visual workflows )  which was built in MVC
model, we had used JSplumb which integrated nicely with AngularJS.
once this graph is submitted this graph has to be interpreted by the
workflow interpreter  and then if everything is fine  communication happens
with Airavata Generic Application Factory (GFac) which facilitates users to
create Web Services wrapping command-line applications. Please correct me
if I am wrong here.

[3]Once the graph is parsed and communication happens with GFac we are
ready for Experiment Builder . The experiment builder launches the workflow
. and finally workflow monitor comes into picture.

[4]Web Based workflow monitor : The current workflow Monitor in the Xbaya
UI is good enough we can build a similar in web based portal.

Please correct me if I am wrong anywhere.

Here we have four different components , but they are tightly coupled . All
of the components will have to be addressed simultaneously.

Currently I am going through code base of Airavata .


On Mon, Apr 15, 2013 at 2:39 PM, Andun Sameera <> wrote:

> Hi,
> On Mon, Apr 15, 2013 at 1:11 PM, Subho Banerjee <>
> wrote:
> > Hi,
> > I have been looking though some of the code as well as the documentation,
> > to come up with a concrete definition of what the project on composing
> web
> > based workflows for Airavata will entail. Building on what Andun pointed
> > out in his email, I would like to expand the definition of this project
> and
> > propose a solution which I think will work very well -
> >
> >    1. A* Web Interface* built using an MV* pattern, using a framework
> like
> >    AngularJS or BackboneJS (which are both MIT licensed) along with a
> >    presentation layer built using Twitter Bootstrap and the frameworks
> Andun
> >    enumerated in his email (which will try to replace the code in
> >    org.apache.airavata.xbaya.ui.graph.*). With, an MV* pattern, we can
> >    replicate the data model being used currently in
> >* quite easily. Now, once we
> have
> >    a validated graph (workflow) defined, we send this to the Airavata
> service
> >    in the form of a SOAP (XML) message.
> I was thinking the same as Subho has explained. That is the way we
> should do this.
> >    This is where I would like to suggest two major improvements, firstly,
> >    instead of having a workflow parser written separately in Java and
> >    Javascript, we can probably enumerate a set of rules which are
> required to
> >    validate the workflow, and then just read the file containing these
> rules
> >    and validate against them. What this does, is that any future changes
> in
> >    these rules will only imply changing the rules file instead of
> actually
> >    making changes in code.
> This is good idea. But I think this need lot of effort to understand
> all the scenario and coming up with a generic rule set.
> >    Now this brings me to my second suggestion, that
> >    of communication between the frontend and the Airavata service. This
> must
> >    be in a language that both understand. Though Java can handle SOAP
> (XML)
> >    very well, the same cannot be said about the browser. What I would
> like to
> >    suggest is instead of using SOAP, maybe we can come up with an
> equivalent
> >    JSON notation for this data. This is because it is a lot easier to
> compose,
> >    handle and modify JSON data when you are writing programs on a
> browser.
> >    This will involve, coming up with a JSON format for the data being
> >    transferred as well as interfacing this with the Airavata service.
> >    2. How I would like to go about this will be by building a
> *translator*.
> >    This will sit in between the Airavata service and the frontend and
> will
> >    convert JSON data from the browser to SOAP which the service
> understands
> >    and vice versa. The advantage of this will be that as new
> functionality is
> >    added to the frontend, a corresponding translator has to be added that
> >    would interface it with the Airavata service. So this will allow
> >    incremental development of the frontend making things easier. Also
> allowing
> >    people to change the Airavata service as required (maybe by some
> other GSoC
> >    project) without any conflicts. Now at a later date, if Airavata does
> >    accept JSON as standard for data exchange, the translator can be done
> away
> >    with and the frontend can be interface directly with the service.
> >
> This is a good idea. This will add a other GSOC project in to the
> picture I think :)
> > I am currently in the process of looking through the Xbaya code, and my
> > suggestions are from the point of view of someone who is not very well
> > acquainted with the codebase. So I am counting on your help to fix any
> > mistakes I have made and make a successful proposal for GSoC 2013.
> >
> > Thanks.
> >
> > Cheers,
> > Subho.
> Also I think we have to identify all the major small project in this
> big GSOC project and have to priorities them. Because I think we cant
> do all these things.
> Thanks!
> --
> Regards
> Andun S.L. Gunawardana
> Undergraduate
> Department of Computer Science And Engineering
> University of Moratuwa
> Sri Lanka
> Blog -
> LinkedIn -
> Twitter -

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