Angel Todorov wrote:
...
What Dennis suggests is useful, but in reaility there may be
situations where the service is randomly invoked by clients with
crappy soap header / body (think about bots & worms or developers of
web service clients in an open WS environment), to which a fault is
produced, and this doesn't mean that the service is "inoperative", if
a "proper" client knows exactly what he wants from the service. The
whole problem with the SOAP faults actually lies in this that, you can
never know how a service implementor will manage and create SOAP
faults - will this only be done in case of a real business logic
error, or will this happen if the client sends crap, or even for
Exceptions which can be managed internally by the logic.
These are certainly valid points. I wasn't saying that the handler
approach would be a bulletproof way of checking the successful operation
of the service, only that it would offer useful information beyond what
you'd get by just having an echo at the message receiver level.
A true robust approach requires client-side code to support switching to
another service instance when the in-use service fails to respond
properly, along with a central registry of services instances so that
the client can find a new one when it needs to. If the client switches
between different service instances and continues to have problems it
knows that either the problem is due to something fundamental to the
service (backend database crashed, network disconnection, etc.) or it's
making bad requests.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
