I suppose a lot comes down to the type of application. I've seen WS-RM
used mostly with government or industry groups, where there's going to
be a variety of different client and service implementations and they
want to assure reliability across the whole range.
If you're just building a service for internal use by your organization
WS-RM may be overkill, especially if a simple ARQ-style approach (send
and wait, retry if acknowledgement not received before timeout) will
work for your application. And certainly you can make this type of
approach work - just use unique application-level identifiers for your
messages, acknowledge each one, and hold on to each message (probably in
persistent storage) until acknowledged. Then implement a processing
queue on the receive side, assuming you also want in-order processing.
And write this code once for each different type of client or service.
Just out of curiosity, do you also swear off TCP and use UDP for all
your internet stuff? :-)
- Dennis
On 04/01/2014 01:28 AM, Frizz wrote:
Thanks for your reply Dennis.
The more I tinker with WS-RM the more I come to the conclusion that this
reliable messaging should NOT be handled on the transport level - but on
the business level.
I don't want to start a religious war here ... and it's more of a gut
feeling anyway - but: do you guys really use WS-RM? In production
environments?
