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!

WS-RX/WS-RM QoS

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?

VMWare on EC2: nope

Out of curiosity, I had a quick try to see if VMWare can run on EC2. Before terminating the Win2003 (32 bit) server I had running on EC2, I installed VMWare client on it and launched image with it: got a nice error message telling that VMWare is not compatible with Xen hypervisor used by Amazon EC2.

Had a 2nd try with the open source VirtualBox (from Sun). When I launched a virtual machine in VirtualBox (install CentOS from ISO image), the whole EC2 image came to a halt. No problem, I was done with it anyway.

Lesson learned: running virtualization solution on EC2 doesn't seem to work

Note: it should be possbile to convert VMDK to AMI using QEMU

Loosely coupled: loosely defined, loosely understood

"Loosely coupled" is a heavily used term in SOA land. To me, loosely coupling means the use of a standardized contract/interface (aka canonical message format) and preferably also asynchronous messaging such as JMS.

Found an interesting presentation that describes the "facets" of loosely coupling. And it compares the different types of web services with relation to "decoupling".

Belgian weather and water keep Google cool

So Belgian cold weather also has its value: less energy required to cool the Google data center. Interesting to learn as well that the data center's location is nearby a canal to obtain cheap water.

For the location of Google's data center in Belgium itself (Mons): there must definitely be a relationship with the fact that Elio di Rupo is both president of the socialist party and mayor of the town of Mons.

Java Message Service - 2nd edition

JMS or Java Message Service is the basis and standard API for asynchronous, reliable messaging.

After 10 years, a new (2nd) edition of the book "Java Message Service" was recently published. Mark Richards reworked the original edition by David Chappell (ex-Sonic, now Oracle) and Richard Manson-Haefel.

Having just skimmed through the book, it did look very intersting. Obviously an extensive treatment of the API (and thus specification). But nice to see code samples based on ActiveMQ, some explanation of character encoding, use of non-JMS clients (.Net, C++), dynamic vs. administered queues, message driven beans (MDB) and Spring and Security.

Some topics that did not seem to be addressed:SOAP over JMS, REST-like access tot JMS providers, persistence mechanisms (database or file based),

Messaging solutions are still the core backbone for many ESB's and integration solutions. The JMS API remains the standard abstration layer for both Java (ActiveMQ, SonicMQ, OpenMQ, Fiorano) and non-Java based messaging (Tibco , WebSphereMQ, SoftwareAG WebMethods, Oracle AQ) solutions.

Simple SOAP definition

SOAP is the HTML for machine-to-machine communication.