I was just asked by a colleague how to do a Web Service ping, to see if it's alive. He started with SOAP services and then went to HTTP services. For the latter it's easy - if there's any GET operation, just do that and see what happens, it should be safe. But for SOAP services, in absence of any operations marked safe, I suggested this:
Just send the service a message with a mandatory (mustUnderstand) header that you know the service won't understand, for example <ex:FailWithMustUnderstandFault s:mustUnderstand="true"/>. It should even specify that if a SOAP processor understands and processes this header, this must result in generating a mustUnderstand fault, and performing no other processing on this message.
This would be unnecessary if everybody agreed on a Ping operation, but that's not going to happen; and it only checks that the SOAP engine is running correctly, as opposed to any services deployed in it. Could it be useful anyway? 8-)
Posted at 1527 on Thu, Jan 26, 2006 in category Ideas | TrackBack | Comments feedInteresting idea, but I guess there's one small issue - SOAP only requires you to generate and not to send the fault, so you might not get to see the 'pong'. Maybe you need to write a WS-Ping spec ;0)
Posted by: Paul Downey at January 27, 2006 12:09 AMYes, that is true, but as far as you can get anything from any SOAP service, such fault is it. We can't expect every SOAP services to process WS-Ping because it's not part of SOAP, and I expect that there will be very few services that drop the mustUnderstand fault when they are alive and there is a return channel.