Hi All, I understood what you meant. Will read more about the things which you have highlighted in the wiki to have the full picture.
I had my particular interest about developing the web based workflow composer [1]. I had some discussion ,thoughts and finding about that particular idea. I will bring up those key thing here for the discussion, - Basic requirement for implementing this is to find a compilable JavaScript library which is capable of the particular task of designing a workflow by drag and drop, connecting items etc. For that I have came across these and currently analyzing them to find the suitable one, http://hawt.io/ http://www.playframework.com/ http://jqueryui.com/ http://jsplumbtoolkit.com/jquery/demo.html http://raphaeljs.com/ http://kineticjs.com/ - The Data Model which is used underline the web based workflow composer can be built by looking at the existing XBaya UI. So I have did some debugging and found these, # All the workflow design happens on top of the org.apache.airavata.xbaya.ui.graph.GraphCanvas #The workflow data represented via the org.apache.airavata.workflow.model.wf.Workflow # Local file system persistence, retrieving done via org.apache.airavata.xbaya.core.generators.WorkflowFiler # Registry based persistence, retrieving has done via the REST client org.apache.airavata.rest.clientUserWorkflowResourceClient If there is no data model or service interface changes happen, we can build the web based workflow by looking at these easily. Thanks! On Mon, Apr 15, 2013 at 12:35 AM, Suresh Marru <[email protected]> wrote: > Hi Andun and others (i am sure every one has identical concerns): > > I am not intending everything within the wiki has to be accomplished by one. > They are easily 4 projects and may be more. But I want you all to understand > everything on the wiki because they are highly inter-related. For instance > you may feel a certain way of composing workflow may be better, but you need > to understand how the composed workflow will be used. Understanding > experiment builder concept will help what should be within the workflow graph > and so on. > > You are right, implementing a component will require you to do a proper > related study and so forth. Once all of you have the big picture in mind, you > can dive into a particular implementation being cognizant of how it will be > integrated. I am insisting all of this is happening on the mailing lists with > incremental contributions. > > This process certainly is complicated than a typical gsoc project, but as I > said before, this is to mitigate projects executed in isolation which do not > shape back to main code. And secondly these are issues most of the airavata > dev's are working with, so you will get good mentor interest. > > I put out the picture but did not describe individual steps, this is > intentional. I did not want to prescriptive on how it has to be. I just > wanted to be suggestive and open up to your thinking. > > Also note that, if you all convince well, everything can be replaced -- > including all the data models and service interfaces. But you will need to > have good justifications. I for myself will not be convinced if you say it is > a cool thing to do or it is a popular or buzzy thing. I will certainly be > more than convinced if you reason well how it will help address current > issues and will open up for future extensions. > > Suresh > > On Apr 14, 2013, at 2:11 PM, Andun Sameera <[email protected]> wrote: > >> Hi Suresh, >> >> I have read the GSOC 2013 wiki article. That describes a big process, >> which have to be followed very carefully. So I want to clear myself. >> >> As you mentioned in the wiki, perfect understanding Data Models and >> Service Interfaces is mandatory for a GSOC project. There are four >> major components in the Web based UI(Which are shown in the diagram). >> According to my knowledge, the generic task of all these component is >> to manipulate data models and use service interfaces to achieve the >> intended goal of the particular component. >> >> For an example, The component Application Registering UI should get >> some inputs from user about inputs out puts etc. about a application. >> Then it have to map those to ServiceMapSchema to create an Application >> and Register it in Airavata via Service Interfaces. >> >> Also as I understood Data Models and Service Interfaces are fixed >> things and we have to use these in our projects. But sometimes changes >> can happen. That is the point where four separate components >> implementation project have to communicate. Otherwise if we only have >> to use the exiting Data Models and Service Interfaces to implement >> these web based components, we can work separate. >> >> To divide these four major components to GSOC projects, we have to >> understand the related work load for each of the implementations. >> Sometimes these can be four project, more than four or less. >> >> Thanks! >> >> On Sun, Apr 14, 2013 at 10:56 PM, Suresh Marru <[email protected]> wrote: >>> Hi All, >>> >>> Also please do not get too carries away with workflow description. >>> Airavata's key goal is to provide abstraction over distributed computing >>> applications. The decisions on what application description should look >>> like should be based on if it can cover all the intended use cases. The >>> Open Grid Forum's JSDL's specification will be a good reference for >>> skimming through - http://www.gridforum.org/documents/GFD.56.pdf >>> >>> Suresh >>> >>> On Apr 14, 2013, at 9:35 AM, Suresh Marru <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> As briefly discussed in [1], lets brainstorm enough on this thread before >>>> we can derive concrete GSoC projects and appropriate JIRA's. We have an >>>> opportunity to have multiple projects, but we would like to make sure they >>>> all align well. I drafted a overview of what can be potentially done - >>>> [2]. Please do not get overwhelmed by the sheer of changes, at the same >>>> time, it will be time consuming and also will require co-ordination with >>>> the community and other students. So please read [1] and make sure it >>>> matches your interest. >>>> >>>> Please start asking questions based on what you understand in [2] and lets >>>> go from there. I will keep expanding this wiki as we get the questions. We >>>> are roughly 2 weeks away from the proposal deadlines, so please hurry and >>>> understand the problem to tackle well. Then lets collectively identify the >>>> project which is "doable" within next 3 months and how we can break it >>>> down. If this is sounding too onerous for a GSoC project, I frankly >>>> suggest to look at other projects which might fit your time availability >>>> and get the project. Here we would like to use the mentor energy to >>>> accomplish tasks which can directly get into the main code base, write >>>> papers, see the projects in production and so on. The rewards will be >>>> certainly better than an average project, but the challenge and effort >>>> will be demanding. >>>> >>>> I will be relatively very responsive from now through proposal deadlines. >>>> I will hope others on the Airavata PMC will be as well. >>>> >>>> Thanks, >>>> Suresh >>>> >>>> [1] - http://markmail.org/message/rmotieckqj3a4xxv >>>> [2] - https://cwiki.apache.org/confluence/display/AIRAVATA/GSoC+2013 >>> >> >> >> >> -- >> 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 > -- 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 [1] -https://issues.apache.org/jira/browse/AIRAVATA-798
