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/