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