Hi Suresh In order to start with the JSON schema validation I have been looking into some of the libraries.
I am going through [1] which has been implemented in java script and has complete implementation for the current draft of JSON schema draft.We can use it to model the workflow execution context, since its developed in javascript it will also be compatible with the new Xbaya interfaces. It has BSD license,so I don't think there are any licensing issue. Any inputs? [1] https://github.com/garycourt/JSV Regards Sanchit Aggarwal MS Research (Computer Science) Center for Visual Information Technology IIIT Hyderabad, Gachibowli Contact - 9581417330 On Fri, Jun 28, 2013 at 9:02 PM, Sanchit Aggarwal < [email protected]> wrote: > Hi Suresh > > yes, the concrete end-to-end use case will be helpful in understanding the > required goals which we are aiming for. > > Regards > Sanchit Aggarwa > > > > On Fri, Jun 28, 2013 at 7:58 PM, Suresh Marru <[email protected]> wrote: > >> On Jun 28, 2013, at 10:13 AM, Sanchit Aggarwal < >> [email protected]> wrote: >> >> > Hi suresh >> > >> > It seems that the attachments are getting dropped. >> >> Yes, I raised an INFRA JIRA - >> https://issues.apache.org/jira/browse/INFRA-6471 which is pending to be >> addressed. >> >> > However you can find the >> > link of the architecture >> > here<http://airavata.apache.org/architecture/workflow.html> >> > . >> > >> > so the big picture is that,execution interface will validate the inputs >> > for the composed workflow against a schema written in JSON and similar >> to >> > the workflow execution >> > context< >> https://svn.apache.org/repos/asf/airavata/trunk/modules/commons/workflow-execution-context/src/main/resources/workflow_execution_context.xsd >> > >> > and >> > then pass the set context to the interpreter? >> >> This is the basic step, once you get to this step, we need to complicate >> with more real-world execution patterns and passing advance configurations. >> >> > Is there anything other than >> > this which I am missing here? >> >> I would suggest to start with this and make progress and we can build >> from there. >> >> > >> > Also I see that there is the functionality to pause and resume the >> workflow >> > execution but for the advance configuration like adding the checkpoints >> and >> > functionality to resume from the failure point, is there any >> implementation >> > in the Gfac? >> >> There are some partial implementations but nothing concrete. But your >> execution interface should take into consideration to enable the user to >> these kind of capabilities. >> >> Will it be useful for you to have a concrete end-to-end use case instead >> of envisioning this from a abstract sense? >> >> Cheers, >> Suresh >> >> > >> > >> > Regards >> > Sanchit Aggarwal >> > >> > >> > >> > On Sun, Jun 23, 2013 at 7:16 PM, Suresh Marru <[email protected]> >> wrote: >> > >> >> Hi Sanchit, >> >> >> >> Can you please attach the architecture again? You are doing the right >> >> thing in understating DynamicWorkflowRunner. But that gives you an >> >> understanding on how the workflow inputs and context are used in >> executing >> >> the graph. But your project should focus on passing the information >> with >> >> the right format and right level of details and not so much on how it >> will >> >> be used to execute. The key challenge I see for your work is to provide >> >> complex interfaces so they are simple and easy to use for basic cases, >> at >> >> the same time provide flexibility and advanced configurations so power >> >> users can override the default workflow execution behavior. >> >> >> >> I have not yet looked at the assembler you sent here, but I would not >> >> worry about integrating with maven build to start with. Thats a worry >> >> towards the end. But be cautious of any licenses right from the >> beginning. >> >> >> >> Suresh >> >> On Jun 23, 2013, at 9:16 AM, Sanchit Aggarwal < >> [email protected]> >> >> wrote: >> >> >> >>> Hi Suresh, >> >>> >> >>> Actually I was going through the attached architecture and got bit >> >> confused. >> >>> >> >>> So its more like interface with a form for the composed workflow, >> >> setting all the context information and the inputs and then invoking >> the >> >> interpreter,(similar to the window displayed when the workflow is >> executed >> >> DynamicWorkflowRunnerWindow.java ) thus mimicking the xbaya. >> >>> >> >>> so do we also have to come up with the execution parser similar to the >> >> xbaya interpreter (org.apache.airavata.xbaya.interpretor) or just >> invoking >> >> it using the JSON-XML bridge? >> >>> >> >>> Also what are your suggestions on using brunch which is an application >> >> development assembler for HTML5 applications. Please find the link >> here. >> >>> My only concern is how to integrate it with the present Airavata Maven >> >> build? >> >>> >> >>> >> >>> Regards >> >>> Sanchit Aggarwal >> >>> MS Research (Computer Science) >> >>> Center for Visual Information Technology >> >>> IIIT Hyderabad, Gachibowli >> >>> Contact - 9581417330 >> >>> >> >>> >> >>> >> >>> On Sun, Jun 23, 2013 at 6:20 PM, Suresh Marru <[email protected]> >> wrote: >> >>> Hi Sanchit, >> >>> >> >>> This understanding counters your proposal altogether. Please read what >> >> you have proposed, there is no mention on BPEL/DAG. The native XWF >> format >> >> will give you all the required inputs and your project is about >> building an >> >> interface to efficiently configure inputs, set the workflow execution >> >> context and launch it to Workflow Interpreter. This execution interface >> >> need not have an understanding of the underlying workflow language. It >> just >> >> needs to understand inputs, and provide intuitive interfaces to provide >> >> inputs, specify resources to run the workflow. >> >>> >> >>> Suresh >> >>> >> >>> On Jun 1, 2013, at 10:18 AM, Sanchit Aggarwal < >> >> [email protected]> wrote: >> >>> >> >>>> Hi Suresh >> >>>> >> >>>> My understanding on the workflow execution is that the Condor >> DAG/BPEL >> >>>> is formed after the composition of the workflow which is than >> >>>> interpreted by the axis2 based workflow interpreter web service. The >> >>>> workflow execution context is used to specify the parameters for >> >>>> scheduling , handling of inputs etc. This execution context is given >> >>>> from the Xbaya GUI where the context header and other are taken a s a >> >>>> input. Finally a Executable is formed which is then used for running >> >>>> the job by GFac. >> >>>> >> >>>> So according to the above understanding, I guess The Execution >> >>>> interface has to be developed which will export the composed workflow >> >>>> to various workflow languages like BPEL/DAG etc. Please correct me If >> >>>> I am wrong. >> >>>> >> >>>> Since not much has been discussed on the execution interface module >> of >> >>>> the master project ,could we have more inputs on the same. >> >>>> >> >>>> >> >>>> >> >>>> Regards >> >>>> Sanchit Aggarwal >> >>>> >> >>>> >> >>>> >> >>>> On Fri, May 31, 2013 at 6:36 PM, Suresh Marru <[email protected]> >> >> wrote: >> >>>>> Sanchit, >> >>>>> >> >>>>> Yes lets start the discussion. Please take the lead and post your >> >> understanding and ask specific questions. >> >>>>> >> >>>>> Suresh >> >>>>> >> >>>>> On May 31, 2013, at 7:32 AM, Sanchit Aggarwal < >> >> [email protected]> wrote: >> >>>>> >> >>>>>> Hi Heshan/All >> >>>>>> >> >>>>>> I am covering workflow execution interface part of the master >> project >> >>>>>> in my sub-project.Since the current implementation of the workflow >> >>>>>> execution context specification is expressed in xml schema >> >> encompassed >> >>>>>> within the workflow wsdl it has to be re-framed. >> >>>>>> Can we all start discussing here so to get a better understanding >> of >> >>>>>> workflow execution context and its representation? >> >>>>>> >> >>>>>> Regards >> >>>>>> Sanchit Aggarwal >> >>>>> >> >>> >> >>> >> >> >> >> >> >> >
