How to build trans­ac­tion­al mi­croser­vice ecosys­tems with Atomikos: if you want to split-up your mono­lith then this is how you take care of the in­tegri­ty of your data­bas­es...

The prob­lem

So you're split­ting up that mono­lith into small­er scoped mi­croser­vices. Then you sud­den­ly re­alise that what used to be one trans­ac­tion is now split across mul­ti­ple process­es. It's not easy to make mul­ti­ple up­dates across mul­ti­ple process­es and guar­an­tee con­sis­tent com­mit or roll­back in case of fail­ures. So what can you do?

The so­lu­tion

Based on pop­u­lar de­mand, we at Atomikos have come up with a so­lu­tion to man­age dis­trib­uted trans­ac­tions across sep­a­rate REST mi­croser­vices. You can now have atom­ic, con­sis­tent com­mit or roll­back span­ning mul­ti­ple mi­croser­vice process­es.

Er­ror: im­age not found

The client ap­pli­ca­tion it­self uses an in­stance of Trans­ac­tion­sEssen­tials and can use / ex­port its trans­ac­tions to the ex­ter­nal REST ser­vices. This means that start­ing and com­mit­ting a trans­ac­tion now hap­pen in­side the client's ap­pli­ca­tion, and com­mit in­cludes any ex­ter­nal REST ser­vices' work.

JAX-RS in­ter­cep­tors

Ex­tend­ing the trans­ac­tion scope across mi­croser­vice calls is done via JAX-RS "fil­ters" that in­ter­cept in­com­ing and out­go­ing re­quests and re­spons­es, adding / ex­tract­ing the nec­es­sary in­for­ma­tion to / from the HTTP head­ers of the re­quest. Here's how to con­fig­ure this in your code:

Client-side in­ter­cep­tors

   import com.atomikos.remoting.jaxrs.TransactionAwareRestClientFilter;

   javax.ws.rs.client.Client paymentClient = ClientBuilder.newClient();
   paymentClient.register(TransactionAwareRestClientFilter.class);

The client in­ter­cep­tor au­to­mat­i­cal­ly de­tects any ac­tive Atomikos trans­ac­tion in the client JVM and prop­a­gates it in the out­go­ing calls via HTTP head­ers - so the serv­er on the oth­er end can ex­tract and join that trans­ac­tion. It also ex­tracts any URLs from the re­sponse head­ers for com­mit­ting the work of the oth­er end as part of the ac­tive trans­ac­tion.

Serv­er-side in­ter­cep­tors

   import com.atomikos.remoting.jaxrs.TransactionAwareRestContainerFilter;
   import com.atomikos.remoting.twopc.AtomikosRestPort;

   JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean(); //we used CXF for our demo
   sf.setProvider(new TransactionAwareRestContainerFilter());
   sf.setResourceProvider(new SingletonResourceProvider(new AtomikosRestPort()));

The serv­er in­ter­cep­tor de­tects any trans­ac­tion prop­a­ga­tion in the in­com­ing calls - so it can join that trans­ac­tion. It also adds HTTP head­ers to the re­sponse, con­tain­ing a URL to com­mit its work as part of the trans­ac­tion of the caller. The AtomikosRestPort lis­tens on the URL and awaits com­mit re­quests.

Spring REST in­ter­cep­tors

We have sim­i­lar in­ter­cep­tors for Spring REST, if you pre­fer that frame­work over JAX-RS.

Spring Http In­vok­er in­ter­cep­tors

The Spring HTTP re­mot­ing tech­nol­o­gy is also sup­port­ed.

Ben­e­fits

Some of the ben­e­fits of this tech­nol­o­gy in­clude:

• Con­sis­tent com­mit or roll­back is now pos­si­ble across dif­fer­ent mi­croser­vices.
• If you call a ser­vice and get no re­sponse (or an ex­cep­tion) then you know it has not com­mit­ted any­thing.
• If you refac­tor your ar­chi­tec­ture to­wards mi­croser­vices then you don't have to wor­ry so much about con­sis­ten­cy.

Try for your­self

This post de­scribes real, work­ing ex­am­ples of our code base. Down­load the free open source edi­tion here:

Free Down­load

Are you se­ri­ous about REST trans­ac­tions? Ap­ply here for a free tri­al of our com­mer­cial edi­tion!

Trust­ed By