airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Airavata GSoC 2013 Master Project
Date Fri, 19 Apr 2013 17:37:20 GMT
Hi Shameera,

Thank you for the detailed email. I will address every one since this is a common misunderstanding.

Hi All,

We are not solving the problem of Airavata server reading SOAP messages. Please totally ignore
this fact. It is a 2 week project to move away from Axis2 and replace it with light weight
Jax-RS, thats a byproduct of the current gsoc projects but not the focus. 

Forget all service to service communications - that is clearly distracting.

The key focus of Airavata GSoC Master project is to find a solution to application description
and workflow composition. Please pay attention to the data model. Understand the GFac schema
and how it is used for workflow composition, binding workflow inputs. Second, understand how
workflow execution context is used in Airavata and propose an alternative. Propose an alternative
for these XML schemas. And how a web based XBaya can pull this document (currently XML) and
show a list of applications and allow users to construct workfows with them. Once you have
a workflow, a web interface should be able to load up the workflow and allow user to find
the type of it and also provide metadata about each inputs.

Summarizing again, the issues is not SOAP vs JSON. The issue is Airavata is using WSDL's for
describing application interfaces. A java script based workflow composer reading these wsdl's
will be heavy weight. So what is the light weight alternative, and how do we accomplish it?

A good way to learn this is, register a command line application in XBaya, and understanding
what is being saved in the registry. How it is saved is indeed through a RESTful Registry
service. So please debug through all these steps and get to bottom of this problem.


On Apr 19, 2013, at 1:11 PM, Shameera Rathnayaka <> wrote:

> Hi Suresh and All,
> Web based UI (with JS), it is always good to use JSON instead of SOAP as
> JSON is pretty much handy and easy with JS than SOAP. Not only that, when
> we consider the amount of data need to be transferred over network for a
> same message (native)JSON require less amount of data than SOAP. As this is
> a considerable fact when we deal about network traffic therefore JSON would
> be an idea solution.
> As Airavata backend has tuned to process SOAP messages(Axis2 which is used
> by Airavata server, is a SOAP processing web engine[1]) when we send a JSON
> message to either server or registry it needs to be transferred to SOAP
> (which is a costly operation) to further process. Here i am proposing a
> technique rather than transfer JSON to SOAP in first hand, we keep the JSON
> stream as it is and provide an interface ( XMLStreamReader/XMLStreamWriter)
> to get SOAP(XML) info-set while processing JSON Stream underneath. We can
> use AXIOM[2] like XML infoset compliant object model implementation which
> support on-demand building to read and write SOAP info-set on the fly. This
> implementation inline with axis2 implementations too, If I am correct,
> current REST calls are sent with SOAP request body but with this kind of
> improvement we can send REST call to Registry with JSON, which is most
> prefer data exchange language with REST.
> I have implemented this kind of scenario to improve Apache Axis2 JSON
> support(my previous reply refer to that) as my previous GSOC project. And
> it has good performance numbers than ADB(Axis2 Databinding).
> Either we can use currently available XML schema or introduce new JSON
> schema for this JSON messages(data structure of both schemas should be
> exact same). It is good to have separate JSON schemas for JSON messages
> even it has maintenance issue as we need to keep both schemas in sync. But
> as it is not encouraged to do schema changes this won't be an issue at all.
> Also Not only for Web base UI, we can further improve existing Java client
> api to send JSON messages to the server by implementing API interfaces for
> JSON data binding. With this either user can send SOAP or JSON messages to
> Server and Registry. Both messages treated as same in server side.
> Here i am addressing only JSON message transfer and processing phase of the
> master project. If everyone ok with this approach, I am very much happy to
> submit a proposal for this. And I hope this implementation can perfectly
> match with GSOC scope too.
> Any suggestions or alternatives are well come.
> Thanks,
> Shameera.
> [1]
> [2]
> On Fri, Apr 19, 2013 at 3:55 PM, Suresh Marru <> wrote:
>> Hi Vijayendra,
>> Please refer to [1]. The POJO Client API I referred to is the client which
>> talks to Registry. But the WSDL is about the application being described. I
>> will revisit this document again to bring this out clearly.
>> The SOAP/REST comes only on how a web or a stand alone java clients talks
>> to Airavata Server. For simplification, I would assume all services
>> interactions as JDBC connections. Lets forget a java script is not good
>> directly with JDBC. I am trying to make you all focus on saying, by some
>> exchange you will know how to put and get data from registry. Lets focus on
>> the data itself, and expressiveness. We can come back to the mechanics of
>> interactions, after you fully understand the data models.
>> So there is no POJO to WSDL conversion. The WSDL's in this context are the
>> description of the nodes within the workflow. WSDL's are used for these,
>> not for the SOAP reason, but since they envelop XML Schema of input/outputs
>> (annotated with metadata). XBaya only looks at the application service
>> WSDL's and extracts out the inputs and their types.
>> In the diagram in [1] ignore the lines, they can be SOAP, REST, or
>> something else. Focus on what is going on over the wire in A1, A2 and W1,
>> W2, W3.
>> Suresh
>> [1] -
>> On Apr 18, 2013, at 6:21 PM, Vijayendra Grampurohit <
>>> wrote:
>>> Hi Suresh
>>> In the above conversation you wrote * - We have focused lately on the
>>> Airavata Client API, the reason for not having a service layer around is
>>> intentional. We wanted to first fully stabilize the API and service
>> layers
>>> were distracting. More over the initial gateways integrating with
>> Airavata
>>> were java based (with an exception of couple) so it worked well. Now is a
>>> good time to start exploring the service API.
>>> *
>>> Here I have a small doubt. you wrote POJO interacts with the Airavata
>>> client API(Registry) ? But the data that is stored in the Registry is
>> wsdl
>>> . So it means the data is converted from  POJO to WSDL while storing in
>>> Registry . Is this correct ?
>>> Regards
>>> Vijayendra
>>> *
>>> *
>>> On Wed, Apr 17, 2013 at 6:30 PM, Shameera Rathnayaka <
>>>> wrote:
>>>> Hi devs,
>>>> FYI, Current Apache Axis2 trunk has new feature which provide XML
>> info-set
>>>> while processing JSON stream[1].( NOTE: Here it doesn't convert JSON to
>> XML
>>>> which is more cost effective). Even it implemented to Apache Axis2 it is
>>>> not tightly couple with aixs2, we can use that for our own purpose. I
>> think
>>>> it would be a good solution for this.
>>>> Thanks,
>>>> Shameera.
>>>> [1]
>>>> On Wed, Apr 17, 2013 at 4:02 PM, Sandeep Panem
>>>> <>wrote:
>>>>> Instead of an interface which converts json to soap and then sending
>> soap
>>>>> data to airavata services,we should follow standard data format of json
>>>>> which is compatible with all browsers and easily understandable and
>>>> reduces
>>>>> complexity.
>>>>> On Wed, Apr 17, 2013 at 2:13 AM, Mattmann, Chris A (398J) <
>>>>>> wrote:
>>>>>> Hey Guys,
>>>>>> Best way to find out is to email
>>>>>> I'll try and look at it either there or here and comment.
>>>>>> Cheers,
>>>>>> Chris
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> Chris Mattmann, Ph.D.
>>>>>> Senior Computer Scientist
>>>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>>>> Office: 171-266B, Mailstop: 171-246
>>>>>> Email:
>>>>>> WWW:
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> Adjunct Assistant Professor, Computer Science Department
>>>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> -----Original Message-----
>>>>>> From: Marlon Pierce <>
>>>>>> Reply-To: "" <>
>>>>>> Date: Tuesday, April 16, 2013 1:15 PM
>>>>>> To: "" <>
>>>>>> Subject: Re: Airavata GSoC 2013 Master Project
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>> That license doesn't look too bad, but I don't know how strict
>> need
>>>>>>> to be.  It is possible that the author, if contacted, will adopt
>>>>>>> Apache or Apache-compatible license.
>>>>>>> Marlon
>>>>>>> On 4/16/13 4:12 PM, Subho Banerjee wrote:
>>>>>>>>> If we were two pursue JSON for descriptions applications
>>>>>>>>> workflow, we need to explore validations. I wonder if
there are
>>>>>>>>> any good implementations of the json-schema validation
spec -
>>>>>>>>> From
>>>>>>> what I know, the best (open and closest to implementing the entire
>>>>>>>> spec) validator for JSON schemas is JSV[1]. I am not particularly
>>>>>>>> sure if this license[2] is compatible to the Apache license.
If it
>>>>>>>> is, then using this could be one way to go ahead. However,
in the
>>>>>>>> case that it is not compatible, then we might have to fork
>>>>>>>> sort of a half baked validator and modify it to suit the
needs of
>>>>>>>> the project. I will look into this and let you know what
I find.
>>>>>>>> [1] - [2] -
>>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>>>>>>> Comment: GPGTools -
>>>>>>> Comment: Using GnuPG with Thunderbird -
>>>>>>> W+lVr69MAhPdfiMUxqNjHZwJSjn0yU5b310/8rqQ5RMOw6BUHxAaKo3Iinhfq2xf
>>>>>>> DPyzhGrawiVuUXvkco6aUI4QmHqXl+7PpXC8Sr0o6FuATDNX7DcOrdlSK6Gp2MXi
>>>>>>> BrREBZ4LbY//yue5LkhKkGuz6q7tdBp94AQPrBnbtmTuI81uVBxCLOb0DUxkhOTE
>>>>>>> 87PgkhyWDyR+2wLwVze2Ng1EaUmADcElhRZvBtLqESFg2LoN4NDIzhBX/XdvxKaf
>>>>>>> vlgnmIZS+Uc7ftAijYuQPg4246RJKLDQYFr5Ms3tomu1vt4BHArNuMQdGzoflPs=
>>>>>>> =bQv0
>>>>>>> -----END PGP SIGNATURE-----
>>>>> --
>>>>> -Sandeep Panem
>>>> --
>>>> Best Regards,
>>>> Shameera Rathnayaka.
>>>> Blog :
> -- 
> Best Regards,
> Shameera Rathnayaka.
> Blog :

View raw message