Message Delivery Guarantee in JBoss SOA Platform 5.2???

Latest response

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.

 

Responses

Hello,

 

This is a good question.  SOA-P (JBoss ESB) is going to be able to guarantee messages only as far as the underlying transports allow.  The same will be true of any ESB or framework.

 

HTTP does not allow guaranteed delivery.  When an HTTP message is being processed (whether it's a page request, web service, or other) the container is not obligated to make sure the message persists in the event something bad happens. 

 

There are different ways to deal with this.  One way is to have the client re-try and have the server guarantee 'idempotency'.  This means that the client should always retry if it doesn't get a good response, and the server should know enough to ignore requests it has handled before.  In practice, this can be difficult to implement.

 

Another way is through use of 'guaranteed' transports.  JMS is one of these, a database would be another.  If a message appears on one of these transports and the server has a failure in processing it, then the message is not 'consumed' from JMS or the database, so the server (or another one) can try again to process the message until it is properly handled.  Again-- this is true of any server or framework.

 

There are hybrid approaches, where the ESB might receive an HTTP request, then immediately put the message on a JMS queue and send back an acknowledgement to the client.  The message can then be processed knowing that it is secure-- but the client will have to be contacted asynchronously to let them know the message was processed.

 

Please consider these, and good luck!

 

Rick