Hi Mark, It would be great to have a paper from you. This is a very important topic.
Personally, I'm not convinced that either the REST approach or the WS-* approach solves all problems. I would like to have a discussion on the merits of a hybrid approach. But on the points about architectural constraints and properties such as reliability - yes, nothing is 100% reliable, but techniques exist to improve reliability. Sometimes these techniques are part of the communications protocol, for example in IIOP and WebSphere MQ. Other times they are layered on top, such as WS-ReliableMessaging on HTTP. I think it's a worthwhile debate as to whether or not these mechanisms are necessary for a given application, and while idempotency is important it doesn't work for everything. In particular an important constraing on HTTP is its deliberate lack of persistent sessions. This is what has led to many of the WS-* specs - trying to more or less redefine how other communications mechanisms handle things like secure conversations, reliablilty handshakes, transaction context propagation etc. It is valid to say these things can be worked around, or may not be necessary, but where they are already in use it may be too expensive to pull them out or rewrite them entirely. If the world were a clean slate perhaps HTTP and REST everywhere would make sense, but it isn't. One of the big ironies in all this is that SOAP was originally proposed as a Web-centric XML transmission format, and is ending up finding adoption inside the enterprise instead. Eric ----- Original Message ---- From: Mark Baker <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, December 12, 2006 11:07:20 AM Subject: Re: [service-orientated-architecture] Re: REST FAQ On 12/11/06, Eric Newcomer <[EMAIL PROTECTED] com> wrote: > I'd also like to point out that this recent discussion started with a > question about an alternative to WS-* and so far none has been presented. Because much of it isn't needed. It's rare that requirements map one-to-one with specs, like we've seen with WS-*; need reliable messaging, here's WS-ReliableMessagin g! How convenient! Need security; why, check out WS-Security! Need to transfer some metadata, you guessed it, WS-MetadataTransfer ! In well architected systems it's never quite that easy. For one, messaging is unreliable, so a requirement for reliable messaging is simply not going to be met; messages *will* get lost. What matters is reliability as a property of the architecture as a whole, and applying constraints which induce it... like, for example, having both known safe and idempotent operations per Lamport, and/or being stateless so that the well known problems of partial failure are localized. And so it goes for security/securabili ty, registries/reposito ries, etc... Fundamentally, Web components agree on a lot more when they're first put on a network than do Web services, and so you'd expect that things will be easier to coordinate by using that additional agreement. WS-* specs don't reuse that agreement, hence the solutions they suggest for problems are wildly different than Web based solutions. Imagine trying to explain microeconomic theory to somebody who speaks a different language; now, try to do it to somebody who speaks the same language. Each approach requires a fundamentally different approach, and the latter is obviously a lot simpler because of the additional agreement that existed prior to meeting this person. That's where the bulk of the Web's simplicity comes from; agreeing on more a priori. That's not to say that the Web, today, has everything the enterprise needs of course. It doesn't - it's not sufficient. But it is, effectively, necessary. I think I'll write this up as a paper for your workshop[1], Eric 8-) [1] http://www.w3. org/2006/ 10/wos-ec- cfp.html (oh, I thought the submission deadline was this Friday, but I see it's been moved to Jan 10) Mark. ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
