I was asked this question in a technical interview for a integration intern role.
He was digging much into understanding of SOAP web services.
Question). Consider that you are exposing a web service through SOAP to a Client. The url through which you are providing the service is up and running when you check it. But the Client has a problem, he is not able to access your webservice. How will you go on troubleshooting this issue?
My response:
I would first check whether the url the client is trying to access the service is correct. Will check the .wsdl file: port, bindings & will check once whether upon sending a SOAP request to the URL, am I receiving the SOAP response in local through SOAP UI. If I get error, will troubleshoot based on the kind of error I get: Like page not found, null exception etc.
I felt he was still expecting some other point. He hinted saying where in what registry you will check all the web services which have been hosted(I guess this was much of a production support issue :P)
I told I may look into UDDI registry, but was not sure with this.
Please let me know your inputs on what could be possibly a right approach?
Apache jUDDI PMC here. Yes UDDI could be used to verify that the client is pointed at the right location, assuming the client knows where the UDDI server and that it is registered and the client knows what to query for on the UDDI server and a UDDI query is part of that client's normal workflow. That's a lot of assumptions but certainly feasible.
Most of time, the endpoint is in a config file somewhere or some idiot hard coded it.
That said, this my go to list for checking SOAP service connectivity (from the client's perspective)
Edit: Another alternative approach is to implement a very simple API (wsdl method) on every SOAP service that simple returns a true/false that answers the question "Am I open for business?". This method would provide a standardized approach for identifying if a service was available or not by testing an external dependencies (databases and whatnot).