airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Airavata GSoC 2013 Master Project
Date Mon, 15 Apr 2013 11:17:50 GMT

On Apr 15, 2013, at 3:41 AM, 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.

Hi Subho, 

This is great thinking and exactly inline with what we need to be exploring the emerging JS
frameworks. We have been hearing about Angular JS in Apache Rave [1] and even some implementations

>   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. 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.

JSON is the direction we want to go. But we need a gsoc student who is interested to focus
just on these aspects. This project will have to be little exploratory and understand pros
and cons better. But will be a good workshop paper by itself. 

>   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.

A big + 1 for this approach. This is both forward looking and also evolutionary. 
> 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.

Don't hold off with any questions, ask as many as you can until u t familiar. A good start.

[1]  -
[2] -

> Thanks.
> Cheers,
> Subho.

View raw message