When re-using someone else's service it's nice to know if that service is actually still running. Thankfully whole armies of people are out boiling the world's oceans to come up with mind boggling sophisticated systems to solve this difficult problem. But until all the water has boiled off and their universe saving contraptions are available might I suggest a simpler interim approach? Why not use SOA-Ping?
SOA-Ping
Semantics:
The successful receipt of a pong message in response to a ping message means that the associated interface is at least functional enough to send the pong message. It bears repeating that each interface is expected to support its own ping operation.
Request Format:
<y:ping/>
Response Format:
<y:pong/>
Relax-NG Schema:
namespace y = "http://xml.goland.org/20051005ping"
Ping = element y:ping { anyElement* }
Pong = element y:pong { anyElement* }
Extensibility Notes:
One can imagine an infinite number of things that one can put into a ping request or the pong response. For the response in particular one can imagine things like status messages ("the service is running fine") or URLs pointing to human readable status pages or machine processable status indicators or whatever. Go wild! Stick in whatever you want.
But do notice that only elements can be made children of ping and pong. For good hygiene purposes please only use namespace qualified elements as children. Also note that anyone processing a ping or pong message MUST ignore any child elements they don't recognize.
Acknowledgments:
David Orchard was guilty of thinking of this before me in the specific context of SOA. He is also guilty of pointing out the obvious SOA-Ping pun. But hey, it's all good clean fun!
There is a problem: you cant test one service with a different interface. I mean you can test the listener, the container and maybe the stack, but not the interface itself.
With traditional WSDL-described services you can not test the operation, only the Porttype.
However it is a good idea to design for teasability and monitoring.
Gruss
Bernd
I’m not sure how you ever can really test an individual operation short of having some known “safe” inputs that are guaranteed not to do anything. But in that case they really aren’t testing much. My general feeling is that testing the interface’s existence is about as good as it’s likely to get.
I do intend however to re-write this article for different transports. For example, I want to create a HTTP version that uses Options on the interface URL and returns a header that means “btw I ran a test and I still seem to be alive.”