+1 to David's point. I would prefer this be optional and not required for all MessageReceivers.
Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 "David Illsley" <[EMAIL PROTECTED]> 02/09/2007 03:25 AM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [axis2] Pinging capability to services deployed in Axs2 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]
