On Wed, Jan 4, 2012 at 7:57 PM, Andreas Veithen
<andreas.veit...@gmail.com>wrote:

> I think it is useful to summarize a bit the discussion at this point.
>
> We have identified two approaches to address the SOAP infoset vs. JSON
> question:
>
> 1. As Amila suggests in his last post, put a dummy SOAP envelope in
> the message context and store the JSON message (actually a stream
> representing that message) in a message context property. This is
> technically simple, but it is not an innocent choice because it
> deviates from what we do elsewhere in Axis2. Therefore this requires
> some careful thinking about the implications of such a choice.
>
> 2. Preserve the requirement that a message must have a well defined
> SOAP infoset and use a trivial representation similar (or identical)
> to what we use for plain text. This has the advantage that it is more
> in line with the rest of the Axis2 architecture, but requires a
> careful analysis (and potentially some enhancements in Axiom or Axis2)
> to make sure that we can implement streaming. It should be noted that
> this has applications that are important in a context much broader
> than JSON. In particular, the ability to stream character data
> efficiently is important for Synapse as well.
>
> So, one of the tasks of the proposed GSOC project would be to analyze
> and evaluate both approaches, so that we can make an educated choice.
>
> 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?) 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?
>

  +1

  BTW one interesting question remains is how to dispatch JSON messages
specially in non-http transports ? current approach converts JSON into XML
hence this is not a problem. One solution can be use JSON wrapper element
and use gson.stream.JsonReader to read only that wrapper element before
dispatching and construct SOAP infoset up to that level. I think above
point 2.) is related to this.   Is there any good solution for this ?

Thanks !


>
> 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
>
>


-- 
Sagara Gunathunga

Blog      - http://ssagara.blogspot.com
Web      - http://people.apache.org/~sagara/
LinkedIn - http://www.linkedin.com/in/ssagara

Reply via email to