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. [image: Inline image 1] 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/ > > >
