So how about a handler approach, with an optional interface that MRs can implement if they do support being interrogated about current status? David
On 09/02/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
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]
-- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
