A basic mechanism to make a service idempotent is duplicate detection. For one-way services, duplicate detection may be sufficient, Request/response services require also that exactly the same response message is returned.
Duplicate detection isn’t that hard:
- Unique value in the request. Multiple options exist:
- business identifier such as purchase order number
- hash of the input message or
- technical identifier such as WS-Addressing MessageID
- Database table with unique constraint to manage the identifiers.
- Cleanup job to remove old entries from the above database table.
The ideal location to do duplicate detection is in the back-end services themselves. The service is invoked in a transactional context and has already access to a database. But it can also make sense to do duplicate detection in an intermediate such as an ESB. E.g. when an ESB switches between an unreliable protocol such as HTTP and a reliable persistent queuing protocol.
Integration solutions often need to maintain information about messages anyway. For
message monitoring, message archiving or non-repeduation (keep copy of signed messages). Duplicate detection can also be combined with protection against replay attacks (even required by the core WS-Security spec).
Mule comes with an Idempotent Receiver that provides duplicate detection.
Still, why other ESB’s don’t come with duplicate detection mechanisms is a mystery to me!
