Hi, Hope I'm not too late to catch up... In reply to Eran's questions about the fundaments, >Then the question comes as to what really Axis2 is. If we enable plugging custom types, which are not compatible >with SOAP or REST, then aren't we redefining what Axis2 is? Do we wanna make it something which can handle >more than Web services (I consider "REST within Axis2" also as Web services, as our REST implementation is >based on WSDL 2.0 HTTP binding)
What we mean by custom types in the context of MessageBuilders/formatters is that different serializations of the XML infoset. One example would be fast infoset. When supporting JSON we are using the existing XML<-->JSON transformation standards (or rather agreements) and I beleive this can also be called as a different searialisation of XML infoset.. On the other hand I personally consider a pure JSON service as a web service too... >I don't think so because in the spec once again it says the following here : http://www.w3.org/TR/wsdl20->adjuncts/#_http_operation_xml_encoding<http://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encoding> >"The instance data <http://www.w3.org/TR/wsdl20-adjuncts/#instance_data> of the input, output or fault message is serialized as an *XML document* in the message body >of the HTTP message" Since JSON serialization is not XML, rather name/value pair, application/xml is not >compatible with application/json. As I said earlier we can consider it as XML since we are using XML<--> json conversions standards like Badgerfish or Mapped. Back to the proposed solutions, >Now to get back to your original point - I think the idea of having message formatters applied to faults too (which >you proposed in a later mail) is the right answer. Faults are just messages too and its clearly an oversight that we >didn't apply the design orthogonally there too. Time to fix it. >With current MessageBuilders/>MessageFormatters they build/format requests based on content-type. I'm not too familiar with the fault message >flow in Axis2 (Will have a look on that and get back) But why arn't we allowing the corresponding builder/formatter >to format faults too? If that was the case I think this problem would not occur. Looks like the fundemental problem >lies in there. The messagefomatter interface[1] defines how to write the SOAP message it receives to the wire. It does not differentiate anything about the content of the message (eg: fault or not).. IMHO it's up to the author of the message formatter to decide whether he is going to treat it diffrently or not.. Even in the case of JSON, I do not see anything wrong if our JSON formatter serialised the whole SOAP message (including SOAP). If it serializes just the payload then it is just simply a decision by the message format author. On a side note I see value in providing a configuration option to the JSON formatter to select whether to serialize the whole message or just the payload (isDoingPOX?).. May be the builders can use some magic to figure this out looking at the received messages. I would expect the fault to be treated same as the message (rip off the SOAP if it's doing so for the non-fault messages).. On the other hand, I consider it as a huge bug if Axis2 is not applying the message formatters to the Fault flow at all.. IIRC considered the fault flow and we did this for the fault flow too, so that it'll use the corresponding formatter/builder in case of a fault.. thanks, Thilina [1] http://ws.apache.org/axis2/1_4_1/api/org/apache/axis2/transport/MessageFormatter.html On Sun, Sep 21, 2008 at 11:10 PM, keith chapman <[EMAIL PROTECTED]>wrote: > > > On Mon, Sep 22, 2008 at 9:00 AM, Sanjiva Weerawarana < > [EMAIL PROTECTED]> wrote: > >> I think the whole question of "REST" is not the point here. >> >> Axis2's underlying data model is a SOAP Infoset. As a result, any type of >> data that runs thru the system has to be represented as a SOAP Infoset. >> That's not a big deal - essentially it means we need to create two extra >> Axiom nodes (a s:Envelope node and an s:Body node) and stick a child in >> there that contains whatever the real data is. Using our nice MTOM >> integration and the deferred pull architecture of Axiom, we can do that >> efficiently using OMSourceElement nodes as we've proven multiple times now. >> >> That's for incoming stuff - we take whatever that comes in and represent >> it within a SOAP Infoset. >> >> When we have an outgoing message, the inverse question is relevant - if >> the message is not going out as SOAP, then someone needs to take the real >> message payload (which is in the child node of the s:Body node) and only >> write the content of that. That's basically what MessageFormatters do. >> >> [So calling all of that "REST" is totally wrong and an abuse of what >> "REST" means. I think we need to refactor that code and get rid of any >> references to REST as this has nothing to do with REST. Yes I know the >> history and how it got called that but now its time to fix it.] >> > > +1. Better later than never ;). > >> >> >> Now to get back to your original point - I think the idea of having >> message formatters applied to faults too (which you proposed in a later >> mail) is the right answer. Faults are just messages too and its clearly an >> oversight that we didn't apply the design orthogonally there too. Time to >> fix it. >> > > +1. > > Thanks, > Keith. > >> >> >> Sanjiva. >> >> >> keith chapman wrote: >> >> Let me describe the problem in more detail. As of now Axis2 enables you to >> plug in various message types by registering them in the axis2.xml. Some of >> these message types will be SOAP based (like text/xml and >> application/soap+xml) while others are not. And in the latter case when a >> exception occurs somewhere in the pipe we do not want to throw the fault as >> a SOAP message. What we do in the REST case of of now is that we take the >> fault element in the SOAP body (If not found the first child of the SOAP >> body) and write that out as the fault. As of now Axis2 treats a few message >> Types as REST specifically application/xml, multipart/form-data and >> application/x-www-form-urlencoded. But with the pluggable message types in >> place this may not work that well. Assume that someone want to to plug in >> application/foo and that this message type is REST how are we gonna handle >> it? >> >> Should we consider adding a attribute to the >> messageBuilders/messageFormatters section to indicate weather its REST or >> not? >> >> Thanks, >> Keith. >> >> On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana < >> [EMAIL PROTECTED]> wrote: >> >>> +1 .. but I'm a bit confused. I assume by "REST" you meant that the >>> response has media type text/xml instead of application/soap+xml, right? >>> >>> If we think about it that way, can we get rid of the "isDoingREST" flag?? >>> >>> >>> (I've hated that from day 1 and haven't had a chance to really dig thru >>> it and figure out how to get rid of. Maybe this is an opportunity to get it >>> right ..) >>> >>> Sanjiva. >>> >>> keith chapman wrote: >>> >>> Any input on this would be appreciated. >>> >>> Thanks, >>> Keith. >>> >>> On Thu, Sep 4, 2008 at 8:40 AM, keith chapman <[EMAIL PROTECTED]>wrote: >>> >>>> Hi devs, >>>> >>>> This idea came up because of the following scenario. >>>> >>>> Currently the logic for creating a AxisFault for a fault received lies >>>> in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly >>>> when the received fault is SOAP or REST. But it does not work as expected >>>> when the response is JSON ( rather a exception is thrown saying "The >>>> MessageContext does not have an associated SOAPFault."). The reason is the >>>> logic we use to build the AxisFault. If the fault message is not a SOAP >>>> message we check for the flag messageContext.isDoingREST() and get the >>>> first >>>> element of the SOAPBody as the fault message. >>>> >>>> When the fault message is JSON its neither SOAP and the >>>> messageContext.isDoingREST() returns false. Should we consider JSON >>>> messages as REST messages? I believe so. >>>> >>>> WDYT? >>>> >>>> Thanks, >>>> Keith. >>>> >>>> -- >>>> Keith Chapman >>>> Senior Software Engineer >>>> WSO2 Inc. >>>> Oxygenating the Web Service Platform. >>>> http://wso2.org/ >>>> >>>> blog: http://www.keith-chapman.org >>>> >>> >>> >>> >>> -- >>> Keith Chapman >>> Senior Software Engineer >>> WSO2 Inc. >>> Oxygenating the Web Service Platform. >>> http://wso2.org/ >>> >>> blog: http://www.keith-chapman.org >>> >>> >>> -- >>> Sanjiva Weerawarana, Ph.D. >>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ >>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.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: [EMAIL PROTECTED] For additional >>> commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> -- >> Keith Chapman >> Senior Software Engineer >> WSO2 Inc. >> Oxygenating the Web Service Platform. >> http://wso2.org/ >> >> blog: http://www.keith-chapman.org >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.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: [EMAIL PROTECTED] For additional >> commands, e-mail: [EMAIL PROTECTED] >> > > > > -- > Keith Chapman > Senior Software Engineer > WSO2 Inc. > Oxygenating the Web Service Platform. > http://wso2.org/ > > blog: http://www.keith-chapman.org > -- Thilina Gunarathne - http://thilinag.blogspot.com
