airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Grampurohit <vijayendra....@gmail.com>
Subject Re: Airavata GSoC 2013 Master Project
Date Tue, 23 Apr 2013 10:20:48 GMT
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 <
vijayendra.sdm@gmail.com> 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 <subs.zero@gmail.com>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 <
>> shameerainfo@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > On Tue, Apr 23, 2013 at 2:25 AM, Subho Banerjee <subs.zero@gmail.com>
>> > 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/
>> >
>>
>
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message