Hi Roberto > I agree with your consideration, in general a SOAP fault could be a valid > response for the client. The problem is that a SOAP fault *can *be also an > invalid response from the service, and in current situation there is no way > to manage this information in order to mark an endpoint suspended. > > Using current configuration language, the only solution I have in mind is > this: > > 1) Alter the IN sequence to store somewhere the request message > 2) Alter the OUT sequence to analyze the body of the fault, to verify if the > endpoint is unavailable > 3) Reload the request from 1) > 4) Send the request to the next endpoint (chosen by an hard-coded logic, > storing somewhere the endpoints already used) > 5) Repeat from 2 until success or no other endpoint is available. > > This solution is very very dirty, it makes useless all > failover/loadbalancing/endpoint-groups framework because I have to hardcode > all the logic and all the endpoints. > > I think a way to put a condition (for example a xpath-expression on the > response body) in addition to standard error codes, could be a clean > solution. Otherwise, do you have a suggestion to obtain this goal with a > smarter solution? > Can you give me some time to look at the options.. I will try to give you a solution around early next week..
cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com
