Comments on: JAX-WS for RESTful Web Services? http://www.subbu.org/blog/2006/08/jax-ws-for-restful-web-services Wed, 08 Feb 2012 05:16:45 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Vasan http://www.subbu.org/blog/2006/08/jax-ws-for-restful-web-services/comment-page-1#comment-50430 Vasan Fri, 15 Jan 2010 17:31:54 +0000 http://wp.subbu.org/2006/08/jax-ws-for-restful-web-services/#comment-50430 Thanks for your Quick reply to my question. The blog was quite helpful in dissecting and understanding the JAX-WS overhead for REST. Thanks for your Quick reply to my question. The blog was quite helpful in dissecting and understanding the JAX-WS overhead for REST.

]]> By: subbu http://www.subbu.org/blog/2006/08/jax-ws-for-restful-web-services/comment-page-1#comment-50429 subbu Fri, 15 Jan 2010 17:23:49 +0000 http://wp.subbu.org/2006/08/jax-ws-for-restful-web-services/#comment-50429 Yes, JAX-RS is a good choice in the Java land. As you can see, I wrote this post before JAX-RS was even proposed as a JSR. Yes, JAX-RS is a good choice in the Java land. As you can see, I wrote this post before JAX-RS was even proposed as a JSR.

]]> By: Vasan http://www.subbu.org/blog/2006/08/jax-ws-for-restful-web-services/comment-page-1#comment-50426 Vasan Fri, 15 Jan 2010 16:34:42 +0000 http://wp.subbu.org/2006/08/jax-ws-for-restful-web-services/#comment-50426 What is your take on Jersey Suite. It sounds like it is a lightweight wrapper on the REST implementation. It might make the programming life simpler. What is your take on Jersey Suite. It sounds like it is a lightweight wrapper on the REST implementation. It might make the programming life simpler.

]]> By: Sameer Tyagi http://www.subbu.org/blog/2006/08/jax-ws-for-restful-web-services/comment-page-1#comment-132 Sameer Tyagi Wed, 06 Dec 2006 14:05:22 +0000 http://wp.subbu.org/2006/08/jax-ws-for-restful-web-services/#comment-132 Hi. Thanks for taking the time to read the article and post your review. I just happened to come across this link today so didn't have a chance to respond earlier. Would have been cool if you had posted a link to the above in the comments section on my blog. Anyhow, 1. The intention was not to show either SOAP or REST in "better light" but to present developers with options. I m not really sure how you gathered that. The summary also states that clearly. 2. On your comment about REST+state. You can also do state management with cookies in SOAP based services. There are also specs like WS-Secure Conversation (see wsit.dev.java.net) that combines security and state. You can also build stateful SOAP based web services using JAX-WS directly with the @Stateful annotation. See Kohsuke's blog [1] for details 3.On your comment about REST+performance. There are two kinds of performance, actual and perceived. Also when you use web services from resource constrained devices like like smart phones, bandwidth becomes increasingly important. 4. On your comment about SOAP+XMLHttpRequest - It's possible but not easy. Also a-priori knowledge and parsing of the WSDL may be required. 5.On your comment about semantics - The WSDL and schemas do serve as a contract. In real world scenarios and large enterprise applications, it is extremely unlikely that a service consumer will not know the semantics of the operations. Also most commercial web services management implementations that are used to encore SLA's and policies at the periphery use the wsdl and schemas as the contract. 6. On your comment about crud - If I were to read your explanation, I walk away with the understanding that every possible problem in the web services space can be solved by REST. This is nothing but untrue. There are actual viable use cases where the WS-* technologies and implementations like WSIT [2] for interoperability across platforms play an important part. 7. On your comment about JAX-WS vs Servlets. You are right in that RESTful web services can be built with servlets, but what about the case for polymorphic processors. 8. On your comment about what Jax-WS needs to do for REST. They are all very good suggestions. Could you possibly file RFE's for these on the jax-ws project page [3] so that the team can start looking at them more closely. /s [1]http://weblogs.java.net/blog/kohsuke/archive/2006/10/stateful_web_se.html [2]http://wsit.dev.java.net [3]http://jax-ws.dev.java.net Hi.

Thanks for taking the time to read the article and post your review. I just happened to come across this link today so didn’t have a chance to respond earlier. Would have been cool if you had posted a link to the above in the comments section on my blog.

Anyhow,

1. The intention was not to show either SOAP or REST in “better light” but to present developers with options. I m not really sure how you gathered that. The summary also states that clearly.

2. On your comment about REST+state. You can also do state management with cookies in SOAP based services. There are also specs like WS-Secure Conversation (see wsit.dev.java.net)
that combines security and state. You can also build stateful SOAP based web services using JAX-WS directly with the @Stateful annotation. See Kohsuke’s blog [1] for details

3.On your comment about REST+performance. There are two kinds of performance, actual and perceived. Also when you use web services from resource constrained devices like
like smart phones, bandwidth becomes increasingly important.

4. On your comment about SOAP+XMLHttpRequest – It’s possible but not easy. Also a-priori knowledge and parsing of the WSDL may be required.

5.On your comment about semantics – The WSDL and schemas do serve as a contract. In real world scenarios and large enterprise applications, it is extremely unlikely that a service consumer will not
know the semantics of the operations. Also most commercial web services management implementations that are used to encore SLA’s and policies at the periphery use the wsdl
and schemas as the contract.

6. On your comment about crud – If I were to read your explanation, I walk away with the understanding that every possible problem in the web services space
can be solved by REST. This is nothing but untrue. There are actual viable use cases where the WS-* technologies and implementations like WSIT [2] for
interoperability across platforms play an important part.

7. On your comment about JAX-WS vs Servlets. You are right in that RESTful web services can be built with servlets, but what about the case for polymorphic processors.

8. On your comment about what Jax-WS needs to do for REST.
They are all very good suggestions. Could you possibly file RFE’s for these on the jax-ws project page [3] so that the team can start looking at them more closely.

/s

[1]http://weblogs.java.net/blog/kohsuke/archive/2006/10/stateful_web_se.html
[2]http://wsit.dev.java.net
[3]http://jax-ws.dev.java.net

]]>