The question you've asked goes to the heart of the difference between
RESTful web services and today's SOAP services, so this might not be
terribly intelligible. I will try my best.
A typical SOAP/WSDL service deploys a single "service" object (the
SOAP endpoint) and a WSDL document. The WSDL document points to the
URL of the service object, and describes the format of the documents
to be submitted to that URL.
A RESTful web service works more like a web site: it deploys a large
(probably infinite) number of objects, each with its own URL. The
client can get a description of an object by sending a GET request to
its URL. The description will contain information about the object,
but it will also contain links to related objects, and forms that
explain how to modify the object. The information that would go into a
WSDL file (the URL of the service, and what document formats the
client should use) is distributed among the many objects. Each object
The client starts at some known "home page" object, and follows the
cues to other objects. There are a number of technologies that a
service can use to convey these cues: HTML, WADL, "anyURI" nodes in an
XML document, etc. WSDL 2.0 technically falls into this category, but
it's almost never used for this purpose.
This leaves open the question of how the client knows the "home page"
URL, and how the client knows that the object at the other end of that
URL will help the client reach its goal. The closest RESTful
equivalents to UDDI are search engines like Google. These work well
for the WWW, connecting human beings to URLs that help them reach
their goals. But search engines don't really pick up web services. For
a variety of reasons this problem has not been solved. I expect that
when it is solved, the result will look a lot like a search engine, or
be part of a search engine.
To answer your specific questions:
I don't know if you can publish the URL to a RESTful service to UDDI
(Sam might know). Assuming you can, it's not going to look like other
services in the directory.
You can write a WSDL 2.0 file for at least some RESTful services, but
it's usually more trouble than it's worth. A framework that makes it
possible to generate WSDL for a RESTful service is conceivable, but I
don't think there are any.
Once the user of the web service knows the main URL for the service,
they can GET that URL and see links to other URLs. They will also see
forms that tell them what verbs to use.
What I've described is an idealistic scenario. In most real
services today, some of the links and forms are missing. You have to
read the equivalent information from a natural language document, and
program the information into your client.
I hope this helps. The book covers these topics in detail, especially
in chapter 10.