The folks over at Microsoft working on Indigo have been doing some interesting stuff with their transaction engine. I've been keeping abreast on this as much as possible for some time, so it's nice to see it coming to fruition. What's even more interesting from a personal perspective, is that the architecture they've come up with and the requirements it fulfills, is very similar to what we've been using now for many years: basically a lightweight transaction engine that can be used in situations where not all of the ACID properties are required, but which can dynamically "step up to the plate" (as one Microsoft friend described it) if the need arises.
In some previous posts I've touched on the fact that we have in house something that fits that bill: ArjunaCore. This is a transaction coordinator (plus some associated tools and development frameworks) that has a very small footprint (hey, it runs on an old HP Jornada 720 in significantly less than 32 Meg of memory!) It took us several years of design and development to come to the current architecture, that allows it to be used within every transaction-related product we currently have. Without going into too many details (read the paper), it allows us to relax some or all of the various ACID properties in a controlled manner within products and is extremely fast and agile.
Note, this is not a "one-size fits all" protocol I'm talking about here: it's purely implementation. There's an important difference and the evolution of ArjunaCore has simply reinforced that distinction in my mind. I'm in the process of writing a paper on this, so will hold off saying too much more here.
Transaction processing is a difficult technology to implement well and also to convince people that they need. Terms such as "two-phase commit" and "persistence" are ingrained into people's minds as bad things, synonymous with "poor performance" and "high overhead". When talking to people about how they can use transactions, I've often heard reasons for them not using them begin with "Well, the trouble with transactions in our view is ..." But that needn't be the case and in many situations, the lack of transactions can lead to a much higher overhead if failures occur. Again, I'm writing a paper on this subject at the moment, but may blog on some aspects of it later.
I've had the opportunity to work for the Microsoft/Indigo crowd on several occasions but the timing has never been right. So it's nice to see two independent groups coming to the same ultimate conclusion about how to bring transactions to the masses.
There are many applications out there that don't use transactions and should; likewise, there are applications using transactions that really don't need to. I've believed for a long time that there are several things that we as an industry can (and should) do to help people understand where transactions fit into their architecture: education (why are transactions important? what happens if you don't have them? etc.), ease of use, flexibility (this crosses many different aspects, but includes what can be controlled, e.g., transactions existed before XA, so you don't have to limit yourself to XA-aware participants), performance etc.
We've managed to get a lot of the implementation-side of the equation into ArjunaCore and are constantly working on the education aspect. I know other companies and organisations are starting to look at a similar approach, and in the meantime it's always nice to get some implicit validation from a company like Microsoft.
Saturday, April 16, 2005
A book that changed my life
While dusting the copious books shelves we have in our house, I came across a book that really did help me through a pretty difficult time in my life. My mother has had multiple sclerosis for many years and while it's a difficult enough ailment for the sufferer to cope with, because of it's nature (few outward physical signs to start with, the ability to put symptoms down to stress, or strain etc.) it's often hard for the family and friends of the sufferer to understand what's going on. This book helped at a time when neither my mother nor the doctors could really put the why's, how's and what if's into words. I'd recommend it for anyone else in a similar situation.
Thursday, April 14, 2005
Research papers made easy
In my spare time (!) I'm a visiting research fellow at Newcastle University. I've written a few papers in my time and it's rarely an easy process. However, now some nice people at MIT have come up with a paper generator. It's fun to try out. Here's one I just tried, inputing a few friends names.
The scarey thing is, I'm sure one of the random ones it produced for me looked like a paper I did write ;-)
The scarey thing is, I'm sure one of the random ones it produced for me looked like a paper I did write ;-)
Tuesday, April 12, 2005
Thursday, April 07, 2005
Monday, April 04, 2005
TSS update
Just been talking to Floyd Marinescu of TSS. He'd seen our press release about the OEM deal with webMethods and has written a piece. Nice work Floyd and thanks.
Arjuna, webMethods and Casablanca
It's taken a little longer than expected, but the news is finally out: we've done a licence deal for our ATS 4.0 product with one of the most important Web Service players, webMethods. It's been fun and informative working with those guys and I'm looking forward to the next steps.
The Casablanca reference? Well "I think this is the beginning of a beautiful friendship."
The Casablanca reference? Well "I think this is the beginning of a beautiful friendship."
Friday, April 01, 2005
Tuesday, March 15, 2005
It's out
The GA of the ATS 4.0 Suite is now available for download. You may find that some features aren't enabled by default in the 30 day evaluation software, but we believe this won't affect the majority of evaluators. If it does, mail us and we're always happy to work with prospective customers to make sure your evaluation period progresses smoothly. Based on any feedback we get, we may revisit the decision to disable some features in future releases.
If you've any general questions, then please use the forum, where our engineers will respond as soon as possible.
If you've any general questions, then please use the forum, where our engineers will respond as soon as possible.
Monday, March 14, 2005
Thursday, March 10, 2005
Heuristics in WebServices.org
Back here I commented on the lack of heuristic support in some Web Services transactions specifications. Well I wrote a piece for webservices.org, that's been published here.
Monday, March 07, 2005
Submit those papers
I'm on the PC for the Web Services and Formal Methods workshop. So if you've anything relevant, I'd encourage you to submit.
Friday, March 04, 2005
REST versus SOAP
An interesting discussion going on here and here. I've watched these sorts of things happen over and over again for the past few years and it just seems to me like "use the right tool for the right job". Let's not have yet another "PC versus Mac" debate, or "C++ versus Java". Google use Web Services and Amazon support both approaches. There are good reasons for that.
Pat Helland moving
Pat Helland is moving jobs to Amazon. I know Pat from various HPTS workshops. A great guy who knows his stuff and has a wonderful voice. He's going to be joining the likes of Werner to create a great SOA+reliability group. Good luck Pat.
Wednesday, March 02, 2005
Tuesday, March 01, 2005
POA policies for Web Services addresses
Steve discusses one of the few major changes to WS-Addressing that the TC has made since it's inception. There's potentially some overlap with policy here and it definitely smacks of POA attributes/policies. Not sure if it's a good thing or not at the moment. Time to go away and muse over it.
Monday, February 28, 2005
Why WSDM isn't ready for primetime (yet)
So, the WS-DM TC are happy with their Committee Draft document and are now trying to get it adopted as an OASIS specification. STOP. DON'T DO IT! MOVE SLOWLY AWAY FROM THAT DOCUMENT!
As I've just explained in our vote to OASIS, we're happy with TC CD status, but the unfortunately the specification has dependencies on non-finalised and proprietary specifications, including WS-N and WS-Addressing. What's worse is that WS-N uses a different version of WS-Addressing than the WSDM specs do!
It's premature to elevate the spec. to the level of OASIS international specification. In particular WS-Addressing is currently being worked on and looks like the final version when it finally emerges will be significantly different from its various antecedent proprietary versions and won't be available until after July 2005. In particular, already we've seen that ReferenceProperties has been removed from the current draft of WS-Addressing in W3C, so this will have an immediate affect on WSDM. So you'd download the specification to implement it and find that it's pretty much broken!
I think to adopt this as a standard will set a dangerous precedent for OASIS. Specifications that attain the OASIS international specification level ought to be stable and have a certain amount of rigor and interop testing.
Let's hope the voting members see sense and send this back to the TC to correct.
As I've just explained in our vote to OASIS, we're happy with TC CD status, but the unfortunately the specification has dependencies on non-finalised and proprietary specifications, including WS-N and WS-Addressing. What's worse is that WS-N uses a different version of WS-Addressing than the WSDM specs do!
It's premature to elevate the spec. to the level of OASIS international specification. In particular WS-Addressing is currently being worked on and looks like the final version when it finally emerges will be significantly different from its various antecedent proprietary versions and won't be available until after July 2005. In particular, already we've seen that ReferenceProperties has been removed from the current draft of WS-Addressing in W3C, so this will have an immediate affect on WSDM. So you'd download the specification to implement it and find that it's pretty much broken!
I think to adopt this as a standard will set a dangerous precedent for OASIS. Specifications that attain the OASIS international specification level ought to be stable and have a certain amount of rigor and interop testing.
Let's hope the voting members see sense and send this back to the TC to correct.
Wednesday, February 23, 2005
The shape of things to come
Several years ago REM released a great song called It's the end of the world as we know it. That song seems quite appropriate in some ways at the moment, because we're about to release a GA version of the Arjuna Transaction Service 4.0. As I've said before, I've been working on Arjuna since 1987 and have seen it morph quite a bit over the years. As this paper shows, its seen a lot of changes and most of those have reflected changes in middleware architectures. So it's appropriate and in line with previous changes, that ArjunaTS 4.0 merges our formerly stand-alone Web Services transactions product ArjunaXTS with what has always been called the Arjuna Transaction Service and included JTA and OTS functionality.
There are several reasons why we took the approach back in 2002 to have two separate products and I'll mention a couple. When we were working as part of HP Middleware on the world's first Web Services transactions product it was a separate entity from what was then known as the HP Transaction Service; it also seemed unlikely that people would want Web Services transactions bundles with a transaction manager that required a CORBA ORB, despite the fact that you wouldn't use the ORB if you were working purely in the Web Services arena.
That last point has, with the benefit of hindsight, proven wrong. Back in 2002, just before the finalisation of the end of the HP-Compaq merger, I wrote an internal document about what I called End-to-end Transactions. (Apparently Gartner calls them Multimodal Transactions these days.) It was a way of describing how Web Services transactions (and specifically the product we'd been working on for HP) could be used to glue together other transaction domains, from mobile phones to laptops to mainframes, and incorporating potentially different transaction models. Some of this went on to become the Business Process transaction model in WS-Transaction Management, but most of it got filed in the dark corners of my brain when we span out of HP. But the main concept was that Web Services transactions don't just start in the Web Services ether: they'll typically begin in some corporate intranet and span to other corporate internets, with Web Services as the glue.
Funnily enough, over the past couple of years we've seen precisely this kind of use case from the early adopters of ArjunaXTS. Many of them have been asking for this kind of capability: bridging between J2EE transactions and Web Services transactions and vice versa. As a result, because we had two separate products (and the glue to stick them together), these early adopters ended up taking them both, with the added maintenance, setup, management etc. costs that that implies. So, one product seemed like an obvious improvement. I see the bridging capability a little like Sauron's ring: "and in the darkness bind them".
There are several reasons why we took the approach back in 2002 to have two separate products and I'll mention a couple. When we were working as part of HP Middleware on the world's first Web Services transactions product it was a separate entity from what was then known as the HP Transaction Service; it also seemed unlikely that people would want Web Services transactions bundles with a transaction manager that required a CORBA ORB, despite the fact that you wouldn't use the ORB if you were working purely in the Web Services arena.
That last point has, with the benefit of hindsight, proven wrong. Back in 2002, just before the finalisation of the end of the HP-Compaq merger, I wrote an internal document about what I called End-to-end Transactions. (Apparently Gartner calls them Multimodal Transactions these days.) It was a way of describing how Web Services transactions (and specifically the product we'd been working on for HP) could be used to glue together other transaction domains, from mobile phones to laptops to mainframes, and incorporating potentially different transaction models. Some of this went on to become the Business Process transaction model in WS-Transaction Management, but most of it got filed in the dark corners of my brain when we span out of HP. But the main concept was that Web Services transactions don't just start in the Web Services ether: they'll typically begin in some corporate intranet and span to other corporate internets, with Web Services as the glue.
Funnily enough, over the past couple of years we've seen precisely this kind of use case from the early adopters of ArjunaXTS. Many of them have been asking for this kind of capability: bridging between J2EE transactions and Web Services transactions and vice versa. As a result, because we had two separate products (and the glue to stick them together), these early adopters ended up taking them both, with the added maintenance, setup, management etc. costs that that implies. So, one product seemed like an obvious improvement. I see the bridging capability a little like Sauron's ring: "and in the darkness bind them".
Time to learn a new language
It's been a while since I learnt a new progamming language. The last one was C#, but that was 3 years ago. I've been looking around for a while and the one that's grabbed my interest is Ruby. There've been some interesting things said about it over the past year or so and it seems to have become fairly stable now. Time to take a dive into it, I think.
Sunday, February 13, 2005
Web Services Coordination Framework on its way
Last week we had the second face-to-face WS-CAF meeting to concentrate pretty much soley on the Web Services Coordination Framework (WS-CF). The first was in Dublin last November, where we made some fairly significant modifications to the specification and in this meeting we went through the 76 issues, closing many of them down. Because WS-CF builds on WS-Context the core concept that we've developed is the activity group: such a group is created when a context of a specific type (e.g., a coordination context) is begun via the Context Service. Participants can then register with that group via the endpoint reference (EPR) that is embedded in the WS-CF augmented WS-Context structure.
Because WS-CF is meant to be a low-level, generic coordination infrastructure, there's not a lot we can do at this level in terms of specific coordination protocol, i.e., coordinator-to-participant and participant-to-coordinator interactions. (Actually, we did a lot more in our initial submission to OASIS than we do now, but the TC has decided to remove some of that stuff and punt it to the higher level users/specifications.) So, apart from adding and removing participants, and handling recovery (yes, believe it or not, things do fail in the Web) of both coordinator and participants, that's pretty much WS-CF in a nutshell.
You might ask what's the difference between WS-CF and the IBM, Microsoft, BEA WS-Coordination specification? If you'd asked that question a couple of years ago (when we first released them) as many analysts did, the answer would have taken a couple of pages to describe. Now it's a lot simpler, but would still take a page, so I'll mention only two differences: WS-CF builds on WS-Context, so in our opinion fits into the Web Services architecture more naturally; it also handles basic endpoint recovery at the level that makes sense rather than making everything a users responsibility to figure out.
Anyway, I think that everyone who attended the meeting thought it went very well. Certainly I came away from it last week happy that we'd made a lot more progress than I'd hoped for. With any luck we should have WS-CF finished and almost at Committee Draft by April (we have to produce a Primer, which is probably the most work between now and then) and then we can move on to transactions, which is something I'm looking forward to.
Before I forget though, thanks go to CodeWorks for sponsoring the meeting. We've been working with these guys for a couple of months on helping to educate companies in our region on the benefits of Web Services and their remit is to publicise Web Services and the region as widely as possible. I think this was a good opportunity for them (and us) to get that point across to companies who attended the face-to-face and I'm confident that there'll be some tangible benefit to CodeWorks and the region as a result.
Because WS-CF is meant to be a low-level, generic coordination infrastructure, there's not a lot we can do at this level in terms of specific coordination protocol, i.e., coordinator-to-participant and participant-to-coordinator interactions. (Actually, we did a lot more in our initial submission to OASIS than we do now, but the TC has decided to remove some of that stuff and punt it to the higher level users/specifications.) So, apart from adding and removing participants, and handling recovery (yes, believe it or not, things do fail in the Web) of both coordinator and participants, that's pretty much WS-CF in a nutshell.
You might ask what's the difference between WS-CF and the IBM, Microsoft, BEA WS-Coordination specification? If you'd asked that question a couple of years ago (when we first released them) as many analysts did, the answer would have taken a couple of pages to describe. Now it's a lot simpler, but would still take a page, so I'll mention only two differences: WS-CF builds on WS-Context, so in our opinion fits into the Web Services architecture more naturally; it also handles basic endpoint recovery at the level that makes sense rather than making everything a users responsibility to figure out.
Anyway, I think that everyone who attended the meeting thought it went very well. Certainly I came away from it last week happy that we'd made a lot more progress than I'd hoped for. With any luck we should have WS-CF finished and almost at Committee Draft by April (we have to produce a Primer, which is probably the most work between now and then) and then we can move on to transactions, which is something I'm looking forward to.
Before I forget though, thanks go to CodeWorks for sponsoring the meeting. We've been working with these guys for a couple of months on helping to educate companies in our region on the benefits of Web Services and their remit is to publicise Web Services and the region as widely as possible. I think this was a good opportunity for them (and us) to get that point across to companies who attended the face-to-face and I'm confident that there'll be some tangible benefit to CodeWorks and the region as a result.
Subscribe to:
Posts (Atom)