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