Yes this need to be done in melange system. Mentors can do that. I will take a look to tag Airavata proposals.
Thanks Raminder On May 3, 2013, at 1:12 PM, Danushka Menikkumbura wrote: > Well I did not do anything specifically. Maybe a reviewer hooked it up?. > Not sure. All I did was to use the same name that was used in the > corresponding JIRA ticket. > > Thanks, > Danushka > > > On Fri, May 3, 2013 at 9:13 PM, Viknes Balasubramanee <[email protected]>wrote: > >> Hey Guys, >> >> Can you please share in the list how to associate our proposal with a >> specific project. >> >> Thanks >> Viknes >> >> -----Original Message----- >> From: Suresh Marru [mailto:[email protected]] >> Sent: Friday, May 03, 2013 9:11 AM >> To: [email protected] >> Subject: Re: Airavata GSoC 2013 Master Project >> >> Hi Subho, >> >> I do not see your proposal associated with Airavata. May be Danushka or >> Shameera can tell you how they tagged it to airavata. >> >> Suresh >> >> On May 3, 2013, at 8:43 AM, Subho Banerjee <[email protected]> wrote: >> >>> Hi, >>> You can find a rough draft of my proposal at >>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/sub >>> hobanerjee/13001 >>> >>> I am now working against the clock (6 hours left) to iron out the >>> edges and to put in any content I am missing. >>> >>> Any comments would be welcome. >>> >>> Cheers, >>> Subho, >>> >>> >>> On Fri, May 3, 2013 at 5:24 PM, Danushka Menikkumbura < >>> [email protected]> wrote: >>> >>>> Please find the proposal for "AMQP Messaging protocol support for >>>> Airavata WS-Messenger" at [1] >>>> >>>> Thanks, >>>> Danushka >>>> >>>> [1] - >>>> >>>> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc20 >>>> 13/danushka/1# >>>> >>>> >>>> On Thu, May 2, 2013 at 7:56 PM, Suresh Marru <[email protected]> wrote: >>>> >>>>> Ping!! No proposals yet beyond Shameera's and Danushka's place holder. >>>>> >>>>> Suresh >>>>> >>>>> On May 1, 2013, at 5:13 PM, Suresh Marru <[email protected]> wrote: >>>>> >>>>>> Hi Vijayendra, >>>>>> >>>>>> As you can see from Shameera's proposal, he proposed a JSON >>>>>> conversion >>>>> in front of WS Messenger. Also Danuska has been proposing for the >>>>> AMQP >>>> and >>>>> idea and deliberating its advantages. So given all these, I would >>>>> suggest for you to keep focused on the UI aspects of the monitoring >>>>> and write >>>> into >>>>> your proposal a plan for determining a good strategy for the >>>>> plumbing to WS-Eventing based existing system. You can have the >>>>> concrete deliverables of new UI to change colors based on executions >>>>> (as it currently does in XBaya), double click and show error >>>>> messages and so forth. And keep it exploratory for the actually >> messaging format. >>>>>> >>>>>> I do not have any opinion on the libraries you mentioned, but yaa a >>>> ajax >>>>> based pub system might be the right way to go. Pending the content >>>>> format (JSON or WS-Eventing or JMS or AMQP or something else) >>>>>> >>>>>> Suresh >>>>>> >>>>>> On May 1, 2013, at 4:13 PM, Vijayendra Grampurohit < >>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Suresh >>>>>>> >>>>>>> I am writing proposal for monitoring tool . The monitoring tool is >>>>> based on >>>>>>> pub-sub model (ws-messenger). >>>>>>> While writing proposal , I have to back it by technical stuff that >>>> tells >>>>>>> how can we achieve our purpose. >>>>>>> As this monitoring tool is supposed to be a web based , and we are >>>>> thinking >>>>>>> in the lines of >>>>>>> developing it in javascript. >>>>>>> I was looking into javascript libraries that can we used with >>>>> ws-messenger >>>>>>> in the monitoring module. >>>>>>> Please correct me if I am wrong. >>>>>>> I came across some of the libraries >>>>>>> >>>>>>> - jQuery custom >>>>>>> events< >>>>> http://weblog.bocoup.com/publishsubscribe-with-jquery-custom-events> >>>>>>> - AmplifyJS Pub/Sub <http://amplifyjs.com/api/pubsub/> >>>>>>> - PubSubJS <https://github.com/mroderick/PubSubJS> >>>>>>> - js-signals <http://millermedeiros.github.com/js-signals/> >>>>>>> >>>>>>> please tell me am I thinking in right direction? >>>>>>> >>>>>>> Regards >>>>>>> Vijayendra >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 1, 2013 at 5:30 PM, Suresh Marru <[email protected]> >>>> wrote: >>>>>>> >>>>>>>> Hi Shameera, >>>>>>>> >>>>>>>> This is great, I appreciate you sharing it, I realize this is >>>>>>>> still working document, but I want other students to start seeing >>>>>>>> it and >>>>> model >>>>>>>> their proposals in a similar way. >>>>>>>> >>>>>>>> Airavata Mentors, >>>>>>>> >>>>>>>> Please provide feedback directly on the melange site and uncheck >>>>>>>> the "private" box when you comment. >>>>>>>> >>>>>>>> Suresh >>>>>>>> >>>>>>>> On May 1, 2013, at 7:52 AM, Shameera Rathnayaka < >>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Suresh and All, >>>>>>>>> >>>>>>>>> Of course I am very much happy to share my proposal with >>>>>>>>> everybody, actually i was going to update this thread with the >>>>>>>>> melange link in >>>>> few >>>>>>>>> hours once i have done writing all the sections in the proposal. >>>>>>>>> I >>>>>>>> haven't >>>>>>>>> yet added the milestone plan into it and now working on it. >>>>>>>>> >>>>>>>>> The sub area i am going to work from the Master project is ' >>>>>>>> Implementing >>>>>>>>> a JSON interface to Airavata Client side and Registry component'. >>>>> Here is >>>>>>>>> the link >>>>>>>>> >>>>>>>> >>>>> >>>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/sh >>>> ameera/60002# >>>>>>>>> . >>>>>>>>> >>>>>>>>> >>>>>>>>> Please note that i haven't completed everything in this and >>>>>>>>> still >>>>> doing >>>>>>>>> modifications .Therefore proposal content may be changed bit, >>>>>>>>> need >>>> to >>>>> add >>>>>>>>> more technical details of the approach which explains it well. >>>>>>>>> >>>>>>>>> I would like to know the feedback from all of you regarding the >>>>> proposal >>>>>>>>> and will be modifying it if there is anything to be done. Also >>>> please >>>>>>>>> contact me if you need any help and i am very much willing to >>>>>>>>> share >>>> my >>>>>>>>> thoughts with all. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Shameera >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 1, 2013 at 4:51 PM, Suresh Marru <[email protected]> >>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Shameera, >>>>>>>>>> >>>>>>>>>> Excellent proposal, great job. Would you mind to make your >>>> proposal >>>>>>>>>> public and post the link here? Your proposal should help others >>>>>>>>>> to >>>>> look >>>>>>>> at >>>>>>>>>> it and learn from. >>>>>>>>>> >>>>>>>>>> Again I emphasize to all students, please don't feel you will >>>>>>>>>> be >>>>>>>> competing >>>>>>>>>> with each others. If all of you write good proposals, there is >>>>>>>>>> a >>>> good >>>>>>>>>> chance all of you will be selected. But without a good >>>>>>>>>> proposal, we >>>>>>>> cannot >>>>>>>>>> help. >>>>>>>>>> >>>>>>>>>> Suresh >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Apr 23, 2013, at 1:22 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-ma >>>> shups-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/ >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>>> >> >>
