I'm just reading up on SOA and the service registry / UDDI get mentioned regularly. It sounds nice but how is used in reality?
A service registry stores and publishes information about all available services, mainly their interface description and their current URI (ip, port, whatever). This way the application can simply ask the registry for the needed service and will get the details of a fitting service implementation, and can connect.
UDDI is not the only way to get a registry for you services. But remember that UDDI is intended for webservices only, so it's only usefull if your SOA consists only of webservices.
1) Correct.
2) No, it's not really meant for human eyes. Sure, there are tools to browse the directory, but they are mainly for looking if the registry got the services you need etc. The real usage happens directly between your application/service and the registry.
3) That depends on what you want to accomplish. If you want to build a SOA it think it would be 'wrong' because this contradicts the loose coupling paradigm of SOA. If this is your only service, the only application that uses it and it's likely that the service won't change it's URI there's definitely no problem in hard-wiring it - but then there's propably no need to separate this service :)
I find it to be more theoretically useful than practically useful. It is infrequently implemented and infrequently used. In reality, DNS provides a sufficient abstraction tool for the location of resources on the network.
how about using multicast to disover the service? Like using jgroups or SLP? All the services will discover each other and inject the one they need into a proxies. Then building abstraction over the actual transport implementation. (e.g. rest, soap, rmi)