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/ > > >
