On atomic transactions between multiple systems, I tend to agree with Stefan and Steve. In more than 20 years of building distributed systems, I've always found a better way than using 2PC protocols.
Besides, if your systems are so tightly coupled that they need to do 2PC then you might as well use a tightly coupled technology (LU6.2, Tuxedo, CORBA or whatever) to connect them. But Sanjiva makes a good point. Given that Microsoft is only supporting WS-Everything and not others for interconnection with its systems, you may well have a "tightly coupled" scenario of a Windows platform sitting next to a Java platform requiring 2PC style interactions. Perhaps here, WS-Everything is your only choice and this also ties in with Steve's argument about the importance of vendor technology support. When it comes to business transactions, I have a different opinion though. Back in 1995/6 I designed and built a large integrated CRM system for a telco. To implement a "single view of customer" database we had to integrate (in real time) with dozens of other systems from many different vendors. Our solution was a message-oriented middleware integration framework using request/response messaging. Of course there was no XML in those days, so we had to invent our own flexible message format consisting of name/value pairs and ASCII encoding. By implementing our own APIs we could get read access to most of the customer data required. Unfortunately, several of the "back end" application vendors wouldn't allow us to update their systems directly [for obvious reasons] and we had to resort to "screen scraping" as well. Oh and one of those vendors was so concerned about their system performance that they insisted we could only apply updates during quiet times (i.e. overnight). For those interested, our screen scraping tool was also custom designed and was driven by what today you would call a Domain- Specific Language (DSL). With this heady mix of synchronous read and [massively] asynchronous update activity, the preservation of overall data integrity was a big issue and we had to design our own extended transaction model to cope. This was a fairly classic "chained" transaction model where each step in the transaction chain had its own "forward" and "compensating" actions. The system could then [re-]apply or reverse entire business transactions in sequence and on demand. Building this business transaction framework was hard. Of course we wrote our own tools to help generate code for each kind of transaction step from a "service description" held as a database "view", but it was still a lot of work. Today I can see a lot of value in a standardised framework for such business transactions. Yes, the actual transaction steps are "business logic" and unique to each application, but a consistent framework will save a lot of development time/effort and also ease further integration and interoperability amongst similarly designed systems. -Mike. --- In [email protected], Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > 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/ >
