airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: Airavata GSoC 2013 Master Project
Date Thu, 25 Apr 2013 08:59:14 GMT
Yes. Please.

Missed it completely during exam time.

Thanks,
Danushka


On Thu, Apr 25, 2013 at 12:57 PM, Vijayendra Grampurohit <
vijayendra.sdm@gmail.com> wrote:

> Hi Suresh
>
> Can you also share the hangout discussion video . It would be helpful in
> writing proposals.
>
> Regards
> Vijayendra
>
>
> On Thu, Apr 25, 2013 at 12:52 PM, Shameera Rathnayaka <
> shameerainfo@gmail.com> wrote:
>
> > 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