On Sat, 2006-11-25 at 18:49 +0100, Stefan Tilkov wrote: > 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:
The reason you need something to support transactions is to be able to build transactional applications that span a collection of services. Are you saying that's not a useful or valid scenario? > 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) You've changed the topic around to WS-* bashing again .. the question on the table was how you do this stuff in REST :). FWIW I agree the WS-* version of the TX space is definitely lagging yet. > 2) Atomic (2PC) transactions are a bad idea for loosely-coupled > systems (I consider them to be the most tightly approach you can take) Of course, for widely distributed scenarios. However the most common usecase for WS-AT is to hold a transaction across a Windows system and a Java system "nearby". Is there another way to do that? > 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 That's exactly what WS-BA does- allow the application to become part of the transaction protocol .. the value of a standard is to be able to bring different services together into a single coordinated activity. Again are you seriously saying that's not a valid scenario? I agree its not a usecase for simple Web stuff but it most certainly is IMO is enterprise environments. I actually believe WS-BA will be very useful in Web scenarios as well. We just need very simple implementations and execution environments and we just don't have them yet. > > 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). Its more than tool support: what matters on the Web is *interoperability*. If I publish a service and it requires reliability to work well, I should be able to publish an interoperable protocol that a client from VB to C to Java to Cobol can do. The only way to do that is to have standards that all vendors support. That's the real challenge for REST. Remember that there's nothing new in REST- its been around for 15+ years and has worked great for the Web. Saying its the silver bullet for integration is a bit of a stretch when many of the core needs of integration are not met by the technology. Whether you like the details or not, they *are* met by WS-* stuff. Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Director; Open Source Initiative; http://www.opensource.org/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
