To all can­di­date com­mu­ni­ty mem­bers who did not man­age to cre­ate a fo­rum ac­count:

now it should work again!

Se­cu­ri­ty set­tings and anti-spam mea­sures some­how broke the reg­is­tra­tion process - apolo­gies for that

We've re­strict­ed ac­cess to https://www.atom­ikos.com/maven-repos­i­to­ry (our maven repos­i­to­ry) to cus­tomers only, so they can have easy and time­ly ac­cess to bug fix­es, main­te­nance re­leas­es and full fea­ture re­leas­es.

If you're not a cus­tomer then you have two op­tions:

• Either sub­scribe to­day to be­come one, or
• Grab our com­mu­ni­ty re­leas­es via maven cen­tral

In the near fu­ture we plan to dis­trib­ute Trans­ac­tion­sEssen­tials ex­clu­sive­ly via the cen­tral maven repo.

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.

Ear­ly adopters want­ed! We are work­ing on some­thing rad­i­cal­ly dif­fer­ent and new in the in­dus­try, be­ing a light-weight trans­ac­tion (and BPM) mod­el for REST with the fol­low­ing char­ac­ter­is­tics:

• Guar­an­teed in­ter­op­er­abil­i­ty
• Easy and in­tu­itive to use
• No tech­nol­o­gy de­pen­den­cies, so no con­fig­u­ra­tion re­quired
• Com­pat­i­ble with the REST ar­chi­tec­tur­al con­straints

To get an idea of what it is like, con­sid­er the fol­low­ing ex­am­ple: a tel­co op­er­a­tor wants to al­low cus­tomers to ac­quire 'per­son­al­ized' phone num­bers for a fee. The process is the fol­low­ing, as­sum­ing an in­com­ing re­quest for a giv­en cus­tomer and a cho­sen phone num­ber:

1. The sys­tem checks if the num­ber is avail­able, and if so then re­serves that num­ber for some time (on be­half of the cus­tomer).
2. The cus­tomer's cred­it is checked in the billing sys­tem.
3. If OK, then the phone num­ber reser­va­tion is con­firmed and the billing is done.
4. Other­wise, the phone num­ber is re­leased again and no billing is done.

Imag­ine the BPM mod­el­ing you would need to do to han­dle all fail­ure sce­nar­ios and con­fir­ma­tion sce­nar­ios from that last 2 steps. We know from ex­pe­ri­ence that this does not scale...

In­stead, what we of­fer is a com­plete and re­li­able au­toma­tion of the con­fir­ma­tion and can­cel­la­tion steps - let­ting you fo­cus on the hap­py path of the work­flow. We do this via a ser­vice called TaaS ( TCC as a Ser­vice) and plan to of­fer a REST im­ple­men­ta­tion of that. We've pre­sent­ed this idea at the re­cent SOA sym­po­sium (the pre­sen­ta­tion can be found here) and we are look­ing for ear­ly adopters to spon­sor our ver­sion one prod­uct...

So if your SOA should be light­weight and in­volves the con­cept of reser­va­tions of busi­ness re­sources then please email us to­day to ap­ply for our ear­ly adopter pro­gram. Don't wait, be­cause be­ing a small com­pa­ny we can only do a few of these and first come means first served...

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.