I do not think anyone is trying to force you to use something you do not need. Not sure why you are arguing that.
With respect to the order of the standards, it was security first, then reliability, and then transactions. If there was no requirement for the transactions specs I can assure you we would never have worked on them or implemented them. I do not think any of us suggest using them where they are not needed or useful. One point that often gets missed here is that the approach is very open to extension and new models. Mark Little and I defined a very workable protocol for long running asynch transaction coordination across multiple software domains and protocols. However much people talk about loosely coupled systems, they are still not being built abstractly across heterogeneous system types. Once the industry gets to that stage however the only real way to ensure reliability of multiple operations on data will be to use transactions. As with everything there is a cost benefit and today most transactions are still performed at the back end. Almost every system of record uses them. The mega sites use them for replication. But today these are all monolithic systems without interoperable protocols. A good question is how far to extend coordination across services not just databases. The current work lays a foundation for achieving these things. We are very nearly done in fact. And if it helps anything, you should know that for the most part different people are involved in the transaction standardization efforts, and I do not believe anyone can say what we are doing is holding up any other effort. I think your main point is that you do not need transactions in your projects. That is of course no problem and I do not believe anyone would argue. But if you did find someday that you need them, coding the same yourself would be very difficult and expensive. Oh yes, you did mention compensation. Every well formed transaction should have a compensation. That is not a surprise. Another point is about forcing someone to use them simply because they exist. It seems strange to recommend the existence of something that is useful to some because it is abused by others. Eric [EMAIL PROTECTED] wrote: 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....
