Mashed Articles

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?

In this post, I’ll cover the 2nd question that I raised in my previous post: “where to do transformations (and routing, monitoring, …) of the web service interactions?” When a consumer and service use different service defintions, how to transform between both in a Microsoft world? Or re-phrased: where is the Microsoft EBS to mediate synchronous, request/response web services?

When searching on “Microsoft ESB”, one quickly ends up at Enterprise Service Bus Guidance. This is not a real product but documentation and components developed by Microsoft’s Architecture team. As BizTalk is a hub-and-spoke integration solution that persists every incoming message and it’s MessageStore, BizTalk isn’t really suitable to be an intermediary for synchronous, request/response service invocations. As such, BizTalk lacks crucial features to be called an ESB, although it remains a nice integration solution.

With no Microsoft ESB available, what are the options?

• Java based ESB: commercial (WebSphereESB, AquaLogic/OracleESB, Tibco BusinessWorks/ActiveMatrix, SoftwareAG, JCAPS/OpenESB) or open source (Synapse, WSO2 ESB)
• Runtime governance tools such as Amberpoint that are also capable of doing transformations. Microsoft has SOA Governance integration with Amberpoint and SOA Software.
• XML appliances

But none of these options are really appealing to the average Microsoft shop. If there is full access to the .net source code as one side (consumer or provider), some custom transformation logic can be added. But therre don’t seem to be any clear hooks for transformation in WCF.

Note: Microsoft’s new cloud computing – Azure – specifies an Enterprise Service Bus in its .Net Services. The preliminary documentation of the Microsoft .Net Service Bus talks about naming, different types of RelayBindings and security. But transformation and routing of messages isn’t covered (yet).

Definition of idempotent: Refers to an operation that produces the same results no matter how many times it is performed.” See also the “Idempotent receiver” pattern.

An idempotent service makes life much easier in the unreliable web services world. A service can be invoked multiple times without any side effects. This is highly useful when a service invocation times out (was the service executed yes/no). But also to re-try execution of (part of) a business process.

Making a service idempotent consists of 2 parts: duplicate detection and caching of response messages. Duplicate detection I discussed in an earlier posting. Returning of earlier response message is somewhat harder: each response message must be stored for a reasonable amount of time.

Idempotency is not mentioned in the WS-* specs nor in the WS-I basic profile. Making web services idempotent is left as an exercise to the designer/developer.

With REST, a number of verbs such as GET and DELETE are idempotent. POST (create) is obviously not idempotent. PUT (update) should be idempotent. I can believe PUT to be idempotent in a document world. But PUT is an update and therefore a change in my opinion.

As already explained in my earlier post, the ideal location to do duplicate detection and make services idempotent in the back-end services themselves. Interesting to learn about support for idempotency in recent SAP products (Netweaver 2004S SPS09 / ECC SE 600 SP03). SAP stores the response messages in a “response store”.

Besides duplicate detection, let’s ask ESB vendors to implement support for idempotent services through a “response store”.