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

You could try and use a JMS topic between the services and use JMS redelivery semantics to ensure that messages are redelivered. The only issue with this is that it could get complex if you require responses from B&C to be sent back to A.