Generating a WSDL from an XSD file

The Java runtime library supports validation. Last time I checked this was the Apache Xerces parser under the covers. You should probably use a javax.xml.validation.Validator.

import javax.xml.XMLConstants;
import javax.xml.transform.Source;
import javax.xml.transform.stream.StreamSource;
import javax.xml.validation.*;
import java.net.URL;
import org.xml.sax.SAXException;
//import java.io.File; // if you use File
import java.io.IOException;
...
URL schemaFile = new URL("http://host:port/filename.xsd");
// webapp example xsd: 
// URL schemaFile = new URL("http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd");
// local file example:
// File schemaFile = new File("/location/to/localfile.xsd"); // etc.
Source xmlFile = new StreamSource(new File("web.xml"));
SchemaFactory schemaFactory = SchemaFactory
    .newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
try {
  Schema schema = schemaFactory.newSchema(schemaFile);
  Validator validator = schema.newValidator();
  validator.validate(xmlFile);
  System.out.println(xmlFile.getSystemId() + " is valid");
} catch (SAXException e) {
  System.out.println(xmlFile.getSystemId() + " is NOT valid reason:" + e);
} catch (IOException e) {}

The schema factory constant is the string http://www.w3.org/2001/XMLSchema which defines XSDs. The above code validates a WAR deployment descriptor against the URL http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd but you could just as easily validate against a local file.

You should not use the DOMParser to validate a document (unless your goal is to create a document object model anyway). This will start creating DOM objects as it parses the document - wasteful if you aren't going to use them.

You can not do that so easily. Usually, the xsd defines the structure (type) of the input and output messages. The wsdl used the xsd to define the operations that will be exposed by the service. An operation has usually a name and a pair of input and output messages.

I don't see how a tool could "reconstruct" the operations out of only the xsd only, except if it uses naming convention. E.g. messages requestDoIt and responseDoIt --> operation DoIt. If the xsd already contains the operations (which would be unusual) that could be ok, but it doesn't seem to be your case.

Manually creating the wsdl shouldn't be too long.

<types>
    <xsd:schema xmlns="..." targetNamespace="...">
        <xsd:import namespace="..." schemaLocation="MySchema.xsd"/>
    </xsd:schema>
</types>
...
 <wsdl:portType name="...">
    <wsdl:operation name="doIt">
        <wsdl:input message="tns:requestDoIt"/>
        <wsdl:output message="tns:responseDoIt"/>
    </wsdl:operation>
</wsdl:portType>

Have a look at WSDL essentials to get the general structure of the wsdl.

Or you can give a try to the tool WSDL Generator (from http://www.theprogrammerfactory.com/) whose purpose is apparently to ease this task. (Note that I never used it).

Another approach would be to generate classes out of the xsd, then use them to define the service class manually (this is the tedious part of matching types together into the corresponding operation) and then use another tool to transform the service class back into a complete wsdl. There are various tools available to convert to/from xsd and wsdl, for both Java or C#: wsgen, wsimport, xsd.exe, wsdl.exe.