There are lots of ways to exchange data among programs - e.g. remote method calls, batch jobs, file transfer via FTP, web services, or via reliable messaging. Each method has its place but reliable messaging has distinct advantages:
- Decouples sender and receiver from knowledge of each others' implementation (this isn't a unique advantage to messaging but is key)
- Facilitates asynchronous processing - sender and receiver don't need to be simultaneously online and the receiver can even be unavailable at the time of an activity. you can store and forward messages, process them in parallel, and tie exceptions to backend workflows etc. - provides a lot of flexibility
- Value added features such as guaranteed delivery - reliable is the critical word here since messaging middleware takes care of ensuring messages are delivered to a destination broker - when you cannot afford to lose a message you cannot rely on HTTP. Another useful one is once and only once delivery which ensures that messages aren't delivered multiple times to a receiver.
"when you cannot afford to lose a message you cannot rely on HTTP. "
WS-RM isn't that deployed on HTTP?
Yes WS-RM adds reliability on top of plain HTTP. Reliable messaging prior to the WS-* standards could be done via JMS.
I don't think that the "Decouples sender and receiver from knowledge of each others' implementation" has any relation to reliable messaging but would like to know if there is any relation.
WS-* is just the standards of how the reliable messaging should be addressed but the critical bit is the implementation of it. For Reliable messaging i do believe that the messaging middleware which supports Queuing based machanism has a major role to play to implement WS-RM Standards.
I also think it is vital to talk about the where reliable messaging should be used and where it shouldn't be used.
There is relevance to reliable messaging in the statement "decouples sender and receiver from knowledge of each others' implementation." The advantage here is that the sender and receiver are unaware of each other's technology platforms (e.g. one could be .NET and other J2EE or even mainframe). This loosely couples the sender and the receiver.
Reliable messaging is predominantly implemented using message brokers (e.g. IBM Websphere MQ,Tibco EMS etc.) and in the Java world is supported by the JMS specification.
Online shopping is realtime best example for, where the reliable messaging should be used. Because each and every request that goes through is important. Some times after entering the credit card details if the user does not get the confirmation screen immediatly due to some problem in the network he is not sure whether the transaction is successful or not. In my view in almost all the financial activites done online reliable messaging should be there.