The JOpera Project at ETH Switzerland

Another nice project done by/at my former CS research group (by one of my ex-colleagues, Cesare Pautasso): JOpera, a process engine for web services.

This technology could be used to build a BPEL engine or any other type of workflow engine for service-oriented architectures.

I wonder if they need transaction support -- if so I know where to get it :-) I also think BPEL and its compensation model have serious flaws, maybe this tool can offer something better.

The Axis 2 Project

Earlier on, I have complained about the problems in JAX-RPC (and I am not the only one, it seems).

Today, I found out about the Axis 2 project, which seems to deal with many of the problems of the current JAX-RPC.

Definitely a step in the right direction!

My JAX-RPC Wishlist

Have you ever implemented a web service with JAX-RPC? I did, and it was not that easy. Our technical requirements were the following:

1. we needed to be able to send/receive asynchronous (one-way) document/literal SOAP messages


2. we needed a convenient way to parse/generate the XML


3. we needed to be able to send custom SOAP faults for asynchronous error conditions


4. we needed to be able to process header blocks easily


5. we needed reasonable support for header bindings in the WSDL document


6. we needed to be able to associate server-side header information with thread-specific information in the service being called


7. If possible, we wanted to be able to associate handlers with custom, servlet-based endpoints (not JAX-RPC endpoints)

With the current state of the art in Java's JAX-RPC and JAXB, this was certainly possible but not at all straightforward. 1 and 2 are not so much of a problem, but the Java web services stack falls short on all the other items. So if any of the JAX-RPC committee members read this: I hope these comments or experiences can help in improving/clarifying the JAX-RPC technology...

Don't beam me up, Scotty: the teleportation experiment.

Do you know the teleportation experiment? It is a thought experiment based on the science-fiction series Star Trek (of course you know that one) and it involves teleportation technology. To be more precise: it is a thought experiment simply because it is not possible yet. Nevertheless, some day it may become technically feasible. I frequently think about it. Read on if you want to know why.

For the purpose of our imaginary experiment, a person - say, me - is transferred from Brussels to London in the following way:

• In Brussels, a complete scan is performed on me. This scan yields the information necessary to construct an exact replica of me.


• This information is then sent to London, where an exact replica is actually constructed.


• My body in Brussels is 'destroyed' (yes I know this sounds rude, and I think it actually is rude too).

If teleportation will one day work then this is how science nowadays thinks it could be done. Nevertheless, a very interesting philosphical issue keeps fascinating me: is the resulting person in London really going to be 'me'? To be able to answer that, it is necessary to understand what 'me' really means, so this brings us to the core of the question on personal identity and consciousness.

What do you think? Would you make the trip? To make it more interesting: if you think that the person in London is not me simply because he has a different (but replicated) brain, consider the fact that most of our brain cells are renewed every X years or so. This means that my brain is no longer the same as it was 20 years ago. And still, it has always been me:-)

WS-Transaction version 1.0 is out

It took a long time to finish, but at last the WS-Transaction specification is now available in version 1.0!

This specification consists of two concrete standards, WS-AtomicTransaction and WS-BusinessActivity. Besides BTP (released at OASIS a few years ago), this is the first 'official' release of a WS standard for transactions across web services.

Unlike BTP, this one _is_ backed by industry giants, and very compact as well. At the very least, this gives us a likely candidate for industry-wide adoption.

There are still some things that I don't like -- to name one, the compensation model is built to suit BPEL4WS meaning that it has no business-level actions upon close of the activity (the Atomikos compensation model does a lot more to foster service autonomy and business-level status of activities).

But at least the atomic transaction part seems acceptable...