Why would I need to be reliable?

Hopefully, this is not going to start a REST vs. WS-\* debate, but there are a few arguments from the WS-\* side which usually RESTafarians agree to:

•  WSDL is good if you need a contract-fist approach (although WADL can help define contracts for REST endpoints).
•  WS-Security provides end-to-end message-level security (vs. point-to-point with HTTPS).
•  HTTP is unreliable and WS-ReliableMessaging has no equivalent in the REST world (reliability needs to live at the application level). I am not aware of any work in that area for REST, but if there is, I'd like to hear about it.

You may not need any of the above (in which case a RESTful approach may be more appropriate), but you if think you need reliability, Mike Grogan has a nice and short explanation on why you would want to use WS-ReliableMessaging and how the developer is impacted when using WSIT, the JAX-WS extension for many WS-\* specifications.

WSIT is now in Milestone 3 which works with GlassFish 2 b33c. Install is described here. WSIT M3 is also the build that will be part of the upcoming GlassFish v2 beta release.

Note also that Arun is running a series of nice ScreenCasts for GlassFish JAX-WS and WSIT. The latest one is also about WS-ReliableMessaging.


Comments:

Actually, a more accurate description of the RESTy perspective would be "we think contract-last Web Services" is half the problem of WS interop, and WSDL is the second half". It is a language too hard for humans to write, and is full of ambiguity, especially when used with Xml Schema. Together, XSD and WSDL are so unusable that most people are correctly scared to hand-write WSDL, yet mistakenly opt to their SOAP stack do it instead. Given that most of WSDL (1.x) is dedicated to defining the methods/services of endpoints, it is completely irrelevant to REST, where the interface is uniform across all resources.

The issues about where reliability and security should live are still ongoing. you only need end-to-end security when you are doing some kind of store and forward, which isn't part of HTTP.

As for reliability, well, it's a shame the examples use the blocking-RPC metaphor we've seen before. Surely appending actions into a fault-tolerant message queue would be a better tactic.

The jury is still out on WADL.

now, please defend WS-Addressing :)

Posted by Steve Loughran on February 27, 2007 at 02:56 AM PST #

Oh, you're missing something here w.r.t. end-to-end vs. point-to-point security. A couple of things actually. One is a proposal to do end-to-end authentication over HTTP 1.0 (i.e., not requiring persistent connections) using the GSS-API, with no server-side state, with channel binding to the TLS between the client's last proxy (if there's any) and the server's concentrator (if there is one). The other thing you're missing is that the WS-Security token profiles seem lame, or at least the Kerberos one does -- I've had trouble getting anyone to explain to me how Kerberos authentication is bound into WS-Security.

Posted by Nico on February 27, 2007 at 07:15 AM PST #

Also, for users all of this is meaningless: users know what they like and what they like we tend to call AJAX, and the only thing missing is decent security, and REST vs. WS-\* seems only tangential to that -- SAML seems much more relevant to the authentication issue, and TLS with channel binding from SAML tokens (or GSS-API contexts), seems much more relevant to the transport security issue.

Posted by Nico on February 27, 2007 at 07:19 AM PST #

Post a Comment:
Comments are closed for this entry.