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
