SOA 服务发现 (UDDI) 在实践中如何工作？
我只是在阅读有关 SOA 的内容，并且经常提到服务注册中心/UDDI。 听起来不错，但是实际使用起来如何呢？
- 注册表是否旨在将逻辑服务与其物理实现（端口、URL 等）分离？
- 注册表是否是供寻找有趣服务的人浏览的？
- 硬连线是“错误的”吗？ 应用 它使用的服务？
I'm just reading up on SOA and the service registry / UDDI get mentioned regularly. It sounds nice but how is used in reality?
- Is the registry meant to decouple a logical service from its' physical implementation (port, url etc)?
- Is the registry meant to be browsed by a human looking for an interesting service to play with?
- Would it be 'wrong' to hard-wire an
application
to the services it uses?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现它在理论上比在实际中更有用。 它很少被实现，也很少被使用。 实际上，DNS 为网络上资源的位置提供了足够的抽象工具。
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.
服务注册表存储和发布有关所有可用服务的信息，主要是它们的接口描述和它们当前的 URI（ip、端口等）。 这样，应用程序可以简单地向注册表询问所需的服务，并获得合适的服务实现的详细信息，并且可以进行连接。
UDDI 并不是获取服务注册中心的唯一方法。 但请记住，UDDI 仅适用于 Web 服务，因此仅当您的 SOA 仅包含 Web 服务时它才有用。
1）正确。
2）不，它并不适合人眼。 当然，有一些工具可以浏览目录，但它们主要用于查看注册表是否获得了您需要的服务等。真正的使用直接发生在您的应用程序/服务和注册表之间。
3）这取决于你想要完成什么。 如果您想构建 SOA，它会认为这是“错误的”，因为这与 SOA 的松耦合范例相矛盾。
如果这是您唯一的服务，唯一使用它的应用程序，并且该服务很可能不会更改它的 URI，那么硬连接它肯定没有问题 - 但可能不需要分离该服务:)
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 :)
使用多播来发现服务怎么样？ 喜欢使用 jgroups 或 SLP？ 所有服务都会发现彼此并将其所需的服务注入代理中。 然后在实际的传输实现上构建抽象。 （例如休息、肥皂、rmi）
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)