WS-Transactions moves to OASIS Standard

I am a little tardy in doing so, but I am nonetheless very pleased to say that the WS-Transactions set of specifications (WS-AT, WS-BA, and WS-C) have been adopted as OASIS standards.
My co-chair, Ian Robinson, has written an excellent summary of the history behind the development of the specifications, including a link to Mark Little’s write up on InfoQ earlier this year.
I have to say it was really great working with Ian, and Mark, and Tom, and Max, and Colleen, and Bob, and I’m going to miss everyone. I really had a great co-chair and we really had a great TC.
At one point someone asked me how many TP interop standards I’ve worked on now, which number is WS-Transactions?
Well, let’s see – it’s either 4th or 5th, depending on how you count
The first was the Multivendor Integration Architecture (MIA) transactional RPC, back in 1990. This was essentially a combination of DCE RPC and OSI TP. This was submitted to X/Open somewhere around 1992 I believe and modified (among the modifications was Transarc taking credit for writing it – some things never change . So that’s either 1 or 2, depending on how you count it. This eventually became the X/Open TxRPC specification.
Sidenote: One of the interesting things about the X/Open DTP work, looking back on it, is the “basic compromise” that allowed the work to progress. The vendors could not all agree on a single interoperability standard, so they agreed to create three: TxRPC (basically DCE RPC), CPI-C (basically LU6.2), and XATMI (basically Tuxedo’s ATMI). All three shared a mapping to OSI TP for the remote 2PC. However it was mostly likely this compromise that got in the way of X/Open DTP solving the problem, since these specifications were implemented only by one vendor (maybe two for TxRPC) and all that remains in practice of this body of work is the XA spec (which is still used).
[I actually didn't know that the TP book Phil and I wrote is on books.google.com till I googled for X/Open DTP just now - see link at top of previous paragraph!]
In the late 90s I worked on the Transaction Internet Protocol (TIP) 2PC interop specification, which was my only experience working at IETF. This was adopted by Microsoft as their 2PC interoperability solution for a while (in OLE Transactions, at least betas), and implemented by Digital and Tandem, but I don’t think it ever became product.
After joining IONA I chaired OTS V2, which was also the interop spec adopted in EJB2. I also worked on the additional structuring mechanism for OTS around the same time, which is how I met Mark and Ian.
So that is also 4 or 5, depending on how you count (one OTS or two?).
One of the things that bugs me, after all this time, is that people still tend to look at the use of transactions either outside of their applicable area, or in a kind of black in white context in wihch you either always should use them or always should not.
In the first case, I often find people talking about client initiated transactions. To me a transaction does not exist unless and until there’s an operation on data. If the client has a transactional resource, then fine, it can initiate a transaction. If it doesn’t, it can’t. The server initiates the transaction. And a transaction cannot exist without a transactional resource, since by definition that’s what actually starts the transaction (you know, a database, file, or queue with a transaction manager capable of journaling, committing, and rolling back multiple changes as a group).
In the second case I hear things like “don’t ever use transactions in an SOA!” As if this statement had any practical value. As with any other technology, transactions have their applications. I can remember (unfortunately database coding before transactions were widely available. Believe me you don’t want to be in the situation of telling the customer service department to stop taking orders while you track down the partial updates in the database and remove them by hand, and of course figure out where they should restart entering orders once the system comes back up…
So yes, there’s a cost, and if you are doing distributed 2PC across a network, there is definitely an extra impact to the application’s performance. But sometimes the ability to automatically recover to a known point following a crash is worth it.
Yes, make it a conscious choice. You don’t always need it. But when you do, there’s no substitute. This is not something you want to try to code yourself and get right, always, and without fail.

Gregor Hohpe’s JavaZone presentation on Infoq

I have a lot of blogging topics to catch up on, but I just watched Gregor Hohpe’s presentation on Infoq and wanted to write about it while it’s fresh in my mind.
I really thought it hit home on a lot of very important points about SOA, especially things that developers (as well as the industry) need to think about.
I also would like to take him to task on a few items, including the fact that Starbucks does not need two-phase commit (I think this propagates a misunderstanding about transactions rather than illustrating how best to use them), but more about that later.
I really like Gregor’s book, and was in the same room with him once (the 2005 Microsoft MVP summit, since he and I are both Archiecture MVPs) but failed to introduce myself, something I still regret. He has a good, clear way of understanding integration issues and recommending how to deal with them. He does a great job with the presentation, clear, not too serious, and with a great perspective that acknowledges why things are the way they are even when saying that they are not exactly right.
I would definitely encourage everyone interested in development issues around SOA to sit through this presentation. It’s only about an hour – a little less – but Gregor covers a lot of very good territory, and raises a lot of good issues. Although I have to say that Gregor’s focus is on integration, while the main reason for SOA is reuse (not that these are necessarily in conflct, it’s probably more a matter of emphasis).
Ok, back to the Starbucks thing. Of course Starbucks doesn’t use two-phase commit – that would be like hammering a nail with a screwdriver – wrong tool for the job in other words. I completely understand the good advice not to use 2PC for this kind of scenario – what mystifies me is that someone would think it’s a good idea in the first place.
Transactions exist to coordinate multiple operations on data in order to record a real world transaction. No data operations, no transactions. Many argue that a retrieve operation is not a transaction, since the data isn’t changed.
And recording a real world transaction almost always involves multiple operations on data that need to be treated as a unit. Take the Starbucks example – the store has to record the payment and the fact that the drink was delivered. If either the payment isn’t given or the drink isn’t delivered the transaction didn’t happen and the record of it needs to be erased.
Computers being touchy electrical devices (as opposed to say, pen and paper), they can easily (and predictably, according to Murphy and everyone else) fail between data operations, and transactions are what ensures that the system of record (i.e. the database) matches the real world (i.e. if part of the real world transaction doesn’t complete, the database transaction rolls back one of the changes).
Starbucks no doubt uses some kind of database to record real world transactions. Therefore they no doubt also use software transactions, since it’s very hard to buy a database these days that does not support transactions, and even if you could you wouldn’t want to (personally I remember coding my own locking and doing manual recovery on an old HP Image database circa 1980, pre-transactions, but that’s another story).
Two phase commit (aka distributed transactions) is intended to be used when data operations involving multiple databases (aka transactional resources) need to be coordinated. I know that Gregor knows this, and is trying to illustrate the point that you should not automatically assume that you should use 2PC even if you can, but I for one think he could come up with a better analogy. In particular it would be helpful to illustrate when 2PC is worth the cost, and not just say “never use it.” In talking about most of the other topics he does usually get into a discussion about tradeoffs and when to use what, but in this case the advice is too simplistic for my taste.
Update 5/21 – this seems too long so I’m splitting it here…

Why SOA is different

What I should say, is: what is different that makes SOA popular now when it has been around for 10 years or more?
I’ve given this rap a couple of times now during the past couple of weeks, and I think I’m starting to get it down
I believe the reason SOA is popular now is that the IT software industry has reached a critical turning point in its history. I think this is what’s different.
30 or 40 years ago the big deal was which application to automate next. The idea of using computers to help run a business was new (never mind the idea that some businesses could be completely based on computers).
So everyone was trying to figure out which investments to make in which applications, many of which were automating manual procedures, and speeding up the flow of information, which in turn helped a business to achieve a return on those investments.
No one was really thinking about what do you do once everything is automated? But that’s more or less where the industry finds itself now. Enterprises pretty much have all the IT they need – certainly all the features and functions, languages, operating systems, packaged applications, database management systems, application servers, EAI brokers, etc.
The next challenge – for any industry in this position – is how to improve and refine what has already been done. And that’s why SOA is so popular, and why we at IONA have developed our unique approach to SOA infrastructure.
It’s not about building new applications or integrating ERP systems anymore. It’a about refining and improving what everyone has so it works better together. So it all supports the same level of abstraction and standardization, and all the existing applications we’ve worked so hard on during the past few decades can participate in SOA based solutions.
So we are now in a unique position – for the software industry at least – of looking backward to see what we did and how to improve it, and get more out of the investments we’ve already made – instead of looking forward to the next big feature/function, the next big release.
The industry is different, and needs a different approach to enterprise software. Specifically to support the reasons why SOA is so popular now, and takes into account the different stage of industry evolution in which we find ourselves.

Blog spam

Would somebody please enter a legitimate comment or post a legitimate trackback?
I know I am behind on blogging, but I’ve been out of the office for most of the past couple of weeks and I get back from this week away and I have about 200 blog spam to delete and a couple of dozen phony trackbacks.
Some of the entries are pretty clever, and I guess it’s progress of a sort to have more of them about MP3s and ringtones than porn, but it is still very annoying and if anything it’s getting worse…
Maybe if I look on the bright side this is one way I know that my blog is getting some traffic? Still it would be great to get a legit comment just so I can be sure I remember what one looks like….

WS-Context approved as OASIS standard

I’m very glad to say that WS-Context was approved as an OASIS standard.
(Catching up a bit here…;-) (See also Mark Little’s InfoQ article.)
Red Hat contributed a good presentation on it to the WSEC Workshop in February, and the minutes from that reflect the discussion around the open issue of state management for Web services. There was also a bit of praise for WS-Context from Nick Gall, who called out its support for both RESTful and SOAPy interactions.
(By the way we are still working on the workshop report, which we hope to complete soon. I am somewhat embarassed to admit that I am the holdup at this point, but I am expecting to set aside some time over the weekend to catch up on it.)
On the Web cookies are used to share persistent state between the browser and server, and several times it was proposed to rename “WS-Context” to “WS-Cookie.” But cookies aren’t compatible with XML (and therefore Web services) and more to the point aren’t suitable because they are opaque and owned by the server (i.e. not visible or updatable by the client).
Many WS-* specifications define their own context mechanisms for their shared state management, including WS-Security, WS-Transactions, WS-ReliableMessaging, WS-Trust, WS-SecureConversation, and WS-Federation (I may have missed some).
Although it’s possible to make an argument that this is a good thing (i.e. each context type is designed and tuned for each spec’s specific requirements and purpose) in practice I don’t believe it is.
Most distributed computing systems end up using a commmon mechanism to propagate multiple types of shared session context, including security creditials, transaction context, user and device information, database connection information, and so on, because it’s more efficient and easier to maintain than having to figure out which kind of context goes into which kind of mechanism.
It has been a long haul to get to this point. I’d like to thank everyone who contributed to the WS-CAF TC and to the various interop demos and POCs along the way.
I am hoping CXF will pick this up – certainly there’s been a discussion about this on the dev list – as a future release feature.
Once WS-Context starts to get some use, its advantages are likely to be recognized, and Web services will have its common mechanism for shared session state management.