Focus on Private UDDI
There doesn't seem to be a big demand for deep UDDI knowledge in the developer world. Although I enjoyed Java Web Services 1st edition, the 41 pages of UDDI was overkill. I think you should brush the surface of the core technologies/APIs, talk about UDDI vs. ebXML Registry/Repository, and focus on practical uses of registries within an enterprise.
Let's face it--dynamic agents aren't going to search UDDI registries, find a service, auto-negotiate, and invoke methods with no human intervention. You made a good point in your 1st edition about how it is most likely that business analysts will take care of the searching and negotiating.
Public UDDI won't fly.
Recommendations and Google will still be the main source for finding any kind of product or service. (It would be nice if Google started a public UDDI registry. It would be even nicer if they added a "UDDI" tab to their main page and organized it like their Web Directory. That way you can search based on relevance and not worry about Microsoft, HP, or IBM always ranking first.)
Last but not least, the topic of Private UDDI registries within an enterprise or amongst partners. Most likely, this is how UDDI will be deployed anyway. A company will publish all of its services in an internal registry to maintain an organized repository. That way they can easily integrate new Web Services into their private portal or have a standard way for all the departments to use each others services.
The funny thing is I'm using UDDI for something it wasn't really intended for. Web Service client programs will usually know the URL Endpoint of the service they wish to invoke. There are many ways of specifying the service to invoke: they can either go through the trouble of querying a UDDI registry and obtaining the URL, obtaining it through input from a user interface, or just hard coding it into the code just to name a few. Since web services are similar to web servers in that they must learn to deal with traffic, web services clients must also learn how to deal with responses from web services. No one wants to see a 404 page or a SOAP Fault. There are many methods for server mirroring, failover, fault tolerance, backup, redundancy, or whatever you want to call it, that should ensure uptime. My point is that I'm using UDDI to query for backup services. For example, the client program tries to connect to a web service, the client doesn't receive a response, receives a certain response, or a SOAP Fault that triggers it to disconnect from the current service, query a registry for backups to the service, and connect to that service using the Endpoint provided from the registry. Of course, this assumes that the backup web services are replicas of the one that went down, hosted on different servers, or that they are services that are written by third parties who adhere to the same standard naming convention.
Just an idea of how to use UDDI for something practical. So my final advice is to get rid of it as separate chapter and include it in a "Web Services Issues" chapter or in the case of my last example it can fit in with SOAP Faults, handling responses, or some kind of chapter that discusses deploying mission critical web services and how to ensure uptime with web services clusters.
Hope that helps,