Hi Vijeyendra, The mailing lists does not sent attachments. Can you upload them to the wiki or put it on a web location?
Suresh On Apr 25, 2013, at 4:39 PM, Vijayendra Grampurohit <vijayendra....@gmail.com> wrote: > Hi > > 1] Currently the workflow description has the graph representation form > xbaya . > The data for the Workflow Inputs come from the Registry .This data is in wsdl > form which is stored > in the Registry. > There is also some metadata associated with wsdl . So that the client which > has to bind the input values can use it. > > As we are discussing in the line of developing a browser based application. > For constructing workflow we can make use of below graph library's > http://jsplumbtoolkit.com/jquery/demo.html > http://raphaeljs.com/ > In our project( Openshift workflows) we had used jsplumb library > which worked well with Angularjs . > > There are many more graph libraries which also can be explored. > > 2] Currently the data that is stored in Registry is of the form wsdl. > The workflow will use the data stored in the Registry . > For the new workflow as there is a discussion going on what kind of data are > we > going to store in registry (i.e wsdl or JSON ). This can be worked > accordingly. > > 3] Monitoring tool : I am thinking in terms of a > browser plugin or a simple java script based web based monitoring which will > notify users on workflow progress in real time. > This can be developed as a separate module . > The Monitoring tool subscribes to a pre-specified topic to which > Workflow Engine and GFac are publishing status notifications.Then the > monitoring > tool translates these messages and shows to to the user in the front end. > Please see the image inserted. > > > > What we can also do , When user is executing a very large workflow > with hundreds of variables and doesn't want to track every thing, Then we > can have a option to > which allows customization in the monitoring tool . > My point is we can have features in which user can monitor > the variables or data he wants. > > Please correct me if I am wrong any where. > > Regards > Vijayendra > > > > > > On Thu, Apr 25, 2013 at 7:08 PM, Suresh Marru <sma...@apache.org> wrote: > On Apr 23, 2013, at 8:01 AM, Suresh Marru <sma...@apache.org> wrote: > > > Great discussion Shameera & Subho. > > > > Looks like you guys have a fair idea on what needs to be done, as you both > > state, a week or two into GSOC, you can narrow down on design and > > specifications and so forth. Given there are multiple students tackling > > these issues collectively, if there are hard decisions to make, I would > > suggest to try two approaches in parallel and quickly pick one after a > > proof of concept. > > Can you all discuss the workflow composition strategies related to the data > model the same way we discussed application descriptions? > > We need to decompose the master project into smaller, well aligned projects > this weekend. So please start posting ideas on how to sub-divide the projects. > > Suresh > > > > > Suresh > > > > On Apr 23, 2013, at 3:43 AM, Subho Banerjee <subs.z...@gmail.com> wrote: > > > >> Well exactly, as long as you can define standard way of communication. That > >> is, you can define in advance what should be a string, array and what > >> should be a integer etc. We have no problem. > >> > >> So, when you look at problems, with JSON <-> XML or the other way round, > >> they talk of the very general case (where you no nothing about the data you > >> are converting other than it is valid XML/JSON). There are a myriad of > >> problems in that case, which you pointed out. > >> > >> But when there is standard, there is only one way of doing things, and not > >> several. I think that is the way forward. So what I am proposing is maybe > >> we all discuss and define this standard within the first week of GSoC > >> starting and then actually move into coding. So as long as we work with the > >> presumption that this will be done, we really dont have to worry a lot > >> about this. > >> > >> Cheers, > >> Subho. > >> > >> > >> On Tue, Apr 23, 2013 at 11:52 AM, Shameera Rathnayaka < > >> shameerai...@gmail.com> wrote: > >> > >>> Hi, > >>> > >>> On Tue, Apr 23, 2013 at 2:25 AM, Subho Banerjee <subs.z...@gmail.com> > >>> wrote: > >>> > >>>> Some of these problems are very specific to what the XML is > >>> representing, > >>>> it might not be an actual problem in Airavata, > >>>> maybe some one more experienced with the codebase can point this out. > >>>> > >>> > >>> All issues pointed out in the paper is not directly valid to our > >>> conversion, I didn't list the issues actually need to address in this case > >>> because thought it is worth to read that introduction part which explain > >>> the all the issues we have with this conversion and give us a solid > >>> background of that. > >>> > >>>> 1. Anonymous values, Arrays, Implicit Typing, Character sets -- I > >>> really > >>>> dont see these as problems, as long as you can agree that all parts of > >>>> airavata will treat the JSON in a standard (probably we have to define > >>>> this) way. > >>>> > >>> > >>> > >>> The issue with JSON array only comes when we try to convert XML to JSON > >>> not > >>> the other way. If we map with JSON, inputparameters and outputparameters > >>> in > >>> the ServiceDescription.xsd will map with JSON Arrays. Therefore we need to > >>> solve this issue. > >>> > >>> JSON XML JSON > >>> {"inputs":["test"]} --> <inputs>test<inputs> --> {"inputs":["test"]} // > >>> correct one > >>> --> {"inputs":"test"} // incorrect one > >>> > >>> 2. Namespaces, Processing Instructions -- Is this required? > >>> > >>>> Are separate namespaces used in Airavata? Only place I can see this > >>>> being > >>>> used is probably in the WSDL, but if we can agree on another way > >>>> of communicating registered applications' I/O parameters to the front > >>>> end > >>>> (JSON based), then maybe we can work around this (minor) problem. Are > >>>> custom processing instructions to the Xbaya XML parse even used? > >>>> 3. Attributes -- Again, this can be fixed easily > >>>> > >>> > >>> Yes,attributes convertion will not be a big issues we can solve it. As > >>> Lahiru mentioned in Hangout session namesapce handling is not a big issue > >>> with Airavata. > >>> > >>> > >>> > >>>> > >>>> <array name="abc"> > >>>> <element>1</element> > >>>> <element>2</element> > >>>> <element>3</element> > >>>> <element>4</element> > >>>> </array> > >>>> > >>>> Can become > >>>> > >>>> { > >>>> > >>>> abc : ['1', '2', '3', '4'] > >>>> > >>>> } > >>>> > >>> > >>> With this example it show us we need to change the XML message format of > >>> server side, which require to change the all schemas, If we are going to > >>> change the schemas then we need to change the way it process it in > >>> Ariavara > >>> core. We have dropped our initial major requirement, which is keep the > >>> Airavata Server side as it is. > >>> > >>> with this conversion we only deal with json strings, yes we can send JSON > >>> request with other formats supported by JSON like boolen, null, Number > >>> etc.. But there is no way to get the same JSON from XML as XML only deal > >>> only with Strings. I think it is good if we can consume a this features > >>> with JSON. > >>> > >>> let say i need to send a integer or float to the server using JSON then > >>> proper way is to send {"<name>":123.45} this will works fine but problem > >>> is > >>> how we get the same output ? > >>> > >>> Thanks, > >>> Shameera. > >>> > >>> > >>>> > >>>> > >>>> Cheers, > >>>> Subho. > >>>> > >>> > >>> > >>> > >>> -- > >>> Best Regards, > >>> Shameera Rathnayaka. > >>> > >>> Blog : http://shameerarathnayaka.blogspot.com/ > >>> > > > >
