…and not something you buy!

If you only remember one thing from the BEJUG workshop on SOA then it should be this. And if you didn't go to this workshop: make sure you can go next time, because it was worth it:-)

But seriously, all too often do people buy a product and then start to look at how to use it, say, to build a SOA (Service Oriented Architecture). This is like buying a car: would you get a rolls royce first, and then pick the road to drive it on? Or would you rather look at the road first, and then choose the best car for it? I would do the latter…

Best

Did you hear about Spring? In my opinion, it is going to play a big role in J2EE and simplifying Java programming. At least when it comes to transactional applications, things are much simpler than with EJB.

Have a look for yourself: TSS was kind enough to publish my presentation on Spring.

Rumors had been around for a while that this might happen, and it did: the WS-Transaction specs (proprietary work until recently) are now under the custody of the OASIS standards body: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx

Vendors supporting the WS-TX initiative include BEA Systems, IBM, Microsoft, Oracle, SAP and TIBCO. This sounds like the kind of industry momentum needed to push acceptance in the market:-)

The new standardization committee is open to anybody - I would participate too if it weren't for the strict IPR policies used by OASIS…

With the finalization and publication of Web Services Addressing 1.0 - Core (WS-A) the world of web services has changed drastically (or will do so in the near future).

The idea behind addressing is to allow non-HTTP transports as well as HTTP transports, and even a chain of transports before a message finally gets to its destination. This would mean that a SOAP request can be routed via different platforms (JMS, HTTP, SMTP to name a few) and still make it to its destination. This goes hand in hand with asynchronous SOAP… Another major idea in WS-A is to allow acknowledgements, replies and faults to be returned to other addresses different from the original sender of a SOAP request.

A major consequence is that once again, the JAX-RPC processing model has to be stretched to accomodate this new standard. To see why, let's consider what happens in a typical JAX-RPC service endpoint:

1. An incoming request message is received via HTTP.
2. One or more handlers (intermediaries) are allowed to pre-process the message (mainly its headers).
3. The service implementation gets the message to do the real (business) part of the job and generates a reponse (if applicable).
4. One or more handlers get to post-process the response.
5. The HTTP conversation is terminated by sending an acknowledgement (with or without a response message).

This is almost inherently a synchronous request/reply paradigm, and things like returning a reply to a different address become very cumbersome: this has to be done in a handler that shortcuts the reponse chain and sends the SOAP message somewhere else instead…

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.