I'm evaluating JBoss SOA Platform 5.2 (I'll call it JBoss ESB in short) for my organization now. And I'm very concerned about its "Message Delivery Guarantee" capability when I came across its related document. It looks to me that JBoss ESB can only guarantee the message delivery by using JMS transportation. (You can see details in section 8.2.1. Message Loss at http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Programmers_Guide/chap-SOA_ESB_Programmers_Guide-Fault-tolerance_and_Reliability.html#id578388).
Here is the "Message Delivery Guarantee" requirement I'm trying to evaluate upon JBoss ESB. We have an application A sending a message to ESB through HTTP transportation, and ESB will delivery the message to receiver B and C through web service call. Everything is working fine if all systems are up. But for example, if receiver C is turned down, how ESB can guarantee that all messages that A sends to ESB will be re-delivered to receiver C once it's turned up again? I know I can develop some customer actions to support this with coding, but I'm wondering if JBoss ESB can support this just by its out-of-box configuration?
Here is the testing environment I setup, I downloaded SOA Platform 5.2 (not standard alone), it's running on JDK 1.6 64 bits, and I hook it up with a backend MS SQL Server 2008 database, OS is Windows server 2008 R2 64bits.
Please help me to figure this out, since this feature is very important for us. And it will lead us to the decision whether to use JBoss ESB or not.
In the case you have described JBoss ESB acts as a client to the delivery of a request to message B & C.
You can use the SOAPClient (sopaui based or wise based) to call synchronously the WS at C. The call is synchronous and the OOB actions will wait for a reply from your service. The OOB actions throw exceptions if the application responding on calls to C is not available which would result in the lifecycle of ESB taking over and returning an error to your original client A. You can:
a) when the message has failed to be delivered to re-deliver it from your client back to the ESB (perhaps marking it that it should only go to C this time, again and again until it succeeds)
b) catch the exception and handle it by calling a service which polls your service C to see if it is available and then re-deliver the message to it when it is back on (in this case you are correct you would need to probably extend the SOAPClient or write one from scratch which does this) and of course have the error handling service use some kind of persistence so you do not lose the message. One way would be with a durable queue, another write to db/file and read the message when service C is again available.
I understand that when you compare to big ESB vendors you may not have everything handled by default out of the suite however we are not talking about some extremely difficult implementation here. Hope it helps