WSO2: release candidate of Web Services Framework for Spring

Discussions

News: WSO2: release candidate of Web Services Framework for Spring

  1. WSO2 has posted the first release candidate of "Web Services Framework for Spring," integrating Axis2 into Spring contexts. It provides a Spring configuration file to be used, and then developers can expose their own beans by injecting them into the Web Services Framework. The full configuration is as follows. Add the Spring context listener to the web.xml normally, but add a reference to one servlet: axis2 org.wso2.spring.ws.servlet.SpringAxis2Servlet 1 axis2 /axis2/* axis2 /services/* You can also expose the services via a provided JSP (/axis2-web/index.jsp), which can be added to the list of welcome-files. Next, import the WSF configuration into the Spring context:(It's also possible, one presumes, to add the axis2Config.xml file to the list of configuration files, but this adds a potential error, if the programmer forgets to include this file in the external context configuration.) Lastly, (mostly) from the documentation, a bean can be exposed as shown: Paul Fremantle (speaking at TSSJS-US this year) posted a blog entry ("Web Services for Spring with Axis2") about the release, where he adds:
    ...how does this compare to Spring Web Services? Well, the first thing is that SWS is mainly about contract-first. And while contract first is an excellent practice, there are times when it is not appropriate - for example it may be simply too much effort for a simple first web service. WSF/Spring supports the POJO programming model simply and effectively, and generates the WSDL automatically from the beans you expose. (WSF/Spring does also expose contract-first). The second reason is simply that some users want to use Axis2. Axis2 is a very full featured and interoperable toolkit that does support some extra standards not yet available in SpringWS such as WS-SecureConversation, WS-Trust, WS-Policy and WS-ReliableMessaging. Axis2 also takes a very different approach to enabling these standards using the module approach rather than direct wiring of handlers.

    I honestly don't believe WSF/Spring is "a competitor" to SpringWS. They offer different approaches and each have different benefits. Just as Spring users have a choice of different frameworks for databinding, MVC, etc, this adds one more framework to support Web Services into the excellent Spring framework. And they also share a lot of code - for example they both use Axiom and support many of the same databinding toolkits (JIBX, JAXB, XMLBeans).
    It's an interesting point - with Spring offering core services like integration points, web services, OSGi, etc... do external toolkits like this really make sense?

    Threaded Messages (47)

  2. Axis2 vs CXF?[ Go to top ]

    How does Axis2 compare with CXF? There are both Apache WS projects that seem to cover same/similar space? Anyone have hands-on experience comparing the two? When I recently tried Axis 1.3, it gave me no helpful errors while compiling my WSDL so I obviously couldn't use it.
  3. Cxf is good[ Go to top ]

    Not trying to hijack the thread, but work with Cxf is very good. Download the binary and look in folder "samples/mtosi_1.1", that is one very big XSD/WSDL combo, written in very modular form and shows true power of this framework. Have not worked with Axis so cant comment on that one, but have chosen Cxf because: -it has only 1 blocking bug on jira as opposed to over 50 Axis2 -very nice Spring integration; no wonders on that one since we all know how good James Strachan & co are =).
  4. Correction[ Go to top ]

    I messed up blocking bug number of Axis2, its only 18 blockers. Sorry. http://issues.apache.org/jira/browse/AXIS2
  5. I'm little zapped of this...[ Go to top ]

    No offence but it seems we're going into "not invented here" syndrome, like with MVC few years ago. I love Java - it's my work, I love choices - I'm far from approach like MS presents right now. But choosing WebServices stack nowadays for is just dramatical. Look, suppose new Java programmer gonna implement few web services. Simple, right? As usual He/she goes to apache.org and finds some useful stuff. But wait! We have Axis 1.4, Axis 2 (version 1.4 right now, to be more confusing), CXF, Spring-WS, METRO (which is actually exactly the same thing that comes with JWSDP, except some stuff from Tango and WSIF), plus if You use JBoss you probably are happy user of JBoss-WS (BTW. JBOSS guys are preparing abstraction layer on top of JBOSS-WS for CXF and METRO just to be even most confusing). Add to this the fact that all those frameworks work with some flavour of XML parsers (usually xerces). And expect, of course, that Oracle AS comes with it's own parser, incompatible with above stacks, Bea AS comes with it's own and IBM is not worse, of course. Please be prepared to play with weired classloaders in Your application servers, swapping XML parsers, removing overlapping stuff etc. Well the fact that jax-ws ri comes with JDK 6.0 doesn't help much... Now we have this. Please don't understand me wrong - but stop bombarding us with stuff like this. Axis has a spring integration for Years. Reading Your blog entry 3 times and sorry didn't understand rationale behind Your product. Sorry but 5 minutes test passed for me. Happy CXF user.
  6. market[ Go to top ]

    That is the beauty of the Java market, you are not tied to one implementation, you can choose one that suites best to your needs. Lots of competition can lead only to better conditions for consumers (us developers).
  7. No offence...
    Choice is good, but the XML stuff is really confusing (see also).
  8. Understanding how this fits[ Go to top ]

    WSF/Spring is a project that helps use Axis2 inside Spring. If you are already a happy user of Spring Web Services then probably you don't need this. However, if you are a Spring application developer looking to use Axis2, this project has some useful benefits over the existing Spring support inside Axis2. Basically this project allows you to do everything inside Spring, including all the wiring and configuration of Axis2. So if you understand Spring, then this is a very simple model to get to grips with. I agree too much choice is a pain. However, several hundred years of democracy has shown that it is the lesser of two evils. Too little choice - for example when you have a dictatorship - is worse than too much. However, I will certainly take on board the feedback from this community and see if we can simplify the options and make it easier to understand. Paul
  9. The good, bad and the evil[ Go to top ]

    The good: Having choices The bad: Having choices The Evil: Well, you know who I'm talking about, :) Guys, can you please state what WS stack are you using together with Spring? Yuval.
  10. Re: The good, bad and the evil[ Go to top ]

    XFire + Spring. Will move to CXF later.
  11. I agree too much choice is a pain. However, several hundred years of democracy has shown that it is the lesser of two evils. Too little choice - for example when you have a dictatorship - is worse than too much. However, I will certainly take on board the feedback from this community and see if we can simplify the options and make it easier to understand.
    I think your project is great and I could really use it (Spring/Axis2). However, Java-XML technologies suck (except XStream). I really wonder why volunteers spend their time with it.
  12. suck?[ Go to top ]

    It comes as surprise to consider Java XML stack bad. Can you perhaps, if you are reading this, elaborate on "sucky" part, pointers to something that does it better than Java. Officially formalized (JAX-WS, JAXB, StAX...), with many implementors, healthy competition. Seems pretty good and productive to me.
  13. Re: suck?[ Go to top ]

    It comes as surprise to consider Java XML stack bad. Can you perhaps, if you are reading this, elaborate on "sucky" part, pointers to something that does it better than Java.
    Sure, Java has the best XML technology support. However, it sucks. Pointers? Eight years Java-XML-technology pain experience. It seems like it is a pleasure for yor, but I'm just Java-XML-technology paralyzed.
  14. Re: suck?[ Go to top ]


    Sure, Java has the best XML technology support. However, it sucks. Pointers? Eight years Java-XML-technology pain experience. It seems like it is a pleasure for yor, but I'm just Java-XML-technology paralyzed.
    Thats the evolution, but as of now, to me it seems that Java XML stack has finally become stable and mature.
  15. Re: suck?[ Go to top ]

    It comes as surprise to consider Java XML stack bad. Can you perhaps, if you are reading this, elaborate on "sucky" part, pointers to something that does it better than Java.

    Officially formalized (JAX-WS, JAXB, StAX...), with many implementors, healthy competition. Seems pretty good and productive to me.
    My pointer would be to avoid JAX-WS and JAXB. Xstream with XSLT is a much better choice for binding to objects.
  16. Re: suck?[ Go to top ]

    My pointer would be to avoid JAX-WS and JAXB.

    Xstream with XSLT is a much better choice for binding to objects.
    I must admit I prefer the evils of XML Schema + a binding such as JAXB/XmlBeans/JibX... to the evils of messing with stylesheets. Do you have some example code/project using Xstream+XSLT for databinding? Would be interestng how it compares in terms of complexity, performance etc.
  17. Re: suck?[ Go to top ]

    My pointer would be to avoid JAX-WS and JAXB.

    Xstream with XSLT is a much better choice for binding to objects.


    I must admit I prefer the evils of XML Schema + a binding such as JAXB/XmlBeans/JibX... to the evils of messing with stylesheets.

    Do you have some example code/project using Xstream+XSLT for databinding? Would be interestng how it compares in terms of complexity, performance etc.
    What are the evils of 'messing with stylesheets' as you see them? It seems to me that most of the time that people have preferred JAXB is when they don't want to take time to learn XSLT. In terms of performance, I don't really know. I would guess they are nominally equivalent.
  18. Re: suck?[ Go to top ]

    Example code. You need the Xstream and xpp to run this. You can use the DomDriver if you don't want to get XPP but as I understand it this is much slower. Generally I would separate the transformation from the (un)marshalling using queues or other intermediate steps but I have combined everything together in one lump. The biggest part of the code is the transformation but that is really something you only need to write once. Well most of the code is. All you need to add new bindings is really create your domain object (which you should anyway) and the to/from transformations. You can also use the new Saxon library to compile your transformations into .class files if speed is a concern. package example; import java.io.*; import javax.xml.transform.*; import javax.xml.transform.stream.*; import com.thoughtworks.xstream.XStream; public class Example { public static void main(String[] args) throws Exception { Person person = new Person("Billy", "Badass", 25); out(person); person = in(); System.out.println(person); } static void out(Person person) throws IOException, TransformerException { XStream xstream = new XStream(); // new XStream(new DomDriver()); ByteArrayOutputStream ostream = new ByteArrayOutputStream(); xstream.toXML(person, ostream); transform(ostream.toByteArray(), "billy.xml"); } static Person in() throws IOException, TransformerException { byte[] bytes = transform("billy.xml"); XStream xstream = new XStream(); // new XStream(new DomDriver()); return (Person) xstream.fromXML(new ByteArrayInputStream(bytes)); } private static byte[] transform(String file) throws IOException, TransformerException { InputStream xsl = new FileInputStream("trans.xsl"); try { Source xslSource = new StreamSource(xsl); TransformerFactory factory = TransformerFactory.newInstance(); Transformer outTransformer = factory.newTransformer(xslSource); ByteArrayOutputStream ostream = new ByteArrayOutputStream(); Result result = new StreamResult(ostream); InputStream istream = new FileInputStream(file); try { Source source = new StreamSource(istream); outTransformer.transform(source, result); return ostream.toByteArray(); } finally { try { istream.close(); } catch(Exception e) { e.printStackTrace(); } } } finally { try { xsl.close(); } catch(Exception e) { e.printStackTrace(); } } } private static void transform(byte[] bytes, String file) throws IOException, TransformerException { InputStream xsl = new FileInputStream("trans.xsl"); try { Source xslSource = new StreamSource(xsl); TransformerFactory factory = TransformerFactory.newInstance(); Transformer outTransformer = factory.newTransformer(xslSource); OutputStream ostream = new FileOutputStream(file); Source source = new StreamSource(new ByteArrayInputStream(bytes)); try { Result result = new StreamResult(ostream); outTransformer.transform(source, result); } finally { try { ostream.close(); } catch(Exception e) { e.printStackTrace(); } } } finally { try { xsl.close(); } catch(Exception e) { e.printStackTrace(); } } } } class Person { private final String firstName; private final String lastName; private final int age; Person(final String firstName, final String lastName, final int age) { this.firstName = firstName; this.lastName = lastName; this.age = age; } public String getName() { return firstName + ' ' + lastName; } public int getAge() { return age; } public String toString() { return getName() + ": " + age; } } And trans.xsl:
  19. comparison[ Go to top ]

    I was more referring to WSDL/Web Services stack. You start from XSD, then WSDL then JAXB-wsdl2java process. XStream seems very similar to Jibx, where you custom mapping format replace with XSLT, now it would be interesting to see how that approach works in Web Services/SOA environment. (not buzzword SOA, but realword integration SOA).
  20. Re: comparison[ Go to top ]

    I was more referring to WSDL/Web Services stack. You start from XSD, then WSDL then JAXB-wsdl2java process.

    XStream seems very similar to Jibx, where you custom mapping format replace with XSLT, now it would be interesting to see how that approach works in Web Services/SOA environment.
    (not buzzword SOA, but realword integration SOA).
    There's one way to use JAXB that I am OK with but first, the problem with the naive approach to this is if you take the data schema from the WSDL and generate classes from it, you really haven't bound anything. You still have to map the data into your domain objects but in verbose, brittle, time-consuming, hard-coded Java. You could maybe use the generated classes as your domain object but these are normally super crappy, IMO and get's you in more trouble with the other issue with this approach: what happens if you have a second XML format that maps to the same domain objects. For example, say you decide to revamp the service for version 2. You will still need to support version 1 but know you have two sets of JAXB classes. You can also use the JAXB custom binding but I see no advantage over XSLT and I'm pretty sure XSLT is more flexible and full-featured. XSLT is XML native. It 'knows' XML and can deal with any XML you throw at it. Lastly, you can use JAXB to generate schemata from your domain objects. This I can deal with. I haven't used it but I believe it's very similar to the XStream approach except that you get a schema (which can be very useful in certain circumstances. You can then again use XSLT to transform your XML documents into the cannonical format for binding. There's a little more work involved in regenerating the binding code and schema when the domain object changes vs. XStream but may be worth it depending on the situation.
  21. Re: comparison[ Go to top ]

    I was more referring to WSDL/Web Services stack. You start from XSD, then WSDL then JAXB-wsdl2java process.

    XStream seems very similar to Jibx, where you custom mapping format replace with XSLT, now it would be interesting to see how that approach works in Web Services/SOA environment.
    (not buzzword SOA, but realword integration SOA).
    I don't really see what the problem would be. All SOAP services I have every dealt with are just XML documents inside an envelope and REST based services are just XML (for puts and posts.) If you are actually using the SOAP types (oh the humanity!) consider this quote from Microsoft executive Don Box, the co-founder of SOAP when pointing out that w3c schema is 'the' language of web service definition: "Had XML Schema been done in 1998, we would not have done SOAP." http://www.infoworld.com/articles/hn/xml/02/06/06/020606hnbox.html
  22. XML Schema[ Go to top ]

    Well the reality is that XML Schema is de facto standard and is here to stay. I ain't saying its the best solution, and sure there are some drawbacks, but it is a industry standard. In the WS development context, is there any WS framework that supports XStream binding out of the box and in "native" way as Cxf does Jaxb? If there is better solution than Cxf+Jaxb I'll more than gladly try it. If you want to see how Cxf does it, download binary and see in folder "samples/mtosi_1.1". That is one very big and complex WSDL/XSD combination (300kb of WSDLs and 500KB of XSDs), and Cxf consumes it pretty good. And generated code is very very good, at least seems so to me.
  23. Re: XML Schema[ Go to top ]

    Well the reality is that XML Schema is de facto standard and is here to stay. I ain't saying its the best solution, and sure there are some drawbacks, but it is a industry standard.
    I'm not following. I made this point myself. What are you getting at?
    In the WS development context, is there any WS framework that supports XStream binding out of the box and in "native" way as Cxf does Jaxb?
    Not that I know of. I guess I'll have to add it to my list of open source projects to start.

    If there is better solution than Cxf+Jaxb I'll more than gladly try it.

    If you want to see how Cxf does it, download binary and see in folder "samples/mtosi_1.1". That is one very big and complex WSDL/XSD combination (300kb of WSDLs and 500KB of XSDs), and Cxf consumes it pretty good. And generated code is very very good, at least seems so to me.
    Perfect example of the problem I am talking about: mtosiHeader.value.setMsgName("getActiveAlarmsCountResponse"); mtosiHeader.value.setMsgType(MsgTypeT.RESPONSE); SimpleDateFormat formatter = new SimpleDateFormat("yyyyMMddHHmmss.SSSZ"); mtosiHeader.value.setTimestamp(formatter.format(new Date())); The above code is completely bound to the schema definition. No real xml-object binding has been accomplished. The task of sifting through the document has merely been moved into the Java code. The actually puts you in a worse position. Java is a terrible data transformation language. This becomes especially apparent with documents that have deep hierarchies with optional elements. You end up with code like this: if (parent != null) { Child child = parent.child; if (child != null) { GrandChild grandchild = child.child; if (grandchild != null) { GreatGrandChild greatgrandchild = grandchild.child; if (greatgrandchild != null) return greatgrandchild.someValue; } } } etc. I worked on a system that had many thousands of lines of code like this except there were as many as a dozen levels. Actually a lot of the code didn't work when I started playing with it because the null checks weren't done properly. Of course you could just trap NullPointerException but that seems pretty sketchy. You can also convert to DOM, which I think is the only way you can do programmatic searches without a lot of hardcoding but it's pretty stupid to bind to generated classes just so you can drop back to DOM.
  24. "The point"[ Go to top ]

    Regarding my "point", English ain't my native language and I thought you imply the solution to XSD/SOAP problem is RESTful approach. Glad we agree on that one. Regarding the rest of your post, "I'm not following...What are you getting at?" =) I know JAXB ain't perfect, but its the best one for work with WS stack at the moment, IMHO. I thought XStream might be alternative, but I'll have to wait for you open source implementation then =). Regards
  25. Re: "The point"[ Go to top ]

    Regarding my "point", English ain't my native language and I thought you imply the solution to XSD/SOAP problem is RESTful approach. Glad we agree on that one.

    Regarding the rest of your post, "I'm not following...What are you getting at?" =)

    I know JAXB ain't perfect, but its the best one for work with WS stack at the moment, IMHO. I thought XStream might be alternative, but I'll have to wait for you open source implementation then =).

    Regards
    Just to be clear, I think JAXB2 supports generating bindings and schemas from the Object. And if it works the way I think it does, that's great. You aren't doing yourself any favors by generating the code from the schema. If you need to bind to a database using Hibernate, those classes are going to be a problem. If you want to support other formats like JSON or X12 or whatever is out there over the horizon, you are going to struggle. You will be limited by what JAXB supports. And I don't believe that REST is a solution to WS*. I just thing that WS* is unnecessarily complex. In reality, I know I will have to support it because people still use it. Just like we still have to support FTP, EDI and all the other old standards. WS*, to me is just a newer legacy protocol.
  26. Re: XML Schema[ Go to top ]

    In the WS development context, is there any WS framework that supports XStream binding out of the box and in "native" way as Cxf does Jaxb?
    If there is better solution than Cxf+Jaxb I'll more than gladly try it.
    Spring WebServices supports a number of different ways to get objects from XML including XStream. I don't see any built in support for transformations in and out of XStream but I don't imagine it will be terribly difficult. I don't think SpringWS supports REST so I haven't really played around with it much but if I'm wrong about that, I'd be happy to be corrected.
  27. Databindings[ Go to top ]

    In the WS development context, is there any WS framework that supports XStream binding out of the box and in "native" way as Cxf does Jaxb?
    I tried this with XFire back in the day. But two things stopped me: 1. its support for namespaces sucked at the time. 2. It generated bizarro XML - like bleh. Just use JAXB. JAXB is: * Fast * Gives you some of the best XML schema support around * Is fairly easy to use (once you get over the fact that unqualified namespaces are the default) With the exception of the following cases I see very little need to use anything else [1]: * Need access to the XML infoset * Need to do some insane custom mappings (Don't bother. Just generate some POJOs and have a POJO conversion layer) - Dan 1. Provided you are a sane person doing sane thing with your web services. And there are plenty of you out there who are not.
  28. Re: suck?[ Go to top ]

    It comes as surprise to consider Java XML stack bad. Can you perhaps, if you are reading this, elaborate on "sucky" part, pointers to something that does it better than Java.
    I can. Please look here: http://cwiki.apache.org/CXF20DOC/appserverguide.html This is not CXF problem actually. It's just the state of XML in Java at it's best. I'm java addict, I love java and i think it's by far the best thing happened for Years. It's fun to develop in. It's mature yet interesting. Interesting except... XML. Actually it's not SUN's fault. It's not SAX, StAX, JAX-WS or JAXB. I'm fine with those. I like them, especially JAX-WS. The problem are... pluggable XML parsers in Java. "Write once, run anywhere" doesn't work here. Seemed that every decent Java vendor tried implement it's own parser. Some of them continue this trend so far. Look at Oracle, Bea and IBM - three vendors three parsers. Every with its own set of incompatibilities. It's shame that 7 Years after XML Schema became w3c recommendation we have to fight with problems described above...
  29. Re: suck?[ Go to top ]

    One of the biggest problems with XML in Java is the tremendously over-designed set of factories. I suppose the idea is that through "Patterns Gone Wild" you could magically replace your XML parser without changing the code. You'd just change a system property and 'blamo', I mean 'voila!' You've got, well something useful in some context, right? I'm not really sure when I would ever want to do that. The last thing I want is to go through all my testing and then have my parser changed to some other version or provider while I'm not looking. In fact, this has only been a pain point, never a helpful feature. If you've ever had to get get two web apps to use different parsers in the same instance, you've probably know what I'm talking about. If I really needed a factory for this, I think I'd be able to do it myself or if they had to provide one, I could choose whether I needed to use it. Lastly what's the point of providing the Result and Source interfaces if they have no real API. I'm not sure how I'm supposed to go about implementing these if I wanted to. I think you need to collect Frosted Flakes box tops and get a decoder ring or something.
  30. Re: suck?[ Go to top ]

    Cannot agree more. This: -Djaxp.debug=1 thing in javax.xml.parsers.SAXParserFactory isn't there without at a reason...
  31. why not in the apache namespace?[ Go to top ]

    it will be more appropriate if ur integration code is in the main apache project and have the same package name(i know that wso2 developers r axis commiters)but the difference in the package name make it looks like we use different products and many prefer the one stop shop why not just download from apache and so developer have all his needs,this will make devs much happier with axis which will be reflected on ur bussiness at wso2
  32. Not Webservices[ Go to top ]

    If you aren't using a contract-first strategy, you are not building services. You are just exposing APIs through HTTP. A lot of people will probably read this and think it's a meaningless statement but there's a big difference between exposing your beans through a WSDL and building a service. If you expose your beans this way and they are actually used by a significant number of consumers, these consumers will be bound not only to the interface that you exposed but also the (probably undocumented) behaviors it posses. This is likely to be permanent barring an extremely costly effort to migrate all clients. I know that before I pour concrete, I spend a lot of time making sure it's going to be right. I think it is really ill-advised to create 'services' mindlessly and without defining a contract.
  33. Personally I would like to see a good open source framework for REST based web services. I'm not sure if it's the way to go but WSDL 2.0 spec should theoretically support REST. I'm unaware of any tools that help with creating these types of WSDLs.
  34. WSDL 2.0 support in Axis2[ Go to top ]

    Axis2 supports the WSDL 2.0 HTTP binding, with which you can create fully RESTful services.
  35. Re: WSDL 2.0 support in Axis2[ Go to top ]

    Axis2 supports the WSDL 2.0 HTTP binding, with which you can create fully RESTful services.
    Does it provide any assistance in producing contract-first REST compatible WSDLs? thanks.
  36. Yes WSDL 2.0 theoretically and Practically supports REST. Have a look at the RESTSampe[1] of the WSO2 Mashup Server (Which is powered via Axis2). The Mashup Server is basically a simple way to write web services in JavaScript and also helps mash various data sources using JavaScript as the primary Language. You can have a look at the WSDL 2.0 (this is auto genarated based on your JavaScript source) we have there which describes this services very nicely. What's more you can try the service (The try it is generated of the WSDL 2.0 doc) and invoke it directly in a RESTfull manner. You may be also interested in the Writing RESTful services section of the Mashup server documentation[2]. Thanks, Keith. [1] http://mooshup.com/mashup.jsp?path=/mashups/samples/RESTSample [2] http://wso2.org/project/mashup/1.0/docs/index.html
  37. REST, WSDL 2.0[ Go to top ]

    Personally I would like to see a good open source framework for REST based web services. I'm not sure if it's the way to go but WSDL 2.0 spec should theoretically support REST. I'm unaware of any tools that help with creating these types of WSDLs.
    Don't use WSDL 2.0 for REST. It's an ugly way of doing RESTful services IMNSHO. There are plenty of great toolkits out there for helping you build RESTful web services. The ones I have my eye on are: * Restlets * JAX-WS RI - aka Jersey allows you to build services easily with annotations. CXF has support in the works too. * Apache Abdera - Build AtomPub services with Abdera. These are quite powerful... Please keep in mind that REST and SOAP programming models don't mix well. There is this complete fallacy going around (I succumbed to it too at one point) that you can use the same service class or description to build a RESTful and a SOAP based service. However, the interactions and mappings should end up being completely different from one to the other! One is message based and one is resource based. You're going to have to design your service differently as they're two completely different beasts. Use the best tool for the job. You'll save yourself time and a lot of hassle.
  38. Re: REST, WSDL 2.0[ Go to top ]

    Don't use WSDL 2.0 for REST. It's an ugly way of doing RESTful services IMNSHO.
    Did you mean to see this because its kind of a contract first approach for REST (I know that the REST guys dont beleive in contracts, but how on earth does a client know how to access a service)?
  39. Re: REST, WSDL 2.0[ Go to top ]

    I know that the REST guys dont beleive in contracts
    What? Really? That's way stupid.
  40. Re: REST, WSDL 2.0[ Go to top ]

    What? Really? That's way stupid.
    Agreed 100%, but thats the truth. REST guys do not like contracts. While developing WSDL 2.0 support in Axis2 we wanted to show that it can interop with existing REST services, and we set off to write a client for Flickr. It was tough cause the REST API for Flickr is described via plain english (no automation possible). So the first thing we did was write a WSDL 2.0 for Flickr which we used to generate client code via Axis2. I beleive that its good to have a standardized way to describe REST services.
  41. Re: REST, WSDL 2.0[ Go to top ]

    What? Really? That's way stupid.

    Agreed 100%, but thats the truth. REST guys do not like contracts. While developing WSDL 2.0 support in Axis2 we wanted to show that it can interop with existing REST services, and we set off to write a client for Flickr. It was tough cause the REST API for Flickr is described via plain english (no automation possible). So the first thing we did was write a WSDL 2.0 for Flickr which we used to generate client code via Axis2.
    I beleive that its good to have a standardized way to describe REST services.
    Maybe we mean different things when we say 'contract'. A spec in English can be a contract. It can even be better than a machine readable contract like a WSDL. A WSDL really isn't an adequate contract. There's a lot more to an API that just the ports and input and outputs. Things like explanations of what the data elements mean, SLAs, support contacts, and requirements on the input that cannot be expressed in a schema need to be specified. This is why you can't just generate a WSDL from your code and have a real service contract.
  42. Re: REST, WSDL 2.0[ Go to top ]

    Don't use WSDL 2.0 for REST. It's an ugly way of doing RESTful services IMNSHO.

    Did you mean to see this because its kind of a contract first approach for REST (I know that the REST guys dont beleive in contracts, but how on earth does a client know how to access a service)?
    No, I just don't like the operation oriented view of WSDL 2.0 to describe what is fundamentally a resource based service. I posted my thoughts on REST and description languages on my blog today if you're intersted: http://netzooid.com/blog/2008/02/07/why-a-restful-idl-is-an-oxymoron-and-what-we-really-need-instead/
  43. Re: REST, WSDL 2.0[ Go to top ]

    Don't use WSDL 2.0 for REST. It's an ugly way of doing RESTful services IMNSHO.

    Did you mean to see this because its kind of a contract first approach for REST (I know that the REST guys dont beleive in contracts, but how on earth does a client know how to access a service)?


    No, I just don't like the operation oriented view of WSDL 2.0 to describe what is fundamentally a resource based service.

    I posted my thoughts on REST and description languages on my blog today if you're intersted:

    http://netzooid.com/blog/2008/02/07/why-a-restful-idl-is-an-oxymoron-and-what-we-really-need-instead/
    OK, reading your blog, I am completely in agreement with your desire for a resource description language. Personally, I don't care if it's called an IDL. All I need is something that tells you how to resolve to a resource path, what parameters it takes (if any), what you can do with it, and what it will accept as input and what it produces as output. I'm not a big fan of WSDL. Actually I think it has been one of the worst standards ever created. How they decided it was acceptable to have two sections with redundant information in different formats is beyond me and it's been a very real pain point. I've even worked with 2 tools from the same vendor that could not understand each other's WSDLs. WSDL 2 seems to be an improvement. The biggest advantage I see is name recognition. But I don't see any competitors. You seem to have some strong feelings on this and understand the issues, have you got any ideas about how to do this? I could come up with some but I'm probably too new to REST to know if I'm missing something.
  44. Re: REST, WSDL 2.0[ Go to top ]

    Personally I would like to see a good open source framework for REST based web services. I'm not sure if it's the way to go but WSDL 2.0 spec should theoretically support REST. I'm unaware of any tools that help with creating these types of WSDLs.


    Don't use WSDL 2.0 for REST. It's an ugly way of doing RESTful services IMNSHO.
    I'm not looking to 'do' REST with WSDL 2.0, I'm just looking for a way to specify the interface in a standardized way. I don't know of any other standards for this.
  45. Re: REST, WSDL 2.0[ Go to top ]

    I'm not looking to 'do' REST with WSDL 2.0, I'm just looking for a way to specify the interface in a standardized way. I don't know of any other standards for this.
    Yes as i said before REST services can be described using WSDL 2.0.
  46. Re: REST, WSDL 2.0[ Go to top ]

    I'm not looking to 'do' REST with WSDL 2.0, I'm just looking for a way to specify the interface in a standardized way. I don't know of any other standards for this.
    You can also have a look at XINS, it's open source (BSD like license), the specification of the API is simplier than WSDL and you can import existing WSDL files. The default protocol is RESTful but you can also receive SOAP or JSON or HTML. http://xins.sourceforge.net/
  47. Re: REST, WSDL 2.0[ Go to top ]

    One is message based and one is resource based. You're going to have to design your service differently as they're two completely different beasts.

    Use the best tool for the job. You'll save yourself time and a lot of hassle.
    Which one do you consider message based and which one is resource based? I see them as both message based. In fact, I would say any communication across a network is a message and the idea that it can be something else is a delusion.
  48. Look at CXF. It has web services, REST etc.