blog.atomikos.com

Some databases, like Oracle in particular, don’t seem to allow you to set the maximum duration for transactions (hence locks). This implies that some applications (those that don’t behave well) can be holding long-lived locks on your data. The result is that some data may become unavailable (even for days in one particular case I have seen!!!).

The solution? I am not sure about other products, but the Atomikos transaction libraries make sure that none of your applications can hold locks longer than the configured XA transaction timeout. Meaning: you get the benefit of ensured control and availability of your data. It’s ironic really; many people believe that XA can block your data but as this case shows it is exactly the opposite!

I have been waiting for ages to see web services get ready for SOA. Recently, hinted by a customer, I (re)discovered JINI. What that moment was like? Well, looking at JINI (in combination with JavaSpaces) I saw a dynamic lookup platform based on interfaces (read: capabilities - not names) and with scalability, self-healing characteristics and the performance of RMI. Javaspaces even adds the best of messaging and asynchrony. It sounds too good to be true.

To be continued…

For my Javapolis 2006 talk I decided to have a closer look at the WS-BA specification (then still in draft) and its relationship to BPEL 2.0 (then also still in draft). While I was at it, I also decided to use the committee’s minutes to clarify any remaining questions I had. This exercise took me a few days but the result made clear that the WS-BA protocol has serious limitations that make it not so useful as it could be:

The WS-BA protocol is almost entirely modeled after BPEL. WS-BA participants map one-to-one to BPEL compensation scopes. Because BPEL doesn’t provide close handlers, neither does the WS-BA protocol allow application logic on close. The implication? If you model your services as WS-BA services then you remain ‘in-doubt’ about every service invocation (in theory, the WS-BA close event would notify you that the deal is closed, but you’re not supposed to do business logic in that callback so it might as well not be there).

To give an example: if you are an airline and want to use WS-BA to make seat reservations transactional then you would never know whether any reservation needs to be canceled or not. More precisely: it will always be possible for any of your current reservations to be compensated at some later time.

The bottom line for you as a service provider: compensation is always possible. The consequence is far-reaching: how do you produce sales reports? You can’t, unless you accept that you are dealing with temporary data (that may later be compensated for). Every single sale you made can theoretically still be compensated.

Fortunately, WS-BA and BPEL allow you to model compensation as something that costs to the customer, so your sales reports may not suffer that much from compensation after all. But this leads us to another problem I have with WS-BA/BPEL: if you model compensation as something that leaves tangible effects (costs?) for the customer then what good is it for me to have that kind of transactional guarantee? After all, BPEL also says that compensation can be triggered by the failure of a parent task. So my customer may have to pay for my service just because some intermediary task has failed! I am not sure if it is just me, but I think this is a big problem.

One more point I have to make about WS-BA is that it appears polluted with workflow messages that don’t really contribute to the purpose of an agreed outcome across services. For instance, the ‘Completed’ message seems to be there just to indicate whether a participating service should be canceled (leave no effects) or compensated. But like I argued before, cancelation can still lead to compensation somewhere down the call stack so this is an utterly useless protocol message anyway. It only makes sense in the context of BPEL. And since BPEL is workflow, WS-BA is a workflow protocol and not a transaction termination protocol. In terms of efficiency it isn’t exactly very good either: there are too many unnecessary message rounds involved. It could all have been much simpler.

My advice: use the Atomikos TCC (Try-Confirm/Cancel) paradigm if you want really reliable and compensation-based web services. It is faster, better and leads to real business-level consistency across service invocations. You will at least know that your sales reports are permanent and correct, and your customers won’t pay for failed business transactions.

That should be the question, but most of the time it is not.

Many people don’t seem to realize when and why they need JTA/XA transactions. I really think you should look into this technology, because of a number of very good reasons. Let this blog post be your guide…

The only case where XA is not useful: if you only access one back-end system. In all other cases XA can help (assuming that you have XA connectors, like most vendors now offer). Note that JMS also counts as a back-end system access technology! So if you have one database and one JMS queue to access (on behalf of the same user/transaction) then you should definitely consider XA!

The most common objection: “yes, but XA is bad for performance!”. Maybe. Did you try it? If you didn’t then you don’t know what you are talking about. While it is true that XA incurs some overhead that you would avoid without, this overhead is necessary to ensure correctness of your transactions. The implication: without XA you can mess up your data really fast:-) My advice: try XA first, and only consider alternatives if you really really really really have to (or if you don’t care about your data). XA will make your code a lot simpler and more robust, trust me!

“I can design/code without it”. Is that so? It is true that one could write software that does similar things as JTA/XA. In the limit, you could even end up writing your own transaction manager. But is it within the scope of your project? I seriously doubt it. And is your code going to be bullet-proof? Maybe, maybe not. Will you test all possible anomalies and crashes in all possible combinations? Not likely (assuming you even know what those anomalies are - this is not so easy in some cases). And: are you going to maintain the code? Even less likely, because infrastructure code is often neglected. Not to mention the colleagues who will inherit your code after you leave to another job.

To conclude, consider this scenario: enterprise XYZ has been coding around XA for years. They now have 23 enterprise projects who all contain workaround code to avoid XA. Just calculate what it takes to maintain this unnecessary code in each of these 23 projects, and things may not even work correctly! And remember: the code you write today is the legacy of tomorrow.

Yes, it is true that XA software used to be expensive. Today, it is no longer the case. For instance, you can use Atomikos TransactionsEssentials for free…

Still not convinced? Here is my favourite question: what happens to your data after a crash of your server(s)? If you don’t know the answer, please use XA. And if you do know the answer: are you willing to bet on it?

Cheers

…and not something you buy!

If you only remember one thing from the BEJUG workshop on SOA then it should be this. And if you didn’t go to this workshop: make sure you can go next time, because it was worth it:-)

But seriously, all too often do people buy a product and then start to look at how to use it, say, to build a SOA (Service Oriented Architecture). This is like buying a car: would you get a rolls royce first, and then pick the road to drive it on? Or would you rather look at the road first, and then choose the best car for it? I would do the latter…

Best

With the finalization and publication of Web Services Addressing 1.0 - Core (WS-A) the world of web services has changed drastically (or will do so in the near future).

The idea behind addressing is to allow non-HTTP transports as well as HTTP transports, and even a chain of transports before a message finally gets to its destination. This would mean that a SOAP request can be routed via different platforms (JMS, HTTP, SMTP to name a few) and still make it to its destination. This goes hand in hand with asynchronous SOAP… Another major idea in WS-A is to allow acknowledgements, replies and faults to be returned to other addresses different from the original sender of a SOAP request.

A major consequence is that once again, the JAX-RPC processing model has to be stretched to accomodate this new standard. To see why, let’s consider what happens in a typical JAX-RPC service endpoint:

1. An incoming request message is received via HTTP.
2. One or more handlers (intermediaries) are allowed to pre-process the message (mainly its headers).
3. The service implementation gets the message to do the real (business) part of the job and generates a reponse (if applicable).
4. One or more handlers get to post-process the response.
5. The HTTP conversation is terminated by sending an acknowledgement (with or without a response message).

This is almost inherently a synchronous request/reply paradigm, and things like returning a reply to a different address become very cumbersome: this has to be done in a handler that shortcuts the reponse chain and sends the SOAP message somewhere else instead…

This is an interesting question. What do you think? Vote here (requires free registration).