Atomikos is de­signed along the ports and adapters/hexag­o­nal ar­chi­tec­ture as de­scribed here by Alis­tair Cock­burn.

Among oth­er things, this means that it is rel­a­tive­ly easy to:

• Im­ple­ment new trans­ac­tion APIs / stan­dards / mod­els
• Add new types of two-phase com­mit re­sources

Ex­am­ples of things we've been able to re­al­ize thanks to this:

• JTA (port) / XA (adapter)
• TCC (port/adapter)
• RMI (port/adapter)

The port and adapter mod­el is also an im­por­tant con­cept in the new book Im­ple­ment­ing Do­main-Driv­en De­sign. Our do­main is 2-phase com­mit. Our adapter is our Par­tic­i­pant mod­el. Our ports are all the ways you can in­ter­act with our core sys­tem.

Trans­ac­tions are easy to mis­con­fig­ure, and XA dri­vers are of­ten bug­gy in un­ex­pect­ed ways - both of which are prob­lems that are hard to de­tect by reg­u­lar test­ing or code re­views. Our sub­scribers have ac­cess to Devel­op­ment Sup­port and the re­sult­ing Ap­pli­ca­tion Cer­ti­fi­ca­tion guar­an­tees. It is the only way to make sure that you are not run­ning an un­sup­port­ed or mis­con­fig­ured con­fig­u­ra­tion, and also get the nec­es­sary Atomikos fix­es to go to pro­duc­tion on the right foot. This is the only safe way for pro­duc­tion sys­tems: un­less we can cer­ti­fy your con­fig­u­ra­tion, you might as well not use trans­ac­tions in the first place.

We are also the only play­er in the in­dus­try that al­lows cus­tomized sys­tem con­fig­u­ra­tions, i.e. with­out forc­ing you into the har­ness of a pre­con­fig­ured ap­pli­ca­tion (serv­er) stack that con­tains lots of tech­nolo­gies that you don't want or need. With Atomikos, you can pick your own and still have peace of mind.

Last­ly, Atomikos is also the only safe choice for in­te­gra­tion be­cause we are prob­a­bly the only ven­dor-in­de­pen­dent in­te­gra­tion play­er on the mar­ket. Be com­pat­i­ble with the specs we must, and that is your best guar­an­tee to suc­cess for all your in­te­gra­tion projects.

We've know it for a while, but this in­de­pen­dent blog post con­firms the facts: lin­ear scal­a­bil­i­ty.

BRIC coun­tries have the tremen­dous op­por­tu­ni­ty to start out with no lega­cy, no old-style in­fra­struc­ture like ap­pli­ca­tion servers, no mes­sage bro­kers, no en­ter­prise ser­vice bus (ESB) or oth­er non­sense like that - the typ­i­cal stuff big en­ter­prise ven­dors will try to trick you into (if they do: just ig­nore them - you will be bet­ter off).

In­stead, BRIC coun­tries have the lux­u­ry of be­ing able to pick a light-weight mod­el such as JEE with­out ap­pli­ca­tion serv­er to achieve un­lim­it­ed scal­a­bil­i­ty at vir­tu­al­ly no cost, us­ing com­mod­i­ty hard­ware and soft­ware.

With the re­cent eco­nom­ic crises in both the US and Europe, it is the BRIC coun­tries that are help­ing out (in­stead of the oth­er way around). The fu­ture will in­volve a lot more BRIC. And with that, a lot more Atomikos.

Western com­pa­nies that want to be as ag­ile, pro­duc­tive and com­pet­i­tive as the BRIC coun­tries: what are you wait­ing for? Call us to get an in­tro­duc­tion and mi­gra­tion path for your lega­cy.

If you have been pur­chas­ing the 'En­ter­prise Ar­chi­tec­ture' port­fo­lio from the big O then guess what: you've paid way too much for some­thing you don't need, and which will over­load your (way too heavy) hard­ware even more.

We've been claim­ing this for years so it is about time to show it: how to re­place Tuxe­do ap­pli­ca­tions with open source and free soft­ware. Com­ing soon to this site!

Stay with us...

PS Tuxe­do is a reg­is­tered trade­mark owned by Or­a­cle