If you take a closer look to the Java specification you'll have a clue of what is clearly the WSDL.
When you build a Web Service in Java you have several way to do it.
- SOAP, spec Jax-WS : this standard is kind of strict. It order to communicate with it you have to respect a contract. This contract, named the WSDL, is an XML that define how to reach the WS, which parameters are needed and what are their types. This file is provided by the service and most of modern IDE would generate it but you have to provide it to your client so it can call the WS respecting the contract.
- REST, spec Jax-RS : this standard is far less strict as you have no contract. This provide an URL over a specific HTTP method (GET, POST, PUT, DELETE). To make a call to this kind of WS, just call it and you'll see what happen.
- Queue JMS : this is a kind of different as the two others but seems important to me as it provide a way to create messaging reliable, decoupled et asynchronous. It is based on a connection factory to deals with the communication.
These standard are implemented in most of the main technologies today. Java EE with its EJB has implementation for the three of them, as do Spring.
SOA provides many ways to communicate now, depending on what are your needs.
I hope I helped, don't hesitate to ask if needed.
EDIT:
To explain use case I'll try to set up an example... It's a kind of hard exercise and not perfect but I hope it will help you.
Consider, you work for a house seller. You have three different call to WS: 1. you confirm a sale on your website, 2. you search in your catalog, 3 you inform your boss via a small message on the intranet.
I precise that using three different type of WS is not compulsory.
- This action is really important for your workflow. Data that are
sent must arrived. You must be sure to respect what is expected on
the WS. Client side and server side must be perfectly matching.
You'll use SOAP because there is a specific contract between these
two sides.
- For this you don't need a specific and rigid contract. Searching is just easy and does not need a structure with defined arguments. Just get data and print it on the screen. Here REST is maybe more suitable because it is easier to set up and if modification are needed, there is no contract to modify on client side.
- For messaging, you want to send the message and that's all. JMS are queues waiting for "message". These messages are requests that will be consume asynchronously. The message will be stored waiting for a consumer to take them in the queue order (FIFO).
The generation of the WSDL is your task. It will generate an xml file based on your Java code of the WS. Notice that the contrary is possible too, if you have a WSDL you can generate the Java from it(see this. Most of the time you have an url corresponding to your WSDL file so it can be accessed from your client.
You can generate WSDL from the IDE. But I'm not sure using Maven is the right way. The WSDL is your contract, it may be the one you based your WS on. The generation with IDE is just a way to make your life easier but at the end the WSDL may not change a lot. If it does then maybe SOAP is not what you need. REST may be more "agile".
Look at these links for manually generation with IDE (IntelliJ, Eclipse) or with external tool WSGEN.