Hi, On Mon, Apr 15, 2013 at 1:11 PM, Subho Banerjee <[email protected]> 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 > 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.
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 - http://www.insightforfuture.blogspot.com/ LinkedIn - http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703 Twitter -http://twitter.com/AndunSLG
