I've come across several examples of SOAP-based web services where automated tooling fails to build a client that works.
Investigating these examples leads me to believe that the WSDL the service uses to describe itself doesn't quite match the service that's being provided. Maybe a wrong type somewhere, a different data structure - something.
I'm unsure what the most appropriate response is - if we assume that the obvious one (get the provider to fix their stuff) isn't available.
Some options I can think of:
Make a fixed WSDL?
Hack the generated code?
Any other options?
No good options?
What good experiences have people had? What works in a real environment?
Thanks
I'd try for the first option, make a fixed wsdl. If that doesn't work then you could fall back on hacking the generated code.
Of course if the service is radically different from the WSDL you might not have much luck with those 2 options.
If you're lucky there's another way. Some web service frameworks support returning a dynamically generated WSDL.
I know with an AXIS 1.4 service you can do a GET on the service url + '?WSDL' and get back a dynamically generated WSDL.
e.g. http://foo.com/service/?WSDL
First I would try to confirm if the tool created a correct binding for the WSDL. If the WSDL is correct and the tool generates bad bindings which do not result in correct SOAP request / response processing, the tool author might provide a fix or a workaround.
Related
I had an endless argument with a friend recently. Our company exposes web services endpoints without their WSDL. WSDLs are hidden inside the system.
Some colleague say "it's better for the security". I say WHAAAAT ?
Another argument is "You don't need to expose the WSDL, because it is only used at development time".
So basically they say that when someone consume our web service, there is always a time where you pass the WSDL by email, in order to let them build a client. Once you are in prod, the WSDL is no longer used.
So, please, tell me I'm right. Tell me that when you expose a service to the outside world, you MUST expose the contract with the endpoint. It's THE RULE. talking about development is irrelevant here, right ?
My friend says that I'm biased because I wrote a dynamic gateway, so I need the WSDL at runtime, and this kind of scenario is very rare.
What really pisses me off in all of this is that the WSDL is considered as the .lib and .h of a .DLL or .SO, it's "just a thing required at development time".
I don't know what it is for CORBA and IDL... Does the IDL was exposed to the public at runtime ?
So, what is the right thing here ? I'm lost. The client is intended to receive the WSDL at runtime right ? Or not ? It should perform some kind of validation at runtime right ?
You are wrong. Making a good interface can take a lot of effort, years of experience, and the WSDL is a very detailed description of the service. If that is a secret, so be it. As authentication might be included, there is also a potential security issue.
I would like to argue that you should NEVER download the WSDL from a service if you can get the original instead. The online WSDLs are sometimes generated by the SOAP framework and things documentation will often not be included. Furthermore the endpoint address should always be explicitly set, never use the value which might be included in the WSDL.
In fact the right way to communicate the service definiton is not only a well-defined set of WSDL / XSDs but also with concrete request/response examples in including error responses.
Relying on downloading a WSDL to bootstrap your service is a receipt for disaster (if this stops your app from starting).
So I'm evaluating this tool called QLIK over BIRT which should be used to pull and represent data from a SOAP service.
In BIRT I basically just supply the WSDL and I'm done. If I want to do the same with QLIK they tell us in the tutorial to use an external tool to create the SOAP Request and then use it as POST in something they call "Web Connector", which I can't find anywhere in the UI.
Am I missing something here or is it basically not possible to use SOAP services with QLIK inside the tool?
Bonus points if you can tell me where this "Web Connector" is.
Also I find it pretty confusing that they offer a REST connection but no SOAP connection on the datasource selection page?
I did find a place to configure a SOAP service in a menu called "SalesForce" shich is as far as I understand some 3th party service. This all makes totally no sense to me.
There are a couple of options to do this as I understand it, however I've not worked with SOAP/WDSL myself.
Use the REST Connector which is included with Qlik Sense v2 but is also free for earlier versions of Qlik Sense and QlikView. This allows you to issue a POST command rather than a GET command. The request body would presumably be the XML.
Use the "General Web Connector" from "Qlik Web Connectors". This is an add-on that you have to subscribe to, so if the REST one works for you, there's probably not much reason to go for it. That said, the documentation for it is more useful with some worked examples. (The background here is that Qlik bought a company that made a tool called QVSource earlier this year - hence the overlap between these two approaches and why the documentation is still branded as QVSource)
Hope that helps, sorry I can't be more specific.
I am a SOAP/WebServices newbie, and have been given a WSDL file that has a bunch of web services that I can connect to.
What is the easiest way to parse this and show me what services are offered, and what the input and output parameters are that are required? I really don't want anything more than this, but for whatever reason I can't seem to google an answer.
The closest I've gotten is using wsdl2java from Apache Axis, however it creates a whole bunch of Java objects. What I really want is very basic, which is give me a list of all of the services available, and the input/output parameters.
Does such a thing exist or do I need to build this myself?
Without installing anything I suppose this link would work but it requires that your WSDL be web accessible...
http://www.validwsdl.com/
Other online parsers may be better. Personally I'd recommend installing Eclipse with the web services plugin or the demo version of SOAPSonar, but if you only need to peek at what a WSDL offers without having to dig through the XML, then the above link might be an acceptable option.
What is the reason why hitting, for example, http:///_vti_bin/UserGroup.asmx?wsdl gives me a not full wsdl specification (if compared with http://msdn.microsoft.com/en-us/library/dd965659%28v=office.12%29.aspx)?
What I mean about not full: it does not contain some of complex types definition, e.g. User (unlike the full one), so this types are no generated by the wsdl.exe.
I have a question in regard of this: is it safe to generate c# web service stub basing on specification from MSDN or this approach is dangerous due to possible changes in contract?
For your first question as to the WSDL not being the same: it really should be equivalent and contain all the types! Whenever you append /_vti_bin/UserGroup.asmx?wsdl to your site's URL, SharePoint should definitely display the FULL WSDL, including the complex type definitions, etc. I just tried it now against my own SharePoint instance and the WSDL returned from http:// mysite.com/ ...snip... /pierre/_vti_bin/UserGroup.asmx?wsdl is pretty much the same size as the one from http://msdn.microsoft.com/en-us/library/dd965659%28v=office.12%29.aspx and a quick check to make sure complex types are in both places confirm that.
To answer your second question: I think you should NOT create your Web Service stubs and skeletons based on the WSDL in the documentation. Instead use the WSDL returned from your site. If you're not getting all the complex types in the WSDL returned from SharePoint, you should fix that issue first.
First thing I would try: download SOAPui (free) and simply plugin the URL that ends with ?wsdl and create sample requests. Maybe you'll run into access issues (UAG or other) but at least you'll know that the WSDL is well formed. If SOAPui can generate the client code based on the WSDL, you can too (using wsdl2java or the wsdl2dotnet equivalent; I can't remember the name of the .net version).
And yes, it's dangerous to copy the WSDL from the docs but I'd be more worried about some things being abbreviated or documentation going stale, etc.
As for the contract changing, I'm using the UserGroup.asmx?wsdl endpoint since 2009 and it still works on newer versions of SharePoint (even after the upgrade to SP2010). And I'm using java as the client code. Microsoft really nailed the Web Services in SharePoint, it was surprisingly easy to integrate our java stack and make calls to/from the SharePoint web services. And it was also very inter-operable with the other tools we use to test Web Services like SOAPui, etc.
Which approach (Contract-First/Code-First) should be used when creating Web services with Apache Axis2? If I choose the contract-first approach, which tool should I use to create wsdl? I am using the WSO2 platform.
Contract-first is the best approach IMHO. The reason is quite simple. When you code first and generate a WSDL, it might change. This may cause problems for other teams working on client code based on that WSDL.
In case of contract first, the WSDL will always be the subject of discussion between teams, and it will not just change because of code changes, but only when all parties agree.
It is best to use versioning in it as well.
You can create a WSDL in Eclipse, which also has excellent checks (requires internet access).
Definitlety contract first.
Interfaces are the way to go for strong typed web services.