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".
3 comments:
Guy,
You don't need an ESB for this - this can easily be done via a SOAP interceptor (intermediary).
Best
Guy
how can delete be idempotent?
If you delete something that has already been deleted, then at the end, the thing is still deleted, the outcome is the same so it's idempotent.
Post a Comment