> 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
Think about a service using a service which in turn uses a service etc. What happens is "infection" of a set of services which all together make up a distributed computation. How does an application coordinate the outcome of a collection of other application which it might even not know? How can the application ensure reliability in case of system outages? How (etc etc) This is all covered by the concept (and implementation :-)) of a coordinator which reliably runs an agreement protocol even in case of compensation based recovery. This kind of middleware plumbing should not be done by an application programmer, but this is (reusable) middleware logic... Frank ----- Ursprüngliche Mail ---- Von: Sanjiva Weerawarana <[EMAIL PROTECTED]> An: [email protected] Gesendet: Sonntag, den 26. November 2006, 02:49:12 Uhr Betreff: Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards) 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-AtomicTransactio n: 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/soareliabili ty/) (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.opensour ce.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2. com/ Director; Open Source Initiative; http://www.opensour ce.org/ Member; Apache Software Foundation; http://www.apache. org/ Visiting Lecturer; University of Moratuwa; http://www.cse. mrt.ac.lk/ ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
