airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Subho Banerjee <subs.z...@gmail.com>
Subject Re: Airavata GSoC 2013 Master Project
Date Mon, 15 Apr 2013 07:41:21 GMT
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
   org.apache.airavata.workflow.model.wf.* 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.
   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.
   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.

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.

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