On 26/11/06, Eric Newcomer <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
It would be really useful to me to have some of the sample use cases for WS-TX that explained the scenarios that it would be used in. The charter just explains the technical infrastructure elements, rather than the requirements that led to it being needed. > > 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. I'm really not sure that is true, lots of ERP vendors get away without having this sort of transaction management available to consumers, and they seem to get on fine. > > 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. My point is that vendors concentrate on technical, rather than business focused, standards. This is why we see lots of different attempts at process and choreography, but very little around KPI, SLA or contract management. > > 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. People use things because they are there, its a simple fact, its the reason I'm against JAX-WS in JavaSE 6, its got callbacks in it, that is a bad idea in a basic platform IMO. WS-TX is an edge case standard that many systems have historically successfully avoided the problem of by architecting it out. It would be really useful to understand the business scenarios and requirements that led to WS-TX, I've done a of a search and all I can find is the interop one (which is after the fact) which is purely technical. > > 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.... > > >
