axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "keith chapman" <keithgchap...@gmail.com>
Subject Re: pushing REST support in axis2 a little beyond sanity ?
Date Sun, 25 May 2008 23:20:46 GMT
Hi,

Sorry for the late reply on this. (I saw this mail on the list a couple of
weeks ago while I was traveling on some urgent matters, I kept the mail
marked so that I can have a look at it later).

On the issue of returning a POX error (
https://issues.apache.org/jira/browse/AXIS2-3771). I recall fixing this POST
1.3, hence can you try this scenario out using Axis2 1.4?

BTW Axis2 does support all four HTTP methods GET, PUT, POST and DELETE hence
it has full fledged REST support.

Also you seem to use WSDL first deployment and I think you might be using
WSDL 1.1. If you try using WSDL 2.0 (Which is much simpler that WSDL 1.1)
you can get better control over the REST support in Axis2, and if you are
interested in giving a try I can help you on this.

Thanks,
Keith.
On Sat, May 10, 2008 at 4:04 PM, Xavi Drudis Ferran <
xdrudis@ambarinformatica.com> wrote:

> Hello
>
>
> Oopss. 230 odd lines for my first message to this list it's a bit too
> much. Sorry.
> I'll add an overview here so that people can skip it if not interested
> (which
> will make it still longer). You never know whether some subscriber might
> be bored eading mail in a station or something...
>
>
> summary
>
> I present an odd use of the REST support in Axis2.
>
> We have coded a client and server with Axis2 like
> XML examples -> XSD -> tuned XSD -> WSDL -> Java stub, skeleton and beans
> -> app
> Steps 1,3 and 4 are automated, steps 2 and 5 are manual.
>
> I refer to a problem with fault detection and REST, might be a bug
> or an unssuported use, see JIRA AXIS2-3771
>
> I attach the XSLT 2.0 sheet used for step 3, xsd2wsdl.xslt,
> adapted from one by Arjen Poutsma.
>
> Then I ask whether we can use axis2 in case we don't fully know
> the content of the xml our client will get, just some of the elements
> it will contain, and we can ignore the rest.
>
> end of summary
>
>
>
> We had a web application and had to add interoperability with
> another application through soap (being a server of some services
> and a client of others). So we decided to integrate axis2 in
> the web application. While we were at it a new, more urgent
> requirement came in to interoperate with yet another server,
> through non-SOAP web services.
>
> The documentation for this non-SOAP application explained that
> we should send it an http(s) GET with some parameters and it
> would return xml content. It included an example, let's imagine
> like this:
>
> http://server:8080/app/services/getData?id=123&page=1&itemsperpage=3
>
> =>
>
> <data result="OK">
>  <items count="25">
>  <item>
>     <a>value for a</a>
>     <b>value for b</b>
>     <c>value for c</c>
>  </item>
>  <item>
>     <a>value for a in the second element</a>
>     <b>value for b in the 2nd...</b>
>     <c>... c in 2nd...</c>
>  </item>
>  <item>
>     <a>... a in 3rd....</a>
>     <b>... b ... 3 ... </b>
>     <c>... c 3 ... </c>
>  </item>
>  <items>
> <data>
>
> Then the documentation gave a table with descriptions of the data:
>
> element type      desc
> a        string   a-ness of the element
> b        string   b attribute of ...
> c        string   such and such
> d        datetime moment of inspiration for such an element
> e        int      cm3 of beer...
>
> (we assumed d and e where optional elements that could appear)
>
> It could also return errors, in two ways:
> like this:
> <data result="KO">
>   <errors>
>     <error desc="sorry, boy, but no luck"/>
>     <error desc="anyway, we didn't know that id"/>
>   <errors>
> </data>
>
> or like this:
>
> <error desc="you won't try to make me work today, will you?"/>
>
> In retrospect we should have used an http client and an XML parser and
> get done with it, but we thought that we could leverage axis2 since we
> have axis2 integrated, and axis2 has some support for REST (or POX,
> but I don't want to argue that because in our simple case they might
> even be the same).
>
> So what we did was (inspired by this post by Arjen Poutsma
>
> http://blog.springframework.com/arjen/archives/2006/07/27/xslt-that-transforms-from-xsd-to-wsdl/
> ):
>
> A- use inst2xsd in xmlbeans to produce a preliminar xsd from the xml
> samples.  (inst2xsd is a tool in xmlBeans that infers schema from
> examples)
>
> B- modify the xsd manually to :
>
>  B.1 - accomodate the documentation (add optional fields, declare the
>  data types properly...)
>
>  B.2 - make data have two optional elements "items" and "errors" so
>       that we can get either data or the error list.
>
>  B.3 - add an element for the parameters (we won't send the parameters
>       by xml, but we pretend we can so that axis2 REST support
>       accepts/sends the call using parameters in the url)
>
>  B.4 - add another element which we'll use as an exception for the
>       answer with the single "error" element
>
>
> C- generate an wsdl from the xsd (with Poustma's xslt script, adapted
> to handle empty namespaces and include fault declarations for the
> elements matching the naming convention, in our case "error", so that
> axis throws them as exceptions) I tried to send the changes to Arjen
> Poustma, in case he or she is interested but wasn't able to reach him or
> her. I'll attach it here in case anyone's interested (but it's not
> fully tested). I used orangeVolt eclipseXSLT with Saxon to apply it
> because it's XSLT 2.0.
>
> D- generate the data beans corresponding to the xml, a client and a
> server with axis2, with WSDL2Java
>
> E- code a simple test server (we don't have access to a server like
> the one we have to interoperate with during development, only at
> scheduled test visits).  We could have used static test data in xml
> files, but we wanted a little diversity so wrote a server that
> returned near random data with the characteristics we wanted. This
> server was to behave as the documentation described the real server.
>
> F- configure axis2 to accept REST invocation for this test server,
> don't use namespaces, etc.
>
> G- code our client for our web application, configuring the stub to
> use REST
>
> It's really more complex to explain it than to do it, and the tools
> take care of all the tedious coding, leaving us only the business
> logic, as it should be. I miss an eclipse plugin that integrates all
> these tools for this kind of tasks (and couldn't use axis2 plugin for
> task D because I wanted the generated classes in a package even
> without namespaces, but the command line or ant task worked fine).
>
> We got the test server to behave as we thought the real server would.
> We got the client to behave almost right, except that when the server
> sent the fault <error desc="foobar"/> the Axis2 stub wouldn't throw
> the generated exception, but an IllegalArgumentException (I filed
> https://issues.apache.org/jira/browse/AXIS2-3771
> in case it is a bug)
>
>
>
> We finally went to test life with the real server and we found the
> answer we got was more like
>
> <data result="OK">
>  <items count="25">
>  <item>
>     <stuff>bla</stuff>
>
>     <a>value for a</a>
>
>     <foo>foo value for 1</foo>
>
>     <c>value for c</c>
>
>     <b>value for b</b>
>     <d>2008-05-10T12:00:00.123Z/d>
>     <e>500</e>
>     <some>
>        <more>stuff</more>
>     </some>
>     <and>
>        <so> ... </so>
>        <on> ... </on>
>        <on> ... </on>
>        <on> ... </on>
>     </and>
>
>  </item>
>  <item>
>     <stuff>bla</stuff>
>     <a>value for a in the second element</a>
>     <foo>foo value for 1</foo>
>     <c>... c in 2nd...</c>
>
>    <b>value for b in the 2nd...</b>
>     <d>2008-05-10T12:00:00.123Z/d>
>     <e>500</e>
>     <and>
>        <so> ... </so>
>        <on> ... </on>
>     </and>
>
>  </item>
>  <items>
> <data>
>
>
> That is: the elements we expected were there in a different order
> and there were new unexpected elements before, after and between them.
> Not all of the new elements were always present, so at least some were
> optional, and we only got two examples, there might be optional elements
> missing in both that could appear one day in production.
>
> Ok, we regenerated xsd, wsdl and java classes from the examples we got
> from the live server, putting minOccurs="0" in all the new elements,
> and made it work so that we could perform some other tests that run
> after that one. So it then would work with the examples in the
> documentation and the one we had seen from the server. But we don't
> know what can happen with more examples from the real server. So we
> told our customer we couldn't guarantee interoperability yet and they
> put us in touch with the provider of that server. So we wrote them to
> ask for more details on what the server can return.
>
> Their answer so far has been that the documentation says all we need to
> know
> (it didn't say there were no more possible elements, it just described
> some),
> that any other elements are optional and any may come and that the order
> of elements is not important in xml, that's why there are different tags
> to mark data.
>
> Well of course you can define xml uses where order of elements is not
> important and you can almost parse an xml with just the information of
> some of the elements you're going to find (you just need to ask the
> extra requirement that none of the added elements repeats the name of
> any of the elements you know, so as not to have to choose between two
> identically named elements for the single value you need).  But in any
> case this adds unnecessary complexity and can be avoided, and it is
> not typical xml usage. We're still trying to get the complete
> information to make this simpler.
>
> But the question is (in fact more out of curiosity than because I
> would think it's any worthwhile use case): is there any way you can
> declare in your wsdl that messages can contain almost anything and
> axis2 should parse them and extract just a few known elements ? (any
> one of each name, if there'd be more). I tried using xsd:any in
> several places and didn't try xsd:choose because I thought that
> wouldn't work when generating code, but maybe I'm missing something
> obvious. I think xsd:any won't cut it because you don't know how many
> elements can come between interesting elements and you don't have a
> way to restrict xsd:any to any element with a name not belonging to a
> given set.  If I could express it in wsdl at least I would be a formal
> specification in case someone else wants to talk to our client in the
> future (not too likely).
>
> Or if as I suspect there is no way to do that through wsdl, is there a
> hook in axis2 where I can easily plug custom code to modify the input
> the client gets and extract the interesting elements off it. Maybe
> using xslt on the input would be too expensive (is it?) but supplying a
> custom SAX parser that just fills some beans would be efficient and
> easy enough to code ?
>
>
> I repeat I don't pretend that using axis2 for such a task would
> be the ideal solution, I believe it must have been thought for more
> precisely specified services, but I wonder whether it can be used,
> and I guess trying it's a way to learn a little about axis2, xsd and wsdl.
>
> Thanks to anyone who have the patience to reach till here.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>



-- 
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/

blog: http://www.keith-chapman.org

Mime
View raw message