airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Airavata GSoC 2013 Master Project
Date Tue, 16 Apr 2013 11:06:58 GMT

On Apr 15, 2013, at 3:41 AM, Subho Banerjee <subs.zero@gmail.com> wrote:

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

If we were two pursue JSON for descriptions applications and workflow, we need to explore
validations. I wonder if there are any good implementations of the json-schema validation
spec - http://tools.ietf.org/pdf/draft-fge-json-schema-validation-00.pdf

Suresh

> 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
View raw message