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
<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).
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/
