It has been tak­ing months since we start­ed it, but our new web­site will be on­line very soon now. We are cur­rent­ly do­ing the last bits of work to get it ready...

What makes our new site in­ter­est­ing is our ge­o­graph­i­cal­ly dis­persed team that has been work­ing on it:

• The con­tent and PDF good­ies were writ­ten in Cana­da
• The over­all site de­sign was done in Bel­gium
• The con­tent man­age­ment sup­port - a wiki plat­form - was (and still is) be­ing done in Ger­many

From the in­cep­tion to the fin­ish, this has been a great deal of fun (and work!) and it is a very ex­cit­ing way of do­ing things! This is yet an­oth­er ex­am­ple of how far you can get with a work track­er (like fog­bugz), a wiki and skype;-)

Ru­mors had been around for a while that this might hap­pen, and it did: the WS-Trans­ac­tion specs (pro­pri­etary work un­til re­cent­ly) are now un­der the cus­tody of the OASIS stan­dards body: http://www.oa­sis-open.org/com­mit­tees/tc_home.php?wg_ab­brev=ws-tx

Ven­dors sup­port­ing the WS-TX ini­tia­tive in­clude BEA Sys­tems, IBM, Mi­crosoft, Or­a­cle, SAP and TIBCO. This sounds like the kind of in­dus­try mo­men­tum need­ed to push ac­cep­tance in the mar­ket:-)

The new stan­dard­iza­tion com­mit­tee is open to any­body - I would par­tic­i­pate too if it weren't for the strict IPR poli­cies used by OASIS...

Another nice project done by/at my for­mer CS re­search group (by one of my ex-col­leagues, Ce­sare Pau­tas­so): JOpera, a process en­gine for web ser­vices.

This tech­nol­o­gy could be used to build a BPEL en­gine or any oth­er type of work­flow en­gine for ser­vice-ori­ent­ed ar­chi­tec­tures.

I won­der if they need trans­ac­tion sup­port -- if so I know where to get it I also think BPEL and its com­pen­sa­tion mod­el have se­ri­ous flaws, maybe this tool can of­fer some­thing bet­ter.

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...