I need transactions, what I don't need are transactions managed across coarse grained facilities like Web Services. What I _really_ don't need are transaction boundaries that span across multiple enterprises.
SAP and some other ERPs are good examples of not needing this type of transaction, if you make a mistake you put a compensating request in (order 1000 widgets by mistake? place an order for -1000 widgets to solve the problem), this is a standard solution to the problem and it scales brilliantly. In terms of priority of importance and where vendors could have invested time (e.g. having something that enables me to say "don't call this service between 2am and 3am because its down for backup) then transaction management was massively at the end of the list. Having been doing Web Service systems commercially for 5+ years now I can safely say that I've missed not having WS-RM, I've missed not having WS-Security et al put I've never ever missed not having Transaction management. To me this is a great example of doing something "because we could" and putting heavy artillery into the hands of children. Steve On 25/11/06, Eric Newcomer <[EMAIL PROTECTED]> wrote:
I'll just point out that it's fine to say you don't need transactions - at least, until you find that you do need them. Eric ----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, November 25, 2006 3:51:06 PM Subject: Re: [service-orientated-architecture] ROA is not SOA - (was Alternatives to WS Standards) On 25/11/06, Stefan Tilkov <stefan.tilkov@ innoq.com<stefan.tilkov%40innoq.com>> 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] lk<sanjiva%40opensource.lk>> 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-AtomicTransactio n: 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/soareliabili ty/<http://www.goland.org/soareliability/>) (by Yaron Goland) and > HTTPLR (http://www.dehora. net/doc/httplr/ draft-httplr- 00.html<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/<http://www.innoq.com/blog/st/> > > > >
