Hi Vijayendra, On Apr 15, 2013, at 7:43 AM, Vijayendra Grampurohit <[email protected]> wrote:
> Hi , > > Adding to above discussions and my take on the application. > > Referring back to the Airavata wiki ,It can be observed that there are > four major components > Application Registration UI, > Web based workflow composer, > Web based experiment builder, > Web based workflow monitor. > > Application Registration UI (front end) can be built using html5 along with > javascript . As suggested by subho we can build the web interface in MVC > model . Apart from AngularJs and Backbone JS which were suggested , I think > we can also go for Spine JS . It is similar to backbone js but has some > advantages over it . One good thing about the Spine is that the library is > broken into separate files. Spine core, ajax, local storage and routes are > separate files so it’s possible to pick which one to include in our apps > and avoid loading unnecessary code.And also it also has good documentation Since few of you are exploring the libraries, once the projects start, we probably should have a week or two focused on evaluation criteria and critic each others suggestions. > . Moving on, Application Registration UI talks to Airavata service > interface (API) in turn to Registry . This is currently done using > SAOP/WSDL . As we are trying to build a browser based portal we could use > JSON for communication between UI and Airavata server. Here if you think > changing to JSON suddenly is not a good idea then what I suggest is we > can build a interface before (Airavata service interface api) where in it > again converts JSON to SOAP . So the communication with browser and our new > interface will be JSON while that between our new interface and Airavata > server will be in SOAP. In this was we can solve the problem. We have focused lately on the POJO Airavata Client API, the reason for not having a service layer around is intentional. We wanted to first fully stabilize the API and service layers were distracting. More over the initial gateways integrating with Airavata were java based (with an exception of couple) so it worked well. Now is a good time to start exploring the service API. So your plan for injecting a intermediary RESTful service is a good one, but make sure you only talk to the client API and have it improved and avoid talking to internal components like Registry. This will ensure there is a abstraction layer which will not prevent internal components from evolving. Once the summer projects finish, we can all brainstorm how to make all these into a clean architecture. > [2]Going to second part that is Web Based workflow composer . Here as > suggested by andun we can use any of the libraries for drag and drop > feature. > We in our project(openshift visual workflows ) which was built in MVC > model, we had used JSplumb which integrated nicely with AngularJS. > once this graph is submitted this graph has to be interpreted by the > workflow interpreter and then if everything is fine communication happens > with Airavata Generic Application Factory (GFac) which facilitates users to > create Web Services wrapping command-line applications. Please correct me > if I am wrong here. You right to most extent. Workflow Interpreter will orchestrate individual tasks within the workflow and the tasks can be external web services or GFac generated services. In the case of later, Interpreter will invoke GFac with the service id and the input message (with all input name value pairs) and the context header. Gfac will go to registry to pull the service, application and host descriptions needed to execute the job on computational resources. For this goal of compose, the target is to generate the correct XWF file, either within the browser (I hear all of you that it is complex) so at the intermediary web service layer which needs to be developed as part of GSoC. Saminda has worked a lot of this piece and I will let him answer in detail. > [3]Once the graph is parsed and communication happens with GFac we are > ready for Experiment Builder . The experiment builder launches the workflow > . and finally workflow monitor comes into picture. Yes this is correct. > > [4]Web Based workflow monitor : The current workflow Monitor in the Xbaya > UI is good enough we can build a similar in web based portal. Exactly. Here you can resuse the compose, but the challenge is to map the notification events and color changes. I listed this one, because the goal for this monitoring should influence the design decisions of the composer. > > Please correct me if I am wrong anywhere. > > Here we have four different components , but they are tightly coupled . All > of the components will have to be addressed simultaneously. This is exactly right. So I suggest atleast 4 GSoC projects on this task, how to divide them is still open. Suresh > > Currently I am going through code base of Airavata . > > > Regards > Vijayendra > > > > > On Mon, Apr 15, 2013 at 2:39 PM, Andun Sameera <[email protected]> wrote: > >> 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 >>
