4 ms·
> WSDL/XSD specs in this case seem to be incomplete or just wrong. Are you meaning in my comment, or in the GitHub repo the article references? Asking because
by justinclift 11d ago
> WSDL/XSD specs in this case seem to be incomplete or just wrong.
Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
- lazide 11d agoAre you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services? Which is also my experience too. Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.
- justinclift 11d ago> Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services? Correct, yes I haven't. Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above. And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
- lazide 11d agosorry to hear that. if it’s any consolation, once you do get something that works, it tends to be pretty solid job security.