On Tue, Jan 10, 2012 at 11:28 PM, Shameera Rathnayaka <
shameerai...@gmail.com> wrote:
>
>
> On Sat, Jan 7, 2012 at 5:21 PM, Amila Suriarachchi <
> amilasuriarach...@gmail.com> wrote:
>
>>
>>
>> On Sat, Jan 7, 2012 at 2:34 AM, Andreas Veithen <
>> andreas.veit...@gmail.com> wrote:
>>
>>> On Thu, Jan 5, 2012 at 05:57, Shameera Rathnayaka
>>> <shameerai...@gmail.com> wrote:
>>> > Here what i understood simply is under the 1st approch Inside the
>>> message
>>> > builder class i need to get the input stream and store it inside the
>>> message
>>> > context as a property to access later, while putting a dummy SOAP
>>> envelope.
>>> > And dispatching will be occurred request uri based.i.e dummy message
>>> would
>>> > be some thing like
>>> >
>>> >
>>>
>>> <soap:Envelope><soap:Body><ns:wrapper>Json</ns:wrapper></soap:Body></soap:Envelope>
>>> >
>>> > This input-stream is processed only inside the message receiver when
>>> gson
>>> > reads the input stream and create relavant java objects from that.
>>> >
>>> > Response is also handled same as request handle but bottom up way.
>>> >
>>> > In the 2nd approach Inside the message builder class i have to get the
>>> input
>>> > stream and build the Json String first and then store it as
>>>
>>> Not exactly. You would not read the input stream in the message
>>> builder, but construct a SOAPEnvelope that builds that representation
>>> lazily (using the OMSourcedElement/OMDataSource API). If something
>>> (e.g. a logging/auditing handler) between the message builder and the
>>> message receiver attempts to access the SOAPEnvelope, then the input
>>> stream will be read and the corresponding Axiom objects created on the
>>> fly. If the SOAPEnvelope reaches the message receiver untouched, then
>>> you would feed the input stream (more or less) directly to
>>> google-gson.
>>>
>>
>> Another option is to write an xmlstream reader/writer implementation to
>> parse the json stream. And provide that xml stream implementation to Axiom.
>>
>> This model works with other data bindings such as ADB as well.
>>
>
> If we use xmlstream reader/writer to parse the json stream. How it works
> with ADB ?
>
ADB I mean the ADB generated code. Which only uses the xmlstream API
instead of Axiom. Anyway Axiom is also written on top of xmlstream layer.
So if we can create a json type implementation for xmlstreams that will
work with any axis2 instance.
> as i know ADB needs xml representation of all elements to process i.e ADB
> create complex and simple types of relevant xml representation of the
> request, and process the request. But here we only have wrapped xml
> elements. Should i implement ADB to use with json?
>
>
>> thanks,
>> Amila.
>>
>>
>>>
>>> Once you start your GSOC project, we will point you to some samples
>>> (such as the plain text handling in Synapse) that show how this works.
>>>
>>> > <soap:Envelope><soap:Body>json-string</soap:Body></soap:Envelope> ,
>>> > json-string would be something like "method":{"name":"value"}.
>>> >
>>> > After that inside the message receiver it is processed using google
>>> gson.
>>> > It can be dispatched using request uri based and qname based as sagara
>>> > mentioned previous post.
>>> >
>>> > I'am interesting in doing these two approaches as the GSoc project.
>>> > According to the knowledge that i have in Axis2 this implementation
>>> > can be done. But not sure about the workload of each approach because
>>> > most probably i will meet lot of problems with these approaches.
>>> >
>>> >
>>> > About the analyzing part - First as a student i would like touch
>>> > architecture
>>> > and designing side also, But can you clarify your idea a little bit as
>>> i
>>> > have seen
>>> > there are few blog posts explaining why axis2 cant support Mapped
>>> > convention?.
>>> > Because it's not possible to know the namespace mappings used on one
>>> side
>>> > of the transport to the other side (client or service).
>>>
>>> The situation is actually somewhat similar to how WSDL 2.0 attempted
>>> to describe REST services: on one side you have a client that speaks
>>> REST (using various HTTP verbs, resource identifiers, etc.) and on the
>>> other side you have a Web service with an abstract interface that is
>>> described in terms of operations, messages and XML schema constructs.
>>> The Web service engine then also needs to know how to map REST
>>> requests/responses to operations, messages, etc. These mappings are
>>> described in a WSDL binding.
>>>
>>> In the case of mapped JSON, it's actually even simpler, because the
>>> engine "only" needs to map between JSON prefixes and XML namespaces.
>>> However, as in the REST/WSDL 2.0 case that mapping is specific to a
>>> given service. It would actually be trivial to implement something
>>> that lets the developer specify these mappings on a service (a service
>>> parameter would be enough for that), but the problem is that the
>>> message builder (which is responsible to generate the XML
>>> representation) doesn't know which service will be invoked and is
>>> therefore unable to locate that configuration.
>>>
>>> >
>>> > On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen <
>>> andreas.veit...@gmail.com>
>>> > wrote:
>>> >>
>>> >>
>>> >> I think that it would also be interesting to add another task in the
>>> >> scope of that GSOC project, namely to analyze why Axis2 doesn't have a
>>> >> good support for mapped JSON. In fact, if you look at Shameera's
>>> >> initial post, he (she?)
>>> >
>>> > It's he :)
>>> >
>>> >
>>> > Thanks
>>> > Shameera
>>> >
>>> >>
>>> >> takes the fact that "Mapped formatted JSON
>>> >> with namespaces are not supported in Axis2" as a basic assumption. The
>>> >> interesting question is actually why this is so. I was thinking about
>>> >> this a couple of months ago, and I believe that this is actually due
>>> >> to a too restrictive assumption that is made in the Axis2 architecture
>>> >> (which is that it is possible to construct a SOAP infoset solely based
>>> >> on the properties of the incoming message, i.e. the content of the
>>> >> message and its content type), and that this is connected to some
>>> >> other problems as well as the presence of code in Axis2 that doesn't
>>> >> fit naturally into the architecture.
>>> >>
>>> >> Fixing that properly would probably be out of scope for a GSOC
>>> >> project, but doing an analysis would be highly interesting, in
>>> >> particular if Shameera is interested not only in development, but also
>>> >> in architecture and design.
>>> >>
>>> >> I think that if one includes these different things into the proposal,
>>> >> it would indeed make a very interesting GSOC project. Can we agree on
>>> >> that?
>>> >>
>>> >> Andreas
>>> >>
>>> >> On Wed, Jan 4, 2012 at 13:54, Sagara Gunathunga
>>> >> <sagara.gunathu...@gmail.com> wrote:
>>> >> > This proposal is to address real issue with Axis2, that is in Axis2
>>> JSON
>>> >> > messages are not perform well as XML messages. Since we have enough
>>> time
>>> >> > for
>>> >> > GSoC we can decide the best approach for this. With your
>>> explanation 2nd
>>> >> > approach sound good to me , also this approach enable to use QName
>>> based
>>> >> > dispatching on JSON messages too.
>>> >> >
>>> >> > One design consideration need to fulfill is full streaming support
>>> in
>>> >> > builders/formatters level so that gson can process underline stream
>>> >> > directly, otherwise this proposal is meaningless.
>>> >> >
>>> >> > My thought about project scope is first let student to define the
>>> goals
>>> >> > and
>>> >> > scope and give our comments later during community discussion
>>> period so
>>> >> > that
>>> >> > he can add/remove some additional goals that he has confidence on
>>> >> > implementing them.
>>> >> >
>>> >> > Thanks !
>>> >> >
>>> >> > On Wed, Jan 4, 2012 at 4:27 PM, Andreas Veithen
>>> >> > <andreas.veit...@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Axiom is an object model for XML and SOAP. Using it to store
>>> something
>>> >> >> that doesn't have an XML representation is sonsense. What you are
>>> >> >> probably referring to is the fact that an OMDataSource that backs
>>> an
>>> >> >> OMSourcedElement can store an arbitrary Java object. However, the
>>> >> >> OMDataSource must be able to produce an XML representation of that
>>> >> >> data. More precisely it must be able to create a representation in
>>> the
>>> >> >> form of an XMLStreamReader and it must be able to write the XML
>>> >> >> representation to an XMLStreamWriter.
>>> >> >>
>>> >> >> At the level of Axis2 that translates into the fact that when a
>>> >> >> message flows through the Axis2 engine, at any given point in time
>>> >> >> that message has a well defined SOAP infoset. In principle you
>>> could
>>> >> >> serialize the message to an XML document, deserialize it again and
>>> >> >> replace the SOAPEnvelope in the MessageContext with that
>>> deserialized
>>> >> >> message, without changing the outcome of the request.
>>> >> >>
>>> >> >> I don't know what you are doing in WSO2 products, but to my
>>> knowledge
>>> >> >> there is no exception to that rule in Axis2 or Synapse, even for
>>> plain
>>> >> >> text and binary messages. For both types of messages, Axis2/Synapse
>>> >> >> internally uses a well defined SOAP infoset:
>>> >> >>
>>> >> >> - For plain text messages, the SOAP infoset uses an element that
>>> wraps
>>> >> >> the entire text message as character data. E.g. for a message with
>>> >> >> content "my message", the SOAP infoset would be (namespaces
>>> removed):
>>> >> >>
>>> >> >> <soap:Envelope><soap:Body><ns:wrapper>my
>>> >> >> message</ns:wrapper></soap:Body></soap:Envelope>
>>> >> >>
>>> >> >> - For binary messages, the SOAP infoset uses an element that wraps
>>> the
>>> >> >> message encoded as base64Binary.
>>> >> >>
>>> >> >> That being said, Axis2 uses several Axiom features to avoid
>>> building a
>>> >> >> full DOM like in memory representation of the entire SOAP infoset:
>>> >> >>
>>> >> >> - For a request, the databindings consume the SOAP infoset without
>>> >> >> building the Axiom tree.
>>> >> >> - For a response, the databindings use an
>>> >> >> OMDataSource/OMSourcedElement that is able to write the XML
>>> >> >> representation directly to an XMLStreamWriter.
>>> >> >> - For plain text, we also use a special OMDataSource implementation
>>> >> >> that is able to produce the XML representation shown above, but
>>> that
>>> >> >> at the same time allows to stream the character data.
>>> >> >> - For binary messages, we simply use the Axiom features that are
>>> also
>>> >> >> used for XOP/MTOM, i.e. we construct a complete Axiom tree, but
>>> with
>>> >> >> an OMText instance that refers to a DataHandler with the binary
>>> data.
>>> >> >>
>>> >> >> However, these various optimizations don't change anything about
>>> the
>>> >> >> fact that in Axis2, a message always has a well defined SOAP
>>> infoset.
>>> >> >>
>>> >> >> Since google-gson defines a direct mapping between JSON and Java
>>> >> >> without defining an XML representation, you will have two options:
>>> >> >>
>>> >> >> 1. Use an OMDataSource that doesn't have an XML representation,
>>> i.e.
>>> >> >> that doesn't have meaningful implementations of the getReader and
>>> >> >> serialize methods, but that only acts as a holder for a Java object
>>> >> >> that can't be transformed to XML. That would clearly be a misuse of
>>> >> >> Axiom.
>>> >> >>
>>> >> >> 2. Define a trivial XML representation, which would be the JSON
>>> string
>>> >> >> wrapped in a wrapper element. Since this is the same thing as we do
>>> >> >> for plain text, we already have the corresponding message builders
>>> and
>>> >> >> formatters, and one would simply map these builders/formatters to
>>> the
>>> >> >> JSON content type. Implementing the proposal would then require
>>> only
>>> >> >> three things:
>>> >> >>
>>> >> >> - Implementing the message receiver.
>>> >> >> - Probably one would have to create a specialized OMDataSource that
>>> >> >> enables streaming of the response.
>>> >> >> - Potentially some minor enhancements to Axiom and/or the plain
>>> text
>>> >> >> message builders/formatters to make sure that streaming is fully
>>> >> >> supported.
>>> >> >>
>>> >> >> Since the message receiver is basically glue gode between
>>> google-gson,
>>> >> >> Axiom and the service object, it will be fairly trivial. The
>>> problem
>>> >> >> is then that the scope of this is likely not large enough for a
>>> GSOC
>>> >> >> project.
>>> >> >>
>>> >> >> Andreas
>>> >> >>
>>> >> >> On Sun, Jan 1, 2012 at 16:25, Sanjiva Weerawarana
>>> >> >> <sanj...@opensource.lk>
>>> >> >> wrote:
>>> >> >> > +1 - while Andreas this functionality can be implemented without
>>> >> >> > Axis2,
>>> >> >> > the
>>> >> >> > proposed feature would add a lot of value to use of Axis2 as a
>>> way to
>>> >> >> > have
>>> >> >> > services that have a good JSON binding in addition to other
>>> bindings.
>>> >> >> > Axiom's design allows passing of non-XML content without forcing
>>> XML
>>> >> >> > and
>>> >> >> > that model performs perfectly fine and well (Synapse and WSO2 ESB
>>> >> >> > both
>>> >> >> > leverage that heavily).
>>> >> >> >
>>> >> >> > Sanjiva.
>>> >> >> >
>>> >> >> >
>>> >> >> > On Fri, Dec 30, 2011 at 10:25 AM, Amila Suriarachchi
>>> >> >> > <amilasuriarach...@gmail.com> wrote:
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>>> >> >> >> <andreas.veit...@gmail.com> wrote:
>>> >> >> >>>
>>> >> >> >>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>> >> >> >>> <amilasuriarach...@gmail.com> wrote:
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>> >> >> >>> > <andreas.veit...@gmail.com>
>>> >> >> >>> > wrote:
>>> >> >> >>> >>
>>> >> >> >>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>> >> >> >>> >> <shameerai...@gmail.com> wrote:
>>> >> >> >>> >> > 2. store json string without doing any process untill it
>>> >> >> >>> >> > reaches
>>> >> >> >>> >> > JsonMessageReceiver. JsonMessageReceiver is a new Message
>>> >> >> >>> >> > Receiver
>>> >> >> >>> >> > which
>>> >> >> >>> >> > use
>>> >> >> >>> >> > gson to convert json to java objects, call relevant
>>> operation
>>> >> >> >>> >> > and
>>> >> >> >>> >> > get
>>> >> >> >>> >> > result.
>>> >> >> >>> >>
>>> >> >> >>> >> What this means in practice is that you will have a message
>>> >> >> >>> >> builder, a
>>> >> >> >>> >> message receiver and a message formatter that interact with
>>> each
>>> >> >> >>> >> other, but that have no meaningful interaction with any
>>> other
>>> >> >> >>> >> component of the Axis2 framework (the fundamental reason
>>> being
>>> >> >> >>> >> that
>>> >> >> >>> >> google-gson defines a mapping between JSON and Java
>>> objects, but
>>> >> >> >>> >> eliminates XML from the picture). The question is then why
>>> would
>>> >> >> >>> >> a
>>> >> >> >>> >> user go through all the pain of setting up Axis2 for this?
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > if you look into a point where users only need to expose a
>>> POJO
>>> >> >> >>> > with
>>> >> >> >>> > json
>>> >> >> >>> > then they don't have to use Axis2.
>>> >> >> >>> >
>>> >> >> >>> > But if the user want to expose the same POJO service both
>>> soap
>>> >> >> >>> > and
>>> >> >> >>> > json
>>> >> >> >>> > formats this provides a value in terms of performance for
>>> latter
>>> >> >> >>> > case.
>>> >> >> >>> > In
>>> >> >> >>> > this case JSON message receiver can be written extending RPC
>>> >> >> >>> > message
>>> >> >> >>> > receiver and call the normal RPC processing if the received
>>> >> >> >>> > message
>>> >> >> >>> > is
>>> >> >> >>> > not a
>>> >> >> >>> > json one.
>>> >> >> >>> >
>>> >> >> >>> > thanks,
>>> >> >> >>> > Amila.
>>> >> >> >>>
>>> >> >> >>> As you know, Axis2 assumes that every message it processes is
>>> >> >> >>> representable as XML (which is different from CXF where a
>>> message
>>> >> >> >>> can
>>> >> >> >>> have different representations, depending on the phase that is
>>> >> >> >>> executed). Until now this has always been the case, even for
>>> plain
>>> >> >> >>> text and unstructured binary data. Are you going to drop that
>>> >> >> >>> requirement from the Axis2 architecture
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Drop that requirement ( I would say initially Axis2 is designed
>>> like
>>> >> >> >> that
>>> >> >> >> but latter specially in all contract first approaches it has not
>>> >> >> >> followed
>>> >> >> >> this for performance reasons) and make an efficient way to work
>>> >> >> >> with
>>> >> >> >> JSON.
>>> >> >> >> Then obviously this won't support WS-Security etc .. which are
>>> >> >> >> anyway
>>> >> >> >> meaningless for json.
>>> >> >> >>
>>> >> >> >> If you look at how ADB works for non security (or non message
>>> >> >> >> building
>>> >> >> >> case) is similar to this. It stores the xml stream in the Axiom
>>> >> >> >> object
>>> >> >> >> (this
>>> >> >> >> feature has come from axiom differed building) and get that
>>> >> >> >> underline
>>> >> >> >> stream
>>> >> >> >> at the message receiver and directly build the java objects from
>>> >> >> >> that.
>>> >> >> >> Then
>>> >> >> >> at the response also it save the response in OMDatasource and
>>> >> >> >> directly
>>> >> >> >> serialize to the xml stream at the formatter.
>>> >> >> >>
>>> >> >> >> So idea for this is to provide such a direct stream parsing
>>> >> >> >> serializing
>>> >> >> >> technique which performs well for POJO objects to communicate
>>> using
>>> >> >> >> json.
>>> >> >> >>
>>> >> >> >> thanks,
>>> >> >> >> Amila.
>>> >> >> >>
>>> >> >> >>>
>>> >> >> >>> or else, what would be the XML
>>> >> >> >>> representation of a JSON message received by that message
>>> receiver?
>>> >> >> >>>
>>> >> >> >>> >
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >> Andreas
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> >> >> >>> >>
>>> ---------------------------------------------------------------------
>>> >> >> >>> >> To unsubscribe, e-mail:
>>> java-dev-unsubscr...@axis.apache.org
>>> >> >> >>> >> For additional commands, e-mail:
>>> java-dev-h...@axis.apache.org
>>> >> >> >>> >>
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > --
>>> >> >> >>> > Amila Suriarachchi
>>> >> >> >>> > WSO2 Inc.
>>> >> >> >>> > blog: http://amilachinthaka.blogspot.com/
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>
>>> ---------------------------------------------------------------------
>>> >> >> >>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
>>> >> >> >>> For additional commands, e-mail: java-dev-h...@axis.apache.org
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Amila Suriarachchi
>>> >> >> >> WSO2 Inc.
>>> >> >> >> blog: http://amilachinthaka.blogspot.com/
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Sanjiva Weerawarana, Ph.D.
>>> >> >> > Founder, Director & Chief Scientist; Lanka Software Foundation;
>>> >> >> > http://www.opensource.lk/
>>> >> >> > Founder, Chairman & CEO; WSO2; http://wso2.com/
>>> >> >> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/
>>> >> >> > Member; Apache Software Foundation; http://www.apache.org/
>>> >> >> > Visiting Lecturer; University of Moratuwa;
>>> http://www.cse.mrt.ac.lk/
>>> >> >> >
>>> >> >> > Blog: http://sanjiva.weerawarana.org/
>>> >> >> >
>>> >> >>
>>> >> >>
>>> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
>>> >> >> For additional commands, e-mail: java-dev-h...@axis.apache.org
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Sagara Gunathunga
>>> >> >
>>> >> > Blog - http://ssagara.blogspot.com
>>> >> > Web - http://people.apache.org/~sagara/
>>> >> > LinkedIn - http://www.linkedin.com/in/ssagara
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
>>> >> For additional commands, e-mail: java-dev-h...@axis.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Shameera Rathnayaka
>>> > Undergraduate
>>> > Department of Computer Science and Engineering
>>> > University of Moratuwa.
>>> > Sri Lanka.
>>> >
>>> > Blog : http://shameerarathnayaka.blogspot.com/
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
>>> For additional commands, e-mail: java-dev-h...@axis.apache.org
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Shameera Rathnayaka
> Undergraduate
> Department of Computer Science and Engineering
> University of Moratuwa.
> Sri Lanka.
>
> Blog : http://shameerarathnayaka.blogspot.com/
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
