axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Improve Json support with Axis2 using google-gson java library
Date Wed, 04 Jan 2012 10:57:49 GMT
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):


- 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

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

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


On Sun, Jan 1, 2012 at 16:25, Sanjiva Weerawarana <> 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
> <> wrote:
>> On Fri, Dec 30, 2011 at 12:35 AM, Andreas Veithen
>> <> wrote:
>>> On Thu, Dec 29, 2011 at 15:55, Amila Suriarachchi
>>> <> wrote:
>>> >
>>> >
>>> > On Tue, Dec 27, 2011 at 7:58 PM, Andreas Veithen
>>> > <>
>>> > wrote:
>>> >>
>>> >> On Sun, Dec 25, 2011 at 15:09, Shameera Rathnayaka
>>> >> <> 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,
>>> >> 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:
>>> >> For additional commands, e-mail:
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Amila Suriarachchi
>>> > WSO2 Inc.
>>> > blog:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog:
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> Founder, Chairman & CEO; WSO2;
> Founder & Director; Thinkcube Systems;
> Member; Apache Software Foundation;
> Visiting Lecturer; University of Moratuwa;
> Blog:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message