Scal­ing ap­pli­ca­tions to the web and the cloud - com­bined with con­tin­u­ous de­ploy­ment au­toma­tion prac­tices - is not easy. The cur­rent rigid and over­sized in­fra­struc­ture plat­forms don't help here.

So it's time for some­thing dif­fer­ent: dis­cov­er our in­creas­ing­ly pop­u­lar "no-appserv­er-par­a­digm", en­abling you to use all of the en­ter­prise fea­tures with­out the heavy plat­form bur­den...

Down­load the full ar­ti­cle here!

Some peo­ple will claim that REST does not need BPM be­cause it pro­vides all the se­man­tics you need.

How­ev­er, if you look be­neath the hood then it turns out that this is not ex­act­ly true: in par­tic­u­lar, if mul­ti­ple (in­de­pen­dent) REST ser­vices need to come to the same out­come then you want some­thing more...

Won­der­ing what that is? Good! It's all ex­plained in one of our lat­est pub­li­ca­tions - to learn the de­tails: just fill out this form.

En­joy!

So you're into REST and you are won­der­ing how to de­fine some kind of trans­ac­tion guar­an­tee with it...

Look no fur­ther, be­cause we have ex­act­ly what you need:

• A de­sign pat­tern
• A sim­ple, ven­dor-in­de­pen­dent REST API
• Backed by a reusable co­or­di­na­tor ser­vice if you need one (that is up to you, re­al­ly)

FREE down­load: "TCC for REST API" (API spec­i­fi­ca­tion)

PS: the tech­nol­o­gy de­scribed in this spec­i­fi­ca­tion is avail­able and can be down­loaded as part of Trans­ac­tion­sEssen­tials

126795: Nul­lPoin­t­erEx­cep­tion dur­ing bor­rowCon­nec­tion in JMS with con­cur­rent close of ex­ist­ing ses­sion

Fixed a NPE con­di­tion where con­cur­rent bor­row re­quests and close op­er­a­tions on ex­ist­ing ses­sions would in­ter­fere.

This post was based on old con­tent and is no longer rel­e­vant.

Visit our Distrib­uted Trans­ac­tions Tu­to­r­i­al for equiv­a­lent con­tent.