Ear­li­er on, I have com­plained about the prob­lems in JAX-RPC (and I am not the only one, it seems).

To­day, I found out about the Axis 2 project, which seems to deal with many of the prob­lems of the cur­rent JAX-RPC.

Def­i­nite­ly a step in the right di­rec­tion!

Have you ever im­ple­ment­ed a web ser­vice with JAX-RPC? I did, and it was not that easy. Our tech­ni­cal re­quire­ments were the fol­low­ing:

1. we need­ed to be able to send/re­ceive asyn­chro­nous (one-way) doc­u­ment/lit­er­al SOAP mes­sages
2. we need­ed a con­ve­nient way to parse/gen­er­ate the XML
3. we need­ed to be able to send cus­tom SOAP faults for asyn­chro­nous er­ror con­di­tions
4. we need­ed to be able to process head­er blocks eas­i­ly
5. we need­ed rea­son­able sup­port for head­er bind­ings in the WSDL doc­u­ment
6. we need­ed to be able to as­so­ciate serv­er-side head­er in­for­ma­tion with thread-spe­cif­ic in­for­ma­tion in the ser­vice be­ing called
7. If pos­si­ble, we want­ed to be able to as­so­ciate han­dlers with cus­tom, servlet-based end­points (not JAX-RPC end­points)

With the cur­rent state of the art in Java's JAX-RPC and JAXB, this was cer­tain­ly pos­si­ble but not at all straight­for­ward. 1 and 2 are not so much of a prob­lem, but the Java web ser­vices stack falls short on all the oth­er items. So if any of the JAX-RPC com­mit­tee mem­bers read this: I hope these com­ments or ex­pe­ri­ences can help in im­prov­ing/clar­i­fy­ing the JAX-RPC tech­nol­o­gy...

It took a long time to fin­ish, but at last the WS-Trans­ac­tion spec­i­fi­ca­tion is now avail­able in ver­sion 1.0!

This spec­i­fi­ca­tion con­sists of two con­crete stan­dards, WS-AtomicTrans­ac­tion and WS-Busi­nessAc­tiv­i­ty. Be­sides BTP (re­leased at OASIS a few years ago), this is the first 'of­fi­cial' re­lease of a WS stan­dard for trans­ac­tions across web ser­vices.

Un­like BTP, this one is backed by in­dus­try gi­ants, and very com­pact as well. At the very least, this gives us a like­ly can­di­date for in­dus­try-wide adop­tion.

There are still some things that I don't like -- to name one, the com­pen­sa­tion mod­el is built to suit BPEL4WS mean­ing that it has no busi­ness-lev­el ac­tions upon close of the ac­tiv­i­ty (the Atomikos com­pen­sa­tion mod­el does a lot more to fos­ter ser­vice au­ton­o­my and busi­ness-lev­el sta­tus of ac­tiv­i­ties).

But at least the atom­ic trans­ac­tion part seems ac­cept­able...

Here is a nice tool that can take care of back-end sys­tem in­te­gra­tion and java trans­ac­tion man­age­ment. The Trans­ac­tions prod­uct is a JTA (java trans­ac­tion API) im­ple­men­ta­tion with full re­cov­ery un­der the hood. It in­te­grates with most J2EE ap­pli­ca­tion servers as well as with J2SE ap­pli­ca­tions, and adds trans­ac­tion­al ro­bust­ness, and au­to­mat­ic re­cov­ery on-the-fly. Per­fect for your on­line trans­ac­tion pro­cess­ing (OLTP)!

Some of the sup­port­ed ap­pli­ca­tion servers are:
-Tom­cat (JTA trans­ac­tions)
-JBoss (JTA trans­ac­tions with RMI/IIOP sup­port)
-Web­sphere Ex­press
-ServletEx­ec (by New At­lanta)
Here is more in­for­ma­tion about trans­ac­tion pro­cess­ing soft­ware.
Al­ter­na­tive­ly, go di­rect­ly to the JTA down­load.

Clus­ter­ing and Load Balanc­ing in Tom­cat 5, Part 1 by Sri­ni Penchikala -- The lat­est ver­sion of Tom­cat pro­vides clus­ter­ing and load bal­anc­ing ca­pa­bil­i­ties for scal­able, high­ly avail­able sys­tems. In part one of this se­ries, Sri­ni Penchikala looks at ar­chi­tec­tur­al fac­tors to con­sid­er in such a sys­tem and how Tom­cat im­ple­ments them.