On Apr 15, 2013, at 3:41 AM, Subho Banerjee <[email protected]> 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.
