airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shameera Rathnayaka <shameerai...@gmail.com>
Subject Re: Airavata GSoC 2013 Master Project
Date Thu, 25 Apr 2013 07:22:21 GMT
Hi suresh,

Are there any place we can find the presentations and animations you used
in hangout session? If not could you please share with us?. Those are very
good detailed resources to understand how airavata works.

Thanks,
Shameera.


On Tue, Apr 23, 2013 at 10:52 PM, Shameera Rathnayaka <
shameerainfo@gmail.com> 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 <smarru@apache.org> 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-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/
>> > >
>> >
>> >
>>
>>
>
>
> --
> 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/

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