Hi All, Thank you for attending the hangout and the discussion was very informative. I hope the projects are bit more clear now. I added the slides now to end of the wiki page - https://cwiki.apache.org/confluence/display/AIRAVATA/GSoC+2013
Unfortunately my naive google hangout experience did not record the hangout. I set the on-Air but that did not work out. Any one with google hangout expertise please post instructions on how to pre-schedule events with hangouts on the air. Give it a try first to see if it works. Cheers, Suresh On Apr 25, 2013, at 4:59 AM, Danushka Menikkumbura <[email protected]> wrote: > Yes. Please. > > Missed it completely during exam time. > > Thanks, > Danushka > > > On Thu, Apr 25, 2013 at 12:57 PM, Vijayendra Grampurohit < > [email protected]> wrote: > >> Hi Suresh >> >> Can you also share the hangout discussion video . It would be helpful in >> writing proposals. >> >> Regards >> Vijayendra >> >> >> On Thu, Apr 25, 2013 at 12:52 PM, Shameera Rathnayaka < >> [email protected]> wrote: >> >>> Hi suresh, >>> >>> Are there any place we can find the presentations and animations you used >>> in hangout session? If not could you please share with us?. Those are >> very >>> good detailed resources to understand how airavata works. >>> >>> Thanks, >>> Shameera. >>> >>> >>> On Tue, Apr 23, 2013 at 10:52 PM, Shameera Rathnayaka < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> Yes it is not easy to solve all problems, But defining our own standard >>> or >>>> adhere to any standard >>>> provided by third party library will solve the problem to some extend. >>>> >>>> Here i see two possible approaches, >>>> >>>> 1. Use existing third party library(we can find which is best) adhere >> to >>>> it standard and see how we change the >>>> backend to be inline with it. >>>> >>>> 2. Use our own convention with help of XMLSchema (The way i suggest). >>>> >>>> As Suresh mentioned we can do a POC with both approaches to compare >>>> performance >>>> and changes need to be done in server side. Then select the best one. >>>> >>>> Another question was, can we works with graph data in JSON format. >>>> There are few JS graph framworks[1] which provide that functionality. >>>> we can use one of them to show airavata monitoring data as graphs >>>> >>>> Thanks, >>>> Shameera. >>>> >>>> [1] jqPlot <http://www.jqplot.com/index.php> , D3 <http://d3js.org/> , >>>> Processing.js <http://processingjs.org> , Sencha Charts< >>> http://www.sencha.com/products/extjs/> >>>> >>>> >>>> On Tue, Apr 23, 2013 at 5:44 PM, Suresh Marru <[email protected]> >> wrote: >>>> >>>>> Hi Vijeyandra, >>>>> >>>>> Airavata Messaging is based on a pub-sub model and the events >> themselves >>>>> are xml (WS-Eventing [1]). >>>>> >>>>> The Messenger paper [2] should give you more information. >>>>> >>>>> Hi All (Especially those at WS02): >>>>> >>>>> Here is an old effort from a Morotuwa undergrad project, you may want >> to >>>>> read through these papers and chat with the authors to get >> experiences: >>>>> >>>>> http://dl.acm.org/citation.cfm?id=1890807 >>>>> http://mgc2010.lncc.br/slides-pdf/Mooshabaya_Final_Presentation.pdf >>>>> http://kkpradeeban.blogspot.com/2010/09/mooshabaya-story-behind.html >>>>> http://mooshabaya.wikidot.com/ >>>>> >>>>> >>> >> http://chamibuddhika.wordpress.com/2009/10/06/mooshabaya-generates-mashups-from-workflows/ >>>>> >>>>> Suresh >>>>> [1] - http://www.w3.org/Submission/WS-Eventing/ >>>>> [2] - >>>>> >>> http://www.extreme.indiana.edu/xgws/messenger/doc/HuangY-WSMessenger.pdf >>>>> >>>>> On Apr 23, 2013, at 6:20 AM, Vijayendra Grampurohit < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Suresh >>>>>> >>>>>> I wanted to know more about the monitoring tool . >>>>>> Currently from where does the monitoring tool gets data . Is it from >>>>>> workflow interpreter ? or Is it from the WS Messenger ( that might >>>>> continuously >>>>>> send messages to monitoring tool as to tell how much is the progress >>>>>> and what are the variables getting changed) ? >>>>>> >>>>>> Again the how is the data being exchanged. I guess it must be xml ? >>>>>> It must be one way data exchange . I mean the data is TO the >>>>>> monitoring module. >>>>>> Then monitoring Tool is sending back this >>>>>> data to Xbaya for displaying to the user ? Please correct me if I am >>>>> wrong >>>>>> >>>>>> I have downloaded the source code from the trunk . can you please >>> point >>>>>> me which part of code should I be code at for this module. >>>>>> >>>>>> Regards >>>>>> Vijayendra >>>>>> >>>>>> >>>>>> On Tue, Apr 23, 2013 at 3:16 PM, Vijayendra Grampurohit < >>>>> [email protected]> wrote: >>>>>> Hi >>>>>> >>>>>> What i am suggesting is, we send the JSON message directly to >> Airavata >>>>>> Backend(or Registry) >>>>>> When the message gets build after the transport phase, convert JSON >>>>> message >>>>>> to SOAP(XML). >>>>>> From that point message will treated as SOAP message. >>>>>> >>>>>> If we look at the JSON <--> XML conversion there are set of third >>> party >>>>>> libraries we >>>>>> can use for. But before selecting a one we need to think about >>> problems >>>>>> having >>>>>> >>>>>> with JSON <--> XML and how these libraries handle those issues. >>> Because >>>>> we >>>>>> need a robust >>>>>> way to do this conversions. >>>>>> >>>>>> >>>>>> >>>>>> Shameera what you are suggesting is sending the JSON message >> directly >>>>> to Registry. >>>>>> when the message gets built after the transport phase , convert it >> to >>>>> SOAP . >>>>>> >>>>>> If you are suggesting Registry will have JSON data instead of WSDL , >>>>> Then this might >>>>>> complicate the things for us . >>>>>> The workflow interpreter needs wsdl(xml) to interpret the workflows >>> and >>>>> for other details . >>>>>> Which means we might again have to do some changes with workflow >>>>> interpretor . >>>>>> Yesterday from what I heard in discussion is that , they do not want >>> to >>>>> mess with workflow >>>>>> interpreter atleast for GSOC projects. >>>>>> >>>>>> What I want to suggest is , why carry the JSON data till Regisrty . >>>>> Build a interface >>>>>> before (Apache server API) where we can do the necessary conversion >>>>> (JSON to SOAP). >>>>>> In this way we can avoid messing up with Airavata server as a whole. >>>>>> Client ( using a we browser) is interacting with JSON (web service) >>> but >>>>> the Apache server >>>>>> is interacting with SOAP. >>>>>> >>>>>> >>>>>> >>>>>> Secondly yesterday Suresh was speaking about validating the >>> connections >>>>> of the workflow. >>>>>> for example , the workflow is expecting a file as input >>>>>> but user is giving a sting or int . >>>>>> >>>>>> Here what I suggest is , while creating wsdl in the registry for a >>>>> particular >>>>>> workflow , we can add extra information in the form of >>>>>> annotation as the kind of input/ output the workflow is accepting. >>>>>> Then we will be able to check these against users entry during >>>>> execution. >>>>>> Please correct me if I am wrong. >>>>>> >>>>>> Regards >>>>>> Vijayendra >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 23, 2013 at 1:13 PM, Subho Banerjee < >> [email protected]> >>>>> 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 < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, Apr 23, 2013 at 2:25 AM, Subho Banerjee < >>> [email protected]> >>>>>>> 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/ >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> Shameera Rathnayaka. >>>> >>>> Blog : http://shameerarathnayaka.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> Best Regards, >>> Shameera Rathnayaka. >>> >>> email: shameera AT apache.org , shameerainfo AT gmail.com >>> Blog : http://shameerarathnayaka.blogspot.com/ >>> >>
