Just once to get the address location and use it forever?
Every time a call is made?
Or some time in between?
The only purpose of the WSDL URL is to return the WSDL that describes the current service.
The only reason to ever read it is if the reader does not have the WSDL that describes the current service.
The only time a reader would need to read it is if they never had the WSDL that described the service, or if the service has changed.
Some downlevel clients are pretty stupid and need to download the WSDL before each call. Avoid them.
It depends what you are trying to do. If you're calling or referencing the Web Service...you will need to re-reference it when the Web Service interface changes. If the Web Service interface won't change, then you only need to reference it once
I agree with John and would add that in most cases you don't need the WSDL to be hosted on a URL at all. Unless you have a public web service that anyone can sign up and use you're probably better off to keep the wsdl to yourself and only fork it out to specific users as needed.
Related
I am going to deploy a SOAP web service on a WebLogic server.
The endpoint of the service is something like:
http://myserver.mycompany.com:1234/MyService-0.0.1-SNAPSHOT/MyServiceService
However, if (using a browser), I navigate to either
http://myserver.mycompany.com:1234/MyService-0.0.1-SNAPSHOT/MyServiceService?WSDL
-- or --
http://myserver.mycompany.com:1234/MyService-0.0.1-SNAPSHOT/MyServiceService?xsd=1
I can see the WSDL or schema file, respectively, for the service.
My group does not deploy a lot of web services (we're a back-office group and use Oracle Middleware to automate what little services we do provide), so a question has come up regarding whether exposing the WSDL file and schema file is "best practice".
Is it OK for these files to be visible, or should access to them be shutdown somehow? Conversely, is it even possible to restrict access to them, or would that interfere with clients trying to access the service?
This is an old question, but anyway.
It depends, but in my projects it was considered a bad practice to do so. You should always do Contract first, don't base your WSDL on your code or most likely you will end up with a WSDL that is somehow dependent on the programming language used for the implementation.
I don't know how Weblogic behaves but I remember that Jboss (5) used to generate the WSDL from the code any way and serve that. Even when we did Contract (WSDL) first development. So you would end up with little differences in these WSDLs which may cause problems. Exchange of the WSDL and the XML Schema files should be done by other means. It is possible to restrict access to any URI on Weblogic.
Another aspect is, that if you don't remove these, we found the developers on the clientside will start pointing their development-tools and implementation to these endpoints to get the WSDLs. This will most likely also cause problems and at least (a lot) unnecessary downloads of these files. As most frameworks will (need to) read the WSDL every time they instantiate the client-code. By not providing these endpoints, you keep the clients from these bad practices.
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).
When I'm tasked with dealing with connecting to web services, I've always found the appropriate .wsdl file, ran WSDL2Java.bat, and incorporated those Java files into my Java project. Then I've successfully completed my project that needs to access data via web services.
My question is, are there other ways to use the .wsdl file to access web services? ( I'm not talking about creating classes for different languages ). For example, I have documentation describing one company's web services. The examples it shows in it's documentation are essentially dumps of HTTP Post requests. Is this "web services"? It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right? I really feel like I'm missing something here.
Am I a web-services illiterati?
To call a SOAP web service over HTTP you just need to send it a properly formatted XML with a POST request. That's it! How you build the request is irrelevant as long as it conforms to the SOAP protocol and the payload corresponds to a proper web service operation that exists on the particular web service you are calling.
But how do you know how to build the proper payload?
The web service needs to have some sort of documentation otherwise you don't know what to put inside the XML. The documentation can be whatever you like as long as people can use it to build valid requests. WSDL fits this criteria but has an extra advantage: you can feed it to a tool that generates code. That code knows how to handle all the SOAP details and exposes objects and methods to your application.
What would you prefer? Generating code from the WSDL in a few minutes and be able to call whatever operation on the web service or, build the requests and parse the responses by hand and spend hours or days doing so. What would your boss or company prefer? :)
It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right?
Right! But you also have to consider your productivity as an employee in one case as opposed to the other.
Is it mandated by any standard that a web service should provide a WSDL by appending ?wsdl to the endpoint address?
Is it OK if the WSDL is hosted at a different URL (without appending ?wsdl)?
For example:
Endpoint: http://abc.xyz.com/MyService
WSDL: http://abc.xyz.com/MyServiceDefinition.pqr
Note that I'm even using a different extension for the WSDL definition.
Does using this approach violate any standards or one can host the thing the way they want?
Is it mandatory to have a WSDL definition accessible using ?wsdl?
No, it's not.
A WSDL is used to describe a web service contract and is provided because it allows tools to automate generation of client stub code for calling the specified web service. Exposing the WSDL at the same location as the web service with ?wsdl appended to it is just very handy and that's the convention everybody uses.
People and tools look for the WSDL at that location and frameworks automatically expose it at that location but it's just a convention. As to my knowledge this isn't specified in any specification (or at least none that I could find).
Sometimes though you don't want to provide a WSDL that everybody can look at and try to create a client because it's a private web service and you only want to give access to your partners, not to everybody. At that point you can disallow the ?wsdl URL and provide the WSDL only to your partners by using an alternative channel. You can even e-mail it if you don't want it exposed online.
So you can choose whatever channel to expose it. Just remember that because people and tools are following this convention they are used to see it there and some (poorly written) tools might choke in a different extension, for example.
P.S. One other thing I wanted to mention - which isn't strictly related to this answer but kinda reinforces the convention - is the new ?singleWsdl option in WCF 4.5.
WCF, as most other tools, exposes the WSDL at the ?wsdl address but uses xsd:import statements with external schemas. Some frameworks were not able to process WSDL with imported dependencies so people started to write customizations over WCF to have a flat WSDL exposed, so much so that in the latest version of WCF Microsoft decided to add this feature out of the box.
But for backward compatibility they needed to keep the ?wsdl endpoint as it was (returning a WSDL document with xsd:import statements inside) and were forced to add a new query parameter for the flat WSDL: ?singleWsdl. I'm sure this idea will be picked up by other web service vendors and providers as well.
No, Its not mandatory to have ?wsdl access, but its recommended way.
Its worth noting that most clients will try to append "?wsdl" to your URL and will try to access WSDL file, Hence its highly recommended to setup it.
I am new to Enyo and web services. I am looking to build a web page with Enyo that will require use of Echonest. Can anyone help me understand how to connect to the Echonest service from inside Enyo and whether to use SOAP, REST, or something else?
I assume you are talking about the Echo Nest found here: http://the.echonest.com ?
Briefly glancing at their API, you may not have to use SOAP or REST since everything is accessible with simple GET requests through the Web service. It looks like the hardest part of using their API will be generating OAuth signatures for authenticated requests.
As far as the enyo.WebService, http://enyojs.com/api/#enyo.WebService, goes, you should be able to include the kind, set the URL and call the .send() method on it. Then you response handler would get the data back (I recommend json) so you can do what you will with it.
Another option would be to use enyo.Ajax, http://enyojs.com/api/#enyo.Ajax, directly. enyo.WebService wraps that and provides a familiar (to Enyo 1 developers) way to use it.