Guy's Blog

Towards a new democratic model for Europe: lessons learned from Belgian politics

2011-10-15T12:21:00.002+02:00

This blog post is to encourage a new model for politics and democracy. I am writing this down during lunch break so these are some quick thoughts that need more work to refine, but I think the idea is clear enough...

Some recent history that lead me to writing this: 3 years ago, Belgium sold its Fortis bank to France, for less than the intrinsic value (i.e., for less than the bank had money in its accounts). Today, in an attempt to save Dexia (a Belgian/French bank) our government has agreed to cover most of the risk for a bad bank construction. This is way less than France could/should have done, so once again our politicians have been ripped off by the French.

Because of this, we are now amongst the worst positioned countries in Europe should it ever come to a Greek bankruptcy. I am personally (as a citizen) supposed to warrant 5000 euro for this bad bank construction, along with every other Belgian. This is unacceptable to me: as an entrepreneur, my bank always used to ask hard guarantees and payback plans whenever my company asked for a loan. It turns out those same banks neglected to do so for others, or there would never have been those bad bank constructions in the first place. And our government is making it _our_ problem now.

This and many similar mistakes could have been avoided IMHO - if only we had a better democracy. The current system of elected politicians (mostly without any real life experience at all) is outdated. New media like Twitter and the Internet make information and interaction possible across a distance, instantly. Just look at the Twitter hashtag #dexia for the voice of the people in this. Among those people are many renowned economists, who had warned us for the mistakes that would be made.

So what would be a better democracy? One that takes those people's insights into account. Instead of politicians getting ripped off in their ivory tower, they could have formed an expert committee with knowledgeable people from industry who have dedicated their lives to their specialties. These people are easy to reach, just try Twitter for instance. I am sure they would all be willing to contribute, since they already do (without being heard it seems).

Perhaps the best way to explain is by referring to House, MD (the TV show). House is in charge, but he is continuously challenged by his team of experts. Together, they come to find solutions where others have failed. Our politicians should assume the role of House, taking responsibility for the final decisions. Unlike now, they should consult several domain experts to reach that decision. Now that would be an improvement... Remember: we are smarter than me!

So on to the House democracy, I hope.

Lessons learned being an amateur investor

2011-08-25T20:37:00.004+02:00

I am not particularly wealthy - not at all. I just have a bit of savings (rather modest, pension money and so on) that I try to safeguard for later. I started doing this about 12 years ago in 1999 - when stock markets were still euphoric. Needless to say, I 'invested' in stock and stock funds at my bank. Did I know... Today, I still have most of that stock, only it is worth a fraction of what I paid for it a decade ago.

That was when I learned a very important lesson: when investing, don't buy what everybody has been buying (and what therefore has been going up in price) because you are paying too much. Without exception, all my 'investments' today are still worth less than they used to be.

It does not end there: in the big crash early 2000s (bursting of the 'bubble') everybody with money pulled out in time (I didn't). Instead of stock, people started investing in real estate - at least where I live. Consequence: with everybody buying, prices of houses went up sky-high. You know, way too much demand. Today, houses are over-priced in Belgium (according to the IMF, and also according to my personal impression;-). My conclusion: now is a bad time to buy a house - at least in Belgium.

Then comes the current geopolitical situation. The dollar being unstable, the euro also. Inflation around the corner. Investors massively buying gold (and gold skyrocketing in price), smarter ones buying railway corporations (Warner Buffett).

Following my rule of thumb, what is left to put my savings into? Real estate? Don't think so - overpriced. Gold? Nope. Railways? Don't have those on the stock exchange here - and Belgian railways aren't really the smartest ones in their spending anyways;-)

So what is left? My careful conclusion is: the stock market again. Everybody is running away from it, so it could be time to move in. I spent most of the day researching undervalued stock on the Brussels exchange. Fingers crossed...

[Update: forgot to mention that obligations are not an option these days in Europe, and keeping money in the bank doesn't seem a good idea either with inflation lurking around the corner...]

Ondernemen is...

2011-07-20T19:54:00.006+02:00

Gezien de huidige politieke impasse in België, en de daarbij horende nefaste plannen om de nodige budgetten te vinden via extra belastingen voel ik me geroepen deze post de doen. De politici aan de macht zijn namelijk duidelijk niet op de hoogte van wat ondernemen is. Hierbij mijn ervaring van 10 jaar op een rijtje:

Ondernemen is een 60+ uren werkweek aan een laag loon (je wil de zaak draaiend houden dus beperk je de kosten - dat is verantwoordelijkheid).

Ondernemen in een kenniseconomie betekent: hooggeschoolde specialisten aantrekken die dus ook een degelijk loon verwachten. Totale maandkost voor een goede programmeur die 2500 euro netto verwacht (en waard is): 8000 euro! 2500 is voor de werknemer, de rest voor de staat (ok, sociale zekerheid zit erbij maar is niet de hoofdbrok). Om hier winst op te boeken moet je die ontwikkelaar al voor 12000 euro per maand kunnen 'verkopen' aan klanten, of het is niet rendabel. De werknemer zelf houdt er ook niet veel aan over (amper 1/3 van wat de onderneming betaalt), en vooral: als hij 2x meer uren doet dan krijgt hij daarom niet 2x meer uitbetaald. Dat is pas ambitie tegengaan! En voor de ondernemer is het ook niet makkelijk om een meerwaarde van factor 5 te realiseren.

Ondernemen is: risico's durven nemen en verantwoordelijkheid durven nemen, wetend dat de staat zo goed als niets doet om te helpen de nodige klanten en inkomsten te zoeken. Je staat er zelf voor (en terecht, dat op zich is geen probleem voor mij).

Je zou terecht kunnen vragen: waarom doet iemand dit? Hoe kan iemand zo dom zijn? Het antwoord: omdat er wel degelijk mensen zijn met ambitie. Er zijn mensen die denken dat ze de wereld kunnen verbeteren. Er zijn mensen die initiatief durven nemen. Er zijn mensen die risico durven nemen - op eigen kosten. De beloning? Mogelijk niets, of in het slechtste geval zelfs een faillissement. Je hebt het dan tenminste geprobeerd. Maar mogelijk ook: het verwezenlijken van de droom van succes en verloning op termijn, verloning waar je jarenlang alle hoop op een normaal leven en pensioen voor opgeeft. Verloning waar je alle risico's voor wil dragen, waar je alleen voor staat.

En wat wil de staat nu doen? De voornaamste verloning die een ondernemer kan nastreven, namelijk een overname, belasten.

Bovenop al de belastingen die de staat reeds oplegt (en die reeds schaamteloos hoog zijn in België), wil men nu ook nog eens de enige hoop die men kan koesteren om een beetje risico te nemen (en zelf te dragen, zonder tussenkomst of hulp van de staat!!!) in de kiem smoren. Niks Europese droom - afstaan zult gij! Risico nemen en initiatief nemen moet worden belast! Dit grenst aan het ongelooflijke. Walgelijk vind ik dit zelf. Ik word er zowaar misselijk van...

Mijn boodschap aan de Belgische staat: langs de kassa passeren is gemakkelijk, vooral als je er niets moet voor doen. Dit kan echt niet meer. Dit is onaanvaardbaar. Dit is onethisch. En dat terwijl er (uit eigen ervaring weet ik dit) met geld gesmeten wordt bij diverse overheidsbedrijven - op een wijze die totaal onverantwoord is! Met andere woorden: winst en initiatief belasten is makkelijk - en zelf laat de staat na te realiseren wat ze van haar ondernemers verwacht: meerwaarde, winst die kan "belast" worden. Die factor 5 realiseren om winst te maken. Als er 22 miljard gevonden moet worden: gelieve eerst de eigen budgetten en overheidsbedrijven door te lichten.

Mijn boodschap aan kandidaat ondernemers: ga weg uit dit land. Richt uw bedrijf elders op. Ik heb het hier gedaan omdat ik naïef was en dacht dat er zoiets bestond als rechtvaardigheid en loon naar werken. Ik vrees nu meer en meer dat dit niet zo is. Hopelijk heb ik ongelijk...

New revenue without income tax

2011-05-28T07:54:00.007+02:00

This post applies to all of Europe, and to Belgium in particular. With the recent turmoil regarding state expenses and how to gather the required money for the future (retirement funds, investments in the future etc) there is a big debate on whether it is best to cut government expenses or rather introduce new taxes.

I would like to seize the opportunity to defend an idea of mine (actually it is not mine, but I like it):

we take the very brave step of abandoning income tax altogether (read on!)

we collect all tax money via VAT

Now I know what you will think: raising the VAT would require a VAT rate that is unrealistically high. I think this is not true because this is in essence a redistribution of the tax burden to where the money is:

People who are in the black economy (drugs, illegal construction work, anybody else cheating) will contribute in this system.

Also, foreign visitors that consume in Belgium will contribute in this system.

Also, very rich people who consume more will contribute more in this system (now they don't - there is no tax on capital (good!)).

Everybody else that I might have forgotten will also contribute.

In summary: because more people contribute, there will be more income from VAT than there is now from income tax without a significant increase in VAT. To optimize, luxury goods could receive a higher tax rate than now. At the very least, this should be considered as a serious alternative by our Belgian politicians. Given the current polictical situation they surely have time to investigate this :-)

Edited: another reason why this is fair: heavy consumers pay more tax - this is also better for the environment. And one more: if you don't consume, you don't pay taxes. You can keep the money you make.

Hopefully, this kind of regime will also attract the foreign workforce talent we so much need here in Europe!

My top iPad apps

2011-03-26T12:08:00.002+01:00

I have been using the iPad for a while now (got the first model) both for business and for fun. My main goal was to eliminate most of the paper (reference guides) and personal notebooks I carried around all the time. In combination with my iPhone, here is how I managed to do that:

I use Evernote as the universal online storage (notebooks) for all my notes. The Evernote iPad app makes it easy to browse.

During meetings, I take pictures of the whiteboard (if any) and send them to Evernote so they become available on the iPad too.

My personal notes go the same way, either text created with the built-in Notes app or drawings with Jot! (another iPad app). All are emailed into Evernote.

The combination of Dropbox (for online file sharing) with Pages, Numbers and Keynote means I can access all my project files on the go, on the iPad.

Reading and annotating PDFs is easy with GoodReader and the Dropbox accessibility.

With iBooks, I carry all my reference books around on the iPad, with no extra weight or space requirements.

I use Omnifocus (synchronized with my laptop) to keep track of my daily tasks according to the Getting Things Done methodology.

That is the essence of my power stack for the iPad. Of course I also enjoy the email client and the browser, but those are not why I bought my iPad.

The only thing I am (just a bit) disappointed in is that handwritten notes are not well supported. I mean: it is hard to write (even with a stylus) on the iPad. You have to type instead, and typing is way faster on my laptop keyboard than on my iPad. So while I can manage for meetings, I can't really see how to make the system work for, say, following a training course and taking real-time class notes like I did in college. If anybody has any suggestions, feel free to post them.

No, I am not a politician

2009-05-26T22:34:00.005+02:00

In case you're in Belgium and wondering if I am into politics: this is not me (halfway down the page, more or less):

http://www.standaard.be/Artikel/Detail.aspx?artikelId=DMF20090525_110

Note: I am interested (very much) in politics, but not in the mess that the Belgian politicians have made of it (BTW: thanks, Yves L. and the rest of the bunch - time to move on and make progress now!)

Me, myself and I

New blog!

2009-03-13T15:39:00.002+01:00

We have a new website at Atomikos, and we have integrated a blog engine too.

Consequently, at least my professional posts will now be posted on the Atomikos blog.

I will keep this blog for occasional personal postings though...

Greetings!

Greetings from Devoxx 2008

2008-12-10T22:06:00.000+01:00

I was at Devoxx (formerly Javapolis) today. Besides wandering around in the lobby (I prefer to talk to people there rather than listening to talks), the only presentation I attended was on the SpringSource dm Server. Joris Kuipers did a nice job on explaining how the OSGi modules work (I think I got it - more or less;-)

Tomorrow (Thursday) I will be there too - so if you are around just make sure to say hi!

Atomikos for XTP: Transactions for Nothing and Failover for Free

2008-11-28T08:32:00.000+01:00

A lot of the hype in "Extreme Transaction Processing (XTP)" is fail-over. When Oracle bought Coherence (a Tangosol product), they essentially got an XTP solution for database access.

As Cameron Purdy notes here, this now allows Oracle to provide a degree of XTP failover.

Now guess what: with Atomikos TransactionsEssentials you get:

Transactional robustness for nothing, and

failover for free

How? Just do the following:

queue requests in JMS

process them by a cluster of competing consumer processes

use Atomikos TransactionsEssentials to ensure that each message is processed exactly once, without duplicates or message loss

By the semantics of queues, this architecture will give you failover. By the semantics of transactions, this will give you exactly once. Since the requests can be queued by any source, this is multichannel. Everything is commodity infrastructure. This is very easy to scale: just add another process.

In summary, this is XTP of the highest degree:-)

Why Amazon should use two-phase commit (or: how Amazon ripped me off)

2008-10-24T21:36:00.000+02:00

Working for Atomikos, I use two-phase commit a lot. While I don't want to claim that it is a solution to all problems, I do find it frustrating to hear people proclaiming that they don't use it because it doesn't scale (or some other reason).

Take, for instance, Werner Vogel's talk about the Amazon architecture. Once again, two-phase commit is rejected as a viable solution/technology. Once again, I disagree.

Let me illustrate my point with an example of what really happened to me recently - after ordering a book at Amazon (ironically;-). I can give similar examples with airline ticket reservations but those will have to wait until later...

So what happened really? Well, I ordered a book that I really wanted to have. I ordered it online at Amazon... All went well, I checked out and paid by VISA. However, that is where things started to go wrong: while waiting for the book to be delivered, I suddenly get an email from Amazon saying that... my order has been canceled!

Canceled? Yes, but not in a way you would think: I still had to pay for the delivery by DHL (sorry, what is that?!). Yes sir, DHL claimed they had found nobody present at the delivery address. The delivery was at our office address, so it is very unlikely that nobody be there in the first place. Moreover, any courier service I know will leave a note that they passed by and at least settle for an alternative delivery. Not this time.

My conclusion? DHL did not arrive at my place. On the Amazon order tracking page, my order had not even left Germany (to be delivered where I live, in Belgium).

Now what will I remember? I will remember that Amazon ripped me off, either directly or via DHL. I will also remember to be very suspicious about people who say they don't need two-phase commit. Two-phase commit comes down to ensuring agreement between the different parties involved in a transaction. Clearly, there was no such thing in my case.

A CAP Solution (Proving Brewer Wrong)

2008-09-07T12:17:00.000+02:00

One of the latest challenges in computer science seems to be the CAP theorem. It addresses a perceived impossibility of building large-scale and clustered (web) service architectures. The fact that it (supposedly) has been proven to be true makes what I am going to write here all the more unlikely. Still, read on because I will show that I am right and CAP is not an impossibility after all... While the impossibility proof of CAP is mathematically correct, it is based on assumptions that are too strict. By relaxing these assumptions, I found the solution presented here.

What is CAP?

The CAP theorem (short for consistency, availability, partition-tolerant) essentially states that you cannot have a clustered system that supports all of the following three qualities:

Consistency
: Consistency is a quality meaning (informally speaking) that reads and writes happen correctly. In other words, the overall effect of executing thousands or millions of transactions concurrently is the same as if they had been executed one-at-a-time. Usually, this is done with the help of a transaction manager of some sort.
Availability
: Availability essentially means that every operation (that makes it to a non-failing node) eventually returns a result.
Partition-tolerant
: This quality refers to the possibility of tolerating partitions on the network. Note that we suppose a cluster architecture (which is where the network comes in).

CAP is a conjecture originally formulated by Eric Brewer (Inktomi) and has influenced many of today's larger-scale websites like . In other words, the impact of CAP is very large. To make it worse, the perceived impossibility of a CAP system (one that has all three desirable properties) has lead people to advocate something called BASE (Basically Available, Soft-state and Eventually Consistent) - see this talk by Werner Vogels (CTO at Amazon).

As far as I know (but I could be wrong), a theoretical foundation of BASE does not exist yet (it seems more of an informal approach which to me raises serious questions concerning correctness). In this post I will present:

a CAP solution

how this conforms to what BASE wants to achieve

a "design pattern" for building correct systems that (in a way) offer both CAP and BASE qualities

Because CAP is perceived as impossible and because BASE lacks formal treatment, I consider this to be a signification contribution to the state of today's engineering;-)

What about the proof of Brewer's theorem?

Brewer's proof has been published by Nancy Lynch et al and discussed by me (see my earlier post and also this one).

While the theoretical proof of the impossibility of CAP is valid, it has a big limitation: it assumes that all three CAP properties have to be supplied at the same moment in time. If you drop this assumption, then all of a sudden you get into a new spectrum of possibilities. This is what I will do here.

A CAP solution

Enough talk, let's get to the core of the matter. Here is my solution to CAP. To make it concrete, I will use the concept of a web-shop like Amazon. Here are the rules that are sufficient to ensure CAP:

Process reads from the database if possible, or use a cached value if needed for availability (if the DB is unreachable).

All reads use versioning or another mechanism that allows optimistic locking.

Updates supplied by clients (orders in case of Amazon) are queued for execution, and include the versioning information of the reads that lead to the update.

Queued updates are processed when the number of partitions is low enough to do so. The easiest way to do this is with a cluster-wide distributed transaction across all replicas (more on scalability later), but other more refined ways are possible (such as quorum-based replication or any other smart way of replicating). The version information in the update is used to validate it: if the data in the database has been modified since the original read(s) that lead to the update, the update is rejected and a cancellation is reported back to the client. Otherwise the order is processed and a confirmation is reported back to the client.

The results (confirmation or cancellation) are sent asynchronously to the clients. This can be either email, message queuing, or any other asynchronous delivery method.

That's it. Adhere to these guidelines, and you have a CAP architecture. I will not provide a formal proof here (I intend to do that elsewhere, in a research paper), but intuitively the proof is as follows:

This system is consistent because reads are based on snapshots and incorrect updates are rejected before they are applied. In other words: there are no incorrect executions.

This system is available since reads always return a value, and so do writes (even though they are queued and it may take a while).

This system is partition-tolerant because it allows network and node failures.

Granted, this system does not provide all three at the same moment in time (which is how we go around the impossibility), but nevertheless the result is quite strong IMHO.

The limitations

There are some limitations to this solution - all of which seem reasonable:

Read-only requests may be presented with stale information (due to updates that have yet-to-be-applied). In that sense, their results could be "inconsistent": for instance, the availability of an Amazon item can change between two page views. I do not see this as a major restriction, since no website that I know of will offer read consistency for the duration of a user session. It all depends on what you consider to be within the scope of one transaction;-) Note that this almost corresponds to snapshot isolation found in Oracle.

Partitions should not last forever: in order for this to work, partitions should be resolved within a reasonable time (reasonable being: within the expected confirmation time for updates). The duration of any partitions also affects the time window in which reads can produce stale data.

The updates have to be applied in the same relative order at all cluster nodes. This puts some restrictions on the algorithm used to do this.

Note that updates are always based on correct reads thanks to the versioning check before they are applied. So update transactions are always consistent.

How does this relate to BASE?

You could see this as a design pattern for BASE if you like. The solution adheres to BASE in the sense that it uses cached reads (if needed) and that the updates are delayed (so you could say they are "eventually" applied and the system becomes "consistent").

Reflections in scalability

So far the CAP focus was on possibility. I think my solution shows that it is possible. Now how about scaling up?

The naive solution (a huge distributed transaction to update all cluster nodes in-sync) is unlikely to scale: as you add more nodes, more updates are needed. Now I am a big fan of transactions, but not to use them in an arbitrary matter. So how to propagate these updates through the cluster?

While smarter solutions for this exist (such as the work by Bettina Kemme), a trivial first try would be to push updates (lazily) to all nodes in the cluster. This can be done with a smart queuing mechanism. The disadvantage is that updates are not applied everywhere at once (rather, the all-or-nothing quality just "ripples" through the system). So you get into the "eventually" style again.

Note that this latter suggestion makes the system behave much like the READ COMMITTED isolation level (which, by the way, is the default in Oracle). So this approach sacrifices consistency/isolation a bit in favor of scalability.

Future work

Additional research could/should be done in the following areas:

Improving read consistency through session affinity

The best way to push the updates through the cluster

Performance evaluation in real life implementations

Final note and disclaimer

I did not see Brewer's original presentation of the CAP theorem - so it could be that what he meant with consistency also involved all reads (see the limitations of the solution I presented here). In that case I did not find a solution for CAP but at least it is a framework and proof outline for BASE ;-)

Why Forte migrations should use Atomikos

2008-09-06T12:54:00.000+02:00

Forté/UDS is an end-of-life technology that used to be in Sun's product portfolio. When talking to people who have been doing a lot with Forté in the past, it seems that Forté can be considered an ancestor of Java:

It has an object-oriented (4GL) development language.

Like Java's JMX, Forte also has instrumentation (the agent is even called iconsole - like jconsole for Java's built-in JMX agent these days!).

It has distributed transactions.

It has a strong notion of events as first-class citizens in the language.

The only thing that Forté does not have is Enterprise JavaBeans (EJB), nor XML configuration issues for the application server. This means that Forté developers who migrate to Java (because they are left little choice) get confronted with complexities that they did not have to bother with in their 4GL environment.

Thanks to Atomikos and the J2EE without application server methodology, teams who used to work in Forté can easily do Java/J2EE without having to bother about the clutter of EJB nor about the application server's XML hell. What's more, in combination with Spring, Hibernate and JMS there is an equivalent, light-weight Java stack that (thanks to Atomikos) can still do all the connection pooling, event-driven and transactional processing that is needed.

What makes it even better is that this methodology seems to achieve equal productivity as with the 4GL environment in Forté, which is pretty good given that Java is a 3GL and is not widely known as a productivity miracle.

The Achilles heel of the CAP theorem

2008-09-05T20:23:00.000+02:00

In my last post I discussed the theoretical proof of the CAP theorem. Both the theorem and the proof have a limitation that might very well render them not-so-universal as assumed.

The limitation of the CAP proof

The limitation of the CAP proof (as formulated by Lynch et al) is the following: it assumes that - for the purpose of availability - requests are to be served even when there is a partition in the cluster.

A way around the limitation

There is a way around this limitation - although it may sound exotic: just make sure that there are no partitions when requests are served.

How? By simply doing the following:

Queue requests (e.g., in JMS).

Only process requests when there is no partition problem.

Send responses asynchronously, for instance via email.

Since no partition (hopefully) lasts forever, this solution does not lead to livelock.

Also, note that quorum solutions exist to avoid that the complete cluster has to be up at the same time.

Is this the capitulation of CAP? Who knows...

My take on CAP

2008-09-03T21:54:00.000+02:00

The CAP theorem (Consistency, Availability, Partitioning) has been receiving quite a lot of interest lately, just to mention one of the many references.

What is CAP about?

First let me give credits here: I am deriving my inspiration from the theoretical insights found in this paper co-authored by one of my favorite woman scientists, Nancy Lynch from MIT. If you get a chance to read this paper, go ahead it will bring you some very useful fundamental understanding...

The CAP theorem is essentially a limitation on what you can do with clustered (web) services in the fashionable context of SOA.

The word 'cluster' is important here since that is what it is all about. In particular, the theorem states that you can't have all three properties (Consistency, Availability, Partitioning) in one and the same system (read: service). This implies that there is no perfect solution to building a high-throughput popular service, or is there? Let's first explore what each thing means...

Consistency

By consistency, the theorem refers to the property that changes (updates) to the service back-end are visible to later queries. Simplifying: if you add something to your shopping basket then it will appear there next time you retrieve your basket status. That sounds trivial, but it is not if the basket is spread over multiple physical server processes... Consistency is commonly ensured (between processes) by having some sort of distributed transaction coordinator, or (assuming a central back-end) a single centralized database.

Availability

The Lynch paper uses a very simple but sufficient definition of "availability": a system is available if every request to it returns. In other words: there is no infinite blocking.

Partitioning

Partitioning means the cut-off between two segments of the cluster. In other words, one or more nodes become unreachable for at least some time.

What is the Theorem saying?

You can't have all three of the above qualities, period. However, you can combine any two of them if you like. This is proven in the paper by Lynch et al. Also (and this is important) you can apply different combinations of qualities to parts of your system. Meaning: you can stress consistency in one part, availability in another part, and so on. For instance, order processing or payment processing can be done consistently and available (sacrificing partition tolerance) whereas querying the product catalog can be done differently (stressing partition tolerance in favor of consistency).

Does this contradict or invalidate Atomikos?

Not at all, quite the contrary: it makes Atomikos (and its third generation of TP monitors) all the more relevant. Why? Because Atomikos products can help you in making those parts consistent when you want them to be.

Virtually achieving all three qualities

If you embrace asynchronous messaging (a la JMS or email) and extreme transaction processing (XTP) then it is possible to asymptotically realize all three qualities (consistency, availability, partition-tolerance) provided that you do use a callback mechanism to communicate results (e.g., by sending a confirmation email). Here is how:

Queue requests in JMS.

Process each request transactionally (so failures will leave the request queued for retries).

The process that digests each request can be arbitrarily complex and use transactions (consistency) and return whenever it likes (thanks to the queuing, no reply is expected within a preset time frame).

Any lack of availability of the processing is recovered by the queues: failed requests will stay queued until the process in the back-end is in fact available again.

Now did I just break the CAP impossibility? More on this in a next post...

Unlimited scaling, easy!

2008-08-01T13:00:00.000+02:00

Suppose you want to develop a high-volume transaction processing system in Java/J2EE. How would you do it? Most people would say: don't use JTA/XA transactions because they kill performance. Wrong. And they would also say: use an appserver to scale. Again, they couldn't be more wrong.

Here is the magic recipe on how we build systems with virtually unlimited scalability at Atomikos:

Kick out your appserver as soon as you can, as explained here. J2EE is not limited to an appserver. J2EE is a set of APIs. The appserver ties these APIs to a programming model that almost nobody needs. Conclusion: drop the latter.

Use a persistent JMS queue to store transaction requests. This allows easy load-balancing and provides crash resilience for ongoing requests. It also de-couples the clients from the transaction processing system.

Use ExtremeTransactions to process the requests (stored in JMS). This allows for reliable, exactly-once message processing as outlined here. Make sure to use the supplied JMS and JDBC drivers!

To add more power, just add a second VM (process) on a separate CPU.

Repeat until performance is high enough.

You will reach the required performance because of the intra-VM nature of each process you add. The only potential bottlenecks are your own database or JMS backend. So scaling comes down to scaling your backends, which is much simpler than scaling your application itself (which has already been done in a natural way as outlined above).

So don't let anybody fool you: transactions do scale - even without limits!.

Loosely-coupled deployment vs loosely-coupled design

2008-07-31T08:42:00.000+02:00

I have talked to a number of people who claim to be doing SOA, when in the end all they do is loosely-coupled design. Let me explain what I mean by an example.

A team of enterprise architects was designing an SOA infrastructure for a bank I know. The system they were building would be based on interfaces, so that it would be possible to deploy parts of the system as separate instances later on. This was their notion of SOA...

The good thing about it is that there are interfaces in their design, meaning it is likely to be loosely-coupled. The bad news is that this is not SOA, at least not in my view: one of the biggest advantages of SOA - reuse in place - is never realized in this way. So, whereas this approach to 'SOA' may be loosely coupled in design, it is not loosely coupled in deployment (which is at least as important).

The consequence? Whenever a 'service' is upgraded, they will need to upgrade all the dependent services and redeploy them. This is because each 'service' is really an embedded module inside other parts of the system.

I guess this also holds for the debate on cloud vs grid computing: in my view, a cloud is more loosely coupled than a grid in its deployment.

BPEL and compensation

2007-10-19T22:15:00.000+02:00

Is BPEL a good tool for implementing compensation? It really depends, and you really have to know what you are doing - which (with all respect) doesn't seem the case for most people (not even BPEL specialists). So if not even those experts know, how can we expect the rest of us to know? Hence this blog entry.

For instance, on repeated occasions I have heard renowned BPEL and workflow experts mention that compensating transactions are "perhaps" best modeled at the business logic level. This, by the way, includes Bill Burke in the case of JBoss/jBPM - see here. Note that I emphasized the word "perhaps": this indicates the shade of misunderstanding usually present in the arguments.

I have been saying this here and there in the past (and in fine detail in this article), but I want to repeat it again: BPEL, nor workflow nor WS-BA are ideal for compensation unless the compensating party doesn't care whether it needs to compensate eventually. In other words, if the compensation is business as usual to the provider of the compensatable service then BPEL might be OK (though certainly not desirable - see below).

Why is that? Put yourself in the place of a service that is asked to compensate by a BPEL engine somewhere. Also suppose that you are in a B2B ecosystem where you don't necessarily trust the party that owns the BPEL engine. Now what would you rather do: trust the BPEL to compensate - eventually (which might be never!) or rather deal with compensation yourself, say after a timeout? I would definitely choose the latter. I don't want someone else to decide when I need to compensate. I want to decide for myself, and the Atomikos TCC model allows for that. BPEL and jBPM don't.

So BPEL is ruled out for me - at least as far as compensation goes. What about WS-BA? It is a step in the right direction, but unfortunately it is a bloated protocol, very inefficient and loaded with application-level messages that pollute the compensating part. Even worse, it also suffers in a large part from the lack of timeout and depends on the BPEL to at least trigger compensation.

Also, WS-BA doesn't allow for application logic on close - I won't go and bother you with the entire spec details but it is like a try..catch...finally where the exception is raised by the client (ugly!) and where the finally block can only be empty! Again, Atomikos TCC is far superior, more efficient and more elegant. It is also more natural for compensation than any BPEL engine will ever be.

One last note on BPEL and this supposed "modeling the compensation in the business process": I was talking to an IBM architect the other day. He said that they were doing a large telco project with BPEL to co-ordinate things. One of the things he complained about was exactly this: they have to model the compensation and error logic as explicit workflow paths, and it was literally overloading everything with complexity. Moreover, this complexity is hard to test. As he correctly put it, they were implementing a transaction manager at the business logic (BPEL) level, over and again in every process model. In addition, this was also hard to test he said and that it was virtually killing the project - especially if there were change requests to consider. I believe him:-) I gave him the URL to our TCC article above.

Atomikos and TCC allow you to focus on the happy path of your workflow models. We take care of the rest. Now imagine what a reduction in complexity that is, and how much more reliable things get! So no, compensation should NOT be modeled at the business level. Except on rare occasions maybe.

REST and reliability

2007-10-19T09:46:00.000+02:00

Whenever I see a presentation on REST I am impressed by its simplicity. With just four operations (GET, POST, PUT, DELETE) it seems to accomplish a simple model for service-oriented architectures, where every business resource has a URL.

With this simplicity, REST also leverages the ubiquitous HTTP protocol as the underlying mechanism. More and more people seem to like this, including me.

However, the big question for me is: how do you make this reliable? Imagine that you integrate 4 systems in a REST style. You would be using HTTP and a synchronous invocation mechanism for each service. Now comes the question: how reliable is this? The answer: less than the least reliable system that you are using! More precisely, availability goes down quickly because your aggregated service fails as soon as one of the services fails...

With transports like JMS you can improve reliability, but how do you do REST of JMS, given its close relationship with HTTP and URLs? That is the problem with REST for me.

Data Replication in SOA: The Price of Loose Coupling

2007-10-11T15:59:00.000+02:00

When designing a corporate SOA architecture you are often faced with a tough choice: do you rely on a common database (centralized) or do you implement replication instead?

Let me explain what I mean. The idea in SOA is that you define more or less independent services that correspond (hopefully) to clearly defined and business-related activities. For instance, you could have a customer management service and a payment/invoicing service. The customer management service belongs to CRM, the invoicing to the billing department. However, both of these services might need the same customer data. Now what do you do? Basically, you have the following options:

Use the same centralized customer database. This gives you the benefit of easy maintenance because there is only one copy. However, this also means that you are coupling your services into the same database schema, and updates to the schema are likely to affect more than one service.

Replicate the customer database, by identifying one master (the CRM?) that regularly pushes or publishes updates (in an XML feed, for instance). While you lose the benefit of easy maintenance, this does give you loose coupling: as long as the XML format is the same, you can change DBMS schemas as much as you like - without affecting other services.

Merge the customer and invoicing services into one. However, this may not always be possible or desirable, and may even defeat the purpose of service-oritentation altogether.

Have the invoicing query the customer service for each payment. Thi seems to incur a lot of dependencies and network traffic.

So what do you do? My preference tends to go to the second option. However, it means that realistic SOA architectures are likely to have an event-driven nature.

Atomikos Offers 3rd Generation TP Monitors

2007-10-08T16:47:00.000+02:00

This post on InfoQ was made by Arjuna, one of our (ex) competitors after JBoss (and then Red Hat) bought their transaction technology.

More interesting than the referred paper are the comments, which I would like to discuss here. Most posts seem to rule out transactions as something that doesn't scale. None of these comments I agree with.

The main complaints uttered seem to fall into these categories:

Transaction managers are supposedly centralized.

Transaction managers are accused of overhead for two-phase commit and synchronization.

I will now show that both these statements are a misconception, claiming that the 3rd generation transaction monitor already exists. Moreover, I will show that 3rd generation transaction managers are better than (or at least as good as) the alternatives - when used correctly.

The product I am talking about is Atomikos ExtremeTransactions, including its JTA/XA open source edition named TransactionsEssentials. Let me now outline why none of the above objections are actually accurate:

Atomikos ExtremeTransactions is a peer-to-peer system for transactions. Whenever two or more processes are involved in the same transaction, the transaction manager component (library) in each process will collaborate with its peer counterpart in the other process. This is how it is done. Consequently, there is no centralized component nor bottleneck. Our studies have shown that this gives you linear (i.e., perfect) scalability. This invalidates the first criticism above.

While two-phase commit does incur some synchronization, the same is true for any other solution (assuming that you want to push operations to one or more backends). A simple example to illustrate my point: many people think that queuing is a way to avoid the need for transactions (and two-phase commit). Is it? Hardly: even if we neglect the resulting risk in message loss (see http://www.atomikos.org/forums/viewtopic.php?t=108) then you have to realize that most queueing systems use two-phase commit internally anyway. This invalidates the second criticism above.

The often-heard criticism that transactions may block your data is not fair either.
There is some interesting theoretical work done by Nancy Lynch (MIT) et al - I believe it is this one. Basically, this is mathematics that proves that you cannot have a non-blocking (read: perfect) solution for distributed agreement in realistic scenarios.
In practice, this means that a queued operation may not make it if the connection to the receiver is down too long. So your system is 'blocked' in the queue, even though you don't use transactions. This is the equivalent of the perceived 'blocking' but now placed in a non-transactional scenario.

Again on the perceived synchronization overhead: if you don't keep track of "what" you have done and "where" (by synchronizing) then you end up with an error-prone process. This is especially true for many critical applications that consume messages and insert the results in a database. If you don't use transactions then you will find yourself implementing duplicate message detection and/or duplicate elimination, none of which are safe without the proper commit ordering. Basically, you are implementing a transaction manager yourself (yuk!).

Am I saying that transactions and two-phase commit don't block? Not exactly - especially if you use XA then things can block. However, Atomikos avoids this in two ways:

Very strong heuristic support: unilateral decision are encouraged both in the backend and in the Atomikos transaction manager. If a transaction takes too long, it is terminated anyhow. Where classical scenarios would block, Atomikos enforces a unilateral termination by either party. The resulting anomaly is reflected in the transaction logs, so the transaction manager can track problem cases (instead of letting you chase different systems to find out what happened - the alternative without transactions). Ironically, we have seen more blocks caused by non-XA transactions: if your database does not support an internal timeout mechanism for non-XA (which seems to be so in the most commonly used DBMS) then it will be non-XA transactions that cause the blocking!. I can go on for hours about this - but that is another post.

Atomikos also offers local transactions with compensation instead of rollback: you can use our TCC (Try-Cancel/Confirm) API to handle overall rollback. This allows you to use non-XA, local transactions. It never blocks your application, ever! TCC is similar to WS-BA, only better because we have been working on it for much longer than anybody else in the world. See http://www.atomikos.org/forums/viewtopic.php?t=97 for more on TCC.

Summing up then: do I recommend two-phase commit? Yes, if needed. In the past, this need arose out of legacy integration. In the present and future, that need arises out of up-front requirements. The most typical use cases are:

Processing persistent messages with exactly-once guarantees. There is no substitute for the reliability and ease of Atomikos ExtremeTransactions here. Note that this can be done intra-process!

Across processes/services if you have a reservation model inherent in your business process. Our TCC technology will make sure that your database never blocks.

More information about Atomikos products can be found here

My JP06 talk on Parleys...

2007-05-08T19:06:00.000+02:00

My J06 talk on WS-AT and WS-BA is now online here

Thanks to Stephan Janssen, Guy Crets and the rest of the BEJUG crew!

-Guy

Controlling Lock Duration in the DBMS

2007-03-06T07:20:00.000+01:00

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!

Building a SOA with JINI

2007-02-26T18:23:00.000+01:00

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...

WS-BA for Compensation-Based Web Services

2007-02-24T09:23:00.000+01:00

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.

To XA or not to XA

2006-10-31T07:32:00.000+01:00

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

SOA is something you do...

2006-10-31T07:24:00.000+01:00

...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

Guy Pardon: Transactional J2EE Apps with Spring

2005-11-27T22:03:00.000+01:00

Did you hear about Spring? In my opinion, it is going to play a big role in J2EE and simplifying Java programming. At least when it comes to transactional applications, things are much simpler than with EJB.

Have a look for yourself: TSS was kind enough to publish my presentation on Spring.

WS-Transaction under OASIS custody!

2005-10-18T10:30:00.000+02:00

Rumors had been around for a while that this might happen, and it did: the WS-Transaction specs (proprietary work until recently) are now under the custody of the OASIS standards body: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx

Vendors supporting the WS-TX initiative include BEA Systems, IBM, Microsoft, Oracle, SAP and TIBCO. This sounds like the kind of industry momentum needed to push acceptance in the market:-)

The new standardization committee is open to anybody - I would participate too if it weren't for the strict IPR policies used by OASIS...

Web Services Addressing and JAX-RPC

2005-10-13T13:45:00.000+02:00

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:

An incoming request message is received via HTTP.

One or more handlers (intermediaries) are allowed to pre-process the message (mainly its headers).

The service implementation gets the message to do the real (business) part of the job and generates a reponse (if applicable).

One or more handlers get to post-process the response.

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...

Web service transactions: very long, long or just short?

2005-10-10T20:31:00.000+02:00

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

Where will Europe be in 2010?

2005-10-08T14:37:00.000+02:00

You may have heard about the recent enthousiasm about Turkey's 'approval' for starting the entry procedure into the EU. This is certainly good news, but what Europe really needs right now is something more than a loose federation of countries.

In particular, in order to stay (or become) a competitive economy, a lot more action is required to reform the internal household and strategically align all member states. And I am not even mentioning the issue of a constitution here (whether or not that is needed is subject to discussion).

Then what am I talking about? I mean setting priorities straight, and making sure that all that money that goes into funding is really well spent. If we want to become a knowledge economy (the goal stated by the commission itself) then why do we keep spending 40% of the budget on agriculture? By the way, I don't know if it is true but I read the other day that this money actually goes to people who happen to own a lot of terriritory. (Even the British royalty seems to get its share?!)

Also, the money that _does_ go to strategic areas should be spent a little better IMHO. For instance, it is well-known that the current way of funding ICT is more or less a closed circuit. Once you're in the club of players, you get to play along. Why? In part because of the way that ICT funding is measured for performance: the EU seems to value follow-up projects because they re-use previous investments.

While this certainly means that these previous investments are not lost, it is not the most accurate way of measuring efficiency, I think. Instead, it would be better to measure the business revenue that is generated by previous investments. But maybe I am overlooking something, I don't know...

I am definitely not the first to complain about this, but by repeating there is just a bit more probability that someone reads it and can make a difference;-)

The JOpera Project at ETH Switzerland

2005-09-30T14:12:00.000+02:00

Another nice project done by/at my former CS research group (by one of my ex-colleagues, Cesare Pautasso): JOpera, a process engine for web services.

This technology could be used to build a BPEL engine or any other type of workflow engine for service-oriented architectures.

I wonder if they need transaction support -- if so I know where to get it :-) I also think BPEL and its compensation model have serious flaws, maybe this tool can offer something better.

The Axis 2 Project

2005-09-30T11:23:00.000+02:00

Earlier on, I have complained about the problems in JAX-RPC (and I am not the only one, it seems).

Today, I found out about the Axis 2 project, which seems to deal with many of the problems of the current JAX-RPC.

Definitely a step in the right direction!

My JAX-RPC Wishlist

2005-09-29T16:42:00.000+02:00

Have you ever implemented a web service with JAX-RPC? I did, and it was not that easy. Our technical requirements were the following:

we needed to be able to send/receive asynchronous (one-way) document/literal SOAP messages

we needed a convenient way to parse/generate the XML

we needed to be able to send custom SOAP faults for asynchronous error conditions

we needed to be able to process header blocks easily

we needed reasonable support for header bindings in the WSDL document

we needed to be able to associate server-side header information with thread-specific information in the service being called

If possible, we wanted to be able to associate handlers with custom, servlet-based endpoints (not JAX-RPC endpoints)

With the current state of the art in Java's JAX-RPC and JAXB, this was certainly possible but not at all straightforward. 1 and 2 are not so much of a problem, but the Java web services stack falls short on all the other items. So if any of the JAX-RPC committee members read this: I hope these comments or experiences can help in improving/clarifying the JAX-RPC technology...

Don't beam me up, Scotty: the teleportation experiment.

2005-09-27T15:23:00.003+02:00

Do you know the teleportation experiment? It is a thought experiment based on the science-fiction series Star Trek (of course you know that one) and it involves teleportation technology. To be more precise: it is a thought experiment simply because it is not possible yet. Nevertheless, some day it may become technically feasible. I frequently think about it. Read on if you want to know why.

For the purpose of our imaginary experiment, a person - say, me - is transferred from Brussels to London in the following way:

In Brussels, a complete scan is performed on me. This scan yields the information necessary to construct an exact replica of me.

This information is then sent to London, where an exact replica is actually constructed.

My body in Brussels is 'destroyed' (yes I know this sounds rude, and I think it actually is rude too).

If teleportation will one day work then this is how science nowadays thinks it could be done. Nevertheless, a very interesting philosphical issue keeps fascinating me: is the resulting person in London really going to be 'me'? To be able to answer that, it is necessary to understand what 'me' really means, so this brings us to the core of the question on personal identity and consciousness.

What do you think? Would you make the trip? To make it more interesting: if you think that the person in London is not me simply because he has a different (but replicated) brain, consider the fact that most of our brain cells are renewed every X years or so. This means that my brain is no longer the same as it was 20 years ago. And still, it has always been me:-)

WS-Transaction version 1.0 is out

2005-09-27T09:17:00.000+02:00

It took a long time to finish, but at last the WS-Transaction specification is now available in version 1.0!

This specification consists of two concrete standards, WS-AtomicTransaction and WS-BusinessActivity. Besides BTP (released at OASIS a few years ago), this is the first 'official' release of a WS standard for transactions across web services.

Unlike BTP, this one _is_ backed by industry giants, and very compact as well. At the very least, this gives us a likely candidate for industry-wide adoption.

There are still some things that I don't like -- to name one, the compensation model is built to suit BPEL4WS meaning that it has no business-level actions upon close of the activity (the Atomikos compensation model does a lot more to foster service autonomy and business-level status of activities).

But at least the atomic transaction part seems acceptable...

Atomikos: java transaction manager software

2004-10-27T10:44:00.000+02:00

Here is a nice tool that can take care of back-end system integration and java transaction management. The Transactions product is a JTA (java transaction API) implementation with full recovery under the hood. It integrates with most J2EE application servers as well as with J2SE applications, and adds transactional robustness, and automatic recovery on-the-fly. Perfect for your online transaction processing (OLTP)!

Some of the supported application servers are:
-Tomcat (JTA transactions)
-JBoss (JTA transactions with RMI/IIOP support)
-Websphere Express
-ServletExec (by New Atlanta)
Here is more information about transaction processing software.
Alternatively, go directly to the JTA download.

Clustering in Tomcat 5

2004-05-19T09:35:00.000+02:00

Clustering and Load Balancing in Tomcat 5, Part 1 by Srini Penchikala -- The latest version of Tomcat provides clustering and load balancing capabilities for scalable, highly available systems. In part one of this series, Srini Penchikala looks at architectural factors to consider in such a system and how Tomcat implements them.

Guy created his blogspot!

2004-05-19T09:18:00.000+02:00

Yes, today is the day where Guy's Blog was created!