Hi, is there a good way to test (ping) an axis webservice? I use axis 1.4 for my service client. I would like to avoid having to mock up a sample request, but if there was a standard way to ping an endpoint or endpoint + method, that would be great.
Originally posted by Andy Hahn: I would like to avoid having to mock up a sample request, but if there was a standard way to ping an endpoint or endpoint + method, that would be great.
What would you do any differently if the "sample request" fails instead of the actual request? And just because the sample request succeeds doesn't guarantee that nothing unfortunate has happened to the server/service in the meantime - so you will still have to handle the actual request failing.
So you might as well deal with the situations that you have to deal with anyway and not add any new ones.
My goal (or thought) would be to try to not use a request or sample request at all. My hope was that the axis stubs would be able to test an endpoint without a request at all.
If there way a way to test/ping an endpoint successfully, I could verify 1) connectivity, 2) mutual authentication/ssl is working prperly, and 3) that the service is up. I agree with you that if I really wanted to test the response payload then I would need to send an actual request.
The reasons for not using an actual request are 1) we get charged for calling the service, 2) we use live sensitive customer information in the payload (every request gets audited), and 3) historically most of our axis related issues have been with connectivity/handshake/service being up.
The goal is to create a screen with button for testing the various services.
Originally posted by Andy Hahn: The reasons for not using an actual request are 1) we get charged for calling the service, 2) we use live sensitive customer information in the payload (every request gets audited), and 3) historically most of our axis related issues have been with connectivity/handshake/service being up.
You have a service level agreement that makes you pay for unsuccessfully completed requests??? Or it this a transport layer cost? The sensitivity issue has to be resolved regardless of whether the request will be successful or not. And your third reason simply emphasizes your need to have a way of gracefully backing out if something goes wrong "in the middle". Web service invocations are not as transparent as local object method calls.
And there is no standard way of determining if a "service is up". In fact some services are "composed services" that could fail if any one of the services they delegate to is down. So the only way to know is to try and then gracefully deal with any exceptions that may occur.
Post by:autobot
Why fit in when you were born to stand out? - Seuss. Tiny ad:
a bit of art, as a gift, the permaculture playing cards