airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Airavata GSoC 2013 Master Project
Date Tue, 23 Apr 2013 12:14:26 GMT
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 <vijayendra.sdm@gmail.com> 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 <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. 
> 
> 
> 
> 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/alternative (inline, None, 0 bytes)
View raw message