我发现它在理论上比在实践中更有用。它很少被实现，也很少被使用。事实上，DNS为网络上的资源定位提供了足够的抽象工具。

服务注册表存储并发布关于所有可用服务的信息，主要是它们的接口描述和当前URI（ip、端口等）。通过这种方式，应用程序可以简单地向注册表请求所需的服务，并获得合适的服务实现的详细信息，然后可以进行连接。

UDDI并不是为您的服务获取注册表的唯一方法。但请记住，UDDI仅用于Web服务，因此只有当您的SOA仅由Web服务组成时，它才有用。

1） 正确。

2） 不，它并不是真正为人眼设计的。当然，有一些工具可以浏览目录，但它们主要用于查看注册表是否获得了您需要的服务等。实际使用情况直接发生在您的应用程序/服务和注册表之间。

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 :)

使用多播来取消服务怎么样？喜欢使用jgroups还是SLP？所有的服务都会发现彼此，并将它们需要的服务注入到代理中。然后在实际的传输实现之上构建抽象。（例如休息、肥皂、rmi）