0

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?

coder kemp
  • 361
  • 2
  • 13

1 Answers1

1

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)

  • DNS resolution of the hostname in the URL
  • Ping the remote host
  • HTTP GET to the URL of the SOAP service + ?wsdl (this usually works). This is also a good time to verify SSL connectivity.
  • You can also parse the WSDL doc, assuming one is returned for identify the endpoint url.
  • Finally if that all works, execute the service. HTTP 200 is general a positive sign

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).

spy
  • 3,199
  • 1
  • 18
  • 26
  • Interesting inputs thanks. However I need clarifications on these points shared by you. 'the endpoint is in a config file somewhere or some idiot hard coded it' : which config file are you talking about, can you be specific? & 'HTTP GET to the URL of the SOAP service + ?wsdl (this usually works). This is also a good time to verify SSL connectivity' : So, with get() call I am trying to open the wsdl file in the URL. So what can we conclude from this? – coder kemp Oct 15 '17 at 04:23
  • When developing software that interacts with a web service that is remote, the location of that service has to be stored somewhere. Depending on the language, it could be a .config file (.net), .properties file (java) or just about anything else. Otherwise it's hard coded. What happens if the URL changes? – spy Oct 15 '17 at 12:56
  • 'HTTP GET to the URL of the SOAP service + ?wsdl". Most web service frameworks with create a wsdl doc on the fly from reflection. If ?wsdl responds, there's a great chance that the service it reachable. It won't tell you if any resources that the service needs are online though, such as a database – spy Oct 15 '17 at 12:57