Tuesday, September 29, 2009

Shock absorber

Listened to an interesting interview on se-radio with Michael Nygard. Great interview where Michael explains his focus on IT systems in production. The title of his book says it all: "Release It! Design and Deploy Production-Ready Software".

One of the nice quotes during the interview was "messaging middleware" as the "shock absorber" between IT systems. Indeed, the stength of queueing is the option to pile up messages while a system is heavily loaded or temporarily unavailalbe. The use of asynchronous communication also leads to applications that are fully aware about time-outs that may occur.

Triggered by the interview, I started reading the book. Well written, with at the beginning of each part a real-life "story". Recommended book!

Saturday, September 12, 2009


IBM recently published an article on the use of WS-ReliableMessaging between WebSphere 6.1 and Axis2. Most interesting I found the part on the Quality of Service of WS-RM:
  • Unmanaged non-persistent tolerates network and remote system failures. You can configure Web service applications to use WS-RM with a default in-memory message store. This QoS requires minimal configuration; it is for a single server only and does not support clusters. Although this QoS allows for the re-sending of messages that are lost in the network, failure of a server results in lost messages. The default is unmanaged non-persistent.
  • Managed non-persistent tolerates system, network, and remote system failures, but state is discarded after the messaging engine restarts. This in-memory QoS option supports clusters as well as single servers. This option uses a messaging engine to manage the sequence state, and messages are written to disk if memory is low. This QoS allows for the resending of messages that are lost in the network, and can also recover from server failure. However, a failure of the messaging engine causes message loss.
  • Managed persistent tolerates system, network, and remote system failures. This QoS for asynchronous Web service invocations is recoverable. This option also uses a messaging engine and message store to manage the sequence state. Messages are persisted at the Web service requester server and at the Web service provider server, and are recoverable if the server fails. Messages that have not been successfully transmitted when a server fails can continue to be transmitted after the server restarts.
QoS of WS-RM is actually not part of any standard. Most implementations of WS-RM are non-persistent, in particular Microsoft WCF and Sun's Metro. And that is in my opinion the major shortcoming of the WS-* story. The WS-RX committee should have made message persistence part of the WS-RM spec and/or the WS-RM Policy spec.

Anyway, IBM has a persistent implementation of WS-RM. And so has SAP: SAP doesn't even give you the option and uses persistent WS-RM as its default. Well done by SAP, although the SAP implementation is based on an older version of the WS-RM spec (WS-RM 2005/02.)

What I don't find are reports of the use of persistent WS-RM between stacks of different vendors, e.g. between IBM and SAP. Maybe we'll need to have a go ourselves one day?