On 25/11/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > On Nov 25, 2006, at 3:50 PM, Sanjiva Weerawarana wrote: > > On Sat, 2006-11-25 at 08:44 -0500, Mark Baker wrote: > > > On 11/25/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > > > Well it shouldn't be .. if you don't need SOAP you don't need > > it. If all > > > > you need is to send some XML over HTTP or HTTPS then SOAP is > > not at all > > > > needed. SOAP should come into the picture IFF you need message > > level > > > > security, reliability or transactions or any of the other > > things that > > > > have been built on SOAP. If not why pay the price? > > > > > > What's interesting about this argument is an implicit assumption > > being > > > made; that if you had an existing HTTP/URI based Web API, but then > > > later found it needed "security, reliability, or transactions", that > > > you need to abandon the existing Web API and replace it with SOAP. > > > What about, oh, say, *adding* those ilities incrementally, within > > the > > > constraints of the existing API? > > > > Hey great idea! OK now tell me, what exactly does one need to do to > > add > > message level security to HTTP? After I sign the message where do I > > put > > it so the recipient will always check that before touching the > > message? > > > > How about reliability? (Remember HTTP-R?) > > > > How about transactions? > > > > NOTE: We need interoperable standards with corresponding metadata > > (i.e., > > policies) for all of the above so that tools can work with them. > > > Semi-seriously, I say "no, we don't". Let's take transactions as the > first example. Here are my three reasons why we don't need WS- > Coordination, WS-BusinessActivity or WS-AtomicTransaction:
I'm with you on these ones, Atomic Transaction on Web Services... I shudder. > 1) There are many successful WS-* implementations already (or so > everybody tells me), and none of them currently relies on these > (because they're neither finalized nor widely supported) I remember in 2001 having to do authenticated security using WS, so it was HTTP/S with client side certificates enforced by Apache. It worked and it was very secure, but its much better having standards like now exist. I completely agree than some of WS-* is 100% pointless and almost seems to be done because the product developers find it easy to do a certain type of standards that focus on a re-implementation of things that were better done without WS. > 2) Atomic (2PC) transactions are a bad idea for loosely-coupled > systems (I consider them to be the most tightly approach you can take) > 3) Even using compensations à la WS-BusinessActivity, IMO, belong in > the application -- they're business logic anyway, and I don't see > what standards support buys you here +1 > > > 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 > > I agree that none of them is standardized yet, which doesn't prevent > anyone from using them in their own applications, but hinders tool > development (which can be considered a disadvantage). Cheers for those pair, I hadn't come across them before, I'll go an have a look. Tool development and broad vendor acceptance is critical however. > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ > > > >
