On Sat, 2006-11-25 at 17:49, Stefan Tilkov wrote: > > Please tell me what standards in non-WS-* REST-land do these things. > As to transactions, I don't think anyone has bothered yet. As for > reliability, examples include > > SOA-Rity (http://www.goland.org/soareliability/) (by Yaron Goland) and > HTTPLR (http://www.dehora.net/doc/httplr/draft-httplr-00.html) by > Bill de hÓra
Don't forget RRMTP (http://sdec.reach.ie/rigs/rig0007/) :) :) -- Similar but slightly different to Bill's approach, but also provides reliable message delivery using a series of HTTP request/responses. In answer to Sanjiva, and probably against some of the more savvy REST proponents here, my personal plan for adding support for security has been to leverage existing specifications in the message, e.g. XML-ENC/DSIG. As I understand applications of REST, you still have an application protocol over HTTP as a transport protocol which defines what you need to do with your requests and responses. In some cases, that application protocol will be closer to HTTP than others, but it shouldn't go against the way HTTP was intended to be used. One reason I made the payload deliberately opaque in RRMTP was so that you could define an application protocol on top of that which passed completely encrypted messages over it, much the same way that we specialized it to support the Reach Envelope as the only valid payload in rig8204. If you attempt to send anything other than a well-formed, RCF-able Reach Envelope to a service using rig8204 as the transport, you're going to get an HTTP 5xx level response. HTTP principles are still valid, RRMTP principles are still valid (you would be in the PUT step of the protocol, in this case), but you may have the wrong application level protocol. The way I see this approach, you can then build your software in terms of any one of the layers that interests you, e.g.: HTTP Layer -- I only care about the transport RRMTP/Reliability Layer -- I only care about the reliable delivery protocol Application Layer -- I only care about the message. Transport and reliability are deferred to something else. While the composibility of SOAP/WS-* allows you to do this conceptually, it's harder to separate your concerns because everything is mixed in to the same SOAP envelope. Obviously, we have proven that SOAP/WS-* will work, but I see it as a much more "all or nothing" approach unless you start layering your concerns in other envelopes with attachments. But then if you're going to do that, why not just truly separate your concerns in the first place? Yes, clear specifications are important, and interoperability of implementations are also important, but with the way the WS-* stack is developing, it seems like we're rolling the "big ball of mud" from POSA1. Just because we can, doesn't mean we should. For my money, and the money of my clients, I want to ensure that the right level of flexibility exists in their solutions. I think you can achieve that flexibility in many different ways, but there's never going to be one unifying approach. This is why Gregg keeps trying to educate us all how you can apply JINI to implement SOA. However, I do believe that the more easily you can separate concerns orthogonally from each other, the more flexible your system will be. ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
